Hi Wendel, So sorry I'm slow to reply here.
> I see the classes get woven at startup, but then at runtime the aspect isn't executing. So the showweaveinfo and 'after' dumped bytecode is showing the weaving is happening but the aspects aren't running? I've not seen that before as usually if the weaving happens, the aspects run. If they don't I'd be expecting some kind of classnotfoundexception as the woven code cannot access the aspect class. Are you using something like my notes in http://andrewclement.blogspot.ca/2009/02/load-time-weaving-basics.html to debug the load time weaving? Do you by any chance have JMX turned on for the linux case? I'm aware of a bug in 1.7.3 related to turning on JMX that can adversely affect weaving. (Fixed in 1.7.4 snapshots) > LTW adds over 2 minutes to startup Can be many reasons for this. If you have a proliferation of classloaders, each will get a weaver. There are techniques for avoiding certain classloaders (e.g. jsp loaders) that you *know* are loading classes that should never be woven. We can also tweak the pointcuts sometimes to speed up matching (and reduce load time weaving time) - on that blog I referenced before is an article about using the built in timers to assess whether your pointcuts are taking a long time to match. If, with verbose on, you are seeing lots of jsp loaders getting weavers, we can address that. > org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'vendorKeyController.AjcClosure9' defined in URL [jar:file:/export/home/infusionsoft/crm-29-sandbox2/ This gets into an area I don't know so well. I don't know why Spring would be trying to treat a generated closure as a bean. This forum should be a good place for that question: http://forum.spring.io/forum/spring-projects/aop - 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?) There is nothing special in AspectJ that should cause it to behave differently on different OSs. Are you using the same JDK (and fixpack level of that JDK) on each OS? - 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? I would ask on the forum I referenced about that closure being treated as a bean. cheers, Andy On 17 October 2013 10:15, Wendel Schultz <wendel.schu...@gmail.com> wrote: > > 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 > >
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
