Adjust SecurityContextImpl to use ServiceLoader discovery for CallerDetailsResolver and ResourceAccessResolver

[darranl]

The server implementation may wish to be a complete implementation but at the very least it will be desirable to provide custom implementations of CallerDetailsResolver and ResourceAccessResolver.

[arjantijms]

Absolutely. I vividly remember this as one of the open issues for Soteria 1.0. We didn't have an actual SPI/Service Locator yet, and just quickly seeded the security context implementation with default implementations:

@PostConstruct
public void init() {
   callerDetailsResolver = new ReflectionAndJaccCallerDetailsResolver();
   resourceAccessResolver = new JaccResourceAccessResolver();
}

[darranl]

There are two different strategies I could consider for this one.

One option could be to adjust the CDI extension so servers can extend the extension and customise the behaviour, the instantiation of these implementations could be moved into a protected method allowing child classes to swap in their own instances.

Establishing a pattern of extending the CDI extension could be useful if other aspects of Soteria may way to be modifiable based on the server.

Or a simpler solution as both of these already have a defined interface may be to just use ServiceLoader discovery for the two classes with a rule that the first instance discovered will be used.

[darranl]

Actually as the SecurityContextImpl is already a CDI bean maybe it will be better for both these instances to be application scoped beans then alternatives can be provided. That would also mean if Soteria is bundled in a web application and not managed by a server alternate implementations could also be provided in a similar way.

[darranl]

Continuing the thoughts in this one, Soteria already contains a mechanism to use ServiceLoader discovery with Soteria providing a default implementation and prioritising the alternative if found - to keep this simple for now it feels easier to use this mechanism for the two interfaces used by SecurityContextImpl/

[arjantijms]

@darranl Indeed, Soteria contains this: https://github.com/eclipse-ee4j/soteria/blob/master/impl/src/main/java/org/glassfish/soteria/SoteriaServiceProviders.java

Eventually it would be great to identify why such things are needed, and see if we can address it by introducing standard APIs in future versions of Jakarta EE.