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
