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
