cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uwe Gerger <Uwe.Ger...@bmw.de>
Subject Re: Orcale-XML-Parser in Coccon2
Date Wed, 26 Mar 2003 12:28:57 GMT
Hello,
I change the cocoon.xconf to use the Oracel-parser:
<xml-parser class="oracle.xml.jaxp.JXSAXParser"
logger="core.xml-parser">
....
    <parameter name="sax-parser-factory"
value="oracle.xml.jaxp.JXSAXParserFactory"/>
    <parameter name="document-builder-factory"
value="oracle.xml.jaxp.JXDocumentBuilderFactory"/>
</xml-parser>

When starting the web-server an loading a cocoon-application I get the
following error messages in "core.log":


DEBUG   (2003-03-26) 13:20.16:866   [core.startup] (Unknown-URI)
Unknown-thread/DefaultComponentHandler: ComponentHandler initialized
for: oracle.xml.jaxp.JXSAXParser
DEBUG   (2003-03-26) 13:20.16:866   [core.startup] (Unknown-URI)
Unknown-thread/ExcaliburComponentManager: Could not access the Component
for role: org.apache.avalon.excalibur.xml.Parser
java.lang.IllegalAccessException: oracle.xml.jaxp.JXSAXParser
	at java.lang.Class.newInstance0(Native Method)
	at java.lang.Class.newInstance(Class.java:232)
	at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:102)
	at
org.apache.avalon.excalibur.component.DefaultComponentHandler.doGet(DefaultComponentHandler.java:106)
	at
org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:139)
	at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:374)
	at org.apache.cocoon.Cocoon.configure(Cocoon.java:324)
	at org.apache.cocoon.Cocoon.initialize(Cocoon.java:266)
	at
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1237)
	at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:435)
	at
weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java:499)
	at
weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStubImpl.java:453)
	at
weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:442)
	at
weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:361)
	at
weblogic.servlet.internal.ServletContextImpl.preloadServlet(ServletContextImpl.java:752)
	at
weblogic.servlet.internal.ServletContextImpl.preloadServlets(ServletContextImpl.java:726)
	at weblogic.t3.srvr.HttpServer.initServletContexts(HttpServer.java:683)
	at weblogic.t3.srvr.HttpServer.start(HttpServer.java:479)
	at weblogic.t3.srvr.T3Srvr.start(T3Srvr.java:1393)
	at weblogic.t3.srvr.T3Srvr.main(T3Srvr.java:879)
	at java.lang.reflect.Method.invoke(Native Method)
	at weblogic.Server.startServerDynamically(Server.java:140)
	at weblogic.Server.main(Server.java:97)
	at weblogic.Server.main(Server.java:58)
ERROR   (2003-03-26) 13:20.16:866   [core] (Unknown-URI)
Unknown-thread/Cocoon: Could not configure Cocoon environment
org.apache.avalon.framework.component.ComponentException: Could not
access the Component
	at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:407)
	at org.apache.cocoon.Cocoon.configure(Cocoon.java:324)
	at org.apache.cocoon.Cocoon.initialize(Cocoon.java:266)
	at
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1237)
	at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:435)
	at
weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java:499)
	at
weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStubImpl.java:453)
	at
weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:442)
	at
weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:361)
	at
weblogic.servlet.internal.ServletContextImpl.preloadServlet(ServletContextImpl.java:752)
	at
weblogic.servlet.internal.ServletContextImpl.preloadServlets(ServletContextImpl.java:726)
	at weblogic.t3.srvr.HttpServer.initServletContexts(HttpServer.java:683)
	at weblogic.t3.srvr.HttpServer.start(HttpServer.java:479)
	at weblogic.t3.srvr.T3Srvr.start(T3Srvr.java:1393)
	at weblogic.t3.srvr.T3Srvr.main(T3Srvr.java:879)
	at java.lang.reflect.Method.invoke(Native Method)
	at weblogic.Server.startServerDynamically(Server.java:140)
	at weblogic.Server.main(Server.java:97)
	at weblogic.Server.main(Server.java:58)
java.lang.IllegalAccessException: oracle.xml.jaxp.JXSAXParser
	at java.lang.Class.newInstance0(Native Method)
	at java.lang.Class.newInstance(Class.java:232)
	at
org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(DefaultComponentFactory.java:102)
	at
org.apache.avalon.excalibur.component.DefaultComponentHandler.doGet(DefaultComponentHandler.java:106)
	at
org.apache.avalon.excalibur.component.ComponentHandler.get(ComponentHandler.java:139)
	at
org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(ExcaliburComponentManager.java:374)
	at org.apache.cocoon.Cocoon.configure(Cocoon.java:324)
	at org.apache.cocoon.Cocoon.initialize(Cocoon.java:266)
	at
org.apache.cocoon.servlet.CocoonServlet.createCocoon(CocoonServlet.java:1237)
	at org.apache.cocoon.servlet.CocoonServlet.init(CocoonServlet.java:435)
	at
weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java:499)
	at
weblogic.servlet.internal.ServletStubImpl.createInstances(ServletStubImpl.java:453)
	at
weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:442)
	at
weblogic.servlet.internal.ServletStubImpl.prepareServlet(ServletStubImpl.java:361)
	at
weblogic.servlet.internal.ServletContextImpl.preloadServlet(ServletContextImpl.java:752)
	at
weblogic.servlet.internal.ServletContextImpl.preloadServlets(ServletContextImpl.java:726)
	at weblogic.t3.srvr.HttpServer.initServletContexts(HttpServer.java:683)
	at weblogic.t3.srvr.HttpServer.start(HttpServer.java:479)
	at weblogic.t3.srvr.T3Srvr.start(T3Srvr.java:1393)
	at weblogic.t3.srvr.T3Srvr.main(T3Srvr.java:879)
	at java.lang.reflect.Method.invoke(Native Method)
	at weblogic.Server.startServerDynamically(Server.java:140)
	at weblogic.Server.main(Server.java:97)
	at weblogic.Server.main(Server.java:58)

I don't know why I receive a IllegalAccessException. In the policy-file
I've set "java.security.AllPermissions".

Any sugestions?

Thanks in advance
	Uwe


mpo@outerthought.org schrieb:
> 
> 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
> >
> > mpo@outerthought.org 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/
> >>mpo@outerthought.org                              mpo@apache.org
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> >>For additional commands, e-mail: cocoon-users-help@xml.apache.org
> >
> >
> 
> --
> Marc Portier                            http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> Read my weblog at              http://radio.weblogs.com/0116284/
> mpo@outerthought.org                              mpo@apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org

-- 
Uwe Gerger                                _/_/_/   _/    _/  _/    _/
BMW AG, TG-53 IT-Technologie             _/   _/  _/_/_/_/  _/    _/
80788 Muenchen                          _/_/_/   _/ _/ _/  _/ _/ _/
Tel: +49 89 382 35687                  _/   _/  _/    _/  _/_/_/_/
Fax: +49 89 382 49040                 _/_/_/   _/    _/  _/    _/
mailto:Uwe.Gerger@bmw.de

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org


Mime
View raw message