Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4D77E677.1040303@free.fr>
Date: Wed, 09 Mar 2011 21:43:35 +0100
From: Luc Maisonobe <Luc.Maisonobe@free.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [math] Re: svn commit: r1078734
References: <20110307103754.1331923889EB@eris.apache.org>
 <4D768EE6.6050707@free.fr>
 <AANLkTinFGsbWmCfoVhgod+6T9XOaF998GnQbtaV_Wdz9@mail.gmail.com>
 <il6btu$ute$1@dough.gmane.org> <4D773ED3.1020607@free.fr>
 <20110309125903.GR22814@dusk.harfang.homelinux.org>
 <4D7787E7.4070307@free.fr>
 <20110309152515.GS22814@dusk.harfang.homelinux.org>
 <il87tb$4uf$1@dough.gmane.org>
In-Reply-To: <il87tb$4uf$1@dough.gmane.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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