[quote comment="26827"]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?[/quote]
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.

[quote comment=\"26846\"]When the classloader implementation was flaky, you ended up with singletons-that-are-not-really-singletons.[/quote]
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

[quote comment="32368"]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.[/quote]
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.

[quote comment="56980"]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? [/quote]

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.

[quote comment=\\\"59619\\\"]… 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?[/quote]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.

[quote comment="60928"]… 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?[/quote]
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.

[quote comment="75127"]…
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![/quote]

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.

[quote comment="85032"]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.[/quote]

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

[quote comment="85381"]…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 ?[/quote]
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?
[quote comment="85381"]…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 ?
[/quote]
Almost: not the setBeanFactoryLocator call leads to creation, but the call to loadBeanFactory from the ejbCreate.
[quote comment="85381"]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 ?
[/quote]
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

(This is a reply to a comment from Bruno Sant'Anna that now seems have disappeared:)
Does my example work for you? The errors you're showing are not coming from my sample, as that doesn't have a my.service.AccountService not an accountService property.
It looks like a classloading issue to me: the proxy should be an instance of my.service.AccountService, but that interface (or is it a concrete class? that would explain the use of a CGLIB proxy) might be defined in multiple classloaders, thus causing the exception. It's hard to tell without further details, but you probably need to package your jars in another way to ensure the AccountService type is defined in a single classloader.

If you just want to share an ApplicationContext between your EJBs and your web app, you don't have to use JNDI to store your ApplicationContext. I guess you are referring to the ContextJndiBeanFactoryLocator? That only retrieves its config file locations from JNDI to create an ApplicationContext, it doesn't retrieve the ApplicationContext itself. I find that one quite cumbersome to use.
What I do in those cases is to use the Spring support classes for EJB, but override the setSessionContext method to call setBeanFactoryLocator with a ContextSingletonBeanFactoryLocator. This is also suggested in the JavaDocs of AbstractEnterpriseBean. This ends up working very similar to what I've described in my blog.

Hi Joern,

with Spring-DM this model simply doesn't make a lot of sense:
first of all, you don't want the bundle that defines the child context to trigger the creation of the parent context, as each bundle has its own ApplicationContext. This context is created when the bundle is started by the Spring-DM extender bundle.
Second of all, Spring-DM allows for a much more refined model than hierarchical contexts through its integration with the OSGi service registry. You're no longer confined to a tree of contexts, but each bundle can expose the beans it wants to share as an OSGi service which gives you much more flexibility.

To adapt your application to this model does not require a lot of work and hardly any changes. For your 'parent' bundle, just define an extra Spring config file that uses Spring-DM's osgi: namespace to export the beans that should be accessible by the 'child' bundle(s) as OSGi services with <osgi:service>. For your child bundle(s), create a similar file that contains <osgi:reference> elements to create proxies that will access these services. If these references use the same ids as the exported bean definitions, you don't have to touch your existing config files: just make sure that the new files are loaded as part of the created ApplicationContext. Of course you would remove the context parameter from your web.xml that triggers the parent context loading and setting. With such a shared services war, you do need to define a custom subclass of the XmlWebApplicationContext that is OSGi-aware. Which class depends on if you just use Spring-DM or the dm Server: consult the documentation for the respective projects for details.

I must admit that I'm not very familiar with Spring-DM's web extender, as I always use the SpringSource dm Server for OSGi-based web applications. I'm sure this approach would work with both environments, though.

For plain Spring-DM, check here:
http://static.springframework.org/osgi/docs/1.1.3/reference/html/web.html#web:spring-mvc

For dm Server, check here:
http://static.springsource.com/projects/dm-server/1.0.x/programmer-guide/html/ch05s02.html#developing-applications-packaging-war

Not sure what you mean with using "getBean() method to dynamically create beans". getBean() uses existing bean definitions: are you referring to protype-scoped beans, maybe? That should simply work.

You are asking the right person, but for further questions you might want to use the forums instead

Ah, I see: that section says that the ApplicationContext from a bundle is also exposed as a service itself. Other bundles should typically only interact with it by using services that are backed by Spring beans from that context, not by calling the other bundle's ApplicationContext itself using calls like getBean. In general, we discourage API calls to the ApplicationContext or BeanFactory as it ties your code to Spring.
Do you have a particular use case for which you need the actual ApplicationContext of another bundle and getBean() instead of just accessing its beans as OSGi service references?

Hi Shameer,

I haven't actually tried what happens, but looking at the code for the ContextLoader (which is responsible for creating the sub-contexts for the war files) I see only one call to refresh(), after the ApplicationContext has been created and its parent has been set. I'm therefore assuming that you're talking about the shared parent context that gets refreshed multiple times? Looking at the code in the ContextSingletonBeanFactoryLocator this might be caused by the fact that its initializeDefinition() method is called multiple times. Can you confirm that? In that case it's either a classloader issue (BeanFactoryGroup not found when it should be) or a bug, in which case I would advise you to open a JIRA issue against Spring.