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 P
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,
Man
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, Anto
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 sim
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 f
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
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
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
decla
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.h
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
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/
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 applica
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 in
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=, so the system classloader
b
This is simple now :) - it's a pity a did not look at JarRunner earlier.
The launcher adds -Djava.class.path=, 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
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 fo
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$MyLoa
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
Gero
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
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 Magnusso
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
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
22 matches
Mail list logo
