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

Regarding the issue of 'being tied to Spring'.

Well your tied to Struts? So, if your going to use something make the most of it.

To some extent there are good reasons not to make some dependencies but where does it stop?

Here is an example I just wrote.

My main Server shuts down its embedded servers by directly invoking shutdown on them. I thought this was not good, the embedded servers are configured in the app context, so why not just use the shutdown lifecycle stuff managed by the context. So, I just added an attribute to the servers, "destroy-method", and now the main server does a single ctx.close().

Is this incorrectly being tied down to Spring? I'm using a Spring context and it does a bunch of stuff, why not just use it.

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.