Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Custom JoinPoints

Title: RE: [aspectj-users] Custom JoinPoints

Wes,

You are right, our application is not  blocked by unavailability of custom join points. But we are in planning phase, and Iam trying to make a case to introduce AspectJ in our software (because I see benefits in using AspectJ).

Regarding weak references , I do understand what that entails and the tradeoff is debatable ( again a design time decision), because we have handful of such objects and logging them during brief logging is not essential.

 

-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Wes
Sent: Thursday, October 05, 2006 5:36 PM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Custom JoinPoints

I still don't get it.  How does a custom join point class help?
The canonical use for user state in join points is to communicate
between advice on the same join point, but this is just a special
form of logging.

Object creation is not expensive.  Detecting large objects is, as is
converting them to String.  So there's no real additional cost to
doing this with your own data structures compared to supporting
custom join points.  It's certainly doable; it's not like your
application is blocked by not having custom join points.

(Also, a flight recorder is one of the last things I'd want
dumping data randomly by using weak references.)

Wes

> ------------Original Message------------
> From: "Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Date: Thu, Oct-5-2006 3:37 PM
> Subject: 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
>
> _______________________________________________
> 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


Back to the top