cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: more about properties in cocoon 2.2
Date Tue, 22 Aug 2006 06:21:00 GMT
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/

Mime
View raw message