[Installation, Configuration & DEPLOYMENT] - ClassCastException due to Xerces conflict during app deploym
by rodos77
JBoss: 5.1.0.GA
JDK: 1.5.0_11-b03
OS: WinXP SP3
Hi,
I'm getting the dreaded ClassCastException when deploying my web app due to a conflict between XercesImpl.jar bundled with JBoss and another one inside my war file:
| 13:00:45,353 INFO [TomcatDeployment] deploy, ctxPath=/nexj-web
| 13:00:45,462 ERROR [JBossContextConfig] XML error parsing: context.xml
| org.jboss.xb.binding.JBossXBRuntimeException: Failed to create a new SAX parser
| at org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:100)
| at org.jboss.web.tomcat.service.deployers.JBossContextConfig.processContextConfig(JBossContextConfig.java:549)
| at org.jboss.web.tomcat.service.deployers.JBossContextConfig.init(JBossContextConfig.java:536)
| at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:279)
| at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
| at org.apache.catalina.core.StandardContext.init(StandardContext.java:5436)
| at org.apache.catalina.core.StandardContext.start(StandardContext.java:4148)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:310)
| at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142)
| at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461)
| at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118)
| at org.jboss.web.deployers.WebModule.start(WebModule.java:97)
| 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.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
| at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206)
| at $Proxy38.start(Unknown Source)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42)
| at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37)
| at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
| at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
| at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:286)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.system.ServiceController.doChange(ServiceController.java:688)
| at org.jboss.system.ServiceController.start(ServiceController.java:460)
| at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99)
| at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46)
| at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62)
| at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
| at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1178)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
| at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
| at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
| at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
| at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
| at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
| at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
| at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
| at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
| at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
| at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
| at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
| at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
| at org.jboss.Main.boot(Main.java:221)
| at org.jboss.Main$1.run(Main.java:556)
| at java.lang.Thread.run(Thread.java:595)
| Caused by: org.jboss.xb.binding.JBossXBException: Failed to create a new SAX parser
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:97)
| at org.jboss.xb.binding.UnmarshallerImpl.<init>(UnmarshallerImpl.java:56)
| at org.jboss.xb.binding.UnmarshallerFactory$UnmarshallerFactoryImpl.newUnmarshaller(UnmarshallerFactory.java:96)
| ... 73 more
| Caused by: java.lang.ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration
| at org.apache.xerces.parsers.SAXParser.<init>(SAXParser.java:99)
| at org.apache.xerces.parsers.SAXParser.<init>(SAXParser.java:84)
| at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(SAXParserImpl.java:364)
| at org.apache.xerces.jaxp.SAXParserImpl.<init>(SAXParserImpl.java:124)
| at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(SAXParserFactoryImpl.java:76)
| at org.jboss.xb.binding.parser.sax.SaxJBossXBParser.<init>(SaxJBossXBParser.java:92)
| ... 75 more
|
I've traced through the deployer and Xerces code and the Exception is happening for the following reason:
- the deployer sets the context classloader to be the war classloader
- the deployer tries to create a parser to parse context.xml file, this is delegated to xerces
- as part of initializing the parser, xerces does the following:
| (XMLParserConfiguration)ObjectFactory.createObject(
| "org.apache.xerces.xni.parser.XMLParserConfiguration",
| "org.apache.xerces.parsers.XIncludeAwareParserConfiguration")
|
- digging into the createObject() call, xerces uses the context classloader to load XIncludeAwareParserConfiguration
- however, XMLParserConfiguration to which XIncludeAwareParserConfiguration is cast in the above statement is loaded by the current classloader which is the deployer classloader (jboss-web, I believe)
- thus the ClassCastException
Now, I can resolve this issue by following the instructions in http://www.jboss.org/community/wiki/useJBossWebClassLoaderinJBoss5. However, neither of the approaches there is acceptable since they both boil down to effectively removing the XercesImpl.jar from my war. Both of those approaches force the war classloader to delegate to parent first which essentially forces the JBoss bundled XercesImpl.jar to always be used. In fact, if I follow this approach I get another (application specific) Exception because my application relies on using the context classloader (i.e. the war classloader) to load classes from the XercesImpl.jar inside my war. Additionally, I don't really want to change the Servlet Spec classloading behaviour anyway.
I think the real problem is that the deployer sets the context classloader to the war classloader before instantiating the parser. IMHO, I think the deployer should either do this after it instantiates the parser or it should temporarily swap out the context classloader and swap in the deployer classloader in its place. Incidently, in JBoss 4.0.5, the version from which I'm trying to upgrade to 5.1.0, there is no problem. I've briefly looked at the 4.0.5 code and I believe that the tomcat deployer used to deploy the war, indeed uses the deployer classloader to instantiate the parser and not the war classloader.
Do I have a point or am I way off?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244410#4244410
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244410
17 years
[Beginners Corner] - Bound to localhost instead of VIP
by aiesulauro
The RHEL4 netstat output below shows that the jboss-5.1.0.GA application server started with the __-b jestdev03__ command line option is listening on a localhost port. There are no user applications deployed to this application server. The database is mysql executing on the same host as the application server.
Is this a problem? Is there any way to determine which JBoss deployment is listening on the port?
| netstat -ap | grep 13450
| tcp 0 0 jestdev03:3873 *:* LISTEN 13450/java
| tcp 0 0 localhost.localdomain:35876 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:4712 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:3528 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:8009 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:4713 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:4457 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:1098 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:1099 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:webcache *:* LISTEN 13450/java
| tcp 0 0 jestdev03:8083 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:30426 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:krb524 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:4445 *:* LISTEN 13450/java
| tcp 0 0 jestdev03:4446 *:* LISTEN 13450/java
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244406#4244406
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244406
17 years
[Remoting] - Re: javax.jms.JMSException: Failure on underlying remoting c
by ron.sigal＠jboss.com
Hi Kris,
Well, that just shows that every day, in every way, we get better and better. :)
I have two suggestions.
1. On a busy network, or busy hosts, a spurious failure is always possible. If you lengthen the ping cycle, e.g.,
| <attribute name="validatorPingPeriod" isParam="true">20000</attribute>
| <attribute name="validatorPingTimeout" isParam="true">10000</attribute>
|
you might reduce the number of occurrences.
2. We just added some major fixes on the JBossRemoting / JBossMessaging boundary in EAP 4.3.CP05 (Remoting 2.2.3 / JBM 1.4.0.SP3_CP08), which seems to be available now. I'm not sure if they will affect your situation, but I think that anyone using JBossMessaging should probably upgrade to these new jars.
Of course, if you have a support contract, you would have to do the whole upgrade.
-Ron
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244403#4244403
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244403
17 years
[JBoss Messaging] - Re:
by nbhatia
"timfox" wrote : Why are you persisting orders in a database?
To clarify, orders are persisted in two databases, one on each system. The two systems belong to different departments (or even different companies) - so there is an ownership issue here and both systems need to save the data. Moreover the database representation of an order is different on each system (different attributes, different relationships) based on their responsibilities. Only the common attributes needed by both systems are passed on the JMS message. I hope this clarifies the need for persisting the orders in the two databases.
"timfox" wrote : If you are using persistent messages then the JMS system can guarantee persistence for you.
I am confused about this. I believe that JMS persists messages only to guarantee delivery in case the target system is down or not operating correctly. You do not expect me to look at persisted JMS messages as the system of record for my orders, do you? For me these are just text messages on a queue, not first class objects that can be associated with other objects in my database. Moreover, at least conceptually I think of persisted JMS messages to be deleted when the message has been consumed and acknowledged. So they are not a permanent record of my business transactions. Am I missing something?
Given these requirements, I know that I will need x milliseconds to store orders in my databases. All I am trying to do now is to make sure that JMS is minimum overhead on my system, which is a completely orthogonal issue. As I said earlier, I am prepared to embrace all the best practices on the JMS side to improve performance as long as I have reliable and performant messaging. I can punt MDBs, JTA, JCA - whatever you say as long as I have a decent alternative. So if you want me to reuse connections, sessions, consumers, producers, tell me how: write my own, use something provided by JBM, or pick something like Spring JMS template (with some connection pooling) and their MDP container!
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244399#4244399
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244399
17 years
[Persistence, JBoss/CMP, Hibernate, Database] - jboss 4.2.x - connection pooling
by Web
I have a question related to Prepared Steatement pooling (across all connections). Here's the config file
<local-tx-datasource>
<jndi-name>JNDI-NAME</jndi-name>
<connection-url>jdbc:mysql://<server_name>/<database_name>?useServerPrepStmts=true</connection-url>
<driver-class>com.mysql.jdbc.Driver</driver-class>
<user-name>xxx</user-name>
xxxxx
<min-pool-size>10</min-pool-size>
<max-pool-size>20</max-pool-size>
<idle-timeout-minutes>20</idle-timeout-minutes>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
<valid-connection-checker-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLValidConnectionChecker</valid-connection-checker-class-name>
<background-validation>true</background-validation>
<background-validation-minutes>5</background-validation-minutes>
<prepared-statement-cache-size>100</prepared-statement-cache-size>
<share-prepared-statements>true</share-prepared-statements>
<!-- sql to call when connection is created
<new-connection-sql>some arbitrary sql</new-connection-sql>
-->
<!-- sql to call on an existing pooled connection when it is obtained from pool - MySQLValidConnectionChecker is preferred for newer drivers
<check-valid-connection-sql>some arbitrary sql</check-valid-connection-sql>
-->
<!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml -->
<type-mapping>mySQL</type-mapping>
</local-tx-datasource>
It seems that this line:
<background-validation-minutes>5</background-validation-minutes>
doesn't cause any problems with Prepared Statements, but:
<idle-timeout-minutes>20</idle-timeout-minutes>
causes that all connections are removed and re-created if there was no traffic for the last 20 minutes. Because of that existing Prepared Statements are removed from the pool of cached Prepared Statements. How to overcome this issue? I have to use idle-timeout-minutes because MySQL server closes the connection after 8h
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244394#4244394
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4244394
17 years