Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Aspect.aspectOf() behaviour

Ill go through the blog and see what we can come up with. Using a
perInstance perClause is a given for our desgin and of yes course affects
lazyloading...
Thanks for the link,
Neil.

-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Alexandre Vasseur
Sent: 18 October 2005 10:31
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] Aspect.aspectOf() behaviour


this is not about lazy loading
this is about perClause.

perClause controls the points where the aspect(s) is/are instantiated. This
can be singleton, per target / this, per cflow, per cflow below. All except
singleton requires a pointcut that will control when the aspect is bound and
possibly unbound (per cflow / per cflow below). AspectJ 1.5 introduced per
type as well.

That said, this is true, the current AspectJ weaver will not instantiate
f.e. a singleton aspect prior it is used (ie one of its advice gets
executed). I don't think that this affects your design though.

If you have a need for controlling the aspect configuration, you should look
at Adrian Colyer blog. He describes a way to do IoC into the aspect thru
Spring.
http://www.aspectprogrammer.org/blogs/adrian/2005/03/hacking_with_ha.html

Alex


On 10/18/05, AVERY, Neil, FM <Neil.AVERY@xxxxxxxx> wrote:
> Hi Alex,
> Ive thought more about the Aspects.aspectOf behaviour..The problem 
> with lazy loading/weaving of aspects is that we cannot grab them from 
> the target instance and configure them (perInstance). Our app relies 
> on our container being able to configure aspects before the component 
> is made available for use. However, if lazy loading is applied, then 
> the component must be used
> (invoked) before the aspect is available and therefore there is no chance
> for us to configure the behaviour on the aspect. Putting in a stub, 'noop'
> method is a bit of a hack.
>
> I can see the case for lazy loading of aspects (like performance) but 
> there are also the drawbacks such as our situation where runtime 
> configuration of the aspect is required. Granted we don't do it much, 
> but it is functionality we require. When considering tools like 
> hibernate - lazyloading should be disabled when you want to keep 
> objects in a secondary level cache, the behaviour is configurable 
> depending upon how the object is used. Or spring where - lazy-init is 
> not the default (faster startup etc), but in both cases the behaviour 
> is configurable to allow for the semantics of those objects to be 
> correctly controlled.
>
> Is there any chance of making aspect lazy loading configurable - or 
> having any lookup request for an aspect cause weaving to take place?
>
> Cheers Neil.
>
> -----Original Message-----
> From: aspectj-users-bounces@xxxxxxxxxxx 
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Alexandre 
> Vasseur
> Sent: 17 October 2005 15:16
> To: aspectj-users@xxxxxxxxxxx
> Subject: Re: [aspectj-users] Aspect.aspectOf() behaviour
>
>
> yes it still apply
> for such a thing I think you need a facade aspect with your own map 
> instance(target and/or this) -> aspect instance Alex
>
> On 10/17/05, AVERY, Neil, FM <Neil.AVERY@xxxxxxxx> wrote:
> >
> > (Sorry Alex - this was sent to the wrong mailing list) - does the 
> > same still apply? We are using the latest stable aspectJ build 
> > (20051015) -Neil
> >
> > -----Original Message-----
> > From: AVERY, Neil, FM
> > Sent: 17 October 2005 14:24
> > To: 'user@xxxxxxxxxxxxxxxxxxxxxxxx'
> > Subject: Aspect.aspectOf() behaviour
> >
> >
> > All,
> > If I apply a 'perTarget' Aspect to a object and call 
> > Aspects.aspectOf(SimpleAroundAspect.class, testClass) then I get an 
> > exception, NoAspectBound...(see below)
> >
> > However, if a prior invocation has occured then Aspects.aspectOf(..) 
> > will return the Aspect that was bound....
> >
> > Ideally I would like to get access to an aspect bound to the object 
> > instance regardless of whether or not it has been invoked. Is it 
> > possible to determine/control the behaviour as its the kind of thing 
> > that will affect component lifecycle when interacting with 
> > aspects...?
> >
> > Cheers Neil.
> >
> > TEST:
> >  public void testDifferendAspectInstanceGetsApplied()
> > throws Exception {
> >
> >   TestClass testClass = new TestClass();
> > >>>//  testClass.doStuff();
> >
> >   Object aspect1 = Aspects.aspectOf(SimpleAroundAspect.class,
> > testClass);  } }
> > THROWS:
> > org.aspectj.lang.NoAspectBoundException: Exception while 
> > initializing org.stuff.SimpleAroundAspect: 
> > java.lang.reflect.InvocationTargetException
> >  at org.aspectj.lang.Aspects.aspectOf(Aspects.java:66)
> >  at
> >
> org.stuff.aspectof.SimpleAspectTest.testDifferendAspectInstanceGetsApp
> lied(S
> impleAspectTest.java:27)
> >  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> >  at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:39
> )
> >  at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> orImpl
> .java:25)
> >  at java.lang.reflect.Method.invoke(Method.java:585)
> >  at junit.framework.TestCase.runTest(TestCase.java:154)
> >  at junit.framework.TestCase.runBare(TestCase.java:127)
> >  at
> > junit.framework.TestResult$1.protect(TestResult.java:106)
> >  at
> > junit.framework.TestResult.runProtected(TestResult.java:124)
> >  at junit.framework.TestResult.run(TestResult.java:109)
> >  at junit.framework.TestCase.run(TestCase.java:118)
> >  at
> >
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(Remote
> TestRu
> nner.java:478)
> >  at
> >
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestR
> unner.
> java:344)
> >  at
> >
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTest
> Runner
> .java:196)
> > Caused by: java.lang.reflect.InvocationTargetException
> >  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> > Method)
> >  at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:39
> )
> >  at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> orImpl
> .java:25)
> >  at java.lang.reflect.Method.invoke(Method.java:585)
> >  at org.aspectj.lang.Aspects.aspectOf(Aspects.java:63)
> >  ... 14 more
> > Caused by: org.aspectj.lang.NoAspectBoundException
> >  at
> > org.stuff.SimpleAroundAspect.aspectOf(SimpleAroundAspect.java:1)
> >  ... 19 more
> >
> > ASPECT:
> > package org.stuff;
> >
> > import org.aspectj.lang.ProceedingJoinPoint;
> > import org.aspectj.lang.annotation.*;
> >
> > @Aspect("pertarget(call(* org.stuff.TestClass.*(..)))") public class 
> > SimpleAroundAspect {  public static int callCount = 0;
> >
> >   @Around("call(* org.stuff.TestClass.*(..))")
> >   public Object invoke(ProceedingJoinPoint thisJoinPoint) throws 
> > Throwable {
> >
> >    System.err.println("called onto SimpleAroundAspect count:" +
> > callCount++);
> >    return thisJoinPoint.proceed();
> >   };
> > }
> >
> >
> >
> >
> >
> >
> > ********************************************************************
> > **
> > *************
> >  The Royal Bank of Scotland plc. Registered in Scotland No 90312.
> Registered
> > Office: 36 St Andrew Square, Edinburgh EH2 2YB.
> >  Authorised and regulated by the Financial Services Authority
> >
> >  This e-mail message is confidential and for use by the  addressee 
> > only. If the message is received by anyone other  than the 
> > addressee, please return the message to the sender  by replying to 
> > it and then delete the message from your  computer. Internet e-mails 
> > are not necessarily secure. The  Royal Bank of Scotland plc does not 
> > accept responsibility for  changes made to this message after it was 
> > sent.
> >
> >  Whilst all reasonable care has been taken to avoid the  
> > transmission of viruses, it is the responsibility of the recipient 
> > to  ensure that the onward transmission, opening or use of this  
> > message and any attachments will not adversely affect its  systems 
> > or data. No responsibility is accepted by The Royal  Bank of 
> > Scotland plc in this regard and the recipient should carry  out such 
> > virus and other checks as it considers appropriate.  Visit our 
> > websites at:  http://www.rbs.co.uk/CBFM  http://www.rbsmarkets.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
> _______________________________________________
> 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