[jboss-jira] [JBoss JIRA] Commented: (JBAOP-795) Don't copy signature attribute for introduced methods
Kabir Khan (JIRA)
jira-events at lists.jboss.org
Mon Jun 7 11:19:42 EDT 2010
[ https://jira.jboss.org/browse/JBAOP-795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12534258#action_12534258 ]
Kabir Khan commented on JBAOP-795:
----------------------------------
Basically the problem is that when introducing an interface like
public interface TestInterface<T>
{
T method(T t);
}
When creating the introduction, in addition to copying across the annotations and parameter annotations, we were also copying the method signature. Since the addition of the interface via aop is "untyped", i.e. we don't define what T is in the class signature, calling Method.getGenericReturnType/getGenericParameterTypes()/getGenericExeptionTypes() fails since T is undefined. I have changed it to not copy across the signature attribute for introduced methods to avoid the problem with not finding T.
The real fix would be to force people introducing interfaces to supply a type argument, and to then add those type arguments to the class signature, but since AOP is in maintenance mode, I don't want to spend too long on that.
> Don't copy signature attribute for introduced methods
> -----------------------------------------------------
>
> Key: JBAOP-795
> URL: https://jira.jboss.org/browse/JBAOP-795
> Project: JBoss AOP
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 2.2.1.Alpha2
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 2.2.1.GA
>
>
> From: Kabir Khan <kabir.khan at jboss.com>
> Date: 7 June 2010 12:36:13 GMT+01:00
> To: Ales Justin <ales.justin at gmail.com>
> Cc: Flavia Rainone <flavia.rainone at jboss.com>
> Subject: Re: aop + scanning
> So it seems like the class has already been woven and the method comes from an introduction, it is falling over on
> public int org.jboss.test.aop.jdk15annotated.NoInterfacesPOJO2.compareTo(java.lang.Object)
> Which seems to be coming from this introduction
> @Mixin (target=org.jboss.test.aop.jdk15annotated.NoInterfacesPOJO2.class, interfaces={Comparable.class})
> public static ComparableMixin createComparableMixin() {
> return new ComparableMixin();
> }
> So I guess AOP is not updating the target classes signature attribute when adding introductions, but might be when adding the method?
> This means that when we call getDeclaredMethods() on the target class, and then on that method try to call getGenericParameterTypes() behind the scenes it tries to load up the value of the type variable defined on the method
> public int compareTo(T o);
> it can not find T and returns the array [null], rather than an array containing Object.
> I can work around it in reflect by returning the typeinfo for Object if Type is null. We should fix aop, but there might be other things doing the same thing? I'll dig a bit into how aop handles the signature stuff for a few different things at the moment, and see if it is fixable. At least that will give us a good idea of what is wrong so I can generate some "faulty" classes in the reflect testsuite and make sure reflect works as it should in these cases.
> From: Kabir Khan <kabir.khan at jboss.com>
> Date: 7 June 2010 11:35:22 GMT+01:00
> To: Ales Justin <ales.justin at gmail.com>
> Subject: Re: aop + scanning
> The root exception when I run AS is:
> Caused by: java.lang.IllegalArgumentException: Null type
> at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getTypeInfo(IntrospectionTypeInfoFactoryImpl.java:360) [jboss-reflect.jar:2.2.0.Alpha5]
> at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getTypeInfos(IntrospectionTypeInfoFactoryImpl.java:306) [jboss-reflect.jar:2.2.0.Alpha5]
> at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl$2.run(IntrospectionTypeInfoFactoryImpl.java:236) [jboss-reflect.jar:2.2.0.Alpha5]
> at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl$2.run(IntrospectionTypeInfoFactoryImpl.java:222) [jboss-reflect.jar:2.2.0.Alpha5]
> at java.security.AccessController.doPrivileged(Native Method) [:1.6.0_20]
> at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getMethods(IntrospectionTypeInfoFactoryImpl.java:221) [jboss-reflect.jar:2.2.0.Alpha5]
> at org.jboss.reflect.plugins.ClassInfoImpl.getDeclaredMethods(ClassInfoImpl.java:416) [jboss-reflect.jar:2.2.0.Alpha5]
> at org.jboss.scanning.plugins.visitor.ClassHierarchyResourceVisitor.handleClass(ClassHierarchyResourceVisitor.java:78) [:1.0.0.Alpha2]
> at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.doVisit(ReflectResourceVisitor.java:108) [:1.0.0.Alpha2]
> at org.jboss.scanning.plugins.visitor.ReflectResourceVisitor.visit(ReflectResourceVisitor.java:86) [:1.0.0.Alpha2]
> ... 63 more
> Which seems to stem from this call in ITIFI.getMethods():
> @SuppressWarnings("deprecation")
> public MethodInfoImpl[] getMethods(final ClassInfoImpl classInfo)
> {
> return AccessController.doPrivileged(new PrivilegedAction<MethodInfoImpl[]>()
> {
> public MethodInfoImpl[] run()
> {
> Class<?> clazz = classInfo.getType();
> Method[] methods = getDeclaredMethods(clazz);
> if (methods == null || methods.length == 0)
> return null;
> ClassLoader requesting = SecurityActions.getClassLoaderOrSystemClassLoader(clazz);
> ReflectMethodInfoImpl[] infos = new ReflectMethodInfoImpl[methods.length];
> for (int i = 0; i < methods.length; ++i)
> {
> AnnotationValue[] annotations = getAnnotations(methods[i]);
> infos[i] = new ReflectMethodInfoImpl(annotations,
> methods[i].getName(),
> getTypeInfo(methods[i].getGenericReturnType()),
> getTypeInfos(methods[i].getGenericParameterTypes()), // <<<<<<<<<<<<<<<
> getParameterAnnotations(methods[i].getParameterAnnotations()),
> getClassInfos(methods[i].getGenericExceptionTypes()),
> methods[i].getModifiers(),
> (ClassInfo) getTypeInfo(methods[i].getDeclaringClass()));
> infos[i].setMethod(methods[i]);
> }
> return infos;
> }
> });
> }
> I'll get the alpha5 source and debug, what is happening, probably some corner case we have not covered in the tests
> On 3 Jun 2010, at 12:55, Ales Justin wrote:
> Can you have a look at this:
> * https://jira.jboss.org/secure/attachment/12334744/jbas8060-test-regressions.txt
> What I would like to know is where this "Null type" is coming from.
> --------------------
> Test: org.jboss.test.aop.test.ScopedAnnotatedTestCase(aop-scoped)
> 2010-06-02 21:19:10,325 DEBUG [org.jboss.aop.asintegration.jboss5.AOPDeploymentAopMetaDataDeployer] (RMI TCP Connection(2)-127.0.0.1) Finished deploying AbstractVFSDeploymentContext at 7879273{vfs:///work/TRUNK/trunk/testsuite/output/lib/aop-scoped-annotated.sar/aop-scoped-annotated.aop/}
> 2010-06-02 21:19:11,786 DEBUG [org.jboss.scanning.deployers.ScanningDeployer] (RMI TCP Connection(2)-127.0.0.1) Error during deploy: vfs:///work/TRUNK/trunk/testsuite/output/lib/aop-scoped-annotated.sar/aop-scoped-annotated.aop/: java.lang.Error: Error visiting "/work/TRUNK/trunk/testsuite/output/lib/aop-scoped-annotated.sar/aop-scoped-annotated.aop/org/jboss/test/aop/jdk15annotated/NoInterfacesPOJO2.class"
> at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:268) [jboss-classloading-vfs.jar:2.2.0.Alpha5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:407) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:395) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:102) [jboss-classloading-vfs.jar:2.2.0.Alpha5]
> at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:181) [:2.2.0.Alpha5]
> at org.jboss.scanning.plugins.DeploymentUnitScanner.scan(DeploymentUnitScanner.java:111) [:1.0.0.Alpha2]
> at org.jboss.scanning.spi.helpers.UrlScanner.scan(UrlScanner.java:96) [:1.0.0.Alpha2]
> at org.jboss.scanning.deployers.ScanningDeployer.deploy(ScanningDeployer.java:90) [:1.0.0.Alpha2]
> at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha5]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha5]
> <snip>
> Caused by: java.lang.RuntimeException: java.lang.IllegalArgumentException: Null type
> at org.jboss.scanning.plugins.visitor.IgnoreSetErrorHandler.handleError(IgnoreSetErrorHandler.java:57) [:1.0.0.Alpha2]
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list