[jboss-jira] [JBoss JIRA] Commented: (JBAS-3248) JBoss xercesImpl.jar conflicts with xerces.jar within Ears/wars

denny Valliant (JIRA) jira-events at lists.jboss.org
Mon Jul 6 16:57:51 EDT 2009


    [ https://jira.jboss.org/jira/browse/JBAS-3248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12475124#action_12475124 ] 

denny Valliant commented on JBAS-3248:
--------------------------------------

You can just delete the xercesImpl jar in the jasperserver/WEB-INF/lib folder and it will start fine.  Haven't done extensive testing with XML stuff to make sure there isn't something broken deep inside, but everything seems to work just dandy.

> JBoss xercesImpl.jar conflicts with xerces.jar within Ears/wars
> ---------------------------------------------------------------
>
>                 Key: JBAS-3248
>                 URL: https://jira.jboss.org/jira/browse/JBAS-3248
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: ClassLoading, Clustering
>    Affects Versions: JBossAS-4.0.3 SP1
>         Environment: Red Hat Enterprise Linux ES release 4;
> java version 1.5.0_06;
> JBoss in cluster mode
>            Reporter: Alan
>            Assignee: Scott M Stark
>
> I have an application (.war file) that uses a lib called xerces.jar located at .war /WEB-INF/lib directory. I run JBoss in cluster mode. So, after deploy, when I run my application, I got an exception with the xml libs. I guess it's a classloader problem. MY application tries to use the JBoss xml classes intead of it's own. I discovered the problem was with the xerces.jar and xercesImpl.jar because I deleted the line below from the <JBOSS_HOME>/bin/run.sh:
> -Djava.endorsed.dirs=...
> I searched for a solution and discovered jdk versions before 1.5 have a bug with xml, so I tried the solution above and all worked fine. Now my application use it's own xerces instead of JBoss xerces.
> I think my solution is a workaround. I would like to know if there is a better way to solve this problem. Is there ?
> The exception is below.
> Than you.
> Alan
> The exception:
> java.lang.reflect.InvocationTargetException
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>         at java.lang.reflect.Method.invoke(Method.java:585)
>         at org.apache.struts.actions.DispatchAction.perform(DispatchAction.java :236)
>         at org.apache.struts.action.ActionServlet.processActionPerform(ActionServlet.java:1787)
>         at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1586)
>         at org.apache.struts.action.ActionServlet.doPost (ActionServlet.java:510)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>         at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter (ApplicationFilterChain.java:252)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java :81)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>         at org.jboss.web.tomcat.security.CustomPrincipalValve.invoke (CustomPrincipalValve.java:39)
>         at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:159)
>         at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java :407)
>         at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:59)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
>         at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.java:105)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:744)
>         at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket (PoolTcpEndpoint.java:527)
>         at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
>         at java.lang.Thread.run(Thread.java:595)
> Caused by: java.lang.VerifyError: (class: org/apache/soap/util/xml/XercesParserLiaison, method: read signature: (Ljava/lang/String;Ljava/io/Reader;)Lorg/w3c/dom/Document;) Incompatible object argument 
>  for function call
>         at org.apache.soap.rpc.Call.<init>(Call.java)
>         at org.apache.soap.rpc.Call.<init>(Call.java)
>         at com.attachmate.mcs.agent.impl.SOAPPackager.a(SOAPPackager.java )
> ...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        



More information about the jboss-jira mailing list