[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] Custom JoinPoints
|
Hi Savita,
It seems to me that being able to manage per join point state could help with your use case (and it's a feature I too would very much like to see added). You could store additional related state in the extra state of a join point object as you could in a custom extension of join point, and the overhead ought to be similar (maybe with one more object being allocated by the AspectJ runtime).
The interesting wrinkle in your case is the desire to avoid pinning large objects in memory. For that you'd really like the ability to store state per join point but *not* pin the join point object. If the per join point storage facility were separate from the join point, that would allow computing small objects without holding references to potentially large data structures. I don't think this would be valuable for per static part storage, because there the data being held is a small constant and has been made quite small.
I think the next step is really for someone to create a good design and implementation. I don't know what the committers plans are in this respect, but am eager to know.
My $.02,
Ron
-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Chandan, Savita
Sent: Thursday, October 05, 2006 11:22 AM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Custom JoinPoints
Hi Ron,
Iam curious to know what the Inquiring minds thought about the use case below. and if we plan to do something about it?
Thanks,
Savita
-----Original Message-----
From: "Chandan, Savita" <Savita.Chandan@xxxxxxxxxxxxxx>
Date: Fri, 29 Sep 2006 17:56:48 -0700
Delivered-to: aspectj-users@xxxxxxxxxxx
Thread-index: Acbisvt1A3npu+aVRN2g6xviHMHe3wAFRhnAAEfALYAAEDbSYA==
Thread-topic: [aspectj-users] Custom JoinPoints
--------------------------------------------------------------------------------
I was intending to do more research before I responded to any of the
other emails, but haven't had a chance to do that.
Anyways, My requirement was,
If I could have a custom JoinPoint that can do special translation for
some specific method arguments in its current context.
The reason being, In a FlightRecorder utility, if I were to cache the
JoinPoint for dumping the data to a log file at a later time and one of
the method arguments had a huge memory footprint, I wouldn't want to
cache that particular argument and hold on to the reference, instead I
would convert that parameter to a brief String in the JoinPoint and
cache the JoinPoint. My Custom JoinPoint would detect such arguments and
immediately convert them to a brief string and not cache the object
argument ( Not sure what can of worms that this would open, but it
should be doable right?)
Now, may be there are other ways of doing this without derived/Custom
JoinPoint, like the user object proposed in the bug for AspectJ
https://bugs.eclipse.org/bugs/show_bug.cgi?id=89009. This would mean
creation of 2 objects for logging ( one is the JoinPoint that would be
created and other is the userObject to be set in the JoinPoint in
addition to some reflection calls). I think the hit would be limited to
creation of just 1 Object if the userObject was part of StaticJoinPoint
( which was also suggested in the bug comments).
Or
another idea that was brought up independent of AspectJ was using weak
references which again is Object creation ( might end up doing this if
nothing else works).
Hope this discourse above is clear enough to explain my requirements.
Savita
-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Ron Bodkin
Sent: Friday, September 29, 2006 10:42 AM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Custom JoinPoints
So Savita,
Inquiring minds want to know: what behavioral modification of a join
point
are you seeking to achieve?
-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Wes
Sent: Thursday, October 05, 2006 11:03 AM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Warning return
IDE support for messages is basically to mark them as warning or error, so we already
provide all the information that IDE's currently support. Indeed, AJDT goes to the
trouble of providing dual links, one to the code making the violation and one to
the code defining violation. (For discussions of extending AOP IDE's to do new
and cool things, see adjt-dev@xxxxxxxxxxx.)
It's not clear to me that what you're suggesting would work with all IDE's or all
implementations of AspectJ. I recommend submitting a bug that specifies a use-case
(what you want and how it will help), and optionally proposing an implementation.
I'm not aware of any other compiler that executes user-defined code; take that
into consideration when considering the implementation.
I suggested specially-coded warning strings and a custom message handler in order
to give you a way to prototype the kinds of warnings and analysis you'd like to
provide using pointcuts. It's really an implementation detail whether we use
"9 Something bad is coded here"
or
new WarningMessage(9, "Something bad is coded here")
since you can define your message handler to produce such WarningMessage and
consume them yourself. I agree that it's not the best for most programmers,
but it should give you a way to build up the kind of analysis you want.
In any case, there is a high bar for changing the AspectJ language, even
in a backwards-compatible way, so the use case should be compelling. For that,
it would be good to see the kinds of warnings, etc. you propose. As I said,
I personally believe that the set of things you can find by analyzing code for errors
on a per-join-point basis is far outstripped by what other tools do by evaluating the
structure of code (i.e., whole-program analysis). Thus, I believe any general-
purpose application would not be compelling because better alternatives exist.
However, it's very compelling to have aspect-related declarations that prove
assumptions being made by pointcuts and to make simple per-join-point assertions
about illegal practices. That's what we do already.
This is one of the most interesting application areas, so if you can propose
something interesting in the bug, that would be great.
hth - Wes
> ------------Original Message------------
> From: "matsui akira" <akira_in_tokyo@xxxxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Thu, Oct-5-2006 6:17 AM
> Subject: [aspectj-users] Warning return
>
> Sorry for insisting on this topic. I really believe this is something
> we
> could take a look at more carefully. Since the subject deviated since
> the
> original message, I think it is best to start a new conversation.
>
> I believe warnings give to IDE a good oportunity to improve code
> measurement and interaction with programmer.
>
> I have seen strings-based programming failing many times. So my
> suggestion
> is to change the return type to Object or a new interface. So warning
> declaration could be both:
>
> declare warning : bad() : new WarningMessage(9, "Something bad is coded
>
> here.");
>
> or
>
> declare warning : bad() : "Something bad is coded here.";
>
> Message handlers could then do reflection to find from which class the
> message return is. A simple message handler could simply call
> .toString()
> to print results as current implementation does.
>
> This feature can, for example, create reports to measure how many
> directs
> calls exist to file IO within all classes.
>
> Also, it would be possible to report how many calls to deprecated
> methods
> exist inside the code. So one could get a legacy code and, in face of a
> new
> release of libs and without much effort, create an aspect that can
> measure
> its quality.
>
>
> >From: "Wes Isberg" <wes@xxxxxxxxxxxxxx>
> >Reply-To: aspectj-users@xxxxxxxxxxx
> >To: aspectj-users@xxxxxxxxxxx
> >Subject: Re: [aspectj-users] Describing the chattyness
> >Date: Sat, 30 Sep 2006 12:38:49 -0700
> >
> >This is an interesting problem area but one not directly in
> >the domain of AOP.
> >
> >While declare error/warning can pick out specific
> >staticly-determinable join point, pointcut languages aren't
> >typically set up to make assertions across join points or
> >about missing join points (e.g., you should implement this
> >method or have a constructor that takes this argument), so
> >things like JQuery are better suited to that. However,
> >those are often limited to static analysis, and the runtime
> >capabilities of AOP can augment those systems. For
> >example, it's a common aspect to track a use pattern like
> >(open stream, use stream, close stream) where the stream
> >might be opened, used, and closed by different components.
> > AOP is good at detecting that the stream was not closed
> >and who was supposed to.
> >
> >
> >On the question of the warning level, the user can encode a
> >particular level in the message, e.g.,
> >
> > declare warning : bad() : "09 bad thing";
> >
> >Not the best, but...
> >
> >Also, the message handlers are pluggable so you can set up
> >programmer support at build time by installing a message
> >handler that does something special when given your special
> >messages (e.g., counting up an overall "score" for a
> >program given all the messages).
> >
> >hth - Wes
> >
> >On Sat, 30 Sep 2006 20:36:59 +0900
> > "matsui akira" <akira_in_tokyo@xxxxxxxxxxx> wrote:
> > > I believe this use points to an interesting application
> > > for AOP. Warnings could be used to measure code. In this
> > > case, the number of communication with a certain layer
> > > could be counted by a tool that attaches to the IDE in
> > > use and give the programmer a quantification about the
> > > code.
> > >
> > > I already had a similar problem before. I had to create
> > > advices to tell programmers about choices that could
> > > reflect in bad execution performance. Programmers could
> > > have a tool that give them an overal report about code
> > > quality so that this could guide their development.
> > > Warnings could be classified according to it severity.
> > >
> > > As a sugestion, warning declaration could be changed
> > > optionally to the following:
> > >
> > > declare warning (10, WARNING_CLASS) : within({Business});
> > >
> > > where 10 is the severity and WARNING_CLASS is an
> > > enumeration item.
> > >
> > > >From: "Wes" <wes@xxxxxxxxxxxxxx>
> > > >Reply-To: wes@xxxxxxxxxxxxxx, aspectj-users@xxxxxxxxxxx
> > > >To: aspectj-users@xxxxxxxxxxx
> > > >Subject: Re: [aspectj-users] Describing the chattyness
> > > >Date: Thu, 28 Sep 2006 10:57:59 -0700
> > > >
> > > >
> > > >Calls from Business:
> > > >
> > > > declare warning : within({Business}) && call({Dao}) :
> > > "business ->
> > > DAO";
> > > > where {Business} and {Dao} depend on your system.
> > > >
> > > >Similarly, callbacks from DAO:
> > > >
> > > > declare warning : within({Dao}) && call({Business}) :
> > > "DAO ->
> > > Business";
> > > >
> > > >For a runtime accounting, use advice to log the same
> > > pointcuts.
> > > >
> > > >Is that what you were looking for? ("reference count"
> > > typically means
> > > >the number of references to a particular object.)
> > > >
> > > >(See also JDepends.)
> > > >
> > > >Wes
> > > >
> > > >btw, search didn't turn up any relevant definition of
> > > "AMOF"
> > > >
> > > > > ------------Original Message------------
> > > > > From: Thomas SMETS - disposable add
> > > <duvelbier-tsmets@xxxxxxxxx>
> > > > > To: aspectj-users@xxxxxxxxxxx
> > > > > Date: Thu, Sep-28-2006 10:50 AM
> > > > > Subject: [aspectj-users] Describing the chattyness
> > > > >
> > > > >
> > > > > Dear,
> > > > >
> > > > > I was wondering how I could do a reference count...
> > > > > AMOF, I would like to measure the level of chattyness
> > > in my code :
> > > > >
> > > > >
> > > > > Service Layer <--> Business Layer <--> Dao
> > > <--> DB
> > > > >
> > > > >
> > > > > If I can forbid the Service to talk directly to the
> > > Dao, I woundered if
> > > > > I could also point the places where the Business was
> > > chatting too much
> > > > > with the DAO's (hence the DB).
> > > > >
> > > > > Any hint into this would be appreciated !
> > > > >
> > > > > \T,
> > > > >
> > > > >
> > > > > -- Any fool can write code that a computer can
> > > understand.
> > > > > Good programmers write code that humans can
> > > understand.
> > > > >
> > > > > Martin Fowler
> > > > >
> > > > > T. : +32 (0)2 742 05 94
> > > > > M. : +32 (0)497 44 68 12
> > > > > @ : duvelbier-tsmets@xxxxxxxxx
> > > > > Do you skype too ... (tsmets) ?
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > aspectj-users mailing list
> > > > > aspectj-users@xxxxxxxxxxx
> > > > >
> > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > > > >
> > > >
> > > >_______________________________________________
> > > >aspectj-users mailing list
> > > >aspectj-users@xxxxxxxxxxx
> > > >https://dev.eclipse.org/mailman/listinfo/aspectj-users
> > >
> > >
> >_________________________________________________________________
> > > あなたのPCの健康状態を無料でチェック・維持します
> http://safety.live.com/
> > > _______________________________________________
> > > aspectj-users mailing list
> > > aspectj-users@xxxxxxxxxxx
> > > https://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> >_______________________________________________
> >aspectj-users mailing list
> >aspectj-users@xxxxxxxxxxx
> >https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _________________________________________________________________
> au版メッセンジャーEZアプリ新登場！いますぐ無料ダウンロード！
> http://promotion.live.jp/messenger/mobile.htm
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
