5:16 a.m.
[
https://issues.jboss.org/browse/AS7-1271?page=com.atlassian.jira.plugin.s...
]
Rasto Cesnek edited comment on AS7-1271 at 7/25/12 6:14 AM:
------------------------------------------------------------
Hi Jeff.
The Xerces (2.9.1-XYZ.jar) here comes directly from JBoss 7.1.1 modules. The EAR, EJB nor
the WAR bundles any Xerces implementation.
The servlet creates a Document object using DocumentBuilderFactory.DocumentBuilder (this
then gets sent to the MDB using the other bean in the EJB module.
What is strange though, other code in the EJB module also creates Document instances using
DocumentBuilderFactoy.DocumentBuilder without problems, so the EJB module has Xerces
available on class path (implicitly added as dependency).
I tried fixing this issue with explicit dependency in EAR/MANIFEST-MF:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="org.apache.xerces" export="true" />
</dependencies>
...
this does the trick.
What I still do not understand though is, why can I create instances of the Document in
the EJB module but I cannot deserialize an existing one. It is sort of contra-intuitive
for me. Either the module has the class on class-path or does not have it. I will have a
look to the link you provided to see if it explains the issue.
was (Author: erce):
Hi Jeff.
The Xerces (2.9.1-XYZ.jar) here comes directly from JBoss 7.1.1 modules. The EAR, EJB nor
the WAR bundles any Xerces implementation.
The servlet creates a Document object using DocumentBuilderFactory.DocumentBuilder (this
then gets sent to the MDB using the other bean in the EJB module.
What is strange though, other code in the EJB module also creates Document instances using
DocumentBuilderFactoy.DocumentBuilder without problems, so the EJB module has Xerces
available on class path (implicitly added as dependency).
I tried fixing this issue with explicit dependency in EAR/MANIFEST-MF:
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.1">
<ear-subdeployments-isolated>false</ear-subdeployments-isolated>
<deployment>
<dependencies>
<module name="org.apache.xerces" export="true" />
</dependencies>
...
this does the trick.
What I still do not understand though is, why can I create instances of the Document in
the EJB module but I cannot deserialize an existing one. It is sort of contra-intuitive I
will have a look to the link you provided to see if it explains the issue.
Fired object messages violate classloaders
------------------------------------------
Key: AS7-1271
URL: https://issues.jboss.org/browse/AS7-1271
Project: Application Server 7
Issue Type: Bug
Components: JMS
Reporter: John Ament
Assignee: Jeff Mesnil
Fix For: 7.2.0.Alpha1
JMS allows you to fire an object message. In this case, I have a object of type in my
deployment. It fires fine. I bind a message consumer to a queue in AS7. the object
message coming in results in a classloader violation:
22:13:35,116 ERROR
[org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB] (Thread-2
(group:HornetQ-client-global-threads-767046602))
org.jboss.seam.jms.example.statuswatcher.model.Status from [Module
"org.hornetq:main" from local module loader @19d009b4 (roots:
/apps/jboss-as-7.0.0.Final/modules)]: javax.jms.JMSException:
org.jboss.seam.jms.example.statuswatcher.model.Status from [Module
"org.hornetq:main" from local module loader @19d009b4 (roots:
/apps/jboss-as-7.0.0.Final/modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:358)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:330)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:307)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:101)
at java.lang.Class.forName0(Native Method) [:1.6.0_22]
at java.lang.Class.forName(Class.java:247) [:1.6.0_22]
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_22]
at
org.hornetq.utils.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:69)
[hornetq-core-2.2.6.Final.jar:]
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_22]
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_22]
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
[:1.6.0_22]
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_22]
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_22]
at org.hornetq.jms.client.HornetQObjectMessage.getObject(HornetQObjectMessage.java:158)
[hornetq-jms-2.2.6.Final.jar:]
at
org.jboss.seam.jms.example.statuswatcher.messagedriven.DistributorMDB.onMessage(DistributorMDB.java:46)
at
org.hornetq.jms.client.JMSMessageListenerWrapper.onMessage(JMSMessageListenerWrapper.java:91)
[hornetq-jms-2.2.6.Final.jar:]
at
org.hornetq.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:866)
[hornetq-core-2.2.6.Final.jar:]
at
org.hornetq.core.client.impl.ClientConsumerImpl.access$100(ClientConsumerImpl.java:44)
[hornetq-core-2.2.6.Final.jar:]
at
org.hornetq.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:983)
[hornetq-core-2.2.6.Final.jar:]
at
org.hornetq.utils.OrderedExecutorFactory$OrderedExecutor$1.run(OrderedExecutorFactory.java:100)
[hornetq-core-2.2.6.Final.jar:]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[:1.6.0_22]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[:1.6.0_22]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_22]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira