cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <>
Subject C2 with saxon
Date Tue, 11 Jun 2002 20:53:35 GMT
I set out for the quest of installing Tomcat+Cocoon with Saxon
instead of the usual Xerces+Xalan combo. Yes, even without Xerces.

Major points:
- AElfred, the XML parser delivered with Saxon is a SAX2 only
- The DOM coming with Saxon is read-only.

0. Ant: Ant at least up to 1.4.1 uses the SAX1 interface. Hacked
   Ant to use SAX2.

1. Tomcat problems. Provided for
   - Build Tomcat from Source. Not for the faint of heart.
   - Starting Tomcat bombs in an attempt to read server.xml because
     AElfred's namespace support cannot be switched off. Deleted
     two setNamespaceAware("false") statements. A hack, but not so
     bad if seen in conjunction with the next point.
   - Starting Tomcat bombs because of SAX1 interface. Upgraded
     Catalina to SAX2 (For some odd reason, migrating to SAX2 seems
     to be a somewhat unpopular topic within parts of the Apache community)
   - Starting Tomcat still bombs with an NPE in the entity resolver
     because AElfred calls it for every input stream in order to
     allow mappings, even if the public id is not set. Reported
     as a bug and fixed by bypassing the mapping unless a public
     id is set.
   - Tomcat starts but bombs yet again while reading web.xml
     because validation is requested, and AElfred does not validate.
     Caught the ParserConfigurationException and turned off validation
     locally. Ugly workaround, but so what.
   Finally, Tomcat works.

2. Cocoon.
   - First access bombs because the default hardcoded
    DocumentBuilderFactory is not available (a crimson class). This is,
    for variety, a Saxon bug. Added
    to CATALINA_OPTS to tell the JAXP implementation of Saxons DOM
   - Next access still bombs because the sitemap cannot be compiled
     The parameter 'compiler' does not contain a value
     <parameter name="compiler"
    to <java-language> in cocoon.xconf.
   - Next access still bombs because there is still a setting defaulting
    javax.xml.parsers.SAXParserFactory to the Xerces factory. Fixed by
    I have no idea where the Xerces setting came from.
   - Next access bombs yet again because org.xml.sax.driver points to
    a Xerces class. Fixed by adding
    Again, I have no idea where this setting came from.
   - Finally, the sitemap compiles but results in a 404 "ressource not
    found" because of:
      UnnamedSelector: ComponentSelector could not find the component
      for hint: xslt	at org.apache.avalon.excalibur.component
   This also causes another exception later:
   WARN    (2002-06-06) 14:45.36:056   [core.event-pipeline]
    (/bredevc/index.html) HttpProcessor[8080][1]/AbstractEventPipeline:
     Failed to release components from event pipeline.
    java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
     at java.util.ArrayList.RangeCheck( Code))
     at java.util.ArrayList.get( Code))
     at org.apache.cocoon.components.pipeline.AbstractEventPipeline

That's where the fun ended (or began, depending on PoV).

The big problem is that none of the Excalibur code logs anything.
I have absolutely no idea why.

Because of this, I tried to put some trace messages into the Excalibur
code. Does somebody know why it's so much of a pain to get the Excalibur
source distribution to compile? It took me *two* *full* *hours*, a
timespan hitherto unprecedented for any Apache project and most other

After digging through a heap of output for three days, I discovered
that the logged problem was completely bogus: The exception was caused
- the TraxTransformer pool could not be refilled, because
- the component handler for BrowserImpl could not be created because
** drum roll **
- the BrowserImpl.createDocumentForBrowserInfo() bombs because
- the Saxon DOM does not allow modifications of a DOM document and
   throws an UnsupportedOperationException
I looked hard  but was unable to spot the point where this exception
was lost.

There appear to be a few places in ExcaliburComponentManager and other
places where the assumptions about what could go wrong are a bit too
optimistic.  Simply ignoring an exception and trying to get a component
from the parent manager or trying to create a new handler could mask
the underlying problems. Fixing this ought to be hard, component
handlers and selectors probably need to discriminate between stuff that
cannot be looked up because a parent/child is responsible and stuff
that cannot be looked up or created because important data is missing
or previous steps had failed.

Furthermore, the way to generate the browserinfo appears to be one of
the more esoteric solutions I've seen to date: generating a Java file
from XML which builds various hashMaps from which DOM documents are
built which are put together with the data in the DOM into the
HashMaps...  I'd thought there would an XML file read at sitemap
initialisation time, perhaps into a DOM, and the HashMaps are filled
from the XML data.


To unsubscribe, e-mail:
For additional commands, email:

View raw message