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
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?
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}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
