Ovidiu Predescu wrote:
> I am sure people on this list would like to hear more of your tales,
> hopefully not as horrid as your last experience. Please let us know what's
> your experience.
Ok, the tale continues. First, some non-Cocoon issues
lead me through some recursive problems including
reinstalling CygWin from scratch. Finally, I compiled the
2.1 Head (2002-06-18), deployed it, cleaned the workdir
and everything else I could think of and started Tomcat.
Trying to get the webapp's home page resulted in a very
accurate error message about a problem getting the serializer
selector. The logs fortunately had the real cause: a missing
Batik class (I had 1.5b1 instead of 1.5b2). Killed the SVG
serializer from the sitemap. The next try wasn't any better,
killed the svg2jpg and svg2png serializers.
The next reload resulted in a real gem: Cocoon confusion,
unknown reason. Log snippet:
ERROR (2002-06-14) 14:31.41:403 [core.manager] (/bredevc/index.html)
HttpProcessor[8080][1]/LogKitLogger: UnnamedSelector:
ComponentSelector Attempted to retrieve component with null hint.
The messages was triggered by the treemap processor, indicating the
main <pipeline> element as the source. Also there was
WARN (2002-06-14) 14:31.41:460 [sitemap] (/bredevc/index.html)
HttpProcessor[8080][1]/LogKitLogger: ComponentManager exception from
parent CM during lookup.
org.apache.avalon.framework.component.ComponentException:
Could not find component
This looked suspiciously like the points I stepped through
while tracking down the problems with the read-only DOM earlier.
However, getting the patched BrowserImpl.xsl was without effect,
as was ditching Saxon and reinstalling Xerces+Xalan again, symptoms
and logs stayed the same. I've probably got something wrong
in the sitemap, unfortunately, logs and error messages are utterly
useless to track the problem down.
Apart from this, DOM writing functions are spread all over the place
in C2.1, in contrast to 2.0.2 where it was only used in a few and
generally non-vital functionality (BrowserImpl, Deli, getting a new
DOM document in JaxpParser). Conclusion: give up.
Next try was to get 2.0.3 and install it, this time using Xerces+Xalan
right from the start.
This resulted in:
java.lang.NullPointerException
at org.apache.cocoon.components.xslt.XSLTProcessorImpl
.resolve(XSLTProcessorImpl.java:489)
at org.apache.xpath.SourceTreeManager.resolveURI
(SourceTreeManager.java:184)
This was triggered by a document('cocoon://int/release-list') in
the XSLT.
What's really bad is that the exception appears to be rethrown right
up to the tomcat level, which causes a partially generated HTML
delivered to the browser and, worse, cached. No 500.
The exception is caused because "includes" in the XSLTTransformerImpl
is null. Apparently, this was implemented with the premise that
only XSL includes will go through the method. Unfortunately, URLs
for document() also go through this. Of course, the information
should be used for caching the pipeline output.
I quickly hacked a if(includes!=null) {} around the problem (should
rather have setup something for cache validation for the pipeline...if
I could only understand this!). Now, it runs...slowly, because of
Xalan bug #2425.
I ditched Xalan and use Saxon again, with Xerces. This is the current
situation.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
