Hi Andy, Thank you for the complete response on ‘cflow’ and ‘if(..)'. I really liked both ideas of the LTW and the DummyAuthenticator.
I liked the second suggestion more. Actually my aspect was delegating the work to the another class.That’s why I thought the second solution was more fitting to my base code. Thank you very much for the help. Cheers On Apr 24, 2014, at 12:03 AM, Andy Clement <[email protected]> wrote: > > ‘cflow’ might have performance problems. Is that true? > > Not really, certainly no worse than if you did it by hand. There is no > special magic here. Consider this point cut: > > execution(* foo(..)) && cflow(execution(* bar(..)) > > the woven code would look like this (the ajc$ related code is created by the > weaving process) > ... > public void bar() { > ajc$threadlocalcounter++; > try { > foo(); > } finally { > ajc$threadlocalcounter--; > } > } > ... > public void foo() { > if (ajc$threadlocalcounter>0) { > ajc$beforeAdvice(); > } > ... > } > > An if() test on the existence of an annotation would be tricky to craft (if > you are thinking of an if() point cut component). If you are thinking of an > if() test at the start of your advice then the code to determine the caller > and dig around for its annotation would be a nasty performance problem. > > > don’t you think that your argument about mixing the test conditions with > > 'production’ also applies here in this solution? > > Yes it does. > > Just brainstorming, but I wonder, if you had your advice call out to a > delegate method > > before(...): thisthing() { > doit(...) > } > > then when running your tests use LTW to add an extra aspect that is only > present when running the tests. > > aspect ForTesting { > void around(): execution(* doit(..)) { > // do not proceed > } > } > > This would make the doit method a no-op when run with tests. > > Simpler than that perhaps, you could have your advice forward to different > implementations of an interface depending on whether it is running within > tests: > > // my silly authentication aspect > aspect Authentication { > > public static Authenticator authenticator; > > public Authentication() { > this.authenticator = new Authenticator(); > } > > before(...): thisthing() { > authenticator.doit(); > } > > } > > and then in your tests: > > Authentication.authenticator = new MyDummyAuthenicator(); > > Where the dummy one has no-ops for doit > > just some thoughts, > Andy > > > > On 23 April 2014 04:47, Sina <[email protected]> wrote: > Hi Andy, > Thank you for the response. I’ve read somewhere (cannot remember where and > when) that ‘cflow’ might have performance problems. Is that true? I myself > was thinking of ‘if(…)’ in combination with "@Test” (If callee has that > annotation skip the Aspect code.) > > I’m doing the compile time weaving so the LTW cannot be the case for me. > What I do with my aspects is user authorization and a kind of logging which > is not important in my tests for me and is not “part of my business logic" (I > will test the aspect code and user authorization in other unit tests.) > Additionally I want to test my code off-container for which I don’t have > access to the user authentication and authorization server….. > > What you suggested about the system property is a good idea (I assume you > mean something like -DAspectJEn=true in jvm options and looking for that > value at the beginning of my aspect code) but don’t you think that your > argument about mixing the test conditions with 'production’ also applies here > in this solution? (Although this gives me the flexibility of disabling the > user authorization and those loggings in runtime if it is needed one day.) > > Cheers. > > > On Apr 22, 2014, at 2:32 AM, Andy Clement <[email protected]> wrote: > >> Well you can engineer the pointcut potentially using something like a >> 'cflow' component that makes the advice running conditional on the control >> flow it finds itself in. But then you would be introducing code that detects >> whether you are in a test into your woven code, which presumably is what you >> are going to put into 'production' - and you probably don't want that (do >> you?) >> >> If you are load time weaving you could just run the tests without the LTW >> agent in the mix. >> >> Why does the advice need to be removed? That may point to the right way to >> do it. I mean you could just do a system property check in your advice >> before the body of it executes and then pass in a system property when >> running tests... >> >> I believe people have done the maven solution you are thinking of (not >> including the aspects when building for a particular test run) but I don't >> speak enough maven to advise on how to do that. >> >> >> cheers, >> Andy >> >> >> >> >> >> On 18 April 2014 11:30, Sina <[email protected]> wrote: >> Hi there, >> >> I want to exclude aspectj codes from being executed when I unit test. What >> is the best way to do that? >> >> Manipulating my pointcut such that it does not execute when the caller has >> “@Test” annotation? >> Using maven goals and exclusion tags? (If so how exactly?) >> One note about the possible maven solution: I guess that maven solution will >> only help if "mvn test” command is run and cannot help when running the >> unit test directly (Right clicking on the test file-> Run As JUnit Test) >> >> Thanks for the help in advance. >> >> >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users >> >> >> _______________________________________________ >> aspectj-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
