Alexander Klimetschek skrev:
Hi Daniel,
a problem during development when using the blocks-protocol is that you
don't see a stacktrace when some problem occurs inside the block called
via the BlockSource. You get an empty XML/HTML stream sent to the browser.
As far as I can see, the nice exception/stacktrace page displayed by
Cocoon ("Problem in creating the Request") is generated in Cocoon's
MultiPartFilter that is by default configured in the web.xml. This
filter is not running when a BlockServlet is called via a BlockSource
connection. Would it be somehow possible to add such a filter there? Or
at least to include the manageException() code of the MultiPartFilter in
the BlockSource/Connection?
I had a look at it but couldn't figure out, where the exception thrown
by the contained SitemapServlet could be catched in the blocks-fw code.
I don't know the details of the error handling, but I don't think that
the MultipartFilter is needed for getting a nice exception page in
Cocoon. The error handling code in the MultipartFilter is copied from
the RequestProcessor that in part is called from the
o.a.c.servlet.SitemapServlet, which is the "standard" sitemap processor
for Cocoon.
In the blocks fw the o.a.c.sitemap.SitemapServlet is used instead and
has much less functionality (e.g. no nice exception handling) than the
o.a.c.servlet.SitemapServlet.
The reason that there is two SitemapServlets in different packages is
that the TreeProcessor is set up in different ways in the standard case
and in the blocks fw case. In the standard case the TreeProcessor is a
singleton and is configured in cocoon-core-sitemap.xconf. In the blocks
fw case there need to be one TreeProcessor per block. In this case the
TreeProcessor is not a managed component but is just created within the
SitemapServlet. Configuration can optionally be done with servlet init
parameters instead, that in turn can be set from the Spring
configuration for a BlockServlet (haven't tested that code though).
What is needed is to modify the standard SitemapServlet so that it works
in the blocks context as well and remove the
o.a.c.sitemap.SitemapServlet. The question is how to do this, I
discussed it a little bit with Carsten at the CocoonGT but we didn't
come to any conclusion.
IMO the TreeProcessor shouldn't be a managed component at all, it should
be enough to create it within a SitemapServlet and optionally configure
it with init parameters. The init params (sitemap-path and set-reload)
can be configured in the web.xml for the "standard" case and in the
BlockServlet configuration for the blocks fw case. I would assume that
the vast majority uses the standard sitemap path and settings anyway so
that it shouldn't matter.
WDOT?
/Daniel
