If this isn't the appropriate forum, feel free to direct me where I should
go.
I have an aspect which measures metrics for annotated classes and methods
of a Spring project. I am looking to measure public @Controller
@RequestMapping methods, public @Repository methods and public methods on
one of our annotations specifically created to capture measurements. This
is a pretty obvious aspectj use.
I have done a lot of flailing so please be gentle.
I do this as a single @Around advice using
@Pointcut("within(@com.spring.Repository)
&& execution(public * *.*(..))")and so on for each annotation's pointcut
definition, ultimately used by my @Around("(repositoryClassPublicMethod()
|| controllerClassRequestMappingMethod() || metricAwareClassPublicMethod())
&& !autowiredMethod())"). I throw in not autowired to trim the fat a
little bit.
This is an enormous legacy app we need to chop up, but as-is it has
thousands of objects in the Spring context when it loads up.
I am able to compile the @Aspect, compile and war up my project to use
Spring's TomcatInstrumentableClassLoader, then instrument the JVM to use
Spring's instrumentation javaagent pointing to my aop.xml for load-time
weaving support. It comes alive and I want to buy everybody a round of
drinks. Kind of.
I say kind of because this works on my Mac (10.8), then when I apply the
patch and try on my buddy's Ubuntu box, I see the classes get woven at
startup, but then at runtime the aspect isn't executing. Again, the same
patch applied on my Mac behaves differently. We deploy to linux, so I'm at
a standstill.
Even if this worked on his Ubuntu box, LTW adds over 2 minutes to startup
(even if I don't showWeaveInfo and don't dump the before/after classes). I
need to do better.
So I looked into compile-time weaving to solve both of these issues (not
executing my aspect as well as load times). I configured our application
to use aspectj compile weaver, but then I see the following exceptions:
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'vendorKeyController.AjcClosure9' defined in URL
[jar:file:/export/home/infusionsoft/crm-29-sandbox2/
infusionsoft-dist/target/camp/webapp/WEB-INF/lib/com.infusion.crm-api.jar!/com/infusionsoft/api/authentication/controller/VendorKeyController$AjcClosure9.class]:
Instantiation of bean fail
ed; nested exception is
org.springframework.beans.BeanInstantiationException: Could not instantiate
bean class
[com.infusionsoft.api.authentication.controller.VendorKeyController$AjcClosur
e9]: *No default constructor found; nested exception is
java.lang.NoSuchMethodException:
com.infusionsoft.api.authentication.controller.VendorKeyController$AjcClosure9.<init>()
*
I use the aspectj-maven-plugin (from codehaus, not the maven-aspectj-plugin
from apache).
>From what I've been able to gather, closures are created when aspectj's
compiler can't inline the advice. OK, that's fine I guess. This leaves me
with a few questions:
- How can I get my LTW to work, even if it is slow (presumably I can use
the caching feature to only pay that price once?)
- How can I get compile-time parity with bytecode generated by LTW?
- Is there another way to dodge the issue in bold above having ajc-ed?
- What bad assumptions am I making?
- I want to build a Spring context. I don't really care how that
happens. Other ideas?
I'm not interested in fighting Spring AOP. It has its own gotchas and we
already use it in some situations which lead to a multiple inheritance
problem for some of the classes I'd be looking to aspect. I'd like to find
the end of this path I'm on.
Thanks SO much in advance,
-w
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
