You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by "J.Pietschmann" <j3...@yahoo.de> on 2002/06/11 22:53:35 UTC
C2 with saxon
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 with saxon
Posted by Carlos <ca...@cvc.edu>.
You can use Saxon's -X option to force saxon to use Xerces as the xml
parser. For command line it's something like:
java com.icl.saxon.StyleSheet -x org.apache.xerces.parsers.SAXParser
I don't know how to translate it to Cocoon instructions
Carlos
On 6/11/02 1:53 PM, "J.Pietschmann" <j3...@yahoo.de> wrote:
>
> - 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.
--
Carlos E. Araya
---+ WebCT Administrator/Trainer
P | California Virtual Campus
- | C/O De Anza College
G | 21250 Stevens Creek Blvd
---+ Cupertino, CA 95014
email carlos@cvc.edu
web http://www.cvc1.org/ (work)
http://silverwolf-net.net (personal)
phone 408 257 0420 (work)
PGP Fingerprint: E629 5DFD 7EAE 4995 E9D7 3D2F 5A9F 0CE7 DFE7 1756
"Do not meddle in the affairs of dragons....for you are crunchy and taste
good with ketchup and mayonnaise.."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 with saxon
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Vadim Gritsenko wrote:
> If you can, please create simple test case and send it to bugzilla.
I thought I did...done now.
Do you have some hints for tracking down bugs more effectively?
All the Components, Managers, Parent Managers and Manager Parents
and Children and Siblings and Selectors made me dizzy. It is like
stepping through a bytecode interpreter in order to debug the
interpreted program.
Just another example: After a small change (I thought), my project's
home page missed some content. I access an internal pipeline with
document('cocoon:/int/news')
Here some commented log snippets:
- The URI passed to document is passed to XSLTProcessorImpl.resolve().
DEBUG (2002-06-25) 17:14.02:560 [core.xslt-processor] (/bredevc/index.html)
HttpProcessor[8080][1]/XSLTProcessorImpl:
resolve(href = cocoon:/int/news, base = file:/proj/...
- Actual resolving snipped
DEBUG (2002-06-25) 17:14.02:582 [core.manager] (/bredevc/index.html) ...
- Got a source (not a XSL source, but you knew this already)
DEBUG (2002-06-25) 17:14.02:698 [core.xslt-processor] (/bredevc/index.html)
HttpProcessor[8080][1]/XSLTProcessorImpl:
xslSource = ..., system id = cocoon://int/news
- Internal pipeline is called
DEBUG (2002-06-25) 17:14.02:700 [core.source-handler] (/bredevc/index.html)
HttpProcessor[8080][1]/AbstractEnvironment:
Resolving 'file:///proj/bre/team/interface/interface/news'
in context 'file:/proj/bre/work/t384/webappdevc/build/webapps/bredevc/WEB-INF/'
DEBUG (2002-06-25) 17:14.02:703 [core.source-handler] (/bredevc/index.html)
HttpProcessor[8080][1]/AbstractEnvironment:
Resolved to 'file:/proj/bre/team/interface/interface/news'
DEBUG (2002-06-25) 17:14.02:707 [core.event-pipeline] (/bredevc/index.html)
HttpProcessor[8080][1]/CachingEventPipeline: Recycling of CachingEventPipeline
DEBUG (2002-06-25) 17:14.02:709 [core.manager] (/bredevc/index.html)
HttpProcessor[8080][1]/LogKitLogger:
Put a org.apache.cocoon.generation.DirectoryGenerator back into the pool.
DEBUG (2002-06-25) 17:14.02:710 [core.manager] (/bredevc/index.html)
HttpProcessor[8080][1]/LogKitLogger:
Put a org.apache.cocoon.components.pipeline.CachingEventPipeline
back into the pool.
DEBUG (2002-06-25) 17:14.02:712 [core.stream-pipeline] (/bredevc/index.html)
HttpProcessor[8080][1]/CachingStreamPipeline:
Recycling of CachingStreamPipeline
DEBUG (2002-06-25) 17:14.02:713 [core.manager] (/bredevc/index.html)
HttpProcessor[8080][1]/LogKitLogger:
Put a org.apache.cocoon.serialization.XMLSerializer back into the pool.
DEBUG (2002-06-25) 17:14.02:714 [core.manager] (/bredevc/index.html)
HttpProcessor[8080][1]/LogKitLogger:
Put a org.apache.cocoon.components.pipeline.CachingStreamPipeline
back into the pool.
- Did something odd happen? All seems well, but then:
WARN (2002-06-25) 17:14.02:718 [core.xslt-processor] (/bredevc/index.html)
HttpProcessor[8080][1]/TraxErrorHandler: Error in TraxTransformer:
javax.xml.transform.TransformerException: Malformed URL [cocoon:/int/news]
<snip repeated lines>
at com.icl.saxon.StandardURIResolver.resolve(StandardURIResolver.java:75)
at com.icl.saxon.functions.Document.makeDoc(Document.java:188)
Where the heck did Saxons default URI resolver pop up from?
In the beginning I saw only the exception and assumed something
went wrong again with setting up the resolver. It took me *hours*
to discover that the URI had been already resolved. The real reason
was that I introduced an action into the internal pipeline in order
to get some global configuration data, which returned null due to
some oversights. Saxon got a null Source and fell back to use it's
own default resolver, which of course cannot handle the cocoon:
protocol. A null source should never be delivered to a lower level
processing layer. (I'll report this tomorrow...)
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 with saxon
Posted by Ovidiu Predescu <ov...@apache.org>.
On 6/24/02 7:07 PM, "Vadim Gritsenko" <va...@verizon.net> wrote:
>> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
>>
>> 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!).
>
> If you can, please create simple test case and send it to bugzilla.
Gosh, even with a simple testcase, replicating the whole story is a major
undertaking :(
J., thanks for taking the time to look into this!
Regards,
--
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 with saxon
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
...
> 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!).
If you can, please create simple test case and send it to bugzilla.
Vadim
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 with saxon
Posted by "J.Pietschmann" <j3...@yahoo.de>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 with saxon
Posted by Ovidiu Predescu <ov...@apache.org>.
On 6/13/02 5:07 PM, "J.Pietschmann" <j3...@yahoo.de> wrote:
> Ovidiu Predescu wrote:
>> You didn't tell us how the story ended? Did you succeed in running C2 with
>> Saxon+AElfred?
>
> I finally succeeded and got a page. Within a few hours,
> I got all the interesting bits from my home grown framework
> and had the first pages up.
> Then I hit the obnoxious null resolver error:
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102338754604507&w=2
> This problem is apparently not amenable to a quick fix,
> there has been extensive patches to TraxTransformer.java
> and other places recently to ensure there is always a
> proper resolver set.
>
> I'm currently downloading the CVS head and preparing myself
> for all kinds of surprises.
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.
>> I'd be interested in some performance comparison between
>> Xerces+Xalan, Xerces+Saxon and AElfred+Saxon.
>
> I use Saxon mainly because of a few extension functions.
> It appears, however, that Xalan isn't even able to handle
> one multi-megabyte file (XML abused as database).
OK.
--
Ovidiu Predescu <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 with saxon
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Ovidiu Predescu wrote:
> You didn't tell us how the story ended? Did you succeed in running C2 with
> Saxon+AElfred?
I finally succeeded and got a page. Within a few hours,
I got all the interesting bits from my home grown framework
and had the first pages up.
Then I hit the obnoxious null resolver error:
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=102338754604507&w=2
This problem is apparently not amenable to a quick fix,
there has been extensive patches to TraxTransformer.java
and other places recently to ensure there is always a
proper resolver set.
I'm currently downloading the CVS head and preparing myself
for all kinds of surprises.
> I'd be interested in some performance comparison between
> Xerces+Xalan, Xerces+Saxon and AElfred+Saxon.
I use Saxon mainly because of a few extension functions.
It appears, however, that Xalan isn't even able to handle
one multi-megabyte file (XML abused as database).
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 with saxon
Posted by "J.Pietschmann" <j3...@yahoo.de>.
J.Pietschmann wrote:
> What's the general stance wrt using XML tools other than Xerces?
Clarification: I don't mind whether Cocoon requires a writable
DOM or not (would be nice if it were documented somewhere though)
What really worries me is that there was not the faintest hint
that the ominous failures had been caused by a read-only DOM.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 with saxon
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Vadim Gritsenko wrote:
> BTW, this is done via DOM API in the XConfToolTask.java. If you use
> AElfred for Cocoon build, and if AElfred's DOM is read-only... How this
> task will work?
It didn't work, obviously. The build suceeded anyway.
What's the general stance wrt using XML tools other than Xerces?
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: C2 with saxon
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Ovidiu Predescu [mailto:ovidiu@apache.org]
>
> On 6/11/02 1:53 PM, "J.Pietschmann" <j3...@yahoo.de> wrote:
...
> > - 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.
Cocoon's build should add either Pizza or Javac to the cocoon.xconf
(depending on availability of the particular compiler).
BTW, this is done via DOM API in the XConfToolTask.java. If you use
AElfred for Cocoon build, and if AElfred's DOM is read-only... How this
task will work?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: C2 with saxon
Posted by Ovidiu Predescu <ov...@apache.org>.
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" <j3...@yahoo.de> 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 <ov...@apache.org>
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org