Re: [jboss-as7-dev] JBoss Modules & object serialization

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.