Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] How to use "call pointcut", when using reflection

Hi Jim

Thanks a lot for further clarifying , you are right and I see your point
and the usefulness for the "call pointcut", I am gonna give it a try for
this newInstance() thing, but :

By the way, what I was referring by this approach was NOT_PERFORMANCE_HIT
but the ugly way to check all the interested types of objects (If my
behaviour needs to be different, for different object types) in the
system and thats kind of bad implementation..

Secondly, I am exactly trying the thing what you mentioned, returning a
different instance to the client than the actual one he/she would have
got otherwise.

Lastly, Could a call pointcut be weaved into a caller if i
ONLY_HAVE_CLASS_FILE but not the source (need not to say, I dont need to
decompile it).

Thanks a ton
Tarun

On Thu, 28 Aug 2003 14:59:01 -0700, "Jim Hugunin" <lists@xxxxxxxxxxx>
said:
> Tarun Sharma wrote:
> > I really appreciate and understand that this might be one way to atleast
> > try, but I believe you would agree that this might not be practical due
> > to following limitations I see.
> > 
> > 1. To have "call construct", I understand that the caller must be
> > included in the weaving (at compile time)and this case it would be core
> > class of jdk i.e. "Constructor", I am not sure if the classloader would
> > allow this. Can we do weaving at class loading time.? Even in that case,
> 
> One of the most useful things about call joinpoints is that the 
> implementation only needs access to the code making the call, not the 
> code that implements the method.  This is very useful for capturing 
> calls of methods in the java..* namespace.  So long as you have access 
> to the code that is calling Constructor.newInstance you should be fine. 
>   Give it a try.
> 
> > 2. Even if it is somehow possible to do the above point (1), I would need
> > to check the various object_types, as you mentioned already (instanceof)
> > in the code snippet and then do certain things. If we do some generic
> > operations via reflection on the newly created object, then its not too
> > bad.But for specific object manuplation, every_possible_object_type check
> > would not be helpful or advisible.
> 
> I'd suggest that you try the solution above before worrying about the 
> performance.  I doubt that the additional instanceof check will be 
> noticable next the the rest of the costs of the reflective call.
> 
> > 3. The same needs to be done for Method.invoke(), as they would also be
> > left (if called via reflection).
> 
> Sure, or you can use method execution joinpoints instead.  Unless you're 
> looking for information that is only available at the call-site, or if 
> you need the special functionality of replacing the object that is 
> returned from a constructor, then there is no reason not to use 
> execution joinpoints.
> 
> -Jim
> 
> 
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users
-- 
  Tarun Sharma
  t_sharma@xxxxxxxxxxxx

-- 
http://www.fastmail.fm - Choose from over 50 domains or use your own


Back to the top