Facade for ServletRequest which may not be on the classpath and related cleanups

[dmatej]

Based on discussion from #161 this should be merged after merging PR #161

• previous impl used reflection and java.lang.Object, but in all javadocs mentioned that the Object must be ServletContext
• this is more strict, uses ServletContext directly, but as it still may not be available, it is represented by the facade, or null is provided, which is same as before.
• removed reflection including related error messages
• impl moved out of SecurityUtil where it doesn't belong

[dmatej]

Glassfish build including tests directly in build:

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  10:58 min
[INFO] Finished at: 2022-03-10T16:21:00+01:00
[INFO] ------------------------------------------------------------------------

Glassfish's old security_all tests:

[exec] ************************
[exec] PASSED=   724
[exec] ------------  =========
[exec] FAILED=   0
[exec] ------------  =========
[exec] DID NOT RUN=   75
[exec] ------------  =========
[exec] Total Expected=799
[exec] ************************
[exec]

BUILD SUCCESSFUL
Total time: 7 minutes 10 seconds

Glassfish's old webservice_all tests:

[java] **********************
[java] * PASSED          81 *
[java] * FAILED           0 *
[java] * DID NOT RUN      0 *
[java] * TOTAL           81 *
[java] **********************
[java] 

BUILD SUCCESSFUL
Total time: 9 minutes 22 seconds

[dmatej]

That Tomcat failure is caused by the fact that Tomcat released M11 and M10 was removed ...
https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.0-M11/bin/

[lukasj]

can you update it in https://github.com/eclipse-ee4j/metro-wsit/blob/master/.github/workflows/maven.yml#L86-L89, please?

[dmatej]

Locally build passed with M11.
The dependency update is here: #163

[lukasj]

the rule is simple:

if a class is in package com.sun.xml.wss.impl.misc, keys come from the resource in com.sun.xml.wss.logging.impl.misc; if a class is in package com.sun.xml.wss.impl.crypto, keys come from the resource in com.sun.xml.wss.logging.impl.crypto - unless some specific message is shared in multiple places

[dmatej]

I would start thinking about moving this class somewhere else - crypto? security? own package? Depends on class and package dependencies, I did not investigate too much, but "misc" is not the right package for this specialized utility class. Maybe it would make even sense to first remove methods if they are used just from one concrete place. That would help to get rid of part of dependencies and have a clear view on what remained.

[lukasj]

Maybe it would make even sense to first remove methods if they are used just from one concrete place.

that would be good start, I don't mind if the same code is copy&pasted on 2 places (3+ is just too much...) should it help

[lukasj]

LGTM

note that the nightly build is going to fail

[lukasj]

note that the second commit should be backported to EE8 branch

[lukasj]

This license is WRONG - must be EDL as is the rest of the code base. I'll change it.

[lukasj]

btw: nightly build job is saying that in https://ci.eclipse.org/metro/job/wsit-master-build/124/console (it's linked from the project home page) and notification was sent to metro-dev list

[dmatej]

Aha, I had a discussion with Arjan yesterday, he noticed somewhere that the copyright plugin takes just the first line to parse the year, so the latest should be first. Until now I always added just the second line.
Sorry for the license, I forgot it is different from Glassfish.

[lukasj]

it can check multiple things - for the year you are correct, it takes only the first line (unless copyright.ignoreyear is true), but it also checks the license as such either against arbitrary template (copyright.template or copyright.alternateTemplate (or sth similar) properties) or against some predefined ones packaged within the copyright plugin