Uwe Gerger wrote:
it is the standard xml-parser in our company; so we have to use it instead of xerces! That's the only reason!
uh!
must feel great though :-p
maybe jdk 1.4 is also a standard in whoch case you have a serious conflict :-)
in coocon.xconf I found some parameter options for the XML-parser, namely sax-parser-factory and document-builder-factory. Have I have to specify them? In the original state they are comment out?
aha. you made me have a look myself now. it's even better then I suggested (I should 've known though)
yes, use those and replace the ??? values with the factories provided by the oracle implementation.
It will need to be full qualified classnames you put in there.
For inspiration on the values open the oracle-jaxp-implementation-whatevername.jar (eg with winzip)
and copy the contents of the files in META-INF/services/javax.xml.parsers.* into the respective elements.
(if oracle parser is jaxp compliant those files should be in the jar, otherwise you'll need to go into the documentation)
for interest in 2 words the theory:
JAXP is an insulation layer for having xml docs parsed using the SAX or DOM API (forgetting about the XSLT support for ease of argument)
Rather then doing the parsing itself this layer just specifies how JAXP compliant parsers should work AND offers a transparent dynamic loading of the implementation class through the AbstractFactory pattern.
Which boils down to:
This last technique requires you to specify which is the full qualified class name of the implementation-factory to be used.
- cocoon lets you do that in the elms you mention there, and I would use that option in this case (since you want to hardwire the inhouse STANDARD) the bad thing about this approach is that newer versions might (unlikely) place their factories elsewhere
- jaxp itself 'detects' (see the directory /META-INF/services in the jar file of xerces and (should be oracle) parsers) which implementation to use by probing for the files /META-INF/services/javax.xml.parsers.(SAXParserFactory or DocumentBuilderFactory) in its classpath... therefor the 'first' jaxp implementation jar in the classpath will get used.
since jdk 1.4 however this means you also have to outsmart the jre-classpath (since it already holds xerces) using the endorsed mechanism
(you will need to check out docos from your webcontainer I guess)
in this latter case I would very much opt for removing xercesImpl.jar
Thanks Uwe
[EMAIL PROTECTED] schrieb:
Uwe,
have no experience with it, however if it is fully JAXP compliant it _should_ be as easy as putting the jar in the classpath up front of (better yet: and removing) the xerces impl jar.
for more detail and explanation: check the <xml-parser> elm in your WEB-INF/cocoon.xconf (loads of comments there taking you by the hand)
any particular reason why you like to switch it though?
-marc=
Uwe Gerger wrote:
Hello, I would like to use the Oracle - XML-Parser (version xdk-9_2_0_1_0) in Cocoon 2. Has anybody some experience in doing this!? What I have to do?
Thanks in advance Uwe
-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
