Please provide a concrete example of what you are proposing before
checking anything in. Then we can discuss this.
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.
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
- Re: [RT] Simplifying setup Ralph Goers
-
