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

[Jeff Mesnil]

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/