[Clarification] web.xml context-param PolicyConfigurationFactory.provider

[darranl]

I was looking for the best mailing list to use but I see the one associated with the spec has 0 subscribers so will start with an issue, https://accounts.eclipse.org/mailing-list/jacc-dev. I can move elsewhere if we have a more appropriate location.

I wanted to start a discussion regarding the expected behaviour of setting jakarta.security.jacc.PolicyConfigurationFactory.provider in a web.xml context param.

This relates to changes introduced in #160.

For other types such as the Policy we are able to obtain instances specific to a web application by using the unique contextId of the application allowing each application to have their own registered implementation.

The PolicyConfigurationFactory API is however built around a singleton registration so calling setPolicyConfigurationFactory is JVM wide. Previously it was only possible to set the PolicyConfigurationFactory via the API directly or via a system property.

As this can now be set with a context-param in a web.xml I wanted to raise this discussion to understand the expected interaction if multiple web applications are deployed and what the scoping mechanism should be.

As it stands it feels that if multiple web applications define this context param unpredictable behaviour may result if these applications are deployed and undeployed independently.

[pzygielo]

re: mail list: I guess - https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/392, thus https://www.eclipse.org/lists/jakarta-security-dev.

[arjantijms]

Previously it was only possible to set the PolicyConfigurationFactory via the API directly or via a system property.
[...]
As it stands it feels that if multiple web applications define this context param unpredictable behaviour may result if these applications are deployed and undeployed independently.

That's true, and we shoud likely be extra clear about this in the specification.

The current bahaviour is equivalent to the case where previously a web application would set the PolicyConfigurationFactory via the API directly in a ServletContextListener. As an advanced operation, it's the user's reponsibility to make sure this is safe.

In the Javadoc for jakarta.security.jacc.PolicyConfigurationFactory.setPolicyConfigurationFactory we say "Set the system-wide PolicyFactory implementation". In the spec document we then say "The container can alternatively set a custom PolicyConfigurationFactory using the setPolicyConfigurationFactory method.", and then that the implementation we set comes from the "context initialization parameter (context-param in web.xml) jakarta.security.jacc.PolicyConfigurationFactory.provider"

So the scoping mechanism here is "system-wide".

The user could deal with this by e.g. only having one application per server, or, having one application that controls setting the factory and other applications that potentially use it.

I remember we did discuss this briefly on the Slack channel, and then said we shouldn't overcomplicate it for now and just host the existing system property into the web application and change little else until there is actual demand to for example set factories per application as well.