Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
...
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.

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.
Yes, in the current block fw I use dependency injection into servlets for components while connections to other servlets (blocks) are available through request dispatchers and (block) properties go to servlet init parameters. After having thought a little bit more about it I have realized that it is better to make the components and/or the service manager that a block depends on available to it as servlet context attributes. This makes the blocks fw usable for more existing servlets and it make the life cycle for the servlets less complicated.

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

WDYM?
What I mean is that the tree processor currently get the path to the sitemap.xmap from the configuration file. If the tree processor stop being a managed component and just is setup in the SitemapServlet, it will still need to get the sitemap path from somewhere. IMO a servlet config init parameter would be a reasonable place to set the sitemap path.

/Daniel