Bug in Struts ContextLoaderPlugIn?

[MHarhen]

The documented method of obtaining a reference to the WebApplication context is:

WebApplicationContext webApplicationContext = WebApplicationContextUtils.getWebApplicationContex t(servletContext);

Unfortunately, this does not work when using the Struts ContextLoaderPlugIn. The workaround is the following:

WebApplicationContext webApplicationContext = (WebApplicationContext)
servletContext.getAttribute(ContextLoaderPlugIn.SE RVLET_CONTEXT_PREFIX);

Can the ContextLoaderPlugIn be modified to support the documented method? It should be a simple one-line change and would have saved a lot of time.

[Juergen Hoeller]

Well, the ContextLoaderPlugIn context is not meant to be accessed that way, because it is not equal to the root application context: It is mainly intended for hosting Struts Action instances and cooperating objects for them. Generic business objects and other reusable stuff that does not depend on Struts should go into a true root application context.

For example, if you have a ContextLoaderListener (root context defined in web.xml) and a ContextLoaderPlugIn (defined in struts-config), the latter will automatically be a child of the former. This means that beans in the ContextLoaderPlugIn context can easily reference beans in the ContextLoaderListener context, but not the other way round.

So if you've got the need to access beans that are defined in ContextLoaderPlugIn context directly via a WebApplicationContext reference, I recommend to move those beans over to a ContextLoaderListener context and access them via WebApplicationContextUtils. Just keep Struts-specific beans in the ContextLoaderPlugIn context.

Juergen

P.S.:
If you absolutely need to access the ContextLoaderPlugIn context, you can use the getRequiredWebApplicationContext method in the DelegatingActionUtils class. Note that this method is not really meant to be used directly in application code, though.

[MHarhen]

Well, the ContextLoaderPlugIn context is not meant to be accessed that way.

Thanks for the clarification - I had erroneously assumed that the ContextLoaderPlugIn was intented to be a full alternative.