[RT] Making components configurable per block in Cocoon 2.2

[Grzegorz Kossakowski <gr...@tuffmail.com>]

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.

If I'm not wrong, solving this problem in clear manner is in scope of our OSGi effort. Am I right,
Daniel?

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

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

Re: [RT] Making components configurable per block in Cocoon 2.2

[Daniel Fagerstrom <da...@nada.kth.se>]

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 accepts
> 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 the
> 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 
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-servlet-service/cocoon-servlet-service-impl/src/main/java/org/apache/cocoon/servletservice/spring/ServletFactoryBean.java, 
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.

/Daniel

Re: [RT] Making components configurable per block in Cocoon 2.2

[Grzegorz Kossakowski <gk...@apache.org>]

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/

Re: [RT] Making components configurable per block in Cocoon 2.2

[Daniel Fagerstrom <da...@nada.kth.se>]

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