cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Making components configurable per block in Cocoon 2.2
Date Tue, 18 Sep 2007 15:54:48 GMT
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?

> 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

> Nevertheless, OSGi integration won't make it into Cocoon 2.2 so we have to find another
way even if
> it's rather hacky. I believe I found such "hack" that I'll explain taking ELs as example.
My plan is
> quite simple:
> 1. Component that has to be configured per block is declared in "call" scope
>   
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.

> 2. Configuration values for component that are different for each block are declared
as
> context-params like this:
> <bean id="org.apache.cocoon.servletservice.sample.servlet1"
> class="org.apache.cocoon.sitemap.SitemapServlet">
>     	<servlet:context mount-path="/foo" context-path="blockcontext:/foo">
>     		<servlet:context-params>
> 			<entry key="org.apache.cocoon.el.ExpressionFactory$defualtExpressionCompiler"
> value-ref="org.apache.cocoon.el.ExpressionCompiler/jxpath"/>
> 		</servlet:context-params>
> 		</servlet:context>
> 	</bean>
> 3. Implement BeanPostProcessor that will inject property value for ExpressionFactory
whenever it is
> created
>   
> What I would like to stress is the fact that I'm *not* willing to implement this as general
> mechanism but only limit myself to this one use case. If there is another strong need
for per-block
> configuration we could think about implementing another BeanPostProcessor but I really
think we
> should not invest too much time/discussion into this as we are going to have better solutions
in
> (hopefully) near future.
>
> WDYT?
>   
We should avoid workarounds and plumbing in the core parts of Cocoon.

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.

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.

/Daniel


Mime
View raw message