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

[Jason T. Greene]

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