[jira] Updated: (HARMONY-5005) [drlvm][kernel][geronimo] Field.getGenericType() fails on a parametrized class from custom classloader

["Vladimir Beliaev (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HARMONY-5005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladimir Beliaev updated HARMONY-5005:
--------------------------------------

    Attachment: 02-H5005.patch

Here is the patch. Its idea is:

1. each caller of AuxiliaryLoader.findClass keeps the reference to "wrapping" Class/Method/Field/Constructor instance called "startPoint".

2. so AuxiliaryLoader.findClass must utilize the ClassLoader of startPoint to load required type.

That's it... With the attached patch the functionality is not "changed" but it is "extended"... The required type loading (and resolution) starts with ClassLoader taken from startPoint or with SystemClassLoader.

Thanks
Vladimir

> [drlvm][kernel][geronimo] Field.getGenericType() fails on a parametrized class from custom classloader
> ------------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-5005
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5005
>             Project: Harmony
>          Issue Type: Bug
>          Components: App-Oriented Bug Reports, DRLVM
>            Reporter: Vasily Zakharov
>            Priority: Critical
>         Attachments: 01-H5005-formatting.patch, 02-H5005.patch
>
>
> java.lang.reflect.Field.getGenericType() fails if the field it's called upon is a parametrized class unavailable through the system class loader. To reproduce use the following code:
> import java.lang.reflect.*;
> import java.net.*;
> public class Test {
>     public static void main(String[] args) {
>         try {
>             ClassLoader loader = new URLClassLoader(new URL[] { new URL("file:foo.jar") } );
>             Class cls = loader.loadClass("Foo");
>             Field field = cls.getDeclaredField("field");
>             Type type = field.getGenericType();
>             System.out.println("SUCCESS: " + type);
>         } catch (Exception e) {
>             e.printStackTrace(System.out);
>         }
>     }
> }
> class Foo {
>     java.util.List<Foo> field;
> }
> After compilation create a foo.jar containing Foo.class and then make sure to remove Foo.class file:
> $ jar cvf foo.jar Foo.class
> $ rm Foo.class
> $ java Test
> Output on RI:
> SUCCESS: java.util.List<Foo>
> Output on Harmony:
> java.lang.TypeNotPresentException: Type Foo not present
> 	at org.apache.harmony.lang.reflect.support.AuxiliaryCreator.createTypeArgs(AuxiliaryCreator.java:216)
> 	at org.apache.harmony.lang.reflect.parser.Parser.parseFieldGenericType(Parser.java:358)
> 	at java.lang.reflect.Field.getGenericType(Field.java:72)
> 	at Test.main(Test.java:9)
> Caused by: java.lang.ClassNotFoundException: Foo
> 	at org.apache.harmony.lang.reflect.support.AuxiliaryLoader.findClass(AuxiliaryLoader.java:119)
> 	at org.apache.harmony.lang.reflect.support.AuxiliaryCreator.createTypeArg(AuxiliaryCreator.java:192)
> 	at org.apache.harmony.lang.reflect.support.AuxiliaryCreator.createTypeArgs(AuxiliaryCreator.java:214)
> 	at org.apache.harmony.lang.reflect.parser.Parser.parseFieldGenericType(Parser.java:358)
> 	... 2 more
> My guess is the problem lies in AuxiliaryLoader.findClass() method, line 67 - the method explicitly uses system class loader to load the target class, which clearly fails if the target class is available through some other classloader. It seems logical to use the classloader of the class whose field is being processed instead. However, the fix seems non-trivial as in the existing architecture the information on the containing class is lost when Parser is called.
> This issue prevents Apache Geronimo 2.0 from starting on Harmony.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.