Resolves #265 Pass in a HttpMethod to the call to hasAccessToWebResource().

[darranl]

No description provided.

[OndroMih]

We shouldn't change the test, the test seems completely valid to me as the API allows calling hasAccessToWebResource method without any methods. The only thing that's missing is clarifying the behavior in such case in the Javadoc, as I mentioned here: #262

[OndroMih]

I'm curious what other committers think. @m0mus , @dblevins , @keilw , @rdebusscher , and others, what's your opinion?

[darranl]

To clarify for Jakarta EE 10 this method is documented as taking at least one method parameter:
https://jakarta.ee/specifications/security/3.0/apidocs/jakarta.security/jakarta/security/enterprise/securitycontext#hasAccessToWebResource(java.lang.String,java.lang.String...)

[arjantijms]

I think I remember what happened here. We had an overloaded method before; hasAccessToWebResource(java.lang.String), which specifically documented the 0 methods case. That one was merged into the one with the varargs, but then the javadoc wasn't updated.

The behaviour as it's now is technically correct and in the spirit of what was meant to be done (specifically what I meant to happen when I designed the method).

But, Darran is right that the javadoc is wrong. It indeed says "1 or more parameters", which is my mistake. Changing the test would help for WildFly to pass the TCK for Jakarta EE 10, but only if we can get an exception from the specification committee to update the TCK in a maintenance release.

Ondro is also right, that the target behaviour is as the test is now, and we would have to change the javadoc in the next release of Jakarta Security and then change the test back (or add another test for the 0 method case).

@darranl is it doable to simply update WildFly to accept the 0 method case as applying "to all the possible HTTP methods."? This would have to be done for the next release of Jakarta Security anyway, and as a bonus WildFly and GlassFish would be more compatible right now.

If WildFly would use WebResourcePermission as implementation detail (as Soteria is already doing by default), it would be trivial to support as well right? Jakarta Authorization has to be available and used by default in Jakarta EE, so there would be no reasons not to do that, would there be?