在GigaSpaces 8和Spring3中，AspectJ autoproxy失败，因为类是由不同的类加载器加载的

Question

我们使用的是GigaSpaces版本8.0.0 (是的，它很旧)和Spring3(是的，它也很旧)。有两个模块A和B。A是“主”模块，它对空间进行读写，并公开一些远程服务。A和B分别运行。B创建一个实体的实例，该实体具有一个作为类对象的字段。这个类只存在于B中；A不知道它。然后，它对A进行远程调用，最终将实例写入空间。

稍后，A加载此实体并通过执行entity.getClassObject().newInstance()创建远程类的一个实例。即使这个类不存在于A的运行时类加载器中，它仍然可以工作，因为这个类的类加载器是GigaSpaces附带的LRMI (轻量级远程方法调用)类加载器。我猜它知道如何实例化它。

当我们向A添加一个方面时，问题就出现了。我们现有的代码使用A的应用程序上下文自动装配远程类的一个实例，并使用initializeBean对其进行初始化。自动装配和初始化工作得很好，直到我们添加了方面。现在，在初始化期间，它尝试查看方面中的建议是否适用于正在初始化的bean。作为此过程的一部分，它尝试使用Class.forName和bean的类名创建类的实例。这会导致ClassNotFoundException，因为该类显然不存在于运行时类加载器中。因此，AspectJ将该类型解析为MissingResolvedTypeWithKnownSignature，而不是立即失败。但最终，当AspectJ尝试查找该类的超类时会失败，因为它没有该信息，并抛出以下异常：

org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldException: warning can't determine implemented interfaces of missing type com.mypackage.MyRemoteClass
 [Xlint:cantFindType]
        at org.aspectj.weaver.reflect.ReflectionWorld$ExceptionBasedMessageHandler.handleMessage(ReflectionWorld.java:129)
        at org.aspectj.weaver.Lint$Kind.signal(Lint.java:328)
        at org.aspectj.weaver.MissingResolvedTypeWithKnownSignature.raiseCantFindType(MissingResolvedTypeWithKnownSignature.java:232)
        at org.aspectj.weaver.MissingResolvedTypeWithKnownSignature.getDeclaredInterfaces(MissingResolvedTypeWithKnownSignature.java:86)
        at org.aspectj.weaver.ResolvedType.getDirectSupertypes(ResolvedType.java:82)
        at org.aspectj.weaver.patterns.TypePattern.matchesSubtypes(TypePattern.java:178)
        at org.aspectj.weaver.patterns.ExactTypePattern.matchesSubtypes(ExactTypePattern.java:74)
        at org.aspectj.weaver.patterns.TypePattern.matchesStatically(TypePattern.java:130)
        at org.aspectj.weaver.patterns.KindedPointcut.fastMatch(KindedPointcut.java:141)
        at org.aspectj.weaver.internal.tools.PointcutExpressionImpl.couldMatchJoinPointsInType(PointcutExpressionImpl.java:84)
        at org.springframework.aop.aspectj.AspectJExpressionPointcut.matches(AspectJExpressionPointcut.java:238)
        at org.springframework.aop.support.AopUtils.canApply(AopUtils.java:200)
        at org.springframework.aop.support.AopUtils.canApply(AopUtils.java:254)
        at org.springframework.aop.support.AopUtils.findAdvisorsThatCanApply(AopUtils.java:286)
        at org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findAdvisorsThatCanApply(AbstractAdvisorAutoProxyCreator.java:117)
        at org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findEligibleAdvisors(AbstractAdvisorAutoProxyCreator.java:87)
        at org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.getAdvicesAndAdvisorsForBean(AbstractAdvisorAutoProxyCreator.java:68)
        at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.wrapIfNecessary(AbstractAutoProxyCreator.java:359)
        at org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator.postProcessAfterInitialization(AbstractAutoProxyCreator.java:322)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyBeanPostProcessorsAfterInitialization(AbstractAutowireCapableBeanFactory.java:407)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1426)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:386)
...

有什么办法可以解决这个问题吗？我能想到两种方法，但我不太确定该怎么做。一种是以某种方式阻止Spring检查方面是否适用，另一种可能是在运行时类加载器中找不到类的情况下，将运行时类加载器替换为委托给LRMI类加载器的类加载器。但我甚至不确定是否可以获得LRMI类加载器的实例。

有没有人遇到过这样的问题？

Answer 1

这是我使用的AspectJ版本(1.6.12)中的known issue。它似乎已经在更高的版本中得到了修复--至少从1.8.14开始(这是我升级到的版本)。所以升级我的AspectJ版本解决了这个问题。