Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[aspectj-users] LTW (load time weaving) with Aj throws OutOfMemoryError

Hi Andy,

I rerun the profiler, still only some static variables remained, such as org.aspectj.apache.bcel.util.ClassLoaderRepository.sharedCach, org.aspectj.weaver.loadtime.Aj$WeaverContainer.weavingAdaptors,
org.aspectj.apache.bcel.Constants.TYPE_OF_OPERANDS,  org.aspectj.apache.bcel.Constants.ACCESS_NAMES and so on. There's no reference on them, at least as my profiler showed.

I have made a hack in my application so that each call will result in creating a chunk of objects per classloader, and I did not find my classloader has memory leak.

BTW, my application will create a new classloader for each request, and in turn a new Aj will be created.

Anfernee

On Wed, Jul 23, 2008 at 4:05 PM, <aspectj-users-request@xxxxxxxxxxx> wrote:
Send aspectj-users mailing list submissions to
       aspectj-users@xxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
       https://dev.eclipse.org/mailman/listinfo/aspectj-users
or, via email, send a message with subject or body 'help' to
       aspectj-users-request@xxxxxxxxxxx

You can reach the person managing the list at
       aspectj-users-owner@xxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of aspectj-users digest..."


Today's Topics:

  1. Regarding worm whole implementation (Mritunjay Kumar)
  2. Re: LTW (load time weaving) with Aj throws        OutOfMemoryError
     (Anfernee Xu)


----------------------------------------------------------------------

Message: 1
Date: Wed, 23 Jul 2008 13:08:44 +0530
From: "Mritunjay Kumar" <mritunjayonemail@xxxxxxxxx>
Subject: [aspectj-users] Regarding worm whole implementation
To: aspectj-users@xxxxxxxxxxx
Message-ID:
       <dd0dee950807230038g7125bc98j665ede6d3fd36f8d@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

Our requirement is to implement worm whole pattern using aspectj.
We are able to do it when caller and callee are in same cflow.
But suppose we have one method 'getUser()', when getUser() method returns,
after that we are calling customerService.createCustomer().
the other end of worm hole comes in customerService.createCustomer()
execution flow.
Is there any way we can make the getUser() as the first point cut or our
question is that 'is there any way to implement worm whole apttern even
thouh caller and callee are not in same control flow".
Please give suggestion on it as soon as possible.

Regards,
Mritunjay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080723/957ff2fe/attachment.html

------------------------------

Message: 2
Date: Wed, 23 Jul 2008 16:05:08 +0800
From: "Anfernee Xu" <anfernee.xu@xxxxxxxxx>
Subject: [aspectj-users] Re: LTW (load time weaving) with Aj throws
       OutOfMemoryError
To: aspectj-users@xxxxxxxxxxx
Message-ID:
       <71e105540807230105y3177b903w792d09987f02c84d@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

The output of console shows

 [WeaveClassLoaderImpl@c625f0] info AspectJ Weaver Version 1.6.1 built on
Thursday Jul 3, 2008 at 18:35:41 GMT
 [WeaveClassLoaderImpl@c625f0] info register classloader
com.ctc.ant.WeaveClassLoaderImpl@c625f0
 [WeaveClassLoaderImpl@c625f0] info using configuration
file:/D:/test/aj-transformer.jar!/META-INF/aop.xml
 [WeaveClassLoaderImpl@c625f0] info register aspect
com.ctc.aspects.TransformerAspect

 Transforming class ...

 Weaver adaptors before queue processing:
 org.aspectj.weaver.loadtime.Aj$AdaptorKey@1ca37bb0 =
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@e50bb4
 Weaver adaptors after queue processing:
 org.aspectj.weaver.loadtime.Aj$AdaptorKey@1ca37bb0 =
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@e50bb4
 Weaver adaptors before queue processing:
 org.aspectj.weaver.loadtime.Aj$AdaptorKey@1ca37bb0 =
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@e50bb4
 Weaver adaptors after queue processing:
 org.aspectj.weaver.loadtime.Aj$AdaptorKey@1ca37bb0 =
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor@e50bb4


Anfernee



On Wed, Jul 23, 2008 at 11:25 AM, <aspectj-users-request@xxxxxxxxxxx> wrote:

> Send aspectj-users mailing list submissions to
>        aspectj-users@xxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://dev.eclipse.org/mailman/listinfo/aspectj-users
> or, via email, send a message with subject or body 'help' to
>        aspectj-users-request@xxxxxxxxxxx
>
> You can reach the person managing the list at
>        aspectj-users-owner@xxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of aspectj-users digest..."
>
>
> Today's Topics:
>
>   1. Re: LTW (load time weaving) with Aj throws        OutOfMemoryError
>      (Andy Clement)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 22 Jul 2008 20:25:14 -0700
> From: "Andy Clement" <andrew.clement@xxxxxxxxx>
> Subject: Re: [aspectj-users] LTW (load time weaving) with Aj throws
>        OutOfMemoryError
> To: aspectj-users@xxxxxxxxxxx
> Message-ID:
>        <689d61aa0807222025wef1a8d3iedc8167302f36d30@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Also, you didn't tell me the output produced for making that API call.
> Passing 'true' means it should tell you the size of the weaveradaptor set
> and whether it is managing to clean it up? (to stdout)
>
> Andy.
>
> 2008/7/22 Anfernee Xu <anfernee.xu@xxxxxxxxx>:
>
> > Thanks Andy for your information.
> >
> > I tried the API call
> >     org.aspectj.weaver.loadtime.Aj.removeStaleAdaptors(true)
> >
> > but it does not help, the memory still bloats, I ran a profiler to
> monitor
> > the possible memory leak,
> > between two time slides, I can see the following instances constantly
> going
> > up.
> >
> > static variable org.aspectj.apache.bcel.util.
> > ClassLoaderRepository.sharedCache
> >
> > and
> >
> > static variable
> > org.aspectj.weaver.loadtime.Aj$WeaverContainer.weavingAdaptors
> >
> > Hope it can help you find out what's going wrong.
> >
> > If you need any further information, feel free to ask me.
> >
> > Thanks for your help.
> >
> > Anfernee
> >
> >
> > On Wed, Jul 23, 2008 at 11:03 AM, Anfernee Xu <anfernee.xu@xxxxxxxxx>
> > wrote:
> >
> >> Thanks Andy for your information.
> >>
> >> I tried the API call
> >>     org.aspectj.weaver.loadtime.Aj.removeStaleAdaptors(true)
> >>
> >> but it does not help, the memory still bloats, I ran a profiler to
> monitor
> >> the possible memory leak,
> >> between two time slides, I can see the following instances constantly
> >> going up.
> >>
> >> static variable
> >> org.aspectj.apache.bcel.util.ClassLoaderRepository.sharedCache
> >>
> >> and
> >>
> >> static variable
> >> org.aspectj.weaver.loadtime.Aj$WeaverContainer.weavingAdaptors
> >>
> >> Hope it can help you find out what's going wrong.
> >>
> >> If you need any further information, feel free to ask me.
> >>
> >> Thanks for your help.
> >>
> >> Anfernee
> >>
> >>
> >>
> >> On Wed, Jul 23, 2008 at 1:33 AM, <aspectj-users-request@xxxxxxxxxxx>
> >> wrote:
> >>
> >>> Send aspectj-users mailing list submissions to
> >>>        aspectj-users@xxxxxxxxxxx
> >>>
> >>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>        https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>> or, via email, send a message with subject or body 'help' to
> >>>        aspectj-users-request@xxxxxxxxxxx
> >>>
> >>> You can reach the person managing the list at
> >>>        aspectj-users-owner@xxxxxxxxxxx
> >>>
> >>> When replying, please edit your Subject line so it is more specific
> >>> than "Re: Contents of aspectj-users digest..."
> >>>
> >>>
> >>> Today's Topics:
> >>>
> >>>   1. Re: Error building project with Eclipse+AJDT 1.5.2 (Andy Clement)
> >>>   2. Re: LTW (load time weaving) with Aj throws        OutOfMemoryError
> >>>      (Andy Clement)
> >>>   3. Static Analysis, BCEL and aspectj (100ji)
> >>>
> >>>
> >>> ----------------------------------------------------------------------
> >>>
> >>> Message: 1
> >>> Date: Tue, 22 Jul 2008 10:18:52 -0700
> >>> From: "Andy Clement" <andrew.clement@xxxxxxxxx>
> >>> Subject: Re: [aspectj-users] Error building project with Eclipse+AJDT
> >>>        1.5.2
> >>> To: aspectj-users@xxxxxxxxxxx
> >>> Message-ID:
> >>>        <689d61aa0807221018n5ae0ed10r9fa295ca26db2a41@xxxxxxxxxxxxxx>
> >>> Content-Type: text/plain; charset="iso-8859-1"
> >>>
> >>> Hi Walter,
> >>>
> >>> 2008/7/22 Walter Cazzola <cazzola@xxxxxxxxxxxxx>:
> >>>
> >>> > Hi Andy,
> >>> > thanks a lot for the answer
> >>> >
> >>> > On Mon, 21 Jul 2008, Andy Clement wrote:
> >>> >
> >>> >   There is a 64k size limit for methods in Java.  Sometimes if an
> >>> >>  already large method contains many join points that match then
> during
> >>> >>  weaving the size will grow past 64k.  AspectJ does not do any
> >>> >>  splitting of the woven code into multiple methods in this case but
> >>> >>  just reports that it cannot weave that method.
> >>> >>
> >>> >
> >>> > We was imaging something like this. Is there a way to work around
> this
> >>> > problem?
> >>> >
> >>>
> >>> Only the workarounds you might imagine, there is no magic solution:
> >>> - use withincode() to avoid weaving the method that will get too large
> >>> with
> >>> your general aspect and write specific advice for relevant join points
> >>> within it.
> >>> - use execution() matching advice rather than call() which might advise
> >>> fewer places
> >>> - turn off advice inlining if using around advice, to reduce code
> >>> inserted
> >>> into advised methods
> >>> - don't use non-static information available at the join point since
> that
> >>> must be packaged up and passed to the advice every time
> >>>
> >>>
> >>> >
> >>> > We are going to weave our aspects on third part applications and we
> >>> > don't want to refactor their code since our aspects have the intent
> to
> >>> > determine what can be extracted and encapsulated in aspects (aspect
> >>> > mining) but this sounds as a recursive problem.
> >>>
> >>>
> >>> The correct solution is breaking the advised method into pieces when it
> >>> gets
> >>> too large, but so far it happens infrequently enough that fixing it
> >>> hasn't
> >>> become a priority for us I'm afraid.  In fact I don't even think we
> have
> >>> an
> >>> open bug request to address it - feel free to raise one but I'm not
> sure
> >>> we'll get to it soon.
> >>>
> >>> cheers,
> >>> Andy.
> >>>
> >>>
> >>>
> >>> >
> >>> >
> >>> > Cheers
> >>> > Walter
> >>> >
> >>> > --
> >>> > Walter Cazzola, PhD - Assistant Professor, DICo, University of Milano
> >>> > E-mail cazzola@xxxxxxxxxxxxx Ph.: +39 02 503 16300  Fax: +39 02 503
> >>> 16100
> >>> > · · · ---------------------------- · · · ----------------------------
> ·
> >>> · ·
> >>> >               ... recursive: adjective, see recursive ...
> >>> > · · · ---------------------------- · · · ----------------------------
> ·
> >>> · ·
> >>> > _______________________________________________
> >>> > aspectj-users mailing list
> >>> > aspectj-users@xxxxxxxxxxx
> >>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>> >
> >>> >
> >>> -------------- next part --------------
> >>> An HTML attachment was scrubbed...
> >>> URL:
> >>>
> https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080722/93aa98b5/attachment.html
> >>>
> >>> ------------------------------
> >>>
> >>> Message: 2
> >>> Date: Tue, 22 Jul 2008 10:28:14 -0700
> >>> From: "Andy Clement" <andrew.clement@xxxxxxxxx>
> >>> Subject: Re: [aspectj-users] LTW (load time weaving) with Aj throws
> >>>        OutOfMemoryError
> >>> To: aspectj-users@xxxxxxxxxxx
> >>> Message-ID:
> >>>        <689d61aa0807221028y34115351r26c54fa85a214179@xxxxxxxxxxxxxx>
> >>> Content-Type: text/plain; charset="iso-8859-1"
> >>>
> >>> > My Ant task will destroy the classloader which creates Aj after each
> >>> processing. It looks to me the
> >>> > loaded/transformed classes is not clean up when the classloader is
> >>> destroyed.
> >>> > I used the latest AspectJ relase, 1.6.1
> >>>
> >>> I specifically tested that tidy up is occurring with 1.6.1 and all my
> >>> scenarios confirm it - however that is doing loadtime weaving the
> regular
> >>> way.  I have seen problems with Ant where classloaders have not been
> >>> released, even when you think they must have.  Can you run your
> >>> classloader
> >>> in a regular Java scenario outside of Ant and confirm whether it
> behaves?
> >>>
> >>> There is an API call
> >>>
> >>> org.aspectj.weaver.loadtime.Aj.removeStaleAdaptors(true)
> >>>
> >>> that will attempt to remove weavers attached to stale classloaders.
>  Try
> >>> calling that and seeing what output you get - if they cannot be tidied
> up
> >>> then the classloaders have not been orphaned.  In that case collect
> some
> >>> hprof profiling output and use something like (j)hat to see who is
> >>> holding
> >>> on to references to them.  If it is the weaver then I have a bug to
> fix.
> >>>
> >>> What is still a problem is that over time the weaver instances will get
> >>> larger and larger and never shrink - we have an open bug report for
> that.
> >>> But if you are constantly using different classloaders (and so
> different
> >>> weaver instances) then they will come and go and never grow out of
> >>> control.
> >>>
> >>> Andy.
> >>>
> >>>
> >>> 2008/7/22 Anfernee Xu <anfernee.xu@xxxxxxxxx>:
> >>>
> >>> > Hi,
> >>> >
> >>> > I'm developing an Ant task which will use LTW to enhance the classes
> >>> > specified in <classpath> nested element of my Ant task. Basically, I
> >>> create
> >>> > a subclass of AntClassLoader, the classloader is at the bottom of
> >>> > classloader tree. and use org.aspectj.weaver.loadtime.Aj to perform
> >>> LTW,
> >>> > here's my ClassLoader code snippet,
> >>> >
> >>> > class WeaveClassLoader extends AntClassLoader {
> >>> >
> >>> >   // aspectj byte-code transformer
> >>> >   protected Aj transformer = null;
> >>> >
> >>> >   // whether need byte-code transformer.
> >>> >   protected boolean isAjOn = false;
> >>> >
> >>> > @Override
> >>> >  protected final Class defineClassFromData(File container, byte[]
> >>> > classData,
> >>> >       String classname) throws IOException {
> >>> >
> >>> >     byte[] classBytes = transform(classname, classData, this);
> >>> >     return super.defineClassFromData(container, classBytes,
> classname);
> >>> >
> >>> >   }
> >>> >
> >>> > protected byte[] transform(String classname, byte[] byteCode,
> >>> >       ClassLoader classloader) {
> >>> >     if (isTransformerTurnOn() && isWeavedClass(classname))
> >>> >       return transformer.preProcess(classname, byteCode, this);
> >>> >     return byteCode;
> >>> >   }
> >>> >
> >>> >
> >>> >   @Override
> >>> >   protected synchronized Class loadClass(String classname, boolean
> >>> resolve)
> >>> >       throws ClassNotFoundException {
> >>> >     Class theClass = findLoadedClass(classname);
> >>> >     if (theClass != null) {
> >>> >       return theClass;
> >>> >     }
> >>> >     if (isSplit(classname) || isAspect(classname)) {
> >>> >       theClass = findClass(classname);
> >>> >       if (resolve) {
> >>> >         resolveClass(theClass);
> >>> >       }
> >>> >
> >>> >     } else {
> >>> >       theClass = super.loadClass(classname, resolve);
> >>> >     }
> >>> >
> >>> >     return theClass;
> >>> >   }
> >>> >
> >>> > The function run pretty well, but over time, it consumed more memory
> >>> and
> >>> > eventually threw OutOfMemory and aborted.
> >>> >
> >>> > The stacktrace is as follows,
> >>> >
> >>> > testErrorHandling_exceptiontype:
> >>> >  Jul 20, 2008 2:36:10 PM org.aspectj.weaver.tools.Jdk14Trace error
> >>> >  SEVERE: junit.framework.Test
> >>> >  java.lang.OutOfMemoryError: CG(q0)
> >>> > [org/aspectj/apache/bcel/Constants.<clinit>()V] JVM@cgFail
> (src/jvm/code/codemanager.c:693).
> >>> Java heapsize=604577792, pa
> >>> >      at
> >>> >
> >>>
> org.aspectj.apache.bcel.classfile.Attribute.readAttribute(Attribute.java:177)
> >>> >      at
> >>> >
> >>>
> org.aspectj.apache.bcel.classfile.FieldOrMethod.<init>(FieldOrMethod.java:111)
> >>> >      at org.aspectj.apache.bcel.classfile.Field.<init>(Field.java:83)
> >>> >      at
> >>> >
> >>>
> org.aspectj.apache.bcel.classfile.ClassParser.readFields(ClassParser.java:280)
> >>> >      at
> >>> >
> >>>
> org.aspectj.apache.bcel.classfile.ClassParser.parse(ClassParser.java:172)
> >>> >      at
> >>> >
> >>>
> org.aspectj.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:288)
> >>> >      at
> >>> > org.aspectj.weaver.bcel.BcelWorld.lookupJavaClass(BcelWorld.java:369)
> >>> >      at
> >>> > org.aspectj.weaver.bcel.BcelWorld.resolveDelegate(BcelWorld.java:338)
> >>> >      at
> >>> org.aspectj.weaver.ltw.LTWWorld.resolveDelegate(LTWWorld.java:97)
> >>> >      at
> org.aspectj.weaver.World.resolveToReferenceType(World.java:378)
> >>> >      at org.aspectj.weaver.World.resolve(World.java:271)
> >>> >      at
> >>> >
> >>>
> org.aspectj.weaver.bcel.BcelWeaver.addLibraryAspect(BcelWeaver.java:165)
> >>> >      at
> >>> >
> >>>
> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerAspects(ClassLoaderWeavingAdaptor.java:399)
> >>> >      at
> >>> >
> >>>
> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerDefinitions(ClassLoaderWeavingAdaptor.java:240)
> >>> >      at
> >>> >
> >>>
> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:152)
> >>> >      at
> >>> >
> >>>
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151)
> >>> >      at
> >>> >
> >>>
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:156)
> >>> >      at
> >>> > org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122)
> >>> >      at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73)
> >>> > .....
> >>> >  Jul 20, 2008 2:36:10 PM org.aspectj.weaver.tools.Jdk14Trace info
> >>> >  INFO: Dumping to .\ajcore.20080720.143610.453.txt
> >>> >    302
> >>> >
> >>>
> tests.functional.webapp.servlet25.clarifications.client.TestClarifications.testClarifications
> >>> > (junit)
> >>> >  testErrorHandling_errorcode:
> >>> >  Jul 20, 2008 2:36:12 PM org.aspectj.weaver.tools.Jdk14Trace error
> >>> >  SEVERE: junit.framework.Test
> >>> >  java.lang.OutOfMemoryError: class allocation, 967086156 loaded,
> >>> 893648896
> >>> > footprint JVM@check_alloc(src/jvm/model/classload/classalloc.c:118).
> >>> 5841
> >>> > bytes
> >>> >      at java.lang.ClassLoader.defineClass1(Native Method)
> >>> >      at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
> >>> >      at
> >>> >
> >>>
> org.apache.tools.ant.loader.AntClassLoader2.defineClassFromData(AntClassLoader2.java:78)
> >>> >      at
> >>> >
> >>>
> org.apache.tools.ant.AntClassLoader.getClassFromStream(AntClassLoader.java:1090)
> >>> >      at
> >>> >
> >>>
> org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1154)
> >>> >      at
> >>> >
> org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:984)
> >>> >      at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
> >>> >      at
> >>> >
> >>>
> org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:140)
> >>> >      at
> >>> >
> >>>
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:151)
> >>> >      at
> >>> >
> >>>
> org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:157)
> >>> >      at
> >>> > org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122)
> >>> >      at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73)
> >>> >
> >>> >
> >>> >
> >>> > My Ant task will destroy the classloader which creates Aj after each
> >>> > processing. It looks to me the loaded/transformed classes is not
> clean
> >>> up
> >>> > when the classloader is destroyed.
> >>> > I used the latest AspectJ relase, 1.6.1
> >>> >
> >>> > Any help is appreciated.
> >>> >
> >>> > Anfernee
> >>> >
> >>> > _______________________________________________
> >>> > aspectj-users mailing list
> >>> > aspectj-users@xxxxxxxxxxx
> >>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>> >
> >>> >
> >>> -------------- next part --------------
> >>> An HTML attachment was scrubbed...
> >>> URL:
> >>>
> https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080722/a6de41b0/attachment.html
> >>>
> >>> ------------------------------
> >>>
> >>> Message: 3
> >>> Date: Tue, 22 Jul 2008 13:32:56 -0400
> >>> From: 100ji <itz100ji@xxxxxxxxx>
> >>> Subject: [aspectj-users] Static Analysis, BCEL and aspectj
> >>> To: aspectj-users@xxxxxxxxxxx
> >>> Message-ID:
> >>>        <496ed55f0807221032p37836435je1515b6755d80af9@xxxxxxxxxxxxxx>
> >>> Content-Type: text/plain; charset=ISO-8859-1
> >>>
> >>> Hi all,
> >>>
> >>> I have a few novice questions about aspectj.
> >>>
> >>> 1) Why can't aspectj be used to perform *some* forms of static
> >>> analysis? For example, for a given source code, I need to find if the
> >>> code has any calls to java.io.ObjectInputStream.readObject and the
> >>> type of object being read if any calls exist. I can use a static
> >>> analysis tool like PMD to find this out, but writing a tree walker is
> >>> extra work when aspectj knows how to do it. Why can I not write
> >>> something like a compile_time_pointcut and compile_time_advice to
> >>> specify this? Since aspectj already knows how to match patterns it can
> >>> give me the points I am interested in during compile time and run the
> >>> compile_time_advice. I understand that this approach is not as
> >>> powerful as one would like it to be, but this seems like a better
> >>> approach then the existing tools. I am not aware if any of the static
> >>> analysis tools can match patterns using a pointcut like syntax, so
> >>> this seemed like a useful addition.
> >>>
> >>> 2) Why is there no support for join points at a line level? For
> >>> example, I want to write an advice before or after the true condition
> >>> block of the if clause. Is there any fundamental reason why this is
> >>> not possible  in aspectj? IIRC I can do this using BCEL or other byte
> >>> code engineering libraries. But, I heard that using 2 instrumentation
> >>> tools on the same code is a bad idea (ex: aspectj and BCEL) since
> >>> either of them may not understand the instrumentation made by the
> >>> other. What do people do when they have to instrument code at a low
> >>> level and still have to use aspectj. What libraries should  I use, if
> >>> I want to do some bytecode level engineering and still use aspectj?
> >>>
> >>> TIA,
> >>> -S-
> >>>
> >>>
> >>> ------------------------------
> >>>
> >>> _______________________________________________
> >>> aspectj-users mailing list
> >>> aspectj-users@xxxxxxxxxxx
> >>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >>>
> >>>
> >>> End of aspectj-users Digest, Vol 41, Issue 34
> >>> *********************************************
> >>>
> >>
> >>
> >>
> >> --
> >> --Anfernee
> >>
> >
> >
> >
> > --
> > --Anfernee
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080722/7a64227c/attachment.html
>
> ------------------------------
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> End of aspectj-users Digest, Vol 41, Issue 38
> *********************************************
>



--
--Anfernee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://dev.eclipse.org/mailman/private/aspectj-users/attachments/20080723/35c89322/attachment.html

------------------------------

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users


End of aspectj-users Digest, Vol 41, Issue 39
*********************************************



--
--Anfernee

Back to the top