ContextLoader should implement default loadParentContext [SPR-358]

[spring-projects-issues]

Victor opened SPR-358 and commented

Right now the loadParentContext() in ContextLoader simply returns null. Therefore we have to create a new loader to load the parent context - why not implement it to read a servlet context-param from web.xml and returns null if no such param exists. I think it's much better than doing nothing, more important - makes it easier for people to start with (it took me a long time to figure this out).

thanks.

---

Affects: 1.1.1

[spring-projects-issues]

Juergen Hoeller commented

Well, what kind of context-param would you evaluate here, and what would you do with it? Do you have a specific use case in mind?

Note that ContextLoaderListener can load the root web application context from any number of config files, so this is no reason to introduce a parent for the root context here.

Effectively, the only reason why loadParentContext exists at all is to allow root web application contexts to be children of a shared EAR context that's also visible to EJBs (Colin needed this once). For pure web applications, I don't see a need for this in the first place.

Juergen

[spring-projects-issues]

Victor commented

Exactly as you described - it's EJB concern - we need to make some cron jobs to access ejbs upon invoking. We ended up using an auto-load servlet to load the spring context at start of the app, which in turn uses Quartz to do the cron tricks.

Right now I extended both contextloader and contextloaderservlet to load 2 parameters (parentContextConfigLocation and parentBeanFactoryId) defined in web.xml, but obviously we can integrate this feature into the ContextLoader the same way as the existing contextConfigLocation param, right?

thanks.

[spring-projects-issues]

Juergen Hoeller commented

Colin, could you please have a look at this? If it turns out to be rather trivial to solve in a generic fashion, we could maybe get this in within the 1.1.2 timeframe (early November).

Juergen

[spring-projects-issues]

Colin Sampaleanu commented

Well, it's trivial to implement something that is identical to this ContextLoader sublass which already exists in the ejbtest integration test sample, since we could just use that code directly:

http://cvs.sourceforge.net/viewcvs.py/springframework/spring/autobuilds/apps/ejbtest/src/java/org/springframework/autobuilds/ejbtest/util/context/ContextLoader.java?view=markup

(For anybody wanting to actually use the existing subclass they would BTW just use this ContextLoaderListener variant):: http://cvs.sourceforge.net/viewcvs.py/springframework/spring/autobuilds/apps/ejbtest/src/java/org/springframework/autobuilds/ejbtest/util/context/ContextLoaderListener.java?view=markup

Now the question for me this is whether this is appropriate default behaviour for the handling of the parent context in the default ContextLoader class? It's a bit of a tough call. Realistically if you have mutliple web-apps, and one needs a parent context, then probably they all need the same parent context. In my case, these were all in an ear file (3 web-apps), and of course the same parent context was also needed by the EJBs. But do we see people having other strategies?

Another option would be to bring in and keep these custom subclasses as separate classes.

[spring-projects-issues]

Victor commented

Thanks Colin for pointing out the current implementation.

I would argue that the behavior (which parent to load) can easily be defined in web.xml - the default rule can be that if nothing shows up in web.xml, then don't load parent context at all. And since web.xml is per web container, user can always define different parents for different war. Right?

As for the listener, since we're still bound to servelet 2.2, I can't leverage it yet. That's probably another reason/benefit to incoporate this feature in spring instead of leaving it open.

[spring-projects-issues]

Colin Sampaleanu commented

It's not a question of which parent to load, but really a question of whether it's appropriate for the default behaviour to use ContextSingletonBeanFactoryLocator for the parent. Of course you can still have multple parent contexts, by using a different selector (i.e. don't use the normal "classpath*:beanRefContext.xml" selector, or specify a different beanfactory/context within the group of contexts loaded by that selector (if there are more than one), but the point is that you're still going to share that parent context with any other web-app in the same classloader setup that uses the same settings. I'm not really arguing that it's not, after all, the normal web-app context itself is a singleton as far as the web-app is concerned...

[spring-projects-issues]

Victor commented

I agree. It's just a matter of which one gets demanded more often, since we always have the option to extend and override the default behavior if we want. My suggestion was to make it easier for newbies like me, I never intended to kill advanced choices. (Good example is I just found in my subclass I forgot to override the closeContext)

The ideal framework will should be easy to learn and provide maximum flexibility once you reached advanced level - which is exact the reason I love Spring. Sorry for being picky on this. ;)

[spring-projects-issues]

Juergen Hoeller commented

Colin, can we provide something here for 1.1.3? Maybe an option that's driven by a further context-param in web.xml, just kicking in when told to do so?

Juergen

[spring-projects-issues]

Colin Sampaleanu commented

The code above will only actually do anything special if in fact a parent context is specified via a web.xml param. So it would take about 2 minutes of work to just move to that code, for the 1.1.3 timeframe...

I'm ambivalent about the use of encouraging the use of singletons (here, that is; for general use cases I'm generally against it :-) ), but realistically, if people want a parent here, it's probably to share it with other web-apps, although I suppose a case could be made for loading a non-shared hierarchy as well...

[spring-projects-issues]

Colin Sampaleanu commented

implemented using ContextSingletonBeanFactoryLocator-based code which was previously used in integration and ejbtext integration samples.