Re: [classlib][TestNG] groups of Harmony test
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
Vladimir Ivanov wrote:
Also some tag for regression tests should be added.
Yes. Do you think we could annotate regression test as
*level.regression*? Thanks a lot.
Yes, I do. While tests can have more than one group it will enough.
thanks, Vladimir
Richard
thanks, Vladimir
On 8/28/06, Richard Liang [EMAIL PROTECTED] wrote:
Richard Liang wrote:
Hello All,
Now let's talk about the TestNG groups. I have read the related
threads which posted by George, Vladimir Ivanov and Alexei Zakharov.
All of them are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of
our tests should be in this group.
*os.platform id* - group of tests which are designed for one
specific platform. A test may be in more than one of the groups. e.g
.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests
or implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g
.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient
way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for
MacOS,
instead of list 9 os.platform id, we can just use
state.broken.MacOS
3) [Test type] type.api , type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in
complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification
of
the entire system. Maybe we'll put them into a separate project.
e.g., harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name= state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Hello All,
I'm sorry. It seems that the example does not work. I will try to
figure
another example soon. ;-)
Best regards,
Richard
Well, I think our most of existing tests are in the groups of
{os.any, type.api, level.unit}, and I have asked TestNG to add
a
new option -groups for its JUnitConverter which allow us to specify
the test groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments
or suggestion. ;-)
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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.init(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 log file.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]
Re: [classlib][logging] A non bug difference from RI?
On 8/30/06, Stepan Mishura [EMAIL PROTECTED] 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.init(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 log file.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. :)
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]
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib] HARMONY-790 is not reproducible
Mark and Geir thanks a lot. I understand you need time but most of them have pretty simple patches. 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 patches 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]
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:
target name=copy.resources
copy todir=${hy.jdk}/jre/lib overwrite=yes flatten=yes
fileset dir=${hy.logging.src.main.java}
include name=**/logging.properties /
/fileset
/copy
/target
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]strings externalization
Hi, Jimmy!
It's great that you are interested in it!
Unfortunately there is no automatic externalization generation tool that
fits our needs. However, you can combine Eclipse externalization tool with
some manual work to get what is need. You can take a look into the
[classlib]strings externalization thread [1] for details. Main points
briefly:
1. Using Eclipse externalization tool you can extract all strings from the
sources. When you process certain source file strings that used for messages
should be externalized, others should be ignored (as a result, Eclipse mark
them with non-nls tag).
2. Eclipse tool by default suggests you to use keep messages from each class
in the separate messages.properties file, and keys in the properties file
will looks like class_name.id. We've decided to have one messages list
for each module with keys module.id (in your case module == instrument
:)). Thus at first you should change common prefix to module.. Next step
is to configure Accessor class field: choose the proper package for
Messages class and messages.properties file(org.apache.harmony
.module.msgstool).
What is to take care of:
1. Continuation of the numeration of messages. For every new source file you
process Eclipse tool will reset enumeration, and you should manually set the
appropriate number for messages. Also it would be better if you avoid
messages duplication in the list. (Pretty annoying if you have many messages
in the module and some of them are duplicated)
2. Messages formatting. If you have message located on the several source
code lines - you should concatenate them into one message string and use one
Messages.getString(..) call. Also messages with arguments are supposed to be
converted to strings with places for substitution by parameters being
arguments in Messages.getString() method. E.g. code:
int param;
...
NullPointerException(foo + param + bar);
supposed to be formatted as
NullPointerException(Messages.getString(module.1, param));
where module.1=foo {0} bar in the resource bundle.
I hope now the process is clear.
You can find examples of internationalized messages in the [sql] module.
As for messages in native code, actually I dealt only with java code.
You may find something interesting for you from the [drlvm] proposals for
VM internationalization thread [2].
Regards,
Ilya.
[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]
On 8/30/06, Jimmy, Jing Lv [EMAIL PROTECTED] wrote:
Ilya Okomin wrote:
Tim, great news for me.
Everything looks fine with the patch you've applied, now it's time for
the
main part of the task.
I've created HARMONY-1308 issue with task description. This issue is
devided
into a set of sub-issues for each module. I'm going to process them one
by
one. These issues can be processed in a parallel way, so everyone is
welcomed to take part in the internationalization process :)
Hi,
Ilya, I'd like to process instrument :) Can you tell me something
about the generation tool, or how can we process these strings? Is there
anything to take care of?
And in fact, in java.lang.instrument, there are some error messages
in native code(AFAIK, there are also many in luni). Is there any tool to
find them out automatic ?
Thanks,
Ilya.
On 8/29/06, Tim Ellison [EMAIL PROTECTED] wrote:
Thanks for waiting Ilya, I've applied the final patch on HARMONY-1201
(I'll check-in the tool when I get back from vacation). So now we can
get to work on breaking out the messages into each component's message
file.
Regards,
Tim
Ilya Okomin wrote:
On 8/11/06, Tim Ellison [EMAIL PROTECTED] wrote:
I took a look at the HARMONY-1041 tool. It is fine, I have only
minor
comments:
- do you think we need to separate the Message and MsgUtil types?
Given that they are generated from a template I'd be inclined to
combine
them into a single type now. We have no need to look in that file
in
general. If you do choose to combine them then I would expect the
resulting header to be (c) 1998, 2006.
- Minor typo Better make changes in the teamplate file. -
template.
Ilya Okomin wrote:
I would suggest to split this task into a set of jira sub-issues,
one
module - one issue. This kind of division would give us an
opportunity this work to be done in a parallel mode.
Agreed. I suggest that we run the msgtool on the existing modules
and
commit the generated code and catalog files, then the incoming
patches
can assume they are there and use them to fix the externalization.
Hello, Tim!
I've made changes to the generation tool [1] and also prepared patch
with
the set of generated files according to the existing modules set I've
raised
issue for that [2]. Not all modules were included into the generation
(full
set can be found in comments to the [2]). E.g. x-net module
Re: [classlib] HARMONY-790 is not reproducible
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. -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]
Re: [classlib][logging] A non bug difference from RI?
Stepan Mishura wrote:
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.init(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 log file.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, this test show RI's locking mechanism has side-effect(needs more
file permissions), while Harmony's is more clean.
IMO, we should add a note to the documentation: why we chose different
locking approach.
Agree, documentation is useful here. Actually I'm a little confused why
RI chose its current locking approach, IIRC, why the file needs to be
locked is due to the spec[1], and IMO the spec hints the lock of logging
file needs to be detected and held.
[1] However, if the FileHandler tries to open the filename and finds
the file is currently in use by another process it will increment the
unique number field and try again.
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]
--
Paulex Yang
China Software Development Lab
IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To
Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
+1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes 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] - 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, Stepan Mishura [EMAIL PROTECTED] 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:
target name=copy.resources
copy todir=${hy.jdk}/jre/lib overwrite=yes flatten=yes
fileset dir=${hy.logging.src.main.java}
include name=**/logging.properties /
/fileset
/copy
/target
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? :-)
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? 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!).
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.
Thanks!
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]
--
Andrew Zhang
China Software Development Lab, IBM
Re: [classlib][logging] A non bug difference from RI?
On 8/30/06, Stepan Mishura [EMAIL PROTECTED] wrote:
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.init(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 log file.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?
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!
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]
--
Andrew Zhang
China Software Development Lab, IBM
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:
target name=copy.resources
copy todir=${hy.jdk}/jre/lib overwrite=yes
flatten=yes
fileset dir=${hy.logging.src.main.java}
include name=**/logging.properties /
/fileset
/copy
/target
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=some 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?
jvmarg value=-java.util.logging.config.file=Harmony testing properties
file/
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: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
+1 On 8/30/06, Mark Hindess [EMAIL PROTECTED] wrote: +1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] HARMONY-790 is not reproducible
I'd add http://issues.apache.org/jira/browse/HARMONY-650 to the list of unassigned issues with patches. It has a patch for the test also. Could somebody take a look, please? On 8/30/06, Stepan Mishura [EMAIL PROTECTED] wrote: 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] - 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-1225 : Assorted fixes and enhancements for AWT and Swing
On 30 August 2006 at 14:02, Sergey Soldatov [EMAIL PROTECTED] wrote: Actually all these rejects were integrated during Swing text integration and they doesn't matter. Ok, but it would still be more reassuring to have a clean patch. Currently, the only way I'd be confident that the patch has been consistently applied would be to check the rejects by hand. I'm assuming those who create the patch could do this quicker than any of committers. -Mark. On 8/30/06, Mark Hindess [EMAIL PROTECTED] wrote: +1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes 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]
[general] jira issues tracking
Hi, I have just tried to use JIRA to see how many unapplied patches are there for DRLVM, but couldn't search just for the issues with patch provided. Does anyone know of a good way to find just the issues with patches submitted? If there is no good way, probably subtasks feature of JIRA could be used, e.g., create subtask for each patch submitted. Subtasks are then easily searchable. I have also seen that other projects in JIRA use Patch available status, but I do not know how non-committer could change the issue state, so this does not look like a solution. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [tools] Need a volunteer to write documentation for Keytool
Anton, Sorry for a long response. Here is what I've been able to make out of the Keytool help document. At first I thought of generating a diff, but then saw that too much has changed and giving a newer version of the file might have more common sense in it. Key changes in the doc: - 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 when I could. This is not a final version, there are a couple of TBD items in the doc, but I think we're much closer to finalization now. Please take a look at the document and let me know what you think. We can work further to enhance and expand the doc. Best regards, Nadya Morozova -Original Message- From: Anton Rusanov [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 3:16 PM To: harmony-dev@incubator.apache.org Subject: Re: [tools] Need a volunteer to write documentation for Keytool Nadya, great to hear this! :) I will be glad to answer all your questions on Keytool, just let me know if they appear. Thank you. 2006/8/22, Morozova, Nadezhda [EMAIL PROTECTED]: Anton, I might be able to help you write the description. The subject is relatively new to me, so I can't write it on my own. However, you can count on my support and advice in writing and reviewing. I will look at the current description and do a quick review :) Best regards, Nadya Morozova -Original Message- From: Anton Rusanov [mailto:[EMAIL PROTECTED] Sent: Monday, August 21, 2006 3:25 PM To: harmony-dev@incubator.apache.org Subject: [tools] Need a volunteer to write documentation for Keytool We have Keytool utility developed now and a draft of its user's guide can be found at enhanced/classlib/trunk/doc/tools/Keytool/Keytool_help.html. If there is a person with technical writer skills who wants to evolve the draft into real documentation I will be happy to answer all related questions. I would be very thankful if somebody will volunteer to write the documentation. -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][MMTk GC] marksweep configuration works in user mode
The selection of header bits for object hash is controlled by HASH_MASK located in mon_enter_exit.h. By happy coincidence, there was an unused bit in the header. The old version: #define HASH_MASK 0x7e The hacked on version for MMTk: #define HASH_MASK 0xfc A question for those who know the thread manager code. Will the above cause a problem today? Will it cause a problem with what the thread manager wants to do with header bits tomorrow? Now the semispace collector definitely goes further before it falls down. I had a long IM session with Steve Blackburn (MMTk expert) last night to figure out the next debug steps. We realized a few important items but, of course, none of this is recorded in harmony-dev email. I will start a second mmtk thread to record the current state of MMTk debugging. On 8/29/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Weldon Washburn wrote: On 8/29/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Weldon Washburn wrote: All, I just committed mods that allow MMTk marksweep configuration to run the simple tests in test.java. That's cool - what do we do with it next? :) The next step is to get MMTk semispace collector running. I am working on it right now. It turns out MMTk needs the mark bit and the forwarding bit adjacent to each other in the same byte of the object header. This may mean shoving around the bits in DRLVM object header to get the required space. In neither case is it configurable via a mask or something? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
On 30 August 2006 at 12:03, 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:
target name=copy.resources
copy todir=${hy.jdk}/jre/lib overwrite=yes flatten=yes
fileset dir=${hy.logging.src.main.java}
include name=**/logging.properties /
/fileset
/copy
/target
The 'test' target depends on 'build' which in turn depends on the above
'copy.resources' target. So this seems perfectly reasonable to me.
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.
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]
--=_Part_17401_4283173.1156914206767--
-
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-1225 : Assorted fixes and enhancements for AWT and Swing
Mark, I'll clean up the patch from those fixes which were applied during HTML integration, and attach the new one. A quick look shows that Sergey is right, and many Swing fixes have been applied already. Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 4:17 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing On 30 August 2006 at 14:02, Sergey Soldatov [EMAIL PROTECTED] wrote: Actually all these rejects were integrated during Swing text integration and they doesn't matter. Ok, but it would still be more reassuring to have a clean patch. Currently, the only way I'd be confident that the patch has been consistently applied would be to check the rejects by hand. I'm assuming those who create the patch could do this quicker than any of committers. -Mark. On 8/30/06, Mark Hindess [EMAIL PROTECTED] wrote: +1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes 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] - 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-1225 : Assorted fixes and enhancements for AWT and Swing
Thanks! -Mark. On 30 August 2006 at 17:56, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Mark, I'll clean up the patch from those fixes which were applied during HTML integration, and attach the new one. A quick look shows that Sergey is right, and many Swing fixes have been applied already. Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 4:17 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing On 30 August 2006 at 14:02, Sergey Soldatov [EMAIL PROTECTED] wrote: Actually all these rejects were integrated during Swing text integration and they doesn't matter. Ok, but it would still be more reassuring to have a clean patch. Currently, the only way I'd be confident that the patch has been consistently applied would be to check the rejects by hand. I'm assuming those who create the patch could do this quicker than any of committers. -Mark. On 8/30/06, Mark Hindess [EMAIL PROTECTED] wrote: +1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][logging] a test suite shouldn't touch any of JRE config files!!!
Andrew Zhang wrote: Yes, they're different. :-) Static first initialization acts differently from readConfiguration if you take a look at the source code. :) 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. What if the test fails, leaving things in a broken state? 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-1225 : Assorted fixes and enhancements for AWT and Swing
Ok, but the correct way here is probably not a completely new patch, but one that can follow the original patch with fix-ups geir Ivanov, Alexey A wrote: Mark, I'll clean up the patch from those fixes which were applied during HTML integration, and attach the new one. A quick look shows that Sergey is right, and many Swing fixes have been applied already. Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 4:17 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing On 30 August 2006 at 14:02, Sergey Soldatov [EMAIL PROTECTED] wrote: Actually all these rejects were integrated during Swing text integration and they doesn't matter. Ok, but it would still be more reassuring to have a clean patch. Currently, the only way I'd be confident that the patch has been consistently applied would be to check the rejects by hand. I'm assuming those who create the patch could do this quicker than any of committers. -Mark. On 8/30/06, Mark Hindess [EMAIL PROTECTED] wrote: +1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [tools] Need a volunteer to write documentation for Keytool
can you add as a JIRA so we can just integrate into the site? Morozova, Nadezhda wrote: Anton, Sorry for a long response. Here is what I've been able to make out of the Keytool help document. At first I thought of generating a diff, but then saw that too much has changed and giving a newer version of the file might have more common sense in it. Key changes in the doc: - 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 when I could. This is not a final version, there are a couple of TBD items in the doc, but I think we're much closer to finalization now. Please take a look at the document and let me know what you think. We can work further to enhance and expand the doc. Best regards, Nadya Morozova -Original Message- From: Anton Rusanov [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 3:16 PM To: harmony-dev@incubator.apache.org Subject: Re: [tools] Need a volunteer to write documentation for Keytool Nadya, great to hear this! :) I will be glad to answer all your questions on Keytool, just let me know if they appear. Thank you. 2006/8/22, Morozova, Nadezhda [EMAIL PROTECTED]: Anton, I might be able to help you write the description. The subject is relatively new to me, so I can't write it on my own. However, you can count on my support and advice in writing and reviewing. I will look at the current description and do a quick review :) Best regards, Nadya Morozova -Original Message- From: Anton Rusanov [mailto:[EMAIL PROTECTED] Sent: Monday, August 21, 2006 3:25 PM To: harmony-dev@incubator.apache.org Subject: [tools] Need a volunteer to write documentation for Keytool We have Keytool utility developed now and a draft of its user's guide can be found at enhanced/classlib/trunk/doc/tools/Keytool/Keytool_help.html. If there is a person with technical writer skills who wants to evolve the draft into real documentation I will be happy to answer all related questions. I would be very thankful if somebody will volunteer to write the documentation. -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
On 30 August 2006 at 10:54, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, but the correct way here is probably not a completely new patch, but one that can follow the original patch with fix-ups I don't think I understand what you mean. So I'd do: 1) apply the original patch with --force and create lots of .rej files 2) apply a patch to remove the legitimate .rej files? 3) check for any remaining .rej files which would indicate real errors? This sounds crazy to me and usually I'm pretty open about hacking things around. ;-) I was imagining a new patch which would be identical to the old one but with the hunks that would have been rejected in the old one removed. And possibly a new patch which clearly identifies any new changes that are required to create something working/consistent to check in. Regards, Mark. geir Ivanov, Alexey A wrote: Mark, I'll clean up the patch from those fixes which were applied during HTML integration, and attach the new one. A quick look shows that Sergey is right, and many Swing fixes have been applied already. Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 4:17 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing On 30 August 2006 at 14:02, Sergey Soldatov [EMAIL PROTECTED] wrote: Actually all these rejects were integrated during Swing text integration and they doesn't matter. Ok, but it would still be more reassuring to have a clean patch. Currently, the only way I'd be confident that the patch has been consistently applied would be to check the rejects by hand. I'm assuming those who create the patch could do this quicker than any of committers. -Mark. On 8/30/06, Mark Hindess [EMAIL PROTECTED] wrote: +1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
Mark Hindess wrote: On 30 August 2006 at 10:54, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Ok, but the correct way here is probably not a completely new patch, but one that can follow the original patch with fix-ups I don't think I understand what you mean. So I'd do: 1) apply the original patch with --force and create lots of .rej files 2) apply a patch to remove the legitimate .rej files? 3) check for any remaining .rej files which would indicate real errors? This sounds crazy to me and usually I'm pretty open about hacking things around. ;-) I was imagining a new patch which would be identical to the old one but with the hunks that would have been rejected in the old one removed. And possibly a new patch which clearly identifies any new changes that are required to create something working/consistent to check in. That's what I thought you meant, but it isn't what I just voted for... If an individual that knows the original patch sends a patch that produces the same end state following the path you find crazy, I'm fine with it. geir Regards, Mark. geir Ivanov, Alexey A wrote: Mark, I'll clean up the patch from those fixes which were applied during HTML integration, and attach the new one. A quick look shows that Sergey is right, and many Swing fixes have been applied already. Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 4:17 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing On 30 August 2006 at 14:02, Sergey Soldatov [EMAIL PROTECTED] wrote: Actually all these rejects were integrated during Swing text integration and they doesn't matter. Ok, but it would still be more reassuring to have a clean patch. Currently, the only way I'd be confident that the patch has been consistently applied would be to check the rejects by hand. I'm assuming those who create the patch could do this quicker than any of committers. -Mark. On 8/30/06, Mark Hindess [EMAIL PROTECTED] wrote: +1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing
I'm going to be the patcher. If you can assert that when I apply the patch to SVN head that I'll be all right, I'll take your word for it. geir Alexey Petrenko wrote: Most (probably all) of the failures are already applied failures. So additional patch has no sense here. Alexey can just remove already applied chunks to not disturb the patcher... 2006/8/30, Geir Magnusson Jr. [EMAIL PROTECTED]: Ok, but the correct way here is probably not a completely new patch, but one that can follow the original patch with fix-ups geir Ivanov, Alexey A wrote: Mark, I'll clean up the patch from those fixes which were applied during HTML integration, and attach the new one. A quick look shows that Sergey is right, and many Swing fixes have been applied already. Regards, Alexey. -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Mark Hindess [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 4:17 PM To: harmony-dev@incubator.apache.org Subject: Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing On 30 August 2006 at 14:02, Sergey Soldatov [EMAIL PROTECTED] wrote: Actually all these rejects were integrated during Swing text integration and they doesn't matter. Ok, but it would still be more reassuring to have a clean patch. Currently, the only way I'd be confident that the patch has been consistently applied would be to check the rejects by hand. I'm assuming those who create the patch could do this quicker than any of committers. -Mark. On 8/30/06, Mark Hindess [EMAIL PROTECTED] wrote: +1 However, I'd also like to hear the end of the dependency saga. It would also be useful (when the vote is complete) to have an up to date patch. The current patch has lots of rejects due to previously applied hunks, etc. It will be quite difficult to integrate in its current state. Regards, Mark. On 28 August 2006 at 1:50, Geir Magnusson Jr [EMAIL PROTECTED] wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. Please vote to accept or reject this set of patches and fixes 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][luni] signalis interruptus in hysock
Time to take another run at this since I didn't get any responses on
the drlvm thread.
We have the problem that DRLVM uses SIGUSR2 in the thread manager
(not an unreasonable thing to do, I believe) but this results in
knocking threads out of select() in hysock.c (and I'm sure we'll see
it in other places.)
Now, I'm not sure what the right course of action is. We have a
suggested patch from Artem that suggests we just ignore when the
tread is interrupted :
--- modules/luni/src/main/native/port/linux/hysock.c
+++ modules/luni/src/main/native/port/linux/hysock.c
@@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
I_32 rc = 0;
I_32 result = 0;
- result =
+ do
+ {
+result =
select (nfds, readfds == NULL ? NULL : readfds-handle,
writefds == NULL ? NULL : writefds-handle,
exceptfds == NULL ? NULL : exceptfds-handle,
timeout == NULL ? NULL : timeout-time);
+ }
+ while (result == -1 errno == EINTR);
+
if (result == -1)
{
rc = errno;
this works, but I'm bothered by the fact that we're just blindly
ignoring signals like this. I also think that I need to go and do
this everywhere we have a non-restarted interruptable blocking system
call.
Now, I'd like to get this fixed today, as it's high time for another
snapshot of the JRE and HDK, but w/o it, Tomcat runs for 2 seconds at
best :)
So - does anyone have any other bright ideas? Why don't we see this
with J9?Would it be better to do a per-thread signal mask after
asking the thread manager what signal it's using du jour? (Andrey
noted that Sun allows one to change the signals used, apparently to
prevent collision w/ user code vi JNI, I guess...)
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] jira issues tracking
+1 I've tried to use this before too - it would be really useful to also be able to find issues without patches for people looking for something to work on. Regards, Sian On 30/08/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Hi, I have just tried to use JIRA to see how many unapplied patches are there for DRLVM, but couldn't search just for the issues with patch provided. Does anyone know of a good way to find just the issues with patches submitted? If there is no good way, probably subtasks feature of JIRA could be used, e.g., create subtask for each patch submitted. Subtasks are then easily searchable. I have also seen that other projects in JIRA use Patch available status, but I do not know how non-committer could change the issue state, so this does not look like a solution. We could turn this on for non-committers - I see no danger... does anyone? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Sian January IBM Java Technology Centre, UK
Re: [general] jira issues tracking
Salikh Zakirov wrote: I have also seen that other projects in JIRA use Patch available status, Geir Magnusson Jr. replied: We could turn this on for non-committers - I see no danger... does anyone? That would be great! JIRA seems to log all changes to the issues, and important information like comments and attachments is immutable, so the risk of open access is low. However, the Patch available status is not currently used by HARMONY JIRA, so I suspect some further action is needed to add the new issue status. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] [testing] crashes in test execution
Hello, I've tried to run 'ant test' in classlib on a recent build hand-made from SVN and came across several problems. First problem was that a popup window with assertion appeared - it was easy to solve it - see HARMONY-1340 . The second one is more tricky for me. ---details start--- vm version: svn = r438451, (Aug 30 2006), Windows/ia32/msvc 1310, debug build tests are run in the following way: set JAVA_HOME=... ant test -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter in compiling LUNI a debug popup occures: in the method JavaLabelPrepass::ldc (file JavaLabelPrepass.cpp) constantType value is null. This happens because in method DrlVMCompilationInterface::getConstantType (file DrlVMInterface.cpp) drlType returned doesn't fit any of options in switch() and surprisingly falls through assert(0) statements to 'return NULL'. ---details end Does anyone else observe similar behaviour? Or you don't have any problems with tests and I should re-check my configuration? -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] crashes in test execution
Yep, I had some popups while run tests on drlvm. But I do not remember exact message. SY, Alexey 2006/8/30, Anton Luht [EMAIL PROTECTED]: Hello, I've tried to run 'ant test' in classlib on a recent build hand-made from SVN and came across several problems. First problem was that a popup window with assertion appeared - it was easy to solve it - see HARMONY-1340 . The second one is more tricky for me. ---details start--- vm version: svn = r438451, (Aug 30 2006), Windows/ia32/msvc 1310, debug build tests are run in the following way: set JAVA_HOME=... ant test -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter in compiling LUNI a debug popup occures: in the method JavaLabelPrepass::ldc (file JavaLabelPrepass.cpp) constantType value is null. This happens because in method DrlVMCompilationInterface::getConstantType (file DrlVMInterface.cpp) drlType returned doesn't fit any of options in switch() and surprisingly falls through assert(0) statements to 'return NULL'. ---details end Does anyone else observe similar behaviour? Or you don't have any problems with tests and I should re-check my configuration? -- 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] -- Alexey A. Petrenko 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] jira issues tracking
I agree. That's a good idea. 2006/8/30, Salikh Zakirov [EMAIL PROTECTED]: Salikh Zakirov wrote: I have also seen that other projects in JIRA use Patch available status, Geir Magnusson Jr. replied: We could turn this on for non-committers - I see no danger... does anyone? That would be great! JIRA seems to log all changes to the issues, and important information like comments and attachments is immutable, so the risk of open access is low. However, the Patch available status is not currently used by HARMONY JIRA, so I suspect some further action is needed to add the new issue status. - 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. Petrenko 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] signalis interruptus in hysock
On Wednesday 30 August 2006 19:29 Geir Magnusson Jr. wrote: So - does anyone have any other bright ideas? Why don't we see this with J9?Would it be better to do a per-thread signal mask after asking the thread manager what signal it's using du jour? (Andrey noted that Sun allows one to change the signals used, apparently to prevent collision w/ user code vi JNI, I guess...) I could be mistaken but I think pthread_kill which is supposed to signal just a single thread works in a following way - it kills the whole process but allows the signal to just one thread. The blocking calls like select are interrupted anyway since signal is process wide and there is no way to make it interrupt only one thread. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][luni] Bug in our file open()?
Try this for classlib : $ svn update $ ant clean $ ant $ cd modules/luni $ ant test -Dtest.case=tests/api/java/net/DatagramSocketTest I get a java.io.FileNotFoundException when the ant JUNIT task is trying to createFormatter(). I've tried this on Ubuntu 6 w/ DRLVM and J9, and winXP w/ J9. It's related to having an existing directory in build/test_report/ TEST-whatever/.../ directory - when I create that manually, all is well- the .xml file is created, and the test runs. The file is being opened with the correct path and our internal write mode, which then seems to get translated correctly to O_CREATE and O_WRONLY. I *thought* that it should simply create the directories needed, and create the file. Am I mis-remembering something? 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][luni] signalis interruptus in hysock
On Aug 30, 2006, at 8:04 PM, Gregory Shimansky wrote: On Wednesday 30 August 2006 19:29 Geir Magnusson Jr. wrote: So - does anyone have any other bright ideas? Why don't we see this with J9?Would it be better to do a per-thread signal mask after asking the thread manager what signal it's using du jour? (Andrey noted that Sun allows one to change the signals used, apparently to prevent collision w/ user code vi JNI, I guess...) I could be mistaken but I think pthread_kill which is supposed to signal just a single thread works in a following way - it kills the whole process but allows the signal to just one thread. The blocking calls like select are interrupted anyway since signal is process wide and there is no way to make it interrupt only one thread. Right - I was thinking a per-thread signal mask... geir -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A subject on profile instrumenting
Could you please prefix your subject lines with [drlvm] to help people sort through the mail traffic? geir On Aug 30, 2006, at 10:14 PM, zouqiong wrote: Hi, I am reading JET in DRLVM now. And try to add some profile instrument via JET, mainly recording the memory accessing patterns. Anyone who are interested with it can discuss with me. Thanks! -- Best Regards, Qiong,Zou - 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:
target name=copy.resources
copy todir=${hy.jdk}/jre/lib overwrite=yes flatten=yes
fileset dir=${hy.logging.src.main.java}
include name=**/logging.properties /
/fileset
/copy
/target
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]
[drlvm]A subject to profiling instrumenting
Hi, I am reading JET in DRLVM now. And try to add some profile instrument via JET, mainly recording the memory accessing patterns. Anyone who are interested with it can discuss with me. Thanks! -- Best Regards, Qiong,Zou
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:
target name=copy.resources
copy todir=${ hy.jdk}/jre/lib overwrite=yes flatten=yes
fileset dir=${hy.logging.src.main.java}
include name=**/logging.properties /
/fileset
/copy
/target
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: [drlvm]A subject to profiling instrumenting
On the 0x1D6 day of Apache Harmony [EMAIL PROTECTED] wrote: Hi, I am reading JET in DRLVM now. And try to add some profile instrument via JET, mainly recording the memory accessing patterns. Sounds interesting again :) Anyone who are interested with it can discuss with me. Thanks! Recording mem-access patterns is a performance-oriented task, am I right? How do you think, should patterns depend on certain JIT and GC tightly? I suspect they depend heavily on GC, and not-so-much on JIT. Though, I should say that JET uses a very cheap register allocation mechanism, so it should negatively influence on the number of memory accesses, and heavily. If you are more oriented on performance you should be rather using OPT for that. But, yet, I do not mind if you start with a more easy-to-use JET :) Are you trying to implement some known techniques or is your work a subject of ongoing research? What papers can I read on this to be more acquainted with what you are doing? -- Egor Pasko, Intel Managed Runtime 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] [testing] crashes in test execution
2006/8/30, Anton Luht [EMAIL PROTECTED]: Hello, I've tried to run 'ant test' in classlib on a recent build hand-made from SVN and came across several problems. First problem was that a popup window with assertion appeared - it was easy to solve it - see HARMONY-1340 . The second one is more tricky for me. ---details start--- vm version: svn = r438451, (Aug 30 2006), Windows/ia32/msvc 1310, debug build tests are run in the following way: set JAVA_HOME=... ant test -Dbuild.compiler=org.eclipse.jdt.core.JDTCompilerAdapter in compiling LUNI a debug popup occures: in the method JavaLabelPrepass::ldc (file JavaLabelPrepass.cpp) constantType value is null. This happens because in method DrlVMCompilationInterface::getConstantType (file DrlVMInterface.cpp) drlType returned doesn't fit any of options in switch() and surprisingly falls through assert(0) statements to 'return NULL'. ---details end Does anyone else observe similar behaviour? Or you don't have any problems with tests and I should re-check my configuration? Anton, This just means that Jitrino.OPT is not 1.5-ready yet. This is known limitation and hopefully will be fixed soon. -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
