JohnJPS (6) [Avatar] Offline
#1
Hello Ramnivas and others,

I've been able to find some info on this, but there are so many variations possible with AspectJ that I've yet to put everything together. My goal is essentially this:

1) create a library that provides an annotation and associated aspect that will weave various code around any method so annotated; I distribute this in a jar.

2) a user who knows nothing of aspects but would like to have the functionality I'm providing, should be able to just annotate any given method, and my library will take it from there... (provided the weave takes place correctly at compile time).

3) Important: I would like that 2nd step to be as simple and straight-forward as possible for the user... ideally they would just import my jar, annotate their methods, and do nothing else out of the ordinary. I understand there may be more to it than that, but wished to gain your insight into what you think would be the simplest way to implement something like this, as in the most transparent approach to the users in step 2.

Thanks much!
- John

(PS: the idea here is targeted performance logging: the aspect I've written collects performance statistics aroudn the annotated methods... the idea is that developers shouldn't have to worry about anything more than whatever methods are potential culprits... I also prefer the compile-time weaving just for performance concerns... but if you have other ideas for this concern, in general, I'd be happy to entertain those thoughts as well).
ramnivas (171) [Avatar] Offline
#2
Re: Compile-time weaving of jar-contained aspect into an user app.
John,

It seems like load-time weaving is your best option here (assuming that you can modify the startup script). This way your build environment will remain unchanged. The downside of this approach is slightly increased startup time.

Another approach is to use binary weaving (see the -injar option for ajc and the "injar" attribute to the 'iajc' Ant task). You keep your build system largely intact with this option and only add a post-build target -- say build-with-aspect that weaves the jar file produced using say the build target. This does increase build time (slightly, and only when you build for performance monitoring), but no modifications to the startup script is needed.

-Ramnivas
JohnJPS (6) [Avatar] Offline
#3
Re: Compile-time weaving of jar-contained aspect into an user app.
Ramnivas,

Thanks for the tips. My company provides developers with a "standard build" of Eclipse / MyEclipse / local BEA app server, so it's conceivable that we could make such a post-build step happen automatically... that may be more work than really seems appropriate for my project, though, so I think I'll take your advice and focus on load-time weakving for a bit.

A quick question on that: when we speak of slightly increased startup time, suppose we have a web service... is the time increase just during app server startup; or perhaps also deployment; or is it every time the web service is actually called? I'm not much worried about slight increases to server startup or deployment times, but I'd probably have to investigate things much more closely if there were a performance hit each time the service was called.
Thanks, John
ramnivas (171) [Avatar] Offline
#4
Re: Compile-time weaving of jar-contained aspect into an user app.
Increased startup time will occur only during loading of a class. Once a class is loaded, performance should be exactly identical to any other weaving mechanisms. In other words, the bytecode seen by the VM is the same regardless of the weaving mechanism.