RR(S): 8011038 sourceObj validation during desereliazation of RelationNotification should be relaxed

[shanliang]

According to the spec, source should not be null and should be a 
validated type, and as the spec says:
    "the MBean Server will rewrite the source to be the ObjectName under 
which that MBean is registered." in case the source is a RelationService 
object

this means that the MBean Server might get a NPE when treating the 
source, or a user will get NPE, so it is definitively a bug to set the 
source null.

I am OK if you prefer to fix JCP break at first, then to fix non-null 
issue in setSource and readObject, but I am afraid that fixing non-null 
issue would break JCK again, not sure.

Shanliang

Dmitry Samersoff wrote:
> Shanlinag,
>
> The main goal of this fix - is preserve a compatibility in cross-version
> environment upon request of JCK team.
>
> i.e. it's possible to create an RelationNotification instance using
> early version of JDK, set sourceObj to null, serialize it and give this
> serialized object to latest update with the validation.
>
> So we can't refuse such serialized stream and as soon as null
> sourceObject can't cause any harm I decided to relax a
> valiadation during *desereliazion*.
>
> Constructor is not affected - it still throws IAE if sourceObj is null,
> as it happens today and described in javadoc.
>
> I'm not sure whether it make sense to change setSource as well to
> prevent setting sourceObject to null in the future - probably yes, but
> compatibility impact of these changes have to be evaluated separately
> and it's clearly out of scope of this CR.
>
> -Dmitry
>
>
>
> On 2013-07-03 11:00, shanliang wrote:
>   
>> After reading again the constructor Javadoc:
>>
>> "sourceObj - source object, sending the notification. This is either an
>> ObjectName or a RelationService object. In the latter case it must be
>> the MBean emitting the notification; the MBean Server will rewrite the
>> source to be the ObjectName under which that MBean is registered."
>>
>> In this case, should we override instead the method "setSource" to
>> refuse a null value and do the necessary check? like
>>    setSource(Object source) {
>>       if (!(sourceObj instanceof RelationService) &&
>>             !(sourceObj instanceof ObjectName))) {
>>            throw new IllegalArgumentException();
>>       }
>>    }
>>   Shanliang
>>
>> shanliang wrote:
>>     
>>> The constructor Javadoc says: "Throws IllegalArgumentException if no
>>> source object", we have to modify the spec if the implementation is
>>> changed.
>>>
>>> Shanliang
>>>
>>> Dmitry Samersoff wrote:
>>>       
>>>> Hi Everybody,
>>>>
>>>> *problem*
>>>>
>>>> Despite the fact, that validation in constructor of RelationNotification
>>>> prohibit creation of the class instance with null sourceObj its possible
>>>> to set it to null later by public setSource() method. So we should relax
>>>> validation rules to preserve serialization behavior compatibility.
>>>>
>>>> *webrev*
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/8011038/webrev.01/
>>>>
>>>> *testing*
>>>>
>>>> JCK, no separate regression tests required.
>>>>
>>>>   
>>>>         
>>>       
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20130703/a1309c48/attachment.html