Carsten Ziegeler wrote:
Leszek Gawron wrote:
I dislike that idea a lot, because:
1. it is error prone.
Agreed
2. It's annoying. In order to load my web application context separately
(because of the filters not finding WebApplicationContext) I had to
split META-INF/spring into META-INF/spring and
META-INF/spring-via-contextloader
Hmm, not sure what you're talking about here.
I mean if you want to use spring for cocoon components you put your
files into META-INF/spring/*.xml and after deployment cocoon will nicely
pick them up.
Still as most of the functionality that you are used to with
WebApplicationContext does not work you create a separate spring context
for handling your domain model (e.g. hibernate), application services,
security (e.g. acegi) etc.
So I have put that context into META-INF/spring-root and loading it with
ContextLoaderListener
3. It narrows functionality. As my web application context Is the root
it cannot use cocoon's xml parser.
True :(
4. I simply cannot wrap my head around the fact that my domain services
context is the parent for cocoon's framework. It should be totally opposite.
Instead of:
my web application context
^
|
cocoon root bean factory
^
|
blocks' contexts
it should be:
my context + cocoon bean factory = root web application context
^
|
blocks' contexts
which is way clearer.
Yes, that's true - now there are some problems here (as always). I
started to implement a spring 2.0 xml namespace handler which would
allow to "plugin" the old avalon configuration into a spring
configuration using an own xml element, like <avalon:components
src="cocoon.xconf"/> (or something like that).
Unfortunately reading the avalon configuration requires access to the
servlet context which is not available inside an xml namespace handler
of spring, so either we can use some hacky workaround here or find
another solution.
Looks like jumping 3 steps at a time for me. This nice change you're
implementing is just an enhancement for switching to WebApplicationContext.
Apart from that, we now have a nice property mechanism which we have to
rewrite if we are going this way as we have to write spring components
for the property handling (shouldn't be a big deal though).
Could you elaborate?
And finally, we have some optional components like an own logging system
or own property providers. Currently these can be defined in the root
web application context using default spring mechanisms and then Cocoon
makes use of them. If they are not available, Cocoon uses default
implementations. We have to find a solution for that as well.
So, if we can solve these issues in a clean way, I'm +1 for just using
the root web application context of spring. This would also mean that we
don't need our own listener anymore.
For now we can use our own listener as long as it also mimics the job of
original ContextLoaderListener.
--
Leszek Gawron, IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
