Skip to main content

Please review fix for [ISSUE #304]

4 replies [Last post]
Anonymous

Hi Vladimir,

please review fix for [ISSUE #304]: REGRESSION: OTA tests started failing with
updated OTASupportServer:

http://fisheye4.atlassian.com/changelog/cqme/?cs=1711

Thanks,
Alexander

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Vladimir Sizikov

Hi Alexander,

The more I look at the code and think about it, the more it seems to me
that this is not a bug at all.

I don't really understand why users expect getStatus() to return anyning
useful after resetRunNotification() is invoked.

The javadoc for resetRunNotification() clearly states that:
"Resets the run notification state to the default value, as if *there*
*were* *no* *run* *notifications*".

And so, if there were no run notificanions, getStatus() should return
failed status.

Am I missing something?

With the proposed code change, getStatus() could return ressults from
old run notification, even though one might explicitly reset the
notifications via resetRunNotification(), which seems to be wrong to me.

Thanks,
--Vladimir

On 11/13/2009 9:30 AM, Alexander Alexeev wrote:
> Hi Vladimir,
>
> please review fix for [ISSUE #304]: REGRESSION: OTA tests started
> failing with
> updated OTASupportServer:
>
> http://fisheye4.atlassian.com/changelog/cqme/?cs=1711
>
> Thanks,
> Alexander
>
[vladimir_sizikov.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Vladimir,

this is really not trivial situation. The tests those expect getStatus()
after resetRunNotification were written before the Javadoc and semantic
of the method resetRunNotification() were changed. And these tests were
really correct at their time. They install and run one midlet and then
install another midlet (not run! just install, but with modern code the
status is null after that). In order to pass to the Javatest's side
information from midlet's run they return getStatus() at the end of the
test. So the issue is really regression.

resetRunNotification() method was changed during the fixing bug 6357305:
"OTASupportServer never drop the result of MIDlet run". The problem was
waitForStatus(testCaseId) will return immediately when status was
already received one time in the same test case. Since I was unable
to find in our TCK's test that uses the fix, my first idea was just to
restore old code with old Javadoc but after some thoughts I fixed the
code as under review. With this code both type of tests will work. May
be some more explanations should be added to the Javadoc. What do you
think?

Thanks,
Alexander

Vladimir Sizikov wrote:
> Hi Alexander,
>
> The more I look at the code and think about it, the more it seems to me
> that this is not a bug at all.
>
> I don't really understand why users expect getStatus() to return anyning
> useful after resetRunNotification() is invoked.
>
> The javadoc for resetRunNotification() clearly states that:
> "Resets the run notification state to the default value, as if *there*
> *were* *no* *run* *notifications*".
>
> And so, if there were no run notificanions, getStatus() should return
> failed status.
>
> Am I missing something?
>
> With the proposed code change, getStatus() could return ressults from
> old run notification, even though one might explicitly reset the
> notifications via resetRunNotification(), which seems to be wrong to me.
>
> Thanks,
> --Vladimir
>
> On 11/13/2009 9:30 AM, Alexander Alexeev wrote:
>> Hi Vladimir,
>>
>> please review fix for [ISSUE #304]: REGRESSION: OTA tests started
>> failing with
>> updated OTASupportServer:
>>
>> http://fisheye4.atlassian.com/changelog/cqme/?cs=1711
>>
>> Thanks,
>> Alexander
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Vladimir Sizikov

Hi Alexander, folks,

Quick status update on this issue. We discussed it at length and it
seems that the behavior should stay as it is now, no change needed.

Only one test has been affected by current behavior, and it is already
fixed in the TCK update release, so no need to complicate things here.

Alexander, could you please update the bug info with the results of our
discussions and close the bug?

Thanks,
--Vladimir

On 11/16/2009 9:48 AM, Alexander Alexeev wrote:
> Hi Vladimir,
>
> this is really not trivial situation. The tests those expect getStatus()
> after resetRunNotification were written before the Javadoc and semantic
> of the method resetRunNotification() were changed. And these tests were
> really correct at their time. They install and run one midlet and then
> install another midlet (not run! just install, but with modern code the
> status is null after that). In order to pass to the Javatest's side
> information from midlet's run they return getStatus() at the end of the
> test. So the issue is really regression.
>
> resetRunNotification() method was changed during the fixing bug 6357305:
> "OTASupportServer never drop the result of MIDlet run". The problem was
> waitForStatus(testCaseId) will return immediately when status was
> already received one time in the same test case. Since I was unable
> to find in our TCK's test that uses the fix, my first idea was just to
> restore old code with old Javadoc but after some thoughts I fixed the
> code as under review. With this code both type of tests will work. May
> be some more explanations should be added to the Javadoc. What do you
> think?
>
> Thanks,
> Alexander
>
> Vladimir Sizikov wrote:
>> Hi Alexander,
>>
>> The more I look at the code and think about it, the more it seems to
>> me that this is not a bug at all.
>>
>> I don't really understand why users expect getStatus() to return
>> anyning useful after resetRunNotification() is invoked.
>>
>> The javadoc for resetRunNotification() clearly states that:
>> "Resets the run notification state to the default value, as if *there*
>> *were* *no* *run* *notifications*".
>>
>> And so, if there were no run notificanions, getStatus() should return
>> failed status.
>>
>> Am I missing something?
>>
>> With the proposed code change, getStatus() could return ressults from
>> old run notification, even though one might explicitly reset the
>> notifications via resetRunNotification(), which seems to be wrong to me.
>>
>> Thanks,
>> --Vladimir
>>
>> On 11/13/2009 9:30 AM, Alexander Alexeev wrote:
>>> Hi Vladimir,
>>>
>>> please review fix for [ISSUE #304]: REGRESSION: OTA tests started
>>> failing with
>>> updated OTASupportServer:
>>>
>>> http://fisheye4.atlassian.com/changelog/cqme/?cs=1711
>>>
>>> Thanks,
>>> Alexander
>>>
>
[vladimir_sizikov.vcf]
---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net

Alexander Alexeev

Hi Vladimir,

done!: https://cqme.dev.java.net/issues/show_bug.cgi?id=304

Thanks,
Alexander

Vladimir Sizikov wrote:
> Hi Alexander, folks,
>
> Quick status update on this issue. We discussed it at length and it
> seems that the behavior should stay as it is now, no change needed.
>
> Only one test has been affected by current behavior, and it is already
> fixed in the TCK update release, so no need to complicate things here.
>
> Alexander, could you please update the bug info with the results of our
> discussions and close the bug?
>
> Thanks,
> --Vladimir
>
>
> On 11/16/2009 9:48 AM, Alexander Alexeev wrote:
>> Hi Vladimir,
>>
>> this is really not trivial situation. The tests those expect getStatus()
>> after resetRunNotification were written before the Javadoc and semantic
>> of the method resetRunNotification() were changed. And these tests were
>> really correct at their time. They install and run one midlet and then
>> install another midlet (not run! just install, but with modern code the
>> status is null after that). In order to pass to the Javatest's side
>> information from midlet's run they return getStatus() at the end of the
>> test. So the issue is really regression.
>>
>> resetRunNotification() method was changed during the fixing bug 6357305:
>> "OTASupportServer never drop the result of MIDlet run". The problem was
>> waitForStatus(testCaseId) will return immediately when status was
>> already received one time in the same test case. Since I was unable
>> to find in our TCK's test that uses the fix, my first idea was just to
>> restore old code with old Javadoc but after some thoughts I fixed the
>> code as under review. With this code both type of tests will work. May
>> be some more explanations should be added to the Javadoc. What do you
>> think?
>>
>> Thanks,
>> Alexander
>>
>> Vladimir Sizikov wrote:
>>> Hi Alexander,
>>>
>>> The more I look at the code and think about it, the more it seems to
>>> me that this is not a bug at all.
>>>
>>> I don't really understand why users expect getStatus() to return
>>> anyning useful after resetRunNotification() is invoked.
>>>
>>> The javadoc for resetRunNotification() clearly states that:
>>> "Resets the run notification state to the default value, as if
>>> *there* *were* *no* *run* *notifications*".
>>>
>>> And so, if there were no run notificanions, getStatus() should return
>>> failed status.
>>>
>>> Am I missing something?
>>>
>>> With the proposed code change, getStatus() could return ressults from
>>> old run notification, even though one might explicitly reset the
>>> notifications via resetRunNotification(), which seems to be wrong to me.
>>>
>>> Thanks,
>>> --Vladimir
>>>
>>> On 11/13/2009 9:30 AM, Alexander Alexeev wrote:
>>>> Hi Vladimir,
>>>>
>>>> please review fix for [ISSUE #304]: REGRESSION: OTA tests started
>>>> failing with
>>>> updated OTASupportServer:
>>>>
>>>> http://fisheye4.atlassian.com/changelog/cqme/?cs=1711
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
For additional commands, e-mail: meframework-help@cqme.dev.java.net