Comments on: Using a shared parent application context in a multi-war Spring application

By: Joel

Joel — Wed, 03 Mar 2010 18:50:26 +0000

The code also appears to work fine on WebSphere 7.0.

By: Joel

Joel — Wed, 03 Mar 2010 17:50:13 +0000

Concur with above comment. Works fine on JBoss 4.2.3 and fails on JBoss 5.1.

By: Berkay

Berkay — Sun, 07 Feb 2010 14:45:28 +0000

doesnt work in jboss 5.x enviroment..

By: Jürgen

Jürgen — Sun, 13 Dec 2009 22:55:35 +0000

Hi Joris,
I managed to deploy and reproduce your your example in Glassfish 2.1.
Unfortunately, the situation in Glassfish v3 (final) is quite different.
I'm facing different object ids in both web apps.

Are you aware of any difference in both versions, concerning e.g. classloader hierarchy?

Thanks in advance
Jürgen

By: Joris Kuipers

Joris Kuipers — Fri, 13 Nov 2009 12:21:30 +0000

Hi Andrew,

if you'd want to share instances across ears, they would need to be loaded by a classloader that is a parent of all ears: not something you could achieve by deploying a 'master ear', I'd say. This not being possible has nothing to do with Spring, it has to do with the J2EE architecture your server uses.
In fact, OSGi with its services registry sounds like the perfect solution to what you're trying to achieve; doesn't JBoss have something as well with its new microkernel in this space?

By: Andrew

Andrew — Fri, 06 Nov 2009 22:23:24 +0000

Hi Joris, thanks for the great post. I have this example working with a single ear and multiple wars contained in the ear. That works ok for some things, but what we are running into (and have been able to work around in the J2EE realm) is that we have many developers deploying to a single jboss instance. Therefore, we typically like to be able to isolate our applications (war/ears) from each other. So what we would like to do is deploy a single ear that contains a core set of services (DOAs, main services that most things will depend on) and then allow each developer create services that just depend on those and deploy them separately from the main ear. So we would have mainStuff.ear and simpleService.war and simpleService.war would want a reference to the application context exposed by mainStuff.ear (i.e. ear.context in your example). This setup additionally allows us to hot deploy sub-services without having to disturb the main/core set of services. I can't figure out how to make this work. Do you have any hints, or is this simply not possible with Spring? Let me know if that doesn't make sense.

By: Joris Kuipers

Joris Kuipers — Sat, 25 Jul 2009 07:03:34 +0000

"If I package multiple WARS in one EAR will this allow me to share one security context, thus essentially having SSO across all the web applications?"

Unfortunately it's not that simple: by default, the SecurityContextHolder is populated with a SecurityContext that's stored in the HttpSession between requests. Each WAR will still have its own HttpSession, even though it can share a single WebApplicationContext as its parent context, so you'd need either a true SSO mechanism or a different storage location for the SecurityContext than the HttpSession, one that's shared between all WARs in the EAR on a per-user basis. This could be a singleton Map keyed on a shared cookie, for example, but you would also need to write a custom ServletFilter to replace the standard HttpSessionContextIntegrationFilter to actually use that. Haven't tried that myself, but I'm sure it wouldn't be too hard to come up with something that does the job.

By: Dave

Dave — Sat, 25 Jul 2009 00:04:32 +0000

This has very interesting possibilities. I am curious if anyone has tried using this with Spring Security. If I package multiple WARS in one EAR will this allow me to share one security context, thus essentially having SSO across all the web applications?

By: Joris Kuipers

Joris Kuipers — Wed, 06 May 2009 18:31:48 +0000

You should think about what it means to share a domain layer first: typically I'd say it involves sharing *types* (classes, mostly) and not *instances*. You can easily do that, and even share the same Spring XML config files if you like, without needing anything like a shared ApplicationContext.
A shared context is only of interest if you need to share beans (not just bean definitions), so managed *instances*, between multiple ApplicationContexts. Stateful services are the typical example here, that cache data for example. A domain layer is not even known to Spring in most applications, as instances of domain classes are not Spring-managed beans.

There are certainly workarounds you can come up with if you really need to access multiple contexts and not just a single parent: you can use the (ContextSingleton)BeanFactoryLocator yourself to obtain a reference to the context and perform a lookup by name or by type, for example. However, I wouldn't recommend that: again, if you really have requirements to do in-VM SOA I would recommend to use OSGi services instead. That gives you an extremely robust and fully dynamic model that goes way beyond what you can achieve with context hierarchies. By using Spring-DM the programming model remains the same as always, and with dm Server most enterprise libraries and frameworks will work just fine combined with OSGi.

By: Phil

Phil — Wed, 06 May 2009 18:00:49 +0000

Thanks for the feedback.

So having only 1 parent shared context means in order to support 2 domain layers packed separately you would need to do something like the following:

Domain-1 is Parent to Domain-2, and Domain-2 is Parent to WAR-1.

Is there any tricks that can be done in the configuration to allow for also this configuration:
Domain-1 is the Parent to WAR-2 or Domain-2 is the parent to WAR-3, but not both Domain-1 and Domain-2.

I understand your previous point, but it seems like this approach is really application centric. I'd like to know if there is an easier way to create the configurations so the dependencies are not so tightly coupled.

Thanks again Joris.