DelegatingRequestProcessor use the spring context loaded by ContextLoaderListener [SPR-1550]

[spring-projects-issues]

Néstor de Jesus Boscán Bujanda opened SPR-1550 and commented

The org.springframework.web.struts.DelegatingRequestProcessor class loads the spring context based on the /WEB-INF/action-servlet.xml or using the "contextConfigLocation" property. This method is not suitable if you have other web components like Servlets and Filters in your application.

The reason is that the spring context loaded with DelegatingRequestProcessor class is loaded AFTER all Servlet and Filter init method are called.

If the DelegatingRequestProcessor can use the spring context loaded by ContextLoaderListener then you can have ONE spring context suitable for Struts, Servlets and Filters.

---

Affects: 1.2.6

Attachments:

• DelegatingActionUtils.java (4.16 kB)

Referenced from: commits https://github.com/spring-projects/spring-webflow/commit/cb86ac8f551e072287c400608424c8c32dc46f0d

[spring-projects-issues]

Néstor de Jesus Boscán Bujanda commented

A possible solution modifying the DelegatingActionUtils.java class.

[spring-projects-issues]

Néstor de Jesus Boscán Bujanda commented

Sorry, the version I'm using is 1.2

[spring-projects-issues]

Juergen Hoeller commented

This is actually a deliberate design decision: DelegatingRequestProcessor expects Struts Action beans to be defined in the ContextLoaderPlugIn context for the simple reason that those Action beans should reside in a separate context. The ContextLoaderPlugIn context effectively contains the Struts-specific web tier then, with the Spring-managed middle tier residing in a Spring root web application context (loaded by ContextLoaderListener or ContextLoaderServlet). Of course, Struts Action beans defined in the ContextLoaderPlugIn context can refer to named Spring beans in the root web application context.

Other Servlets and Filters should only access the root web application context, which will get loaded in time (by ContextLoaderListener or a ContextLoaderServlet with low load-on-startup value). Any common beans needed by both Struts Actions and other Servlets/Filters should reside in that root context, being accessible to the entire application, while Struts-specific Action definitions remain encapsulated in ContextLoaderPlugIn's bean definition file (receiving references to common beans in the root context through dependency injection).

Juergen

[spring-projects-issues]

Néstor de Jesus Boscán Bujanda commented

Hi

I understand this.

The only problem that I see is that this design forces you to have 2 spring contexts and requires that action classes use dynamic lookup instead of IOC to obtain references to the beans in the Spring root web application context. My design is to mantain only 1 spring context for Struts, Servlets and Filters. This are two design choices. It would be nice if the framework supports both.

[spring-projects-issues]

Juergen Hoeller commented

OK, I have finally removed the restriction to only access a ContextLoaderPlugIn context here. It now falls back to the root WebApplicationContext if no ContextLoaderPlugIn context found.

Juergen

[spring-projects-issues]

Néstor de Jesus Boscán Bujanda commented

Hi

Is there a way to get an early access to this code?. We have 3 projects with the same issue and it would be nice to add this fix to our Spring library.

Néstor