Re: [classlib][awt] Fonts with negative size.
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(, new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = + localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks quite strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543,w=-5.46875
,h=-5.7495117]
Actually, I dont see any sence in negative height and width metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen, you can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to choose only
positive sized fonts. Also I've looked on the GDI LOGFONT structure
description in MSDN and I've seen there again that we deal with absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because the spec does not explicitly
describe the requirement of font size.
I suggest we follow RI.
Best regards,
Richard
Thanks,
Ilya.
--
--
Ilya Okomin
Intel Middleware Products Division
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][logging] In applying the LogManager patch...
On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: ... as suggested by Nikolay, I did run the tests $ cd modules/logging $ ant test and it was endless stacktraces, both before and after I made the modification. How do I know if I broke anything? I'm going to go forward with the patch as I don't see any harm, since Logger.global is supposed to be set via getLogger(global) anyway, so subsequent settings shouldn't harm. I got the same stacktraces, and it said BUILD SUCCESSFUL in the end. ;-) After a quick looking through the test (SocketHandlerTest), I found that some tests try to verify some expected exception, in the mean while the exceptions are delegated to ErrorManager which reports the exception to System.err. Running the test on RI, we will also see some error messages (not stacktraces) I guess you broke nothing ;-) Best regards, Richard geir - 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 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][launcher][drlvm] Running vm inside gdb
I have found a solution to this issue. As before, it helps to setup LD_LIBRARY_PATH before running launcher. If it finds required PATHs it doesn't re-execute itself. Pathes looks like: path[0] = /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/default path[1] = /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/ BTW, I have found a bug in the path checks. Giving only first path will satisfy the condition in the code and will prevent execv(), but VM will fail to run: export #LD_LIBRARY_PATH=/home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/default #./deploy/jre/bin/java Test java/lang/UnsatisfiedLinkError : Failed loading library libhyzlib.so: DSO load failed I'm working on the fix. -- Ivan On 9/23/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Yes, I've seen the same, please keep us informed if you find a solution. On 9/23/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: GNU gdb 6.4 Attaching is ok, but it is not quite convinient to do attaching when running small test, I prefer: gdb --args prog args... but it no longer works for me after switch to new launcher. -- Ivan On 9/23/06, Sunny Chan [EMAIL PROTECTED] wrote: Which version of gdb are you using? Older version of gdb doesn't play along well with nptl or java launcher which spawn another process. Try running your java program first and attach gdb to the process. Ivan Volosyuk wrote: I have problems running drlvm from gdb: (gdb) run Starting program: /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/java Test [Thread debugging using libthread_db enabled] [New Thread -1214326592 (LWP 25698)] [New Thread -1214510160 (LWP 25701)] Cannot find user-level thread for LWP 25698: generic error Does anybody have seen the problem? - 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] getting activeMQ to run
On Sep 23, 2006, at 12:00 AM, Nathan Beyer wrote:
-Original Message-
From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
Sent: Friday, September 22, 2006 7:43 PM
On Saturday 23 September 2006 04:20 Geir Magnusson Jr. wrote:
Hm.
LogManger's initializer does
Logger root = Logger.getLogger();
and Logger has
public final static Logger global = Logger.getLogger(global);
which eventually executes
LogManager man = LogManager.getLogManager();
and around we go.
So why don't we always run aground with this? Why is this the first
time we see this?
I think that only stack trace of NPE can show the real reason of the
problem... If it is NPE (uninitialized field has to be null),
otherwise my
guess could be wrong.
Wouldn't a simple approach to fixing this be create the root logger
with a
custom implementation of Logger instead of using Logger.getLogger
() to
create it. Also, the same thing would be done for the global logger
initialization. This could be done with a package-private
constructor just
for this special purpose. This way the initialization of LogManager
can use
Logger, but the initialization of Logger doesn't use LogManager.
How would the root logger be a Logger?
geir
-Nathan
The workaround for such cases is simple, in methods like
void m () {
f.m2();
}
it is necessary to write
void m () {
if (f == null)
initf();
f.m2();
}
This, in case may cause infinite recursion because in case
initialization
of
field f may still refer to method m in other classes, but it is
easier to
resolve.
--
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: harmony-dev-
[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][launcher][drlvm] Running vm inside gdb
On Sep 23, 2006, at 6:00 AM, Ivan Volosyuk wrote: I have found a solution to this issue. As before, it helps to setup LD_LIBRARY_PATH before running launcher. Lets be clear - it only helped to setup LD_LIBRARY_PATH before for reasons unknown. W/o my recent change, it worked fine on Ubuntu 6 but not on Suse... If it finds required PATHs it doesn't re-execute itself. Pathes looks like: path[0] = /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/default path[1] = /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/ BTW, I have found a bug in the path checks. Giving only first path will satisfy the condition in the code and will prevent execv(), but VM will fail to run: Ha! yes, of course. My bad. Obviously if the needed path is a substring of a path that's already there, it does the wrong thing. Doh :) export #LD_LIBRARY_PATH=/home/ivan/svn/drlvm/trunk/build/deploy/jre/ bin/default #./deploy/jre/bin/java Test java/lang/UnsatisfiedLinkError : Failed loading library libhyzlib.so: DSO load failed I'm working on the fix. Ok. I think it's straightforward - look to see if the full string is there by seeing if *(ptr + strstr() + 1) == either null or separator Back to the issue - this means that we can't debug across the execv()? geir -- Ivan On 9/23/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Yes, I've seen the same, please keep us informed if you find a solution. On 9/23/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: GNU gdb 6.4 Attaching is ok, but it is not quite convinient to do attaching when running small test, I prefer: gdb --args prog args... but it no longer works for me after switch to new launcher. -- Ivan On 9/23/06, Sunny Chan [EMAIL PROTECTED] wrote: Which version of gdb are you using? Older version of gdb doesn't play along well with nptl or java launcher which spawn another process. Try running your java program first and attach gdb to the process. Ivan Volosyuk wrote: I have problems running drlvm from gdb: (gdb) run Starting program: /home/ivan/svn/drlvm/trunk/build/deploy/ jre/bin/java Test [Thread debugging using libthread_db enabled] [New Thread -1214326592 (LWP 25698)] [New Thread -1214510160 (LWP 25701)] Cannot find user-level thread for LWP 25698: generic error Does anybody have seen the problem? - 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: [launcher] Patch is available for harmonyvm.properties parsing
I reattached the patch. Not sure this was the case Ivan talked about - launcher was trying to read() the whole file at once - but anyway now file contents is mmapped for parsing. -- Alexey 2006/9/23, Geir Magnusson Jr. [EMAIL PROTECTED]: Hopefully we'll know when we get the actual patch. geir On Sep 22, 2006, at 1:39 PM, Ivan Volosyuk wrote: When 'stracing' loading of VM I saw quite inefficient way to load a file from disk. Reading one byte at a time by read() call. If I'm not mistaken it was this property file. Is this issue fixed in the JIRA? (Just curious) -- Ivan On 9/22/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Dear comitters, Please find the patch attached to HARMONY-1376 which fixes number of issues with harmonyvm.properties: 1) Robust file parsing with any EOLs; 2) The buffer overflow; 3) Added support for %VM_DIR% tokens, now easy to add any others; 4) Command-line -Xbootclasspath: option now really overrides whole BCP. - 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][launcher][drlvm] Running vm inside gdb
On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 23, 2006, at 6:00 AM, Ivan Volosyuk wrote: I have found a solution to this issue. As before, it helps to setup LD_LIBRARY_PATH before running launcher. Lets be clear - it only helped to setup LD_LIBRARY_PATH before for reasons unknown. W/o my recent change, it worked fine on Ubuntu 6 but not on Suse... It works fine on my gentoo. The only thing. Look at the paths. First one without trailing slash, the second with it. This should be exactly the same after the check is fixed. :) I don't know the reason for that, so I have left this intact. If it finds required PATHs it doesn't re-execute itself. Pathes looks like: path[0] = /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/default path[1] = /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/ BTW, I have found a bug in the path checks. Giving only first path will satisfy the condition in the code and will prevent execv(), but VM will fail to run: Ha! yes, of course. My bad. Obviously if the needed path is a substring of a path that's already there, it does the wrong thing. Doh :) export #LD_LIBRARY_PATH=/home/ivan/svn/drlvm/trunk/build/deploy/jre/ bin/default #./deploy/jre/bin/java Test java/lang/UnsatisfiedLinkError : Failed loading library libhyzlib.so: DSO load failed I'm working on the fix. Ok. I think it's straightforward - look to see if the full string is there by seeing if *(ptr + strstr() + 1) == either null or separator Will not work. We should do this in loop at least. If we found another variant of the path it will fail the check. I have made the correct fix. Look at https://issues.apache.org/jira/browse/HARMONY-1557. Back to the issue - this means that we can't debug across the execv()? We don't. -- Ivan geir -- Ivan On 9/23/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Yes, I've seen the same, please keep us informed if you find a solution. On 9/23/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: GNU gdb 6.4 Attaching is ok, but it is not quite convinient to do attaching when running small test, I prefer: gdb --args prog args... but it no longer works for me after switch to new launcher. -- Ivan On 9/23/06, Sunny Chan [EMAIL PROTECTED] wrote: Which version of gdb are you using? Older version of gdb doesn't play along well with nptl or java launcher which spawn another process. Try running your java program first and attach gdb to the process. Ivan Volosyuk wrote: I have problems running drlvm from gdb: (gdb) run Starting program: /home/ivan/svn/drlvm/trunk/build/deploy/ jre/bin/java Test [Thread debugging using libthread_db enabled] [New Thread -1214326592 (LWP 25698)] [New Thread -1214510160 (LWP 25701)] Cannot find user-level thread for LWP 25698: generic error Does anybody have seen the problem? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [launcher] Patch is available for harmonyvm.properties parsing
You are right. It is different property file: $JRE/lib/boot/bootclasspath.properties (6kbyte) The strace looks like following. Not quite effective. The number of syscalls is greater then all others at the startup of VM. I would like to file a performance JIRA for the issue, but I don't quite understand if it DRLVM specific or classlib? -- Ivan read(3, #, 1) = 1 read(3, , 1) = 1 read(3, C, 1) = 1 read(3, o, 1) = 1 read(3, p, 1) = 1 read(3, y, 1) = 1 read(3, r, 1) = 1 read(3, i, 1) = 1 read(3, g, 1) = 1 read(3, h, 1) = 1 read(3, t, 1) = 1 read(3, , 1) = 1 read(3, 2, 1) = 1 read(3, 0, 1) = 1 read(3, 0, 1) = 1 read(3, 5, 1) = 1 read(3, , 1) = 1 read(3, T, 1) = 1 read(3, h, 1) = 1 read(3, e, 1) = 1 read(3, , 1) = 1 read(3, A, 1) = 1 -- Regards, Ivan On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote: I reattached the patch. Not sure this was the case Ivan talked about - launcher was trying to read() the whole file at once - but anyway now file contents is mmapped for parsing. -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [launcher] Patch is available for harmonyvm.properties parsing
On Sep 23, 2006, at 6:59 AM, Alexey Varlamov wrote: I reattached the patch. Thanks, I saw that. Not sure this was the case Ivan talked about - launcher was trying to read() the whole file at once - but anyway now file contents is mmapped for parsing. Do you have any portability concerns with that solution? -- Alexey 2006/9/23, Geir Magnusson Jr. [EMAIL PROTECTED]: Hopefully we'll know when we get the actual patch. geir On Sep 22, 2006, at 1:39 PM, Ivan Volosyuk wrote: When 'stracing' loading of VM I saw quite inefficient way to load a file from disk. Reading one byte at a time by read() call. If I'm not mistaken it was this property file. Is this issue fixed in the JIRA? (Just curious) -- Ivan On 9/22/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Dear comitters, Please find the patch attached to HARMONY-1376 which fixes number of issues with harmonyvm.properties: 1) Robust file parsing with any EOLs; 2) The buffer overflow; 3) Added support for %VM_DIR% tokens, now easy to add any others; 4) Command-line -Xbootclasspath: option now really overrides whole BCP. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [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][launcher][drlvm] Running vm inside gdb
On Sep 23, 2006, at 7:05 AM, Ivan Volosyuk wrote: On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 23, 2006, at 6:00 AM, Ivan Volosyuk wrote: I have found a solution to this issue. As before, it helps to setup LD_LIBRARY_PATH before running launcher. Lets be clear - it only helped to setup LD_LIBRARY_PATH before for reasons unknown. W/o my recent change, it worked fine on Ubuntu 6 but not on Suse... It works fine on my gentoo. The only thing. Look at the paths. First one without trailing slash, the second with it. This should be exactly the same after the check is fixed. :) I don't know the reason for that, so I have left this intact. Oh, just because it doesn't matter - we could add the trailing slash if we wanted too... If it finds required PATHs it doesn't re-execute itself. Pathes looks like: path[0] = /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/default path[1] = /home/ivan/svn/drlvm/trunk/build/deploy/jre/bin/ BTW, I have found a bug in the path checks. Giving only first path will satisfy the condition in the code and will prevent execv(), but VM will fail to run: Ha! yes, of course. My bad. Obviously if the needed path is a substring of a path that's already there, it does the wrong thing. Doh :) export #LD_LIBRARY_PATH=/home/ivan/svn/drlvm/trunk/build/deploy/ jre/ bin/default #./deploy/jre/bin/java Test java/lang/UnsatisfiedLinkError : Failed loading library libhyzlib.so: DSO load failed I'm working on the fix. Ok. I think it's straightforward - look to see if the full string is there by seeing if *(ptr + strstr() + 1) == either null or separator Will not work. We should do this in loop at least. Yes, that was shorthand for for each match of the dir in the oldpath, see if the next char is a separator or the null at the end. if so, you found a match, otherwise keep going You did effectively the same thing in the patch. If we found another variant of the path it will fail the check. I have made the correct fix. Look at https://issues.apache.org/jira/browse/HARMONY-1557. Back to the issue - this means that we can't debug across the execv ()? We don't. -- Ivan geir -- Ivan On 9/23/06, Nikolay Kuznetsov [EMAIL PROTECTED] wrote: Yes, I've seen the same, please keep us informed if you find a solution. On 9/23/06, Ivan Volosyuk [EMAIL PROTECTED] wrote: GNU gdb 6.4 Attaching is ok, but it is not quite convinient to do attaching when running small test, I prefer: gdb --args prog args... but it no longer works for me after switch to new launcher. -- Ivan On 9/23/06, Sunny Chan [EMAIL PROTECTED] wrote: Which version of gdb are you using? Older version of gdb doesn't play along well with nptl or java launcher which spawn another process. Try running your java program first and attach gdb to the process. Ivan Volosyuk wrote: I have problems running drlvm from gdb: (gdb) run Starting program: /home/ivan/svn/drlvm/trunk/build/deploy/ jre/bin/java Test [Thread debugging using libthread_db enabled] [New Thread -1214326592 (LWP 25698)] [New Thread -1214510160 (LWP 25701)] Cannot find user-level thread for LWP 25698: generic error Does anybody have seen the problem? - 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: [launcher] Patch is available for harmonyvm.properties parsing
Ha! This is apr_file_gets() who does this! So this is DRLVM specific and duplicates classlib's efforts. We should get rid of this. 2006/9/23, Ivan Volosyuk [EMAIL PROTECTED]: You are right. It is different property file: $JRE/lib/boot/bootclasspath.properties (6kbyte) The strace looks like following. Not quite effective. The number of syscalls is greater then all others at the startup of VM. I would like to file a performance JIRA for the issue, but I don't quite understand if it DRLVM specific or classlib? -- Ivan read(3, #, 1) = 1 read(3, , 1) = 1 read(3, C, 1) = 1 read(3, o, 1) = 1 read(3, p, 1) = 1 read(3, y, 1) = 1 read(3, r, 1) = 1 read(3, i, 1) = 1 read(3, g, 1) = 1 read(3, h, 1) = 1 read(3, t, 1) = 1 read(3, , 1) = 1 read(3, 2, 1) = 1 read(3, 0, 1) = 1 read(3, 0, 1) = 1 read(3, 5, 1) = 1 read(3, , 1) = 1 read(3, T, 1) = 1 read(3, h, 1) = 1 read(3, e, 1) = 1 read(3, , 1) = 1 read(3, A, 1) = 1 -- Regards, Ivan On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote: I reattached the patch. Not sure this was the case Ivan talked about - launcher was trying to read() the whole file at once - but anyway now file contents is mmapped for parsing. -- Alexey - 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][launcher][drlvm] Running vm inside gdb
On Sep 23, 2006, at 7:54 AM, Geir Magnusson Jr. wrote: Ok. I think it's straightforward - look to see if the full string is there by seeing if *(ptr + strstr() + 1) == either null or separator Will not work. We should do this in loop at least. Yes, that was shorthand for for each match of the dir in the oldpath, see if the next char is a separator or the null at the end. if so, you found a match, otherwise keep going And on second glance, it was terrible shorthand as I forgot the strlen() :) 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: [launcher] Patch is available for harmonyvm.properties parsing
2006/9/23, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 23, 2006, at 6:59 AM, Alexey Varlamov wrote: I reattached the patch. Thanks, I saw that. Not sure this was the case Ivan talked about - launcher was trying to read() the whole file at once - but anyway now file contents is mmapped for parsing. Do you have any portability concerns with that solution? Not at the moment, at least. Anyway this is isolated in the shared parser and can be fixed trivially. -- Alexey 2006/9/23, Geir Magnusson Jr. [EMAIL PROTECTED]: Hopefully we'll know when we get the actual patch. geir On Sep 22, 2006, at 1:39 PM, Ivan Volosyuk wrote: When 'stracing' loading of VM I saw quite inefficient way to load a file from disk. Reading one byte at a time by read() call. If I'm not mistaken it was this property file. Is this issue fixed in the JIRA? (Just curious) -- Ivan On 9/22/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Dear comitters, Please find the patch attached to HARMONY-1376 which fixes number of issues with harmonyvm.properties: 1) Robust file parsing with any EOLs; 2) The buffer overflow; 3) Added support for %VM_DIR% tokens, now easy to add any others; 4) Command-line -Xbootclasspath: option now really overrides whole BCP. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [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: [launcher] Patch is available for harmonyvm.properties parsing
Please... On Sep 23, 2006, at 7:58 AM, Alexey Varlamov wrote: Ha! This is apr_file_gets() who does this! So this is DRLVM specific and duplicates classlib's efforts. We should get rid of this. 2006/9/23, Ivan Volosyuk [EMAIL PROTECTED]: You are right. It is different property file: $JRE/lib/boot/bootclasspath.properties (6kbyte) The strace looks like following. Not quite effective. The number of syscalls is greater then all others at the startup of VM. I would like to file a performance JIRA for the issue, but I don't quite understand if it DRLVM specific or classlib? -- Ivan read(3, #, 1) = 1 read(3, , 1) = 1 read(3, C, 1) = 1 read(3, o, 1) = 1 read(3, p, 1) = 1 read(3, y, 1) = 1 read(3, r, 1) = 1 read(3, i, 1) = 1 read(3, g, 1) = 1 read(3, h, 1) = 1 read(3, t, 1) = 1 read(3, , 1) = 1 read(3, 2, 1) = 1 read(3, 0, 1) = 1 read(3, 0, 1) = 1 read(3, 5, 1) = 1 read(3, , 1) = 1 read(3, T, 1) = 1 read(3, h, 1) = 1 read(3, e, 1) = 1 read(3, , 1) = 1 read(3, A, 1) = 1 -- Regards, Ivan On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote: I reattached the patch. Not sure this was the case Ivan talked about - launcher was trying to read() the whole file at once - but anyway now file contents is mmapped for parsing. -- Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [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][awt] Fonts with negative size.
Google said this is the bug of RI in progress [1]. However there is no
distinct resolution yet...
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(, new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = + localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks quite strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543,w=-5.46875
,h=-5.7495117]
Actually, I dont see any sence in negative height and width metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen, you can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to choose only
positive sized fonts. Also I've looked on the GDI LOGFONT structure
description in MSDN and I've seen there again that we deal with absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because the spec does not explicitly
describe the requirement of font size.
I suggest we follow RI.
Best regards,
Richard
Thanks,
Ilya.
--
--
Ilya Okomin
Intel Middleware Products Division
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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][awt] Fonts with negative size.
On 9/23/06, Alexey Varlamov [EMAIL PROTECTED] wrote:
Google said this is the bug of RI in progress [1]. However there is no
distinct resolution yet...
It's reported again Java 1.1.8 more than 3 years agao. I don't think
RI will fix this bug.
Richard.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4803825
2006/9/23, Richard Liang [EMAIL PROTECTED]:
On 9/22/06, Ilya Okomin [EMAIL PROTECTED] wrote:
Hi, all!
I was playing with fonts and found that Font with negative size can be
created on RI.
Unfortunately spec keep silence about fonts with negative sizes.
On Harmony if font size is negative then it is set to zero.
test.java---
import java.awt.*;
import java.awt.font.FontRenderContext;
public class NegativeFontTest {
public static void main(String[] args) {
int fontsize=-5;
Font localFont = new Font(Arial, 2, fontsize);
System.out.println(Size = + localFont.getSize2D());
System.out.println(Height = + localFont.getLineMetrics(, new
FontRenderContext(null, false, false)).getHeight());
System.out.println(MaxCharBounds = +
localFont.getMaxCharBounds(new
FontRenderContext(null, false, false)));
}
}
If you run this test case on RI you can see that output looks quite strange:
Size = -5.0
Height = -5.7495117
MaxCharBounds = java.awt.geom.Rectangle2D$Float[x=0.0,y=4.6081543,w=-5.46875
,h=-5.7495117]
Actually, I dont see any sence in negative height and width metrics and
I think it is an RI bug.
If you try to draw text with such font on RI - nothing is happen, you can't
see any text on the component.
I've ran 'xfontsel' tool on Linux and there was suggested to choose only
positive sized fonts. Also I've looked on the GDI LOGFONT structure
description in MSDN and I've seen there again that we deal with absolute
height values.
Any thoughts on this issue, is it RI bug or not?
We cannot say it's a bug of RI, because the spec does not explicitly
describe the requirement of font size.
I suggest we follow RI.
Best regards,
Richard
Thanks,
Ilya.
--
--
Ilya Okomin
Intel Middleware Products Division
--
Richard Liang
China Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
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 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] In applying the LogManager patch...
Can't we muffle it for good? 2006/9/23, Richard Liang [EMAIL PROTECTED]: On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: ... as suggested by Nikolay, I did run the tests $ cd modules/logging $ ant test and it was endless stacktraces, both before and after I made the modification. How do I know if I broke anything? I'm going to go forward with the patch as I don't see any harm, since Logger.global is supposed to be set via getLogger(global) anyway, so subsequent settings shouldn't harm. I got the same stacktraces, and it said BUILD SUCCESSFUL in the end. ;-) After a quick looking through the test (SocketHandlerTest), I found that some tests try to verify some expected exception, in the mean while the exceptions are delegated to ErrorManager which reports the exception to System.err. Running the test on RI, we will also see some error messages (not stacktraces) I guess you broke nothing ;-) Best regards, Richard geir - 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 Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][logging] In applying the LogManager patch...
+1 On Sep 23, 2006, at 8:50 AM, Alexey Varlamov wrote: Can't we muffle it for good? 2006/9/23, Richard Liang [EMAIL PROTECTED]: On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: ... as suggested by Nikolay, I did run the tests $ cd modules/logging $ ant test and it was endless stacktraces, both before and after I made the modification. How do I know if I broke anything? I'm going to go forward with the patch as I don't see any harm, since Logger.global is supposed to be set via getLogger(global) anyway, so subsequent settings shouldn't harm. I got the same stacktraces, and it said BUILD SUCCESSFUL in the end. ;-) After a quick looking through the test (SocketHandlerTest), I found that some tests try to verify some expected exception, in the mean while the exceptions are delegated to ErrorManager which reports the exception to System.err. Running the test on RI, we will also see some error messages (not stacktraces) I guess you broke nothing ;-) Best regards, Richard geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Richard Liang China Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Cleaning insides of Class.h header
Created Harmony-1558 [1] with the intention to attach all patches to it. Step 1 patch attached - interested parties can review. Regards, Pavel. [1] https://issues.apache.org/jira/browse/HARMONY-1558 On 7/24/06, Pavel Pervov [EMAIL PROTECTED] wrote: Hello, all. I would like to work on cleaning the insides of Class.h header file. This header is related to internal representation of java class inside the VM. Currently it contains all entities for internal class representation: class itself, constant pool, members (field, method), exceptions handler, vtable and so forth. First thing I would like to do is to split the file into a group of files, each of which would contain only one entity (and some closely related entities, if any). This would produce the following headers: 1) Class.h – constant pool and class 2) vtable.h – vtable 3) class_member.h – field and method entities descriptors, exception handler descriptor 4) cci.h – code chunk entity (part of compiled method code) Second thing to do is to throw away members (and other stuff), which are not used anymore and the only reason they are still there is history or they do not belong to these files. Third thing to do is to make all these entities C++ objects. Currently, member variables of all listed entities are used arbitrarily throughout DRLVM code. I would like to regularize usage and, also, document internals of these entities. Certainly, I'll do all these changes step-by-step with little patches coming in. Regards, Pavel Pervov Intel Middleware Products Division.
Re: [jira] Closed: (HARMONY-1545) [drlvm] [jvmti] Unified JVMTI breakpoints infrastructure implementation
Geir, Looks like you've missed adding file enhanced/drlvm/trunk/vm/vmcore/include/jvmti_break_intf.h to SVN tree. Regards, Pavel. On 9/23/06, Geir Magnusson Jr (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1545?page=all ] Geir Magnusson Jr closed HARMONY-1545. -- [drlvm] [jvmti] Unified JVMTI breakpoints infrastructure implementation --- Key: HARMONY-1545 URL: http://issues.apache.org/jira/browse/HARMONY-1545 Project: Harmony Issue Type: Improvement Components: DRLVM Reporter: Ilya Berezhniuk Assigned To: Geir Magnusson Jr Attachments: JVMTI-breakpoints-unified-infrastructure.patch Hello I've reworked the implementation of JVMTI breakpoints and single step. The code which sends breakpoint and single step events currently is ugly and uses unobvious logic. In the new implementation the infrastructure is much more clean and clear :) Main class is VMBreakPoints. It is the container for all breakpoint instrumentation and handler for all breakpoint events. A VMBreakInterface is a class for breakpoints references container. It can be used for any purpose, be it SingleStep or user breakpoints container. In VMBreakInterface breakpoints instrumentations are referenced by VMBreakPointRef. VMBreakPoints has handlers for native (JIT mode) and interpreter mode breakpoints. When such handler is called, the processing goes through all registered VMBreakInterface instances according to their priorities (currently two priorities are supported - SingleStep is first according to JVMTI spec about colocated events) and calls VMBreakInterface handling callback which can send an event of type which this interface supports. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Closed: (HARMONY-1545) [drlvm] [jvmti] Unified JVMTI breakpoints infrastructure implementation
oh, you're right - thanks Done On Sep 23, 2006, at 10:46 AM, Pavel Pervov wrote: Geir, Looks like you've missed adding file enhanced/drlvm/trunk/vm/vmcore/include/jvmti_break_intf.h to SVN tree. Regards, Pavel. On 9/23/06, Geir Magnusson Jr (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-1545?page=all ] Geir Magnusson Jr closed HARMONY-1545. -- [drlvm] [jvmti] Unified JVMTI breakpoints infrastructure implementation - -- Key: HARMONY-1545 URL: http://issues.apache.org/jira/browse/ HARMONY-1545 Project: Harmony Issue Type: Improvement Components: DRLVM Reporter: Ilya Berezhniuk Assigned To: Geir Magnusson Jr Attachments: JVMTI-breakpoints-unified-infrastructure.patch Hello I've reworked the implementation of JVMTI breakpoints and single step. The code which sends breakpoint and single step events currently is ugly and uses unobvious logic. In the new implementation the infrastructure is much more clean and clear :) Main class is VMBreakPoints. It is the container for all breakpoint instrumentation and handler for all breakpoint events. A VMBreakInterface is a class for breakpoints references container. It can be used for any purpose, be it SingleStep or user breakpoints container. In VMBreakInterface breakpoints instrumentations are referenced by VMBreakPointRef. VMBreakPoints has handlers for native (JIT mode) and interpreter mode breakpoints. When such handler is called, the processing goes through all registered VMBreakInterface instances according to their priorities (currently two priorities are supported - SingleStep is first according to JVMTI spec about colocated events) and calls VMBreakInterface handling callback which can send an event of type which this interface supports. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/ software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] my latest round of patches broke something
This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [drlvm] getting activeMQ to run
Now I'm seeing it :) On Sep 22, 2006, at 5:29 PM, Nikolay Kuznetsov wrote: Ok then, it was suse 9, ia32. On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: what platform? I'm not seeing that... On Sep 22, 2006, at 4:01 PM, Nikolay Kuznetsov wrote: core dumps in debug and prints something like this in release: WARN DefaultJDBCAdapter - Could not create JDBC tables; they could already exist. Failure was: That might be simply because you created the tables needed when you ran the first time? I don't know for sure, but J9 works fine w/o any warnings: INFO JDBCPersistenceAdapter - Database driver recognized: [apache_derby_embedded_jdbc_driver] INFO JournalPersistenceAdapter - Journal Recovery Started from: Active Journal: using 5 x 20.0 Megs at: /nfs/pb/home/nakuznet/disk_j/workspace/harmony.orig/incubator- activemq-4.0.1/activemq-data/journal ... ... and the fact that debug version core dumps, also looks suspicious :) Nik. , but finally starts: INFO BrokerService - ActiveMQ JMS Message Broker (localhost, ID:pbtmrte007-57413-1158949586838-1:0) started Will continue investigate. So this look ok... My tests w/ the patch show it running, and I was able to run producer/ consumer tests geir Nik. On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: First, thanks so much for the fast response and good solution. I don't see any problem with this patch, but you're right - I don't understand why we have it, since Logger should set it's global field to getLogger(global) in the static initialization. I have the same problem with J9, so I don't think it's a VM problem. If no one complains, I'm going to test it, apply it, and add a JIRA to look at the fact that global isn't set...or tell me why it shouldn't be geir On Sep 22, 2006, at 1:51 PM, Nikolay Kuznetsov wrote: Hello, I was able to run ActiveQM on Linux with patch attached. Looks like something is broken in logger static initialization sequence. Though this patch helpps in running ActiveQM, I would treat this patch as workaround, this issue requires some more analysis and testing. Nik. On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 22, 2006, at 12:47 AM, Vladimir Gorr wrote: On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 22, 2006, at 12:37 AM, Vladimir Gorr wrote: On 9/22/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Even though we have the jar issue fixed w/t he launcher- based build, I still can't run ActiveMQ using release build on Ubuntu. Can anyone else report success? Or a patch? :) I was succesfull on Windows. No success exist for Linux however. What do you see on linux? ACTIVEMQ_HOME: /nfs/ins/proj/drl/coreapi/vgorr/Tools/ incubator- activemq-4.0 Loading message broker from: xbean:activemq.xml ERROR: java.lang.RuntimeException: Failed to execute start task. Reason: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.activemq.store.PersistenceAdapterFactoryBean' defined in class path resource [activemq.xml]: Instantiation of bean failed; ... Yah, that's what I get. We really need to get this kind of thing worked out, and fast... geir snipped ... Steps I do are the following: 1. unset JAVA_HOME 2. set PATH=.../jre/bin;PATH 3. cd .../activemq-3.2.3\bin; activemq Are these steps correct? Close enough. I set JAVA_HOME to the harmony jre directory (deploy/ jre), added bin to the path, and then sh bin/activemq But I'm using activeMQ 4.0.something Yes, it seems this version doesn't work correctly. At least on Linux. I'll try this on Windows as well. Thanks, Vladimir. Thanks, Vladimir. geir - Terms of use : http://incubator.apache.org/harmony/ mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/ mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/ mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev-
RE: [drlvm] getting activeMQ to run
The global logger and root logger would just be constructed using new
Logger() and then LogManager would set the parent relationship in it static
initialization. I'm playing around with it a bit now.
Also, it seems that the application of a patch to create revision 436703
seems to have broken another application, in this case Tomcat. The public
readConfiguration method was replaced with a call to readConfigurationImpl,
which means the LogManager override mechanism won't work correctly. I'm
fixing that on.
-Nathan
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 23, 2006 5:48 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] getting activeMQ to run
On Sep 23, 2006, at 12:00 AM, Nathan Beyer wrote:
-Original Message-
From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
Sent: Friday, September 22, 2006 7:43 PM
On Saturday 23 September 2006 04:20 Geir Magnusson Jr. wrote:
Hm.
LogManger's initializer does
Logger root = Logger.getLogger();
and Logger has
public final static Logger global = Logger.getLogger(global);
which eventually executes
LogManager man = LogManager.getLogManager();
and around we go.
So why don't we always run aground with this? Why is this the first
time we see this?
I think that only stack trace of NPE can show the real reason of the
problem... If it is NPE (uninitialized field has to be null),
otherwise my
guess could be wrong.
Wouldn't a simple approach to fixing this be create the root logger
with a
custom implementation of Logger instead of using Logger.getLogger
() to
create it. Also, the same thing would be done for the global logger
initialization. This could be done with a package-private
constructor just
for this special purpose. This way the initialization of LogManager
can use
Logger, but the initialization of Logger doesn't use LogManager.
How would the root logger be a Logger?
geir
-Nathan
The workaround for such cases is simple, in methods like
void m () {
f.m2();
}
it is necessary to write
void m () {
if (f == null)
initf();
f.m2();
}
This, in case may cause infinite recursion because in case
initialization
of
field f may still refer to method m in other classes, but it is
easier to
resolve.
--
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: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] my latest round of patches broke something
Ok, I'm not as worried - I went back a few days to r447025 and still have the problem, so it's not from this morning. I guess this has been masked all along by the logger problem. Noted in JIRA HARMONY-1560 geir On Sep 23, 2006, at 11:04 AM, Geir Magnusson Jr. wrote: This is completely my fault. The latest round of patches, while I dutifully do smoke, c-unit and kernel tests for each patch, I didn't do any app testing. I tried to run ActiveMQ, and it breaks with an asset in object_handles.cpp : 99 I'm going to back out the two GC patches I applied and hope for the best. 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: [drlvm] getting activeMQ to run
On Sep 23, 2006, at 1:24 PM, Nathan Beyer wrote:
The global logger and root logger would just be constructed using new
Logger() and then LogManager would set the parent relationship in
it static
initialization. I'm playing around with it a bit now.
Sorry for being dense, but how is that different from what we have now?
Also, it seems that the application of a patch to create revision
436703
seems to have broken another application, in this case Tomcat. The
public
readConfiguration method was replaced with a call to
readConfigurationImpl,
which means the LogManager override mechanism won't work correctly.
I'm
fixing that on.
-Nathan
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 23, 2006 5:48 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] getting activeMQ to run
On Sep 23, 2006, at 12:00 AM, Nathan Beyer wrote:
-Original Message-
From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
Sent: Friday, September 22, 2006 7:43 PM
On Saturday 23 September 2006 04:20 Geir Magnusson Jr. wrote:
Hm.
LogManger's initializer does
Logger root = Logger.getLogger();
and Logger has
public final static Logger global = Logger.getLogger(global);
which eventually executes
LogManager man = LogManager.getLogManager();
and around we go.
So why don't we always run aground with this? Why is this the
first
time we see this?
I think that only stack trace of NPE can show the real reason of
the
problem... If it is NPE (uninitialized field has to be null),
otherwise my
guess could be wrong.
Wouldn't a simple approach to fixing this be create the root logger
with a
custom implementation of Logger instead of using Logger.getLogger
() to
create it. Also, the same thing would be done for the global logger
initialization. This could be done with a package-private
constructor just
for this special purpose. This way the initialization of LogManager
can use
Logger, but the initialization of Logger doesn't use LogManager.
How would the root logger be a Logger?
geir
-Nathan
The workaround for such cases is simple, in methods like
void m () {
f.m2();
}
it is necessary to write
void m () {
if (f == null)
initf();
f.m2();
}
This, in case may cause infinite recursion because in case
initialization
of
field f may still refer to method m in other classes, but it is
easier to
resolve.
--
Gregory Shimansky, Intel Middleware Products Division
---
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [drlvm] getting activeMQ to run
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
On Sep 23, 2006, at 1:24 PM, Nathan Beyer wrote:
The global logger and root logger would just be constructed using new
Logger() and then LogManager would set the parent relationship in
it static
initialization. I'm playing around with it a bit now.
Sorry for being dense, but how is that different from what we have now?
It eliminates the circular execution between the static initializers and
makes the code more simple and straightforward by having only one path for
initialization, instead of two paths that execute based which class is
loaded first. I have the code done and all of the tests passing. I'll check
it in and if it's disliked, we can roll it back.
-Nathan
Also, it seems that the application of a patch to create revision
436703
seems to have broken another application, in this case Tomcat. The
public
readConfiguration method was replaced with a call to
readConfigurationImpl,
which means the LogManager override mechanism won't work correctly.
I'm
fixing that on.
-Nathan
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 23, 2006 5:48 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] getting activeMQ to run
On Sep 23, 2006, at 12:00 AM, Nathan Beyer wrote:
-Original Message-
From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
Sent: Friday, September 22, 2006 7:43 PM
On Saturday 23 September 2006 04:20 Geir Magnusson Jr. wrote:
Hm.
LogManger's initializer does
Logger root = Logger.getLogger();
and Logger has
public final static Logger global = Logger.getLogger(global);
which eventually executes
LogManager man = LogManager.getLogManager();
and around we go.
So why don't we always run aground with this? Why is this the
first
time we see this?
I think that only stack trace of NPE can show the real reason of
the
problem... If it is NPE (uninitialized field has to be null),
otherwise my
guess could be wrong.
Wouldn't a simple approach to fixing this be create the root logger
with a
custom implementation of Logger instead of using Logger.getLogger
() to
create it. Also, the same thing would be done for the global logger
initialization. This could be done with a package-private
constructor just
for this special purpose. This way the initialization of LogManager
can use
Logger, but the initialization of Logger doesn't use LogManager.
How would the root logger be a Logger?
geir
-Nathan
The workaround for such cases is simple, in methods like
void m () {
f.m2();
}
it is necessary to write
void m () {
if (f == null)
initf();
f.m2();
}
This, in case may cause infinite recursion because in case
initialization
of
field f may still refer to method m in other classes, but it is
easier to
resolve.
--
Gregory Shimansky, Intel Middleware Products Division
---
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] getting activeMQ to run
I just gave it a quick look. Given that you've taken the creation of
Loggers away from Logger via it's factory, and now moved it into
LogManager, how can we be sure we never have more than one root logger?
geir
On Sep 23, 2006, at 2:18 PM, Nathan Beyer wrote:
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
On Sep 23, 2006, at 1:24 PM, Nathan Beyer wrote:
The global logger and root logger would just be constructed using
new
Logger() and then LogManager would set the parent relationship in
it static
initialization. I'm playing around with it a bit now.
Sorry for being dense, but how is that different from what we have
now?
It eliminates the circular execution between the static
initializers and
makes the code more simple and straightforward by having only one
path for
initialization, instead of two paths that execute based which class is
loaded first. I have the code done and all of the tests passing.
I'll check
it in and if it's disliked, we can roll it back.
-Nathan
Also, it seems that the application of a patch to create revision
436703
seems to have broken another application, in this case Tomcat. The
public
readConfiguration method was replaced with a call to
readConfigurationImpl,
which means the LogManager override mechanism won't work correctly.
I'm
fixing that on.
-Nathan
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 23, 2006 5:48 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] getting activeMQ to run
On Sep 23, 2006, at 12:00 AM, Nathan Beyer wrote:
-Original Message-
From: Gregory Shimansky [mailto:[EMAIL PROTECTED]
Sent: Friday, September 22, 2006 7:43 PM
On Saturday 23 September 2006 04:20 Geir Magnusson Jr. wrote:
Hm.
LogManger's initializer does
Logger root = Logger.getLogger();
and Logger has
public final static Logger global = Logger.getLogger
(global);
which eventually executes
LogManager man = LogManager.getLogManager();
and around we go.
So why don't we always run aground with this? Why is this the
first
time we see this?
I think that only stack trace of NPE can show the real reason of
the
problem... If it is NPE (uninitialized field has to be null),
otherwise my
guess could be wrong.
Wouldn't a simple approach to fixing this be create the root
logger
with a
custom implementation of Logger instead of using Logger.getLogger
() to
create it. Also, the same thing would be done for the global
logger
initialization. This could be done with a package-private
constructor just
for this special purpose. This way the initialization of
LogManager
can use
Logger, but the initialization of Logger doesn't use LogManager.
How would the root logger be a Logger?
geir
-Nathan
The workaround for such cases is simple, in methods like
void m () {
f.m2();
}
it is necessary to write
void m () {
if (f == null)
initf();
f.m2();
}
This, in case may cause infinite recursion because in case
initialization
of
field f may still refer to method m in other classes, but it is
easier to
resolve.
--
Gregory Shimansky, Intel Middleware Products Division
-
--
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
--
--
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
---
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-
[EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [drlvm] getting activeMQ to run
This may be considered a bug, maybe not, but if you write a simple program
that only references the Logger.global field, nothing will be logged out on
Sun's RI 5.0_8 implementation. However, if you lookup the global logger
(Logger.getLogger(global)), then data will be logged out.
Here's the test - run this and nothing will be written:
public class GlobalLogger {
public static void main(String[] args) {
Logger global = Logger.global;
global.severe(hello);
}
}
Now, if you run this, the a message will be written to the console:
public class GlobalLogger {
public static void main(String[] args) {
Logger global = Logger.getLogger(global);
global.severe(hello);
}
}
And if you extend it a bit farther with this example, the first message
isn't logged, but the second two are.
public class GlobalLogger {
public static void main(String[] args) {
Logger global = Logger.global;
global.severe(hello);
global = Logger.getLogger(global);
global.severe(hello again);
global = Logger.global;
global.severe(and again);
}
}
Then add another variation by looking up an arbitrary logger (to spark the
LogManager up); here the output is the same as before
public class GlobalLogger {
public static void main(String[] args) {
Logger global = Logger.global;
global.severe(hello);
global = Logger.getLogger(not_global);
global.severe(hello again);
global = Logger.global;
global.severe(and again);
}
}
The last variation then is to use the LogManager instead Logger to get the
global logger; again, the output is the same (only the last two messages are
printed).
public class GlobalLogger {
public static void main(String[] args) {
Logger global = Logger.global;
global.severe(hello);
global = LogManager.getLogManager().getLogger(global);
global.severe(hello again);
global = Logger.global;
global.severe(and again);
}
}
This tells me that the global logger is instantiated, but not initialized
with the LogManager's configuration until something calls the LogManager to
start off initialization.
The javadoc alludes to this behavior [1] by stating The global logger is
initialized by calling Logger.getLogger(global).. It seems that the
guarantee here may just be that the field is available, but it won't be
guaranteed to actually do anything until LogManager is initialized.
An additional test proves how uninitialized the global field is; this test
shows that the global field's parent logger is null (it should be root()),
but after LogManager is loaded, the parent logger is set and it is the root
logger.
public class GlobalLogger {
public static void main(String[] args) {
Logger global = Logger.global;
global.severe(hello);
System.err.println(global.getParent());
global = LogManager.getLogManager().getLogger(global);
global.severe(hello again);
System.err.println(global.getParent());
global = Logger.global;
global.severe(and again);
System.err.println(global.getParent());
}
}
The point of this whole story; regardless of what we do with the root
logger, I think our initialization of the Logger.global was incorrect, or at
least not consistent with the RI. Note, with my change it is now consistent.
-Nathan
[1] file:///C:/install/jdk/5.0/docs/api/java/util/logging/Logger.html#global
-Original Message-
From: Nathan Beyer [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 23, 2006 2:38 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [drlvm] getting activeMQ to run
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
I just gave it a quick look. Given that you've taken the creation of
Loggers away from Logger via it's factory, and now moved it into
LogManager, how can we be sure we never have more than one root logger?
Keep in mind the Logger class is NOT the managing authority of Logger
instances; this really belongs to LogManager. Logger just provides a
helper
method for the prescribed algorithm of LogManager.getLogger() if null
LogManager.addLogger(new Logger()), return logger.
Anyway, the LogManager is guaranteed never to maintain more than one
instance of the root () logger because once the logger is constructed in
LogManager static initializer, it's added to the pool of known loggers.
Any
subsequent calls to LogManager.addLogger() will then fail.
-Nathan
geir
On Sep 23, 2006, at 2:18 PM, Nathan Beyer wrote:
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
On Sep 23, 2006, at 1:24 PM, Nathan Beyer wrote:
The global logger and root logger would just be constructed using
new
Logger() and then LogManager would set the parent relationship in
it
Can't unsubscribe...
Help... I need to move my mailing list subscriptions from this email address to another. I emailed the unsubscribe address shown at the footer of every message, but so far it doesn seem to have worked. Any ideas/suggestions? (please refrain from saying throw your computer off a cliff ;-). Is this a join if you wish, leave if you can kind of mailing list?. ;-) FC
[drlvm] invoking non-trivial jars results in IllegalAccessError
So the simple-minded JarRunner that I added to DRLVM works for simple things, but I'm seeing the method.invoke() toss a InvocationTargetException wrapping a IllegalAccessError for Geronimo and Eclipse. I'm sure it's obvious to someone here, but it's not to me. I'm going to keep trying to figure it out, as I'm going to learn something, but if anyone knows the answer, please, just shout it out. The way that DRLVM works now w/ a jar is that it simplemindedly runs o.a.h.vm.JarRunner, which expects the jar name as the first element in the String[] passed to main(). it opens the jar, finds the main class name from the manifest, gets that Method, and then invokes it. For simple test jars, it works fine. For Eclipse, for example, I get java.lang.IllegalAccessError: from org/eclipse/core/launcher/Main to org/eclipse/core/launcher/Main$Identifier at org.eclipse.core.launcher.Main.basicRun(Main.java:265) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.harmony.vm.JarRunner.main(Unknown Source) I'm sure it's something obvious I'm overlooking. Thanks for any help. 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: [drlvm] getting activeMQ to run
On Sep 23, 2006, at 3:58 PM, Nathan Beyer wrote: [1] file:///C:/install/jdk/5.0/docs/api/java/util/logging/ Logger.html#global /me tries to mount a c-drive on my mac... :) 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: Can't unsubscribe...
which address do you want to unsub? geir On Sep 23, 2006, at 4:43 PM, Fernando Cassia wrote: Help... I need to move my mailing list subscriptions from this email address to another. I emailed the unsubscribe address shown at the footer of every message, but so far it doesn seem to have worked. Any ideas/suggestions? (please refrain from saying throw your computer off a cliff ;-). Is this a join if you wish, leave if you can kind of mailing list?. ;-) FC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can't unsubscribe...
this one... [EMAIL PROTECTED] I find myself erasing messages all the time... (my 2.5gb space is at 99%).. and the ones to blame for that are the two dozen mailing lists I've subscribed to... :-) Thanks FC On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: which address do you want to unsub? geir On Sep 23, 2006, at 4:43 PM, Fernando Cassia wrote: Help... I need to move my mailing list subscriptions from this email address to another. I emailed the unsubscribe address shown at the footer of every message, but so far it doesn seem to have worked. Any ideas/suggestions? (please refrain from saying throw your computer off a cliff ;-). Is this a join if you wish, leave if you can kind of mailing list?. ;-) FC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- When I do good, I feel good; when I do bad, I feel bad. That's my religion. - Abraham Lincoln. I do not believe in the immortality of the individual, and I consider ethics to be an important but exclusively human concern, without any supernatural authority behind it. - Albert Einstein.
Re: Can't unsubscribe...
Done geir On Sep 23, 2006, at 4:52 PM, Fernando Cassia wrote: this one... [EMAIL PROTECTED] I find myself erasing messages all the time... (my 2.5gb space is at 99%).. and the ones to blame for that are the two dozen mailing lists I've subscribed to... :-) Thanks FC On 9/23/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: which address do you want to unsub? geir On Sep 23, 2006, at 4:43 PM, Fernando Cassia wrote: Help... I need to move my mailing list subscriptions from this email address to another. I emailed the unsubscribe address shown at the footer of every message, but so far it doesn seem to have worked. Any ideas/suggestions? (please refrain from saying throw your computer off a cliff ;-). Is this a join if you wish, leave if you can kind of mailing list?. ;-) FC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- When I do good, I feel good; when I do bad, I feel bad. That's my religion. - Abraham Lincoln. I do not believe in the immortality of the individual, and I consider ethics to be an important but exclusively human concern, without any supernatural authority behind it. - Albert Einstein. - 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] getting activeMQ to run
In case you're still struggling - http://java.sun.com/j2se/1.5.0/docs/api/java/util/logging/Logger.html#global -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Saturday, September 23, 2006 3:48 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] getting activeMQ to run On Sep 23, 2006, at 3:58 PM, Nathan Beyer wrote: [1] file:///C:/install/jdk/5.0/docs/api/java/util/logging/ Logger.html#global /me tries to mount a c-drive on my mac... :) 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: [drlvm] getting activeMQ to run
Getting back to original topic. I have managed to get following message on activemq-4.0.2 in release build of drlvm: ica-50215-1159047303002-1:0) started Is that it? What is the exact scenario to try with activemq? -- Ivan On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 23, 2006, at 3:58 PM, Nathan Beyer wrote: [1] file:///C:/install/jdk/5.0/docs/api/java/util/logging/ Logger.html#global /me tries to mount a c-drive on my mac... :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ivan 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: [drlvm] getting activeMQ to run
On Sep 23, 2006, at 5:39 PM, Ivan Volosyuk wrote: Getting back to original topic. I have managed to get following message on activemq-4.0.2 in release build of drlvm: ica-50215-1159047303002-1:0) started Is that it? What is the exact scenario to try with activemq? release runs - I as able to do some pub/sub tests yesterday (even with our sub-standard patch to Logger... :) The problem is in debug build... geir -- Ivan On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 23, 2006, at 3:58 PM, Nathan Beyer wrote: [1] file:///C:/install/jdk/5.0/docs/api/java/util/logging/ Logger.html#global /me tries to mount a c-drive on my mac... :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Ivan 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
From Ivan's hints in HARMONY-1561 I created a simple example that illustrates the bug. Attached to the JIRA. geir On Sep 23, 2006, at 4:46 PM, Geir Magnusson Jr. wrote: So the simple-minded JarRunner that I added to DRLVM works for simple things, but I'm seeing the method.invoke() toss a InvocationTargetException wrapping a IllegalAccessError for Geronimo and Eclipse. I'm sure it's obvious to someone here, but it's not to me. I'm going to keep trying to figure it out, as I'm going to learn something, but if anyone knows the answer, please, just shout it out. The way that DRLVM works now w/ a jar is that it simplemindedly runs o.a.h.vm.JarRunner, which expects the jar name as the first element in the String[] passed to main(). it opens the jar, finds the main class name from the manifest, gets that Method, and then invokes it. For simple test jars, it works fine. For Eclipse, for example, I get java.lang.IllegalAccessError: from org/eclipse/core/launcher/Main to org/eclipse/core/launcher/Main$Identifier at org.eclipse.core.launcher.Main.basicRun(Main.java:265) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.harmony.vm.JarRunner.main(Unknown Source) I'm sure it's something obvious I'm overlooking. Thanks for any help. 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
Actually... This is another bug :) The one I have found is implementation of putfield bytecode. Yours, somewhere in resolution code common to interpreter and jitrino. The first bug is fixed by the patch attached. Fix helps to pass ActiveMQ startup on interpreter. -- Ivan On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: From Ivan's hints in HARMONY-1561 I created a simple example that illustrates the bug. Attached to the JIRA. geir On Sep 23, 2006, at 4:46 PM, Geir Magnusson Jr. wrote: So the simple-minded JarRunner that I added to DRLVM works for simple things, but I'm seeing the method.invoke() toss a InvocationTargetException wrapping a IllegalAccessError for Geronimo and Eclipse. I'm sure it's obvious to someone here, but it's not to me. I'm going to keep trying to figure it out, as I'm going to learn something, but if anyone knows the answer, please, just shout it out. The way that DRLVM works now w/ a jar is that it simplemindedly runs o.a.h.vm.JarRunner, which expects the jar name as the first element in the String[] passed to main(). it opens the jar, finds the main class name from the manifest, gets that Method, and then invokes it. For simple test jars, it works fine. For Eclipse, for example, I get java.lang.IllegalAccessError: from org/eclipse/core/launcher/Main to org/eclipse/core/launcher/Main$Identifier at org.eclipse.core.launcher.Main.basicRun(Main.java:265) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.harmony.vm.JarRunner.main(Unknown Source) I'm sure it's something obvious I'm overlooking. Thanks for any help. geir -- Ivan 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
On Sep 23, 2006, at 7:46 PM, Ivan Volosyuk wrote: Actually... This is another bug :) Oh well :) The one I have found is implementation of putfield bytecode. Yours, somewhere in resolution code common to interpreter and jitrino. The first bug is fixed by the patch attached. Fix helps to pass ActiveMQ startup on interpreter. Cool -thx. geir -- Ivan On 9/24/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: From Ivan's hints in HARMONY-1561 I created a simple example that illustrates the bug. Attached to the JIRA. geir On Sep 23, 2006, at 4:46 PM, Geir Magnusson Jr. wrote: So the simple-minded JarRunner that I added to DRLVM works for simple things, but I'm seeing the method.invoke() toss a InvocationTargetException wrapping a IllegalAccessError for Geronimo and Eclipse. I'm sure it's obvious to someone here, but it's not to me. I'm going to keep trying to figure it out, as I'm going to learn something, but if anyone knows the answer, please, just shout it out. The way that DRLVM works now w/ a jar is that it simplemindedly runs o.a.h.vm.JarRunner, which expects the jar name as the first element in the String[] passed to main(). it opens the jar, finds the main class name from the manifest, gets that Method, and then invokes it. For simple test jars, it works fine. For Eclipse, for example, I get java.lang.IllegalAccessError: from org/eclipse/core/launcher/Main to org/eclipse/core/launcher/Main$Identifier at org.eclipse.core.launcher.Main.basicRun(Main.java:265) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.harmony.vm.JarRunner.main(Unknown Source) I'm sure it's something obvious I'm overlooking. Thanks for any help. geir -- Ivan 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
Ok - simple example is found in HARMONY-1562 geir On Sep 23, 2006, at 4:46 PM, Geir Magnusson Jr. wrote: So the simple-minded JarRunner that I added to DRLVM works for simple things, but I'm seeing the method.invoke() toss a InvocationTargetException wrapping a IllegalAccessError for Geronimo and Eclipse. I'm sure it's obvious to someone here, but it's not to me. I'm going to keep trying to figure it out, as I'm going to learn something, but if anyone knows the answer, please, just shout it out. The way that DRLVM works now w/ a jar is that it simplemindedly runs o.a.h.vm.JarRunner, which expects the jar name as the first element in the String[] passed to main(). it opens the jar, finds the main class name from the manifest, gets that Method, and then invokes it. For simple test jars, it works fine. For Eclipse, for example, I get java.lang.IllegalAccessError: from org/eclipse/core/launcher/Main to org/eclipse/core/launcher/Main$Identifier at org.eclipse.core.launcher.Main.basicRun(Main.java:265) at org.eclipse.core.launcher.Main.run(Main.java:977) at org.eclipse.core.launcher.Main.main(Main.java:952) at java.lang.reflect.VMReflection.invokeMethod(Native Method) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.harmony.vm.JarRunner.main(Unknown Source) I'm sure it's something obvious I'm overlooking. Thanks for any help. 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]
