Hi,
I found the source of the problem:
saxon.jar has those files:
/META-INF/services/javax.xml.parsers.SAXParserFactory
/META-INF/services/javax.xml.transform.TransformerFactory
Those files contains a name of class, respectively:
com.icl.saxon.aelfred.SAXParserFactoryImpl
com.icl.saxon.TransformerFactoryImpl
If I remove those files from the jar, everything works fine. I guess
that jackrabbit is picking those classes to do the xml parsing of the
configuration files and does not expect those ones.
Thanks to all for your help.
Maxime Bégnis.
I've just tried (same code base, I'm Max's 'boss' ;-)) with saxon9 jars,
namely saxon9.jar, saxon9-s9api.jar and saxon9-dom.jar, on the
classpath. Everything works as expected.
We're investigating if we can use Saxon9 with DocBook stylesheets
(that's what we need Saxon for, in the first place), so far no luck. It
would be nice if saxon6 jars would work fine...
Connor, Brett (LNG-TWY) wrote:
-----Original Message-----
From: Alexander Klimetschek
On Wed, Jul 22, 2009 at 1:08 PM, Connor, Brett
(LNG-TWY)<[email protected]> wrote:
That implies that it can read workspace.xml ok with saxon,
but not repository.xml.
This lends weight to Julian's suggestion, which I think is
the better suggestion than mine.
No, the stacktrace indicates that it happens when parsing a
workspace.xml:
org.apache.jackrabbit.core.config.RepositoryConfig.loadWorkspa
ceConfig(RepositoryConfig.java:368)
Regards,
Alex
Ah you're right, didn't read that detail. So is it a reading or a
writing
problem then. Perhaps binary compare the workspace.xml written with
and witout saxon.jar in place? Is workspace.xml written using xslt?
I've now deleted the email with the stack trace so this may well be a
silly idea also.
LexisNexis is a trading name of REED ELSEVIER (UK) LIMITED - Registered office
- 1-3 STRAND, LONDON WC2N 5JR
Registered in England - Company No. 02746621
