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

Question

我们正在使用GigaSpaces版本8.0.0（是旧版本）和Spring 3（是旧版本）。有两个模块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类加载器的实例。

有人遇到这种问题吗？

我们正在使用GigaSpaces版本8.0.0（是旧版本）和Spring 3（是旧版本）。有两个模块A和B。A是“主要”模块，它对空间进行读写，并公开一些...

Answer 1

这是我使用的AspectJ版本（1.6.12）中的known issue。它似乎已在更高版本中修复-至少从1.8.14起（我将其升级到此版本）。因此，升级我的AspectJ版本可以解决此问题。