cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject [RT] Simplifying setup
Date Mon, 01 May 2006 09:05:32 GMT
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).

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).

For the Cocoon main servlet I suggest that we start from the 
SitemapServlet 
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/sitemap/SitemapServlet.java,

and modify it so that it gets the bean container from a servlet context 
attribute instead of being injected. 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.

WDYT?

/Daniel

Mime
View raw message