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/
