date:20060904




Mikhail Loenko wrote:

Hi Vladimir

Could you please decribe for what purpose it will be used?

I mean why one might have to either exclude or run only regression tests?


If running all tests takes up much time, running all regression test 
(for one particular version) may be a convenient way to verify the 
correctness of bug-fixing.


Best regards,
Richard.



Thanks,
Mikhail

2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:

On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:



 Vladimir Ivanov wrote:
  Also some tag for regression tests should be added.
 Yes. Do you think we could annotate regression test as
 *level.regression*? Thanks a lot.


Yes, I do. While tests can have more than one group it will enough.
 thanks, Vladimir


Richard
  thanks, Vladimir
 
 
  On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
 
 
 
  Richard Liang wrote:
   Hello All,
  
   Now let's talk about the TestNG groups. I have read the related
   threads which posted by George, Vladimir Ivanov and Alexei 
Zakharov.

   All of them are good discussion about TestNG groups.
  
   IMHO, we may define Harmony test groups according the following 4
   dimensions:
  
   1) [Platform] os.any, os.platform id
   *os.any* - group of tests which pass on any platform. IMHO, 
most of

   our tests should be in this group.
   *os.platform id* - group of tests which are designed for one
   specific platform. A test may be in more than one of the 
groups. e.g

 .,
   @Test(groups={os.win.IA32, os.linux.IA32})
  
  ** os.any and os.platform id are mutually exclusive, that 
is,

   tests in os.any group should not be in os.win.IA32.
  
   2) [Test state] state.broken, state.broken.platform id
   *state.broken* - group of tests which fail on every platform, 
because
   of bugs of tests or implementation. We need to fix the bugs of 
tests

   or implementation to make them pass.
   *state.broken.platform id* - groups of test which only fail 
on one
   specific platform. A test may be in more than one of the 
groups. e.g

 .,
   @Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
  
   **state.broken.platform id group may be used as a 
convenient

 way
   to indicate that a test is platform-specific. e.g., If we 
support 10

   platforms, and one test are designed for 9 platforms except for
 MacOS,
   instead of list 9 os.platform id, we can just use
 state.broken.MacOS
  
   3) [Test type] type.api , type.impl
   *type.api* - group of tests which are tests for APIs in the Java
   Specification
   *type.impl* - groups of tests which are tests for 
Harmony-specific

   implementation
  
   ** type.api and type.impl are also mutually exclusive.
  
   4) [Test Level] level.unit, level.integration, level.system,
   level.stress, etc. (Levels of Test refer to the increase in
 complexity
   as moving through test cycle. )
  ** A test may be in more than one of the groups.
  ** In fact, some tests such as System tests are the 
verification

 of
   the entire system.  Maybe we'll put them into a separate project.
   e.g., harmony/enhanced/SVT (System Verification Test).
  
   If we want to run all the unit test for APIs on windows, we 
may use

   TestNG groups to select the tests:
  groups
  run
  include name=os.any /
  include name=type.api /
  include name=os.win.IA32 /
  exclude name= state.broken /
  exclude name=state.broken.win.IA32 /
  /run
  /groups
  
  Hello All,
 
  I'm sorry. It seems that the example does not work. I will try to
 figure
  another example soon. ;-)
 
  Best regards,
  Richard
  
   Well, I think our most of existing tests are in the groups of
   {os.any, type.api, level.unit}, and I have asked TestNG 
to add

 a
   new option -groups for its JUnitConverter which allow us to 
specify

   the test groups when migrate from JUnit test to TestNG test.
  
   Thanks for reading so far, and I will highly appreciate your 
comments

   or suggestion.  ;-)
  
 
  --
  Richard Liang
  China Software Development Lab, IBM
 
 
 
  
-

  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: 
[EMAIL PROTECTED]
  For additional commands, e-mail: 
[EMAIL PROTECTED]

 
 
 

 --
 Richard Liang
 China Software Development Lab, IBM



 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]






-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Richard Liang
China Software Development Lab, IBM

Re: [classlib][TestNG] groups of Harmony test


On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:




Mikhail Loenko wrote:
 Hi Vladimir

 Could you please decribe for what purpose it will be used?

 I mean why one might have to either exclude or run only regression
tests?

If running all tests takes up much time, running all regression test
(for one particular version) may be a convenient way to verify the
correctness of bug-fixing.



Thanks Richard. It is exactly what I want to say :)
On the other hand may be all proposed groups need similar explanation (smt.
like use-case for group)?

thanks, Vladimir

Best regards,

Richard.


 Thanks,
 Mikhail

 2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
 On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
 
 
 
  Vladimir Ivanov wrote:
   Also some tag for regression tests should be added.
  Yes. Do you think we could annotate regression test as
  *level.regression*? Thanks a lot.


 Yes, I do. While tests can have more than one group it will enough.
  thanks, Vladimir


 Richard
   thanks, Vladimir
  
  
   On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
  
  
  
   Richard Liang wrote:
Hello All,
   
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei
 Zakharov.
All of them are good discussion about TestNG groups.
   
IMHO, we may define Harmony test groups according the following
4
dimensions:
   
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO,
 most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the
 groups. e.g
  .,
@Test(groups={os.win.IA32, os.linux.IA32})
   
   ** os.any and os.platform id are mutually exclusive, that
 is,
tests in os.any group should not be in os.win.IA32.
   
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform,
 because
of bugs of tests or implementation. We need to fix the bugs of
 tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail
 on one
specific platform. A test may be in more than one of the
 groups. e.g
  .,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64
})
   
**state.broken.platform id group may be used as a
 convenient
  way
to indicate that a test is platform-specific. e.g., If we
 support 10
platforms, and one test are designed for 9 platforms except for
  MacOS,
instead of list 9 os.platform id, we can just use
  state.broken.MacOS
   
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for
 Harmony-specific
implementation
   
** type.api and type.impl are also mutually exclusive.
   
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
  complexity
as moving through test cycle. )
   ** A test may be in more than one of the groups.
   ** In fact, some tests such as System tests are the
 verification
  of
the entire system.  Maybe we'll put them into a separate
project.
e.g., harmony/enhanced/SVT (System Verification Test).
   
If we want to run all the unit test for APIs on windows, we
 may use
TestNG groups to select the tests:
   groups
   run
   include name=os.any /
   include name=type.api /
   include name=os.win.IA32 /
   exclude name= state.broken /
   exclude name=state.broken.win.IA32 /
   /run
   /groups
   
   Hello All,
  
   I'm sorry. It seems that the example does not work. I will try to
  figure
   another example soon. ;-)
  
   Best regards,
   Richard
   
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG
 to add
  a
new option -groups for its JUnitConverter which allow us to
 specify
the test groups when migrate from JUnit test to TestNG test.
   
Thanks for reading so far, and I will highly appreciate your
 comments
or suggestion.  ;-)
   
  
   --
   Richard Liang
   China Software Development Lab, IBM
  
  
  
  
 -
   Terms of use : http://incubator.apache.org/harmony/mailing.html
   To unsubscribe, e-mail:
 [EMAIL PROTECTED]
   For additional commands, e-mail:
 [EMAIL PROTECTED]
  
  
  
 
  --
  Richard Liang
  China Software Development Lab, IBM
 
 
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail:
[EMAIL

Re: Re: [classlib][TestNG] groups of Harmony test

2006-09-04 Thread Alex Blewitt


IMNSO it doesn't make sense to arbitrarily partition the tests based
on a moniker, such as 'integration test', 'unit test', 'regression
test' etc. For one thing, developers are generally not good at
agreeing on the difference between them :-)

If you've got fast and slow tests, then have a group for fast and slow
tests. Then you can choose to just run the fast tests, and any
automated build system can handle running the slow tests.

Alex.

On 04/09/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:

On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:



 Mikhail Loenko wrote:
  Hi Vladimir
 
  Could you please decribe for what purpose it will be used?
 
  I mean why one might have to either exclude or run only regression
 tests?

 If running all tests takes up much time, running all regression test
 (for one particular version) may be a convenient way to verify the
 correctness of bug-fixing.


Thanks Richard. It is exactly what I want to say :)
On the other hand may be all proposed groups need similar explanation (smt.
like use-case for group)?

 thanks, Vladimir

Best regards,
 Richard.

 
  Thanks,
  Mikhail
 
  2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
  On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
  
  
  
   Vladimir Ivanov wrote:
Also some tag for regression tests should be added.
   Yes. Do you think we could annotate regression test as
   *level.regression*? Thanks a lot.
 
 
  Yes, I do. While tests can have more than one group it will enough.
   thanks, Vladimir
 
 
  Richard
thanks, Vladimir
   
   
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
   
   
   
Richard Liang wrote:
 Hello All,

 Now let's talk about the TestNG groups. I have read the related
 threads which posted by George, Vladimir Ivanov and Alexei
  Zakharov.
 All of them are good discussion about TestNG groups.

 IMHO, we may define Harmony test groups according the following
 4
 dimensions:

 1) [Platform] os.any, os.platform id
 *os.any* - group of tests which pass on any platform. IMHO,
  most of
 our tests should be in this group.
 *os.platform id* - group of tests which are designed for one
 specific platform. A test may be in more than one of the
  groups. e.g
   .,
 @Test(groups={os.win.IA32, os.linux.IA32})

** os.any and os.platform id are mutually exclusive, that
  is,
 tests in os.any group should not be in os.win.IA32.

 2) [Test state] state.broken, state.broken.platform id
 *state.broken* - group of tests which fail on every platform,
  because
 of bugs of tests or implementation. We need to fix the bugs of
  tests
 or implementation to make them pass.
 *state.broken.platform id* - groups of test which only fail
  on one
 specific platform. A test may be in more than one of the
  groups. e.g
   .,
 @Test(groups={state.broken.linux.IA32, os.broken.linux.IA64
 })

 **state.broken.platform id group may be used as a
  convenient
   way
 to indicate that a test is platform-specific. e.g., If we
  support 10
 platforms, and one test are designed for 9 platforms except for
   MacOS,
 instead of list 9 os.platform id, we can just use
   state.broken.MacOS

 3) [Test type] type.api , type.impl
 *type.api* - group of tests which are tests for APIs in the Java
 Specification
 *type.impl* - groups of tests which are tests for
  Harmony-specific
 implementation

 ** type.api and type.impl are also mutually exclusive.

 4) [Test Level] level.unit, level.integration, level.system,
 level.stress, etc. (Levels of Test refer to the increase in
   complexity
 as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the
  verification
   of
 the entire system.  Maybe we'll put them into a separate
 project.
 e.g., harmony/enhanced/SVT (System Verification Test).

 If we want to run all the unit test for APIs on windows, we
  may use
 TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups

Hello All,
   
I'm sorry. It seems that the example does not work. I will try to
   figure
another example soon. ;-)
   
Best regards,
Richard

 Well, I think our most of existing tests are in the groups of
 {os.any, type.api, level.unit}, and I have asked TestNG
  to add
   a
 new option -groups for its JUnitConverter which allow us to
  specify
 the test groups when migrate from JUnit test to TestNG test.

 Thanks for reading so far, and I will highly appreciate your
  comments
 or

Re: [classlib] internationalization and new patches

2006-09-04 Thread Ilya Okomin


On 9/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:


We have recently starting internationalization of existing modules
(thanks to all people involved!)

Now when we submit new patches and apply old ones let's make sure that
we don't break internationalization for the modules that were already
internationalized!



I've analyzed modules in Harmony that were already internationalized, they
are: luni, archive, sql.
IMHO we must don't break internationalization for the modules that were
already
internationalized but we should update them to follow the
new internationalization scheme that was discussed on harmony-dev. This
scheme supposed to be common for all modules in harmony.

Turning back to already internationalized modules..
There is nothing to do for sql module.
Archive module was partly internationalized. I've prepared patch where all
necessary messages were ported from the
o.a.h.luni.util.ExternalMessages.properties file into the
o.a.h.archive.internal.nls.messages.properties file with updated keys.
Committer who is going to apply this patch or any other patch with
internationalization for this module - should check if everything is
correct.
I suggest to do the same with luni module.

Regards,
Ilya.


Thanks,

Mikhail

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
--
Ilya Okomin
Intel Middleware Products Division

RE: [classlib][TestNG] groups of Harmony test

2006-09-04 Thread Ivanov, Alexey A

-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sent: Monday, September 04, 2006 10:56 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][TestNG] groups of Harmony test

Mikhail Loenko wrote:
 Hi Vladimir

 Could you please decribe for what purpose it will be used?

 I mean why one might have to either exclude or run only regression
tests?

If running all tests takes up much time, running all regression test
(for one particular version) may be a convenient way to verify the
correctness of bug-fixing.

I can be used for informational purposes as well. If the test fails, you
need simply re-open the associated bug provided the bug number can be
easily found.

Regards,
Alexey.

Best regards,
Richard.

 Thanks,
 Mikhail

 2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
 On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:

  Vladimir Ivanov wrote:
   Also some tag for regression tests should be added.
  Yes. Do you think we could annotate regression test as
  *level.regression*? Thanks a lot.

 Yes, I do. While tests can have more than one group it will enough.
  thanks, Vladimir

 Richard
   thanks, Vladimir

   On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:

   Richard Liang wrote:
Hello All,

Now let's talk about the TestNG groups. I have read the
related
threads which posted by George, Vladimir Ivanov and Alexei
 Zakharov.
All of them are good discussion about TestNG groups.

IMHO, we may define Harmony test groups according the
following 4
dimensions:

1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO,
 most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for
one
specific platform. A test may be in more than one of the
 groups. e.g
  .,
@Test(groups={os.win.IA32, os.linux.IA32})

   ** os.any and os.platform id are mutually exclusive,
that
 is,
tests in os.any group should not be in os.win.IA32.

2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform,
 because
of bugs of tests or implementation. We need to fix the bugs
of
 tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail
 on one
specific platform. A test may be in more than one of the
 groups. e.g
  .,
@Test(groups={state.broken.linux.IA32,
os.broken.linux.IA64})

**state.broken.platform id group may be used as a
 convenient
  way
to indicate that a test is platform-specific. e.g., If we
 support 10
platforms, and one test are designed for 9 platforms except
for
  MacOS,
instead of list 9 os.platform id, we can just use
  state.broken.MacOS

3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the
Java
Specification
*type.impl* - groups of tests which are tests for
 Harmony-specific
implementation

** type.api and type.impl are also mutually exclusive.

4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
  complexity
as moving through test cycle. )
   ** A test may be in more than one of the groups.
   ** In fact, some tests such as System tests are the
 verification
  of
the entire system.  Maybe we'll put them into a separate
project.
e.g., harmony/enhanced/SVT (System Verification Test).

If we want to run all the unit test for APIs on windows, we
 may use
TestNG groups to select the tests:
   groups
   run
   include name=os.any /
   include name=type.api /
   include name=os.win.IA32 /
   exclude name= state.broken /
   exclude name=state.broken.win.IA32 /
   /run
   /groups

   Hello All,

   I'm sorry. It seems that the example does not work. I will try
to
  figure
   another example soon. ;-)

   Best regards,
   Richard

Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG
 to add
  a
new option -groups for its JUnitConverter which allow us to
 specify
the test groups when migrate from JUnit test to TestNG test.

Thanks for reading so far, and I will highly appreciate your
 comments
or suggestion.  ;-)

   --
   Richard Liang
   China Software Development Lab, IBM

-
   Terms of use : http://incubator.apache.org/harmony/mailing.html
   To unsubscribe, e-mail:
 [EMAIL PROTECTED]
   For additional commands, e-mail:
 [EMAIL PROTECTED]

  --
  Richard Liang
  China Software Development Lab, IBM

-

Re: [general] jira issues tracking

2006-09-04 Thread Oleg Khaschansky


+1

On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:



Geir Magnusson Jr. wrote:


 Salikh Zakirov wrote:
 Hi,

 I have just tried to use JIRA to see how many unapplied patches are
 there for DRLVM,
 but couldn't search just for the issues with patch provided.

 Does anyone know of a good way to find just the issues with patches
 submitted?

 If there is no good way, probably subtasks feature of JIRA could be
 used,
 e.g., create subtask for each patch submitted. Subtasks are then
 easily searchable.

 I have also seen that other projects in JIRA use Patch available
 status,
 but I do not know how non-committer could change the issue state,
 so this does not look like a solution.

 We could turn this on for non-committers - I see no danger... does
 anyone?

+1 to open Patch Available to non-committers. ;-)

Just notice that Geronimo has opened two additional JIRA status: Patch
Available and Patch Reviewed.


 geir



 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



--
Richard Liang
China Software Development Lab, IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!

2006-09-04 Thread Stepan Mishura


On 9/1/06, Paulex Yang wrote:


Stepan Mishura wrote:
 Hi Andrew,

 I've just looked into static initialization block and then to the
 spec. for
 LogManager class.
 My impression is that Harmony implementation doesn't follow the spec.

 The spec. says: At startup the LogManager class is located using the '
 java.util.logging.manager' system property.By default, the LogManager
 reads
 its initial configuration from a properties file
 lib/logging.properties in
 the JRE directory
Stepan,

I think the meaning of By default is debatable. Actually the spec
looks like this:

At startup the LogManager class is located using the
java.util.logging.manager system property.

By default, the LogManager reads its initial configuration from a
properties file lib/logging.properties in the JRE directory. If you
edit that property file you can change the default logging configuration
for all uses of that JRE.

In addition, the LogManager uses two optional system properties that
allow more control over reading the initial configuration:

   * java.util.logging.config.class
   * java.util.logging.config.file...



So I consider the By default doesn't necessarily means default case
without java.util.logging.manager property, but means the default case
without java.util.logging.config.class/file properties.

A simple test on RI of specifying a customized MockLogManager by
j.u.l.manager property shows the default lib/logging.properties does
affect the behavior of the customized LogManager, say the root logger's
level, etc.



Do you mean that RI resets the root logger's level of customized LogManager
to default value from lib/logging.properties?

Thanks,
Stepan.



 So if the property 'java.util.logging.manager' is not set a default
 implementation is used. The default implementation looks for '
 java.util.logging.config.class' and 'java.util.logging.config.file'
 system
 properties, reads config from 'jre/lib/logging.properties' and so on.
 If the mentioned property is set then a custom LogManager class
 implementation is used. And it is up to the custom implementation how to
 load configuration. Right?

 But Harmony implementation follows default initialization procedure in
 any
 case. It loads the custom LogManager, looks for '
 java.util.logging.config.class' and 'java.util.logging.config.file'
 system
 properties and if none of them are set and it forces the custom
 LogManager  to read properties from 'jre/lib/logging.properties' file.
 Why?
 It is up to the custom implementation whether to read it or not.
 Did I missed something?

 Thanks,
 Stepan.


 SNIP


--

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!

2006-09-04 Thread Paulex Yang


Stepan Mishura wrote:

On 9/1/06, Paulex Yang wrote:


Stepan Mishura wrote:
 Hi Andrew,

 I've just looked into static initialization block and then to the
 spec. for
 LogManager class.
 My impression is that Harmony implementation doesn't follow the spec.

 The spec. says: At startup the LogManager class is located using 
the '

 java.util.logging.manager' system property.By default, the LogManager
 reads
 its initial configuration from a properties file
 lib/logging.properties in
 the JRE directory
Stepan,

I think the meaning of By default is debatable. Actually the spec
looks like this:

At startup the LogManager class is located using the
java.util.logging.manager system property.

By default, the LogManager reads its initial configuration from a
properties file lib/logging.properties in the JRE directory. If you
edit that property file you can change the default logging configuration
for all uses of that JRE.

In addition, the LogManager uses two optional system properties that
allow more control over reading the initial configuration:

   * java.util.logging.config.class
   * java.util.logging.config.file...



So I consider the By default doesn't necessarily means default case
without java.util.logging.manager property, but means the default case
without java.util.logging.config.class/file properties.

A simple test on RI of specifying a customized MockLogManager by
j.u.l.manager property shows the default lib/logging.properties does
affect the behavior of the customized LogManager, say the root logger's
level, etc.



Do you mean that RI resets the root logger's level of customized 
LogManager

to default value from lib/logging.properties?
Yes, so I think customized LogManager also needs to initialize itself in 
same procedure as j.u.l.LogManager.


Thanks,
Stepan.





--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [build-test-infra] Build Test Infrastructure

2006-09-04 Thread Anton Luht

Thanks,

These were remains of setup experiments - removed from the list.

On 9/4/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:

Seems, that links

upload60551http://harmonytest.org/testapp.do;jsessionid=9644A083467EC4F0C4CC806DB107C3F2?method=showrunid=upload60551
Europe/Moscow
11.2.0 x86 Windows XP 5.1
upload60552http://harmonytest.org/testapp.do;jsessionid=9644A083467EC4F0C4CC806DB107C3F2?method=showrunid=upload60552
Europe/Moscow
11.2.0 x86 Windows XP 5.1
upload60553http://harmonytest.org/testapp.do;jsessionid=9644A083467EC4F0C4CC806DB107C3F2?method=showrunid=upload60553
Europe/Moscow
11.2.0 x86 Windows XP 5.1

are broken.
thanks, Vladimir

On 9/1/06, Anton Luht [EMAIL PROTECTED] wrote:

Hello,

I've deployed the test infrastructure app to http://harmonytest.org .
It is mostly for demo purpose - the disk space is not too large - I
hope it will move somewhere else after evaluation. Please try to
upload your test results there and send comments/wishes about the app
- I'll try to implement them.

There is no design because I didn't dare to make it Apache-looking :)

The problem I see is that DRL VM version as seen is 'java.exe
-version' is not seen in System.getProperties() as is not recorded in
xmls with test results because of it. It's hard to identify the
configuration the tests were run on - I think version information
should be added to properties.

I don't want to send the account data to the list - please let me know
if you want to have access to the site.

On 8/4/06, Anton Luht [EMAIL PROTECTED] wrote:
Hello,

I've uploaded a proto of a proto for test infrastructure to
http://issues.apache.org/jira/browse/HARMONY-1062 . At least it allows
to upload test results to a server. Unfortunately I haven't found a
server to deploy it yet so I can't send URL that contains test
installation. The screenshots look much like those I've sent before.
Sorry I haven't implemented Alexei's proposal to make test report
JUnitReport style looking but I do remember about it.

I've tried to separate web application logic from data access logic -
the latter is implemented with data stored in files.
--
Regards,
Anton Luht,
Intel Middleware Products Division

--
Regards,
Anton Luht,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Regards,
Anton Luht,
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: [classlib][TestNG] groups of Harmony test

2006-09-04 Thread Mikhail Loenko


+1

2006/9/4, Alex Blewitt [EMAIL PROTECTED]:

IMNSO it doesn't make sense to arbitrarily partition the tests based
on a moniker, such as 'integration test', 'unit test', 'regression
test' etc. For one thing, developers are generally not good at
agreeing on the difference between them :-)

If you've got fast and slow tests, then have a group for fast and slow
tests. Then you can choose to just run the fast tests, and any
automated build system can handle running the slow tests.

Alex.

On 04/09/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
 On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:
 
 
 
  Mikhail Loenko wrote:
   Hi Vladimir
  
   Could you please decribe for what purpose it will be used?
  
   I mean why one might have to either exclude or run only regression
  tests?
 
  If running all tests takes up much time, running all regression test
  (for one particular version) may be a convenient way to verify the
  correctness of bug-fixing.


 Thanks Richard. It is exactly what I want to say :)
 On the other hand may be all proposed groups need similar explanation (smt.
 like use-case for group)?

  thanks, Vladimir

 Best regards,
  Richard.
 
  
   Thanks,
   Mikhail
  
   2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
   On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
   
   
   
Vladimir Ivanov wrote:
 Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
  
  
   Yes, I do. While tests can have more than one group it will enough.
thanks, Vladimir
  
  
   Richard
 thanks, Vladimir


 On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:



 Richard Liang wrote:
  Hello All,
 
  Now let's talk about the TestNG groups. I have read the related
  threads which posted by George, Vladimir Ivanov and Alexei
   Zakharov.
  All of them are good discussion about TestNG groups.
 
  IMHO, we may define Harmony test groups according the following
  4
  dimensions:
 
  1) [Platform] os.any, os.platform id
  *os.any* - group of tests which pass on any platform. IMHO,
   most of
  our tests should be in this group.
  *os.platform id* - group of tests which are designed for one
  specific platform. A test may be in more than one of the
   groups. e.g
.,
  @Test(groups={os.win.IA32, os.linux.IA32})
 
 ** os.any and os.platform id are mutually exclusive, that
   is,
  tests in os.any group should not be in os.win.IA32.
 
  2) [Test state] state.broken, state.broken.platform id
  *state.broken* - group of tests which fail on every platform,
   because
  of bugs of tests or implementation. We need to fix the bugs of
   tests
  or implementation to make them pass.
  *state.broken.platform id* - groups of test which only fail
   on one
  specific platform. A test may be in more than one of the
   groups. e.g
.,
  @Test(groups={state.broken.linux.IA32, os.broken.linux.IA64
  })
 
  **state.broken.platform id group may be used as a
   convenient
way
  to indicate that a test is platform-specific. e.g., If we
   support 10
  platforms, and one test are designed for 9 platforms except for
MacOS,
  instead of list 9 os.platform id, we can just use
state.broken.MacOS
 
  3) [Test type] type.api , type.impl
  *type.api* - group of tests which are tests for APIs in the Java
  Specification
  *type.impl* - groups of tests which are tests for
   Harmony-specific
  implementation
 
  ** type.api and type.impl are also mutually exclusive.
 
  4) [Test Level] level.unit, level.integration, level.system,
  level.stress, etc. (Levels of Test refer to the increase in
complexity
  as moving through test cycle. )
 ** A test may be in more than one of the groups.
 ** In fact, some tests such as System tests are the
   verification
of
  the entire system.  Maybe we'll put them into a separate
  project.
  e.g., harmony/enhanced/SVT (System Verification Test).
 
  If we want to run all the unit test for APIs on windows, we
   may use
  TestNG groups to select the tests:
 groups
 run
 include name=os.any /
 include name=type.api /
 include name=os.win.IA32 /
 exclude name= state.broken /
 exclude name=state.broken.win.IA32 /
 /run
 /groups
 
 Hello All,

 I'm sorry. It seems that the example does not work. I will try to
figure
 another example soon. ;-)

 Best regards,
 Richard
 
  Well, I think our most of existing tests are in the groups of
  {os.any, type.api, level.unit}, and I have asked TestNG
   to add
a
  new option -groups for its

Re: [drlvm] DRLVM, jre/bin/default and launcher

2006-09-04 Thread Evgueni Brevnov


Ok, I will try to teach DRLVM where to load dlls from before doing other things.

Evgueni.

On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

Ok, but can we wack off the biggest problem first, namely that DRLVM
doesn't work when it's artifacts (dll's, so's) are in a subdirectory of
jre/bin?

TO me, that's our biggest problem.  Subtle cleanup issues are also
important, but not as much at this point.

geir

Evgueni Brevnov wrote:
 Hi Geir,

 I'm very enthusiastic about making DRLVM to work with the launcher. It
 requires implementation of the Invocation API to a certain extent. For
 example it's enougth to have only partial support for
 DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
 necessary as well. So if there is no objections I can start working on
 it right now.

 Thanks
 Evgueni.

 On 8/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 We need to make DRLVM work with the launcher in the same way that J9
 works with the launcher.  It's a royal PITA to do an ant-clean and have
 DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.

 My goal here is two fold -

 a) make it easy for people to have both DRLVM and j9 around for A/B
 testing

 b) make DRLVM the default VM we use for everything

 I know that we still have the epic argument around hythread to resolve,
 but we can do this task first.

 Does anyone want to volunteer to take this on?  If not, I'll do it, but
 I know that there are people out there that know DRLVM far better than I
 do...

 geir

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] DRLVM, jre/bin/default and launcher

2006-09-04 Thread Andrey Chernyshev


On 9/1/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:

Hi Geir,

I'm very enthusiastic about making DRLVM to work with the launcher. It
requires implementation of the Invocation API to a certain extent. For
example it's enougth to have only partial support for


To some extent, some of those invocation API you mentioned have been
already implemented. I believe DRLVM can already be started with the
launcher if type a command:

java -vm:vmcore  -vmdir:.

If we want to complete the transition to the classlib's launcher, then
I guess we need to do the following:

1.  Fix the DRLVM layout - rename vmcore to harmonyvm and move
.dll/.so into the default subdirectory such that one doesn't have to
type -vm and -vmdir options;

2. Exclude building of the original launcher from the DRLVM build -
it currently conflicts with the classlib launcher (both are called
java).

3. Aside from the hythread, it may also have a sense to make the
classlib and DRLVM using the same zlib dll/so (preferably the system
one).


Thanks,
Andrey.



DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
necessary as well. So if there is no objections I can start working on
it right now.

Thanks
Evgueni.

On 8/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 We need to make DRLVM work with the launcher in the same way that J9
 works with the launcher.  It's a royal PITA to do an ant-clean and have
 DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.

 My goal here is two fold -

 a) make it easy for people to have both DRLVM and j9 around for A/B testing

 b) make DRLVM the default VM we use for everything

 I know that we still have the epic argument around hythread to resolve,
 but we can do this task first.

 Does anyone want to volunteer to take this on?  If not, I'll do it, but
 I know that there are people out there that know DRLVM far better than I
 do...

 geir

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Andrey Chernyshev
Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][TestNG] groups of Harmony test


On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:


On 9/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
 Well, my question was for what particular reason? for example?

 Tio verify correctness of bug-fixing IMHO all the unit, intergration,
api, and
 regression tests should be run

Running all tests are always good to verify our code quality. And I
think this is what we have been doing. But what will we do if it takes
us 24 hours to run all Harmony tests? Anyway, running regression tests
could provide some confidence to our bug-fixing. We may consider it as
another option. :-)



I prefer to run all tests in one module instead. :) Although it can not
guarentee all tests would pass, it's less likey to break build system
frequently.  If the fix causes other module fails, it shows the lack of
tests in its module. And we should add the corresponding test in the module.

Currently, Harmony regression test is a test for certain Harmony jira issue.
So IMHO, running all regression tests for certain issue doesn't make sense.

But whether using annotation to mark regression test is another story. At
least, it doesn't have any disadvantages compared with comment way, does it?


Best regards,

Richard


 Thanks,
 Mikhail

 2006/9/4, Richard Liang [EMAIL PROTECTED]:
 
 
  Mikhail Loenko wrote:
   Hi Vladimir
  
   Could you please decribe for what purpose it will be used?
  
   I mean why one might have to either exclude or run only regression
tests?
 
  If running all tests takes up much time, running all regression test
  (for one particular version) may be a convenient way to verify the
  correctness of bug-fixing.
 
  Best regards,
  Richard.
 
  
   Thanks,
   Mikhail
  
   2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
   On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
   
   
   
Vladimir Ivanov wrote:
 Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
  
  
   Yes, I do. While tests can have more than one group it will enough.
thanks, Vladimir
  
  
   Richard
 thanks, Vladimir


 On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:



 Richard Liang wrote:
  Hello All,
 
  Now let's talk about the TestNG groups. I have read the
related
  threads which posted by George, Vladimir Ivanov and Alexei
   Zakharov.
  All of them are good discussion about TestNG groups.
 
  IMHO, we may define Harmony test groups according the
following 4
  dimensions:
 
  1) [Platform] os.any, os.platform id
  *os.any* - group of tests which pass on any platform. IMHO,
   most of
  our tests should be in this group.
  *os.platform id* - group of tests which are designed for
one
  specific platform. A test may be in more than one of the
   groups. e.g
.,
  @Test(groups={os.win.IA32, os.linux.IA32})
 
 ** os.any and os.platform id are mutually exclusive,
that
   is,
  tests in os.any group should not be in os.win.IA32.
 
  2) [Test state] state.broken, state.broken.platform id
  *state.broken* - group of tests which fail on every
platform,
   because
  of bugs of tests or implementation. We need to fix the bugs
of
   tests
  or implementation to make them pass.
  *state.broken.platform id* - groups of test which only
fail
   on one
  specific platform. A test may be in more than one of the
   groups. e.g
.,
  @Test(groups={state.broken.linux.IA32, 
os.broken.linux.IA64})
 
  **state.broken.platform id group may be used as a
   convenient
way
  to indicate that a test is platform-specific. e.g., If we
   support 10
  platforms, and one test are designed for 9 platforms except
for
MacOS,
  instead of list 9 os.platform id, we can just use
state.broken.MacOS
 
  3) [Test type] type.api , type.impl
  *type.api* - group of tests which are tests for APIs in the
Java
  Specification
  *type.impl* - groups of tests which are tests for
   Harmony-specific
  implementation
 
  ** type.api and type.impl are also mutually exclusive.
 
  4) [Test Level] level.unit, level.integration, level.system,
  level.stress, etc. (Levels of Test refer to the increase in
complexity
  as moving through test cycle. )
 ** A test may be in more than one of the groups.
 ** In fact, some tests such as System tests are the
   verification
of
  the entire system.  Maybe we'll put them into a separate
project.
  e.g., harmony/enhanced/SVT (System Verification Test).
 
  If we want to run all the unit test for APIs on windows, we
   may use
  TestNG groups to select the tests:
 groups
 run
 include name=os.any /
 include name=type.api /
 include name=os.win.IA32 /
 exclude name=

Re: [drlvm] DRLVM, jre/bin/default and launcher

2006-09-04 Thread Salikh Zakirov

Andrey Chernyshev wrote:
 1.  Fix the DRLVM layout - rename vmcore to harmonyvm and move
 ..dll/.so into the default subdirectory such that one doesn't have to
 type -vm and -vmdir options;

While would you want to rename DRLVM to Harmony VM? 
It feels to me like claiming DRLVM to be the only Harmony VM.
On the contrary, I thought Harmony project is about *encouraging* diversity.

I think having library named libdrlvm.so would be much better.

 2. Exclude building of the original launcher from the DRLVM build -
 it currently conflicts with the classlib launcher (both are called
 java).
 
 3. Aside from the hythread, it may also have a sense to make the
 classlib and DRLVM using the same zlib dll/so (preferably the system
 one).


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: [classlib][TestNG] groups of Harmony test


On 9/4/06, Andrew Zhang [EMAIL PROTECTED] wrote:

On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:

 I sent my reply this afternoon, but I have not received it. (it seems
 there
 is something wrong with my smtp server). So I send it again. :-)

 On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote:
 
  IMNSO it doesn't make sense to arbitrarily partition the tests based
  on a moniker, such as 'integration test', 'unit test', 'regression
  test' etc. For one thing, developers are generally not good at
  agreeing on the difference between them :-)



 This is really a problem, however it might be simpler than we imagine. We
 are open to any discussion. ;-) Anyway, developers are required to write
 unit tests.


 If you've got fast and slow tests, then have a group for fast and slow
  tests. Then you can choose to just run the fast tests, and any
  automated build system can handle running the slow tests.


 IMHO, fast or slow may not be the key point. The question is whether we
 have any requirements to run only the regression tests.


I think your first proposal looks fine. Platform + os + state + api/impl
information are enough for all tests. We have to assure all tests pass on
every platform.



Thanks a lot. Well, I agree :-). TestNG annotations are most helpful
to us in the management of unit tests that are prone to change. For
example, some unit tests suddenly break on a particular platform. or
we may want to exclude some tests temporarily.

Here I just try to list all the possible facets, so that we could
have more thorough discussion.

Best regards,
Richard


For quick run, developers can use their own short approach, like run single
test in IDE... It's not business of TestNG. :-)


Best regards,
 Richard

 Alex.
 
  On 04/09/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
   On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:
   
   
   
Mikhail Loenko wrote:
 Hi Vladimir

 Could you please decribe for what purpose it will be used?

 I mean why one might have to either exclude or run only regression
tests?
   
If running all tests takes up much time, running all regression test
(for one particular version) may be a convenient way to verify the
correctness of bug-fixing.
  
  
   Thanks Richard. It is exactly what I want to say :)
   On the other hand may be all proposed groups need similar explanation
  (smt.
   like use-case for group)?
  
thanks, Vladimir
  
   Best regards,
Richard.
   

 Thanks,
 Mikhail

 2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
 On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
 
 
 
  Vladimir Ivanov wrote:
   Also some tag for regression tests should be added.
  Yes. Do you think we could annotate regression test as
  *level.regression*? Thanks a lot.


 Yes, I do. While tests can have more than one group it will
 enough.
  thanks, Vladimir


 Richard
   thanks, Vladimir
  
  
   On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
  
  
  
   Richard Liang wrote:
Hello All,
   
Now let's talk about the TestNG groups. I have read the
  related
threads which posted by George, Vladimir Ivanov and Alexei
 Zakharov.
All of them are good discussion about TestNG groups.
   
IMHO, we may define Harmony test groups according the
  following
4
dimensions:
   
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform.
 IMHO,
 most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for
  one
specific platform. A test may be in more than one of the
 groups. e.g
  .,
@Test(groups={os.win.IA32, os.linux.IA32})
   
   ** os.any and os.platform id are mutually exclusive,
  that
 is,
tests in os.any group should not be in os.win.IA32.
   
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every
  platform,
 because
of bugs of tests or implementation. We need to fix the
 bugs
  of
 tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only
  fail
 on one
specific platform. A test may be in more than one of the
 groups. e.g
  .,
@Test(groups={state.broken.linux.IA32, 
  os.broken.linux.IA64
})
   
**state.broken.platform id group may be used as a
 convenient
  way
to indicate that a test is platform-specific. e.g., If we
 support 10
platforms, and one test are designed for 9 platforms
 except
  for
  MacOS,
instead of list 9 os.platform id, we can just use
  state.broken.MacOS
   
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in

Re: [classlib] [ldap] support for multiple VMs?

2006-09-04 Thread Alexey Varlamov


2006/8/28, Paulex Yang [EMAIL PROTECTED]:

Oliver Deakin wrote:
 Hi Alexey,

 I have taken a look at the patch - generally it looks good to me, and
 if it all
 works ok when you test it, it's fine by me.

 I think if there are cases where some functionality is repeated many
 times, it
 would be good to see it split out somewhere central. However, Im not sure
 the port library is the right place for these functions - the port
 library is really a
 generic front hiding platform specific operations. These functions do
 not really
 fit into that category - perhaps they would be better placed in the
 common
 library (luni/src/main/native/common)? This component provides a set of
 helper functions required by many native modules, and seems like the
 right
 place to put them.
Agree, portlib is designed to encapsulate OS/architecture difference,
and it should be taken care to be concise, so that it can be ported
easily to as many platforms as possible(at least to those Harmony
planned to support),  it is not a common library.


Paulex, Oliver,

Sorry for late response, I fully agree with your considerations. I was
just not familiar enough with luni natives structure and was drawn
away with idea of runtime code sharing. But indeed common lib with
static linkage is appropriate for the case.
So I rearranged the patch for HARMONY-1243, please review and commit.
Seems there are good cases for using these common functions, for
example issue #1386.

--
WBR,
Alexey



 Regards,
 Oliver

 Alexey Varlamov wrote:
 Oliver,

 Please take a look at a HARMONY-1243 patch. I fixed all bugs noticed
 and made parsing a bit more robust. Also, added a define for
 org.apache.harmony.boot.class.path name to vmi.h - to enforce that
 there is 2-sided contract for this property.

 I still think that some of those functions may worth to be added to
 the portlib, namely:
 char * str_concat (HyPortLibrary * portLibrary, ...);
 int props_read_from_file(HyPortLibrary * portLibrary, const char
 *filename,
  key_value_pair** properties, U_32 *number);
 void props_free(HyPortLibrary * portLibrary, key_value_pair *
 properties);

 Justification: the same functionality is duplicated at least in
 launcher/shared/main.c, and there are other property files to be read
 by VM.

 If nobody object, I will try to add these 3 functions to portlib.




--
Paulex Yang
China Software Development Lab
IBM



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [classlib][TestNG] groups of Harmony test

2006-09-04 Thread Ivanov, Alexey A

-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Monday, September 04, 2006 6:18 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][TestNG] groups of Harmony test

On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:

 On 9/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
  Well, my question was for what particular reason? for example?

  Tio verify correctness of bug-fixing IMHO all the unit,
intergration,
 api, and
  regression tests should be run

 Running all tests are always good to verify our code quality. And I
 think this is what we have been doing. But what will we do if it
takes
 us 24 hours to run all Harmony tests? Anyway, running regression
tests
 could provide some confidence to our bug-fixing. We may consider it
as
 another option. :-)

I prefer to run all tests in one module instead. :) Although it can not
guarentee all tests would pass, it's less likey to break build system
frequently.  If the fix causes other module fails, it shows the lack of
tests in its module. And we should add the corresponding test in the
module.

Currently, Harmony regression test is a test for certain Harmony jira
issue.
So IMHO, running all regression tests for certain issue doesn't make
sense.

But whether using annotation to mark regression test is another story.
At
least, it doesn't have any disadvantages compared with comment way,
does it?

Agree. We may introduce a special annotation for this purpose.

Regards,
Alexey.

Best regards,
 Richard

  Thanks,
  Mikhail

  2006/9/4, Richard Liang [EMAIL PROTECTED]:

   Mikhail Loenko wrote:
Hi Vladimir

Could you please decribe for what purpose it will be used?

I mean why one might have to either exclude or run only
regression
 tests?

   If running all tests takes up much time, running all regression
test
   (for one particular version) may be a convenient way to verify
the
   correctness of bug-fixing.

   Best regards,
   Richard.

Thanks,
Mikhail

2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:

 Vladimir Ivanov wrote:
  Also some tag for regression tests should be added.
 Yes. Do you think we could annotate regression test as
 *level.regression*? Thanks a lot.

Yes, I do. While tests can have more than one group it will
enough.
 thanks, Vladimir

Richard
  thanks, Vladimir

  On 8/28/06, Richard Liang [EMAIL PROTECTED]
wrote:

  Richard Liang wrote:
   Hello All,

   Now let's talk about the TestNG groups. I have read the
 related
   threads which posted by George, Vladimir Ivanov and
Alexei
Zakharov.
   All of them are good discussion about TestNG groups.

   IMHO, we may define Harmony test groups according the
 following 4
   dimensions:

   1) [Platform] os.any, os.platform id
   *os.any* - group of tests which pass on any platform.
IMHO,
most of
   our tests should be in this group.
   *os.platform id* - group of tests which are designed
for
 one
   specific platform. A test may be in more than one of
the
groups. e.g
 .,
   @Test(groups={os.win.IA32, os.linux.IA32})

  ** os.any and os.platform id are mutually
exclusive,
 that
is,
   tests in os.any group should not be in os.win.IA32.

   2) [Test state] state.broken, state.broken.platform
id
   *state.broken* - group of tests which fail on every
 platform,
because
   of bugs of tests or implementation. We need to fix the
bugs
 of
tests
   or implementation to make them pass.
   *state.broken.platform id* - groups of test which
only
 fail
on one
   specific platform. A test may be in more than one of
the
groups. e.g
 .,
   @Test(groups={state.broken.linux.IA32, 
 os.broken.linux.IA64})

   **state.broken.platform id group may be used as a
convenient
 way
   to indicate that a test is platform-specific. e.g., If
we
support 10
   platforms, and one test are designed for 9 platforms
except
 for
 MacOS,
   instead of list 9 os.platform id, we can just use
 state.broken.MacOS

   3) [Test type] type.api , type.impl
   *type.api* - group of tests which are tests for APIs in
the
 Java
   Specification
   *type.impl* - groups of tests which are tests for
Harmony-specific
   implementation

   ** type.api and type.impl are also mutually
exclusive.

   4) [Test Level] level.unit, level.integration,
level.system,
   level.stress, etc. (Levels of Test refer to the
increase in
 complexity
   as moving through test cycle. )
  ** A test may be in more than one of the groups.
  ** In fact, some tests such as System tests are the
verification
 of
   the entire system.  Maybe we'll put them

Re: [drlvm]A subject to profiling instrumenting

2006-09-04 Thread zouqiong


在06-9-4，Salikh Zakirov [EMAIL PROTECTED] 写道：


zouqiong wrote:
  I am now doing two things:
  1. track accesses to the three things you refer. And just the same
  implementation as some
  rt_helper_***, but the following error happens:
  java.exec:
  /root/harmony/enhanced/drlvm/trunk/vm/jitrino/src/jet/cg_ia32.cpp：
 1621： void
  Jitrino::Jet::Compiler::gen_patch(const char*, const
  Jitrino::Jet::CodePatchItem): 断言cpi.target_offset != 0失败。
  abort_handler()
 

 This error has been fixed. But I still want to know How to dump out the
 native code generated by the VM. Should the liblwdis.so
 be written by ourselves?

 Now, although the above error has been resolved, I encounter an new
issue.
 SIGSEGV in VM code. This error seems some error happens in generated
 code.



This issue has been solved.  Thanks.

Segmentation faults in compiled java code are always treated as

NullPointerException,
no matter what address or operation caused a segmentation fault.

SIGSEGV in VM code. means that the segmentation code occured in C++ code
of the VM.
gdb should be of much help in this case.


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Best Regards,
Qiong,Zou

Re: [classlib][TestNG] groups of Harmony test


On 9/4/06, Andrew Zhang [EMAIL PROTECTED] wrote:

On 9/4/06, Richard Liang [EMAIL PROTECTED] wrote:

 On 9/4/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
  Well, my question was for what particular reason? for example?
 
  Tio verify correctness of bug-fixing IMHO all the unit, intergration,
 api, and
  regression tests should be run

 Running all tests are always good to verify our code quality. And I
 think this is what we have been doing. But what will we do if it takes
 us 24 hours to run all Harmony tests? Anyway, running regression tests
 could provide some confidence to our bug-fixing. We may consider it as
 another option. :-)


I prefer to run all tests in one module instead. :) Although it can not
guarentee all tests would pass, it's less likey to break build system
frequently.  If the fix causes other module fails, it shows the lack of
tests in its module. And we should add the corresponding test in the module.



Running all tests for one module is practical for most cases (except luni).



Currently, Harmony regression test is a test for certain Harmony jira issue.
So IMHO, running all regression tests for certain issue doesn't make sense.


Yes, Harmony regression test is not the so-called regression test
which aim to verify that no unwanted changes were introduced to one
part of the system as a
result of making changes to another part of the system.

I agree that we may not want to run all the regression test. If
there is no objection I will remove level.regression



But whether using annotation to mark regression test is another story. At
least, it doesn't have any disadvantages compared with comment way, does it?



We may use @Test(description=Regression: Harmony-).



Best regards,
 Richard

 
  Thanks,
  Mikhail
 
  2006/9/4, Richard Liang [EMAIL PROTECTED]:
  
  
   Mikhail Loenko wrote:
Hi Vladimir
   
Could you please decribe for what purpose it will be used?
   
I mean why one might have to either exclude or run only regression
 tests?
  
   If running all tests takes up much time, running all regression test
   (for one particular version) may be a convenient way to verify the
   correctness of bug-fixing.
  
   Best regards,
   Richard.
  
   
Thanks,
Mikhail
   
2006/8/30, Vladimir Ivanov [EMAIL PROTECTED]:
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:



 Vladimir Ivanov wrote:
  Also some tag for regression tests should be added.
 Yes. Do you think we could annotate regression test as
 *level.regression*? Thanks a lot.
   
   
Yes, I do. While tests can have more than one group it will enough.
 thanks, Vladimir
   
   
Richard
  thanks, Vladimir
 
 
  On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
 
 
 
  Richard Liang wrote:
   Hello All,
  
   Now let's talk about the TestNG groups. I have read the
 related
   threads which posted by George, Vladimir Ivanov and Alexei
Zakharov.
   All of them are good discussion about TestNG groups.
  
   IMHO, we may define Harmony test groups according the
 following 4
   dimensions:
  
   1) [Platform] os.any, os.platform id
   *os.any* - group of tests which pass on any platform. IMHO,
most of
   our tests should be in this group.
   *os.platform id* - group of tests which are designed for
 one
   specific platform. A test may be in more than one of the
groups. e.g
 .,
   @Test(groups={os.win.IA32, os.linux.IA32})
  
  ** os.any and os.platform id are mutually exclusive,
 that
is,
   tests in os.any group should not be in os.win.IA32.
  
   2) [Test state] state.broken, state.broken.platform id
   *state.broken* - group of tests which fail on every
 platform,
because
   of bugs of tests or implementation. We need to fix the bugs
 of
tests
   or implementation to make them pass.
   *state.broken.platform id* - groups of test which only
 fail
on one
   specific platform. A test may be in more than one of the
groups. e.g
 .,
   @Test(groups={state.broken.linux.IA32, 
 os.broken.linux.IA64})
  
   **state.broken.platform id group may be used as a
convenient
 way
   to indicate that a test is platform-specific. e.g., If we
support 10
   platforms, and one test are designed for 9 platforms except
 for
 MacOS,
   instead of list 9 os.platform id, we can just use
 state.broken.MacOS
  
   3) [Test type] type.api , type.impl
   *type.api* - group of tests which are tests for APIs in the
 Java
   Specification
   *type.impl* - groups of tests which are tests for
Harmony-specific
   implementation
  
   ** type.api and type.impl are also mutually exclusive.
  
   4) [Test Level] level.unit, level.integration, level.system,
   level.stress, etc. (Levels of Test refer to the increase in

Re: [general] jira issues tracking




Richard Liang wrote:



Geir Magnusson Jr. wrote:



Salikh Zakirov wrote:

Hi,

I have just tried to use JIRA to see how many unapplied patches are 
there for DRLVM,

but couldn't search just for the issues with patch provided.

Does anyone know of a good way to find just the issues with patches 
submitted?


If there is no good way, probably subtasks feature of JIRA could be 
used,
e.g., create subtask for each patch submitted. Subtasks are then 
easily searchable.


I have also seen that other projects in JIRA use Patch available 
status,

but I do not know how non-committer could change the issue state,
so this does not look like a solution.


We could turn this on for non-committers - I see no danger... does 
anyone?


+1 to open Patch Available to non-committers. ;-)

Just notice that Geronimo has opened two additional JIRA status: Patch 
Available and Patch Reviewed.


Because Ken placed the project in a review then commit mode.  We're 
not going there :)


geir






geir




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] DRLVM, jre/bin/default and launcher

2006-09-04 Thread Oliver Deakin


Salikh Zakirov wrote:

Andrey Chernyshev wrote:
  

1.  Fix the DRLVM layout - rename vmcore to harmonyvm and move
..dll/.so into the default subdirectory such that one doesn't have to
type -vm and -vmdir options;



While would you want to rename DRLVM to Harmony VM? 
It feels to me like claiming DRLVM to be the only Harmony VM.

On the contrary, I thought Harmony project is about *encouraging* diversity.

I think having library named libdrlvm.so would be much better.
  


The Harmony launcher looks for harmonyvm.dll as its default vm library.  
It's just a generic
name so that the launcher can find the correct library without -vm. The 
IBM VME also
contains a harmonyvm.dll, which is why it works without specifying 
command line options


Regards,
Oliver

  

2. Exclude building of the original launcher from the DRLVM build -
it currently conflicts with the classlib launcher (both are called
java).

3. Aside from the hythread, it may also have a sense to make the
classlib and DRLVM using the same zlib dll/so (preferably the system
one).




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  


--
Oliver Deakin
IBM United Kingdom Limited


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] DRLVM, jre/bin/default and launcher


Cool.

I guess the question is, can it load resources from the directory where 
the VM itself came from?  We want to package things such that they all 
go into


  jre/bin/somedirectoryname

with the default for that being 'default' (although it shouldn't matter).

We also want to avoid setting LD_LIBRARY_PATH and other such 
externalities...


geir


Evgueni Brevnov wrote:
Ok, I will try to teach DRLVM where to load dlls from before doing other 
things.


Evgueni.

On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:

Ok, but can we wack off the biggest problem first, namely that DRLVM
doesn't work when it's artifacts (dll's, so's) are in a subdirectory of
jre/bin?

TO me, that's our biggest problem.  Subtle cleanup issues are also
important, but not as much at this point.

geir

Evgueni Brevnov wrote:
 Hi Geir,

 I'm very enthusiastic about making DRLVM to work with the launcher. It
 requires implementation of the Invocation API to a certain extent. For
 example it's enougth to have only partial support for
 DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
 necessary as well. So if there is no objections I can start working on
 it right now.

 Thanks
 Evgueni.

 On 8/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 We need to make DRLVM work with the launcher in the same way that J9
 works with the launcher.  It's a royal PITA to do an ant-clean and 
have

 DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.

 My goal here is two fold -

 a) make it easy for people to have both DRLVM and j9 around for A/B
 testing

 b) make DRLVM the default VM we use for everything

 I know that we still have the epic argument around hythread to 
resolve,

 but we can do this task first.

 Does anyone want to volunteer to take this on?  If not, I'll do it, 
but
 I know that there are people out there that know DRLVM far better 
than I

 do...

 geir

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] DRLVM, jre/bin/default and launcher




Andrey Chernyshev wrote:

On 9/1/06, Evgueni Brevnov [EMAIL PROTECTED] wrote:

Hi Geir,

I'm very enthusiastic about making DRLVM to work with the launcher. It
requires implementation of the Invocation API to a certain extent. For
example it's enougth to have only partial support for


To some extent, some of those invocation API you mentioned have been
already implemented. I believe DRLVM can already be started with the
launcher if type a command:

java -vm:vmcore  -vmdir:.


Yes. But it won't work if vmdir isn't .



If we want to complete the transition to the classlib's launcher, then
I guess we need to do the following:

1.  Fix the DRLVM layout - rename vmcore to harmonyvm and move
.dll/.so into the default subdirectory such that one doesn't have to
type -vm and -vmdir options;


Yes, but that can be done in the build script.

The problem is that DRLVM - apparently EM which seems to a bit of the 
loading - can't seem to handle when resources aren't in .




2. Exclude building of the original launcher from the DRLVM build -
it currently conflicts with the classlib launcher (both are called
java).

3. Aside from the hythread, it may also have a sense to make the
classlib and DRLVM using the same zlib dll/so (preferably the system
one).


Yep.

But first, we need to fix EM so that resources can be in a subdirectory.

so to summarize :

I don't believe the issue is as simple as a build script.  I thought I 
experimented with getting DRLVM to work with the normal launcher when 
DRLVM was in /default.  If memory serves, it doesnt' work.


geir





Thanks,
Andrey.



DestroyJavaVM(JavaVM * vm). Some changes to j.l.Thread class is
necessary as well. So if there is no objections I can start working on
it right now.

Thanks
Evgueni.

On 8/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote:
 We need to make DRLVM work with the launcher in the same way that J9
 works with the launcher.  It's a royal PITA to do an ant-clean and have
 DRLVM wiped out of the deploy/jdk/jre directory in classlib-land.

 My goal here is two fold -

 a) make it easy for people to have both DRLVM and j9 around for A/B 
testing


 b) make DRLVM the default VM we use for everything

 I know that we still have the epic argument around hythread to resolve,
 but we can do this task first.

 Does anyone want to volunteer to take this on?  If not, I'll do it, but
 I know that there are people out there that know DRLVM far better 
than I

 do...

 geir

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] DRLVM, jre/bin/default and launcher




Salikh Zakirov wrote:

Andrey Chernyshev wrote:

1.  Fix the DRLVM layout - rename vmcore to harmonyvm and move
..dll/.so into the default subdirectory such that one doesn't have to
type -vm and -vmdir options;


While would you want to rename DRLVM to Harmony VM? 
It feels to me like claiming DRLVM to be the only Harmony VM.

On the contrary, I thought Harmony project is about *encouraging* diversity.

I think having library named libdrlvm.so would be much better.


No - the launcher picks up the vm from harmonyvm.dll (or .so) so 
that's what we'll name it.


Then it makes it easy.  put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm 
and then


  java -vmdir:j9

or

  java -vmdir:drlvm


etc

geir




2. Exclude building of the original launcher from the DRLVM build -
it currently conflicts with the classlib launcher (both are called
java).

3. Aside from the hythread, it may also have a sense to make the
classlib and DRLVM using the same zlib dll/so (preferably the system
one).



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: Re: [classlib][TestNG] groups of Harmony test

2006-09-04 Thread Alex Blewitt


On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:

On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote:

 If you've got fast and slow tests, then have a group for fast and slow
 tests. Then you can choose to just run the fast tests, and any
 automated build system can handle running the slow tests.

IMHO, fast or slow may not be the key point. The question is whether we
have any requirements to run only the regression tests.


No, probably not the key point, but (a) groups don't have to be
mutually exclusive (so you can decorate it with whatever groups you
want) and (b) it might be useful for an automated build system to run
fast tests first, followed by slow (or non-fast) tests. Mind you, I
don't know what's going to happen with an automated test'n'build
system; so it might not make sense to do it at this point.

Alex.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints

2006-09-04 Thread Gregory Shimansky

Hello

Now that DRLVM has some basic implementation of breakpoints in JIT mode as 
HARMONY-1363 has been created I've decided the same mechanism may be used for 
implementation of SingleStep JVMTI event [1].

I've thought of some draft design for SingleStep implementation using just 
int3 breakpoints which are already written in HARMONY-1363. It seems to be 
enough to satisfy JVMTI spec requirements.

The way how I think SingleStep could be implemented is setting a new 
breakpoint on every new bytecode in compiled code. The breakpoint handler 
would remove SingleStep breakpoints instrumentation from compiled code and 
set new ones for the next executable location.

The tricky parts is to find the next executable location have the following 
points

1. Turning SingleStep event state on. When this state is turned on all threads 
should be switched into SingleStep mode. All of them have to have the next 
after currently executed bytecode marked with SingleStep type breakpoint.
2. New threads when started and SingleStep state is on have to mark the first 
bytecode marked with SingleStep breakpoint.
3. Any native to Java transition have to mark first executable bytecode of the 
method with SingleStep type breakpoint.
4. When exception occurs the SingleStep breakpoints have to be removed from 
the places of the next executable location and set to exception handler 
starting address instead.
5. Breakpoints handler which would handle SingleStep type breakpoints as well 
has to distinguish agent set Breakpoints and synthetic SingleStep ones.
6. When SingleStep state is turned off all breakpoints for the next bytecode 
in all threads have to be deleted.

The implementation would require next bytecode predictor which would allow 
the handler of breakpoints to set them on the next bytecode to be executed. 
For conditional situations it is easiest to have a set of possibly executable 
locations, or otherwise it would require parsing current Java stack state. 
The breakpoints predicted for the next bytecode should certainly be kept in 
TLS for every thread.

There is going to be some subtle logic for distinguishing plain breakpoints 
and synthetic SingleStep ones and turning SingleStep on/off while in 
SingleStep and/or Breakpoint callback.

So in places like #4, #5 and #6 predicted breakpoints would have to be added 
and removed in sets potentially with more than one target address.

At the moment I don't see any flaws in this simple design and I'm going to 
start working on its implementation. Let me know what you think about it. 
Surely it is a subject for improvement.

I am mostly keeping the whole idea in my head and never tried to write it down 
completely, I may miss describing some nuances since I may think of them as 
obvious so feel free to ask me.

[1]
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#SingleStep

-- 
Gregory Shimansky, Intel Middleware Products Division

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][security] Exception compatibility


On 9/4/06, Boris Kuznetsov [EMAIL PROTECTED] wrote:


Usually Harmony behavior is compared with RI behavior. But in security
area RI behavior depends on provider. With different providers RI
behave differently.

For example, RI passes incorrect method arguments to provider. In such
cases provider may throw exception (e.g. DigestException or
IllegalArgumentException) or some RuntimeException (e.g.
ArrayIndexOutOfBoundsException) may be thrown during the execution.
Here is example.

There are number of methods with arguments like (byte[] buf, int
offset, int len). RI doesn't check if offset and len are negative but
Harmony does, so we have difference in behavior (see Harmony-1120,
1148): on combination RI + provider application gets provider specific
exception, but on Harmony + provider - IllegalArgumentException (as in
other invalid parameters cases).

So we have two options:
1. Fix Harmony (remove negative parameters checks)
2. Don't fix. Throw IllegalArgumentException for invalid parameters.
Document as non-bug difference from RI.

Note, specification doesn't describe implementation behavior for
invalid arguments, but RI also throws IllegalArgumentException if
ofsset+len  buf.length. So throwing of IllegalArgumentException in
Harmony can't break any application.

I suggest option 2.



I like option1. Why not just pass all parameters to provider as RI, and let
the provider determine the behaviour?


Thoughts?


Thanks,
Boris

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Andrew Zhang
China Software Development Lab, IBM

Re: [classlib][luni] signalis interruptus in hysock

2006-09-04 Thread Jimmy, Jing Lv


Geir Magnusson Jr. wrote:



Artem Aliev wrote:
The hyport and hy* are a porting layer that provides os independent 
interface.

hysock_select() does not return EINTR on windows why it should do it
under linux?
either user presses Ctrl-c or ctrl-\ or VM uses other signals for its
owns needs.


I think you just gave me the answer.

The *caller* to hysock_select() needs to decide what to do on EINTR, not 
 hysock_select() itself.




+1 to this solution, let's first keep portlib as it is, IIRC, there's 
many native methods refers it.


But I'm still worry about ignore the signal in select(or its callers). I 
know few about the SIGUSR2, but I doubt if some user give a signal to 
the thread, how can our select process tell if the signal comes from 
user or form VM? Shall it continue anyway?
Mask the signal may be a better way, select only stop when a certain 
signal comes with a certain mask. However it may still puzzle the native 
code if user also use masks.


I was thinking the powerful SIGUSR2 may resolve some problem 
straightforwardly(like wakeup, etc.), but now I see there are still many 
problems.
I believe J9 was not using any lib like SIGUSR2, maybe they create and 
handle threads themselves (RI may do like this as well).


I'll keep an eye on the discussion, there are may select-related native 
codes to deal ...



I still don't think this is a perfect solution, but I think it's better :)

I still want to know about J9 though.  Maybe I need to go work for IBM 
again :)


geir


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][security] Exception compatibility


On 9/4/06, Boris Kuznetsov [EMAIL PROTECTED] wrote:

Usually Harmony behavior is compared with RI behavior. But in security
area RI behavior depends on provider. With different providers RI
behave differently.

For example, RI passes incorrect method arguments to provider. In such
cases provider may throw exception (e.g. DigestException or
IllegalArgumentException) or some RuntimeException (e.g.
ArrayIndexOutOfBoundsException) may be thrown during the execution.
Here is example.

There are number of methods with arguments like (byte[] buf, int
offset, int len). RI doesn't check if offset and len are negative but
Harmony does, so we have difference in behavior (see Harmony-1120,
1148): on combination RI + provider application gets provider specific
exception, but on Harmony + provider - IllegalArgumentException (as in
other invalid parameters cases).

So we have two options:
1. Fix Harmony (remove negative parameters checks)
2. Don't fix. Throw IllegalArgumentException for invalid parameters.
Document as non-bug difference from RI.

Note, specification doesn't describe implementation behavior for
invalid arguments, but RI also throws IllegalArgumentException if
ofsset+len  buf.length. So throwing of IllegalArgumentException in
Harmony can't break any application.

I suggest option 2.
Thoughts?


According to our Compatibility guidelines[1], I suggest we follow RI
for this issue, because the spec does not describe the behavior
clearly and it seems that RI's behavior is not so illogical ;-)

[1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html

Best regards,
Richard




Thanks,
Boris

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Richard Liang
China Software Development Lab, IBM

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: Re: [classlib][TestNG] groups of Harmony test


On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote:

On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:
 On 9/4/06, Alex Blewitt [EMAIL PROTECTED] wrote:
 
  If you've got fast and slow tests, then have a group for fast and slow
  tests. Then you can choose to just run the fast tests, and any
  automated build system can handle running the slow tests.

 IMHO, fast or slow may not be the key point. The question is whether we
 have any requirements to run only the regression tests.

No, probably not the key point, but (a) groups don't have to be
mutually exclusive (so you can decorate it with whatever groups you
want)


I agree. For example, os.win and os.linux are not mutually exclusive.

Thanks a lot.

and (b) it might be useful for an automated build system to run

fast tests first, followed by slow (or non-fast) tests.


That makes sense through we have not clear requirement currently.


Mind you, I don't know what's going to happen with an automated test'n'build
system; so it might not make sense to do it at this point.


Really? ;-) We could also discuss whether it's feasible to move to
TestNG. As you may know, there are already several threads about
TestNG  JUnit. Here I just review the open questions one by one so
that we have sufficient preparation.


[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
 PROTECTED]
[2]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
 PROTECTED]
[3]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
 PROTECTED]

Best regards,
Richard



Alex.

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Richard Liang
China Software Development Lab, IBM

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][security] Exception compatibility

2006-09-04 Thread Stepan Mishura


On 9/4/06, Boris Kuznetsov wrote:


Usually Harmony behavior is compared with RI behavior. But in security
area RI behavior depends on provider. With different providers RI
behave differently.

For example, RI passes incorrect method arguments to provider. In such
cases provider may throw exception (e.g. DigestException or
IllegalArgumentException) or some RuntimeException (e.g.
ArrayIndexOutOfBoundsException) may be thrown during the execution.
Here is example.

There are number of methods with arguments like (byte[] buf, int
offset, int len). RI doesn't check if offset and len are negative but
Harmony does, so we have difference in behavior (see Harmony-1120,
1148): on combination RI + provider application gets provider specific
exception, but on Harmony + provider - IllegalArgumentException (as in
other invalid parameters cases).

So we have two options:
1. Fix Harmony (remove negative parameters checks)
2. Don't fix. Throw IllegalArgumentException for invalid parameters.
Document as non-bug difference from RI.



Hi, Boris.

We agreed to be exceptions-compatible with RI so we would have chosen the
first option. But I think that the first option is not suitable. I'll try to
explain why. I have a look at MessageDigest.java and mentioned JIRAs: so
there are 4 cases when parameters are invalid and an implementation has to
check if:
1) buf - is null
2) offset  0
3) len  0
4) offset + len  buf's len

The first option means that we have to remove 2 and 3 checks. And leave 1
and 4 as RI does. But 4 check is meaningless without 2 and 3. IOW, it is
only valid if offset and len params are correct. IMO chosing the first
option is copying inconsistent behaviour. So I vote for the second option.

Thanks,
Stepan.

Note, specification doesn't describe implementation behavior for

invalid arguments, but RI also throws IllegalArgumentException if
ofsset+len  buf.length. So throwing of IllegalArgumentException in
Harmony can't break any application.

I suggest option 2.
Thoughts?

Thanks,
Boris

--

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: Re: [classlib][TestNG] groups of Harmony test


OK, let's return back to the usage model.
If I understood it correctly, before the commit of any changes each
developer run *all* tests (at least all which we have now) on all available
to him platforms. In this context seems we don't need in any 'level' group
(while 'stress' tests require reasonable time to pass).
Seems, that platform group also can be deleted (at present time we have
10 platform-dependent tests and this amount should not increase
dramatically so the platform-detection can be included to the each such
test).
Also cpu groups can be deleted (while we have not cpu-dependent test).
At the end we need only state groups to support test exclusion on the
'one-element' level (while we have unresolved entries in the current exclude
list).

So, after small update of unit (aka integration, aka regression etc) tests
and resolution of all entries in the exclude list we don't need any groups
and pure JUnit covers all our needs :)

On the other side, if we define some groups it will nice to define *all*
reasonable groups at the begin of the process.

thanks, Vladimir

By the way, our regression tests are 'classic' regression tests that
demonstrate some issues which were not resolved by initial code. But it
provides less coverage than 'regression tests' + unit tests, of cause.

On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote:


On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote:
 On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:
  On 9/4/06, Alex Blewitt [EMAIL PROTECTED]  wrote:
  
   If you've got fast and slow tests, then have a group for fast and
slow
   tests. Then you can choose to just run the fast tests, and any
   automated build system can handle running the slow tests.
 
  IMHO, fast or slow may not be the key point. The question is whether
we
  have any requirements to run only the regression tests.

 No, probably not the key point, but (a) groups don't have to be
 mutually exclusive (so you can decorate it with whatever groups you
 want)

I agree. For example, os.win and os.linux are not mutually exclusive.

Thanks a lot.

and (b) it might be useful for an automated build system to run
 fast tests first, followed by slow (or non-fast) tests.

That makes sense through we have not clear requirement currently.

 Mind you, I don't know what's going to happen with an automated
test'n'build
 system; so it might not make sense to do it at this point.

Really? ;-) We could also discuss whether it's feasible to move to
TestNG. As you may know, there are already several threads about
TestNG  JUnit. Here I just review the open questions one by one so
that we have sufficient preparation.


[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
 PROTECTED]

[2]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
 PROTECTED]

[3]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
 PROTECTED]


Best regards,
Richard


 Alex.

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




--
Richard Liang
China Software Development Lab, IBM

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][TestNG] groups of Harmony test

2006-09-04 Thread Alexey Varlamov


2006/9/4, Richard Liang [EMAIL PROTECTED]:



Alex Blewitt wrote:
 IMNSO it doesn't make sense to arbitrarily partition the tests based
 on a moniker, such as 'integration test', 'unit test', 'regression
 test' etc. For one thing, developers are generally not good at
 agreeing on the difference between them :-)

This is really a problem, however it might be simpler than we imagine.
We are open to any discussion. ;-) Anyway, developers are required to
write unit tests.


 If you've got fast and slow tests, then have a group for fast and slow
 tests. Then you can choose to just run the fast tests, and any
 automated build system can handle running the slow tests.
IMHO, fast or slow may not be the key point. The question is whether
we have any requirements to run only the regression tests.


I believe we have not. If a testcase was added to prevent regression,
it basically means that there was a hole in test coverage for some
reason. Provided that such holes are scattered randomly through the
given module, what for we may want to run such a sieve test suite?
I can think of the sole reason, that regression tests may
*potentially* highlight weak spots in the code (or design) which are
more prone to fail during code evolution. But still I see no reason to
run only regression tests ignoring others. I'd rather second Alex in
fast/slow grouping orthogonal to regressions.

As for information purposes, Mikhail (?) suggested good idea -
explicitly specify no. of the issue in descripton comment (or
annotation).

[snip]

--
Alexey

-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: Re: [classlib][TestNG] groups of Harmony test


On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:


OK, let's return back to the usage model.
If I understood it correctly, before the commit of any changes each
developer run *all* tests (at least all which we have now) on all
available
to him platforms.



Yes. But as you mentioned, what's all available?

If a test passes on windows while fails on linux, is it available to
windows?

If it is, how will we control it? TestNG groups.

In this context seems we don't need in any 'level' group

(while 'stress' tests require reasonable time to pass).
Seems, that platform group also can be deleted (at present time we have
10 platform-dependent tests and this amount should not increase
dramatically so the platform-detection can be included to the each such
test).
Also cpu groups can be deleted (while we have not cpu-dependent test).
At the end we need only state groups to support test exclusion on the
'one-element' level (while we have unresolved entries in the current
exclude
list).

So, after small update of unit (aka integration, aka regression etc) tests
and resolution of all entries in the exclude list we don't need any groups
and pure JUnit covers all our needs :)

On the other side, if we define some groups it will nice to define *all*
reasonable groups at the begin of the process.



Yes. We should figure out all possible groups. And it can be consolidated
during applying TestNG.

thanks, Vladimir


By the way, our regression tests are 'classic' regression tests that
demonstrate some issues which were not resolved by initial code. But it
provides less coverage than 'regression tests' + unit tests, of cause.

On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote:

 On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote:
  On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:
   On 9/4/06, Alex Blewitt [EMAIL PROTECTED]  wrote:
   
If you've got fast and slow tests, then have a group for fast and
 slow
tests. Then you can choose to just run the fast tests, and any
automated build system can handle running the slow tests.
  
   IMHO, fast or slow may not be the key point. The question is
whether
 we
   have any requirements to run only the regression tests.
 
  No, probably not the key point, but (a) groups don't have to be
  mutually exclusive (so you can decorate it with whatever groups you
  want)

 I agree. For example, os.win and os.linux are not mutually exclusive.

 Thanks a lot.

 and (b) it might be useful for an automated build system to run
  fast tests first, followed by slow (or non-fast) tests.

 That makes sense through we have not clear requirement currently.

  Mind you, I don't know what's going to happen with an automated
 test'n'build
  system; so it might not make sense to do it at this point.

 Really? ;-) We could also discuss whether it's feasible to move to
 TestNG. As you may know, there are already several threads about
 TestNG  JUnit. Here I just review the open questions one by one so
 that we have sufficient preparation.


 [1]http://mail-
archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]

 [2]http://mail-
archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]

 [3]http://mail-
archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]


 Best regards,
 Richard

 
  Alex.
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 Richard Liang
 China Software Development Lab, IBM

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]







--
Andrew Zhang
China Software Development Lab, IBM

Re: Re: Re: [classlib][TestNG] groups of Harmony test


One more note (seems it already was said sorry if I repeat): the test
without any marks should be run in all configurations (i.e. we have
'default' group but declaration of this group may be missed).

thanks, Vladimir


On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:


 OK, let's return back to the usage model.
If I understood it correctly, before the commit of any changes each
developer run *all* tests (at least all which we have now) on all available
to him platforms. In this context seems we don't need in any 'level' group
(while 'stress' tests require reasonable time to pass).
Seems, that platform group also can be deleted (at present time we have
10 platform-dependent tests and this amount should not increase
dramatically so the platform-detection can be included to the each such
test).
Also cpu groups can be deleted (while we have not cpu-dependent test).
At the end we need only state groups to support test exclusion on the
'one-element' level (while we have unresolved entries in the current exclude
list).

So, after small update of unit (aka integration, aka regression etc) tests
and resolution of all entries in the exclude list we don't need any groups
and pure JUnit covers all our needs :)

On the other side, if we define some groups it will nice to define *all*
reasonable groups at the begin of the process.

 thanks, Vladimir

By the way, our regression tests are 'classic' regression tests that
demonstrate some issues which were not resolved by initial code. But it
provides less coverage than 'regression tests' + unit tests, of cause.

 On 9/5/06, Richard Liang [EMAIL PROTECTED]  wrote:

 On 9/5/06, Alex Blewitt  [EMAIL PROTECTED] wrote:
  On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:
   On 9/4/06, Alex Blewitt [EMAIL PROTECTED]  wrote:
   
If you've got fast and slow tests, then have a group for fast and
 slow
tests. Then you can choose to just run the fast tests, and any
automated build system can handle running the slow tests.
  
   IMHO, fast or slow may not be the key point. The question is
 whether we
   have any requirements to run only the regression tests.
 
  No, probably not the key point, but (a) groups don't have to be
  mutually exclusive (so you can decorate it with whatever groups you
  want)

 I agree. For example, os.win and os.linux are not mutually exclusive.

 Thanks a lot.

 and (b) it might be useful for an automated build system to run
  fast tests first, followed by slow (or non-fast) tests.

 That makes sense through we have not clear requirement currently.

  Mind you, I don't know what's going to happen with an automated
 test'n'build
  system; so it might not make sense to do it at this point.

 Really? ;-) We could also discuss whether it's feasible to move to
 TestNG. As you may know, there are already several threads about
 TestNG  JUnit. Here I just review the open questions one by one so
 that we have sufficient preparation.


 
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
 PROTECTED]

 
[2]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
 PROTECTED]

 
[3]http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL
 PROTECTED]


 Best regards,
 Richard

 
  Alex.
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 


 --
 Richard Liang
 China Software Development Lab, IBM

 -
 Terms of use : http://incubator.apache.org/harmony/mailing.html
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: Re: [classlib][TestNG] groups of Harmony test


On 9/5/06, Andrew Zhang [EMAIL PROTECTED] wrote:


On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:

 OK, let's return back to the usage model.
 If I understood it correctly, before the commit of any changes each
 developer run *all* tests (at least all which we have now) on all
 available
 to him platforms.


Yes. But as you mentioned, what's all available?

If a test passes on windows while fails on linux, is it available to
windows?

If it is, how will we control it? TestNG groups.



If developer has only windows box than he should run tests on windows only.
If test fails on linux than (for example):
- the test/ implementation should be fixed or
- the test should define platform and report 'passed' if it does not
support current platform

In this context seems we don't need in any 'level' group

 (while 'stress' tests require reasonable time to pass).
 Seems, that platform group also can be deleted (at present time we
have
 10 platform-dependent tests and this amount should not increase
 dramatically so the platform-detection can be included to the each such
 test).
 Also cpu groups can be deleted (while we have not cpu-dependent test).
 At the end we need only state groups to support test exclusion on the
 'one-element' level (while we have unresolved entries in the current
 exclude
 list).

 So, after small update of unit (aka integration, aka regression etc)
tests
 and resolution of all entries in the exclude list we don't need any
groups
 and pure JUnit covers all our needs :)

 On the other side, if we define some groups it will nice to define *all*
 reasonable groups at the begin of the process.


Yes. We should figure out all possible groups. And it can be consolidated
during applying TestNG.



Agree.
thanks, Vladimir

thanks, Vladimir


 By the way, our regression tests are 'classic' regression tests that
 demonstrate some issues which were not resolved by initial code. But it
 provides less coverage than 'regression tests' + unit tests, of cause.

 On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote:
 
  On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote:
   On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:
On 9/4/06, Alex Blewitt [EMAIL PROTECTED]  wrote:

 If you've got fast and slow tests, then have a group for fast
and
  slow
 tests. Then you can choose to just run the fast tests, and any
 automated build system can handle running the slow tests.
   
IMHO, fast or slow may not be the key point. The question is
 whether
  we
have any requirements to run only the regression tests.
  
   No, probably not the key point, but (a) groups don't have to be
   mutually exclusive (so you can decorate it with whatever groups you
   want)
 
  I agree. For example, os.win and os.linux are not mutually exclusive.
 
  Thanks a lot.
 
  and (b) it might be useful for an automated build system to run
   fast tests first, followed by slow (or non-fast) tests.
 
  That makes sense through we have not clear requirement currently.
 
   Mind you, I don't know what's going to happen with an automated
  test'n'build
   system; so it might not make sense to do it at this point.
 
  Really? ;-) We could also discuss whether it's feasible to move to
  TestNG. As you may know, there are already several threads about
  TestNG  JUnit. Here I just review the open questions one by one so
  that we have sufficient preparation.
 
 
  [1]http://mail-

archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
 
  [2]http://mail-

archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
 
  [3]http://mail-

archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
 
 
  Best regards,
  Richard
 
  
   Alex.
  
  
-
   Terms of use : http://incubator.apache.org/harmony/mailing.html
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail:
[EMAIL PROTECTED]
  
  
 
 
  --
  Richard Liang
  China Software Development Lab, IBM
 
  -
  Terms of use : http://incubator.apache.org/harmony/mailing.html
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 




--
Andrew Zhang
China Software Development Lab, IBM

Re: Re: Re: [classlib][TestNG] groups of Harmony test


On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:


On 9/5/06, Andrew Zhang [EMAIL PROTECTED] wrote:

 On 9/5/06, Vladimir Ivanov [EMAIL PROTECTED] wrote:
 
  OK, let's return back to the usage model.
  If I understood it correctly, before the commit of any changes each
  developer run *all* tests (at least all which we have now) on all
  available
  to him platforms.


 Yes. But as you mentioned, what's all available?

 If a test passes on windows while fails on linux, is it available to
 windows?

 If it is, how will we control it? TestNG groups.


If developer has only windows box than he should run tests on windows
only.
If test fails on linux than (for example):
- the test/ implementation should be fixed or



What if the behaviour is different on different platforms?

- the test should define platform and report 'passed' if it does not

support current platform



How to define platform? Get platform information in test code?

In this context seems we don't need in any 'level' group

  (while 'stress' tests require reasonable time to pass).
  Seems, that platform group also can be deleted (at present time we
 have
  10 platform-dependent tests and this amount should not increase
  dramatically so the platform-detection can be included to the each
such
  test).
  Also cpu groups can be deleted (while we have not cpu-dependent
test).
  At the end we need only state groups to support test exclusion on
the
  'one-element' level (while we have unresolved entries in the current
  exclude
  list).
 
  So, after small update of unit (aka integration, aka regression etc)
 tests
  and resolution of all entries in the exclude list we don't need any
 groups
  and pure JUnit covers all our needs :)
 
  On the other side, if we define some groups it will nice to define
*all*
  reasonable groups at the begin of the process.


 Yes. We should figure out all possible groups. And it can be
consolidated
 during applying TestNG.


Agree.
thanks, Vladimir

thanks, Vladimir
 
  By the way, our regression tests are 'classic' regression tests that
  demonstrate some issues which were not resolved by initial code. But
it
  provides less coverage than 'regression tests' + unit tests, of cause.
 
  On 9/5/06, Richard Liang [EMAIL PROTECTED] wrote:
  
   On 9/5/06, Alex Blewitt [EMAIL PROTECTED] wrote:
On 04/09/06, Richard Liang [EMAIL PROTECTED] wrote:
 On 9/4/06, Alex Blewitt [EMAIL PROTECTED]  wrote:
 
  If you've got fast and slow tests, then have a group for fast
 and
   slow
  tests. Then you can choose to just run the fast tests, and any
  automated build system can handle running the slow tests.

 IMHO, fast or slow may not be the key point. The question is
  whether
   we
 have any requirements to run only the regression tests.
   
No, probably not the key point, but (a) groups don't have to be
mutually exclusive (so you can decorate it with whatever groups
you
want)
  
   I agree. For example, os.win and os.linux are not mutually
exclusive.
  
   Thanks a lot.
  
   and (b) it might be useful for an automated build system to run
fast tests first, followed by slow (or non-fast) tests.
  
   That makes sense through we have not clear requirement currently.
  
Mind you, I don't know what's going to happen with an automated
   test'n'build
system; so it might not make sense to do it at this point.
  
   Really? ;-) We could also discuss whether it's feasible to move to
   TestNG. As you may know, there are already several threads about
   TestNG  JUnit. Here I just review the open questions one by one so
   that we have sufficient preparation.
  
  
   [1]http://mail-
 

archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
  
   [2]http://mail-
 

archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
  
   [3]http://mail-
 

archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/[EMAIL PROTECTED]
  
  
   Best regards,
   Richard
  
   
Alex.
   
   
 -
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
 [EMAIL PROTECTED]
   
   
  
  
   --
   Richard Liang
   China Software Development Lab, IBM
  
  
-
   Terms of use : http://incubator.apache.org/harmony/mailing.html
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail:
[EMAIL PROTECTED]
  
  
 
 


 --
 Andrew Zhang
 China Software Development Lab, IBM







--
Andrew Zhang
China Software Development Lab, IBM

Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!

2006-09-04 Thread Stepan Mishura

On 9/4/06, Paulex Yangwrote:
Stepan Mishura wrote: On 9/1/06, Paulex Yang wrote: Stepan Mishura wrote:
  Hi Andrew,   I've just looked into static initialization block and then to the  spec. for  LogManager class.  My impression is that Harmony implementation doesn't follow the spec.
   The spec. says: At startup the LogManager class is located using the '  java.util.logging.manager' system property.By default, the LogManager  reads
  its initial configuration from a properties file  lib/logging.properties in  the JRE directory Stepan, I think the meaning of By default is debatable. Actually the spec
 looks like this: At startup the LogManager class is located using the java.util.logging.manager system property. By default, the LogManager reads its initial configuration from a
 properties file lib/logging.properties in the JRE directory. If you edit that property file you can change the default logging configuration for all uses of that JRE.
 In addition, the LogManager uses two optional system properties that allow more control over reading the initial configuration:* java.util.logging.config.class
* java.util.logging.config.file...  So I consider the By default doesn't necessarily means default case without 
java.util.logging.manager property, but means the default case without java.util.logging.config.class/file properties. A simple test on RI of specifying a customized MockLogManager by
 j.u.l.manager property shows the default lib/logging.properties does affect the behavior of the customized LogManager, say the root logger's level, etc.
 Do you mean that RI resets the root logger's level of customized LogManager to default value from lib/logging.properties?Yes, so I think customized LogManager also needs to initialize itself in
same procedure as j.u.l.LogManager.


Hi Paulex, 

I've implemented custom LogManager(see attachment):it sets value for root logger's level different from default value(INFO). According to my test (see attachment) RI doesn't change level of root logger.

Thetest prints the following:
$java -classpath . MyTest
INFO
$java -classpath . -Djava.util.logging.manager=CustomLogManager MyTest
SEVERE

Did I missed something?

Thanks,
Stepan.--Terms of use : http://incubator.apache.org/harmony/mailing.htmlTo unsubscribe, e-mail: 
[EMAIL PROTECTED]For additional commands, e-mail: [EMAIL PROTECTED]
 
import java.beans.PropertyChangeListener;
import java.io.IOException;
import java.io.InputStream;
import java.util.Enumeration;
import java.util.Hashtable;
import java.util.logging.Level;
import java.util.logging.LogManager;
import java.util.logging.Logger;

public class CustomLogManager extends LogManager {

private Hashtable loggers;

public CustomLogManager() {
}

public String getProperty(String p) {
return null;
}

public synchronized boolean addLogger(Logger logger) {
if (loggers.contains(logger)) {
return false;
}
loggers.put(logger.getName(), logger);
return true;
}

public synchronized Logger getLogger(String logger) {
return (Logger) loggers.get(logger);
}

public synchronized Enumeration getLoggerNames() {
return loggers.keys();
}

public void addPropertyChangeListener(PropertyChangeListener arg0)
throws SecurityException {
}

public void checkAccess() throws SecurityException {
}

public void readConfiguration() throws IOException, SecurityException {

loggers = new Hashtable();

// set root logger
Logger root = new Logger(, null) {
{
setLevel(Level.SEVERE);
}
};
loggers.put(, root);
}

public void readConfiguration(InputStream in) throws IOException,
SecurityException {
}

public void removePropertyChangeListener(PropertyChangeListener prop)
throws SecurityException {
}

public void reset() throws SecurityException {
}
}
import java.util.logging.LogManager;

public class MyTest {

public static void main(String[] args) {
System.out.println(LogManager.getLogManager().getLogger().getLevel());
}
}
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Re: Re: [classlib][TestNG] groups of Harmony test