commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
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
of
>>>>>> 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.

Luc

> 
> - Jörg
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message