Preserving context information outside the container
Hi everyone,
I am currently using Spring and Struts together. As you know the ApplicationContextAware interface has the method setApplicationContext() which the app context calls, allows the use of app contexts (resources, events etc) - but it ties you to spring. I have read numerous articles, mission statements, and books that clearly state that you shouldn't tightly couple yourself to spring (for obvious reasons). Namely, having your objects implement ApplicationContextAware would do just that. However, these articles don't go on to demonstrate how to prevent tight coupling to the framework AND still preserve context information across various tiers (outside the container). I am utilizing Spring's IOC services by using a ContextLoaderListener and making calls in my struts action code within the container. All of this works fine. However, when I have to leave the container and make a call to my business tier, I need to preserve the context. The problem that I am finding, is that there is little documentation demonstrating how to ensure contextual information is preserved from the webtier (within the container) to the app tier (outside of the container) with out having to either:
1.)decorate the interfaces with a helper object that would otherwise wrap information normally kept in the context
2.)have every object implement applicationContextAware interface - which would tightly couple me to Spring.
3.)have a common service object (that all spring-i-fied objects would extend) - another form of tight coupling.
4.)code directly against the XMLBeanFactory (programatic approach to integrating with spring)
Your help is appreciated.
-Justin
Re: Preserving context information outside the container
Quote:
Originally Posted by jmoore
Hi everyone,
I am currently using Spring and Struts together. As you know the ApplicationContextAware interface has the method setApplicationContext() which the app context calls, allows the use of app contexts (resources, events etc) - but it ties you to spring. I have read numerous articles, mission statements, and books that clearly state that you shouldn't tightly couple yourself to spring (for obvious reasons). Namely, having your objects implement ApplicationContextAware would do just that. However, these articles don't go on to demonstrate how to prevent tight coupling to the framework AND still preserve context information across various tiers (outside the container). I am utilizing Spring's IOC services by using a ContextLoaderListener and making calls in my struts action code within the container. All of this works fine. However, when I have to leave the container and make a call to my business tier, I need to preserve the context. The problem that I am finding, is that there is little documentation demonstrating how to ensure contextual information is preserved from the webtier (within the container) to the app tier (outside of the container) with out having to either:
1.)decorate the interfaces with a helper object that would otherwise wrap information normally kept in the context
2.)have every object implement applicationContextAware interface - which would tightly couple me to Spring.
3.)have a common service object (that all spring-i-fied objects would extend) - another form of tight coupling.
4.)code directly against the XMLBeanFactory (programatic approach to integrating with spring)
I'm missing out on what you think the problem is. Ideally with Struts you use the ContextLoaderPlugin, so that the Struts actions themselves are managed beans in the context, and all their dependencies, which will mostly be services they talk to, are injected into them. The actions don't know about Spring, and just talk to the services, and the services themselves have their dependencies injected, and so on.
The main disadvantage of the ContextLoderPlugin approach is that the action paths are defined in both the struts-config file and the context. If this is bothersome, then you would use ActionSupport instead, where your Action hierarchy extends ActionSupport, and some level in the hierarchy does directly get service object from the context, but ideally you localize this to just a few base classes in the init method, so that all the main Actions are again dealing with services which they don't care how they were initialized (they're just fields set by the base class). Again, the services themselves have all their dependencies injected into them, since they are managed beans.