commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] Re: svn commit: r1078734
Date Wed, 09 Mar 2011 20:43:35 GMT
Le 09/03/2011 16:55, Jörg Schaible a écrit :
> Hi Gilles,
> Gilles Sadowski wrote:
>> On Wed, Mar 09, 2011 at 03:00:07PM +0100, Luc Maisonobe wrote:
>>> Le 09/03/2011 13:59, Gilles Sadowski a écrit :
>>>> Hi.
>>>>>>> [...]
>>>>>>> Or make the fields transient?
>>>>>>> That would perhaps cause problems if the Exceptions were ever
>>>>>>> serialised, but can that happen?
>>>>>> Yes, it's a typical JEE scenario and I cannot say how often I cursed
>>>>>> Sun for stuffing an unserializable object into
>>>>>> NamingException.setResolvedObject within their LDAP implementation
>>>>>> ...
>>>>>> Actually the MathRE should contain a writeObject implementation that
>>>>>> replaces any non-serializable object in that array with some kind
>>>>>> replacement (e.g. with its String representation). Otherwise the
>>>>>> MathRE will not reach its destination and all the localization was
>>>>>> for nothing.
>>>>> That's a good idea. We could even do that replacement directly at
>>>>> construction and never store the Object themselves, regardless of
>>>>> their status with respect to serialization.
>>>> Do you mean storing only the String representation of the arguments?
>>>> Wouldn't that defeat the purpose of the map feature (which was to allow
>>>> any kind of objects to be stored and retrieved)?
>>> You are right, I am stupid. So we have to check for serializable.
>> I don't see why: The serialization will work provided all "Object"
>> arguments are "Serializable"; it is the user's code responsibility to not
>> try serializing the exception when it knows that it contains a
>> non-serializable object.
>> If the exceptions generated from CM contain only serializable objects
>> (which is the case now), then we've done our part.
> Yes, but it might not be always directly obvious. It's always annoying, if 
> in a client/server scenario an error occurs and suddenly cannot even 
> reported to the client. That's why I proposed the customized 
> writeObject/readObject for MathRE. The thrown exception should make it under 
> any circumstances over the wire, even if it means that unserializable 
> objects are nulled or replaced with a String representation. Otherwise the 
> client simply gets an error and no-one can tell why. However, this is an 
> action only for the serialization process. Or ensure - as already proposed 
> in this thread - that only serializable types can be added by using an 
> appropriate method/type signature.

Since in this case a complete roundtrip serialization/deserialization
occurs, I think we should convert to null non-serializable objects at
the serialization step as you propose.


> - Jörg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message