Leszek Gawron wrote: > I dislike that idea a lot, because: > > 1. it is error prone. Agreed > > 2. It's annoying. In order to load my web application context separately > (because of the filters not finding WebApplicationContext) I had to > split META-INF/spring into META-INF/spring and > META-INF/spring-via-contextloader Hmm, not sure what you're talking about here.
> > 3. It narrows functionality. As my web application context Is the root > it cannot use cocoon's xml parser. True :( > > 4. I simply cannot wrap my head around the fact that my domain services > context is the parent for cocoon's framework. It should be totally opposite. > > > Instead of: > > my web application context > ^ > | > cocoon root bean factory > ^ > | > blocks' contexts > > > it should be: > my context + cocoon bean factory = root web application context > ^ > | > blocks' contexts > > which is way clearer. > Yes, that's true - now there are some problems here (as always). I started to implement a spring 2.0 xml namespace handler which would allow to "plugin" the old avalon configuration into a spring configuration using an own xml element, like <avalon:components src="cocoon.xconf"/> (or something like that). Unfortunately reading the avalon configuration requires access to the servlet context which is not available inside an xml namespace handler of spring, so either we can use some hacky workaround here or find another solution. Apart from that, we now have a nice property mechanism which we have to rewrite if we are going this way as we have to write spring components for the property handling (shouldn't be a big deal though). And finally, we have some optional components like an own logging system or own property providers. Currently these can be defined in the root web application context using default spring mechanisms and then Cocoon makes use of them. If they are not available, Cocoon uses default implementations. We have to find a solution for that as well. So, if we can solve these issues in a clean way, I'm +1 for just using the root web application context of spring. This would also mean that we don't need our own listener anymore. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/