On June 12, 2007 at 6:49 am, Christian Seiler said:

I'm wondering how session-scoped beans would fit into this scenario. Since the shared context is not a web context, I assume that you can't use session-scoped beans there. Right?

Right; even if you would make the shared context a WebApplicationContext somehow, it still wouldn't make any sense: the Session is scoped to the ServletContext (which corresponds to a war file), so I'd say that session scope is meaningless outside the web application context of the war itself.
That doesn't prevent you to place shared session-scoped bean definitions inside a single configuration file, of course: it only means that this file should be used to construct the WebApplicationContexts of each war by adding it to the list of files in the contextConfigLocation parameter in each war's web.xml. Still DRY, but these beans will not become part of the shared parent context.

When the classloader implementation was flaky, you ended up with singletons-that-are-not-really-singletons.

Absolutely, but with flaky classloaders that would also be the case if you implemented your own singleton, right?
In the setup that I described (multiple wars and a jar in the root of the ear, referenced from the Class-Path entry in the MANIFEST.MF as opposed to placed in WEB-INF/lib), most if not all containers will by default create a ClassLoader per war and a parent ClassLoader for the jar(s). This ensures that the wars can't see each other's classes and that the jar can't see the wars. Thus, the singleton beans will be loaded by that parent CL. I've never experienced problems with this setup myself, but I can imagine other scenario's, like using the (Context)SingletonBeanFactoryLocator programatically without having a parent CL in place, that can lead to the problems you descibe (there's actually a warning in the JavaDoc of the BeanFactoryLocator about this sort of usage).
So I agree that a SingletonBeanFactoryLocator should only be used (a) if really needed and (b) if you understand how it interacts with your server environment. Then again, I feel the same about most technologies

On July 5, 2007 at 6:51 am, Rapthor said:

I think I misunderstood something about your approach. What I did was putting my shared classes into a seperate jar file and provide it via Tomcat's shared lib folder. Then I assumed another webapp should have access to the jar and load its context as parent. While the parent context was initialized, I got the ClassNotFoundExceptions as described above.

Is there no way to do it the way I described here? I do not want to use an application server hence I do want to avoid EAR-files.

You have indeed misunderstood my original description, since it only descibes a solution for ear-files with multiple war-files inside.
However, what you want is certainly possible: I've just tried it out, and it works perfectly. Just make sure that not only the shared parent jar is placed inside the shared/lib directory, but also the the spring jar that holds the ContextSingletonBeanFactoryLocator class (and other jars that your application might need). This way, there can be an actual singleton in the shared classloader visible to both web applications that each have their own classloader.

This should work using my original example:
- download the multiple-contexts-sample.zip linked to from the blog entry
- put all jars from that zip in Tomcat's shared/lib folder
- (re)start Tomcar
- deploy the 2 war-files from that zip under /web1 and /web2
- go to http://localhost:8080/web1 and …/web2 and ensure that the same instance of the shared service is now used (refresh a couple of times to see the shared counter being incremented)

I guess this also answers Jörg's question. BTW, don't use the common dir, use the shared dir: the common is for libraries that should also be seen by Tomcat itself, these jars are loaded by a parent classloader of the shared classloader. The classes in the shared classloader are only visible to deployed applications, which is exactly what we want in this case.

On October 22, 2007 at 10:42 am, JoeC said:

One problem we are having is that we dynamically load our application context, selecting the configuration files in Java. This also works well, but we how can we connect the two approaches? We created a custom listener and loader for a web application that creates and loads the context. As a result, it is not defined as a Spring bean in a configuration file. We would now like our dynamically created context to become the parent context for other web modules. Is there some way that we can "name" this context so that we can reference it in the web.xml of other web modules?

Since you've already created your own ContextLoader and have overridden the loadParentContext method, why would you still want to name that root context? That name is normally only used by the default loadParentContext method, since it delegates to a ContextSingletonBeanFactoryLocator and looks up the context named by the parentContextKey parameter. You're not using that in your ContextLoader implementation…

In your case, I'd say that all you need is to instruct the ContextLoaderListener to use your JeeContextLoader instead of the default ContextLoader. To do that, all you need to do is to subclass ContextLoaderListener, override createContextLoader to create a JeeContextLoader and register that subclass as a listener in your web.xml. You mentioned that you have also created a custom listener already, so I'm not sure if I fully understand your problem: if your code always returns the same ApplicationContext when the same ModuleReferences value is passed to it, then it looks like you have already created a working solution… The code that does this isn't too clear, however.

… That partner override code will be in a separate WAR so that it can be tested and deployed separately. By using your solution I can have the child context replace the bean definitions for the parent context thereby injecting the partner code instead of the baseline code with no effect on the baseline. Is this correct? Is this the most effective way to gain this flexibility?

Do you mean that the partners will use both the base WAR and a seperate WAR, or that the seperate WAR will contain the base plus overriding/extension code? In the last case, you don\'t need multiple contexts: you can simply override base bean definitions by adding extra configuration files to the list of files that make up the application context. Wildcarding would work here probably, maybe something like this as the context-param value in your web.xml:

I didn\'t try this, but it seems like this would enable you to simply put the extra code under /WEB-INF/lib or /WEB-INF/classes in the base WAR and create one or more extra configuration files called something-override.xml that you also place on the classpath, which can then override existing base bean definitions.

If you meant using multiple WAR files then I\'m not really getting your deployment scheme here: how would deploying an extra WAR file change the behavior of an already deployed base WAR file? My sample only talks about a shared parent context for multiple WAR files in a single EAR file: the base WAR file presumably doesn\'t use a parent context for the context created by the ContextLoaderListener.

On November 6, 2007 at 12:02 pm, Arnon Davidovici said:

… So are you saying that if the override defines a bean later in the initialization than the baseline it will replace the bean that was originally defined with that id?

Yes, Spring has no problem with multiple bean definitions with the same id, as long as they're not in the same file. This definitely seems like the easiest thing to do, and is supported just for this use case. The latest bean definition that's loaded simply 'wins' and masks other definitions with the same id.

On December 2, 2007 at 12:34 pm, Aidan Whiteley said:

…
Does the above sound right? If so, do you know if there is an easy way round this i.e. so I can continue to run with prefer-web-inf-classes but am still able to pull in a single instance of an ApplicationContext created in a higher classloader as a parent into different web app's ApplicationContexts.

Thanks in advance if you have any pointers. I realise what I'm trying to do might sound strange i.e. turn on prefer-web-inf-classes to increase segregation between web apps while then wanting to also also put something on the server classpath but I would claim to have a valid use case for this!

I'd say that you only have to move the spring.jar out of WEB-INF/lib: if you want to share the ApplicationContext through a singleton, then that's required. The rest of your code can probably stay in WEB-INF/lib. The reason that I say 'probably' is that code that's in a higher classloader that needs to access classes loaded by the web classloader will need to properly use the context classloader in that case.

Maybe you should go for another solution instead, for instance registering your shared ApplicationContext in the JNDI registry and perform a lookup from the WAR. You'd need to ensure that the shared context would have been created and registered before the lookup occurs, of course.

On January 5, 2008 at 8:48 am, EDH said:

when I deploy/(re)start my EAR when there are messages on the queue. In this situation I'm running into the problem that the container preloads the MDB and calls the setMessageDrivenContext method in which the above method calls occur. Of course, at that point in time my web module is not started yet and therefore the shared application context is not loaded/initialized yet.
As a result I get a spring exception and my application doesn't start.

I don't think the shared context can only be created by the ContextLoader from the web module; that class has a method called loadParentContext which calls BeanFactoryLocator.useBeanFactory(parentContextKey) which triggers the creation of the shared parent context, but the AbstractEnterpriseBean.loadBeanFactory method does exactly the same thing. That method gets called from AbstractMessageDrivenBean.ejbCreate(): that should happen after the setMessageDrivenContext method gets called by the container, so the loadBeanFactory should recreate your parent context using your ContextSingletonBeanFactoryLocator and beanFactoryLocatorKey, right? So, just by looking at the code, one would expect the shared parent context to be loaded and initialized just fine, regardless of the module that starts first.

Can you provide the exception that you receive? This might have something to do with the shared context not being properly destroyed on restart, so it doesn't get recreated when useBeanFactory gets called. It might also help to put in some trace logging in the methods involved to see what happens exactly after a restart. Also enable trace logging for the org.springframework.beans.factory loggers to see what Spring is doing!

HTH,

Joris

On January 6, 2008 at 8:27 am, EDH said:

…a first problem I'll have to solve is to find out why the spring.schemas (file) is not found when the MDB gets created(preloaded) while in the normal scenario, when the web module is first loaded the schemas are found without any problem ? Do you have some advise on this perhaps ?

Not sure: could be classloader-related, maybe? Where is your spring.jar and how do you make it available to the ejb jar? If the spring.jar is in the ear, is it also refered to in the MANIFEST.MF Class-Path entry of the ejb jar?

On January 6, 2008 at 8:27 am, EDH said:

…what I understand from your comment is that when the MDB is created/preloaded (before the web module has started and thus before the web module's contextloader kicks in) the setBeanFactoryLocator(ContextSingletonBeanFactoryLocator.getInstance("classpath*:**/beanRefContext.xml")) call will also lead to the creation/initialization of the shared context. Is that correct ?

Almost: not the setBeanFactoryLocator call leads to creation, but the call to loadBeanFactory from the ejbCreate.

On January 6, 2008 at 8:27 am, EDH said:

If so, then what happens at the time the web module gets loaded and it's contextloader kicks in ? Will it "detect" that the shared context is already there, or will it try to re-initialize it again ?

It should detect it, since the context is already registered in a Map that's kept as a singleton (so your web module and your ejb module should use a spring.jar loaded by the same single classloader).

Joris