cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <>
Subject Re: more about properties in cocoon 2.2
Date Tue, 22 Aug 2006 09:02:51 GMT
Carsten Ziegeler wrote:
> 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.

I mean if you want to use spring for cocoon components you put your 
files into META-INF/spring/*.xml and after deployment cocoon will nicely 
pick them up.

Still as most of the functionality that you are used to with 
WebApplicationContext does not work you create a separate spring context 
for handling your domain model (e.g. hibernate), application services, 
security (e.g. acegi) etc.

So I have put that context into META-INF/spring-root and loading it with 

>> 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.

Looks like jumping 3 steps at a time for me. This nice change you're 
implementing is just an enhancement for switching to WebApplicationContext.

> 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).
Could you elaborate?

> 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.

For now we can use our own listener as long as it also mimics the job of 
original ContextLoaderListener.

Leszek Gawron, IT Manager                          MobileBox sp. z o.o.
+48 (61) 855 06 67                    
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

View raw message