SEC-906: SecuredMethodDefinitionSource always requires AspectJ to be on the classpath #1159

spring-issuemaster opened this Issue Jul 4, 2008 · 3 comments


None yet

1 participant

from SEC-906) said:

When setting up a SecuredMethodDefinitionSource based on AOP Alliance Java will throw a "java.lang.NoClassDefFoundError: org/aspectj/lang/Signature ". The reason is that SecuredMethodDefinitionSource extends AbstractFallbackMethodDefinitionSource which has compile time references to AOP alliance and aspectJ classes. Thus it currently is not possible to use @Secured without having AspectJ on the classpath.

AbstractFallbackMethodDefinitionSource as well as AbstractMethodDefinitionSource should delegate AspectJ related checkings to subclasses that are only loaded if it is dynamically determined whether AspectJ is on the classpath or not.

Right now I helped myself by patching the class and simply commenting out all JoinPoint and Signature class references.


Luke Taylor said:

This dependency has been in there since Acegi’s AspectJSecurityInterceptor was written so this isn’t anything new and so a decision can be postponed till 2.1. Any changes to check with classloaders etc will just make the code harder to follow and the aspectj runtime jar is only about 100k in size in any case.


Luke Taylor said:

I don’t think this justifies making changes to core code to locate classes reflectively etc. It just makes for a maintenance headache and aspectj is likely to feature even more strongly in future releases.


Dan Diephouse said:

This dependency wasn’t in Acegi 1.0.6. We performed a straightforward upgrade of our app and this is the first time we had to add the dependency.

@spring-issuemaster spring-issuemaster added this to the 3.0.0 M1 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment