WebApplicationContext initialization with EJB tier

[mperham]

I'm using ContextSingletonBeanFactoryLoader with my EAR to have a logic context at the EAR level. I'd like my WAR context to extend that logic context but I can't see how to configure the war to use beanRefFactory.xml in order to extend an existing context. What am I missing?

[mperham]

This is what I am talking about. How do I do what is mentioned in bold?

Spring docs 3.16:

As an alternative, classes such as ContextSingletonBeanFactoryLocator or SingletonBeanFactoryLocator may be used to demand load multiple hierarchical (i.e. one is a parent of another) BeanFactories or ApplicationContexts in an effectively singleton fashion, which may then be used as the parents of the web-app ApplicationContexts. The result is that bean definitions for lower layers are loaded only as needed, and loaded only once.

[mperham]

Found this through Google but have not tried it yet:

http://article.gmane.org/gmane.comp....work.user/2182

Note the params set in the web.xml. These are not documented AFAIK.

[mperham]

I've found what I consider a problem with ContextSingletonBeanFactoryLocator. The problem is that it is difficult to write POJOs which use that class without them knowing the filename (or "selector" in the source) used to create that context.

For example I have a JMS subscriber which needs to look up the ApplicationContext via getInstance() but I have two sets of beanRefContext files for my unit test and normal environments. That JMS subscriber code needs to know whether it is using the "beanRefContext.xml" instance or "beanRefContext-test.xml" instance. This is bad IMO.

Any ideas on how to deal with this?

[Colin Sampaleanu]

I would actually use the same selector name for the whole app, including in tests. The selector is more for isolating different apps or modules from each other (so the default name doesn't class), than say, differentiating between normal app usage and tests.

What I do for tests is actually just play around with classpaths or the ant scripts so for the test the actual end context definition is different. If I have my dataAccess definitions in a fragment called applicationContext-dataaccess.xml, for example, I can easily set up my build and environment so for tests a different one is accessed than for the real life app.