cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: [RT] Making components configurable per block in Cocoon 2.2
Date Wed, 19 Sep 2007 08:33:16 GMT
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>> Hi,
>>
>> I would like to address an issue that we are facing today that there
>> is no option to use different
>> default ELs for each block. Our Spring-based configuration of beans is
>> global and in context of
>> default settings it's very inconvenient.
>>   
> Is this really a problem that we need to solve?

I'm not sure what you mean. Could you elaborate?

>> If I'm not wrong, solving this problem in clear manner is in scope of
>> our OSGi effort. Am I right,
>> Daniel?
>>   
> With Spring-OSGi each block (bundle) has its own Spring application
> context, so it would probably enough to have an own implementation of
> the EL Factory in the block. But this depends a lot on how we decide to
> organize wiring between blocks and components, there are some open

Something must ate your words ;-)
What are "open"?

> That is not such a good idea, call scope means that you are going to
> create a new EL Factory for each servlet service call, that is rather
> expensive for a component that is supposed to be more or less a singleton.

I agree in general, but EL Factory turned out to be rather light-weight to create. I wanted
to
exploit call scope to minimize the effort and maximize the gains.

> We should avoid workarounds and plumbing in the core parts of Cocoon.

Ok, it's rather strong point that one hardly can discuss with... :-)

> AFAIU, the above problem can be solved by creating a local EL Factory in
> the component section of the main sitemap of the block that needs a
> different default EL.

That's quite interesting idea but according to my knowledge component section of sitemap accepts
only Avalon-style configuration. Could you give an example how config you are talking about
could be
achieved?

> If that doesn't work, another option would be to create a "local Spring
> context" proxy that can be placed between the sitemap servlet proxy and
> the embeded servlet (e.g. a sitemap servlet). I.e. so that we get an
> interception chain like this:
> 
> [servlet service proxy] -> [local spring context proxy] -> [sitemap
> servlet]
> 
> The local Spring context proxy would take a Spring configuration file
> URL as parameter and set up a Spring application context based on that
> configuration file and with the Spring application context from the
> servlet context attribute of the servlet service proxy as parent
> context. Then it needs to intercept the calls from the sitemap servlet,
> when it tries to get the application context through the servlet context
> attribute, so that it get the local one instead.
> 
> This solution is both generic and orthogonal.

I guess that I understand your idea but there are some remaining open questions:
1. Why can't we just create local Spring context and put it to servlet context thus avoiding
the
need for local spring context proxy? I don't know Spring so much so I don't know if this makes
sense.
2. Where such block-specific config would be stored?

-- 
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message