11 Replies Latest reply on Jun 12, 2007 8:40 PM by Flavia Rainone

    Retrowoven container project

    Kabir Khan Master

      A few of the JDK 1.4 tests in AOP are failing due to java.lang.reflect.ParameterizedType being used by the container project. while not supported in JBoss Retro. I tried adding that to Retro, but it now falls over on things like:

      java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
      java.lang.NoSuchMethodError: java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
      at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getConstructors(IntrospectionTypeInfoFactoryImpl.java:143)
      at org.jboss.reflect.plugins.ClassInfoImpl.getDeclaredConstructors(ClassInfoImpl.java:400)
      at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getConstructors(AbstractBeanInfoFactory.java:177)
      at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:138)
      at org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:75)
      at org.jboss.test.beaninfo.test.AbstractBeanInfoTest.getBeanInfo(AbstractBeanInfoTest.java:349)
      at org.jboss.test.beaninfo.test.BeanInfoUnitTestCase.testBean(BeanInfoUnitTestCase.java:153)
      at org.jboss.test.beaninfo.test.BeanInfoUnitTestCase.testBeanConstructors(BeanInfoUnitTestCase.java:73)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)

      So support for this needs implementing

        • 1. Re: Retrowoven container project
          Scott Stark Master

          Can you create a test for this and add a jira issue to http://jira.jboss.com/jira/browse/JBBUILD under the JBossRetro component so it does not get lost.

          • 2. Re: Retrowoven container project
            Adrian Brock Master

            This also needs linking with this:
            http://jira.jboss.com/jira/browse/JBMICROCONT-129
            I'm not sure what support Javassist has for the Java5 types?

            • 3. Re: Retrowoven container project
              Kabir Khan Master

              http://jira.jboss.com/jira/browse/JBBUILD-333

              Javassist doesn't seem to have any built in support for the types, but they seem to be tied in somehow with the Signature attribute.

              • 4. Re: Retrowoven container project
                Shigeru Chiba Expert

                OK, I will fix this problem.

                • 5. Re: Retrowoven container project
                  Shigeru Chiba Expert

                   

                  java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
                  java.lang.NoSuchMethodError: java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
                  at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getConstructors(IntrospectionTypeInfoFactoryImpl.java:143)
                  at org.jboss.reflect.plugins.ClassInfoImpl.getDeclaredConstructors(ClassInfoImpl.java:400)


                  It seems that the underlying JVM is 1.4 and thus does not support getGenericParameterTypes(). Is this correct?
                  If yes, Javassist is not guilty of this problem. (Of course, Javassist should
                  provide some support of generic types but I am now writing about this particular problem.)

                  • 6. Re: Retrowoven container project
                    Kabir Khan Master

                    When used with JBoss Retro, we will replace access to Constructor.getGenericParameterTypes() with a call to some other class that does this. We will also replace all occurrences of java.lang.reflect.Type with org.jboss.lang.reflect.Type etc.

                    The "some other class that does this" will need to use javassist to get hold of the generic info, similarly to how the JBoss Retro AnnotationHelper uses javassist to get hold of the annotations from the bytecode attributes.

                    • 7. Re: Retrowoven container project
                      Flavia Rainone Master

                      The main difficulty of implementing the generic reflection methods is the fact that java.lang.Class does not extend java.lang.reflect.Type.
                      Kabir and I have been discussing about this issue in the past few days.
                      I decided to play a little with the code Kabir attached to Jira
                      http://jira.jboss.com/jira/browse/JBBUILD-333

                      The generic API Kabir implemented is returning java.lang.Object where java.lang.Type is expected. This approach works fine, except for the following scenario:

                      final Type[] OBJ_TYPE_ARR = new Type[] {Object.class};
                      

                      which results in java.lang.ArrayStoreException

                      I can think of three solutions for this problem:

                      (1) do nothing, leave as is, and add the scenario above as a restriction in the usage of jboss retro
                      pros: simplicity
                      cons: we are not solving the problem above

                      (2) change bootclasspath, in a similar way we do in Jboss AOP to affect
                      java.lang.ClassLoader. In a very simple way, we could make Class to implement Type, and make Class, Method and Constructor to implement GenericDeclaration.
                      pros: simple solution and solves the problem
                      cons: we are forcing users to set xbootclasspath everytime they run a retro woven code

                      (3) replace java.lang.Class by a org.jboss.retro.runtime.lang.Class
                      pros: problem solved
                      cons: problem of casting (explained below)
                      affects performance
                      complex solution

                      After playing with the replacement of java.lang.Class for a while, I have an almost ready version. Nevertheless, there is a lot of details involved that I had to solve. The code looks too complex, and it does not work completely. It will fail in the following scenarios:
                      Class clazz = (Class) list.get(0); // if this list has been returned by an api, and it contains java.lang.Class instances, we have a problem, we need to wrap the element in a org.jboss.retro.runtime.lang.Class instance
                      Class clazz = (Class) Biblio.doSomething(); // same here, this time it is an api method that returns Object
                      

                      In order to solve the problem with the code above, we would need to detect those class casts and wrap the java.lang.Class in a jboss retro class.

                      All in all, I think that we should leave as is, unless ArrayStoreException be considered a very serious issue. Another possibility would be to provide the bootclasspath solution as an option, so that, if there is a problem with an woven code due to java.lang.Class not implementing org.jboss.retro.runtime.lang.Type, there would be a solution available.

                      Any thoughts?

                      • 8. Re: Retrowoven container project
                        Paul Gier Master

                        How about translating Type to java.lang.Object? Since the jdk1.5 Type interface does not have any methods, you don't seem to lose any functionality. So the code above becomes

                        final Object[] OBJ_TYPE_ARR = new Object[] {Object.class};
                        


                        If you get the latest jboss retro from svn, this is how I have it working now. Combined with kabir's code, this seems to work. At least for the test cases I came up with.

                        Maybe we lose something else that I'm not thinking of.

                        • 9. Re: Retrowoven container project
                          Flavia Rainone Master

                          Great! When I looked at the retro trunk code, I just noticed I couldn't find the problematic line at the test class anymore. I didn't realize that you were replacing java.lang.Class by java.lang.Object :)

                          Your idea is really good. Maybe, you could apply the same to GenericDeclaration. Replace it by Object, and replace calls to its single method (getTypeParameters) by calls to a Helper, as is done in GenericsHelper. That way, all the problem would be solved, and in a very simple way.

                          • 10. Re: Retrowoven container project
                            Paul Gier Master

                            Ok, I should be able to add the GenericDeclaration stuff today. And then I will release retro 1.1.0 at the end of today or tomorrow.

                            • 11. Re: Retrowoven container project
                              Flavia Rainone Master

                              Excelent news! :)