Make web.xml accessible prior to ServletContext initialisation

[jakartaee]

Make web.xml accessible prior to ServletContext initialisation

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/servlet-spec/issues/9
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @shingwaichan

[glassfishrobot]

@glassfishrobot Commented
Reported by bleathem

[glassfishrobot]

@glassfishrobot Commented
rojkov said:
I think this needs a use case. I can't not suggest that parsing web.xml yet another time should be avoided. Possibly, we can define a pre-start phase that makes the xml available in parsed state.

[glassfishrobot]

@glassfishrobot Commented
bleathem said:
A use case is as I stated in the issue description, where one wants to access the web.xml from a CDI extension. For instance, to determine the JSF project stage, to conditionally activate different beans in production and development.

[glassfishrobot]

@glassfishrobot Commented
@shingwaichan said:
At this time, we don't expose the content of web.xml in Servlet API.
Where do you want to access the information contained in the descriptor and how can we reconcile the information specified by annotation?
It will be consider in the future release.

[glassfishrobot]

@glassfishrobot Commented
@shingwaichan said:
Adding it to the bucket of FUTURE_RELEASE

[glassfishrobot]

@glassfishrobot Commented
@edburns said:
Would it be sufficient to just make the WEB-INF/web.xml accessible or must all the fragements be considered as well? Also, we need to consider how useful this is in the case where the configuration comes from annotations.

[glassfishrobot]

@glassfishrobot Commented
gregwilkins said:
Also it would be good to have "prior to ServletContext initialisation" defined. Is this during calls to ServletContainerInitializers? In which case much of the content of the web.xml is available via API (and if not then we could add some more API).

I would really rather avoid encouraging other parsing web.xml, as this does not cover configuration from fragments, API, annotation etc.

[glassfishrobot]

@glassfishrobot Commented
This issue was imported from java.net JIRA SERVLET_SPEC-9

@gregw My suggestion here would be to look at what is missing from the ServletContext API that those CDI extensions are looking for. As CDI is bootstrapped using a ServletContainerInitializer it can access the ServletContext API at that time. Where the actual configuration came from should be irrelevant to the CDI extension as the ServletContext API is the 'materialized view' of a web application where configuration is concerned.