Re: [general][testing] cruise control on the WinXP and SUSE linux
On 11/17/06, Vladimir Ivanov wrote: For the first notification: sometimes it happens :( Usually, the second run helps. For the second, I need more information. I never saw it before. Could you rerun it? I rerun it but it didn't helped. It seems that CC does nothing - no email notifications. And the last message it printed was: [cc]Nov-17 20:16:32 BuildQueue- BuildQueue started I've tried to check CC status via browser as README.txt suggests and I see: HTTP ERROR: 500 Unable to compile class for JSP RequestURI=/ Thanks, Stepan. Thanks, Vladimir On 11/16/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > Vladimir, > > I've applied the latest patch from HARMONY-995 and run CC. And it failed > on > Windows. However I've just built and run classlib's tests successfully. > I've > got 2 e-mail notifications. > > The first one is 724Kb and starts with: > > BUILD FAILED > Ant Error Message: > C:\users\smishura\buildtest\cc\projects\classlib\trunk\build.xml:123: The > following error occurred while executing this line: > C:\users\smishura\buildtest\cc\projects\classlib\trunk\make\build- java.xml > :96: > ... Built files still exist after module clean targets have run. This > probably means that one or more patternsets are incomplete. The remaining > files are: > > C:\users\smishura\buildtest\cc\projects\classlib\trunk\build\classes\com\sun\net\ssl\internal\ssl\Provider$1.class > > C:\users\smishura\buildtest\cc\projects\classlib\trunk\build\classes\com\sun\net\ssl\internal\ssl\Provider.class > .. > ... > > The second notification is small and it just says: > BUILD FAILED > Ant Error Message: error string found > > Any idea what is wrong? > > Thanks, > Stepan. > > On 11/16/06, Vladimir Ivanov wrote: > > > > On 11/16/06, Stepan Mishura wrote: > > > > > > Vladimir, > > > > > > Sorry, I didn't follow discussions about build-and-test infra. I've > done > > > check out of build-and-test workspace and I'm trying to set up it. I > > > have some questions: > > > - README.txt file says about downloading IBM VME and I guess you run > CC > > on > > > DRL VM. Does the file is up to date? > > > - 'ant setup' fetches CruiseControl and sets it up. But why I should > > fetch > > > classlib dependencies manually? IMHO, 'ant setup' should do it too. > > > > > > > > Thanks. You're the second person who asks about CC :) > > > > Actually, I use the updated version of script (this one + patch from > issue > > 995). The updated version has updated README.txt and also run build for > > classlib and drlvm modules. Please, try it. > > > > > > > > Thanks, Vladimir > > > > > > > > > Thanks, > > > Stepan. > > > > > > On 11/16/06, Vladimir Ivanov wrote: > > > > > > > > Thanks, today this test passed on both machines :( I hope, the CC > will > > > > send > > > > notification if this test fail again. > > > > > > > > Now, notifications should be sending to harmony-commits list from > the > > > > [EMAIL PROTECTED] address. > > > > > > > > > > > > > > > > Thanks, Vladimir > > > > > > > > On 11/16/06, Stepan Mishura wrote: > > > > > > > > > On 11/15/06, Vladimir Ivanov wrote: > > > > > > > > > > > > Sorry, I can't use the [EMAIL PROTECTED] > > > > > address. > > > > > > > > > > > > Sorry again, to test it I use the [EMAIL PROTECTED] as for > > IBM > > > > > > notifications without ask for permission :( > > > > > > > > > > > > > > > > > > > > > > > > Could somebody register some fake mail address in the > > > harmony-commits > > > > to > > > > > > use > > > > > > it for my CC notifications or I should use other alias or may be > > > other > > > > > > options exist? > > > > > > > > > > > > > > > > > > > > > > > > Thanks, Vladimir > > > > > > > > > > > > By the way, now my CC reports for both systems: > > > > > > Unit Test Error Details: (1)Test: test_Sign Class: > > > > > > org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest > > > > > > junit.framework.AssertionFailedError at &
Re: [drlvm][unit] New regression? org.apache.harmony.auth.tests.javax.security.auth.kerberos.serialization.KrbDelegationPermissionCollectionTest
On 11/17/06, Alexei Fedotov wrote: Folks, Has anyone seen the following problem in the whole test run? I cannot reproduce the problem for standalone test. (SuSE 9) Passed for me. Can you reproduce it by rerunning whole classlib test suite? Thanks, Stepan. org.apache.harmony.auth.tests.javax.security.auth.kerberos.serialization.KrbDelegationPermissionCollectionTest " name="testGolden" time="0.047"> java.io.IOException at java.io.IOException.<init>(IOException.java:35) at org.apache.harmony.luni.platform.OSFileSystem.close( OSFileSystem.java:203) at java.io.FileInputStream.close(FileInputStream.java:174) at org.apache.harmony.nio.internal.FileChannelImpl.implCloseChannel (FileChannelImpl.java:102) at java.nio.channels.spi.AbstractInterruptibleChannel.close( AbstractInterruptibleChannel.java:98) at java.io.FileInputStream.close(FileInputStream.java:167) at java.io.FilterInputStream.close(FilterInputStream.java) at java.io.BufferedInputStream.close(BufferedInputStream.java:121) at java.io.FilterInputStream.close(FilterInputStream.java) at java.io.ObjectInputStream.close(ObjectInputStream.java) at org.apache.harmony.testframework.serialization.SerializationTest.getObjectFromStream (SerializationTest.java:201) at org.apache.harmony.testframework.serialization.SerializationTest.getObject (SerializationTest.java:520) at org.apache.harmony.testframework.serialization.SerializationTest.verifyGolden (SerializationTest.java:428) at org.apache.harmony.testframework.serialization.SerializationTest.verifyGolden (SerializationTest.java:402) at org.apache.harmony.testframework.serialization.SerializationTest.testGolden (SerializationTest.java:146) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at org.apache.harmony.testframework.serialization.SerializationTest.runBare( SerializationTest.java:111) -- Stepan Mishura 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: [general][testing] cruise control on the WinXP and SUSE linux
Vladimir, I've applied the latest patch from HARMONY-995 and run CC. And it failed on Windows. However I've just built and run classlib's tests successfully. I've got 2 e-mail notifications. The first one is 724Kb and starts with: BUILD FAILED Ant Error Message: C:\users\smishura\buildtest\cc\projects\classlib\trunk\build.xml:123: The following error occurred while executing this line: C:\users\smishura\buildtest\cc\projects\classlib\trunk\make\build-java.xml:96: ... Built files still exist after module clean targets have run. This probably means that one or more patternsets are incomplete. The remaining files are: C:\users\smishura\buildtest\cc\projects\classlib\trunk\build\classes\com\sun\net\ssl\internal\ssl\Provider$1.class C:\users\smishura\buildtest\cc\projects\classlib\trunk\build\classes\com\sun\net\ssl\internal\ssl\Provider.class .. ... The second notification is small and it just says: BUILD FAILED Ant Error Message: error string found Any idea what is wrong? Thanks, Stepan. On 11/16/06, Vladimir Ivanov wrote: On 11/16/06, Stepan Mishura wrote: > > Vladimir, > > Sorry, I didn't follow discussions about build-and-test infra. I've done > check out of build-and-test workspace and I'm trying to set up it. I > have some questions: > - README.txt file says about downloading IBM VME and I guess you run CC on > DRL VM. Does the file is up to date? > - 'ant setup' fetches CruiseControl and sets it up. But why I should fetch > classlib dependencies manually? IMHO, 'ant setup' should do it too. Thanks. You're the second person who asks about CC :) Actually, I use the updated version of script (this one + patch from issue 995). The updated version has updated README.txt and also run build for classlib and drlvm modules. Please, try it. Thanks, Vladimir > Thanks, > Stepan. > > On 11/16/06, Vladimir Ivanov wrote: > > > > Thanks, today this test passed on both machines :( I hope, the CC will > > send > > notification if this test fail again. > > > > Now, notifications should be sending to harmony-commits list from the > > [EMAIL PROTECTED] address. > > > > > > > > Thanks, Vladimir > > > > On 11/16/06, Stepan Mishura wrote: > > > > > On 11/15/06, Vladimir Ivanov wrote: > > > > > > > > Sorry, I can't use the [EMAIL PROTECTED] mail > > > address. > > > > > > > > Sorry again, to test it I use the [EMAIL PROTECTED] as for IBM > > > > notifications without ask for permission :( > > > > > > > > > > > > > > > > Could somebody register some fake mail address in the > harmony-commits > > to > > > > use > > > > it for my CC notifications or I should use other alias or may be > other > > > > options exist? > > > > > > > > > > > > > > > > Thanks, Vladimir > > > > > > > > By the way, now my CC reports for both systems: > > > > Unit Test Error Details: (1)Test: test_Sign Class: > > > > org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest > > > > junit.framework.AssertionFailedError at > > > > > > > > > > org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest.test_Sign > > > > ( > > > > DigitalSignatureTest.java:135) at > > > > java.lang.reflect.VMReflection.invokeMethod(Native Method) > > > > > > > > > Hm, ... strange. The test passes for me on Linux and Windows. > > > > > > This is regression test for JSSE provider and it goes with a fix for > the > > > provider. So it can fail if CC doesn't perform classlib rebuild. And I > > > believe it does. > > > > > > Is the failure stable for you? Can you reproduce it? > > > > > > Thanks, > > > Stepan. > > > > > > On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > > > > > > > > 15.11.06, Gregory Shimansky<[EMAIL PROTECTED]> написал(а): > > > > > > Vladimir Ivanov wrote: > > > > > > > Hello everyone, > > > > > > > I started cruise control (stored in the "buildtest" module > with > > > > patch > > > > > from > > > > > > > issue 995) on the Windows XP and SUSE Linux boxes. > > > > > > > Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb > > HDD). > > > > > > > > > > > > > > On each platform cruise control runs (as separate pr
Re: [general][testing] cruise control on the WinXP and SUSE linux
Vladimir, Sorry, I didn't follow discussions about build-and-test infra. I've done check out of build-and-test workspace and I'm trying to set up it. I have some questions: - README.txt file says about downloading IBM VME and I guess you run CC on DRL VM. Does the file is up to date? - 'ant setup' fetches CruiseControl and sets it up. But why I should fetch classlib dependencies manually? IMHO, 'ant setup' should do it too. Thanks, Stepan. On 11/16/06, Vladimir Ivanov wrote: Thanks, today this test passed on both machines :( I hope, the CC will send notification if this test fail again. Now, notifications should be sending to harmony-commits list from the [EMAIL PROTECTED] address. Thanks, Vladimir On 11/16/06, Stepan Mishura wrote: > On 11/15/06, Vladimir Ivanov wrote: > > > > Sorry, I can't use the [EMAIL PROTECTED] mail > address. > > > > Sorry again, to test it I use the [EMAIL PROTECTED] as for IBM > > notifications without ask for permission :( > > > > > > > > Could somebody register some fake mail address in the harmony-commits to > > use > > it for my CC notifications or I should use other alias or may be other > > options exist? > > > > > > > > Thanks, Vladimir > > > > By the way, now my CC reports for both systems: > > Unit Test Error Details: (1)Test: test_Sign Class: > > org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest > > junit.framework.AssertionFailedError at > > > org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest.test_Sign > > ( > > DigitalSignatureTest.java:135) at > > java.lang.reflect.VMReflection.invokeMethod(Native Method) > > > Hm, ... strange. The test passes for me on Linux and Windows. > > This is regression test for JSSE provider and it goes with a fix for the > provider. So it can fail if CC doesn't perform classlib rebuild. And I > believe it does. > > Is the failure stable for you? Can you reproduce it? > > Thanks, > Stepan. > > On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > > > > 15.11.06, Gregory Shimansky<[EMAIL PROTECTED]> написал(а): > > > > Vladimir Ivanov wrote: > > > > > Hello everyone, > > > > > I started cruise control (stored in the "buildtest" module with > > patch > > > from > > > > > issue 995) on the Windows XP and SUSE Linux boxes. > > > > > Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb HDD). > > > > > > > > > > On each platform cruise control runs (as separate projects in СС > > > terms, all > > > > > settings have default values): > > > > > - build of classlib module (target: 'rebuild'); > > > > > - classlib tests on J9 VM (target 'test' in the classlib module); > > > > > - build of drlvm module (target: 'build'); > > > > > - vm tests (kernel+smoke+cunit, target: 'test' in the drlvm > module); > > > > > - classlib tests on DRL VM (target: 'test' in the classlib module > > with > > > - > > > > > Dtest.jre.home=drlvm); > > > > > > > > > > Is it OK to send my cruise control notifications to the > > > harmony-commits > > > > > list > > > > > in order to notify about regressions? > > > > > > > > > > I suspect the notifications are not ideal but I will work on their > > > > > improvement upon precedents (false alarms) and your feedback > > > > > > > > I am +1 for cruise control and notifications to harmony-commit. > > > > > > > > But I wonder about linux version choice. If it is SuSE9, then could > we > > > > upgrade it to SuSE10 or install another distribution like FC5 with > gcc > > > > 4.1.x? This will help a lot with compilation errors which gcc 3.3.3on > > > > SuSE9 doesn't report. > > > Good point, I support this. > > > Alexey > -- Stepan Mishura 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: [general][testing] cruise control on the WinXP and SUSE linux
On 11/15/06, Vladimir Ivanov wrote: Sorry, I can't use the [EMAIL PROTECTED] mail address. Sorry again, to test it I use the [EMAIL PROTECTED] as for IBM notifications without ask for permission :( Could somebody register some fake mail address in the harmony-commits to use it for my CC notifications or I should use other alias or may be other options exist? Thanks, Vladimir By the way, now my CC reports for both systems: Unit Test Error Details: (1)Test: test_Sign Class: org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest junit.framework.AssertionFailedError at org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest.test_Sign ( DigitalSignatureTest.java:135) at java.lang.reflect.VMReflection.invokeMethod(Native Method) Hm, ... strange. The test passes for me on Linux and Windows. This is regression test for JSSE provider and it goes with a fix for the provider. So it can fail if CC doesn't perform classlib rebuild. And I believe it does. Is the failure stable for you? Can you reproduce it? Thanks, Stepan. On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > 15.11.06, Gregory Shimansky<[EMAIL PROTECTED]> написал(а): > > Vladimir Ivanov wrote: > > > Hello everyone, > > > I started cruise control (stored in the "buildtest" module with patch > from > > > issue 995) on the Windows XP and SUSE Linux boxes. > > > Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb HDD). > > > > > > On each platform cruise control runs (as separate projects in СС > terms, all > > > settings have default values): > > > - build of classlib module (target: 'rebuild'); > > > - classlib tests on J9 VM (target 'test' in the classlib module); > > > - build of drlvm module (target: 'build'); > > > - vm tests (kernel+smoke+cunit, target: 'test' in the drlvm module); > > > - classlib tests on DRL VM (target: 'test' in the classlib module with > - > > > Dtest.jre.home=drlvm); > > > > > > Is it OK to send my cruise control notifications to the > harmony-commits > > > list > > > in order to notify about regressions? > > > > > > I suspect the notifications are not ideal but I will work on their > > > improvement upon precedents (false alarms) and your feedback > > > > I am +1 for cruise control and notifications to harmony-commit. > > > > But I wonder about linux version choice. If it is SuSE9, then could we > > upgrade it to SuSE10 or install another distribution like FC5 with gcc > > 4.1.x? This will help a lot with compilation errors which gcc 3.3.3 on > > SuSE9 doesn't report. > Good point, I support this. > -- > Alexey > > > > > -- > > Gregory > > > > > -- Stepan Mishura 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][swing] Serialization of Swing classes
On 11/13/06, Ivanov, Alexey A wrote:
>-Original Message-
>From: Tim Ellison
>Sent: Sunday, November 12, 2006 1:12 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][swing] Serialization of Swing classes
>
>Nathan Beyer wrote:
>> Runtime optimization - I'm not positive of this, nor do I completely
>> understand the actual affect, but wouldn't explicit
'serialVersionUID'
>> fields mean that when those classes are actually serialized, a UID
>> wouldn't need to be generated at runtime, correct? Now, I'll be the
>> first to admit, this is a micro optimization, so it doesn't carry to
>> much weight. However, I am curious about the details of the reality
>> behind this thought, so if anyone knows, please post.
>
>Take a look at the effect of "java.io.ObjectStreamClass#lookup(Class)"
>for types that have a SUID field and those that don't.
>
>The actual work is done in
>ObjectStreamClass#computeSerialVersionUID(Class, Field[]), which scans
>the fields looking for a serialVersionUID field first, and computing it
>if not found using some non-trivial algorithm.
>
>The lookup result is cached, so any saving will be only on the first
>time the class is seen. Whether the computation is noticeable will
>depend upon the set of classes of objects being serialized as well as
>the presence (or absence) of the SUID field.
Actually I don't mind having SUIDs declared in classes. Though IMHO
without declaring this field, we communicate to developers serialized
form of this class is not guaranteed to deserialize correctly. OTOH
having looked through the methods Tim pointed, I can say that if classes
declare SUID and one tries to serialize an object, there'll be no time
spent to compute SUID during execution thus improving performance a
little.
Therefore I'm inclined to declare SUID rather than using
@SuppressWarning("serial"). However it may be worth to add a comment
similar to that in the JavaDoc. What do you think?
+1
-Stepan.
Regards,
Alexey.
>
>Regards,
>Tim
>
>--
>
>Tim Ellison ([EMAIL PROTECTED])
>IBM Java technology centre, UK.
--
Alexey A. Ivanov
Intel Enterprise Solutions Software Division
--
Stepan Mishura
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: Japi diffs for harmony
On 11/9/06, Ivanov, Alexey A wrote: >-Original Message- >From: Nathan Beyer [mailto:[EMAIL PROTECTED] >Sent: Thursday, November 09, 2006 5:49 AM >To: harmony-dev@incubator.apache.org >Subject: Re: Japi diffs for harmony > >No problem on the name change, but doesn't what Stuart is talking >about require that methods add this exception to the signature to >actually show up in the reports? I guess the answer is yes. They can be added lazily when unimplemented methods are spotted. And new stubs should have this throws from the beginning. Maybe it's worth putting this info somewhere on the site. Added to [1] at r474287. -Stepan. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements.html Also having this kind of declaration will simplify searching for not implemented methods. Regards, Alexey. > >On 11/8/06, Tim Ellison <[EMAIL PROTECTED]> wrote: >> Stuart Ballard wrote: >> > Tim Ellison wrote: >> >> I'm no fan of stubs for just such reason. But for those dev's that >are >> >> following along, there is an >> >> org.apache.harmony.luni.util.NotYetImplementedException that is >defined >> >> for just such purposes. >> > >> > Would you consider renaming this to NotImplementedException since Japi >> > recognizes that name in throws clauses and treats it specially? >> > >> > If you feel strongly about not changing the existing name, I can add >> > NotYetImplementedException as an alternative hardcoded name in >> > Japitools but that seems kinda redundant... >> > >> > What do you think? >> >> I have no objection to renaming it. If nobody objects in the next day >> or so then I'll go ahead and do it. >> >> Regards, >> Tim >> >> -- >> >> Tim Ellison ([EMAIL PROTECTED]) >> IBM Java technology centre, UK. >> -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -- Stepan Mishura 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: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
On 11/8/06, Ivanov, Alexey A wrote: >-Original Message- >From: Stepan Mishura >Sent: Wednesday, November 08, 2006 4:09 PM >To: harmony-dev@incubator.apache.org >Subject: Re: svn commit: r472115 - >/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm >on/javax/swing/text/GapContent.java > >On 11/8/06, Ivanov, Alexey A wrote: >> >> Stepan, >> >> I must be missing something obvious... >> What kind of regression test do you expect? > > >My logic is quite straightforward: the best way to fix a decision is to >create a regression test. For example, if another volunteer find out that >Harmony implementation of GapContent differ from RI's and propose a patch >to >fix it will any test remind him (or committer) about the decision? To summarize my position: I see no value in discussing compatibility issues on harmony-dev if a discussion doesn't have any outcome (JIRA to document a difference or a regression test to fix implementation behavior). In our case evaluation of HARMONY-1809 and HARMONY-1975 showed a difference with RI. So we should fix/document it. Does this fit to 'Good Issue Resolution Guideline'? If a volunteer wants to make Harmony implementation of GapContent.replace() compatible with RI, they will provide many tests - to test all invalid and edge situations to ensure the behaviour is *compatible* - along with patch. And I see no reason to stop them. Sure, no reason to stop. (However, I believe a volunteer will search JIRA for GapContent before starting this work. And then they face this bug.) On the other hand, I hardly imagine an application depends on this functionality. That's why I haven't fixed it myself. IMHO, an assumption that there is no such application is not a reason for not documenting the difference. >In our case we decided not to follow RI and do nothing for invalid >parameters. So a regression test should verify that Harmony silently >ignores >bad parameters. It may make sense. From my experience it always makes sense to add a test (even simple and obvious). Thanks, Stepan. >BWT, HARMONY-1809 should be marked as "non-bug difference from RI". I'm against this. > >Thanks, >Stepan. > >What was done is the signature of the GapContent.replace had been >> changed so that it didn't contain 'throws BadLocationException' clause. >> >> What is a regression test to demonstrate? That BadLocationException is >> not thrown any more? >> Or do you insist on setting gapStart to -2 after call replace(-2, 2, >> null, 0), so that any subsequent operation on GapContent generates >> ArrayIndexOutOfBounds? >> >> Regards, >> Alexey. >> >> >> P.S. The discussion thread: >> http://thread.gmane.org/gmane.comp.java.harmony.devel/17837/focus=17837 >> The related JIRA issues: >> https://issues.apache.org/jira/browse/HARMONY-1809 >> https://issues.apache.org/jira/browse/HARMONY-1975 >> >> >> -- >> Alexey A. Ivanov >> Intel Middleware Product Division >> >> >> >-Original Message- >> >From: Stepan Mishura [mailto: [EMAIL PROTECTED] ] >> >Sent: Wednesday, November 08, 2006 9:12 AM >> >To: harmony-dev >> >Subject: Re: svn commit: r472115 - >> >/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ >> comm >> >on/javax/swing/text/GapContent.java >> > >> >Hi, >> > >> >Any chance to see regression test (that I asked for in HARMONY-1975)? >> :-) >> > >> >Thanks, >> >Stepan. >> > >> >>-Original Message- >> >>From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] ] >> >>Sent: Tuesday, November 07, 2006 7:50 PM >> >>To: [EMAIL PROTECTED] >> >>Subject: svn commit: r472115 - >> >>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java >> /com >> >m >> > >> >>on/javax/swing/text/GapContent.java >> >> >> >>Author: apetrenko >> >>Date: Tue Nov 7 05:50:07 2006 >> >>New Revision: 472115 >> >> >> >>URL: http://svn.apache.org/viewvc?view=rev&rev=472115 >> >>Log: >> >>Patch for HARMONY-1809 >> >>"[classlib][swing]javax.swing.text.GapContent.replace(int, int, >> >> java.lang.Object, int) throws unspescified BadLocationException" >> >> >> >>Modified: >> >> >> >>incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ >> comm >> >o >> >>n/javax/swing/text/GapContent.java >> >> >> > >> >> >-- >Stepan Mishura >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] -- Alexey A. Ivanov Intel Middleware Product Division -- Stepan Mishura 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: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
On 11/8/06, Ivanov, Alexey A wrote: >-Original Message- >From: Oleg Khaschansky >Sent: Wednesday, November 08, 2006 4:20 PM >To: harmony-dev@incubator.apache.org >Subject: Re: svn commit: r472115 - >/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm >on/javax/swing/text/GapContent.java > >> BWT, HARMONY-1809 should be marked as "non-bug difference from RI". >I don't think that it's non-bug diff since it fixes an API issue. I agree. This issue fixes "bad method" from JAPItools. Then we should create another JIRA to document the difference. -Stepan. Regards, Alexey. > >On 11/8/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: >> On 11/8/06, Ivanov, Alexey A wrote: >> > >> > Stepan, >> > >> > I must be missing something obvious... >> > What kind of regression test do you expect? >> >> >> My logic is quite straightforward: the best way to fix a decision is to >> create a regression test. For example, if another volunteer find out that >> Harmony implementation of GapContent differ from RI's and propose a patch >to >> fix it will any test remind him (or committer) about the decision? >> >> In our case we decided not to follow RI and do nothing for invalid >> parameters. So a regression test should verify that Harmony silently >ignores >> bad parameters. >> >> BWT, HARMONY-1809 should be marked as "non-bug difference from RI". >> >> Thanks, >> Stepan. >> >> What was done is the signature of the GapContent.replace had been >> > changed so that it didn't contain 'throws BadLocationException' clause. >> > >> > What is a regression test to demonstrate? That BadLocationException is >> > not thrown any more? >> > Or do you insist on setting gapStart to -2 after call replace(-2, 2, >> > null, 0), so that any subsequent operation on GapContent generates >> > ArrayIndexOutOfBounds? >> > >> > Regards, >> > Alexey. >> > >> > >> > P.S. The discussion thread: >> > http://thread.gmane.org/gmane.comp.java.harmony.devel/17837/focus=17837 >> > The related JIRA issues: >> > https://issues.apache.org/jira/browse/HARMONY-1809 >> > https://issues.apache.org/jira/browse/HARMONY-1975 >> > >> > >> > -- >> > Alexey A. Ivanov >> > Intel Middleware Product Division >> > >> > >> > >-Original Message- >> > >From: Stepan Mishura [mailto: [EMAIL PROTECTED] ] >> > >Sent: Wednesday, November 08, 2006 9:12 AM >> > >To: harmony-dev >> > >Subject: Re: svn commit: r472115 - >> > >>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java / >> > comm >> > >on/javax/swing/text/GapContent.java >> > > >> > >Hi, >> > > >> > >Any chance to see regression test (that I asked for in HARMONY-1975)? >> > :-) >> > > >> > >Thanks, >> > >Stepan. >> > > >> > >>-Original Message- >> > >>From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] >> > >>Sent: Tuesday, November 07, 2006 7:50 PM >> > >>To: [EMAIL PROTECTED] >> > >>Subject: svn commit: r472115 - >> > >>>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/jav a >> > /com >> > >m >> > > >> > >>on/javax/swing/text/GapContent.java >> > >> >> > >>Author: apetrenko >> > >>Date: Tue Nov 7 05:50:07 2006 >> > >>New Revision: 472115 >> > >> >> > >>URL: http://svn.apache.org/viewvc?view=rev&rev=472115 >> > >>Log: >> > >>Patch for HARMONY-1809 >> > >>"[classlib][swing]javax.swing.text.GapContent.replace(int, int, >> > >>java.lang.Object, int) throws unspescified BadLocationException" >> > >> >> > >>Modified: >> > >> >> > >>>incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java / >> > comm >> > >o >> > >>n/javax/swing/text/GapContent.java >> > >> >> > > >> > >> > >> -- >> Stepan Mishura >> 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] >> >> -- Alexey A. Ivanov Intel Middleware Product Division -- Stepan Mishura 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: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
On 11/8/06, Ivanov, Alexey A wrote: Stepan, I must be missing something obvious... What kind of regression test do you expect? My logic is quite straightforward: the best way to fix a decision is to create a regression test. For example, if another volunteer find out that Harmony implementation of GapContent differ from RI's and propose a patch to fix it will any test remind him (or committer) about the decision? In our case we decided not to follow RI and do nothing for invalid parameters. So a regression test should verify that Harmony silently ignores bad parameters. BWT, HARMONY-1809 should be marked as "non-bug difference from RI". Thanks, Stepan. What was done is the signature of the GapContent.replace had been changed so that it didn't contain 'throws BadLocationException' clause. What is a regression test to demonstrate? That BadLocationException is not thrown any more? Or do you insist on setting gapStart to -2 after call replace(-2, 2, null, 0), so that any subsequent operation on GapContent generates ArrayIndexOutOfBounds? Regards, Alexey. P.S. The discussion thread: http://thread.gmane.org/gmane.comp.java.harmony.devel/17837/focus=17837 The related JIRA issues: https://issues.apache.org/jira/browse/HARMONY-1809 https://issues.apache.org/jira/browse/HARMONY-1975 -- Alexey A. Ivanov Intel Middleware Product Division >-Original Message- >From: Stepan Mishura [mailto: [EMAIL PROTECTED] ] >Sent: Wednesday, November 08, 2006 9:12 AM >To: harmony-dev >Subject: Re: svn commit: r472115 - >/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm >on/javax/swing/text/GapContent.java > >Hi, > >Any chance to see regression test (that I asked for in HARMONY-1975)? :-) > >Thanks, >Stepan. > >>-Original Message- >>From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] >>Sent: Tuesday, November 07, 2006 7:50 PM >>To: [EMAIL PROTECTED] >>Subject: svn commit: r472115 - >>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java /com >m > >>on/javax/swing/text/GapContent.java >> >>Author: apetrenko >>Date: Tue Nov 7 05:50:07 2006 >>New Revision: 472115 >> >>URL: http://svn.apache.org/viewvc?view=rev&rev=472115 >>Log: >>Patch for HARMONY-1809 >>"[classlib][swing]javax.swing.text.GapContent.replace(int, int, >>java.lang.Object, int) throws unspescified BadLocationException" >> >>Modified: >> >>incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/ comm >o >>n/javax/swing/text/GapContent.java >> > -- Stepan Mishura 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] [suncompat] completion (was; Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1)
On 11/8/06, Tim Ellison wrote:
Nathan Beyer wrote:
> I just looked at the changes you made and have a question about this
> snippet.
>
> +if (VM.callerClassLoader() != null) {
> +throw new SecurityException("Unsafe");
> +}
>
> I just want to understand what this actually means. If the
> 'callerClassLoader' is null, then the caller is the bootstrap class
> loader, correct? Assuming that's correct, we're asserting that only
> classes in the bootstrap class loader can call Unsafe, correct?
Exactly, we are saying that only 'system' code (i.e. that on the
bootclasspath) can get an instance of Unsafe because of the inherent
dangers in the Unsafe APIs. It is then the responsibility of such
system code not to release the instance of Unsafe to application code.
IMO, if this piece of code may cause questions then it makes sense to add
comments above to the code. Just to avoid similar questions in future.
Thanks,
Stepan.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Stepan Mishura
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: svn commit: r472149 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java
Hi Alexei, Sorry, I don't understand your logic. Is the test case valid? If there was another bug (for example: "[another_VM][unit] half of classlib beans tests crashes VM"), would you agree to comment out a half of beans tests? Thanks, Stepan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 10:09 PM To: [EMAIL PROTECTED] Subject: svn commit: r472149 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/ apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java Author: ayza Date: Tue Nov 7 08:09:27 2006 New Revision: 472149 URL: http://svn.apache.org/viewvc?view=rev&rev=472149 Log: I commented out testInitialize_circularRedundancy test since it crashes DRLVM DEBUG build (HARMONY-2073) and no prompt solution has been provided. Modified: incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/a pache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java Modified: incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/a pache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modu les/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/Persisten ceDelegateTest.java?view=diff&rev=472149&r1=472148&r2=472149 ======= -- Stepan Mishura 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: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java
Hi, Any chance to see regression test (that I asked for in HARMONY-1975)? :-) Thanks, Stepan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 07, 2006 7:50 PM To: [EMAIL PROTECTED] Subject: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/comm on/javax/swing/text/GapContent.java Author: apetrenko Date: Tue Nov 7 05:50:07 2006 New Revision: 472115 URL: http://svn.apache.org/viewvc?view=rev&rev=472115 Log: Patch for HARMONY-1809 "[classlib][swing]javax.swing.text.GapContent.replace(int, int, java.lang.Object, int) throws unspescified BadLocationException" Modified: incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/commo n/javax/swing/text/GapContent.java -- Stepan Mishura 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][swing] compatibility: j.s.text.GapContent.replace() behaviour
On 11/3/06, Ivanov, Alexey A wrote: >-Original Message- >From: Stepan Mishura >Sent: Friday, November 03, 2006 9:43 AM >To: harmony-dev@incubator.apache.org >Subject: Re: [classlib][swing] compatibility: j.s.text.GapContent.replace() >behaviour > >On 11/2/06, Ivanov, Alexey A wrote: >> >> Hi all, >> >> I've started fixing HARMONY-1809. To remove throws clause from the >> declaration of replace method, as it was proposed by Oleg in >> HARMONY-1975, I placed removeItems() and insertItems() calls into >> try-catch block. This would work OK for any valid arguments. >> >> >> >> Any objections, comments, opinions? > > > >Hi Alexey, Hi Stepan, >I'm not quite convinced by your evaluation (I'm not an expert in Swing API >so I may be wrong). My experiments with GapContent showed that Harmony Let me give a quick introduction what GapContent is then. This class serves as the default storage for all Document implementations within javax.swing.text. It stores text in char[] array... but with a gap in it. Using the default constructor the array will have length 10. And one character will be placed into the buffer; the other 9 characters in the array will be the gap, and they are not considered to be portion of the content. This prevents frequent re-allocations of the underlying storage array where text is inserted or removed. Moving the gap is cheaper than re-allocating the array. When an insert or remove occurs, the gap is moved so that it starts at the position of insert or remove. Thanks for the explanation. initially created different object then RI, for example, if you create an >object with GapContent() constructor, Harmony will return start==0 and >end==9 while RI will return start==1 and end==10. The next point that It doesn't really matter where the gap is. This difference shows only that the gap in the text buffer is located at different location. Using content.shiftGap(0) on RI, you'll get start = 0, end = 9. Accordingly using content.shiftGap(1) on Harmony, you'll get start = 1, end = 10. IMO it might be compatibly issue. I can extend GapContent class and it may depend on what getGapStart() and getGapEnd() return. What matters is that content.length() = 1 in both cases, and content.getString(0, content.length()) returns "\n". Actually, setting the gap to be at 0 is more efficient because the next (or first) insert is likely to happen at position 0 rather than 1. Therefore to insert text at position 0, the gap will be moved to 0 on RI (which involves array copying and some other operations). This won't be the case with Harmony because the gap is already at 0. If you do: GapContent gc = new GapContent(); gc.insertString(0, "text"); then gc.getGapStart() returns 4 on RI not 0 as you wrote. confuses me that the spec. says about position as "logical position in the >storage"...and... "This is not the location in the underlying storage >array". So negative value for position may be considered as valid. It's all about how the text is stored in GapContent. Because there's a gap modeled "the location in the underlying storage array" differs from "the logical position in storage". If you look at the spec of any methods which throw BadLocationException, you'll see that position (it's called 'where') is to be >= 0. Since this method is used to perform operations of insertString() and remove() in RI, negative positions are invalid. I believe they put no checks here because validation of parameters is performed in those methods which call replace(). As I understood the spec. it is true for methods that change content but there is no such restriction for methods that work with gap (see shiftGapEndUp, shiftGapStartDown, shiftEnd, shiftGap) Another point is that replace() in never used in Harmony implementation - it's called from tests only. But it can be used by some app. so it should be compatible. Thanks, Stepan. Thanks, Alexey. P.S. The related JIRA issues: https://issues.apache.org/jira/browse/HARMONY-1809 https://issues.apache.org/jira/browse/HARMONY-1975 GapContent Javadoc: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html Description of GapContent.replace: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html #replace(int,%20int,%20java.lang.Object,%20int) -- Alexey A. Ivanov Intel Middleware Product Division -- Stepan Mishura 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] -- Alexey A. Ivanov Intel Middleware Product Division -- Stepan Mishura 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][swing] compatibility: j.s.text.GapContent.replace() behaviour
On 11/2/06, Ivanov, Alexey A wrote: Hi all, I've started fixing HARMONY-1809. To remove throws clause from the declaration of replace method, as it was proposed by Oleg in HARMONY-1975, I placed removeItems() and insertItems() calls into try-catch block. This would work OK for any valid arguments. I was going to handle invalid arguments by making adjustments so that the following removeItems() and insertItems() will not throw the exception. After I wrote several tests, I faced strange behaviour of RI with regards to invalid arguments to replace. (The Javadoc say nothing about which valid ranges for replace() parameters as well as any exceptions.) RI accepts invalid arguments but the result differs from what I'd expect. For example, if the content has "text" in it, I'd expect that content.replace(-2, 4, null, 0) would give "xt" as the result. I mean the invalid start position is adjusted to 0, and the length of remove is adjusted to be 2 accordingly. But this is not the case. As the result of this call, all characters are removed leaving "" in the content. Moreover the content object becomes unusable after that: content.insertString(0, "1") throws ArrayIndexOutOfBoundsException. Similarly if number of characters to be removed is greater than the length of the content (content.replace(2, 4, null, 0) with "text" in it), the object will throw ArrayIndexOutOfBoundsException when doing insertString. Considering the fact that GapContent is pretty low-level class in text representation model and that it is protected, I think that Harmony implementation can silently ignore BadLocationException possible thrown from insertItems() and removeItems(). Taking into account erroneous behaviour of RI's replace, we can do that until an application is broken. As another option, we can throw an Error from catch block to make application which depends on implementation of replace() fast-fail. Any objections, comments, opinions? Hi Alexey, I'm not quite convinced by your evaluation (I'm not an expert in Swing API so I may be wrong). My experiments with GapContent showed that Harmony initially created different object then RI, for example, if you create an object with GapContent() constructor, Harmony will return start==0 and end==9 while RI will return start==1 and end==10. The next point that confuses me that the spec. says about position as "logical position in the storage"...and... "This is not the location in the underlying storage array". So negative value for position may be considered as valid. Thanks, Stepan. Thanks, Alexey. P.S. The related JIRA issues: https://issues.apache.org/jira/browse/HARMONY-1809 https://issues.apache.org/jira/browse/HARMONY-1975 GapContent Javadoc: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html Description of GapContent.replace: http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.html #replace(int,%20int,%20java.lang.Object,%20int) -- Alexey A. Ivanov Intel Middleware Product Division -- Stepan Mishura 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: [security][testing] unexpected unit test failure
Fixed at r470318. Please verify. -Stepan. On 11/2/06, Vladimir Ivanov wrote: Could somebody look at new unit test failure (winXP, j9): Test: testGenKey_keyPair Class: org.apache.harmony.tools.keytool.tests.GenKeyTest junit.framework.AssertionFailedError: Cannot create a temporary file C:\DOCUME~1\vivanov1\LOCALS~1\Temp\\GenKeyTestTemporaryFile. File with such name already exists.at org.apache.harmony.tools.keytool.tests.GenKeyTest.testGenKey_keyPair( GenKeyTest.java:61) at java.lang.reflect.AccessibleObject.invokeV( AccessibleObject.java:25) Thanks, Vladimir -- Stepan Mishura 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: [general] Re: svn commit: r469512 - in /incubator/harmony/standard/site: docs/contributors.html xdocs/contributors.xml
On 11/1/06, Alexey Petrenko wrote: I think you should add it to the end... :) They were sorted by "last-name alpha order". -Stepan. 2006/11/1, Alexei Zakharov <[EMAIL PROTECTED]>: > Cool, congratulation! BTW, shouldn't this list be ordered somehow? > Looks like it will be long enough pretty soon. Or this is a kind of > historical document? ;) > Just worring about where to put my name when the time (i.e. login) comes. > > Regards, > > 2006/10/31, Alexey Petrenko <[EMAIL PROTECTED]>: > > Yep. Hurray! > > It works... finally :) > > > > SY, Alexey > > > > 2006/10/31, Tim Ellison <[EMAIL PROTECTED]>: > > > Hurray! > > > > > > [EMAIL PROTECTED] wrote: > > > > Author: apetrenko > > > > Date: Tue Oct 31 06:57:44 2006 > > > > New Revision: 469512 > > > > > > > > URL: http://svn.apache.org/viewvc?view=rev&rev=469512 > > > > Log: > > > > I've added myself to the list of committers. > > > -- > Alexei Zakharov, > Intel Enterprise Solutions Software Division > -- Alexey A. Petrenko Intel Middleware Products Division -- Stepan Mishura 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][swing] javax.swing.filechooser.FileSystemViewTest failure on WinXP
Nathan, The issues should be fixed by HARMONY-1893. I've committed the fix at r469056. Thanks, Stepan. On 10/30/06, Nathan Beyer wrote: I'm seeing a failure in the javax.swing.filechooser.FileSystemViewTest on WinXP in the 'testGetSystemTypeDescription' test. Here's the failure and stack trace. expected: but was: junit.framework.ComparisonFailure: expected: but was: at javax.swing.filechooser.FileSystemViewTest.testGetSystemTypeDescription( FileSystemViewTest.java:96) Is this an OS difference or perhaps a inappropriate localization test (asserting the value of displayed string)? -Nathan -- Stepan Mishura 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: [general] POLL : supported platforms
On 26 Oct 2006 10:49:10 +0700, Egor Pasko wrote: On the 0x20D day of Apache Harmony Stepan Mishura wrote: > On 10/16/06, Geir Magnusson Jr. wrote: > > > > We're a volunteer project, so "supported" is based on interest in > > community. Lets be clear by writing down a set of platforms that we as > > a community commit to support. > > > > I think we can define "support" as - "one or more people in the > > community tests on that platform on a regular basis, there are users > > that use that platform, and we have people volunteering to find and fix > > bugs that specifically affect that platform" > > > > Just throw things out there and we'll gather the results and see what's > > popular. We'll summarize in 3 days. Please be clear in indicating what > > you think should be reported. Don't vote against anything. To start, > > using a broad brush : > > > Geir, > > I'd like to summarize the discussion to put the summary to web-site. I'm > going to add something like: "We aimed to support wide range of different > platforms. The main criteria if platform is supported or not is that there > are people interesting in running test on regular base, reporting build > status, finding and fixing bugs for that platform. A list of currently > supported platforms can be found at > http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. " Stepan, that's "HDK runs on the following platforms". DRLVM guys do not use HDK (correct me here). So, I was expecting to see: "Harmony (DRLVM) builds and runs on the following platforms". "Runs" is something more common than "builds", and we want "builds" :) So, we still mean different things when we say "supported". (not my fav. word) Does it make sense to create a separate page for that or enhance the existing one? Or, maybe, it does not make sense at all? ;o) IMO, it makes sense to fix results of the discussion. From my POV the main point is how we define "support" and what it means for us. After we agree on that we can move to details. Thanks, Stepan. > BTW, I think we can also use as indication if a platform is supported if > someone set up Harmony build-and-test infra on the platform and regularly > run it. > > Comments? Objections? > > Thanks, > Stepan. > > > Windows > > === > > Windows XP x86 > > > > Linux > > = > > Ubuntu 6 x86 > > Ubuntu 5 x86 > > RHEL (version ?) x86 > > FC (version ?) x86 > > SUSE (verion ?) x86 > > > > > > > > > -- > Stepan Mishura > Intel Middleware Products Division -- Egor Pasko, Intel Managed Runtime Division -- Stepan Mishura 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: [general] POLL : supported platforms
On 10/26/06, Mikhail Loenko wrote: 2006/10/25, Geir Magnusson Jr. : > > > Stepan Mishura wrote: > > On 10/16/06, *Geir Magnusson Jr.* wrote: > > > > We're a volunteer project, so "supported" is based on interest in > > community. Lets be clear by writing down a set of platforms that we as > > a community commit to support. > > > > I think we can define "support" as - "one or more people in the > > community tests on that platform on a regular basis, there are users > > that use that platform, and we have people volunteering to find and fix > > bugs that specifically affect that platform" > > > > Just throw things out there and we'll gather the results and see what's > > popular. We'll summarize in 3 days. Please be clear in indicating what > > you think should be reported. Don't vote against anything. To start, > > using a broad brush : > > > > > > Geir, > > > > I'd like to summarize the discussion to put the summary to web-site. I'm > > going to add something like: "We aimed to support wide range of > > different platforms. The main criteria if platform is supported or not > > is that there are people interesting in running test on regular base, > > reporting build status, finding and fixing bugs for that platform. A > > list of currently supported platforms can be found at > > http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. " > > > > BTW, I think we can also use as indication if a platform is supported > > if someone set up Harmony build-and-test infra on the platform and > > regularly run it. > > > > Comments? Objections? > > That captures my feeling of it, for the most part. I think it's still > early - we'll rally around a few now, but as our platform and build > becomes more portable, I expect more activity and having to revisit this > question again. Well, we'll probably have to revisit this but if we don't have something to revisit we'll have to discuss it from the beginning. So, I'm for publishing a preliminary decision on the site (or at list wiki). +1 -Stepan. Thanks, Mikhail > > geir > > > > > Thanks, > > Stepan. > > > > > > Windows > > === > > Windows XP x86 > > > > Linux > > = > > Ubuntu 6 x86 > > Ubuntu 5 x86 > > RHEL (version ?) x86 > > FC (version ?) x86 > > SUSE (verion ?) x86 > -- Stepan Mishura 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: [general] POLL : supported platforms
On 10/25/06, Mikhail Fursov wrote: On 10/25/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote: > > Comments? Objections? Wow! the only platform with bugs we have is "Windows XP with VS.NET 2005 Community Edition" ! :) I do not understand the lifecycle of this page. If I report today that my platform works OK, but the next commit brokes it, who will update the page? I guess - you'll update :-) What is "works OK"? Builds and runs classlib/drlvm tests only? I meant running Harmony's build-and-test infra. (IIUC it includes classlib/vm tests but it can include other testing scenarios). You set up it on platform of your interest and report to the mailing list regularly about build/test status. Also you may wish to suggest a fix for the platform. Then it will be clear for all that your platform is supported. Thanks, Stepan. Thanks, > Stepan. > > > Windows > > === > > Windows XP x86 > > > > Linux > > = > > Ubuntu 6 x86 > > Ubuntu 5 x86 > > RHEL (version ?) x86 > > FC (version ?) x86 > > SUSE (verion ?) x86 > > > > > > > > > -- > Stepan Mishura > 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] > -- Mikhail Fursov -- Stepan Mishura 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: [general] POLL : supported platforms
On 10/25/06, Mikhail Loenko wrote: does it make sense to put it on the site? To put what? The definition of "supported platform" or/and the list of supported platforms? I think it makes sense to put at least the definition. Thanks, Stepan. Thanks, Mikhail 2006/10/25, Stepan Mishura > On 10/16/06, Geir Magnusson Jr. wrote: > > > > We're a volunteer project, so "supported" is based on interest in > > community. Lets be clear by writing down a set of platforms that we as > > a community commit to support. > > > > I think we can define "support" as - "one or more people in the > > community tests on that platform on a regular basis, there are users > > that use that platform, and we have people volunteering to find and fix > > bugs that specifically affect that platform" > > > > Just throw things out there and we'll gather the results and see what's > > popular. We'll summarize in 3 days. Please be clear in indicating what > > you think should be reported. Don't vote against anything. To start, > > using a broad brush : > > > Geir, > > I'd like to summarize the discussion to put the summary to web-site. I'm > going to add something like: "We aimed to support wide range of different > platforms. The main criteria if platform is supported or not is that there > are people interesting in running test on regular base, reporting build > status, finding and fixing bugs for that platform. A list of currently > supported platforms can be found at > http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. " > > BTW, I think we can also use as indication if a platform is supported if > someone set up Harmony build-and-test infra on the platform and regularly > run it. > > Comments? Objections? > > Thanks, > Stepan. > > > Windows > > === > > Windows XP x86 > > > > Linux > > = > > Ubuntu 6 x86 > > Ubuntu 5 x86 > > RHEL (version ?) x86 > > FC (version ?) x86 > > SUSE (verion ?) x86 > > > -- Stepan Mishura 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: [general] POLL : supported platforms
On 10/16/06, Geir Magnusson Jr. wrote: We're a volunteer project, so "supported" is based on interest in community. Lets be clear by writing down a set of platforms that we as a community commit to support. I think we can define "support" as - "one or more people in the community tests on that platform on a regular basis, there are users that use that platform, and we have people volunteering to find and fix bugs that specifically affect that platform" Just throw things out there and we'll gather the results and see what's popular. We'll summarize in 3 days. Please be clear in indicating what you think should be reported. Don't vote against anything. To start, using a broad brush : Geir, I'd like to summarize the discussion to put the summary to web-site. I'm going to add something like: "We aimed to support wide range of different platforms. The main criteria if platform is supported or not is that there are people interesting in running test on regular base, reporting build status, finding and fixing bugs for that platform. A list of currently supported platforms can be found at http://wiki.apache.org/harmony/Platforms_to_Run_VM_on. " BTW, I think we can also use as indication if a platform is supported if someone set up Harmony build-and-test infra on the platform and regularly run it. Comments? Objections? Thanks, Stepan. Windows === Windows XP x86 Linux = Ubuntu 6 x86 Ubuntu 5 x86 RHEL (version ?) x86 FC (version ?) x86 SUSE (verion ?) x86 -- Stepan Mishura 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: [vote] Graduate Apache Harmony podling from the Incubator
+1 -Stepan. On 10/21/06, Geir Magnusson Jr. wrote: We're trying something a little different. I think Roy Fielding one said something along the lines of "when a community gets organized enough to vote itself out of the Incubator, it's appropriate." So to bring the Harmony community and the Incubator community together for this important event in Harmony's life, I'm calling for a vote on graduating Harmony here on our own -dev list. The objective is for all in both the Harmony community and the Incubator community that have an opinion to vote together, in the same place, and have it "hosted" by the Harmony podling. This is an unconventional way to do this, but I think that it's valid and could provide one example to the Incubator on how it can work going forward. So, without any further ado : [ ] +1 Graduate Apache Harmony from incubation, and let it petition the board for Top Level Project status [ ] 0 No opinion [ ] -1 No, don't graduate Harmony. Here's why : This vote will end 72 hours from now + time of Apache mail outage. It will therefore end on Monday, October 23, at 3:30 PM eastern, + delta for mail outage. Thanks geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Incubator graduation update
On 10/20/06, Geir Magnusson Jr. wrote: For those that haven't been following along Graduating from the Incubator is a "dynamic" process, as there's no really hard and fast rules to satisfy. On one hand, this is a good thing, because determining the health and prospect of future success of an Apache community is a difficult job, and it therefore relies on the experience and judgment of the Incubator PMC members. (It also allows the process to be adapted for different kinds of podlings - we're a weird one...) On the other hand, it can result it individual Incubator PMC members using different "filter" criterion. Now, I'm really proud to be a part of this community - I think we work very well together, collaboratively, in a positive and friendly atmosphere, and have demonstrated time and again the ability to vote, deal with issues that arise in voting, deal with differences of opinion, amass great hunks of software into an orderly project, etc. That said, I'm not very optimistic that we'll be able to bring this to a close in time for this month's board meeting. It's a shame, but that's ok - we're really in no rush, and if not this month, then next month. There are no major problems - it's partially because of the rather short timelines we tried, and partially because there are a few issues under discussion on the general@incubator.apache.org list, a list I encourage all of you to subscribe to and participate in. First, there are minor 'nits' here and there related to license and license headers. For example, we're missing the antlr license in our NOTICE file. Patch anyone? Also, there are other minor things here and there which can be found with this tool : http://code.google.com/p/arat/ Anyone interested in running it ASAP and giving us a set of patches to get a clean bill of health? Second, we're having a discussion on the general@ list (in which we all can participate) regarding the necessity of a project going through a release. This isn't actually an Incubator requirement, but the case where information on community health and dynamics is absent or scarce, it's a reasonable exercise. However... for Harmony, that isn't the case. I've been arguing that there's plenty of information on us. All four of us mentors (Stefano, Leo, Dims and myself) reported very positive independent assessments of the community (go read on general@) and we have 18 months of consistent, positive interaction with each other. My thinking was that 1) A release is something that we haven't wanted to do yet as a project, as our interest is in producing a more complete and stable implementation first. We have a roadmap, it's been published for a while now, and at least for me, it's the goal that I'm looking towards every day. (heck... we're still deciding what "supported" means...) 2) We're not stable enough to do something we want to shout out to the world as a "developer release" or similar. We will be ready soon, but not now. (This is just my personal opinion - others may certainly differ...) Anyway, that's what I feel about it. There are Incubator PMC members that have decided that there is ample information (Dims, Stefano and Leo really hit it out of the park with their assessments... thanks guys!) and have changed their minds, and I'm hoping to reach consensus with the rest that there *is* enough information. However, if not, and some IPMC memebers still really want to see a demonstration of a release process, we can certainly do that. I've thought about what we might release. One thing that came to mind is a Pack200 jar :) I was under impression that you are against releasing "a piece of Harmony" [1]. Particularly, you wrote: "There no sense in releasing just a classlibrary or a virtual machine. Or a toolset. You need the whole pile." IIUC now it is OK to release harmony-ketool-v1.0.tar.gz. Right? Thanks, Stepan. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200609.mbox/[EMAIL PROTECTED] Any other ideas, and any other thoughts? geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [announce] New Apache Harmony Committers : Oliver Deakin, Richard Liang, Alexey Petrenko, Gregory Shimansky, Alexey Varlamov, Alexei Zakharov
Congratulations! -Stepan. On 10/17/06, Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committers, in alphabetical order : Oliver Deakin Richard Liang Alexey Petrenko Gregory Shimansky Alexey Varlamov Alexei Zakharov These six individuals have shown sustained dedication to the project, an ability to work well with others, and share the common vision we have for Harmony. We all continue to expect great things from them. Gentlemen, you don't have accounts yet. When you finally receive your new committer account information, as a first step to test your almighty powers of committitude, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine 3) Add a public key to .ssh so you can stop using the password 4) Set your SVN password : just type 'svnpasswd' At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, anything checked out of SVN, be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using "svn switch". (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a "have to" situation because you had to submit patches and defend them, but we believe it is a "want to". Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the "commit bombs" to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC -- 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][concurrent] Implementation of the CopyOnWriteArrayList class.
On 10/13/06, Oleg Khaschansky wrote: Could you, please, send the compiler output for these errors? The output of eclipse compiler is quite big (over 1M). I've just extracted some error messages: [javac] 292. ERROR in C:\Apache\Harmony\ClassLib\modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java [javac] (at line 32) [javac] import java.util.concurrent.locks.ReentrantLock; [javac] ^^ [javac] The import java.util.concurrent.locks cannot be resolved [javac] -- [javac] 293. ERROR in C:\Apache\Harmony\ClassLib\modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java [javac] (at line 43) [javac] private final transient ReentrantLock lock = new ReentrantLock(); [javac] ^ [javac] ReentrantLock cannot be resolved to a type [javac] -- [javac] 294. ERROR in C:\Apache\Harmony\ClassLib\modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java [javac] (at line 43) [javac] private final transient ReentrantLock lock = new ReentrantLock(); [javac] ^ [javac] ReentrantLock cannot be resolved to a type [javac] -- Thanks, Stepan. On 10/13/06, Stepan Mishura wrote: > BTW, I stumbled over this class when I tried to build Classlib with Harmony > snapshot - it doesn't compile. > > I did the following: > 1) set JAVA_HOME=C:\Apache\Harmony\snapshot\harmony-hdk-r450941\jdk\jre > 2) ant -Dhy.javac.compiler=org.eclipse.jdt.core.JDTCompilerAdapter > > The build fails with compile errors. And if I revert Tim's commit back > everything goes fine: > $ svn up -r462578 > modules/concurrent/src/main/java/java/util/concurrent/CopyOnWriteArrayList.java > U > modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java > Updated to revision 462578. > > Did anyone try this? > > Thanks, > Stepan. > > > On 10/10/06, Oleg Khaschansky wrote: > > > > I uploaded a patch which implements CopyOnWriteArrayList class. > > Committers, please, take a look at [1]. I also ensured that > > CopyOnWriteArrayListTest passes with this implementation. > > > > [1] http://issues.apache.org/jira/browse/HARMONY-1805 > > -- Stepan Mishura 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][auth]LoginContext should always invoke the LoginModules?
On 10/14/06, Tim Ellison wrote:
Stepan Mishura wrote:
> So we have following suggestions:
>
> 1) leave the check and document the difference with RI
> 2) follow RI and put a warning
What warning did you have in mind? And don't say j.u.logging 'cos I can
find out where you live you know :-)
I meant adding a warning to javadoc for login() method.
Thanks,
Stepan.
Regards,
Tim
> 3) do LogingContext.logout() before the second login()
> 4) introduce a system property to follow RI
>
> Should we vote?
>
> Thanks,
> Stepan.
>
>
> On 9/29/06, Paulex Yang wrote:
>>
>> Hi, all
>>
>> I'm not a security expert, so please correct me if I miss something. I
>> found some different behavior of Harmony and RI on
>> javax.security.auth.login.LoginContext, the testcase[1] shows the
>> difference.
>>
>> Actually I tried to create the event sequence like below:
>> 1. create LoginContext with some Subject
>> 2. LoginContext.login() and return successfully
>> 3. Modify Subject's content to make it invalid(one Principal's name
>> here, maybe passwd/username/servername in more general case)
>> 4. LoginContext.login() again
>>
>> In RI, the second login() invocation really tried to invoke the
relative
>> LoginModule.login() and then failed to login with the modified Subject,
>> but in Harmony, both invocations succeed. I consider RI's behavior is
>> more reasonable.
>>
>> After a rough look of LoginContext implementation, I found the cause
may
>> be the Ln. 275
>>
>>private void loginImpl() throws LoginException {
>>if (loggedIn) {
>>return;
>>}
>>
>>}
>>
>> Seems Harmony won't invoke the LoginModule.login() again only if the
>> login ever succeeds. If I comment out these lines, the test below
passes
>> happily. Any ideas on this issue?
>>
>>
>> [1]
>> public class LoginContextTest extends TestCase {
>>private static final String VALID_NAME = "name1";
>>private static final String INVALID_NAME = "name2";
>>
>>public void testLogin() throws Exception{
>>MyPrincipal pri = new MyPrincipal();
>>HashSet set = new HashSet();
>>set.add(pri);
>>Subject sub = new Subject(false, set, new HashSet(), new
>> HashSet());
>>Configuration.setConfiguration(new MyConfig());
>>LoginContext context = new LoginContext("moduleName", sub);
>>context.login();
>>pri.name = INVALID_NAME;
>>try{
>>context.login();
>>fail("Should throw LoginException");
>>}catch(LoginException e){
>>
>>}
>>}
>>static class MyConfig extends Configuration{
>>AppConfigurationEntry[] entries = new
>> AppConfigurationEntry[]{new
>> AppConfigurationEntry(MyModule.class.getName(),
>> LoginModuleControlFlag.REQUIRED, new HashMap())};
>>public AppConfigurationEntry[] getAppConfigurationEntry(String
>> name) {
>>return entries;
>>}
>>public void refresh() {
>>}
>>}
>>public static class MyModule implements LoginModule{
>>Subject sub;
>>public void MyModule(){
>>}
>>public boolean abort() throws LoginException {
>>return false;
>>}
>>public boolean commit() throws LoginException {
>>return true;
>>}
>>public void initialize(Subject arg0, CallbackHandler arg1,
>> Map arg2, Map arg3) {
>>sub = arg0;
>>}
>>public boolean login() throws LoginException {
>>Principal[] pris = sub.getPrincipals().toArray(new
>> Principal[0]);
>>return VALID_NAME.equals(pris[0].getName());
>>}
>>public boolean logout() throws LoginException {
>>return false;
>>}
>>}
>>public static class MyPrincipal implements Principal{
>>public String name = VALID_NAME;
>>public String getName() {
>>return name;
>>}
>>public String toString(){
>>return name;
>>}
>>};
>> }
>>
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Stepan Mishura
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][tools][test] newly added KeyStoreLoaderSaverTest.java is not compiled
I'll look into. -Stepan. On 10/13/06, Elena Semukhina wrote: Hi all, I could not run classlib tests today because of compilation error described at *http://issues.apache.org/jira/browse/HARMONY-1855*< http://issues.apache.org/jira/browse/HARMONY-1855> Could anyone fix the issue? -- Thanks, Elena -- 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][concurrent] Implementation of the CopyOnWriteArrayList class.
BTW, I stumbled over this class when I tried to build Classlib with Harmony snapshot - it doesn't compile. I did the following: 1) set JAVA_HOME=C:\Apache\Harmony\snapshot\harmony-hdk-r450941\jdk\jre 2) ant -Dhy.javac.compiler=org.eclipse.jdt.core.JDTCompilerAdapter The build fails with compile errors. And if I revert Tim's commit back everything goes fine: $ svn up -r462578 modules/concurrent/src/main/java/java/util/concurrent/CopyOnWriteArrayList.java U modules\concurrent\src\main\java\java\util\concurrent\CopyOnWriteArrayList.java Updated to revision 462578. Did anyone try this? Thanks, Stepan. On 10/10/06, Oleg Khaschansky wrote: I uploaded a patch which implements CopyOnWriteArrayList class. Committers, please, take a look at [1]. I also ensured that CopyOnWriteArrayListTest passes with this implementation. [1] http://issues.apache.org/jira/browse/HARMONY-1805 -- 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][auth]LoginContext should always invoke the LoginModules?
So we have following suggestions:
1) leave the check and document the difference with RI
2) follow RI and put a warning
3) do LogingContext.logout() before the second login()
4) introduce a system property to follow RI
Should we vote?
Thanks,
Stepan.
On 9/29/06, Paulex Yang wrote:
Hi, all
I'm not a security expert, so please correct me if I miss something. I
found some different behavior of Harmony and RI on
javax.security.auth.login.LoginContext, the testcase[1] shows the
difference.
Actually I tried to create the event sequence like below:
1. create LoginContext with some Subject
2. LoginContext.login() and return successfully
3. Modify Subject's content to make it invalid(one Principal's name
here, maybe passwd/username/servername in more general case)
4. LoginContext.login() again
In RI, the second login() invocation really tried to invoke the relative
LoginModule.login() and then failed to login with the modified Subject,
but in Harmony, both invocations succeed. I consider RI's behavior is
more reasonable.
After a rough look of LoginContext implementation, I found the cause may
be the Ln. 275
private void loginImpl() throws LoginException {
if (loggedIn) {
return;
}
}
Seems Harmony won't invoke the LoginModule.login() again only if the
login ever succeeds. If I comment out these lines, the test below passes
happily. Any ideas on this issue?
[1]
public class LoginContextTest extends TestCase {
private static final String VALID_NAME = "name1";
private static final String INVALID_NAME = "name2";
public void testLogin() throws Exception{
MyPrincipal pri = new MyPrincipal();
HashSet set = new HashSet();
set.add(pri);
Subject sub = new Subject(false, set, new HashSet(), new
HashSet());
Configuration.setConfiguration(new MyConfig());
LoginContext context = new LoginContext("moduleName", sub);
context.login();
pri.name = INVALID_NAME;
try{
context.login();
fail("Should throw LoginException");
}catch(LoginException e){
}
}
static class MyConfig extends Configuration{
AppConfigurationEntry[] entries = new
AppConfigurationEntry[]{new
AppConfigurationEntry(MyModule.class.getName(),
LoginModuleControlFlag.REQUIRED, new HashMap())};
public AppConfigurationEntry[] getAppConfigurationEntry(String
name) {
return entries;
}
public void refresh() {
}
}
public static class MyModule implements LoginModule{
Subject sub;
public void MyModule(){
}
public boolean abort() throws LoginException {
return false;
}
public boolean commit() throws LoginException {
return true;
}
public void initialize(Subject arg0, CallbackHandler arg1,
Map arg2, Map arg3) {
sub = arg0;
}
public boolean login() throws LoginException {
Principal[] pris = sub.getPrincipals().toArray(new
Principal[0]);
return VALID_NAME.equals(pris[0].getName());
}
public boolean logout() throws LoginException {
return false;
}
}
public static class MyPrincipal implements Principal{
public String name = VALID_NAME;
public String getName() {
return name;
}
public String toString(){
return name;
}
};
}
--
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: [vote] HARMONY-1609 - bulk contribution of Applet, ImageIO and Print modules
+1 -Stepan. On 10/3/06, Geir Magnusson Jr. wrote: BCC and ACQs in place. [ ] +1 Yes, accept the contribution [ ] -1 No, don't. reason : As usual, 3 days or until all committers vote, or there is an objection/request for continuance -- 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] manifest information
On 10/5/06, Tim Ellison wrote: Alexey Petrenko wrote: > We also need to keep Import-Package section up to date... For sure, and (just to be clear to all) these are not just for Eclipse's benefit, they are for our benefit as they are the definition of our class library modularity. When you add a new Import or Export you are changing the module's interface and potentially adding new coupling. It should not be undertaken lightly. Hi Tim, I've just realized that I don't really understand why we should add tests' dependencies to manifest. I guess that I missed something. I've looked through harmony-dev mail archive but I haven't find answer. Could you give me a hint where to look at? Thanks, Stepan. I appreciate that it is hard to maintain the module boundaries if you don't use a tool like Eclipse that warns you if you reach outside the module definition; and we should consider adding such a check into the automated build. Therefore, I'd not be in favour of automatically updating the Imports and Exports in the manifest -- it would hide any widening of the inter-module dependencies and we could end up with the spaghetti code evident in 'other popular implementations of the spec'. Regards, Tim > 2006/10/5, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> Can we consider making the final manifest that goes into our jars to be >> created/updated dynamically? >> >> I just went through all manifests and added Specification-Version, >> Implementation-Version, etc and they will change, at least the last one. >> >> I know the Eclipse people depend on them, so maybe can we used ant's >> filtering to set the Impl-Version dynamically? Or something like that? >> >> geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
On 10/5/06, Vladimir Ivanov wrote: On 10/4/06, Stepan Mishura wrote: > > > Seems, that everybody thinking about separated test jar for each module > (I > > proposed one jar as first step onlyJ). Now, we should implement this. If > > you > > need any help I'm a volunteer. > > > > This won't work for all resource files, for example, there are a number of > tests for a config parser and they need a path to a config file. Agree. Seems, separated 'modules.resource.jar' for each module should be created too. Sorry, I didn't catch. Do you mean that I have to unpack it before I run tests? Thanks, Stepan. Tahnks, Vladimir Thanks, > Stepan. > > thanks, Vladimir > > > > Regards, > > > Oliver > > > > > > > We may also supply the build file with placeholders > > > > for user classes & tests dirs that will be prepended to > > > > classpath/bootclasspath. > > > > > > > > Regards, > > > > > > > > 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: > > > >> On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > > > >> > > > > >> > > > > >> > > > > >> > If I recall, the point of the test.jar was to have a pre-built > jar > > of > > > >> > tests in the HDK so that someone could setup the build-test infra > > > >> > using the HDK so they could run tests on their platform w/o > having > > to > > > >> > build everything. Good idea. > > > >> > > > >> > > > >> Yes, you are correct. This idea implemented in the jira 964. > > > >> > > > >> If that's so, then something would > > > >> > have to be configured to have the classlib "test" target use that > > > >> > jar. All I'm saying is that how we do this is important, as we > > don't > > > >> > want to cause pain for classlib developers who use the HDK for > > > >> > development support. > > > >> > > > >> > > > >> > > > >> Seems, we think about different use cases. > > > >> > > > >> In my case, user can download the HDK for own platform (if we have > > > >> one) run > > > >> tests and look on results (also, may be upload it to the harmony > > > >> site). Also > > > >> it can be used for application run to check 'enable' status. But if > > > this > > > >> user interested in Harmony development he should checkout ws and > use > > > >> built-in ant targets to build and test updated ws. > > > >> > > > >> > > > >> > > > >> How you plan to use HDK? It looks like initial miscommunication :) > > > >> thanks, Vladimir > > > >> > > > >> > > > >> > > > >> > geir > > > >> > > > > >> > > > > > >> > > Thanks, Vladimir > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > >> > Thanks, Vladimir > > > >> > >> > > > > >> > >> > geir > > > >> > >> >> > > > >> > >> >> > > > > >> > >> >> > > > > >> > >> >> > > > > >> > >> >> > Thanks, Vladimir > > > >> > >> >> > > > > >> > >> >> > > > > >> > >> >> > > > > >> > >> >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > > > >> > >> >> >> > > > >> > >> >> >> They are at the regular place > > > >> > >> >> >> > > > >> > >> >> >> > http://people.apache.org/dist/incubator/harmony/snapshots > > > >> > >> >> >> > > > >> > >> >> >> I moved all the old classlib snapshots into /old and > I'll > > > >> > >> >> update the > > > >> > >> >> >> website accordingly. I'll be automating this. Also, > lets > > > >> not > > > >> > >> >> >> make much > > > >> > >> >> >> noise about this for a little while so we can test to > make > > > >> sure > > > >> > >> >> >> there's > > > >> > >> >> >> no major errors. Things seem good. I have a list of > more > > > >> > >> >> things to > > > >> > >> >> >> fix, but I realized today that I was obsessing over the > > > >> > >> snapshot > > > >> > >> >> >> contents - it's not a release, and it's "good enough". > > > >> > >> >> >> > > > >> > >> >> >> I'd like to ditch both /old and the remaining classlib > > > >> > >> >> snapshots, as > > > >> > >> >> >> > > > >> > >> >> >> 1) they are snapshots - history doesn't matter > > > >> > >> >> >> > > > >> > >> >> >> 2) the classlib is now in the HDK, so we just need to > > adjust > > > >> > >> the > > > >> > >> >> >> docs to > > > >> > >> >> >> match. > > > >> > >> >> >> > > > >> > >> >> >> I'll do the latter, but wanted to see if anyone has a > > > problem > > > >> > >> >> w/ me > > > >> > >> >> >> removing /old and the last classlib snapshot. I'll do > > this > > > >> > >> if I > > > >> > >> >> >> don't > > > >> > >> >> >> hear any protest, so either positively acknowledge this > > > >> action > > > >> > >> >> if you > > > >> > >> >> >> support it, dont' do a thing if you support or dont' > care, > > > >> > >> or say > > > >> > >> >> >> why we > > > >> > >> >> >> shouldn't :) > > > >> > >> >> >> > > > >> > >> >> >> geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] jre and hdk snapshots posted to general snapshot site
On 10/3/06, Vladimir Ivanov wrote: On 10/2/06, Oliver Deakin wrote: > > <...> > Does this sound reasonable? Seems, that everybody thinking about separated test jar for each module (I proposed one jar as first step onlyJ). Now, we should implement this. If you need any help I'm a volunteer. This won't work for all resource files, for example, there are a number of tests for a config parser and they need a path to a config file. Thanks, Stepan. thanks, Vladimir Regards, > Oliver > > > We may also supply the build file with placeholders > > for user classes & tests dirs that will be prepended to > > classpath/bootclasspath. > > > > Regards, > > > > 2006/9/27, Vladimir Ivanov <[EMAIL PROTECTED]>: > >> On 9/27/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >> > > >> > > >> > > >> > If I recall, the point of the test.jar was to have a pre-built jar of > >> > tests in the HDK so that someone could setup the build-test infra > >> > using the HDK so they could run tests on their platform w/o having to > >> > build everything. Good idea. > >> > >> > >> Yes, you are correct. This idea implemented in the jira 964. > >> > >> If that's so, then something would > >> > have to be configured to have the classlib "test" target use that > >> > jar. All I'm saying is that how we do this is important, as we don't > >> > want to cause pain for classlib developers who use the HDK for > >> > development support. > >> > >> > >> > >> Seems, we think about different use cases. > >> > >> In my case, user can download the HDK for own platform (if we have > >> one) run > >> tests and look on results (also, may be upload it to the harmony > >> site). Also > >> it can be used for application run to check 'enable' status. But if > this > >> user interested in Harmony development he should checkout ws and use > >> built-in ant targets to build and test updated ws. > >> > >> > >> > >> How you plan to use HDK? It looks like initial miscommunication :) > >> thanks, Vladimir > >> > >> > >> > >> > geir > >> > > >> > > > >> > > Thanks, Vladimir > >> > > > >> > > > >> > > > >> > > > >> > > > >> > >> > Thanks, Vladimir > >> > >> > > >> > >> > geir > >> > >> >> > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > Thanks, Vladimir > >> > >> >> > > >> > >> >> > > >> > >> >> > > >> > >> >> > On 7/23/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote: > >> > >> >> >> > >> > >> >> >> They are at the regular place > >> > >> >> >> > >> > >> >> >> http://people.apache.org/dist/incubator/harmony/snapshots > >> > >> >> >> > >> > >> >> >> I moved all the old classlib snapshots into /old and I'll > >> > >> >> update the > >> > >> >> >> website accordingly. I'll be automating this. Also, lets > >> not > >> > >> >> >> make much > >> > >> >> >> noise about this for a little while so we can test to make > >> sure > >> > >> >> >> there's > >> > >> >> >> no major errors. Things seem good. I have a list of more > >> > >> >> things to > >> > >> >> >> fix, but I realized today that I was obsessing over the > >> > >> snapshot > >> > >> >> >> contents - it's not a release, and it's "good enough". > >> > >> >> >> > >> > >> >> >> I'd like to ditch both /old and the remaining classlib > >> > >> >> snapshots, as > >> > >> >> >> > >> > >> >> >> 1) they are snapshots - history doesn't matter > >> > >> >> >> > >> > >> >> >> 2) the classlib is now in the HDK, so we just need to adjust > >> > >> the > >> > >> >> >> docs to > >> > >> >> >> match. > >> > >> >> >> > >> > >> >> >> I'll do the latter, but wanted to see if anyone has a > problem > >> > >> >> w/ me > >> > >> >> >> removing /old and the last classlib snapshot. I'll do this > >> > >> if I > >> > >> >> >> don't > >> > >> >> >> hear any protest, so either positively acknowledge this > >> action > >> > >> >> if you > >> > >> >> >> support it, dont' do a thing if you support or dont' care, > >> > >> or say > >> > >> >> >> why we > >> > >> >> >> shouldn't :) > >> > >> >> >> > >> > >> >> >> geir -- 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][tools] package name for Keytool tests
Hi Anton, I think we should name tool's tests as classlib does. So for tools we will have: o.a.h.tools..tests Thanks, Stepan. On 10/4/06, Anton Rusanov <[EMAIL PROTECTED]> wrote: Hi, I'm going to add a test for Keytool but I don't know how to name the package for tests: org.apache.harmony.tests.tools.keytool like it is done for javac or org.apache.harmony.tools.keytool.tests like it was decided for classlib? -- Thanks, Anton -- 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] [testing] How to file JIRA issues for impl JUnit tests?
On 10/3/06, Anton Luht wrote: Hello, It's clear how to file issues for public API - write a test with differend behaviour on RI and Harmony. It's not clear how to write tests or report problems when JUnit impl test fail. Hi Anton, At minimum you can just file a JIRA describing a failure and what to do to reproduce it. Or you can try to analyze the failure. In this particular case the test passes on IBM VME and fails on DRL VM. So what the difference is? I'd try to minimize test case to demonstrate the difference and add it to JIRA. Also I'd look to the spec. to understand what the expected result is. Thanks, Stepan. I see org.apache.harmony.security.tests.asn1.der.SequenceTest failing at svn = r452457, (Oct 3 2006), Windows/ia32/msvc 1310, debug build Other people report failures , too : http://www.harmonytest.org/testapp.do?method=showresult&id=74663 -- 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] -- Thanks, Stepan Mishura 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: [r451637] - Code cleanup - ... - Remove unnecessary comments
On 10/4/06, Nathan Beyer wrote:
If this is an event that should be logged, as the TODO indicated, then
why not just print out the stack trace and be done with it? If this
exception happens so often that you'd like it removed, then why would
we want to log a warning message, which I would presume would print to
the console just as frequently.
As for TODOs, in general I find TODOs never get done, especially
trivial ones like this particular case.
I don't agree. TODOs are good hint for making improvements and I'd keep them
in source files.
Thanks,
Stepan.
-Nathan
On 10/3/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> Nathan,
>
> I've seen you dropped many TODOs in "- Code cleanup -" series of
commits;
> I'd like to know what reasoning was behind this? I think it's a bit
> early to erase TODOs without appropriate consideration...
>
> In particular, could you please undo the following change, it produces
> garbage messages during AUTH testing:
>
>
modules/auth/src/main/java/common/org/apache/harmony/auth/login/DefaultConfigurationParser.java
> ===
> @@ -216,12 +206,12 @@ public class DefaultConfigurationParser
> try {
> val = PolicyUtils.expand(st.sval, system);
> } catch (Exception e) {
> - //TODO: warning log
> - }
> + e.printStackTrace();
> + }
> }
>
> --
> WBR,
> 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: [classlib][auth]LoginContext should always invoke the LoginModules?
On 10/2/06, Tim Ellison wrote: Alex Astapchuk wrote: > Hi Stepan, all, > >> I think the spec. statement: "A LoginContext should not be used to >> authenticate more than one Subject." was taken too strict: reusing >> LoginContext object to get the same set of credentials seemed odd. > > The decision was mostly about resources. > > Indeed, the spec does not specify behavior of LoginContext. > > However, the spec is more or less clear in what should the > Login*Module*-s do in response to login/logout/etc. > It states 'login() saves result ...'. It does not warn with > anything like 'check previous state and clean up resources > from previous successful logins'. > The resource clean up is explicitly for abort() and logout(). The spec might not say so explicitly, but cleaning up the resources before attempting another login would seem like a reasonable thing to do. Hi Tim, And if RI doesn't clean up resources should we do the same to be "compatible"? :-) I see two possible solutions here: 1) Revert the change and add javadoc comments that the second login() is ignored if logout() is not ivoked before. 2) LoginContext calls logout() before the second login(). But both variants will be incompatible with RI (testing shows that it doesn't invoke logout() before second login()). Other variants? Thanks, Stepan. I consider RI's behavior is more reasonable. > > I would say it's more dangerous. > The invocation of login() on already logged LoginModule-s > may easily produce a resource leak. > Presuming the authentication is normally not a too frequent > task, such a leak would be really hard to discover and hunt. I don't see why we would have to suffer the leak -- if the state changes are made via API then we have the opportunity to fix things first. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1410 : JDWP agent for DRLVM
+1 -Stepan. On 9/28/06, Geir Magnusson Jr. wrote: BCC and ACQs are in. What say ye? Would it be nice to debug using eclipse debugger in DRLVM? [ ] + 1 accept this contribution into the project [ ] -1 don't accept (please give reason) Vote runs usual 3 days unless protest or early completion. geir -- 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][auth]LoginContext should always invoke the LoginModules?
On 9/30/06, Paulex Yang wrote:
Paulex Yang wrote:
> Hi, all
>
> I'm not a security expert, so please correct me if I miss something. I
> found some different behavior of Harmony and RI on
> javax.security.auth.login.LoginContext, the testcase[1] shows the
> difference.
>
> Actually I tried to create the event sequence like below:
> 1. create LoginContext with some Subject
> 2. LoginContext.login() and return successfully
> 3. Modify Subject's content to make it invalid(one Principal's name
> here, maybe passwd/username/servername in more general case)
> 4. LoginContext.login() again
>
> In RI, the second login() invocation really tried to invoke the
> relative LoginModule.login() and then failed to login with the
> modified Subject, but in Harmony, both invocations succeed. I consider
> RI's behavior is more reasonable.
>
> After a rough look of LoginContext implementation, I found the cause
> may be the Ln. 275
>
>private void loginImpl() throws LoginException {
>if (loggedIn) {
>return;
>}
>
>}
>
> Seems Harmony won't invoke the LoginModule.login() again only if the
> login ever succeeds. If I comment out these lines, the test below
> passes happily. Any ideas on this issue?
I've removed these lines at revision r451557 with regression test,
please shout if anyone thinks the update harmful for some reason.
I'll look into to verify if the update is harmless.
Thanks,
Stepan.
>
> [1]
> public class LoginContextTest extends TestCase {
>private static final String VALID_NAME = "name1";
>private static final String INVALID_NAME = "name2";
>
>public void testLogin() throws Exception{
>MyPrincipal pri = new MyPrincipal();
>HashSet set = new HashSet();
>set.add(pri);
>Subject sub = new Subject(false, set, new HashSet(), new
> HashSet());
>Configuration.setConfiguration(new MyConfig());
>LoginContext context = new LoginContext("moduleName", sub);
>context.login();
>pri.name = INVALID_NAME;
>try{
>context.login();
>fail("Should throw LoginException");
>}catch(LoginException e){
> }
>} static class MyConfig extends Configuration{
>AppConfigurationEntry[] entries = new
> AppConfigurationEntry[]{new
> AppConfigurationEntry(MyModule.class.getName(),
> LoginModuleControlFlag.REQUIRED, new HashMap())};
>public AppConfigurationEntry[] getAppConfigurationEntry(String
> name) {
>return entries;
>}
>public void refresh() {
>}
>}
>public static class MyModule implements LoginModule{
>Subject sub;
>public void MyModule(){
>}
>public boolean abort() throws LoginException {
>return false;
>}
>public boolean commit() throws LoginException {
>return true;
>}
>public void initialize(Subject arg0, CallbackHandler arg1,
> Map arg2, Map arg3) {
>sub = arg0;
>}
>public boolean login() throws LoginException {
>Principal[] pris = sub.getPrincipals().toArray(new
> Principal[0]);
>return VALID_NAME.equals(pris[0].getName());
>}
>public boolean logout() throws LoginException {
>return false;
>}
>}
>public static class MyPrincipal implements Principal{
>public String name = VALID_NAME;
>public String getName() {
>return name;
>}
>public String toString(){
>return name;
>}
>};
> }
>
>
>
--
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: [classlib][auth]LoginContext should always invoke the LoginModules?
On 9/29/06, Paulex Yang wrote:
Hi, all
I'm not a security expert, so please correct me if I miss something. I
found some different behavior of Harmony and RI on
javax.security.auth.login.LoginContext, the testcase[1] shows the
difference.
Actually I tried to create the event sequence like below:
1. create LoginContext with some Subject
2. LoginContext.login() and return successfully
3. Modify Subject's content to make it invalid(one Principal's name
here, maybe passwd/username/servername in more general case)
Hi, Paulex
LoginContext doesn't verify Subject's contents - all requred info is
obtained with callback handler and passed to login modules. And login
modules check whether password/username are valid or not.
4. LoginContext.login() again
In RI, the second login() invocation really tried to invoke the relative
LoginModule.login() and then failed to login with the modified Subject,
but in Harmony, both invocations succeed. I consider RI's behavior is
more reasonable.
After a rough look of LoginContext implementation, I found the cause may
be the Ln. 275
private void loginImpl() throws LoginException {
if (loggedIn) {
return;
}
}
I think the spec. statement: "A LoginContext should not be used to
authenticate more than one Subject." was taken too strict: reusing
LoginContext object to get the same set of credentials seemed odd.
But if RI let LoginContext object to be reusable then it makes sense doing
the same.
Thanks,
Stepan.
Seems Harmony won't invoke the LoginModule.login() again only if the
login ever succeeds. If I comment out these lines, the test below passes
happily. Any ideas on this issue?
[1]
public class LoginContextTest extends TestCase {
private static final String VALID_NAME = "name1";
private static final String INVALID_NAME = "name2";
public void testLogin() throws Exception{
MyPrincipal pri = new MyPrincipal();
HashSet set = new HashSet();
set.add(pri);
Subject sub = new Subject(false, set, new HashSet(), new
HashSet());
Configuration.setConfiguration(new MyConfig());
LoginContext context = new LoginContext("moduleName", sub);
context.login();
pri.name = INVALID_NAME;
try{
context.login();
fail("Should throw LoginException");
}catch(LoginException e){
}
}
static class MyConfig extends Configuration{
AppConfigurationEntry[] entries = new
AppConfigurationEntry[]{new
AppConfigurationEntry(MyModule.class.getName(),
LoginModuleControlFlag.REQUIRED, new HashMap())};
public AppConfigurationEntry[] getAppConfigurationEntry(String
name) {
return entries;
}
public void refresh() {
}
}
public static class MyModule implements LoginModule{
Subject sub;
public void MyModule(){
}
public boolean abort() throws LoginException {
return false;
}
public boolean commit() throws LoginException {
return true;
}
public void initialize(Subject arg0, CallbackHandler arg1,
Map arg2, Map arg3) {
sub = arg0;
}
public boolean login() throws LoginException {
Principal[] pris = sub.getPrincipals().toArray(new
Principal[0]);
return VALID_NAME.equals(pris[0].getName());
}
public boolean logout() throws LoginException {
return false;
}
}
public static class MyPrincipal implements Principal{
public String name = VALID_NAME;
public String getName() {
return name;
}
public String toString(){
return name;
}
};
}
--
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: [doc] new "Getting Started" guides
On 9/29/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote: ... My two cents: > The path to a component > should end with component's status info - ideally it should give the newbie > enough info not to search though harmony-dev mail archive or JIRA at all. Good point, but am not sure we're ready for it just now. I haven't found nice wiki pages for each modules/components. Things are sometimes quite chaotic ;( I think we should try reduce a level of chaos. BTW, how many steps are required to find very usefull LUNI's wiki page? Yes, wiki pages are good but I think we need more. What the component's > home page should contain? From my point of view it should contain the > following: > 1) Doc: just brief overview and pointers to spec., docs, user's guides Again, nice idea, but not sure this is workable at the moment. We only have >5 docs for API modules + ~3 DRLVM components + a couple more misc docs. Do you think we can have sort of table in Classlib and VM component pages: a list of modules with pointers to specs + Harmony-specific docs + status (done/missing/in progress/see JIRA/). This can give a pretty clear picture of where we are :) Yes, this can be possible solution. 2) Work with the component: how to build, deploy with Harmony JRE (or > another JRE if possible) and run with apps. Would that not be very similar (except for paths and similar) for the majority of components? Don't think we need how-to build for each. It may just contain a reference to common part + some component's specific (that is optional) 3) Status: in progress, no activity or done (that I mean by saying > "released", sorry for confusion) Very important info. We have http://incubator.apache.org/harmony/roadmap.html where major issues can be listed, but probably component-wise info can also help. However, I am not sure this is appropriate for newbies. Before deciding how they can contribute, they'd rather have the code and run it. Also, this info can be on Wiki page, where actual discussions/decisions run. Hm, check out 0.5Gb of code, build (there is a risk that the build may be broken) it and realize that she/he want to contribute to some small module :-) 4) Open issues: info from JIRA (we can fetch issues related only to the > component from JIRA) Can this be automated, at least to an extent? JIRAs seem to be a very dynamic system. Otherwise, to keep the component page up-to-date and with JIRA numbers would require frequent changes to the website. Yes, I think this can be automated. 5) Mailing list: I think we should let the newbie to be aware only about > exact part of the project. Specifying keywords by which to search on the mailing list? Well, if the newbie wants to find something very much she/he will definitely find it. The question is how many efforts are required for searching. I just want to work out a way how organize web-site to make it simple. Thanks, Stepan Mishura 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: [doc] new "Getting Started" guides
On 9/28/06, Geir Magnusson Jr. wrote: > > For example, what the problem with releasing 'keytool' or 'beans > framework'? > Why these parts should wait until we complete full toolset of > classlib? Maybe the problem is a simple confusion over the word "release". What do you mean here? We'd have a download called "harmony-ketool- v1.0.tar.gz"? I'm guessing that this isn't what you mean. Sorry for me being dense :) Yes, you are right about confusing "release" word. Let's forget about it and start from the beginning. My point is that we should give clear message to a newbie that the project consists of independent parts and we should provide the newbie with a shortest path to a part where the newbie want to contribute. For example, 3 steps: Apache Harmony Home page ->Getting Started For Contributors page -> Component's homepage The path shouldn't lead to nowhere, like saying: go to the dev-mail archive or JIRA and search for [classlib][]. The path to a component should end with component's status info – ideally it should give the newbie enough info not to search though harmony-dev mail archive or JIRA at all. At minimum the path should lead the newbie to the component's wiki page. Yes, wiki pages are good but I think we need more. What the component's home page should contain? From my point of view it should contain the following: 1) Doc: just brief overview and pointers to spec., docs, user's guides 2) Work with the component: how to build, deploy with Harmony JRE (or another JRE if possible) and run with apps. 3) Status: in progress, no activity or done (that I mean by saying "released", sorry for confusion) 4) Open issues: info from JIRA (we can fetch issues related only to the component from JIRA) 5) Mailing list: I think we should let the newbie to be aware only about exact part of the project. 6) Wiki page For example, the newbie may be interesting in contributing to BEANS and don't want to receive tons of messages about VM. We may let message pass from component's mailing list to common mailing list. (Even more we may add required prefix to subject automatically, for example, "problems with Introspector" => "[classlib][beans] problems with Introspector") Does this make sense? > > >> I think we need to continue to focus on our primary goal, java SE. >> I've also been concerned about having "subprojects" that are too >> independent, creating sub-communities. I think that should be >> avoided at all cost. Sure, we each have our focus and >> specialization, but we're one project, one community. > > > > IMHO, we unintentionally pushed idea of independency components to > project's > backyard. I think this is not good. Sorry - I don't understand either. I just meant that we should start with description of independent parts. We have categories for JIRA - doesn't that work? Mail list is busy, but right now we seem to be doing ok in terms of segmenting by subject line, and quite frankly, I still think that the benefits of intermixing currently outweigh the costs. yes, we need a user list soon, and someday we'll split VM from classlib, but right now, there's such good collaboration... Yes, high mail traffic might be a problem it constantly grows. And subject's line definitely helps now but I'm not sure about future. Oh, we're definitely going to split lists someday. Mail traffic is going to exceed 2K message this month. Are you waiting for 10K messages? :-) > Also some parts of the project are indeed independent. For example, > it may > be possible to take some framework from classlib, say logging > framework, and > try it with another JRE. And the framework should work. This is true > independence. So it seems more natural for me to create a sub- > project for > the framework to let it be more attractive for users: has less > bugs, is > faster, follows the spec. and so on. Why not? First, classlib is modular so users can do that already. I thought that it may be not quite clear for newbie how to use modularity. May be I'm wrong. Second, the Java SE spec license doesn't allow independent releases as in "we are choosing to distribute this as shipping software", so we don't want to take on that issue. Yes, I understood you point. I don't suggest delivering some framework or a tool and announcing it as "piece of JAVA". IANAL, I just wonder if we can suggest a user to try the following testing scenario: take some module's jar, for example, sql.jar and try an app that depends on SQL API with JRE that she/he usually uses. Is this restricted by the license? Thanks, Stepan Mishura 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: [doc] new "Getting Started" guides
On 9/28/06, Geir Magnusson Jr. wrote: On Sep 27, 2006, at 10:53 PM, Stepan Mishura wrote: > t is great that you've created guides and put references to them at > top. So > now it is clear for newcomer what the next step is. And I'd like to > suggest > the following improvement for contributors guide: the page contains > only few > words about projects parts and it may create impression that > Harmony is a > one big/complex piece of software that has a lot of dependencies to > download. I think that it is important to say clearly in the > beginning of > the page that the project consists of many quite independent parts. > And the > newcomer has a choice to work with whole code base (a.k.a. > federated build) > or with a part of the project. So the top of the page should > contain two > references to federated build and to a description of the project's > components. I understand. Remember, this is targetted for newbies - people who don't know anything yet, and what it tries to do is find the fastest path to getting working code from a single checkout. Yes, I remember that and I wanted to share my view what the fastest way is. > > We have instructions for federated build. It looks OK for me. And the > description of components should give detailed picture of all > components not > just mention VM and Classlib. And the components' description > should points > to components' homepages. Good point. But what other components right now would you point to? A structure can be - Classlib . <= pointers to subcomponents - Tools . <= pointers to subcomponents -VM . <= pointers to subcomponents > > BTW, just random idea. I'd let each module to live by its own life > by having > its own homepage, releases, mailing list and JIRA component, like > we have > for ORB module (Apache Yoko project). Does this make sense? No. There no sense in releasing just a classlibrary or a virtual machine. Or a toolset. You need the whole pile. Sometimes it is hard to swallow a whole pile. J2SE implementation is a big pile. I don't see anything wrong here why not to suggest the newbie to try a piece of the pile. For example, what the problem with releasing 'keytool' or 'beans framework'? Why these parts should wait until we complete full toolset of classlib? I think we need to continue to focus on our primary goal, java SE. I've also been concerned about having "subprojects" that are too independent, creating sub-communities. I think that should be avoided at all cost. Sure, we each have our focus and specialization, but we're one project, one community. IMHO, we unintentionally pushed idea of independency components to project's backyard. I think this is not good. We have categories for JIRA - doesn't that work? Mail list is busy, but right now we seem to be doing ok in terms of segmenting by subject line, and quite frankly, I still think that the benefits of intermixing currently outweigh the costs. yes, we need a user list soon, and someday we'll split VM from classlib, but right now, there's such good collaboration... Yes, high mail traffic might be a problem it constantly grows. And subject's line definitely helps now but I'm not sure about future. Also some parts of the project are indeed independent. For example, it may be possible to take some framework from classlib, say logging framework, and try it with another JRE. And the framework should work. This is true independence. So it seems more natural for me to create a sub-project for the framework to let it be more attractive for users: has less bugs, is faster, follows the spec. and so on. Why not? Thanks, Stepan. As for homepages, we already have that - basic pages for each major component. geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [doc] new "Getting Started" guides
On 9/22/06, Geir Magnusson Jr. wrote: As discussed earlier today, there are now two new "Getting Started" guides on the website, accessible from the homepage. http://incubator.apache.org/harmony/quickhelp_users.html http://incubator.apache.org/harmony/quickhelp_contributors.html There is still more work to do - for example, we need to fill in the lists of tools needed and dependencies. (I'll add a fresh Ubuntu VM in Parallels tomorrow and work though all the deps that need to be added) Give a read, test it out, and comment... Hi Geir, It is great that you've created guides and put references to them at top. So now it is clear for newcomer what the next step is. And I'd like to suggest the following improvement for contributors guide: the page contains only few words about projects parts and it may create impression that Harmony is a one big/complex piece of software that has a lot of dependencies to download. I think that it is important to say clearly in the beginning of the page that the project consists of many quite independent parts. And the newcomer has a choice to work with whole code base (a.k.a. federated build) or with a part of the project. So the top of the page should contain two references to federated build and to a description of the project's components. We have instructions for federated build. It looks OK for me. And the description of components should give detailed picture of all components not just mention VM and Classlib. And the components' description should points to components' homepages. BTW, just random idea. I'd let each module to live by its own life by having its own homepage, releases, mailing list and JIRA component, like we have for ORB module (Apache Yoko project). Does this make sense? Thanks, Stepan Mishura 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][math]three tests fail, anyone else see this?
Yes, is see failures. I guess that a cause may be math module
internalization.
Thanks,
Stepan.
On 9/27/06, Paulex Yang wrote:
Anyone else see these test errors of BigDecimalConstructorsTest?
testConstrDoubleNaNFailureImproper exception message
expected:<...e...> but was:<...y...>
testConstrDoublePosInfinityFailureImproper exception message
expected:<...e...> but was:<...y...>
testConstrDoubleNegInfinityFailureImproper exception message
expected:<...e...> but was:<...y...>
I believe it is caused by the patch of i18n message properties, it
returns "Infinity or NaN", I've updated it at revision r450333, but is
it necessary to verify exception message so strictly like this?
try {
new BigDecimal(a);
fail("NumberFormatException has not been caught");
} catch (NumberFormatException e) {
assertEquals("Improper exception message", "Infinite or NaN",
e.getMessage());
}
--
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: [VOTE] HARMONY-1217 : JNI-style C header file generator (aka 'javah')
+1 -Stepan. On 9/25/06, Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1217 wrt BCC and ACQ. Please vote to accept or reject this contribution into the Apache Harmony project : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - 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] x509 test failures
Tim,
A signature of CertificatePolicies.addPolicyInformation was changed:
-public void addPolicyInformation(PolicyInformation policyInformation) {
+public CertificatePolicies addPolicyInformation(
+PolicyInformation policyInformation) {
Did you rebuild the workspace before running tests?
Thanks,
Stepan.
On 9/23/06, Stepan Mishura wrote:
I'll look into ...
Yes, I updated X.509 framework yesterday, run all tests on Linux but
I did not see any failures.
-Stepan.
On 9/22/06, Tim Ellison wrote:
>
> Anyone else seeing them on current head (r448946)?
>
> I get four failures, like this:
>
>
org/apache/harmony/security/x509/CertificatePolicies.addPolicyInformation(Lorg/apache/harmony/security/x509/PolicyInformation;)V
>
>
> java.lang.NoSuchMethodError:
>
>
org/apache/harmony/security/x509/CertificatePolicies.addPolicyInformation(Lorg/apache/harmony/security/x509/PolicyInformation;)V
> at
> java.security.cert.X509CertSelectorTest$TestCert.getExtensionValue (
> X509CertSelectorTest.java:425)
> at
> java.security.cert.X509CertSelector.getExtensionValue(
> X509CertSelector.java:86)
> at java.security.cert.X509CertSelector.match(X509CertSelector.java:16)
> at
> java.security.cert.X509CertSelectorTest.testSetPolicy (
> X509CertSelectorTest.java:2377)
> at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25)
>
> --
>
> Tim Ellison ([EMAIL PROTECTED])
> IBM Java technology centre, UK.
>
>
>
--
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] x509 test failures
I'll look into ... Yes, I updated X.509 framework yesterday, run all tests on Linux but I did not see any failures. -Stepan. On 9/22/06, Tim Ellison wrote: Anyone else seeing them on current head (r448946)? I get four failures, like this: org/apache/harmony/security/x509/CertificatePolicies.addPolicyInformation(Lorg/apache/harmony/security/x509/PolicyInformation;)V java.lang.NoSuchMethodError: org/apache/harmony/security/x509/CertificatePolicies.addPolicyInformation(Lorg/apache/harmony/security/x509/PolicyInformation;)V at java.security.cert.X509CertSelectorTest$TestCert.getExtensionValue( X509CertSelectorTest.java:425) at java.security.cert.X509CertSelector.getExtensionValue( X509CertSelector.java:86) at java.security.cert.X509CertSelector.match(X509CertSelector.java:16) at java.security.cert.X509CertSelectorTest.testSetPolicy( X509CertSelectorTest.java:2377) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [legal] change of copyright notice policy
On 9/21/06, Geir Magnusson Jr. wrote: The ASF has changed it's copyright notice policy for source files. The policy is noted here : http://www.apache.org/legal/src-headers.html Any release after Nov 1, 2006 must conform to this policy. Since we aren't near a release yet, we have plenty of time, but we should do this sooner than later. First and foremost, any new contributions should follow the policy. IOW, from today all new files coming to SVN should contain a new license header. Right? -Stepan. Second, we should decide how we want to proceed. It's clear to me that we're not going to naturally touch all the files over time in any reasonable amount of time, so we can't just do it over time as we work on the code. The best solution is a script that can be run on an arbitrary source tree, so that developers can do this on a package by package basis (or the whole thing at once, although it seems package by package over time by all the committers seems to be a good way to farm out the work. :) I think that patches are a bad idea for this since the script is neater and re-usable for other projects as well. Thoughts? geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [General]Different SerialVersionID between RI and Harmony
On 9/21/06, Spark Shen wrote: Stepan Mishura 写道: > On 9/21/06, Spark Shen wrote: >> >> Tony Wu 写道: >> > I had a look at the comparison result on kaffe.org[1] and I'm very >> > glad to see it had fully achieved the 90 percent code coverage in this >> > September :) >> > In the meanwhile, I noticed many differences from RI were >> > SerialVersionID related. >> > I volunteer to fix these problems if no one >> > objects. >> > [1] >> > >> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_util >> >> > >> Hi Tony: >> >> Many are coursed by the spec did not give a offical statement about the >> SerialVersionID. > > > > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED] > Thanks stepan. And I think you support us to add those SerialVersionID. :-) Sure. -Stepan. Best regards > > -Stepan. > > But, since the test reveals the SerialVersionID of RI, I think we should >> follow RI's behavior. I will join you to supply patch for them. >> >> Best regards >> >> >> -- >> Spark Shen >> China Software Development Lab, IBM
Re: [General]Different SerialVersionID between RI and Harmony
On 9/21/06, Spark Shen wrote: Tony Wu 写道: > I had a look at the comparison result on kaffe.org[1] and I'm very > glad to see it had fully achieved the 90 percent code coverage in this > September :) > In the meanwhile, I noticed many differences from RI were > SerialVersionID related. > I volunteer to fix these problems if no one > objects. > [1] > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-harmony.html#pkg_java_util > Hi Tony: Many are coursed by the spec did not give a offical statement about the SerialVersionID. http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200601.mbox/[EMAIL PROTECTED] -Stepan. But, since the test reveals the SerialVersionID of RI, I think we should follow RI's behavior. I will join you to supply patch for them. Best regards -- Spark Shen 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]
[general][jira] granting ASF license to a team's work (was: Re: [jira] Assigned: (HARMONY-1486) [doc] Keytool user's guide update)
Hi, I'd like to understand what a rule for granting ASF license to a team's work is. Let's look into the HARMONY-1486 - its description contains the following phrase: "This update is the result of cooperative work of Anton Rusanov and Nadya Morozova". So we have one file that was updated by Anton and Nadya. IIUC, Anton as a reporter granted a license to ASF for inclusion ONLY HIS work. And what about Nadya? Should she confirm by commenting the issue that she agree with inclusion HER work?Or there is nothing to care about. Thanks, Stepan. On 9/21/06, Stepan Mishura (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-1486?page=all ] Stepan Mishura reassigned HARMONY-1486: ------- Assignee: Stepan Mishura > [doc] Keytool user's guide update > - > > Key: HARMONY-1486 > URL: http://issues.apache.org/jira/browse/HARMONY-1486 > Project: Harmony > Issue Type: Improvement > Components: Classlib > Reporter: Anton Rusanov > Assigned To: Stepan Mishura > Attachments: Keytool_help.html > > > Key changes in the doc: > - added options' descriptions, > - added some styles to make reading easier, > - merged common options and default values to have a comprehensive set of options used with the tool, > - checked and corrected writing style. > The document differs from the original draft too much to make a diff. So please, replace the file enhanced/classlib/trunk/doc/tools/Keytool/Keytool_help.html with the attached one. > This update is the result of cooperative work of Anton Rusanov and Nadya Morozova. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [test] Jetty integration progress ? (was Re: [classlib] jetty based tests)
On 9/19/06, Richard Liang wrote:
On 9/18/06, Geir Magnusson Jr. wrote:
>
>
> Andrew Zhang wrote:
> > On 9/18/06, Richard Liang <[EMAIL PROTECTED]> wrote:
> >>
> >> On 9/18/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> >> > Hi,
> >> >
> >> > It's me again. Seems no big progress on jetty. I'd like to take the
job
> >> if
> >> > no one objects. Here are my suggestions:
> >>
> >> Great :-)
> >>
> >> >
> >> > 1. jetty version: I suggest that Harmony adopt jetty 6. Because
many
> >> > 5.xAPIs are deprecated in jetty 6, we'd better follow latest jetty
> >> > version.
> >>
> >> +1
> >>
> >> >
> >> > 2. location to put jetty jars: support module.
> >> >
> >>
> >> Do you mean we will check the jetty jars into Harmony svn?
> >
> >
> > Yes. Is it OK? Or put the jar in depends folder?
>
> Just make it a depends. We should avoid checking in jars.
>
Yes. It's good make jetty as a depends, and we could add jetty.jar
into their build scripts if some modules (e.g., luni) require jetty.
Just thinking about another question, how shall we handle the
.classpath of luni in Eclipse? Use external jar"?
I'd use it as 'support.jar' - so it is downloaded to 'depends', copied by
the build to 'deploy/build/test' and added as external jar in Eclipse.
Thanks,
Stepan.
>
> >> 3. how to write jetty test? I suggest that we could start jetty in
any
> >> test
> >> > if necessary. If we found there are heavy code duplicates, we could
> >> extract
> >> > them as utility methods in support module. So far, I'd like to
write
> >> jetty
> >> > test directly in each module, because the code is rather simple,
only a
> >> few
> >> > lines.[1] It's also easy to write user-customized handler for
> >> > negative tests. Let's make it work, and then make it better. :-)
> >> >
> >> > Any suggestions/comments/objections? I volunteer to upload patches
> >> when
> >> we
> >> > reach an agreement.
> >> >
> >> > Best regards,
> >> > Andrew
> >> >
> >> > [1]
> >> > jetty-based test example:
> >> > setUp code:
> >> > port = Support_PortManager.getNextPort();
> >> > Server server = new Server(port);
> >> > ResourceHandler resource_handler=new ResourceHandler();
> >> > resource_handler.setResourceBase("somewhere");
> >> > server.setHandler(resource_handler);
> >> > server.start();
> >> > tearDown code:
> >> > server.stop();
> >> >
> >> >
> >>
> >>
> >> --
> >> Richard Liang
> >> China 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]
[classlib][suncompat] do we need compatibility tests?
Hi, When we created 'suncompat' module we were not going to put any tests there (at least we didn't talk about them). But I think it might make sense to have compatibility tests for 'suncompat' module. For example, if there is a bug in Base64 class. When the bug is fixed a regression test is added to luni module only. Well, a developer may also additionally verify that the regression tests also passes on RI by changing the test to run it against sun.misc.Base64Encoder class. But what if next Base64 RI's version will be incompatible with Harmony (for example, because of another bug fix)? And how we are going to know about that? Yes, there is a chance that an user will complain about application incompatibility or some classlib test that depends on Base64 class will fail on new RI's version. But we can track that directly by having the same test against Base64 class in 'suncompat' as we have in 'luni'. Does this make sense? Thanks, Stepan Mishura 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][luni] java.net.URL(String, String, int, String) constructor exception thrown sequence (was re: [jira] Commented: (HARMONY-1158) [classlib][luni]Compatibility: java.net.URL new URL("ss",
On 9/14/06, Alexey Petrenko wrote: 2006/9/14, Stepan Mishura : > On 9/14/06, Alexey Petrenko wrote: > > > > 2006/9/14, Stepan Mishura : > > > On 9/14/06, Andrew Zhang wrote: > > > > > > > > There are two reasons: > > > > > > > > 1. Spec has explicitly pointed out "No validation of the inputs is > > > > performed > > > > by this constructor." > > > > > > > > > > > > In this spec. quotation above there is one thing that confuses me - > > "THIS > > > CONSTRUCTOR". May this mean that validation of inputs is perform, for > > > example, only by corresponding protocol handler? > > > > > > This looks logical because only protocol handler can verify whether > > params > > > are correct or not. > > Almost right. But if RI passes all the parameters to protocol handler > > then it should throw unknown protocol for all these cases. Since "ss" > > is unknown protocol. > > And you do not need a protocol handler to understand that port number > > can not have a negative value :) > Not agree. What if I add a custom protocol handler that accepts negative > port values? It will break RFC 2396 (Uniform Resource Identifiers (URI): Generic Syntax) [1] where port is specified as "port = *digit". And this is unsigned value. Then the spec. is not quite correct - the constructor validates some inputs :-) -Stepan -- 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][luni] java.net.URL(String, String, int, String) constructor exception thrown sequence (was re: [jira] Commented: (HARMONY-1158) [classlib][luni]Compatibility: java.net.URL new URL("ss",
On 9/14/06, Alexey Petrenko wrote:
2006/9/14, Stepan Mishura :
> On 9/14/06, Andrew Zhang wrote:
> >
> > There are two reasons:
> >
> > 1. Spec has explicitly pointed out "No validation of the inputs is
> > performed
> > by this constructor."
>
>
>
> In this spec. quotation above there is one thing that confuses me -
"THIS
> CONSTRUCTOR". May this mean that validation of inputs is perform, for
> example, only by corresponding protocol handler?
>
> This looks logical because only protocol handler can verify whether
params
> are correct or not.
Almost right. But if RI passes all the parameters to protocol handler
then it should throw unknown protocol for all these cases. Since "ss"
is unknown protocol.
And you do not need a protocol handler to understand that port number
can not have a negative value :)
Not agree. What if I add a custom protocol handler that accepts negative
port values?
Thanks,
Stepan.
SY, Alexey
>
> Thanks,
> Stepan.
>
> 2. The exception thrown sequence is really hard to follow, as described
by
> > Ilya, see examples below:
> >
> > 1. new URL("ss", "0", -3, null);
> > java.net.MalformedURLException: Invalid port number :-3
> >
> > 2. new URL("ss", null, -3, null);
> > java.lang.NullPointerException
> >
> > 3. new URL("ss", "0", -3, "file");
> > java.net.MalformedURLException: Invalid port number :-3
> >
> > 4. new URL("ss", null, -3, "file");
> > java.net.MalformedURLException: unknown protocol: ss
> >
> > 5. new URL("ss", "0", -1, null);
> > java.lang.NullPointerException
> >
> > Yes, we should follow RI for exception thrown sequence if possible.
But
> > for
> > thise case, would anyone suggest how to throw exception to follow RI?
> >
> >
> >
> >
> >
> > On 9/14/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> > >
> > > It's not clear why it should be non-bug diff?
> > >
> > > Shouldn't it be fixed to follow RI?
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > 2006/9/14, Andrew Zhang <[EMAIL PROTECTED]>:
> > > > Would any commiter like to confirm and close this "non-bug
differences
> > > from
> > > > RI" jira? Thanks!
> > > >
> > > > On 9/13/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > From: Andrew Zhang (JIRA) <[EMAIL PROTECTED]>
> > > > > Date: Sep 13, 2006 11:02 AM
> > > > > Subject: [jira] Commented: (HARMONY-1158)
> > > [classlib][luni]Compatibility:
> > > > > java.net.URL new URL("ss", null, -3, null) throws
> > > MalformedURLException
> > > > > while RI throws NPE
> > > > > To: [EMAIL PROTECTED]
> > > > >
> > > > >[
> > > > >
> > >
> >
http://issues.apache.org/jira/browse/HARMONY-1158?page=comments#action_12434348
> > > ]
> > > > >
> > > > > Andrew Zhang commented on HARMONY-1158:
> > > > > ---
> > > > >
> > > > > Ilya, I agree with you. Spec has explicitly pointed out "No
> > validation
> > > of
> > > > > the inputs is performed by this constructor."
> > > > >
> > > > > The tests show that the exception thrown sequence is uncertain
and
> > > > > implemention-dependent.
> > > > >
> > > > > If no application and test cases are broken by currenty Harmony
> > code,
> > > I
> > > > > suggest not fix the problem.
> > > > >
> > > > > Best regards,
> > > > > Andrew
> > > > >
> > > > > > [classlib][luni]Compatibility: java.net.URL new URL("ss",
null,
> > -3,
> > > > > null) throws MalformedURLException while RI throws NPE
> > > > > >
> > > > >
> > >
> >
--
> > > > > >
> > > > > > Key: HARMONY-1158
> > > > > > URL:
> > > http://issues.apache.org/jira/browse/HARMONY-1158
> > > > > > Project: Harmony
> > > > > > Issue Type: Bug
> > > > &
Re: [classlib][luni] java.net.URL(String, String, int, String) constructor exception thrown sequence (was re: [jira] Commented: (HARMONY-1158) [classlib][luni]Compatibility: java.net.URL new URL("ss",
ava:373) > > > > at java.net.URL.(URL.java:283) > > > > at test.main(test.java:7) > > > > java.lang.NullPointerException > > > > at java.net.Parts.(URL.java:1259) > > > > at java.net.URL.(URL.java:380) > > > > at java.net.URL.(URL.java:283) > > > > at test.main(test.java:13) > > > > Output on Harmony: > > > > java.net.MalformedURLException: Port out of range: -3 > > > > at java.net.URL.(URL.java:393) > > > > at java.net.URL.(URL.java:367) > > > > at test.main(test.java:7) > > > > java.net.MalformedURLException: Port out of range: -3 > > > > at java.net.URL.(URL.java:393) > > > > at java.net.URL.(URL.java:367) > > > > > > -- > > > This message is automatically generated by JIRA. > > > - > > > If you think it was sent incorrectly contact one of the > administrators: > > > http://issues.apache.org/jira/secure/Administrators.jspa > > > - > > > For more information on JIRA, see: > http://www.atlassian.com/software/jira -- Thanks, Stepan Mishura 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: [JIRA]what is non-bug difference issue?
On 9/13/06, Tony Wu wrote: When I looked though the old JIRA issues I noticed that many non-bug difference issues had patches and some of them was fixed already. e.g. harmony-401 836 1050 and so on. IMHO the non-bug difference indicates that it is an acceptable difference between RI and Harmony and won't be fixed. Am I right? Yes, I think you are right. Thanks for catching this. IIRC we created this JIRA category just to document difference with RI but not to fix it. IMO you should add comments to such JIRAs asking why a difference was fixed. Thanks, Stepan Mishura 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: [jira] Updated: (HARMONY-1409) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport
On 9/13/06, Alexei Zakharov wrote: Ok, Stepan, in this case I suggest to leave the check and rise the additional "Non-bug differences from RI" JIRA (I can do if no one objects). I don't really think there are many applications that rely on this silent RI behavior, and IMHO we should not care until we encounter one. Agree. Go forward with JIRA. -Stepan. Regards, 2006/9/12, Stepan Mishura <[EMAIL PROTECTED]>: > Just have found in java.beans package description: > "Unless explicitly stated, null values or empty Strings are not valid > parameters for the methods in this package. You may expect to see exceptions > if these parameters are used." > > So it is a bug in RI. > > -Stepan. > > On 9/12/06, Stepan Mishura wrote: > > > > Alexei, > > > > We have the following RI behaviour here: > > 1) Constructor doesn't allow 'null' value and throws NPE > > 2) setSource allow 'null' value > > > > This looks inconsistent - to assign soure null value we can not use > > constuctor directly! > > > > Thanks, > > Stepan. > > > > > > On 9/12/06, Alexei Zakharov wrote: > > > > > > Hi Stepan, > > > > > > Thank you for your attention to my patch first of all. IMHO everything > > > is ok except for the null-check you add to the setSource() method. It > > > seems RI does not check for null in this case. At least your > > > regression test fails on Sun JDK 1.5.0_06: > > > > > > No expected NullPointerException > > > junit.framework.AssertionFailedError: No expected NullPointerException > > >at > > > org.apache.harmony.beans.tests.java.beans.PropertyEditorSupportTest.test_setSourceLjava_lang_Object > > > (PropertyEditorSupportTest.java:291) > > > > > > Thanks, > > > > > > 2006/9/12, Stepan Mishura (JIRA) < [EMAIL PROTECTED]>: > > > > [ http://issues.apache.org/jira/browse/HARMONY-1409?page=all ] > > > > > > > > Stepan Mishura updated HARMONY-1409: > > > > > > > > > > > >Summary: [classlib][beans] add missing get/setSource methods to > > > PropertyEditorSupport (was: [classlib][beans] PropertyEditorSupport > > > cleanup) > > > > > > > > > [classlib][beans] add missing get/setSource methods to > > > PropertyEditorSupport > > > > > > > > > > > > > > > > > > Key: HARMONY-1409 > > > > > URL: > > > http://issues.apache.org/jira/browse/HARMONY-1409 > > > > > Project: Harmony > > > > > Issue Type: Improvement > > > > > Components: Classlib > > > > > Environment: ws2003 > > > > >Reporter: Alexei Zakharov > > > > > Assigned To: Stepan Mishura > > > > > Attachments: PropertyEditorSupport.patch > > > > > > > > > > > > > > > Attached patch adds two missing API methods that were introduced in > > > Java 1.5 API. In addition to that all unnecessary javadoc comments are > > > removed (@author and etc.), the coding style is corrected. > > > > > > > > -- > > > > This message is automatically generated by JIRA. > > > > - > > > > If you think it was sent incorrectly contact one of the > > > administrators: http://issues.apache.org/jira/secure/Administrators.jspa > > > > - > > > > For more information on JIRA, see: > > > http://www.atlassian.com/software/jira -- 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][swing] set of passed swing tests
Sorry, my question was unclear - you can try to update the script to fork new VM for each test. -Stepan. On 9/12/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: Can you run a single test? -Stepan On 9/12/06, Mikhail Loenko wrote: > > I'm trying to exclude all the swing tests that fail on linux. > But every time I run, exclude failuing tests and rerun, new tests fail > or hang up. > And it looks endless. > > any receipt? > > 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]
Re: [classlib][swing] set of passed swing tests
Can you run a single test? -Stepan On 9/12/06, Mikhail Loenko wrote: I'm trying to exclude all the swing tests that fail on linux. But every time I run, exclude failuing tests and rerun, new tests fail or hang up. And it looks endless. any receipt? 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]
Re: [jira] Updated: (HARMONY-1409) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport
Just have found in java.beans package description: "Unless explicitly stated, null values or empty Strings are not valid parameters for the methods in this package. You may expect to see exceptions if these parameters are used." So it is a bug in RI. -Stepan. On 9/12/06, Stepan Mishura wrote: Alexei, We have the following RI behaviour here: 1) Constructor doesn't allow 'null' value and throws NPE 2) setSource allow 'null' value This looks inconsistent - to assign soure null value we can not use constuctor directly! Thanks, Stepan. On 9/12/06, Alexei Zakharov wrote: > > Hi Stepan, > > Thank you for your attention to my patch first of all. IMHO everything > is ok except for the null-check you add to the setSource() method. It > seems RI does not check for null in this case. At least your > regression test fails on Sun JDK 1.5.0_06: > > No expected NullPointerException > junit.framework.AssertionFailedError: No expected NullPointerException >at > org.apache.harmony.beans.tests.java.beans.PropertyEditorSupportTest.test_setSourceLjava_lang_Object > (PropertyEditorSupportTest.java:291) > > Thanks, > > 2006/9/12, Stepan Mishura (JIRA) < [EMAIL PROTECTED]>: > > [ http://issues.apache.org/jira/browse/HARMONY-1409?page=all ] > > > > Stepan Mishura updated HARMONY-1409: > > > > > >Summary: [classlib][beans] add missing get/setSource methods to > PropertyEditorSupport (was: [classlib][beans] PropertyEditorSupport > cleanup) > > > > > [classlib][beans] add missing get/setSource methods to > PropertyEditorSupport > > > > > > > > > > Key: HARMONY-1409 > > > URL: > http://issues.apache.org/jira/browse/HARMONY-1409 > > > Project: Harmony > > > Issue Type: Improvement > > > Components: Classlib > > > Environment: ws2003 > > >Reporter: Alexei Zakharov > > > Assigned To: Stepan Mishura > > > Attachments: PropertyEditorSupport.patch > > > > > > > > > Attached patch adds two missing API methods that were introduced in > Java 1.5 API. In addition to that all unnecessary javadoc comments are > removed (@author and etc.), the coding style is corrected. > > > > -- > > This message is automatically generated by JIRA. > > - > > If you think it was sent incorrectly contact one of the > administrators: http://issues.apache.org/jira/secure/Administrators.jspa > > - > > For more information on JIRA, see: > http://www.atlassian.com/software/jira > > > -- Thanks, Stepan Mishura 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: Re: [classlib][TestNG] groups of Harmony test
gt; > 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. > > > > -- Thanks, Stepan Mishura 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: [jira] Updated: (HARMONY-1409) [classlib][beans] add missing get/setSource methods to PropertyEditorSupport
Alexei, We have the following RI behaviour here: 1) Constructor doesn't allow 'null' value and throws NPE 2) setSource allow 'null' value This looks inconsistent - to assign soure null value we can not use constuctor directly! Thanks, Stepan. On 9/12/06, Alexei Zakharov wrote: Hi Stepan, Thank you for your attention to my patch first of all. IMHO everything is ok except for the null-check you add to the setSource() method. It seems RI does not check for null in this case. At least your regression test fails on Sun JDK 1.5.0_06: No expected NullPointerException junit.framework.AssertionFailedError: No expected NullPointerException at org.apache.harmony.beans.tests.java.beans.PropertyEditorSupportTest.test_setSourceLjava_lang_Object (PropertyEditorSupportTest.java:291) Thanks, 2006/9/12, Stepan Mishura (JIRA) <[EMAIL PROTECTED]>: > [ http://issues.apache.org/jira/browse/HARMONY-1409?page=all ] > > Stepan Mishura updated HARMONY-1409: > > >Summary: [classlib][beans] add missing get/setSource methods to PropertyEditorSupport (was: [classlib][beans] PropertyEditorSupport cleanup) > > > [classlib][beans] add missing get/setSource methods to PropertyEditorSupport > > > > > > Key: HARMONY-1409 > > URL: http://issues.apache.org/jira/browse/HARMONY-1409 > > Project: Harmony > > Issue Type: Improvement > > Components: Classlib > > Environment: ws2003 > >Reporter: Alexei Zakharov > > Assigned To: Stepan Mishura > > Attachments: PropertyEditorSupport.patch > > > > > > Attached patch adds two missing API methods that were introduced in Java 1.5 API. In addition to that all unnecessary javadoc comments are removed (@author and etc.), the coding style is corrected. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira -- Alexei Zakharov, Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura 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] [ldap] reuse of security parser
Hi Daniel, Yes, the parser used by 'security' code put some restrictions on distinguished names (see [1]) and IMO it is a good idea to try to improve the parser to make it possible to reuse it by 'jndi' module. When we developed security code we also thought about creating a common 'engine' for parsing distinguished names that can be extended by 'security' and 'ldap' code. But because of time limit we put off developing such 'engine' for a while. It is great to hear that you work on completing 'ldap' public API and I think that it is time to return this. As I understood you the current parser suits for 'ldap' code and can be used as common 'engine' for both modules (only minor updates are required, like changing visibility attributes). Then I think the best way is to submit a patch to JIRA and discuss it. And if we'll find out later that more updates are required then IMO we should think about redesigning the parser code. Thoughts? Ideas? Thanks, Stepan. [1] http://java.sun.com/j2se/1.5.0/docs/api/javax/security/auth/x500/X500Principal.html On 9/9/06, Daniel Gandara wrote: Hi all, as you know at the ITC we are working to complete javax.naming.ldap package v 1.5. We are currently implementing the 1.5 classes and I have one question regarding the reuse of an already donated code from other package (org.apache.harmony.security.x509). The specific issue is as follow: in order to implement the classes LdapName and Rdn -from javax.naming.ldap- we need a Distinguished Name parser that parses according to the bnf syntax specified in RFC2253 and RFC1779. We've found a DNParser class in the package org.apache.harmony.security.x509 we could re-use, but it checks for valid AttributeTypes by looking in a table of valid OIDs. What we need is a less restrictive parser that allows types that do not have a valid OID. We could easily implement this behavior extending from this class and rewriting the specific functionality; but we would have to change some methods and attributes visibility of DNParser and AttributeTypeAndValue from private to protected. The specific question is: should we made this change on the security package and submit it with our contribution? or should we ask for this change to be made by the ones who wrote the security package? I'll wait for feedback, Thanks, Daniel -- Thanks, Stepan Mishura 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][logging] a test suite shouldn't touch any of JRE config files!!!
On 9/5/06, Paulex Yang wrote: Stepan Mishura wrote: > Paulex, thanks for your patience and answers. > > Yes, Sun's JRE sets root logger's level according to > 'lib/logging.properties'. Also specifying the level for root logger in > j.u.l.config.file doesn't help. (I assumed before that a JRE respects my > "lovely" custom LogManager settings :-(! ) > > OK. Let's return to the initial issue: how to run logging tests without > changing JRE config files? > > I still believe that there should be some elegant way for testing logging > implementation without touching JRE files. I agreed this is not acceptable. AFAIK current LogManagerTest has used a MockLogManager in most test cases, so the migration should be relatively easy. > For example, what > about developing custom LogManager for testing? The testing manager will > work in 2 modes: default configuration and custom configuration. A > test will > have a hook to switch testing manager's mode. The first configuration is > read from JRE config files (by j.u.l.LogManager implementation) and the > second one will be fully controlled by a test and is set by the test > via some manager's method (say readConfiguration(InputStream)). Does this > sound crazy? Maybe we just need one Support_Exec() invocation to verify if the LogManager reads the default logging properties(jre/lib/logging.properties) correctly(which should be straightforward by also loading and parsing that properties in test codes), for other tests, we always use customized LogManager or configuration files. If you are fine with this, I'm volunteer to refactor the tests. Agree with this approach. Thanks, Stepan -- 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!!!
On 9/5/06, Paulex Yang wrote: Stepan Mishura wrote: > On 9/4/06, *Paulex Yang* wrote: > > 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. > > The test prints the following: > $java -classpath . MyTest > INFO > $java -classpath . -Djava.util.logging.manager=CustomLogManager MyTest > SEVERE > > Did I missed something? Stepan, I run the test under Sun JDK 1.5.0_06 for WinXP, but I got "INFO" printed for both cases... Paulex, thanks for your patience and answers. Yes, Sun's JRE sets root logger's level according to 'lib/logging.properties'. Also specifying the level for root logger in j.u.l.config.file doesn't help. (I assumed before that a JRE respects my "lovely" custom LogManager settings :-(! ) OK. Let's return to the initial issue: how to run logging tests without changing JRE config files? I still believe that there should be some elegant way for testing logging implementation without touching JRE files. For example, what about developing custom LogManager for testing? The testing manager will work in 2 modes: default configuration and custom configuration. A test will have a hook to switch testing manager's mode. The first configuration is read from JRE config files (by j.u.l.LogManager implementation) and the second one will be fully controlled by a test and is set by the test via some manager's method (say readConfiguration(InputStream)). Does this sound crazy? Thoughts? Other suggestions? Thanks, Stepan Mishura 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][logging] a test suite shouldn't touch any of JRE config files!!!
On 9/5/06, Paulex Yang wrote: Stepan Mishura wrote: > On 9/4/06, *Paulex Yang* wrote: > > 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. > > The test prints the following: > $java -classpath . MyTest > INFO > $java -classpath . -Djava.util.logging.manager=CustomLogManager MyTest > SEVERE > > Did I missed something? Stepan, I run the test under Sun JDK 1.5.0_06 for WinXP, but I got "INFO" printed for both cases... Hmm, interesting. I've tried with BEA JRE ... going to check with Sun's Thanks, Stepan Mishura 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][logging] a test suite shouldn't touch any of JRE config files!!!
On 9/4/06, Paulex Yang wrote:
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.
The test 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: [classlib][security] Exception compatibility
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: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
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. > > > > -- 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 non bug difference from RI?
On 9/1/06, Paulex Yang wrote:
Stepan Mishura wrote:
> Andrew, thanks for the test. But working test doesn't mean that there
> is no
> bug :-)
>
> AFAIK in our case an operation on file (if file is not exist - create
> file)
> should be atomic. And it looks like Harmony implementation doesn't do in
> atomic way.(see FileHandler.initOutputFiles() method)
Seems there is a bug in the FileHandler.initOutputFiles(), in Ln. 232,
if the FileLock isn't held, the FileOutputStream should be closed before
continue.
lock = channel.tryLock();
if (null == lock) {
//the FileChannel(or FileOutputStream) should be
closed here
continue;
}
BTW, why FileNotFoundException is re-thrown in Ln. 223 ? IMO, try-catch
block should be deleted.
try {
fileStream = new FileOutputStream(fileName, append);
channel = fileStream.getChannel();
} catch(FileNotFoundException e){
//invalid path name, throw exception
throw e;
}
But I didn't catch up what's the "atomic" means here, do you mean the
tryLock() is not atomic or sth.? If so, any other solutions for Java
codes? Otherwise, I think current implementation is fine, if two process
try to open same log file at same time, only one process can get the
lock by tryLock(), and the other will close the FileOutputStream then
continue to try another log file name, anything I missed?
I was confused by gaps in code between File.exists(), new FileOutputStream()
and FileChannel.tryLock().
For example, I've tried to emulate the following situation:
A process VM_1 is up to lock a created file (Ln.230) and in this time a
process VM_2 found out that the file exists and deleted it (Ln.213). My
current result is that the file is locked successfully but may be I
incorrectly emulated situation. I'm going to continue experimenting and let
you know if it is possible to create reproducible files conflict.
Thanks,
Stepan Mishura
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][logging] A non bug difference from RI?
On 9/1/06, Andrew Zhang wrote:
On 9/1/06, Stepan Mishura wrote:
OK, I'll try to put the
> question in other words: if there is 2 VM running on the same machine
and
> on
> both VMs new FileHandler() is invoked then there is a files conflict.
And
> it
> is possible to resolve such kind of conflict only by creating lock-file.
RI output:
a a.1 a.lck a.1.lck
Harmony output
a a.1
The test case is simple if you'd like to try, just run two times, and
check
the log file in your disk.
public void test_FileHandler() throws Exception {
FileHandler handler = new FileHandler("a");
handler.publish(new LogRecord(Level.SEVERE, "msg"));
int count = 0;
while (count++ < 60) {
Thread.sleep(1000);
}
handler.close();
}
Andrew, thanks for the test. But working test doesn't mean that there is no
bug :-)
AFAIK in our case an operation on file (if file is not exist - create file)
should be atomic. And it looks like Harmony implementation doesn't do in
atomic way.(see FileHandler.initOutputFiles() method)
Thanks,
Stepan.
> Thanks,
> Stepan.
>
>
> >
> >
> > > >
> > > > > RI tries to delete the created file if FileHandler.close() is
> > > invoked.
> > > > And
> > > > > > Harmony doesn't. Why?
> > > > > >
> > > > > > Thanks,
> > > > > > Stepan.
> > > > > >
> > > > > > If we revise the MockSecurityManager a little, to allow .lck
> file
> > > > > > > permission,
> > > > > > >
> > > > > > >public void checkPermission(Permission perm) {
> > > > > > >if (perm instanceof FilePermission) {
> > > > > > >if (perm.getName().indexOf(".lck") == -1) {
> > > > > > >System.out.println("check " +
perm.getName
> > > ());
> > > > > > >throw new SecurityException();
> > > > > > >}
> > > > > > >}
> > > > > > >}
> > > > > > >
> > > > > > > The test will pass both against RI and Harmony.
> > > > > > >
> > > > > > > So I'd suggest to leave it as "non-bug difference from RI".
> > > > > > >
> > > > > > > Any comments? Thank you!
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Andrew Zhang
> > > > > > > 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][logging] a test suite shouldn't touch any of JRE config files!!!
On 9/1/06, Andrew Zhang wrote: On 8/31/06, Mikhail Loenko wrote: > 2006/8/30, Stepan Mishura : > > On 8/30/06, Andrew Zhang wrote: > > > > > On 8/30/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi, > > > > > > > > I was browsing thought logging tests and realized that running > logging > > > > test > > > > suite cause updates of tested JRE configuration. > > > > The ant script changes jre/lib/logging.properties file by: > > > > > > > > > > > > flatten="yes"> > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do believe that we shouldn't do testing in this way - if a test > > > requires > > > > special env. configuration(different from JRE's default) the test > suite > > > > shouldn't *hack* JRE config files. We should consider dynamic env. > > > > reconfiguration. For example, for this particular case is there any > > > > problem > > > > with using LogManager.readConfiguration(InputStream) to reinitialize > the > > > > logging properties? > > > > > > > > > Yes, they're different. :-) Static first initialization acts > differently > > > from readConfiguration if you take a look at the source code. :) > > > > > > Could you describe in few words what is the difference? > > > > > > > > > But I do agree that we should not change jre config in this way! I > > > suggest > > > solve this problem in following way: > > > 1. backup jre default logging.properties in ant before running logging > > > test. > > > > > > 2. copy test logging.properties to jre before running logging test. > > > 3. restore jre config when logging test ends. > > > > > > Make senses? > > > > > > I'd prefer not touch JRE files at all. For example, what if the suite > run > > is interrupted in the middle? I'm not quite comfort if Harmony test > suite > > touches RI's config files on my local disk. > > +1 > > I'm also not quite comfort if Harmony testsuite touches any files on my > disk > out of the sandbox where the project sits. > > also I'd not be happy if it formats my disks or sends messages from my > account. If Harmony would potientially format my disk, I'll remove it from my disk right away. :) Don't hurry! We may provide a test suite with three pop-up windows that appears one after another:-) 1) These tests may format your disk. Proceed? (Yes/No) 2) Are you sure that you want to run tests tests anyway? (Yes/No) 3) This is your last chance! Cancel? (Yes/No) Thanks, Stepan. Thanks, > Mikhail > > > > > Thanks, > > Stepan. > > > > > > > > > Also keep in mind that the test suite is expected to be run against > some > > > > compatible implementation. I think nobody is going to reinstall > Sun's > > > JRE > > > > each time after running Harmony test suite. > > > > > > > > > Agreed. :-) > > > > > > -- > > > Andrew Zhang > > > 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][logging] a test suite shouldn't touch any of JRE config files!!!
On 8/31/06, Stepan Mishura wrote: On 8/31/06, Stepan Mishura wrote: > On 8/30/06, Mark Hindess wrote: > > > > > On 30 August 2006 at 12:03, "Stepan Mishura" > wrote: > > > > Hi, > > > > I was browsing thought logging tests and realized that running logging > test > > suite cause updates of tested JRE configuration. > > The ant script changes jre/lib/logging.properties file by: > > > > > > flatten="yes"> > > > > > > > > > > > > The 'test' target depends on 'build' which in turn depends on the above > 'copy.resources' target. So this seems perfectly reasonable to me. > > > Hmm, but the file is changed during test suite run and even not > restored. I'll look into... > > Aha, test support class[1] changes the file. Thanks, Stepan. [1]http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/logging/src/test/java/org/apache/harmony/logging/tests/java/util/logging/util/DefaultPropertyHelper.java?view=markup Any volunteer to fix that? -Stepan. It's copying it to the jre to make the jre complete. It is part of the > > build not the test process. > > > > If it was copying to test.jre.home I'd be worried but I don't really > > see > > why this should be a problem. > > > > Regards, > > Mark. > > > > > I do believe that we shouldn't do testing in this way - if a test > > requires > > > special env. configuration(different from JRE's default) the test > > suite > > > shouldn't *hack* JRE config files. We should consider dynamic env. > > > reconfiguration. For example, for this particular case is there any > > problem > > > with using LogManager.readConfiguration(InputStream) to reinitialize > > the > > > logging properties? > > > Also keep in mind that the test suite is expected to be run against > > some > > > compatible implementation. I think nobody is going to reinstall > > Sun's JRE > > > each time after running Harmony test suite. > > > > > > > > > -- 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 non bug difference from RI?
On 8/31/06, Stepan Mishura wrote:
On 8/30/06, Andrew Zhang wrote:
>
> > > If I understoond correctly, new FileHandler() creates temporary file
> for
> > > logging (its name is defined by default configuration properties).
> That
> > is
> > > true for Harmony and RI. Right?
> >
> >
> > Stepan, you missed something here. :)
> > Both Harmony and RI creates a file (not temporary) for logging, and RI
> > created one more file(temporary) for locking.
> > RI tries to delete the temporary .lck file when fileHandler.close ()
is
> > invoked. Harmony has nothing to be deleted. :)
>
>
> IOW, Harmony uses different locking approach for log-files and the test
> above demonstrate side-effect of different approaches. Right?
Yes, exatcly.
IMO, we should add a note to the documentation: why we chose different
> locking approach.
Rather than adding a note to source code, I think it's more helpful to
document the difference on the test.
Yes, documenting our implementation design is helpful, but I think there's
no need to document the design differences between Harmony and RI.
We don't care the design and implementation of RI, do we? So I suggest
document some words on the test case, like "RI fails here because ".
Comments/objections? Thanks!
BTW, if two VMs tries to open the same file for logging how this conflict
is resolved by Harmony if there is not lock file?
It seems that nobody understood the question. OK, I'll try to put the
question in other words: if there is 2 VM running on the same machine and on
both VMs new FileHandler() is invoked then there is a files conflict. And it
is possible to resolve such kind of conflict only by creating lock-file.
Right?
Thanks,
Stepan.
> >
> > > RI tries to delete the created file if FileHandler.close() is
> invoked.
> > And
> > > > Harmony doesn't. Why?
> > > >
> > > > Thanks,
> > > > Stepan.
> > > >
> > > > If we revise the MockSecurityManager a little, to allow .lck file
> > > > > permission,
> > > > >
> > > > >public void checkPermission(Permission perm) {
> > > > >if (perm instanceof FilePermission) {
> > > > >if (perm.getName().indexOf(".lck") == -1) {
> > > > >System.out.println("check " + perm.getName
> ());
> > > > >throw new SecurityException();
> > > > >}
> > > > >}
> > > > >}
> > > > >
> > > > > The test will pass both against RI and Harmony.
> > > > >
> > > > > So I'd suggest to leave it as "non-bug difference from RI".
> > > > >
> > > > > Any comments? Thank you!
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Andrew Zhang
> > > > > 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][logging] a test suite shouldn't touch any of JRE config files!!!
On 8/30/06, Andrew Zhang wrote: On 8/30/06, Stepan Mishura wrote: > > On 8/30/06, Andrew Zhang wrote: > > > On 8/30/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > I was browsing thought logging tests and realized that running logging > > > test > > > suite cause updates of tested JRE configuration. > > > The ant script changes jre/lib/logging.properties file by: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do believe that we shouldn't do testing in this way - if a test > > requires > > > special env. configuration(different from JRE's default) the test > suite > > > shouldn't *hack* JRE config files. We should consider dynamic env. > > > reconfiguration. For example, for this particular case is there any > > > problem > > > with using LogManager.readConfiguration(InputStream) to reinitialize > the > > > logging properties? > > > > > > Yes, they're different. :-) Static first initialization acts differently > > from readConfiguration if you take a look at the source code. :) > > > Could you describe in few words what is the difference? The static initialization block looks different from readConfigure(), doesn't it? :-) 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" 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. -- 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 non bug difference from RI?
On 8/30/06, Andrew Zhang wrote:
> > > If I understoond correctly, new FileHandler() creates temporary file
> for
> > > logging (its name is defined by default configuration properties).
> That
> > is
> > > true for Harmony and RI. Right?
> >
> >
> > Stepan, you missed something here. :)
> > Both Harmony and RI creates a file (not temporary) for logging, and RI
> > created one more file(temporary) for locking.
> > RI tries to delete the temporary .lck file when fileHandler.close() is
> > invoked. Harmony has nothing to be deleted. :)
>
>
> IOW, Harmony uses different locking approach for log-files and the test
> above demonstrate side-effect of different approaches. Right?
Yes, exatcly.
IMO, we should add a note to the documentation: why we chose different
> locking approach.
Rather than adding a note to source code, I think it's more helpful to
document the difference on the test.
Yes, documenting our implementation design is helpful, but I think there's
no need to document the design differences between Harmony and RI.
We don't care the design and implementation of RI, do we? So I suggest
document some words on the test case, like "RI fails here because ".
Comments/objections? Thanks!
BTW, if two VMs tries to open the same file for logging how this conflict is
resolved by Harmony if there is not lock file?
Thanks,
Stepan
>
> > RI tries to delete the created file if FileHandler.close() is invoked.
> And
> > > Harmony doesn't. Why?
> > >
> > > Thanks,
> > > Stepan.
> > >
> > > If we revise the MockSecurityManager a little, to allow .lck file
> > > > permission,
> > > >
> > > >public void checkPermission(Permission perm) {
> > > >if (perm instanceof FilePermission) {
> > > >if (perm.getName().indexOf(".lck") == -1) {
> > > >System.out.println("check " + perm.getName());
> > > >throw new SecurityException();
> > > >}
> > > >}
> > > >}
> > > >
> > > > The test will pass both against RI and Harmony.
> > > >
> > > > So I'd suggest to leave it as "non-bug difference from RI".
> > > >
> > > > Any comments? Thank you!
> > > >
> > > >
> > > >
> > > > --
> > > > Andrew Zhang
> > > > 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][logging] a test suite shouldn't touch any of JRE config files!!!
On 8/31/06, Stepan Mishura wrote: On 8/30/06, Mark Hindess wrote: > > On 30 August 2006 at 12:03, "Stepan Mishura" wrote: > > Hi, > > I was browsing thought logging tests and realized that running logging test > suite cause updates of tested JRE configuration. > The ant script changes jre/lib/logging.properties file by: > > > > > > > > The 'test' target depends on 'build' which in turn depends on the above 'copy.resources' target. So this seems perfectly reasonable to me. Hmm, but the file is changed during test suite run and even not restored. I'll look into... Aha, test support class[1] changes the file. Thanks, Stepan. [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/logging/src/test/java/org/apache/harmony/logging/tests/java/util/logging/util/DefaultPropertyHelper.java?view=markup Thanks, Stepan. It's copying it to the jre to make the jre complete. It is part of the > build not the test process. > > If it was copying to test.jre.home I'd be worried but I don't really see > why this should be a problem. > > Regards, > Mark. > > > I do believe that we shouldn't do testing in this way - if a test > requires > > special env. configuration(different from JRE's default) the test > suite > > shouldn't *hack* JRE config files. We should consider dynamic env. > > reconfiguration. For example, for this particular case is there any > problem > > with using LogManager.readConfiguration(InputStream) to reinitialize > the > > logging properties? > > Also keep in mind that the test suite is expected to be run against > some > > compatible implementation. I think nobody is going to reinstall Sun's > JRE > > each time after running Harmony test suite. > > > > > -- 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!!!
On 8/30/06, Mark Hindess wrote: On 30 August 2006 at 12:03, "Stepan Mishura" wrote: > > Hi, > > I was browsing thought logging tests and realized that running logging test > suite cause updates of tested JRE configuration. > The ant script changes jre/lib/logging.properties file by: > > > > > > > > The 'test' target depends on 'build' which in turn depends on the above 'copy.resources' target. So this seems perfectly reasonable to me. Hmm, but the file is changed during test suite run and even not restored. I'll look into... Thanks, Stepan. It's copying it to the jre to make the jre complete. It is part of the build not the test process. If it was copying to test.jre.home I'd be worried but I don't really see why this should be a problem. Regards, Mark. > I do believe that we shouldn't do testing in this way - if a test requires > special env. configuration(different from JRE's default) the test suite > shouldn't *hack* JRE config files. We should consider dynamic env. > reconfiguration. For example, for this particular case is there any problem > with using LogManager.readConfiguration(InputStream) to reinitialize the > logging properties? > Also keep in mind that the test suite is expected to be run against some > compatible implementation. I think nobody is going to reinstall Sun's JRE > each time after running Harmony test suite. > > -- 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!!!
On 8/30/06, Andrew Zhang wrote: On 8/30/06, Stepan Mishura wrote: > > On 8/30/06, Andrew Zhang wrote: > > > On 8/30/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > > > > > Hi, > > > > > > I was browsing thought logging tests and realized that running logging > > > test > > > suite cause updates of tested JRE configuration. > > > The ant script changes jre/lib/logging.properties file by: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I do believe that we shouldn't do testing in this way - if a test > > requires > > > special env. configuration(different from JRE's default) the test > suite > > > shouldn't *hack* JRE config files. We should consider dynamic env. > > > reconfiguration. For example, for this particular case is there any > > > problem > > > with using LogManager.readConfiguration(InputStream) to reinitialize > the > > > logging properties? > > > > > > Yes, they're different. :-) Static first initialization acts differently > > from readConfiguration if you take a look at the source code. :) > > > Could you describe in few words what is the difference? The static initialization block looks different from readConfigure(), doesn't it? :-) OK. I'll look into. Let the test authors speak for themselves. However, I think specifying test.properties makes sense sometimes. Consider following test scenario: "java.util.logging.config.class" is set. We want to verify that LogManager is loaded as "java.util.logging.config.class" property, rather than "lib/logging.properties" in the JRE directory. How could we assert the result? A test can fork VM with -Djava.util.logging.config.class= and verify that required class was used. We should assert the loaded handlers, level, ... are the same as " java.util.logging.config.class", and properties in "lib/logging.properties" are not loaded. Notice that the default lib/logging.properties may be changed by users. It's better to use a certain test properties than uncertain default properties(we can't assume users never try to modify it!). It is up to user to set JRE default properties and the testing suite shouldn't modify them because there is a risk to damage user's default settings. But after looking at the test cases, it seems there are no such tests. May such tests are deleted? I noticed serveral variables are not used, like CONFIG_CLASS, CONFIG_FILE, and etc... > But I do agree that we should not change jre config in this way! I > > suggest > > solve this problem in following way: > > 1. backup jre default logging.properties in ant before running logging > > test. > > > > 2. copy test logging.properties to jre before running logging test. > > 3. restore jre config when logging test ends. > > > > Make senses? > > > I'd prefer not touch JRE files at all. For example, what if the suite run > is interrupted in the middle? I'm not quite comfort if Harmony test suite > touches RI's config files on my local disk. Basically, I agree with you. But it doesn't happen without any cost. We can't write some tough tests like the example mentioned above. If we decide to delete these overkilled tests(seems I can't find such test in logging module :) ), I totally agree that never touch jre config file. Otherwise, it's acceptable to me that ant test tries its best to restore the default properties file, and ant build always puts the default logging.propertiesfile to deploy directory. What about specifying "java.util.logging.config.file" property in the ant script? IMO it solves the issue Thanks, Stepan. -- 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] HARMONY-790 is not reproducible
On 8/30/06, Mark Hindess wrote: On 30 August 2006 at 11:14, "Denis Kishenko" <[EMAIL PROTECTED]> wrote: > Mark and Geir thanks a lot. I understand you need time but most of > them have pretty simple patches. Just because they are simple doesn't mean we can apply them without thinking or without taking the time to run sufficient tests. For instance, one of the JIRA you list contains a (simple!) bad fix that breaks an existing valid test. ;-( As I pointed out before even simple fixes are unlikely to be committed without patches for regression tests. Writing a concise test is often harder than writing the fix. +1 -Stepan. -Mark. > 2006/8/30, Geir Magnusson Jr. <[EMAIL PROTECTED]>: > > Also, remember that people have to review the patch and decide that it's > > reasonable, not just blindly add them. > > > > That said, I'll start looking as well. > > > > geir > > > > > > Mark Hindess wrote: > > > On 28 August 2006 at 16:14, "Denis Kishenko" <[EMAIL PROTECTED]> wrote: > > >> 2006/8/25, Mark Hindess <[EMAIL PROTECTED]>: > > >>> Thanks for helping by looking at these. If you spot others and send > > >>> messages and/or add comments in JIRA I'll take a look at them. > > >> Mark > > >> > > >> There are a lot of unassigned issues with patches in JIRA. For example > > >> most of issues listed bellow were created more then two weeks ago. > > >> http://issues.apache.org/jira/browse/HARMONY-1070 > > >> http://issues.apache.org/jira/browse/HARMONY-1118 > > >> http://issues.apache.org/jira/browse/HARMONY-1190 > > >> http://issues.apache.org/jira/browse/HARMONY-1131 > > >> http://issues.apache.org/jira/browse/HARMONY-1231 > > >> http://issues.apache.org/jira/browse/HARMONY-1168 > > >> http://issues.apache.org/jira/browse/HARMONY-1153 > > >> http://issues.apache.org/jira/browse/HARMONY-1107 > > >> http://issues.apache.org/jira/browse/HARMONY- > > >> http://issues.apache.org/jira/browse/HARMONY-1175 > > >> http://issues.apache.org/jira/browse/HARMONY-1244 > > > > > > Some of these are fixes without regression test patches. That might be > > > one reason why they are overlooked. Also it helps to indicate if the > > > bug is a blocker for running applications. > > > > > >> Also there are several assigned but not resolved issues which have patch > es to > > >> o. > > >> http://issues.apache.org/jira/browse/HARMONY-1031 > > >> http://issues.apache.org/jira/browse/HARMONY-1139 > > >> http://issues.apache.org/jira/browse/HARMONY-1148 > > >> http://issues.apache.org/jira/browse/HARMONY-1081 > > >> http://issues.apache.org/jira/browse/HARMONY-1184 > > >> http://issues.apache.org/jira/browse/HARMONY-1169 > > > > > > I'll let the respective assignees comment on these. > > > > > >> Could you please look at these issues? > > > > > > I'll try to look at those which have regression tests (at least). > > > > > > -Mark. > > > > > > > > > > > > - > > > 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] > > > > > > > -- > Denis M. Kishenko > 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Thanks, Stepan Mishura 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][logging] A non bug difference from RI?
On 8/30/06, Andrew Zhang wrote:
On 8/30/06, Stepan Mishura wrote:
>
> On 8/30/06, Andrew Zhang wrote:
> >
> > Hi folks,
> >
> > When SecurityManager is enabled and all file permissions are disabled,
> RI
> > fails to new a FileHandler while Harmony allows.
> > Following test code shows the differences:
> >
> >public void test_FileHandler() throws Exception {
> >FileHandler handler = new FileHandler();
> >SecurityManager originalSecurityManager =
> System.getSecurityManager
> > ();
> >try {
> >System.setSecurityManager(new MockFileSecurityManager());
> >handler.publish(new LogRecord(Level.SEVERE, "msg"));
> >
> > // SecurityException is thrown here
> >handler.close();
> >} finally {
> >System.setSecurityManager(originalSecurityManager);
> >}
> >}
> >
> >public static class MockFileSecurityManager extends SecurityManager
{
> >public void checkPermission(Permission perm) {
> >if (perm instanceof FilePermission) {
> >System.out.println("check " + perm.getName());
> >throw new SecurityException();
> >}
> >}
> >}
> > FileHandler.close() spec says "Throws: SecurityException - if a
security
> > manager exists and if the caller does not have
> > LoggingPermission("control").", In the code above, control permission
is
> > allowed. The failure stack trace against RI looks like:
> >
> > java.lang.SecurityException
> > at com.andrew.LoggingTest$MockFileSecurityManager.checkPermission(
> > LoggingTest.java:131)
> > at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
> > at java.io.File.exists(File.java:700)
> > at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:401)
> > at java.io.File.getCanonicalPath(File.java:531)
> > at java.io.FilePermission$1.run(FilePermission.java:218)
> > at java.security.AccessController.doPrivileged(Native Method)
> > at java.io.FilePermission.init(FilePermission.java:212)
> > at java.io.FilePermission.(FilePermission.java:264)
> > at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
> > at java.io.File.delete(File.java:869)
> > at java.util.logging.FileHandler.close(FileHandler.java:594)
> > at com.andrew.LoggingTest.test_FileHandler(LoggingTest.java:121)
> > ...
> >
> > The output is "check C:\Documents and
Settings\myaccount\java0.log.lck"
> >
> > It seems RI tries to delete .lck file, but has no
permission.
> > ".lck" file is never mentioned in spec, and should be implementation
> > detail.
> >
> > Current Harmony code never tries to lock a temp empty .lck file, so
the
> > test
> > passes against Harmony.
>
>
> If I understoond correctly, new FileHandler() creates temporary file for
> logging (its name is defined by default configuration properties). That
is
> true for Harmony and RI. Right?
Stepan, you missed something here. :)
Both Harmony and RI creates a file (not temporary) for logging, and RI
created one more file(temporary) for locking.
RI tries to delete the temporary .lck file when fileHandler.close() is
invoked. Harmony has nothing to be deleted. :)
IOW, Harmony uses different locking approach for log-files and the test
above demonstrate side-effect of different approaches. Right?
IMO, we should add a note to the documentation: why we chose different
locking approach.
Thanks,
Stepan.
RI tries to delete the created file if FileHandler.close() is invoked. And
> Harmony doesn't. Why?
>
> Thanks,
> Stepan.
>
> If we revise the MockSecurityManager a little, to allow .lck file
> > permission,
> >
> >public void checkPermission(Permission perm) {
> >if (perm instanceof FilePermission) {
> >if (perm.getName().indexOf(".lck") == -1) {
> >System.out.println("check " + perm.getName());
> >throw new SecurityException();
> >}
> >}
> >}
> >
> > The test will pass both against RI and Harmony.
> >
> > So I'd suggest to leave it as "non-bug difference from RI".
> >
> > Any comments? Thank you!
> >
> >
> >
> > --
> > Andrew Zhang
> > 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][logging] a test suite shouldn't touch any of JRE config files!!!
On 8/30/06, Andrew Zhang wrote: On 8/30/06, Stepan Mishura <[EMAIL PROTECTED]> wrote: > > Hi, > > I was browsing thought logging tests and realized that running logging > test > suite cause updates of tested JRE configuration. > The ant script changes jre/lib/logging.properties file by: > > > > > > > > > > I do believe that we shouldn't do testing in this way - if a test requires > special env. configuration(different from JRE's default) the test suite > shouldn't *hack* JRE config files. We should consider dynamic env. > reconfiguration. For example, for this particular case is there any > problem > with using LogManager.readConfiguration(InputStream) to reinitialize the > logging properties? Yes, they're different. :-) Static first initialization acts differently from readConfiguration if you take a look at the source code. :) Could you describe in few words what is the difference? But I do agree that we should not change jre config in this way! I suggest solve this problem in following way: 1. backup jre default logging.properties in ant before running logging test. 2. copy test logging.properties to jre before running logging test. 3. restore jre config when logging test ends. Make senses? I'd prefer not touch JRE files at all. For example, what if the suite run is interrupted in the middle? I'm not quite comfort if Harmony test suite touches RI's config files on my local disk. Thanks, Stepan. Also keep in mind that the test suite is expected to be run against some > compatible implementation. I think nobody is going to reinstall Sun's JRE > each time after running Harmony test suite. Agreed. :-) -- Andrew Zhang 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][logging] A non bug difference from RI?
On 8/30/06, Andrew Zhang wrote:
Hi folks,
When SecurityManager is enabled and all file permissions are disabled, RI
fails to new a FileHandler while Harmony allows.
Following test code shows the differences:
public void test_FileHandler() throws Exception {
FileHandler handler = new FileHandler();
SecurityManager originalSecurityManager = System.getSecurityManager
();
try {
System.setSecurityManager(new MockFileSecurityManager());
handler.publish(new LogRecord(Level.SEVERE, "msg"));
// SecurityException is thrown here
handler.close();
} finally {
System.setSecurityManager(originalSecurityManager);
}
}
public static class MockFileSecurityManager extends SecurityManager {
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
System.out.println("check " + perm.getName());
throw new SecurityException();
}
}
}
FileHandler.close() spec says "Throws: SecurityException - if a security
manager exists and if the caller does not have
LoggingPermission("control").", In the code above, control permission is
allowed. The failure stack trace against RI looks like:
java.lang.SecurityException
at com.andrew.LoggingTest$MockFileSecurityManager.checkPermission(
LoggingTest.java:131)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
at java.io.File.exists(File.java:700)
at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:401)
at java.io.File.getCanonicalPath(File.java:531)
at java.io.FilePermission$1.run(FilePermission.java:218)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.FilePermission.init(FilePermission.java:212)
at java.io.FilePermission.(FilePermission.java:264)
at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
at java.io.File.delete(File.java:869)
at java.util.logging.FileHandler.close(FileHandler.java:594)
at com.andrew.LoggingTest.test_FileHandler(LoggingTest.java:121)
...
The output is "check C:\Documents and Settings\myaccount\java0.log.lck"
It seems RI tries to delete .lck file, but has no permission.
".lck" file is never mentioned in spec, and should be implementation
detail.
Current Harmony code never tries to lock a temp empty .lck file, so the
test
passes against Harmony.
If I understoond correctly, new FileHandler() creates temporary file for
logging (its name is defined by default configuration properties). That is
true for Harmony and RI. Right?
RI tries to delete the created file if FileHandler.close() is invoked. And
Harmony doesn't. Why?
Thanks,
Stepan.
If we revise the MockSecurityManager a little, to allow .lck file
permission,
public void checkPermission(Permission perm) {
if (perm instanceof FilePermission) {
if (perm.getName().indexOf(".lck") == -1) {
System.out.println("check " + perm.getName());
throw new SecurityException();
}
}
}
The test will pass both against RI and Harmony.
So I'd suggest to leave it as "non-bug difference from RI".
Any comments? Thank you!
--
Andrew Zhang
China Software Development Lab, IBM
--
Thanks,
Stepan Mishura
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]
[classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Hi, I was browsing thought logging tests and realized that running logging test suite cause updates of tested JRE configuration. The ant script changes jre/lib/logging.properties file by: I do believe that we shouldn't do testing in this way - if a test requires special env. configuration(different from JRE's default) the test suite shouldn't *hack* JRE config files. We should consider dynamic env. reconfiguration. For example, for this particular case is there any problem with using LogManager.readConfiguration(InputStream) to reinitialize the logging properties? Also keep in mind that the test suite is expected to be run against some compatible implementation. I think nobody is going to reinstall Sun's JRE each time after running Harmony test suite. Thanks, Stepan Mishura 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 8/25/06, 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.
*os.any* - group of tests which pass on any platform. IMHO, most of our
tests should be in this group.
*os.* - 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. are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.
*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.* - 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. 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., we can just use state.broken.MacOS
If a test is marked as *state.broken.MacOS* then it sounds like the
test/implementation should be fixed. IMO we should use tag os.
to define explicitly valid platforms for the test so in this particular case
we should use 9 os.s
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).
Mixing different types of testing into one test-file doesn't look good for
me. I'd separate such tests by placing into different directories/packages.
Thanks,
Stepan.
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
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]
Re: [classlib][luni] A problem about behavior of EnumMap
On 8/28/06, Spark Shen wrote:
Hi All:
When I develop EnumMap,I find EnumMap strange on RI. As the following
code describes, the method entrySet() of
EnumMap returns a set view of mappings contained in this map. Then we
get the set's iterator and use the iterator's next() method to get an
Entry which contains one mapping. But if we use next() method again to
get another Entry, the previous Entry will also point to the next Entry.
import java.util.EnumMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;
import junit.framework.TestCase;
public class EnumMapTest extends TestCase{
enum Size {
Small, Middle, Big {
};
}
public void test_entrySet() {
EnumMap enumSizeMap = new EnumMap(Size.class);
enumSizeMap.put(Size.Middle, 1);
enumSizeMap.put(Size.Big, null);
Set set = enumSizeMap.entrySet();
Iterator iter = set.iterator();
Map.Entry entry = (Map.Entry) iter.next();
assertEquals(Size.Middle, entry.getKey());
Map.Entry entry1 = (Map.Entry) iter.next();
assertEquals(Size.Big, entry.getKey());
assertSame(entry,entry1);
}
}
I guess on RI, the returned iterator maintains a reference to current
entry and returns this reference in iter.next() method.
I do not think RI's behavior makes sense here. So I suggest not to
follow RI on the behavior.
I agree. RI behavior looks confusing.
Thanks,
Stepan Mishura
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: svn commit: r436667 - /incubator/harmony/enhanced/classlib/trunk/modules/sql/src/test/java/org/apache/harmony/sql/tests/java/sql/SQLExceptionTest.java
Can anybody explain me what is the problem with SQLExceptionTest.java? I've updated it twice but there are no diffs in commit notifications. They only say: Binary files /tmp/tmpn4i6Jh and /tmp/tmpCQUIda differ The file has the following properties: $svn proplist -v SQLExceptionTest.java Properties on 'SQLExceptionTest.java': svn:eol-style : native Thanks, Stepan. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 12:33 PM To: [EMAIL PROTECTED] Subject: svn commit: r436667 - /incubator/harmony/enhanced/classlib/trunk/modules/sql/src/test/java/org/ap ache/harmony/sql/tests/java/sql/SQLExceptionTest.java Author: smishura Date: Thu Aug 24 22:32:55 2006 New Revision: 436667 URL: http://svn.apache.org/viewvc?rev=436667&view=rev Log: Formatting Modified: incubator/harmony/enhanced/classlib/trunk/modules/sql/src/test/java/org/apa che/harmony/sql/tests/java/sql/SQLExceptionTest.java Modified: incubator/harmony/enhanced/classlib/trunk/modules/sql/src/test/java/org/apa che/harmony/sql/tests/java/sql/SQLExceptionTest.java URL: http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modu les/sql/src/test/java/org/apache/harmony/sql/tests/java/sql/SQLExceptionTes t.java?rev=436667&r1=43&r2=436667&view=diff === === Binary files /tmp/tmpn4i6Jh and /tmp/tmpCQUIda differ -- 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] How to handle bootclasspath tests
On 8/24/06, Richard Liang wrote: Hello All, I'm investigating the possibilities of migrating Harmony tests from JUnit/Directory layout to TestNG while reviewing all the related thread in mailing list. And I will try to answer the open issues. To make things simple, I will post the issues one by one. ;-) Question: How to handle bootclasspath tests? IMHO, I'm not sure whether it is a good idea to use TestNG groups to differentiate the "bootclasspath" tests and "classpath" tests. If we put "bootclasspath" and "classpath" tests in the same directory, and use TestNG groups to differentiate them. When we want to run the "bootclasspath" tests, we have to put all tests in bootclasspath including the "classpath" tests. I don't think it's a good approach. And I cannot find any ways to compile the java sources from one directory into several different directories (ANT or Eclipse). So I suggest we put bootclasspath tests and classpath tests into different directories. Yes, I agree. This is a good example for mixed approach: directory layout + TestNG annotations. Thanks, Stepan. But if we think putting all tests into bootclasspath is not a problem, we may have a workaround: running bootclasspath and classpath tests in separate tasks. I mean:1) Running bootclasspath tests with all tests in bootclasspath 2) running all classpath tests with all tests in classpath Please correct me if I'm wrong. Here is sample of how to launch TestNG in ANT: Thanks for reading this far. ;-) -- 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][html] Please evaluate proposed ASN.1 notation for HTML DTD
On 8/24/06, Miguel Montes wrote:
Thanks Stepan. So, it should be
BDTD ::= SEQUENCE {
name UTF8String,
entity SET OF HTMLEntity,
element SET OF HTMLElement
}
HTMLEntity ::= SEQUENCE {
name UTF8String,
value INTEGER,
general [0] IMPLICIT BOOLEAN DEFAULT FALSE,
parameter [1] IMPLICIT BOOLEAN DEFAULT FALSE,
data UTF8String
}
HTMLElement ::= SEQUENCE {
index INTEGER,
name UTF8String,
type INTEGER,
oStart BOOLEAN,
oEnd BOOLEAN,
exclusions SET OF INTEGER,
inclusions SET OF INTEGER,
attributes SET OF HTMLElementAttributes OPTIONAL,
contentModel HTMLContentModel
}
HTMLContentModel ::= SEQUENCE OF SEQUENCE {
type INTEGER,
index INTEGER
}
HTMLElementAttributes ::= SEQUENCE {
name UTF8String,
type INTEGER,
modifier INTEGER,
defaultValue UTF8String OPTIONAL,
possibleValues SET OF UTF8String OPTIONAL
}
If we want exclusions and inclusions in HTMLElement to be optional, it
should be something like
HTMLElement ::= SEQUENCE {
index INTEGER,
name UTF8String,
type INTEGER,
oStart BOOLEAN,
oEnd BOOLEAN,
exclusions [0] IMPLICIT SET OF INTEGER OPTIONAL,
inclusions [1] IMPLICIT SET OF INTEGER OPTIONAL,
attributes SET OF HTMLElementAttributes OPTIONAL,
contentModel HTMLContentModel
}
Is this right?
Yes, that is right.
- Stepan.
On 8/23/06, Stepan Mishura wrote:
>
> Hi Miguel,
>
> I've looked thought proposed ASN.1 notation and it looks OK for me. I
have
> only few comments.
> (However I don't know all details of DTD, i.e. I've not checked whether
> your
> notation correctly represents DTD so I'll comment only proposed
> ASN.1notation.)
>
> BTW, I've changed the subject if you don't mind.
>
> Common remark: a component of SEQUENCE(OF), SET(OF) should starts with a
> lower-case letter.
>
> Other comment see below.
>
> On 8/23/06, Miguel Montes wrote:
>
> > Hi:
> > We are working on the html parser, and need to have working DTD. The
> > current
> > implementation of DTD.read(), based on serialization, has some
problems,
> > and
> > I think we should have a well defined binary format. I suggest the
> > following
> > ASN.1 format, and if there is consensus on it, we could contribute the
> > code
> > to read and write it.
> > I would like to hear the opinion of Stepan and anyone who has worked
> with
> > ASN.1 before.
> >
> > BDTD ::= SEQUENCE {
> > Name UTF8String,
> > Entity SET OF HTMLEntity,
> > Element SET OF HTMLElement
> > }
> >
> > HTMLEntity ::= SEQUENCE {
> > Name UTF8String,
> > Value INTEGER,
> > General BOOLEAN DEFAULT FALSE,
> > Parameter BOOLEAN DEFAULT FALSE,
> > Data UTF8String
> > }
>
>
> This won't work. I'll try to explain. We have 2 DEFAULT components here.
> If
> a component is declared as DEFAULT then it is also OPTIONAL and can be
> missed. A decoder can detect which component is missed only if a in
block
> of
> OPTIONAL components plus next mandatory component all elements are
> distinct.
>
> We have the next block:
> general BOOLEANDEFAULT FALSE
> parameterBOOLEANDEFAULT FALSE
> data UTF8String
>
> So 1-st and 2-nd elements are not distinct. This can be fixed by tagging
> some elements. I'd use implicit tagging, for example:
>
> generalBOOLEANDEFAULT FALSE
> parameter[0] IMPLICIT BOOLEANDEFAULT FALSE
>
> or
>
> general [0] IMPLICIT BOOLEANDEFAULT FALSE
> parameter[1] IMPLICIT BOOLEANDEFAULT FALSE
>
> Thanks,
> Stepan.
>
> P.S. I'll let you know if I have more corrections.
>
>
>
>
>
> > HTMLElement ::= SEQUENCE {
> > Index INTEGER,
> > Name UTF8String,
> > Type INTEGER,
> > OStart BOOLEAN,
> > OEnd BOOLEAN,
> > Exclusions SET OF INTEGER,
> > Inclusions SET OF INTEGER,
> > Attributes SET OF HTMLElementAttributes OPTIONAL,
> > ContentModel HTMLContentModel,
> > }
> >
> > HTMLContentModel ::= SEQUENCE OF SEQUENCE {
> > Type INTEGER,
> > Index INTEGER
> > }
> >
> > HTMLElementAttributes ::= SEQUENCE {
> > Name UTF8String,
> > Type INTEGER,
> > Modifier INTEGER,
> > DefaultValue UTF8String OPTIONAL,
> > PossibleValues SET OF UTF8String OPTIONAL
> > }
> > --
> > Miguel Montes
> >
--
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] Error building on Linux
Created: (HARMONY-1266) JarURLConnection does not compile: http://issues.apache.org/jira/browse/HARMONY-1266 -Stepan. On 8/23/06, Paulex Yang wrote: It was me, will recover at once. Seems due to the luni-kernel-stubs.jar and luni-kernel.jar has different generics signatures for some j.l.reference classes. Oliver Deakin wrote: > Hi, > > I get a build error on Linux this morning: > >[javac] > /home/odeakin/svn-checkouts/test/modules/luni/src/main/java/org/apache/harmony/luni/internal/net/www/protocol/jar/JarURLConnection.java:229: > inconvertible types >[javac] found : java.lang.ref.Reference java.util.jar.JarFile> >[javac] required: > org.apache.harmony.luni.internal.net.www.protocol.jar.JarURLConnection.CacheEntry > >[javac] while ((entry = (CacheEntry) cacheQueue.poll()) > != null) >[javac] ^ > > Im not sure, but this may have been caused by the application of the > patch for HARMONY-1254. > > Anyone else seeing it? > > Regards, > Oliver > -- 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] -- Thanks, Stepan Mishura 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][html] Please evaluate proposed ASN.1 notation for HTML DTD
Hi Miguel,
I've looked thought proposed ASN.1 notation and it looks OK for me. I have
only few comments.
(However I don't know all details of DTD, i.e. I've not checked whether your
notation correctly represents DTD so I'll comment only proposed ASN.1notation.)
BTW, I've changed the subject if you don't mind.
Common remark: a component of SEQUENCE(OF), SET(OF) should starts with a
lower-case letter.
Other comment see below.
On 8/23/06, Miguel Montes wrote:
Hi:
We are working on the html parser, and need to have working DTD. The
current
implementation of DTD.read(), based on serialization, has some problems,
and
I think we should have a well defined binary format. I suggest the
following
ASN.1 format, and if there is consensus on it, we could contribute the
code
to read and write it.
I would like to hear the opinion of Stepan and anyone who has worked with
ASN.1 before.
BDTD ::= SEQUENCE {
Name UTF8String,
Entity SET OF HTMLEntity,
Element SET OF HTMLElement
}
HTMLEntity ::= SEQUENCE {
Name UTF8String,
Value INTEGER,
General BOOLEAN DEFAULT FALSE,
Parameter BOOLEAN DEFAULT FALSE,
Data UTF8String
}
This won't work. I'll try to explain. We have 2 DEFAULT components here. If
a component is declared as DEFAULT then it is also OPTIONAL and can be
missed. A decoder can detect which component is missed only if a in block of
OPTIONAL components plus next mandatory component all elements are distinct.
We have the next block:
general BOOLEANDEFAULT FALSE
parameterBOOLEANDEFAULT FALSE
data UTF8String
So 1-st and 2-nd elements are not distinct. This can be fixed by tagging
some elements. I'd use implicit tagging, for example:
generalBOOLEANDEFAULT FALSE
parameter[0] IMPLICIT BOOLEANDEFAULT FALSE
or
general [0] IMPLICIT BOOLEANDEFAULT FALSE
parameter[1] IMPLICIT BOOLEANDEFAULT FALSE
Thanks,
Stepan.
P.S. I'll let you know if I have more corrections.
HTMLElement ::= SEQUENCE {
Index INTEGER,
Name UTF8String,
Type INTEGER,
OStart BOOLEAN,
OEnd BOOLEAN,
Exclusions SET OF INTEGER,
Inclusions SET OF INTEGER,
Attributes SET OF HTMLElementAttributes OPTIONAL,
ContentModel HTMLContentModel,
}
HTMLContentModel ::= SEQUENCE OF SEQUENCE {
Type INTEGER,
Index INTEGER
}
HTMLElementAttributes ::= SEQUENCE {
Name UTF8String,
Type INTEGER,
Modifier INTEGER,
DefaultValue UTF8String OPTIONAL,
PossibleValues SET OF UTF8String OPTIONAL
}
--
Miguel Montes
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
I fixed luni/build.xml at r433956. Please verify. Thanks, Stepan. On 8/23/06, Paulex Yang wrote: I updated the test resource files used for java.io, but I'm not sure this is the cause. I got the same errors sometimes on Windows XP before the update. Looking... Stepan Mishura wrote: > Hi, > > I've just refreshed my local 'luni' module with the latest updates and > found > that 2 tests started to fail for me. Can anybody reproduce failures? > > tests.api.java.net.InetAddressTest > > test_getAddress: Incorrect address returned > junit.framework.AssertionFailedError: Incorrect address returned at > tests.api.java.net.InetAddressTest.test_getAddress(InetAddressTest.java :154) > > at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) > > test_getAllByNameLjava_lang_String: Authoritative Answer Host not found > java.net.UnknownHostException: Authoritative Answer Host not found at > java.net.InetAddress.getAliasesByNameImpl(Native Method) at > java.net.InetAddress.getAllByName(InetAddress.java:21) at > tests.api.java.net.InetAddressTest.test_getAllByNameLjava_lang_String( > InetAddressTest.java:165) at java.lang.reflect.AccessibleObject.invokeV( > AccessibleObject.java:25) > > And the update was: > Dmodules\luni\src\test\java\tests\api\java\io\testfile > Dmodules\luni\src\test\java\tests\api\java\io\testfile-utf8.txt > Dmodules\luni\src\test\java\tests\api\java\io\testfile.txt > Umodules\luni\src\test\java\tests\api\java\util\EnumMapTest.java > Amodules\luni\src\test\resources\tests > Amodules\luni\src\test\resources\tests\api > Amodules\luni\src\test\resources\tests\api\java > Amodules\luni\src\test\resources\tests\api\java\io > Amodules\luni\src\test\resources\tests\api\java\io\testfile > Amodules\luni\src\test\resources\tests\api\java\io\testfile-utf8.txt > Amodules\luni\src\test\resources\tests\api\java\io\testfile.txt > Umodules\luni\src\main\java\java\util\EnumMap.java > Umodules\luni\build.xml > Updated to revision 433917. > -- 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: [continuum] BUILD FAILURE: Classlib/linux.ia32 Build/Test
Hi, I've just refreshed my local 'luni' module with the latest updates and found that 2 tests started to fail for me. Can anybody reproduce failures? tests.api.java.net.InetAddressTest test_getAddress: Incorrect address returned junit.framework.AssertionFailedError: Incorrect address returned at tests.api.java.net.InetAddressTest.test_getAddress(InetAddressTest.java:154) at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:25) test_getAllByNameLjava_lang_String: Authoritative Answer Host not found java.net.UnknownHostException: Authoritative Answer Host not found at java.net.InetAddress.getAliasesByNameImpl(Native Method) at java.net.InetAddress.getAllByName(InetAddress.java:21) at tests.api.java.net.InetAddressTest.test_getAllByNameLjava_lang_String( InetAddressTest.java:165) at java.lang.reflect.AccessibleObject.invokeV( AccessibleObject.java:25) And the update was: Dmodules\luni\src\test\java\tests\api\java\io\testfile Dmodules\luni\src\test\java\tests\api\java\io\testfile-utf8.txt Dmodules\luni\src\test\java\tests\api\java\io\testfile.txt Umodules\luni\src\test\java\tests\api\java\util\EnumMapTest.java Amodules\luni\src\test\resources\tests Amodules\luni\src\test\resources\tests\api Amodules\luni\src\test\resources\tests\api\java Amodules\luni\src\test\resources\tests\api\java\io Amodules\luni\src\test\resources\tests\api\java\io\testfile Amodules\luni\src\test\resources\tests\api\java\io\testfile-utf8.txt Amodules\luni\src\test\resources\tests\api\java\io\testfile.txt Umodules\luni\src\main\java\java\util\EnumMap.java Umodules\luni\build.xml Updated to revision 433917. -- Thanks, Stepan Mishura 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][test]Is this test necessary?
On 8/23/06, Nathan Beyer wrote:
No, I don't think that's necessary at all. The test should just be testing
that the Error itself works, like you said, not that the VM throws one
when
it runs out of memory. There were other tests like this, that I've cleaned
up in the past, like an IndexOutOfBoundsExceptionTest that asserted the
exception was thrown if an array was accessed out of bounds. I thought it
was just a one-off thing, but it seems there are other tests like that,
which should be cleaned up.
My opinion is that tests that assert VM behavior should be packaged with
the
VM, not the class library.
I agree.
Also I saw unit tests related to VM behaviour like:
SomeException ex = new SomeException();
try {
throw ex;
} catch(Exception e) {
assertSame(ex, e);
}
Thanks,
Stepan.
-Nathan
> -Original Message-
> From: Paulex Yang [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 22, 2006 10:39 PM
> To: harmony-dev@incubator.apache.org
> Subject: [classlib][test]Is this test necessary?
>
> The test case
> below(org.apache.harmony.luni.tests.java.lang.OutOfMemoryErrorTest)
> generally needs > 250 seconds on my thinkpad:
>
> public void test_Constructor() {
> // Test for method java.lang.OutOfMemoryError()
> try {
> StringBuffer large[] = new StringBuffer[10];
>
> for (int i = 0; i < large.length; i++)
> large[i] = new StringBuffer(100);
> } catch (OutOfMemoryError e) {
> return;
> }
> fail("No error generated");
> }
>
> IMO it is not a unit test of OutOfMemoryError constructor like its name,
> actually what it tries to test is the JVM memory management
>
> I suggest to remove this testcase, at least it can be written like below
> to get same error thrown much quickly:
>
> StringBuffer large = new StringBuffer(Integer.MAX_VALUE);
>
> --
> 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: [vote] HARMONY-1125 : thread manager patch for DRLVM
+1 -Stepan. On 8/18/06, Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1125 wrt BCC and ACQ. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1105 : Accept Java Management Console
+1 -Stepan. On 8/18/06, Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1105 wrt BCC and ACQ. Please vote to accept or reject this codebase into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
