5:12 a.m.
I'm working on a messaging issue[1] where an user can not deserialize a JMS
ObjectMessage that contains an org.w3c.dom.Document
object (an instance of org.apache.xerces.dom.DocumentImpl loaded from module
"org.apache.xerces:main").
HornetQ is not able to deserialize the document object and fails with a CNFE:
java.lang.ClassNotFoundException: org.apache.xerces.dom.DocumentImpl from [Module
"org.hornetq:main" from local module
loader @23aa0933 (roots:
/home/jmesnil/Developer/jboss-as/testsuite/integration/smoke/../../../build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
Doing some debugging, it appears that HornetQ is not able to find the class in the TCCL
(it then tries to resolve it with its
own classloader, hence the exception above)
Trying to understand the root cause, I have a simple test[2] that creates a DOM document
inside a Servlet, serialize it and
unserialize it.
The test fails when I deserialize it with a CNFE from the TCCL:
java.lang.ClassNotFoundException: org.apache.xerces.dom.DocumentImpl from [Module
"deployment.objectmessage.ear.objectmessage.war:main" from Service Module
Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at java.lang.Class.forName0(Native Method)
I was expecting this test to succeed. Is there a reason why I could not deserialize a
class in the same context that I have
serialized it?
Thanks,
jeff
[1] https://issues.jboss.org/browse/AS7-1271
[2]
https://github.com/jmesnil/jboss-as/blob/AS7-1271_ObjectMessage_Classload...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
5:23 a.m.
On 07/26/2012 12:12 PM, Jeff Mesnil wrote:
I was expecting this test to succeed. Is there a reason why I could
not deserialize a class in the same context that I have
serialized it?
sent too fast...
I can see the issue only with Document instances.
There are some magic with the XML APIs that I don't understand (e.g. the __redirect
package of jboss-modules) and the user had
to explicitly export the org.apache.xerces module in its EAR to workaround this issue.
However, I don't see why this should not work straight out of the box.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
9:06 a.m.
On 7/26/12 5:23 AM, Jeff Mesnil wrote:
On 07/26/2012 12:12 PM, Jeff Mesnil wrote:
> I was expecting this test to succeed. Is there a reason why I could not deserialize a
class in the same context that I have
> serialized it?
sent too fast...
I can see the issue only with Document instances.
There are some magic with the XML APIs that I don't understand (e.g. the __redirect
package of jboss-modules) and the user had
to explicitly export the org.apache.xerces module in its EAR to workaround this issue.
However, I don't see why this should not work straight out of the box.
This is problem C:
https://community.jboss.org/wiki/ModularSerialization
The user typically imports the JAXP api, but not the implementation (a
key part of the encapsulation/isolation principle in modularity). If you
use serialization directly yourself, serialization expects everything to
be on one big flat classpath in your classloader. The solutions in the
above doc apply.
You can either:
1. Import the implementation you are deserializing, placing it on the
"classpath" of the module (e.g. xerces)
2. Don't serialize Document and instead serialize something in your
shared structure. For example, you could write the xml content to the
stream, or you could create a DTO that contains the values your app needs.
3. Use modular serialization via jboss marshalling
Most of our frameworks use modular serialization. So if you for example
stick a Document on a SFSB, when it replicates to other servers
(clustering) it tags every class in the serialization stream with the
module it came from (in this case the implementation classes, xerces,
would include the org.apache.xerces marker). EJB remote coms do the
same, however if the client isn't modular, a pure SE client not running
on jboss modules, then they have to have xerces in their classpath (as
they would normally have to do talking to any other server).
Now regarding https://issues.jboss.org/browse/AS7-1271, if hornetq were
to implement modular serialization it would resolve the issue without
the user needing to make changes like 1 and 2. The problem is of course
getting the protocol compatibility right, but it's not insurmountable.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
11:20 a.m.
On 07/26/2012 04:06 PM, Jason T. Greene wrote:
On 7/26/12 5:23 AM, Jeff Mesnil wrote:
> On 07/26/2012 12:12 PM, Jeff Mesnil wrote:
>> I was expecting this test to succeed. Is there a reason why I could not
deserialize a class in the same context that I have
>> serialized it?
>
> sent too fast...
>
> I can see the issue only with Document instances.
>
> There are some magic with the XML APIs that I don't understand (e.g. the
__redirect package of jboss-modules) and the user had
> to explicitly export the org.apache.xerces module in its EAR to workaround this
issue.
> However, I don't see why this should not work straight out of the box.
This is problem C:
https://community.jboss.org/wiki/ModularSerialization
The user typically imports the JAXP api, but not the implementation (a key part of the
encapsulation/isolation principle in
modularity). If you use serialization directly yourself, serialization expects everything
to be on one big flat classpath in
your classloader. The solutions in the above doc apply.
You can either:
1. Import the implementation you are deserializing, placing it on the
"classpath" of the module (e.g. xerces)
2. Don't serialize Document and instead serialize something in your shared structure.
For example, you could write the xml
content to the stream, or you could create a DTO that contains the values your app needs.
+1. The real solution is to get rid of ObjectMessage. This was a bad idea to let
developers use Java objects as the
representation for messaging payload (imho, only byte[] and UTF-8 string should have been
supported)
I'll have to lobby clebert to get ObjectMessage deprecated in JMS 2.0 :)
Now regarding https://issues.jboss.org/browse/AS7-1271, if hornetq
were to implement modular serialization it would resolve the
issue without the user needing to make changes like 1 and 2. The problem is of course
getting the protocol compatibility right,
but it's not insurmountable.
Thanks for the info jason, I'll think about a way to achieve this.
TBH, this is a complex undertaking to change this in HornetQ for use cases that can easily
be worked around by proper
application design and user education.
jeff
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/
9:57 a.m.
On 7/26/12 11:20 AM, Jeff Mesnil wrote:
On 07/26/2012 04:06 PM, Jason T. Greene wrote:
> On 7/26/12 5:23 AM, Jeff Mesnil wrote:
>> On 07/26/2012 12:12 PM, Jeff Mesnil wrote:
>>> I was expecting this test to succeed. Is there a reason why I could
>>> not deserialize a class in the same context that I have
>>> serialized it?
>>
>> sent too fast...
>>
>> I can see the issue only with Document instances.
>>
>> There are some magic with the XML APIs that I don't understand (e.g.
>> the __redirect package of jboss-modules) and the user had
>> to explicitly export the org.apache.xerces module in its EAR to
>> workaround this issue.
>> However, I don't see why this should not work straight out of the box.
>
> This is problem C:
> https://community.jboss.org/wiki/ModularSerialization
>
> The user typically imports the JAXP api, but not the implementation (a
> key part of the encapsulation/isolation principle in
> modularity). If you use serialization directly yourself, serialization
> expects everything to be on one big flat classpath in
> your classloader. The solutions in the above doc apply.
>
> You can either:
>
> 1. Import the implementation you are deserializing, placing it on the
> "classpath" of the module (e.g. xerces)
> 2. Don't serialize Document and instead serialize something in your
> shared structure. For example, you could write the xml
> content to the stream, or you could create a DTO that contains the
> values your app needs.
+1. The real solution is to get rid of ObjectMessage. This was a bad
idea to let developers use Java objects as the representation for
messaging payload (imho, only byte[] and UTF-8 string should have been
supported)
I'll have to lobby clebert to get ObjectMessage deprecated in JMS 2.0 :)
> Now regarding https://issues.jboss.org/browse/AS7-1271, if hornetq
> were to implement modular serialization it would resolve the
> issue without the user needing to make changes like 1 and 2. The
> problem is of course getting the protocol compatibility right,
> but it's not insurmountable.
Thanks for the info jason, I'll think about a way to achieve this.
TBH, this is a complex undertaking to change this in HornetQ for use
cases that can easily be worked around by proper application design and
user education.
Yeah it might be better to wait until a later protocol refactoring vs
extending whats there.
That said if you wanted to implement it sooner one way to handle
compatibility is you could introduce a HornetQModularObjectMessage. That
could serialize in modular form, and on deserialization follow it unless
you are in an non-modular client where it would just ignore the module
ids. There would have to be a configuration value somehwere to enable
it, so you can turn it off to be compatible with older peers.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
4532
days inactive
4533
days old
4 comments
2 participants
participants (2)
-
Jason T. Greene -
Jeff Mesnil