app-securitycontext TCK test should pass HttpMethod to SecurityContext.hasAccessToWebResource()

[darranl]

The published version of the specification specifies this method takes one or more methods:

https://jakarta.ee/specifications/security/3.0/apidocs/jakarta.security/jakarta/security/enterprise/securitycontext#hasAccessToWebResource(java.lang.String,java.lang.String...)

The tests in the TCK should be adhering to the published specification / API.

[arjantijms]

Thanks! Agreed. As per Ondro's comment, we should update the javadoc for a later revision of Jakarta Security. cc @OndroMih

[OndroMih]

I believe it's like @arjantijms says, we should clarify the behavior in the specification and javadoc. The test is correct and ensures a valid and expected behavior. But the behavior isn't clearly defined in the hand-written documentation. That's why I raised this issue earlier to update the docs instead: #262

[darranl]

At this point I have been able to get the test to pass in WildFly however:

I believe it's like @arjantijms says, we should clarify the behavior in the specification and javadoc. I completely agree that this should be clarified in a future version of the specification - however the Jakarta Authentication specification has now been published for Jakarta EE 10, any specification changes will be for a later version.

So at this point my understanding of the purpose of the published TCKs is to enable vendors who have provided implementations of the specifications to verify their implementation is compatible with the defined specification.  For this reason the tests within the TCK can not mandate behaviour which is either contrary to the specification or undefined within the specification.  The Jakarta EE 10 TCKs are also not the correct location to be mandating behaviour to be defined in Jakarta EE 11.

For Jakarta EE 11 once this behaviour has been clarified the test within the TCK I believe should actually be expanded to include a much more complete set of calls to this method exploring various permutations of paths and HTTP methods including empty lists, subsets of methods, lists containing all methods etc...

So the purpose of the pull request I have submitted is in relation to compatibility with version 3.0 of the Jakarta Security specification.  If there is any possibility of a maintenance release of the TCK this would enable the test to be using the API as presently documented, alternatively maybe vendors need to be able to optionally ignore this specific test. 

The test is correct and ensures a valid and expected behavior. But the behavior isn't clearly defined in the hand-written documentation. That's why I raised this issue earlier to update the docs instead: #262

Regarding clarity there may be history as to why the wrong text has been included but the API clearly specifies "one or more methods" - there is no ambiguity in this statement.