Hi,
This was a very entertaining reading, although I bet for you the whole
experience was very frustrating! See below for some comments.
On 6/11/02 1:53 PM, "J.Pietschmann" <[EMAIL PROTECTED]> wrote:
> 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.
I've seen this problem too, I have no idea why it happens. It seems to work
fine for normal Cocoon, but unfortunately even if you use the interpreted
sitemap, this option needs to be added for XSP support in some really
obscure cases.
> - 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.
I noticed that too. It's a pain to build even if you check out the
directories in exactly the same structure as they are in CVS. There's no
centralized build file to allow a single build command to be issued. Very
painful...
>
> 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.
I think you can safely remove the BrowserImpl stuff from your local
directory. As far as I know there's no dependency on it in any other part of
Cocoon, and no sample uses this stuff anymore.
> 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.
The static generation of the Java code is a lot faster in development time
than reading the XML document using the bloody DOM API, and generating the
same hierarchical data structure you mention above. I think the author had a
really lazy butt when he wrote the code; BTW, I'm the author ;).
You didn't tell us how the story ended? Did you succeed in running C2 with
Saxon+AElfred? I'd be interested in some performance comparison between
Xerces+Xalan, Xerces+Saxon and AElfred+Saxon.
Cheers,
Ovidiu
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
