Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AspectJExpressionPointcut unpredictable behavior in OSGi environment [SPR-10871] #15498

Closed
spring-issuemaster opened this issue Aug 28, 2013 · 1 comment

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Aug 28, 2013

Temnov Aleksey opened SPR-10871 and commented

Hi,
We have a java application consisting of multiple OSGi modules running with Apache Felix container. Spring DM is responsible for loading spring application contexts of our bundles.
We faced this kind of error:

 
Caused by: java.lang.IllegalArgumentException: warning no match for this type name: my.bundle.second.api.MarkerInterface [Xlint:invalidAbsoluteTypeName]
        at org.aspectj.weaver.tools.PointcutParser.parsePointcutExpression(PointcutParser.java:301)
        at org.springframework.aop.aspectj.AspectJExpressionPointcut.buildPointcutExpression(AspectJExpressionPointcut.java:208)
        at org.springframework.aop.aspectj.AspectJExpressionPointcut.buildPointcutExpression(AspectJExpressionPointcut.java:194)
        at org.springframework.aop.aspectj.AspectJExpressionPointcut.checkReadyToMatch(AspectJExpressionPointcut.java:183)
        at org.springframework.aop.aspectj.AspectJExpressionPointcut.getClassFilter(AspectJExpressionPointcut.java:164)
        at org.springframework.aop.support.AopUtils.canApply(AopUtils.java:208)
        at org.springframework.aop.support.AopUtils.canApply(AopUtils.java:262)
        at org.springframework.aop.support.AopUtils.findAdvisorsThatCanApply(AopUtils.java:294)
        at org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findAdvisorsThatCanApply(AbstractAdvisorAutoProxyCreator.java:118)
        at org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.findEligibleAdvisors(AbstractAdvisorAutoProxyCreator.java:88)
        at org.springframework.aop.framework.autoproxy.AbstractAdvisorAutoProxyCreator.getAdvicesAndAdvisorsForBean(AbstractAdvisorAutoProxyCreator.java:69)

After some researching we found that this exception is thrown while trying to match this aop expression:

@Before("within(my.bundle..*) && target(my.bundle.second.api.MarkerInterface)")

So, we looked up for an issue #13973 and made a small test project that represents the architecture of problematic funсtionality in our project. After we coded it, we faced another problem. Every time we start felix, we randomly get one of two different errors. One of them I already specified upwards and the other one is:

Caused by: org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldException: warning can't determine implemented interfaces of missing type my.bundle.one.FirstAbstractClass
 [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.ReferenceType.isAssignableFrom(ReferenceType.java:566)
        at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:584)
        at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:584)
        at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:418)
        at org.aspectj.weaver.patterns.ExactTypePattern.matchesInstanceof(ExactTypePattern.java:200)
        at org.aspectj.weaver.patterns.TypePattern.matches(TypePattern.java:152)
        at org.aspectj.weaver.patterns.ThisOrTargetPointcut.matchInternal(ThisOrTargetPointcut.java:124)
        at org.aspectj.weaver.patterns.Pointcut.match(Pointcut.java:137)
        at org.aspectj.weaver.patterns.AndPointcut.matchInternal(AndPointcut.java:55)
        at org.aspectj.weaver.patterns.Pointcut.match(Pointcut.java:137)
        at org.aspectj.weaver.internal.tools.PointcutExpressionImpl.getShadowMatch(PointcutExpressionImpl.java:312)
        at org.aspectj.weaver.internal.tools.PointcutExpressionImpl.matchesExecution(PointcutExpressionImpl.java:122)
        at org.aspectj.weaver.internal.tools.PointcutExpressionImpl.matchesMethodExecution(PointcutExpressionImpl.java:103)
        at org.springframework.aop.aspectj.AspectJExpressionPointcut.getShadowMatch(AspectJExpressionPointcut.java:435)
        at org.springframework.aop.aspectj.AspectJExpressionPointcut.matches(AspectJExpressionPointcut.java:273)

The logic of this functionality is very easy:
We have Bundle-1, that contains just one class, we called it "FirstAbstractClass".
Bundle-2 contains class "SecondAbstractClass" that extends "FirstAbstractClass" from bundle-1, aspect "CommonAspect" with expression that I specified earlier and an interface, called "MarkerInterface".
Bundle-3 contains OSGi service classes "ConcreteClass" and "ConcreteClassMarkered", that extend "SecondAbstractClass" and aspect declaration in bundle-3-context file:

<bean id="aspect" class="my.bundle.second.CommonAspect"/>

This is it.
If you comment declaration of "concreteClass" bean in bundle-3 spring context, all the bundles will start fine, but if you comment "concreteClassMarkered" - application won't work.
If you import package of "FirstAbstractClass" from first bundle to third one - it will solve the problem. But I guess it's a weird workaround, and application should work perfectly without it.
I guess, first type of error caused by using wrong classloader during aspect expression processing (guess it was classloader from bundle-1, that can't see bundle-3 "MarkerInterface"). What causes the second one - I don't know.

So, we found that this is a wrong and unpredictable behavior and made this bug.

Test project is also commited to: spring-framework-issues SPR-10871


Affects: 3.2.4

Reference URL: https://github.com/bsko/Spring-SPR-9335-own

1 votes, 2 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jan 12, 2019

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.