Re: [aspectj-users] AspectJ 1.9.0 released

[Brett Randall]

Thanks Andy for all your hard work on this release (and all the previous
ones!).

Brett

On 3 April 2018 at 05:55, Andy Clement  wrote:

> AspectJ 1.9.0 is finally released, after multiple betas and release
> candidates.  The README can be found here:
> https://eclipse.org/aspectj/doc/released/README-190.html - thanks to
> everyone in the community who provided feedback, sample code and test cases
> to iron out as many issues as possible.
>
> The key changes in 1.9.0:
> - primary change is that it supports compiling/weaving Java 9 code/modules.
> - some new APIs have been added to the runtime jar, these are used by the
> generated code when building join points. It should reduce the amount of
> class loading done at runtime. If you try it out (you need to turn on a
> flag to try it out), any feedback is welcome!
> - Incorporates the Spring AOP improvements that were made in recent 1.8.X
> releases.
>
> It should appear in central in the next day or so.
>
> cheers,
> Andy
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Missing stackmap generation for woven code

[Brett Randall]

Maybe if you can post your POMs some Maven guru can help you out.

On 7 October 2017 at 06:55, Eric B  wrote:

> I'm running into a problem with AspectJ 1.8.10, and not sure how to
> resolve this.
>
> I have a multi-module maven build.  One of my modules requires running an
> ant task (using the antrun-maven-plugin) with the jvm -noverify flag.
> Consequently, I run the entire maven build using the -noverify flag.
>
> However, my last module in my build is an AspectJ module.  When I try to
> compile it using the aspectj-maven-plugin, I get the following error thrown:
>
> [ERROR] Failed to execute goal 
> org.codehaus.mojo:aspectj-maven-plugin:1.10:compile
> (default) on project adams-aspects: AJC compiler errors:
> [ERROR] abort ABORT -- (BCException) Unable to find Asm for stackmap
> generation (Looking for 'aj.org.objectweb.asm.ClassReader'). Stackmap
> generation for woven code is required to avoid verify errors on a Java 1.7
> or higher runtime
> [ERROR] when weaving type webapp.tiles.AthleteBasedForm
> [ERROR] when weaving classes
> [ERROR] when weaving
> [ERROR] when batch building BuildConfig[null] #Files=8 AopXmls=#0
> [ERROR]
>
>
> So I'm a bit in a bind.  I can't figure out any way to reconcile both
> requirements - that module1 needs to run a plugin with the -noverify
> parameter, and the aspectj plugin that needs to run it without.
>
> Is there anyway I can disable the need for the stackmap generation to
> exist in AJ 1.8.10?  I've looked for parameters I can pass to ajc but can't
> find any.
>
> Thanks,
>
> Eric
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] AspectJ Maven plugin 1.9 was released and solves Eclipse problem from 1.8

[Brett Randall]

Nice one Alexander.

On 4 December 2016 at 21:58, Alexander Kriegisch 
wrote:

> Hello AspectJ community.
>
> Intrigued by several people reporting problems importing/refreshing
> Eclipse projects when using AspectJ Maven plugin 1.8 on StackOverflow and
> in the plugin's GitHub bug tracker, I snooped around in the source code. I
> managed to fix the problem. My pull request [1] was finally merged and is
> contained in the new plugin version 1.9 [2]. Just upgrade your POM and
> enjoy using the latest AspectJ Maven plugin in Eclipse again.
>
> P.S.: IMO the real problem is in Eclipse, but it was easier to put a
> workaround into the Maven plugin than to get it fixed upstream. If anyone
> (maybe Andy Clement or Andrew Eisenberg?) would take care of getting the
> root cause fixed in Eclipse it would be nice.
>
> [1] https://github.com/mojohaus/aspectj-maven-plugin/pull/19
> [2] https://mvnrepository.com/artifact/org.codehaus.mojo/
> aspectj-maven-plugin/1.9
>
> Best regards
> --
> Alexander Kriegisch
> https://scrum-master.de
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Behaviours of new constructor added by AspectJ ITD

[Brett Randall]

Thanks Andy, best explanation ever of Java field initialization as it
relates to AspectJ.
 On 23/07/2013 8:15 AM, Andy Clement andrew.clem...@gmail.com wrote:

 Some background on Q1:

 public class Child {

 public String name = John;

 public Child(String desc) {
 }

 public Child(int bar) {
 }
 }

 When this code is compiled the bytecode to set name to 'John' is included
 in every constructor within the class (without anything to mark that
 bytecode as existing due to field initialization). It isn't put into some
 other static 'initializer' method that can be invoked separately:

   public Child(java.lang.String);
 Code:
   stack=2, locals=2, args_size=2
  0: aload_0
  1: invokespecial #1  // Method
 java/lang/Object.init:()V
  4: aload_0
  5: ldc   #2  // String John
  7: putfield  #3  // Field
 name:Ljava/lang/String;
 10: return

   public Child(int);
 Code:
   stack=2, locals=2, args_size=2
  0: aload_0
  1: invokespecial #1  // Method
 java/lang/Object.init:()V
  4: aload_0
  5: ldc   #2  // String John
  7: putfield  #3  // Field
 name:Ljava/lang/String;
 10: return

 When we separately compile the aspect, we have no idea which bytecode we
 might need to copy from existing constructors to initialize fields. In your
 case you are compiling the source for the target and the source for the
 aspect together so in compiling the aspect we could look at the target
 source, but a guiding principal of AspectJ is that separate compilation
 works the same as 'altogether' compilation so whether the aspect is
 compiled with the target sources or against the bytecode for that target,
 it must do the same thing. This means if information cannot be determined
 from the bytecode, we just don't know it.

 Andy



 On 17 July 2013 06:12, pai pika...@gmail.com wrote:

 Hi thanks! so it seems for Q1, it's apsecJ's limitation.

 Thank you for the information :)

 I'll post Q2 question in another thread.

 Regards!



 --
 View this message in context:
 http://aspectj.2085585.n4.nabble.com/Behaviours-of-new-constructor-added-by-AspectJ-ITD-tp4651015p4651028.html
 Sent from the AspectJ - users mailing list archive at Nabble.com.
 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users



 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users


___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] JoinPoint.getArgs() in multiple aspects on same joinpoint

[Brett Randall]

I also don't know how you can bind the complete set of arguments for
any/all method signatures.  It might be a decent enhancement-request -
others on the list may know whether access this has been previously
proposed.

For completeness, I believe that the fix for
https://bugs.eclipse.org/bugs/show_bug.cgi?id=67592 resulted in the
array-copy for args, ensuring all advice sees the same args at the
join-point (provided of course that a state-changing method is not
called on one of the array members).

Brett

On 15 April 2013 12:42, Jay Roberts puda...@gmail.com wrote:
 Hi Brett,

 Thanks for the links and the response.  I had come across that discussion, 
 but it still didn't meet my needs.

 I understand the logic of getArgs returning the original passed args, those 
 semantics makes sense.

 But what I can't do is have something like  args(..) in the pointcut and bind 
 to the entire set of arguments.  We don't need just one or two of them, we 
 need all of them brought into scope and bound then so that downstream aspects 
 may act upon what changes we may make.

 The usage of our aspects are across a wide array of method signatures and we 
 want to examine all of them via reflection, etc, making decisions about what 
 to do for each based upon a number of factors.  We don't know which of the 
 params will need modification, replacement in advance, so we would have to 
 write a whole bunch of point cuts to try to cover this.

 Something that would let us bind to all the arguments as, say, an object array

 @Around(execution( @anno * *(..)  args(..))
 public Object myAdvice(ProceedingJoinPoint jp, Object[] args){
  …….
 }

 Or, and it would be useful, the ability for an aspect to access, at least in 
 a read only way, the current state of the closure - if it needs to be 
 modified, jp.proceed(Object[]) already takes care of that.  That would 
 actually allow trailing aspects to understand not just what arguments were 
 originally passed to the method, but what ones the closure is going to 
 actually execute on and do this comprehensively for all arguments.  It seems 
 like that is very relevant information for certain aspects, at least in my 
 limited experience.

 So I appreciate sending on those links, but they really don't help with this 
 situation.

 I did come up w/a very clunky workaround for our stuff, but I'm thinking that 
 maybe I'll go back and write an aspect on JoinPointImpl that exposes the 
 information that we need in our downstream aspects and allows us to have 
 concise code for upstream aspect.

 Again, thanks for the response, I think AspectJ is terrifically cool, I've 
 used it on and off over the years, great stuff.

 Best,

 Jay Roberts

 Seems like a natural extension of
 On Apr 14, 2013, at 10:00 PM, Brett Randall javabr...@gmail.com wrote:

 Jay,

 This was asked not so long ago on the list - it should be added to a
 FAQ if it is not already there, and perhaps justifies a JavaDoc
 clarficiation.

 See also:

 http://aspectj.2085585.n4.nabble.com/Modifying-parameters-in-more-than-one-aspect-providing-around-advice-td4650584.html
 http://stackoverflow.com/questions/12843998/modifying-parameters-in-more-than-one-aspect-providing-around-advice

 The behaviour you are seeing is expected, but perhaps not obvious.
 They key is that JoinPoint.getArgs() only returns a _copy_ of the
 _original_ method arguments at the join-point.  So modifying them in a
 prior aspect and/or reading them in a subsequent aspect will not do
 what you want.

 As mentioned by Alexander on the other thread and per his
 code-example, you cannot use getArgs() to do what you want - you need
 to instead bind arguments using args() in your pointcut, and then
 access the arguments via the formal parameter instead of getArgs(),
 e.g. in your FirstAspect:

 @Pointcut(execution(@SomeAnnotation * *.foo(..))  args(myArg))
 public void anyFoo(Object myArg) {}

 @Around(anyFoo(myArg))
 public Object doAdvice(ProceedingJoinPoint jp, Object myArg) throws 
 Throwable{
  // ...
  if (myArgs instanceof BadArg) {
System.out.println(replaced BadArg);
myArg = new GoodArg();
  }
  return jp.proceed(new Object[] {myArg});
 }

 .. then in your SecondAspect, bind myArg in the same fashion to read
 the replaced argument.  This should make the code work in the way you
 expect.

 Brett


 On 14 April 2013 16:35, Jay Roberts puda...@gmail.com wrote:
 Hi,

 I have a situation where I have several possibly cascading Around advices 
 as simplified below.

 @Aspect
 @Precedence(FirstAspect, *)
 class FirstAspect{
@Around(execution(@SomeAnnotation * *.foo(..)))
public Object doAdvice(ProceedingJoinpoint jp) throws Throwable{
Object [] args = jp.getArgs();
for(int i=0;iargs.length : i++){
if(args[i] instanceof BadArg){
args[i] = new GoodArg();
}
}
jp.proceed(args

Re: [aspectj-users] JoinPoint.getArgs() in multiple aspects on same joinpoint

[Brett Randall]

Jay,

This was asked not so long ago on the list - it should be added to a
FAQ if it is not already there, and perhaps justifies a JavaDoc
clarficiation.

See also:

http://aspectj.2085585.n4.nabble.com/Modifying-parameters-in-more-than-one-aspect-providing-around-advice-td4650584.html
http://stackoverflow.com/questions/12843998/modifying-parameters-in-more-than-one-aspect-providing-around-advice

The behaviour you are seeing is expected, but perhaps not obvious.
They key is that JoinPoint.getArgs() only returns a _copy_ of the
_original_ method arguments at the join-point.  So modifying them in a
prior aspect and/or reading them in a subsequent aspect will not do
what you want.

As mentioned by Alexander on the other thread and per his
code-example, you cannot use getArgs() to do what you want - you need
to instead bind arguments using args() in your pointcut, and then
access the arguments via the formal parameter instead of getArgs(),
e.g. in your FirstAspect:

@Pointcut(execution(@SomeAnnotation * *.foo(..))  args(myArg))
public void anyFoo(Object myArg) {}

@Around(anyFoo(myArg))
public Object doAdvice(ProceedingJoinPoint jp, Object myArg) throws Throwable{
  // ...
  if (myArgs instanceof BadArg) {
System.out.println(replaced BadArg);
myArg = new GoodArg();
  }
  return jp.proceed(new Object[] {myArg});
}

.. then in your SecondAspect, bind myArg in the same fashion to read
the replaced argument.  This should make the code work in the way you
expect.

Brett


On 14 April 2013 16:35, Jay Roberts puda...@gmail.com wrote:
 Hi,

 I have a situation where I have several possibly cascading Around advices as 
 simplified below.

 @Aspect
 @Precedence(FirstAspect, *)
 class FirstAspect{
 @Around(execution(@SomeAnnotation * *.foo(..)))
 public Object doAdvice(ProceedingJoinpoint jp) throws Throwable{
 Object [] args = jp.getArgs();
 for(int i=0;iargs.length : i++){
 if(args[i] instanceof BadArg){
 args[i] = new GoodArg();
 }
 }
 jp.proceed(args);
 }
 }

 @Aspect
 class SecondAspect{
 @Around(execution(@SomeAnnotation * *(..)))
 public Object doAdvice(ProceedingJoinpoint jp) throws Throwable{
 Object [] args = jp.getArgs();
 // Gets the same args as returned from jp.getArgs() in 
 FirstAspect,
 // not the modified ones.

 …. do something but have BadArg instead of GoodArg…..

 jp.proceed();
 }
 }

 FirstAspect may or may not appear before SecondAspect, SecondAspect is 
 narrower.  I traced through the aspectj source and debugger, and I saw that 
 both FirstAspect and SecondAspect have the same join point, whose args remain 
 the original args passed in the target method call.  The args passed in to 
 proceed I see go into state for the AroundClosures and the ones modified in 
 FirstAspect do make it to the target method foo.  FirstAspect is correctly 
 executing before SecondAspect.

 I also see that JoinPoint.getArgs returns a copy of args rather than a 
 reference.  And I've read a whole bunch on the web about binding args inside 
 the join point using args.  However, this binding requires some name/pattern, 
 and both FirstAspect, SecondAspect match to any method params (..).

 So how can I modify things such that downstream aspects of FirstAspect will 
 get the modified args passed by FirstAspect to JoinPoint.proceed?  Is there a 
 way in the advice matching to bind to args(..) so I can get it as a reference 
 in FirstAspect?  Or, can SecondAspect somehow get the AroundClosure state so 
 it can look at those rather than JoinPoint.getArgs()?

 In the meantime, I've just setup a globally accessible 
 ThreadLocalMapJoinPoint, Object[] variable that aspects (possibly) 
 downstream of FirstAspect can lookup modified args and use those if they 
 exist rather than the JoinPoint.getArgs().  This is pretty clunky workaround 
 for the moment, I feel I am really missing something here.

 Any help would be appreciated.

 Thanks1

 Jay Roberts
 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Memory problem when using aspectj

[Brett Randall]

Might be worth a quick test with increased perm gen space, in case you
are running out:

-XX:MaxPermSize=512m

Best
Brett

On 22 January 2013 10:25, Aryenne Bradshaw aryen...@hotmail.com wrote:
 Hi Users,
 This is my first time to the forum.  I am really desperate for some help.  I
 have a project running on Java 1.7 and ajc 1.7.1 on a windows 7 machine 64
 bit.
 Everything compiles correctly.  However, when I try to run the project this
 is the error message (and there is no error log):

 [error] AspectJ 1.7.1 ran out of memory during compilation:

 Please increase the memory available to ajc by editing the ajc script

 found in your AspectJ installation directory. The -Xmx parameter value

 should be increased from 64M (default) to 128M or even 256M.

 See the AspectJ FAQ available from the documentation link

 on the AspectJ home page at http://www.eclipse.org/aspectj
 SUGGESTED SOLUTIONS ALREADY TRIED:
 1.  i  have increased the value of the ajc Xmx parameter from 64M to 1024M
 (and even 4096M)
 2. I have set -Xset:minimalModel=true  -Xset:typeDemotion=true

 The problem exits even if I run the project in eclipse or on the command
 prompt I get the same error.  The project runs with small test files but if
 I try to use larger test files I get the error above.  Any help will be
 greatly appreciated.  I am now at my witts end.
 Thank you.

 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] context information in aspect fields

[Brett Randall]

Hi,

It may or may not be useful to you, but the Perf4j project[1] uses
AspectJ to instrument code with stopwatches, providing generic
around-method timing via an @Profiled annotation.  There's also an
unreleased enhancement in github which allows methods to be timed
without annotating them (by completing an abstract pointcut), so no
source-changes requires.

Best
Brett

[1] http://perf4j.codehaus.org/

On 6 November 2012 21:29, Reik Schatz reik.sch...@gmail.com wrote:
 Hi,

 I am working on a timer example using AspectJ similar to this logging
 example:
 http://adamgent.com/post/5479576926/the-python-decorator-pattern-for-java-using-aspectj

 However the Timer (not Logger) I am using takes among others a String
 argument which describes the context of the place where you are timing (i.e.
 if you are timing a save method in a DAO class, the argument would be
 save). Now that the Timer is defined in the Aspect, is it possible to
 retrieve some context information outside of the pointcut or advice
 definition? Ideally I want to do something like:

 public aspect TimedAspect {

 private final Timer TIMER = Metrics.newTimer(getClass(), TARGET METHOD
 NAME HERE);

 pointcut timedExecution() : execution(@Timed * * (..)); // execution of
 a annotated method

 Object around() : timedExecution() {
 final TimerContext context = TIMER.time();
 try {
 return proceed();
 } finally {
 context.stop();
 }
 }
 }

 For me it looks like the only way is to create the Timer object inside the
 advice and use the context information available.

 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] Git mirror?

[Brett Randall]

Hi,

I believe that the AspectJ source repository is in Eclipse CVS, and
that there isn't a Git migration [1], but I also couldn't spot a Git
CVS mirror [2].  Is there one, or if not could we request a mirror?

Thanks
Brett

[1] http://git.eclipse.org/c/
[2] http://dev.eclipse.org/git/index.html
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Git mirror?

[Brett Randall]

Fantastic, thanks Andy.  It would be great if you could announce on
this list when the Git repo is available.  Perhaps the GitHub Eclipse
team will also mirror a clone there too.

Thanks
Brett

On Tue, Nov 8, 2011 at 3:56 AM, Andy Clement andrew.clem...@gmail.com wrote:
 All the eclipse projects have to move to git in the relatively near
 term, so I'd probably just do that instead.  When I get a few minutes
 I'll kick that process off.

 Andy

 On 7 November 2011 02:30, Brett Randall javabr...@gmail.com wrote:
 Hi,

 I believe that the AspectJ source repository is in Eclipse CVS, and
 that there isn't a Git migration [1], but I also couldn't spot a Git
 CVS mirror [2].  Is there one, or if not could we request a mirror?

 Thanks
 Brett

 [1] http://git.eclipse.org/c/
 [2] http://dev.eclipse.org/git/index.html
 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Aspectj 1.6.12 in a maven repository

[Brett Randall]

Thanks Andy.

On Thu, Oct 27, 2011 at 8:39 AM, Andy Clement andrew.clem...@gmail.com wrote:
 :) It is the greatest, but not yet in central.  I'll do it very soon
 and post here when it is done.

 Andy

 On 26 October 2011 08:34, Jean-Francois Croteau jfcrot...@8d.com wrote:
 Can someone point me to a Maven repository that contains the latest (and I 
 hope the greatest) version of aspectj 1.6.12?


 Jean-Francois Croteau
 jfcrot...@8d.com
 Développeur Java

 8D Technologies Inc.
 http://www.8D.com/

 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] LTW fail hard/fast options (for testing)

[Brett Randall]

Thanks Andy, your comments are spot-on.

I did end up implementing a local IMessageHandler so I could throw
something like an AssertionError.  It didn't give me exactly what I
was after, but it does improve the visibility of the test failure.

The main issue is a combination of the LTW timing issue you allude to,
as well as the way JUnit works. At the time the classes are
loaded/weaved, there are of course no actual tests executing, it's
before that time.  So it's not a simple matter of throwing an
exception - in fact, JUnit seemed happy to continue to launch the test
suite even when an unchecked exception was thrown.  Of course the
custom IMessageHandler can easily store high-priority weaver messages
and then we can make an assertion on it in test(s).

Thanks
Brett

On Mon, Oct 24, 2011 at 8:53 AM, Andy Clement andrew.clem...@gmail.com wrote:
 Right now perhaps the option you have here is -XmessageHandlerClass
 which is supplied the classname of a type implementing IMessageHandler
 - so you can then do what you want for any message that comes out.  I
 guess you could use the type name of the THROW class if you wish,
 likely to be something like org.aspectj.bridge.IMessageHandler$1 (as
 a workaround for it being non 'top-level' at the moment).

 I think I raised a bugzilla already for another approach I was
 thinking of, where you annotated the advice/pointcut with expectations
 (I expect it to match X number of times) and errors will be thrown if
 the expectation isn't met.  This is more straightforward with compile
 time weaving though as you know when that has finished - it isn't so
 obvious in LTW when it has reached the point where the expectation
 should have been met. (there may still be more types to be loaded).

 cheers,
 Andy

 On 22 October 2011 20:54, Brett Randall javabr...@gmail.com wrote:
 Hi,

 When unit testing aspects and advised test/tested code (as opposed to
 deploy/runtime, where this option wouldn't make sense), it would be
 nice to be able to instruct the weaver to throw some sort of unchecked
 Exception or Error if there are configuration problems with error
 severity or higher.  Does such an option exist - I couldn't see it in
 the LTW weaver options?

 This would allow unit tests to fail-fast in the case of a LTW
 configuration error, and could help clarify the cause of the failure.
 Some pre-existing unit tests I'm currently working with picked up some
 weaving issues during development e.g. a typo in a pointcut, and the
 program continues to execute, and to establish the cause of the unit
 test fail you need to read the weaver verbose console messages to find
 the problem, whereas an exception would be clearer.

 Has anything like this ever been considered - would it be feasible and
 worthwhile?

 Thanks
 Brett
 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] LTW fail hard/fast options (for testing)

[Brett Randall]

Hi,

When unit testing aspects and advised test/tested code (as opposed to
deploy/runtime, where this option wouldn't make sense), it would be
nice to be able to instruct the weaver to throw some sort of unchecked
Exception or Error if there are configuration problems with error
severity or higher.  Does such an option exist - I couldn't see it in
the LTW weaver options?

This would allow unit tests to fail-fast in the case of a LTW
configuration error, and could help clarify the cause of the failure.
Some pre-existing unit tests I'm currently working with picked up some
weaving issues during development e.g. a typo in a pointcut, and the
program continues to execute, and to establish the cause of the unit
test fail you need to read the weaver verbose console messages to find
the problem, whereas an exception would be clearer.

Has anything like this ever been considered - would it be feasible and
worthwhile?

Thanks
Brett
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] LTW fail hard/fast options (for testing)

[Brett Randall]

I have now found static/inner IMessageHandler IMessageHandler.THROW,
which seems to be on the right track and what I need.  Do I need to
reproduce this in my test code, or could we promote the THROW instance
to a public class?

Thanks
Brett

On Sun, Oct 23, 2011 at 2:54 PM, Brett Randall javabr...@gmail.com wrote:
 Hi,

 When unit testing aspects and advised test/tested code (as opposed to
 deploy/runtime, where this option wouldn't make sense), it would be
 nice to be able to instruct the weaver to throw some sort of unchecked
 Exception or Error if there are configuration problems with error
 severity or higher.  Does such an option exist - I couldn't see it in
 the LTW weaver options?

 This would allow unit tests to fail-fast in the case of a LTW
 configuration error, and could help clarify the cause of the failure.
 Some pre-existing unit tests I'm currently working with picked up some
 weaving issues during development e.g. a typo in a pointcut, and the
 program continues to execute, and to establish the cause of the unit
 test fail you need to read the weaver verbose console messages to find
 the problem, whereas an exception would be clearer.

 Has anything like this ever been considered - would it be feasible and
 worthwhile?

 Thanks
 Brett

___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] 1.6.11 push to Maven Central?

[Brett Randall]

Thanks Andy, but I'll look into proxying the springframework repo if
that's recommended, I wasn't aware of it.

Brett

On Tue, May 17, 2011 at 12:53 AM, Andy Clement andrew.clem...@gmail.com wrote:
 I'll try to get to it soon.  I just find it so much easier to publish
 to our springframework repository than the central one.

 Andy

 On 15 May 2011 17:29, Brett Randall javabr...@gmail.com wrote:
 Hi,

 1.6.11 was final in March, but I believe that 1.6.10 is the latest
 available in Maven Central.  Is there a separate push step for the
 release and can we run it?

 http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.aspectj%22%20AND%20a%3A%22aspectjrt%22

 Thanks
 Brett
 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] IDE support for 'privileged' modifier

[Brett Randall]

Thanks Andrew.  Also logged
https://bugs.eclipse.org/bugs/show_bug.cgi?id=346017 for the
content-assist.

Brett

On Mon, May 16, 2011 at 6:17 PM, Andrew Eisenberg and...@eisenberg.as wrote:
 Thanks for that.  We don't actually have any unit tests for the new
 aspect wizard, so this may not have been working for some time now.

 I raised https://bugs.eclipse.org/bugs/show_bug.cgi?id=345883 to track this.

 On Mon, May 16, 2011 at 6:36 AM, Brett Randall javabr...@gmail.com wrote:
 I enabled AspectJ tooling on a project in Eclipse, then I needed to
 create a new Aspect with 'privileged' modifier.  I think I notice two
 things:

 1) Checking the 'privileged' modifier checkbox in the new aspect
 wizard didn't result in the privileged keyword/modifier in my new
 Aspect file.
 2) When I went to add it in the editor, it wasn't supported as a
 content assist editor suggestion after typing p-CTRL-SPACE.

 For 2) I found [1], but I accept that content-assist won't find
 private methods, but I thought it might offer the actual keyword in
 the aspect declaration.

 Anyone else confirm these, are they unreported to-date?

 Plugin-spy data:

 The active wizard class:
 NewAspectCreationWizard
 The contributing plug-in:
 org.eclipse.ajdt.ui (2.1.3.e36x-20110315-1000)

 The active page class:
 NewAspectWizardPage
 The contributing plug-in:
 org.eclipse.ajdt.ui (2.1.3.e36x-20110315-1000)

 The active editor class:
 AspectJEditor
 The contributing plug-in:
 org.eclipse.ajdt.ui (2.1.3.e36x-20110315-1000)
 The active editor identifier:
 org.eclipse.ajdt.internal.ui.editor.CompilationUnitEditor
 The active menu contribution identifiers:
 org.eclipse.ajdt.internal.ui.editor.CompilationUnitEditor.EditorContext
 #AbstractTextEditorContext
 #CompilationUnitEditorContext
 #AbstractTextEditorRulerContext
 #AJCompilationUnitRulerContext
 org.eclipse.ajdt.internal.ui.editor.CompilationUnitEditor.RulerContext
 #OverviewRulerContext


 Cheers
 Brett

 [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=263556
 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] 1.6.11 push to Maven Central?

[Brett Randall]

Hi,

1.6.11 was final in March, but I believe that 1.6.10 is the latest
available in Maven Central.  Is there a separate push step for the
release and can we run it?

http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.aspectj%22%20AND%20a%3A%22aspectjrt%22

Thanks
Brett
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] IDE support for 'privileged' modifier

[Brett Randall]

I enabled AspectJ tooling on a project in Eclipse, then I needed to
create a new Aspect with 'privileged' modifier.  I think I notice two
things:

1) Checking the 'privileged' modifier checkbox in the new aspect
wizard didn't result in the privileged keyword/modifier in my new
Aspect file.
2) When I went to add it in the editor, it wasn't supported as a
content assist editor suggestion after typing p-CTRL-SPACE.

For 2) I found [1], but I accept that content-assist won't find
private methods, but I thought it might offer the actual keyword in
the aspect declaration.

Anyone else confirm these, are they unreported to-date?

Plugin-spy data:

The active wizard class:
NewAspectCreationWizard
The contributing plug-in:
org.eclipse.ajdt.ui (2.1.3.e36x-20110315-1000)

The active page class:
NewAspectWizardPage
The contributing plug-in:
org.eclipse.ajdt.ui (2.1.3.e36x-20110315-1000)

The active editor class:
AspectJEditor
The contributing plug-in:
org.eclipse.ajdt.ui (2.1.3.e36x-20110315-1000)
The active editor identifier:
org.eclipse.ajdt.internal.ui.editor.CompilationUnitEditor
The active menu contribution identifiers:
org.eclipse.ajdt.internal.ui.editor.CompilationUnitEditor.EditorContext
#AbstractTextEditorContext
#CompilationUnitEditorContext
#AbstractTextEditorRulerContext
#AJCompilationUnitRulerContext
org.eclipse.ajdt.internal.ui.editor.CompilationUnitEditor.RulerContext
#OverviewRulerContext


Cheers
Brett

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=263556
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Setup older compiler/runtime (1.6.8, v6 attributes) in Eclipse

[Brett Randall]

Hi Andy,

Thanks for the reply.

I ended up applying the same solution as another poster on your blog,
using Maven and the aspectj-maven-plugin, overriding the plugin's
dependency to put the older version of ajc on its classpath.  This
works fine, and together with m2eclipse provides a good developer
experience.  I'm already familiar with Maven so it was easy enough to
make this work.

Thanks
Brett

On Sat, Apr 30, 2011 at 1:40 AM, Andy Clement andrew.clem...@gmail.com wrote:
 Hi Brett,

 There is no HOWTO on doing that, I'm afraid.  Although in terms of
 packaging it is straightforward (a variant of just copying the three
 main aspectj jars into three AJDT plugins), the interfaces between
 AspectJ and AJDT have continued to evolve and you are very likely to
 hit something like an abstractmethoderror. However, if you really want
 to try it, shutdown eclipse then copy aspectjtools.jar (from an
 installed 1.6.8) as ajde.jar in the org.aspectj.ajde plugin.  Copy
 aspectjweaver.jar into org.aspectj.weaver and aspectjrt.jar into
 org.aspectj.runtime (backup what you currently have before overwriting
 the existing jars).

 After doing your development in eclipse, can you instead just kick off
 a build outside of eclipse (using 1.6.8) and deploy the result instead
 of directly deploying the classes that the IDE built?  I'm suggesting
 this as a way to avoid grabbing Eclipse 3.5 (and AJDT 2.0.2:
 http://download.eclipse.org/tools/ajdt/35/update/ajdt_2.0.2_for_eclipse_3.5.zip
 ).

 Andy

 On 28 April 2011 20:17, Brett Randall javabr...@gmail.com wrote:
 Hi,

 I'm using a current Eclipse version, so I've picked-up
 AspectJ/ajc1.6.11 in my development environment.  In my runtime
 environment I'm stuck with 1.6.8 for now, so as expected on deployment
 I'm seeing a v6 versus v7 version clash, per [1].  Unfortunate,
 runtime is only one revision too old for v7 attributes.

 Given I can't follow the recommendation to upgrade my runtime version,
 how difficult is it to setup my Eclipse IDE to use the 1.6.8 compiler
 (perhaps referenced externally)?  Is there a HOWTO on downgrading
 Eclipse IDE AJDT kit?  I'm hoping not to have to hunt down an older
 version of Eclipse.

 Thanks
 Brett

 [1] http://andrewclement.blogspot.com/2010/04/aspectj-169m1-message-unable-to.html
 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

 ___
 aspectj-users mailing list
 aspectj-users@eclipse.org
 https://dev.eclipse.org/mailman/listinfo/aspectj-users

___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] Setup older compiler/runtime (1.6.8, v6 attributes) in Eclipse

[Brett Randall]

Hi,

I'm using a current Eclipse version, so I've picked-up
AspectJ/ajc1.6.11 in my development environment.  In my runtime
environment I'm stuck with 1.6.8 for now, so as expected on deployment
I'm seeing a v6 versus v7 version clash, per [1].  Unfortunate,
runtime is only one revision too old for v7 attributes.

Given I can't follow the recommendation to upgrade my runtime version,
how difficult is it to setup my Eclipse IDE to use the 1.6.8 compiler
(perhaps referenced externally)?  Is there a HOWTO on downgrading
Eclipse IDE AJDT kit?  I'm hoping not to have to hunt down an older
version of Eclipse.

Thanks
Brett

[1] http://andrewclement.blogspot.com/2010/04/aspectj-169m1-message-unable-to.html
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users