Actually I have written a comprehensive article a year or so ago about JDK weaving from Eclipse which I intended to publish on DZone, but the completely forgot about it because of my daytime job. ;-) when I am back home I can dig up the document. It is complete with screenshots and step by step description of different weaving scenarios. I think it was either Andrew Eisenberg or Andy Clement who reviewed it back then, I think the former one (sorry for being forgetful). So it is still on my Google Drive, but I would rather share it as PDF than Word document. If it is not urgent I can finally publish it sometime during the weekend. In today's light I would have tried to mavenise the approach than describe how to do it manually. But I guess it might be helpful even so. -- Alexander Kriegisch
> Am 07.11.2013 um 23:58 schrieb Jonathan Mace <[email protected]>: > > Thanks Alexander. I've been trying out weaving rt.jar and it's simple > enough. I build my project with maven and it's easy enough to weave rt.jar. > By default it does as you describe and includes the entire rt.jar in the > output. What is the ajc command line option (or aspectj-maven-plugin option) > to do as you suggest? > > Cheers, > > Jon > > >> On 7 November 2013 17:26, Alexander Kriegisch <[email protected]> >> wrote: >> Oh, I forgot to mention a little trick I use often in situations like these: >> I do not create a full copy of rt.jar, but just a small jar of woven JRE >> classes which I *prepend* to the bootclasspath, so the classes therein are >> found by the system classloader *before* the ones in the original rt.jar. >> >> -- >> Alexander Kriegisch >> >> >>> Am 07.11.2013 um 23:22 schrieb Alexander Kriegisch >>> <[email protected]>: >>> >> >>> Your intention is to profile low level calls. Whether you like it or not, I >>> think weaving rt.jar is the best choice because it does not have as much >>> overhead as the solutions you are thinking of. Profiling is usually not >>> done in production environments, so weaving the JRE should not be too much >>> trouble. >>> >>> -- >>> Alexander Kriegisch >>> >>> >>>> Am 07.11.2013 um 21:56 schrieb Jonathan Mace <[email protected]>: >>>> >>>> Thanks for your response Andy. >>>> >>>> Consider the following alternative approach to 'marking' the instances I'm >>>> interested in. I maintain a WeakHashSet<FilterInputStream> to reference >>>> all input streams that i'm interested in. I weave all constructor calls >>>> to FilterInputStream, adding this new stream to the set if either a) it's >>>> filtering a FileInputStream or b) it's filtering another FilterInputStream >>>> that already belongs to the set. Then I weave all calls to >>>> FilterInputStream+.read(..), adding an if() in the pointcut to test for >>>> membership in the set. >>>> >>>> It would suffer the same drawbacks of not instrumenting rt.jar, but would >>>> be pretty easy to implement. But, would this impose a lot of additional >>>> overhead? >>>> >>>> Cheers, >>>> >>>> Jon >>>> >>>> >>>>> On 7 November 2013 15:48, Andy Clement <[email protected]> wrote: >>>>> > I'll also mention that I don't want to weave rt.jar. >>>>> >>>>> Shame, that would make it rather easy with a pointcut on execution of >>>>> FileInputStream+.read(..). >>>>> >>>>> I can imagine your proxy route might work. You can advise the constructor >>>>> calls to the various FilterInputStream and FilterOutputStreams, and there >>>>> return a proxy with an additional marker interface. Sounds pretty messy >>>>> compared to what you are already doing though... There isn't anything >>>>> special in AspectJ to help here, simply around advice on the constructor >>>>> call to 'new' and then use cglib to generate the tagged proxy. If some >>>>> of those constructor calls are made inside rt.jar though, you won't be >>>>> catching them. (similar to now where you won't be catching calls to read >>>>> that are made inside classes within rt.jar) >>>>> >>>>> cheers, >>>>> Andy >>>>> >>>>> >>>>>> On 6 November 2013 14:29, Jonathan Mace <[email protected]> wrote: >>>>>> Hi everyone, >>>>>> >>>>>> Love AspectJ. I work on end-to-end tracing using X-Trace, and AspectJ >>>>>> is an awesome mechanism to do some of the tracing that I'm interested in. >>>>>> >>>>>> I'm trying to profile file accesses; specifically, calls to >>>>>> FileInputStream+.read(..) and FileOutputStream+.write(..). However, in >>>>>> many cases, file streams are wrapped in filter classes, such as Buffered >>>>>> streams or Data streams. The specific base classes that provide this >>>>>> mechanism are FilterInputStream and FilterOutputStream. Often, multiple >>>>>> filter streams are applied recursively to some base stream, for example >>>>>> new DataOutputStream(new BufferedOutputStream(new >>>>>> FileOutputStream("myfile.txt"))); >>>>>> >>>>>> Is there a way to define a pointcut that matches any Filter stream, >>>>>> whose underlying stream is a File stream? The naive solution I have so >>>>>> far is: >>>>>> >>>>>> Object around(FilterInputStream o): target(o) && call(* >>>>>> FilterInputStream+.read(..)) { >>>>>> InputStream base = o; >>>>>> while (base instanceof FilterInputStream) >>>>>> base = ((FilterInputStream) base).in; >>>>>> boolean isFileStream = base instanceof FileInputStream; >>>>>> >>>>>> if (isFileStream) { >>>>>> long start = System.nanoTime(); >>>>>> Object ret = proceed(o); >>>>>> long duration = System.nanoTime() - start; >>>>>> // do profiling stuff >>>>>> return ret; >>>>>> } else { >>>>>> return proceed(o); >>>>>> } >>>>>> } >>>>>> >>>>>> I'm worried about the overhead of recursively examining the filter >>>>>> streams to determine whether the base stream is a file stream. I'll >>>>>> also mention that I don't want to weave rt.jar. It would be great if I >>>>>> could insert some kind of proxy class when the appropriate Filter >>>>>> instance is created, then the pointcut can just look for the proxy class. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Jon >>>>>> >>>>>> _______________________________________________ >>>>>> aspectj-users mailing list >>>>>> [email protected] >>>>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>>>> >>>>> >>>>> _______________________________________________ >>>>> aspectj-users mailing list >>>>> [email protected] >>>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >>>> >>>> _______________________________________________ >>>> aspectj-users mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
