Hi,
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
parser.
- 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
-Djavax.xml.parsers.DocumentBuilderFactory=
com.icl.saxon.om.DocumentBuilderFactoryImpl
to CATALINA_OPTS to tell the JAXP implementation of Saxons DOM
builder.
- Next access still bombs because the sitemap cannot be compiled
org.apache.avalon.framework.parameters.ParameterException:
The parameter 'compiler' does not contain a value
Added
<parameter name="compiler"
value="org.apache.cocoon.components.language.programming.java.Javac"/>
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
adding
-Djavax.xml.parsers.SAXParserFactory=
com.icl.saxon.aelfred.SAXParserFactoryImpl
to CATALINA_OPTS.
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
-Dorg.xml.sax.driver=com.icl.saxon.aelfred.SAXDriver
to CATALINA_OPTS.
Again, I have no idea where this setting came from.
- Finally, the sitemap compiles but results in a 404 "ressource not
found" because of:
org.apache.avalon.framework.component.ComponentException:
UnnamedSelector: ComponentSelector could not find the component
for hint: xslt at org.apache.avalon.excalibur.component
.ExcaliburComponentSelector.select(ExcaliburComponentSelector.java:276)
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(ArrayList.java(Compiled Code))
at java.util.ArrayList.get(ArrayList.java(Compiled Code))
at org.apache.cocoon.components.pipeline.AbstractEventPipeline
.recycle(AbstractEventPipeline.java:306)
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
OSS.
After digging through a heap of output for three days, I discovered
that the logged problem was completely bogus: The exception was caused
because
- 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.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
