cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Making components configurable per block in Cocoon 2.2
Date Wed, 19 Sep 2007 16:19:35 GMT
Grzegorz Kossakowski skrev:
> 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?

I just wondered if the inconvinience that you described above is so 
overwhelming so that we have to solve it at any cost. But as we seem to 
be finding a nice enough solution, you can dissregard that question.

>>> 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"?

open questions.

>> 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
> only Avalon-style configuration. Could you give an example how config you are talking
about could be
> achieved?

I don't remember the syntax, but you can configure Spring components in 
sitempas as well. Maybe Carsten can answer.

>> 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
> need for local spring context proxy? I don't know Spring so much so I don't know if this
makes sense.

Yes, that is a better idea. Especially as we allready are setting up a 
local Spring context for the servlet service in the servlet bean,

in the init method. What remains is injecting a configuration location 
in the servlet bean and use that for initializing the local Spring context.

> 2. Where such block-specific config would be stored?

Anywhere in the block except for in WEB-INF/cocoon/spring/. 
WEB-INF/cocoon/spring/local/ would be one suggestion.


View raw message