You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Stephen Ng <st...@verizon.net> on 2002/05/21 16:32:04 UTC
Problems with Saxon (6.5.2) and resolver (Cocoon 2.0.2)
I've been struggling with getting Saxon 6.5.2 and Cocoon 2.0.2 working
together for a couple of days now....
Here's what I did and what I found:
1. I replaced xalan-2.3.1 with saxon.jar.
2. I grabbed v1.9 of xsp.xsl
(http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoo
n/components/language/markup/xsp/java/xsp.xsl)
I started getting (intermittent) null pointer errors trying to resolve
static files. I had a sub-sitemap with:
"context://dir/data.xml"
Changing these to just
"dir/data.xml"
made a set of them go away. (Does this make any sense?)
But I continue to get NPE's in the resolver code. They came from
XSLTProcessorImpl::resolve() {
//...
File parent = new File(base.substring(5));
File parent2 = new File(parent.getParentFile(), href);
xslSource = resolver.resolve(parent2.toURL().toExternalForm());
}
Turns out "resolver" was null.
I looked in CVS, and the whole mechanism for getting a resolver appears
to have been rewritten. So, as a hack, I just check for null in
setSourceResolver. (I have *no idea* what I'm doing here, folks).
public void setSourceResolver(SourceResolver resolver) {
if (resolver!=null)
this.resolver = resolver;
}
Now I have no more NPE's, but I still have a resolver problem
somewhere--one of my pipelines is failing because it can't locate a
stylesheet. Still have to figure that one out.
But, now my app is running enough that I can time it. Well, I'm
getting it's between 10% to 25% faster, which is not nearly as much as
I'd hoped. (A quick test showed Saxon 7 to be a tad slower, but it
might just be noise.) (My app is currently taking about 2.2 seconds to
serve a page (1.7 Ghz P4, 512MB Ram, WinXP), of which I figure no more
than .5 sec is due to database access, and the rest I think is Cocoon
time. I'm really gunning for sub-second response for a demo next week.)
Should I upgrade to CVS 2.0.3 and try again? (I know this is a stupid
question, but how close is it to being soup?) Or keep plugging at
2.0.2? Or wait for 2.0.3 to ship? Best thing would be XSLTC!
Steve
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
RE: Problems with Saxon (6.5.2) and resolver (Cocoon 2.0.2)
Posted by Artur Bialecki <ar...@digitalfairway.com>.
Also, saxon 6.5.2 and 7 has a bug with identity transform
because of bug in DOMDriver.
So, if you're using XPath (eg, xinclude transformer) things
might not look the way you expect them to.
I told the author of Saxon how to fix this bug, but haven't
heard anything back.
Artur...
> -----Original Message-----
> From: Frank Ridderbusch [mailto:frank.ridderbusch@fujitsu-siemens.com]
> Sent: Tuesday, May 21, 2002 10:58 AM
> To: cocoon-users@xml.apache.org
> Subject: Re: Problems with Saxon (6.5.2) and resolver (Cocoon 2.0.2)
>
>
> Well, here is what I've done. However I've found, that no all samples work
> any more with Saxon, in particular SQL transformer and XMLforms.
>
> - Also replaced xalan.jar with saxon.jar
>
> - Starting the servlet-engine with the additional switch
>
> -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
>
> in TOMCAT_OPTS/CATALINA_OPTS.
>
> According to the saxon documentation, saxon uses/can use two XML parsers,
> one for the input and the other for the XSL stylesheet, so that the input
> can be validated and the XSL stylesheet not.
>
> In my setup, before setting the above option, I alway received exceptions
> coming from the in saxon included parser Alfred (something in the realm
> of resolving). Now, Xerces is used for both input and stylesheet.
>
> - in cocoon/WEB-INF/classes/CatalogManager.properties I've set
>
> catalogs=/usr/lib/xemacs/packages/etc/psgml/CATALOG
>
> This is a catalog file, which is included with the PSGML (a XEmacs SGML/HTML
> editing package) and the PSGML packages also contains a bunch of DTDs and
> entity files, which saves you collecting them from the Net.
>
> This setup works for me, even for my own custom DTDs. Although I'm using 2.1-dev
> this should also work for 2.0.2. At least it works with 2.0.3-dev for me.
>
> Perhaps, this helps.
>
> On Tue, 21 May 2002 10:32:04 -0400
> "Stephen Ng" <st...@verizon.net> wrote:
>
> > I've been struggling with getting Saxon 6.5.2 and Cocoon 2.0.2 working
> > together for a couple of days now....
> >
> > Here's what I did and what I found:
> >
> > 1. I replaced xalan-2.3.1 with saxon.jar.
> > 2. I grabbed v1.9 of xsp.xsl
> > (http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoo
> > n/components/language/markup/xsp/java/xsp.xsl)
> >
> > I started getting (intermittent) null pointer errors trying to resolve
> > static files. I had a sub-sitemap with:
> >
> > "context://dir/data.xml"
> >
> > Changing these to just
> >
> > "dir/data.xml"
> >
> > made a set of them go away. (Does this make any sense?)
> >
> > But I continue to get NPE's in the resolver code. They came from
> >
> > XSLTProcessorImpl::resolve() {
> > //...
> >
> > File parent = new File(base.substring(5));
> > File parent2 = new File(parent.getParentFile(), href);
> > xslSource = resolver.resolve(parent2.toURL().toExternalForm());
> >
> > }
> >
> > Turns out "resolver" was null.
> >
> > I looked in CVS, and the whole mechanism for getting a resolver appears
> > to have been rewritten. So, as a hack, I just check for null in
> > setSourceResolver. (I have *no idea* what I'm doing here, folks).
> >
> > public void setSourceResolver(SourceResolver resolver) {
> > if (resolver!=null)
> > this.resolver = resolver;
> > }
> >
> > Now I have no more NPE's, but I still have a resolver problem
> > somewhere--one of my pipelines is failing because it can't locate a
> > stylesheet. Still have to figure that one out.
> >
> > But, now my app is running enough that I can time it. Well, I'm
> > getting it's between 10% to 25% faster, which is not nearly as much as
> > I'd hoped. (A quick test showed Saxon 7 to be a tad slower, but it
> > might just be noise.) (My app is currently taking about 2.2 seconds to
> > serve a page (1.7 Ghz P4, 512MB Ram, WinXP), of which I figure no more
> > than .5 sec is due to database access, and the rest I think is Cocoon
> > time. I'm really gunning for sub-second response for a demo next week.)
> >
> > Should I upgrade to CVS 2.0.3 and try again? (I know this is a stupid
> > question, but how close is it to being soup?) Or keep plugging at
> > 2.0.2? Or wait for 2.0.3 to ship? Best thing would be XSLTC!
> >
> > Steve
> >
> --
> Mit freundlichen Gruessen / Regards
>
> Frank Ridderbusch
>
> Fujitsu Siemens Computers, EP SQ XS1
> Heinz Nixdorf Ring, 33106 Paderborn, Germany
> Email: frank.ridderbusch(at)fujitsu-siemens.com
>
> ---------------------------------------------------------------------
> Please check that your question has not already been answered in the
> FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Problems with Saxon (6.5.2) and resolver (Cocoon 2.0.2)
Posted by Frank Ridderbusch <fr...@fujitsu-siemens.com>.
Well, here is what I've done. However I've found, that no all samples work
any more with Saxon, in particular SQL transformer and XMLforms.
- Also replaced xalan.jar with saxon.jar
- Starting the servlet-engine with the additional switch
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
in TOMCAT_OPTS/CATALINA_OPTS.
According to the saxon documentation, saxon uses/can use two XML parsers,
one for the input and the other for the XSL stylesheet, so that the input
can be validated and the XSL stylesheet not.
In my setup, before setting the above option, I alway received exceptions
coming from the in saxon included parser Alfred (something in the realm
of resolving). Now, Xerces is used for both input and stylesheet.
- in cocoon/WEB-INF/classes/CatalogManager.properties I've set
catalogs=/usr/lib/xemacs/packages/etc/psgml/CATALOG
This is a catalog file, which is included with the PSGML (a XEmacs SGML/HTML
editing package) and the PSGML packages also contains a bunch of DTDs and
entity files, which saves you collecting them from the Net.
This setup works for me, even for my own custom DTDs. Although I'm using 2.1-dev
this should also work for 2.0.2. At least it works with 2.0.3-dev for me.
Perhaps, this helps.
On Tue, 21 May 2002 10:32:04 -0400
"Stephen Ng" <st...@verizon.net> wrote:
> I've been struggling with getting Saxon 6.5.2 and Cocoon 2.0.2 working
> together for a couple of days now....
>
> Here's what I did and what I found:
>
> 1. I replaced xalan-2.3.1 with saxon.jar.
> 2. I grabbed v1.9 of xsp.xsl
> (http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/java/org/apache/cocoo
> n/components/language/markup/xsp/java/xsp.xsl)
>
> I started getting (intermittent) null pointer errors trying to resolve
> static files. I had a sub-sitemap with:
>
> "context://dir/data.xml"
>
> Changing these to just
>
> "dir/data.xml"
>
> made a set of them go away. (Does this make any sense?)
>
> But I continue to get NPE's in the resolver code. They came from
>
> XSLTProcessorImpl::resolve() {
> //...
>
> File parent = new File(base.substring(5));
> File parent2 = new File(parent.getParentFile(), href);
> xslSource = resolver.resolve(parent2.toURL().toExternalForm());
>
> }
>
> Turns out "resolver" was null.
>
> I looked in CVS, and the whole mechanism for getting a resolver appears
> to have been rewritten. So, as a hack, I just check for null in
> setSourceResolver. (I have *no idea* what I'm doing here, folks).
>
> public void setSourceResolver(SourceResolver resolver) {
> if (resolver!=null)
> this.resolver = resolver;
> }
>
> Now I have no more NPE's, but I still have a resolver problem
> somewhere--one of my pipelines is failing because it can't locate a
> stylesheet. Still have to figure that one out.
>
> But, now my app is running enough that I can time it. Well, I'm
> getting it's between 10% to 25% faster, which is not nearly as much as
> I'd hoped. (A quick test showed Saxon 7 to be a tad slower, but it
> might just be noise.) (My app is currently taking about 2.2 seconds to
> serve a page (1.7 Ghz P4, 512MB Ram, WinXP), of which I figure no more
> than .5 sec is due to database access, and the rest I think is Cocoon
> time. I'm really gunning for sub-second response for a demo next week.)
>
> Should I upgrade to CVS 2.0.3 and try again? (I know this is a stupid
> question, but how close is it to being soup?) Or keep plugging at
> 2.0.2? Or wait for 2.0.3 to ship? Best thing would be XSLTC!
>
> Steve
>
--
Mit freundlichen Gruessen / Regards
Frank Ridderbusch
Fujitsu Siemens Computers, EP SQ XS1
Heinz Nixdorf Ring, 33106 Paderborn, Germany
Email: frank.ridderbusch(at)fujitsu-siemens.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>