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" <[EMAIL PROTECTED]> 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: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
