Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Alexey, Thanks for pointing to that test - I created my tests using this approach. Please see HARMONY-1671 for tests. If you think that some more options should be covered - please let me know - I'll try to make tests for them. On 9/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for volunteering. You might be interested to look at org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest in archive module - it gives some basic coverage in this area. I know about it because just recently fixed it, see HARMONY-1622. -- Alexey 2006/9/29, Anton Luht [EMAIL PROTECTED]: Hello, I'd like to volunteer. Just an idea: I'm going to create a number of .class and .jar files and test various combinations of launching using SupportExec On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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] -- 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] -- 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
nice work Anton Luht wrote: Alexey, Thanks for pointing to that test - I created my tests using this approach. Please see HARMONY-1671 for tests. If you think that some more options should be covered - please let me know - I'll try to make tests for them. On 9/29/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Anton, Many thanks for volunteering. You might be interested to look at org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest in archive module - it gives some basic coverage in this area. I know about it because just recently fixed it, see HARMONY-1622. -- Alexey 2006/9/29, Anton Luht [EMAIL PROTECTED]: Hello, I'd like to volunteer. Just an idea: I'm going to create a number of .class and .jar files and test various combinations of launching using SupportExec On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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] -- 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] - 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
Hello, I'd like to volunteer. Just an idea: I'm going to create a number of .class and .jar files and test various combinations of launching using SupportExec On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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] -- 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
Anton, Many thanks for volunteering. You might be interested to look at org.apache.harmony.archive.tests.java.util.jar.JarOutputStreamTest in archive module - it gives some basic coverage in this area. I know about it because just recently fixed it, see HARMONY-1622. -- Alexey 2006/9/29, Anton Luht [EMAIL PROTECTED]: Hello, I'd like to volunteer. Just an idea: I'm going to create a number of .class and .jar files and test various combinations of launching using SupportExec On 9/25/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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] -- 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]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
Alexey, We should also note, that system class loader === application loader (=== URLClassLoader in our case). :) Though, it looks like I've mistaken when generifying the requirement for class loader to parse manifest and extract Class-Path attribute from it. Though :), this requirement is true for bootstrap class loader (at least RIs do parse them). Regards, Pavel. On 9/25/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Pavel, Thanks for the links - I found smth interesting in the last one. Note, however: all of them mention that the application or extension class loader should use the Class-Path attribute, not arbitrary URLClassLoader. Moreover, this depends on the context - e.g. the extension CL should ignore it. And the URLClassLoader does not provide any API to control this. Though our URLClassLoader is aware of the Class-Path attribute and current JarRunner impl works, we may need to revisit this issue in sometime... -- Regards, Alexey 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Ha! I discovered interesting article [1] about java launcher and class loading. Pavel. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html On 9/25/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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] invoking non-trivial jars results in IllegalAccessError
Perfect. The key was I didn't realize the launcher added the jar to the class path. Thanks geir On Sep 24, 2006, at 11:18 PM, Alexey Varlamov wrote: This is simple now :) - it's a pity a did not look at JarRunner earlier. The launcher adds -Djava.class.path=jar, so the system classloader become aware of that path. Due to delegation model, the system classloader has precedence over MyLoader. The root cause of problem is incorrect usage of API for MyLoader - JarRunner should call public loadClass(String) instead of protected findClass(String) for MyLoader. And the access modifiers hint this ;) Actually I see no reason to deal with MyLoader at all - system classloader would do fine. -- Alexey 2006/9/25, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 24, 2006, at 8:09 PM, Gregory Shimansky wrote: On Sunday 24 September 2006 05:46 Geir Magnusson Jr. wrote: On Sep 23, 2006, at 7:46 PM, Ivan Volosyuk wrote: Actually... This is another bug :) Oh well :) I think I've found the cause of this bug. Now what to do with it... Thanks for looking into it so fast. 1. Class Foo is loaded by org/apache/harmony/vm/JarRunner$MyLoader while Bar is loaded by java/net/URLClassLoader$SubURLClassLoader. Why? I thought they would be in the same classloader, given the fact that I fed the jar to MyLoader... 2. The comparison in Resolve.cpp:177 fails because each class loader in VM has its own table of packages and thus Foo and Bar while having the same packages in name, have different packages in terms of class loading. This results in IllegalAccessError. I am not sure what actually is wrong, #1 or #2 or both. I think all user application classes should be loaded by the same system class loader unless user specifies another one. So #1 seems to be the candidate for me. -- 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: [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
As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
2006/9/25, Chris Gray [EMAIL PROTECTED]: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. Right! I had this in mind but forgot somehow :( -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
Alexey, There numerous sources. [1] is jar file specification - look for Class-Path attribute description, [2] is from Java tutorials series - read through first paragraph. I'm sure that more direct statement can be found at java.sun.com. [1] http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html [2] http://java.sun.com/docs/books/tutorial/ext/basics/load.html On 9/25/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
Ha! I discovered interesting article [1] about java launcher and class loading. Pavel. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html On 9/25/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
Pavel, Thanks for the links - I found smth interesting in the last one. Note, however: all of them mention that the application or extension class loader should use the Class-Path attribute, not arbitrary URLClassLoader. Moreover, this depends on the context - e.g. the extension CL should ignore it. And the URLClassLoader does not provide any API to control this. Though our URLClassLoader is aware of the Class-Path attribute and current JarRunner impl works, we may need to revisit this issue in sometime... -- Regards, Alexey 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Ha! I discovered interesting article [1] about java launcher and class loading. Pavel. [1] http://java.sun.com/j2se/1.5.0/docs/tooldocs/findingclasses.html On 9/25/06, Alexey Varlamov [EMAIL PROTECTED] wrote: Pavel, Just to be clear, could you please point to some documentation which declares such responsibility? This seems logical and now I recall why I let it to be forgotten ;) 2006/9/25, Pavel Pervov [EMAIL PROTECTED]: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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] invoking non-trivial jars results in IllegalAccessError
We desperately need tests for this. Anyone want to volunteer, to even make simple ones? We can stuff into the smoke or other frameworks... geir Pavel Pervov wrote: Chris, As far as I understant, this is responsibility of a class loader to parse Class-Path attribute of any jar file it has in its class path. System class loader for DRLVM (which is URLClassLoader) does this. Any objections? Regards, Pavel Pervov. Intel Middleware Products Division. On 9/25/06, Chris Gray [EMAIL PROTECTED] wrote: As I understand it, the classpath of the jarred application should include the jar file itself and the contents of its Class-Path attribute (if any). You probably need to create a special class loader for the application and use that whenever the application (or a library loaded by it) is the initiator. -- Chris Gray/k/ Embedded Java Solutions BE0503765045 Embedded Mobile Java, OSGihttp://www.k-embedded-java.com/ [EMAIL PROTECTED] +32 3 216 0369 - 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
On Sunday 24 September 2006 05:46 Geir Magnusson Jr. wrote: On Sep 23, 2006, at 7:46 PM, Ivan Volosyuk wrote: Actually... This is another bug :) Oh well :) I think I've found the cause of this bug. Now what to do with it... 1. Class Foo is loaded by org/apache/harmony/vm/JarRunner$MyLoader while Bar is loaded by java/net/URLClassLoader$SubURLClassLoader. 2. The comparison in Resolve.cpp:177 fails because each class loader in VM has its own table of packages and thus Foo and Bar while having the same packages in name, have different packages in terms of class loading. This results in IllegalAccessError. I am not sure what actually is wrong, #1 or #2 or both. I think all user application classes should be loaded by the same system class loader unless user specifies another one. So #1 seems to be the candidate for me. -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] invoking non-trivial jars results in IllegalAccessError
On Sep 24, 2006, at 8:09 PM, Gregory Shimansky wrote: On Sunday 24 September 2006 05:46 Geir Magnusson Jr. wrote: On Sep 23, 2006, at 7:46 PM, Ivan Volosyuk wrote: Actually... This is another bug :) Oh well :) I think I've found the cause of this bug. Now what to do with it... Thanks for looking into it so fast. 1. Class Foo is loaded by org/apache/harmony/vm/JarRunner$MyLoader while Bar is loaded by java/net/URLClassLoader$SubURLClassLoader. Why? I thought they would be in the same classloader, given the fact that I fed the jar to MyLoader... 2. The comparison in Resolve.cpp:177 fails because each class loader in VM has its own table of packages and thus Foo and Bar while having the same packages in name, have different packages in terms of class loading. This results in IllegalAccessError. I am not sure what actually is wrong, #1 or #2 or both. I think all user application classes should be loaded by the same system class loader unless user specifies another one. So #1 seems to be the candidate for me. -- 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: [drlvm] invoking non-trivial jars results in IllegalAccessError
This is simple now :) - it's a pity a did not look at JarRunner earlier. The launcher adds -Djava.class.path=jar, so the system classloader become aware of that path. Due to delegation model, the system classloader has precedence over MyLoader. The root cause of problem is incorrect usage of API for MyLoader - JarRunner should call public loadClass(String) instead of protected findClass(String) for MyLoader. And the access modifiers hint this ;) Actually I see no reason to deal with MyLoader at all - system classloader would do fine. -- Alexey 2006/9/25, Geir Magnusson Jr. [EMAIL PROTECTED]: On Sep 24, 2006, at 8:09 PM, Gregory Shimansky wrote: On Sunday 24 September 2006 05:46 Geir Magnusson Jr. wrote: On Sep 23, 2006, at 7:46 PM, Ivan Volosyuk wrote: Actually... This is another bug :) Oh well :) I think I've found the cause of this bug. Now what to do with it... Thanks for looking into it so fast. 1. Class Foo is loaded by org/apache/harmony/vm/JarRunner$MyLoader while Bar is loaded by java/net/URLClassLoader$SubURLClassLoader. Why? I thought they would be in the same classloader, given the fact that I fed the jar to MyLoader... 2. The comparison in Resolve.cpp:177 fails because each class loader in VM has its own table of packages and thus Foo and Bar while having the same packages in name, have different packages in terms of class loading. This results in IllegalAccessError. I am not sure what actually is wrong, #1 or #2 or both. I think all user application classes should be loaded by the same system class loader unless user specifies another one. So #1 seems to be the candidate for me. -- 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] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[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] 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]
