cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Simplifying setup
Date Mon, 01 May 2006 14:20:15 GMT
Daniel Fagerstrom wrote:
> People, I'm fed up with the sickening complicated setup sequence in
> Cocoon. Much of the complication is related to setting up the
> component manager and general over componentization.
> I'd like to remove the component container setup from the concern area
> of Cocoon. The component container should instead be setup by the
> servlet container using a ServletContextListener and made available to
> the Cocoon main servlet through a servlet context attribute (the
> details will be slightly different in the blocks context).

Yup. This is a common practice adopted by Spring and NanoContainer.

> Furthermore the setup contains a number of classes and components with
> fairly overlapping and fuzzy concern areas: The CocoonServlet creates
> a CoreUtil which creates a CocoonBeanFactory which in turn is used to
> get the Cocoon component, which in turn delegates most of it job to
> the SitemapLanguage which also is a component that is managed by the
> CocoonBeanFactory. A fun exercise for the interested is to try to
> figure out how and where the Cocoon component is configured and created.


> Now, I don't see any reason at all for Cocoon and SitemapLanguage to
> be managed components, it just complicates everything. And for the
> Cocoon component there is not much use anymore. Its responsibilities
> are rather vague. I suggest that we just move whatever useful thing it
> might do, to the main servlet and use Servlet instead of Processor as
> top level interface (as discussed before, so many sitemap internal
> details has been added to Processor that it is not useful as an
> abstraction anymore anyway).

Makes sense. The useful abstraction would be pipeline.

> For the Cocoon main servlet I suggest that we start from the
> SitemapServlet
> and modify it so that it gets the bean container from a servlet
> context attribute instead of being injected.

Makes sense also. The servlet specification states that servlet should
have a no-arg constructor and get whatever then need to work in the
init() method. So having servlets expecting dependencies to be injected
by some external stuff makes them something that is no more exactly a
servlet. Note that it can be circumvented somehow by having the init
method grab the component container and do the injection process.

> Also the sitemap path (for non default valiues) could be taken from
> servlet config init parameter instead of the current mechanism.


> The SitemapServlet is rather minimal so some functionality from the
> Cocoon component and the CocoonServlet could be moved to it. But I
> think we should strive to keep it minimal. More advanced functionality
> like multi part mime handling could preferably be moved to servlet
> filters.


> The suggested architecture will make it much easier to maintain and
> understand Cocoon, and will also make it simpler to reuse and to add
> new controllers to (a Flowscript controller or a RoR inspired
> convention controller e.g.). The CLI and Portlet environment will need
> some refactoring if we follow the above path. But the CLI need some
> work anyway and for the Portlet environment I would guess that getting
> closer to the servlet standards just should simplify things.

Sounds good!


Sylvain Wallez -

View raw message