Ralph Goers skrev:
Thanks for the link Daniel.  I took a look at it and reread your original
email. Parts of it I think are good ideas but I have one major concern. I think it is a bad idea to architect things such that the CocoonServlet
will not run unless some ServletContextListener has previously run.
However, I have no problem at all with allowing for
ServletContextListeners to override or extend default behaviors though.

Carsten has already implemented it so that a Spring container that is made available from a servlet context listener will be used as a parent container.

I've been working a lot with Jetspeed lately. It uses Spring for darn near
everything. However, it doesn't seem to use the approach discussed below. Rather, they just have an assembly directory with a whole bunch of
configuration files.  It seems you can just add your own file to the
directory to add whatever behaviors you want.  I guess I prefer that
behavior over having to modify the web.xml (actually, I hate modifying the
web.xml).

As long as you are happy with the default position of the main configuration the sole change will be:

<listener>

<listener-class>org.apache.cocoon.core.container.spring.ContextLoaderListener</listener-class>
</listener>

in the web.xml. And it will be part of the default web.xml so you will not need to write it yourself.

As for getting rid of the Cocoon object and your other suggestions, I
don't have any real concern there.  Actually, I'd prefer a main servlet
that gets a Spring configuration and then just hands off control to a
component configured there.  But that might make it all even harder to
understand since it would then be very loosely coupled.

We basically have something like that today although it happens in two steps and part of the xml bean configuration is created programmatically.

I think component based design is great in many way, but in Cocoon we have taken it to far. Letting absolutely everything including the main controller being a managed component make the bootstrap really complicated. That is the situation we have today, and I want to simplify it by removing flexibility that no one uses.

/Daniel

Reply via email to