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

[Dmitry Samersoff]

Shanliang,

Thank you for gnarly details.

On 2013-07-03 13:12, shanliang wrote:
> 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.

I'm working with JCK team to have it cleaned up.

-Dmitry

> 
> 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.
>>>>>
>>>>>   
>>>>>         
>>>>       
>>
>>
>>   
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.