cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: [RT] Simplifying setup
Date Mon, 01 May 2006 11:35:19 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).
> 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.

hehe ;-)

> 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 

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

After stepping through the code together with you I agree with your analysis and 
your suggestions.

Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}



Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden:

View raw message