Home.... | log in.... | Pub my question! | Sign-up....
Java-index >> Enterprise & Remote Computing >> Web Tier APIs

org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found

i am running Java Sun System Web Server 6.1 SP5 on Windows Server 2003.

i have deployed a 3rd party web application and it works properly. i have also written and deployed my own servlet/struts web application that works properly. the 3rd party application allows for some customization (i.e., you can add links in that application to point to other locations). i have added a link that points from the 3rd party web application to my own web application.

the problem occurs when i do the following steps (in this exact order):

1. deploy MY war file on the web server.

2. bounce the web server.

3. access the 3rd party application in a web browser.

4. click on a link in the 3rd party application that points to MY application.

at this point i get an error (see the stack trace at the end of this posting). the weird thing is that i DO NOT get this error if i access MY application BEFORE attempting to access the 3rd party application.

the 3rd party application has included the following jars (among others) in /WEB-INF/lib:

xercesImpl.jar, xml-apis.jar, saxon.jar, saxon-jdom.jar

i've looked around the web, and there is mention of incompatible xerces classes. i tried to add the aforementioned jars to MY /WEB-INF/lib directory to see if that would help, but it does not. i am at a loss of how to fix this...HELP!!!

stack trace:

javax.servlet.ServletException: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found

at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:387)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:908)

at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:772)

at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:471)

at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:382)

at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1062)

at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:386)

at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:229)

at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)

at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:787)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:908)

at org.apache.catalina.core.StandardWrapperValve.invokeServletService(StandardWrapperValve.java:771)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:322)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:212)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:209)

at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:509)

at com.iplanet.ias.web.connector.nsapi.NSAPIProcessor.process(NSAPIProcessor.java:161)

at com.iplanet.ias.web.WebContainer.service(WebContainer.java:580)

-- Root Cause --

javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found

at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:99)

at org.apache.jasper.parser.ParserUtils.parseXMLDocument(ParserUtils.java:194)

at org.apache.jasper.compiler.TagLibraryInfoImpl.parseTLD(TagLibraryInfoImpl.java:287)

at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:219)

at org.apache.jasper.compiler.JspParseEventListener.processTaglibDirective(JspParseEventListener.java:1220)

at org.apache.jasper.compiler.JspParseEventListener.handleDirective(JspParseEventListener.java:802)

at org.apache.jasper.compiler.DelegatingListener.handleDirective(DelegatingListener.java:125)

at org.apache.jasper.compiler.Parser$Directive.accept(Parser.java:255)

at org.apache.jasper.compiler.Parser.parse(Parser.java:1157)

at org.apache.jasper.compiler.Parser.parse(Parser.java:1115)

at org.apache.jasper.compiler.Parser.parse(Parser.java:1111)

at org.apache.jasper.compiler.ParserController.parse(ParserController.java:239)

at org.apache.jasper.compiler.Compiler.compile(Compiler.java:227)

at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.loadJSP(JspServlet.java:778)

at com.iplanet.ias.web.jsp.JspServlet$JspServletWrapper.access$000(JspServlet.java:636)

at com.iplanet.ias.web.jsp.JspServlet.serviceJspFile(JspServlet.java:413)

at com.iplanet.ias.web.jsp.JspServlet.service(JspServlet.java:375)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:908)

at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:772)

at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:471)

at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:382)

at org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1062)

at org.apache.struts.action.RequestProcessor.processForwardConfig

[5446 byte] By [milleranda] at [2007-10-2 20:09:39]
«« Client seems to be unable to read response from service
»» Problem with Theard
# 1

Rough explanation of what is happening (similar things happened to me in Websphere):

If you access the 3rd-party application then it will use the copy of Xerces that's in its class path, perhaps because it's hard-coded to do so in some way. This sets up Xerces to be the XML parser for the entire JVM. Then your application server (not your other web application) needs to do some XML parsing, but it doesn't have access to Xerces in its class path. Hence the result.

Is it absolutely necessary for the 3rd-party application to have those jars in its classpath? If your underlying JRE is Java 1.4 or later -- and surely it is -- then it provides XML parsing and XSL transforming, so you should be able to leave them out.

DrClapa at 2007-7-13 22:50:09 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 2

the 3rd party application actually requires the jars in the classpath as far as i can tell. part of the installation/deployment of this application requires the option: -Djavax.xml.parsers.SAXParserFactory = org.apache.crimson.jaxp.SAXParserFarctoryImpl

this 3rd party application is an interesting creature. it is not a pure java/servlet application. there is a completely separate application server (that allows for remote desktop clients). when a user accesses the web application (as opposed to the the desktop client), the servlet contacts the application server and there is a messaging interface that occurs. the data that is returned is then parsed with their XML parser and is formatted for display before being returned back to the browser.

my underlying JRE is 1.4.2 (again, a requirement of the 3rd party application).

it seems like there should be a way for me to do one of the following:

1) add some jars to my classpath so that MY application can find the missing classes.

2) manually specify NOT to use Xerces in MY application.

i'm confused as to why my application cannot find the correct classes, especially when i manually copied the 3rd party application's jars to MY ap's WEB-INF/lib directory in an attempt to make the classes visible.

milleranda at 2007-7-13 22:50:09 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 3

> i'm confused as to why my application cannot find the

> correct classes, especially when i manually copied

> the 3rd party application's jars to MY ap's

> WEB-INF/lib directory in an attempt to make the

> classes visible.

Your application and that other 3rd-party application are loaded by different classloaders. So org.apache.xerces.jaxp.DocumentBuilderFactoryImpl in your application's classloader is not the same class as org.apache.xerces.jaxp.DocumentBuilderFactoryImpl in the 3rd-party application's classloader.

Your best hope is to make the entire Tomcat installation use the XML and XSL libraries that the 3rd-party application is forcing upon you. That would involve putting their jar files in (I think) Tomcat's common/lib directory and not in the individual applications' WEB-INF/lib directories. It would also involve providing the system properties (as you described with -D...) to Tomcat when it starts up.

Don't blame me if this doesn't work because I haven't tried it. But I don't think anything else is going to work, really. Except running the two applications in different instances of Tomcat.

DrClapa at 2007-7-13 22:50:09 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
# 4

i've added the jars to \Sun\WebServer6.1\bin\https\jar (which is Sun One's version of common\lib), and i have modified the classpath as per Dr. Clap's suggestion but i am still getting the same error. i am not sure how this error is even possible at this point since i have added the jars to the "common" directory and i've included them in the classpath...

milleranda at 2007-7-13 22:50:09 > top of Java-index,Enterprise & Remote Computing,Web Tier APIs...
Enterprise & Remote Computing
Web Tier APIs

Enterprise & Remote Computing New Topic

Enterprise & Remote Computing Hot Topic

Enterprise & Remote Computing

All Classified