Skip to main content

Please review fix for 6519720: J2meBaseTestSuite does not work withot own interview

5 replies [Last post]
Anonymous

Hi Vladimir,

please review fix by following URL:
http://fisheye4.cenqua.com/changelog/~author=skavas/cqme/branches/users/...

Now simple test suite can use J2meBaseTestSuite directly without
overriding interview or test suite.
As was discussed we definitely need the simple way to tune interview for
concrete test suite. For example in this update it's rather easy to
enable/disable distributed tests in the test suite but it's really hard
to disable some modes (CLDC or CDC for example). To do so you need to
create your own high level interview and create subinterview with tuned
functionality. We should carefully identify places where different test
suites needs different options but I think it's out of scope of this
bug. I propose to submit an separate Enhancement to track this.

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,

I have a question for you. :)

You've changed MidpTckBaseInterview constructor so that the
distributed mode is enabled by default:

http://fisheye4.cenqua.com/browse/cqme/branches/users/skavas/testsuite/s...

Isn't this an incompatible change that would cause problems with other
TCKs, like MSA TCK or MMAPI TCK? These TCKs do not need distributed
test support and use the two-parameter MidpTckBaseInterview
constructor and expect that the constructor will create an interview
with distributed tests support disabled.

Maybe I misunderstood something in your changes?

Thanks,
--Vladimir

On Wed, Mar 14, 2007 at 09:43:03AM +0300, Alexander Alexeev wrote:
> Hi Vladimir,
>
> please review fix by following URL:
> http://fisheye4.cenqua.com/changelog/~author=skavas/cqme/branches/users/...
>
> Now simple test suite can use J2meBaseTestSuite directly without
> overriding interview or test suite.
> As was discussed we definitely need the simple way to tune interview for
> concrete test suite. For example in this update it's rather easy to
> enable/disable distributed tests in the test suite but it's really hard
> to disable some modes (CLDC or CDC for example). To do so you need to
> create your own high level interview and create subinterview with tuned
> functionality. We should carefully identify places where different test
> suites needs different options but I think it's out of scope of this
> bug. I propose to submit an separate Enhancement to track this.
>
> Thanks,
> Alexander
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

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

good question and you are right - now such TCKs have "Communication Server port"
question in the interview and export comm service values in the environment. But
we definitely need to do something with existent inconsistency when test suite
is created with distributed support by default and interview is created
non-distributed. I think redundant question in the old TCKs interviews is a
small price for the correction.

Thanks,
Alexander

Vladimir Sizikov wrote:
> Hi Alexander,
>
> I have a question for you. :)
>
> You've changed MidpTckBaseInterview constructor so that the
> distributed mode is enabled by default:
>
> http://fisheye4.cenqua.com/browse/cqme/branches/users/skavas/testsuite/s...
>
> Isn't this an incompatible change that would cause problems with other
> TCKs, like MSA TCK or MMAPI TCK? These TCKs do not need distributed
> test support and use the two-parameter MidpTckBaseInterview
> constructor and expect that the constructor will create an interview
> with distributed tests support disabled.
>
> Maybe I misunderstood something in your changes?
>
> Thanks,
> --Vladimir
>
> On Wed, Mar 14, 2007 at 09:43:03AM +0300, Alexander Alexeev wrote:
>> Hi Vladimir,
>>
>> please review fix by following URL:
>> http://fisheye4.cenqua.com/changelog/~author=skavas/cqme/branches/users/...
>>
>> Now simple test suite can use J2meBaseTestSuite directly without
>> overriding interview or test suite.
>> As was discussed we definitely need the simple way to tune interview for
>> concrete test suite. For example in this update it's rather easy to
>> enable/disable distributed tests in the test suite but it's really hard
>> to disable some modes (CLDC or CDC for example). To do so you need to
>> create your own high level interview and create subinterview with tuned
>> functionality. We should carefully identify places where different test
>> suites needs different options but I think it's out of scope of this
>> bug. I propose to submit an separate Enhancement to track this.
>>
>> Thanks,
>> Alexander
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

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

Vladimir Sizikov

Alexander,

On Wed, Mar 14, 2007 at 03:24:38PM +0300, Alexander Alexeev wrote:
> good question and you are right - now such TCKs have "Communication
> Server port" question in the interview and export comm service
> values in the environment. But we definitely need to do something
> with existent inconsistency when test suite is created with
> distributed support by default and interview is created
> non-distributed. I think redundant question in the old TCKs
> interviews is a small price for the correction.

Hmmm, this doesn't sound good. DTF-enabled interviews can have more
then just one extra question. Sooner or later we'll add debuging
support question, maybe something else. Leaving thes issue not fixed
will just push the resolution to some further time, and decrease the
ME Framework Interview's usability.

Is there a way to solve both problems, and to have consitent test
suite and interviews, and preserve the backward compatiblity?

How about a new parameter in the jtt file?
"dtf.enabled = true", for example.

Thanks,
--Vladimir

> Vladimir Sizikov wrote:
> >Hi Alexander,
> >
> >I have a question for you. :)
> >
> >You've changed MidpTckBaseInterview constructor so that the
> >distributed mode is enabled by default:
> >
> >http://fisheye4.cenqua.com/browse/cqme/branches/users/skavas/testsuite/src/share/classes/com/sun/tck/j2me/interview/MidpTckBaseInterview.java?r=452#l77
> >
> >Isn't this an incompatible change that would cause problems with other
> >TCKs, like MSA TCK or MMAPI TCK? These TCKs do not need distributed
> >test support and use the two-parameter MidpTckBaseInterview
> >constructor and expect that the constructor will create an interview
> >with distributed tests support disabled.
> >
> >Maybe I misunderstood something in your changes?
> >
> >Thanks,
> > --Vladimir
> >
> >On Wed, Mar 14, 2007 at 09:43:03AM +0300, Alexander Alexeev wrote:
> >>Hi Vladimir,
> >>
> >>please review fix by following URL:
> >>http://fisheye4.cenqua.com/changelog/~author=skavas/cqme/branches/users/skavas/testsuite?cs=452
> >>
> >>Now simple test suite can use J2meBaseTestSuite directly without
> >>overriding interview or test suite.
> >>As was discussed we definitely need the simple way to tune interview for
> >>concrete test suite. For example in this update it's rather easy to
> >>enable/disable distributed tests in the test suite but it's really hard
> >>to disable some modes (CLDC or CDC for example). To do so you need to
> >>create your own high level interview and create subinterview with tuned
> >>functionality. We should carefully identify places where different test
> >>suites needs different options but I think it's out of scope of this
> >>bug. I propose to submit an separate Enhancement to track this.
> >>
> >>Thanks,
> >>Alexander
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >>For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >
>

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

Alexander Alexeev

Vladimir,

I like the idea about property. But unfortunately I don't see how it solves
inconsistent between suite and interview. For simplest case (lack of the
property in the jtt file) we need to allow distributed tests in the test suite
(old TCKs relay on this behavior) and in the same time we need to disable
distributed mode in the interview.

The problem is that test suite and interview should be synchronized in the
enabling/disabling distributed tests but in the same time we strive for reduce
dependencies between suite and interview and bring them to environment.
Seemingly interview should provide information to environment about enabling
distributed tests and take this information by itself (not through constructor
called from test suite). But logically such information belongs to test suite
but not interview. So as I see we need at least one dependency of interview from
test suite. May be it possible to make shouldEnableDistrTests() public and use
it to determine interview behavior? Or create special class with test suite
specific information and use it for customize interview?

Back to the compatibility - I've reverted changes in the constructor of
MidpTckBaseInterview. It solves problems with legacy TCKs with minimal
inconsistency. But I found latest WebService TCKs and MMAPI TCK use three
argument constructor with distributed flag set to true! So we will have problems
described by you with them.

P.S. The best behavior for the simple test suite will be disable distributed
mode by default but unfortunately it's incompatible with existent TCKs at all :-(

Thanks,
Alexander

Vladimir Sizikov wrote:
> Alexander,
>
> On Wed, Mar 14, 2007 at 03:24:38PM +0300, Alexander Alexeev wrote:
>> good question and you are right - now such TCKs have "Communication
>> Server port" question in the interview and export comm service
>> values in the environment. But we definitely need to do something
>> with existent inconsistency when test suite is created with
>> distributed support by default and interview is created
>> non-distributed. I think redundant question in the old TCKs
>> interviews is a small price for the correction.
>
> Hmmm, this doesn't sound good. DTF-enabled interviews can have more
> then just one extra question. Sooner or later we'll add debuging
> support question, maybe something else. Leaving thes issue not fixed
> will just push the resolution to some further time, and decrease the
> ME Framework Interview's usability.
>
> Is there a way to solve both problems, and to have consitent test
> suite and interviews, and preserve the backward compatiblity?
>
> How about a new parameter in the jtt file?
> "dtf.enabled = true", for example.
>
> Thanks,
> --Vladimir
>
>> Vladimir Sizikov wrote:
>>> Hi Alexander,
>>>
>>> I have a question for you. :)
>>>
>>> You've changed MidpTckBaseInterview constructor so that the
>>> distributed mode is enabled by default:
>>>
>>> http://fisheye4.cenqua.com/browse/cqme/branches/users/skavas/testsuite/s...
>>>
>>> Isn't this an incompatible change that would cause problems with other
>>> TCKs, like MSA TCK or MMAPI TCK? These TCKs do not need distributed
>>> test support and use the two-parameter MidpTckBaseInterview
>>> constructor and expect that the constructor will create an interview
>>> with distributed tests support disabled.
>>>
>>> Maybe I misunderstood something in your changes?
>>>
>>> Thanks,
>>> --Vladimir
>>>
>>> On Wed, Mar 14, 2007 at 09:43:03AM +0300, Alexander Alexeev wrote:
>>>> Hi Vladimir,
>>>>
>>>> please review fix by following URL:
>>>> http://fisheye4.cenqua.com/changelog/~author=skavas/cqme/branches/users/...
>>>>
>>>> Now simple test suite can use J2meBaseTestSuite directly without
>>>> overriding interview or test suite.
>>>> As was discussed we definitely need the simple way to tune interview for
>>>> concrete test suite. For example in this update it's rather easy to
>>>> enable/disable distributed tests in the test suite but it's really hard
>>>> to disable some modes (CLDC or CDC for example). To do so you need to
>>>> create your own high level interview and create subinterview with tuned
>>>> functionality. We should carefully identify places where different test
>>>> suites needs different options but I think it's out of scope of this
>>>> bug. I propose to submit an separate Enhancement to track this.
>>>>
>>>> Thanks,
>>>> Alexander
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
>>> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> For additional commands, e-mail: meframework-help@cqme.dev.java.net
>

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

I reviewed the change. Yes, in our case we'd better choose
compatibility over the consistency.

One thing I'd suggest you do add - is to provide some javadocs for
MidpTckBaseInterview constructors and explicitly specify that 2
parameter constructor creates an interview instance with distributed
mode disabled, and that users should consider using 3 parameter
constructors if the want the ditirbuted mode to be disabled.

Currently, it's impossible to tell in which mode the 2 param
constructer will create the interview (without looking at the sources).

Once you've added the javadocs, please commit.

Thanks,
--Vladimir

On Wed, Mar 14, 2007 at 08:10:45PM +0300, Alexander Alexeev wrote:
> Vladimir,
>
> I like the idea about property. But unfortunately I don't see how it solves
> inconsistent between suite and interview. For simplest case (lack of the
> property in the jtt file) we need to allow distributed tests in the test
> suite
> (old TCKs relay on this behavior) and in the same time we need to disable
> distributed mode in the interview.
>
> The problem is that test suite and interview should be synchronized in the
> enabling/disabling distributed tests but in the same time we strive for
> reduce
> dependencies between suite and interview and bring them to environment.
> Seemingly interview should provide information to environment about enabling
> distributed tests and take this information by itself (not through
> constructor
> called from test suite). But logically such information belongs to test
> suite
> but not interview. So as I see we need at least one dependency of interview
> from
> test suite. May be it possible to make shouldEnableDistrTests() public and
> use
> it to determine interview behavior? Or create special class with test suite
> specific information and use it for customize interview?
>
> Back to the compatibility - I've reverted changes in the constructor of
> MidpTckBaseInterview. It solves problems with legacy TCKs with minimal
> inconsistency. But I found latest WebService TCKs and MMAPI TCK use three
> argument constructor with distributed flag set to true! So we will have
> problems
> described by you with them.
>
> P.S. The best behavior for the simple test suite will be disable distributed
> mode by default but unfortunately it's incompatible with existent TCKs at
> all :-(
>
> Thanks,
> Alexander
>
> Vladimir Sizikov wrote:
> >Alexander,
> >
> >On Wed, Mar 14, 2007 at 03:24:38PM +0300, Alexander Alexeev wrote:
> >>good question and you are right - now such TCKs have "Communication
> >>Server port" question in the interview and export comm service
> >>values in the environment. But we definitely need to do something
> >>with existent inconsistency when test suite is created with
> >>distributed support by default and interview is created
> >>non-distributed. I think redundant question in the old TCKs
> >>interviews is a small price for the correction.
> >
> >Hmmm, this doesn't sound good. DTF-enabled interviews can have more
> >then just one extra question. Sooner or later we'll add debuging
> >support question, maybe something else. Leaving thes issue not fixed
> >will just push the resolution to some further time, and decrease the
> >ME Framework Interview's usability.
> >
> >Is there a way to solve both problems, and to have consitent test
> >suite and interviews, and preserve the backward compatiblity?
> >
> >How about a new parameter in the jtt file?
> >"dtf.enabled = true", for example.
> >
> >Thanks,
> > --Vladimir
> >
> >>Vladimir Sizikov wrote:
> >>>Hi Alexander,
> >>>
> >>>I have a question for you. :)
> >>>
> >>>You've changed MidpTckBaseInterview constructor so that the
> >>>distributed mode is enabled by default:
> >>>
> >>>http://fisheye4.cenqua.com/browse/cqme/branches/users/skavas/testsuite/src/share/classes/com/sun/tck/j2me/interview/MidpTckBaseInterview.java?r=452#l77
> >>>
> >>>Isn't this an incompatible change that would cause problems with other
> >>>TCKs, like MSA TCK or MMAPI TCK? These TCKs do not need distributed
> >>>test support and use the two-parameter MidpTckBaseInterview
> >>>constructor and expect that the constructor will create an interview
> >>>with distributed tests support disabled.
> >>>
> >>>Maybe I misunderstood something in your changes?
> >>>
> >>>Thanks,
> >>> --Vladimir
> >>>
> >>>On Wed, Mar 14, 2007 at 09:43:03AM +0300, Alexander Alexeev wrote:
> >>>>Hi Vladimir,
> >>>>
> >>>>please review fix by following URL:
> >>>>http://fisheye4.cenqua.com/changelog/~author=skavas/cqme/branches/users/skavas/testsuite?cs=452
> >>>>
> >>>>Now simple test suite can use J2meBaseTestSuite directly without
> >>>>overriding interview or test suite.
> >>>>As was discussed we definitely need the simple way to tune interview for
> >>>>concrete test suite. For example in this update it's rather easy to
> >>>>enable/disable distributed tests in the test suite but it's really hard
> >>>>to disable some modes (CLDC or CDC for example). To do so you need to
> >>>>create your own high level interview and create subinterview with tuned
> >>>>functionality. We should carefully identify places where different test
> >>>>suites needs different options but I think it's out of scope of this
> >>>>bug. I propose to submit an separate Enhancement to track this.
> >>>>
> >>>>Thanks,
> >>>>Alexander
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >>>>For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >>>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >>>For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >>>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: meframework-unsubscribe@cqme.dev.java.net
> >For additional commands, e-mail: meframework-help@cqme.dev.java.net
> >
>

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