gmane.comp.java.aop.aspectj.general

Load Time Weaving

trhouse — 2012-05-25T21:43:07

Hi all,

Newbie here. I just need a sanity check here on LTW. Here is what I 
think ought to happen

Given a properly constructed aspect and a properly configured and placed 
aop.xml, I can run any java program which has been compiled by regular 
old javac and have LTW apply aspects against it at runtime.


To achieve the above I have to do the all and only the following (aside 
from compiling the aspect with ajc and writing aop.xml):

make certain that the classpath for regular old java program includes:

jar://<path to aspectJ>aspectj1.6/lib/aspectjrt.jar!/
<path to compiled aspects>
<path to aop.xml containing META-INF folder>

and for VM options include:
-Djava.system.class.loader=org.aspectj.weaver.loadtime.WeavingURLClassLoader


That's pretty much it.


How am I mistaken? What am I doing wrong?

Thank you!

Re: newbie question about after returning

Andy Clement — 2012-05-25T16:02:13

Your advice works for me - are you sure you have a method that matches
it?  Here is a complete program that works:

====8<==== B.java
package com.mycom.mypack;
import org.aspectj.lang.JoinPoint;
import org.aspectj.lang.annotation.AfterReturning;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;


public class B {
public static void main(String[] argv) {
System.out.println(myclass.myMethod());
}
}

< at >Aspect
class Azpect {
< at >Pointcut("within(com.mycom.mypack.myclass)")
public void withinMyPackage() {
}

< at >AfterReturning(pointcut = "execution(public static * myMethod ( .. ))  "
+ "  && withinMyPackage() ", returning = "myResult")
public void provideAdviseAfterReturning(MyType myResult, JoinPoint jp) {
// do something with returned results
System.out.println("advice handling "+myResult);
}
}

class myclass {
public static MyType myMethod() {
return new MyType();
}
}

class MyType {
}
====8<=====
when I run it:
advice handling com.mycom.mypack.MyType< at >24a3736

Re: convert unchecked-exception to checked-exception

Andy Clement — 2012-05-25T15:57:01

There are a couple of reasons we don't do this right now:

- we aren't setup to analyze advice and work out what it is doing, we
don't know that you are translating the exception.  Ok I could special
case when the after throwing body is purely a throw, but what would I
do in this case?

          after() throwing (Exception ex) throws DSException : mypointcut() {
  if (something()) {
       throw new DSException(ex);
  } else {
       throw new OtherUncheckedException(ex);
  }
  }
that would still require the declare soft probably.

- we don't let advice affect type checking right now (we could debate
whether exception handling is type checking, but it is done at the
same time as type checking right now).  Advice is treated as an
entirely different thing from declare soft or other ITDs and
matched/woven at a different time in the build process.  When the
compiler is about to produce the message about the uncaught exception,
we have no idea that after advice may sort it out later, but we do
know t

Re: Accessing protected methods of parent classfrom within an aspect in another package

Sina — 2012-05-25T15:51:21



Yes I meant that warning.

Actually I imported the project from SVV and checked that out as "maven project".
I looked into the inpath of the project in which the child class exists. The config was right and the project in which the 
parent exists was included in the inpath (From: Maven dependencies).

The warning appears and disappears. Seems like a bug or sth. like that in Eclipse.
The main point is that the code is working!

Thank you Andy for the help. 
Sina

newbie question about after returning

Srinivas S Tamvada — 2012-05-25T15:33:47

Hi
I have a very simple point cut, but the method return does not seem to be intercepted.
Is the syntax wrong ?

Thanks !

< at >Pointcut("within(com.mycom.mypack.myclass)")
               
public void withinMyPackage() {}
 
< at >AfterReturning(pointcut = "execution(public static *
myMethod ( .. ))  " +       
"  && withinMyPackage() "
,         returning = "myResult"        
)
public void provideAdviseAfterReturning(   MyType
myResult    , JoinPoint jp ) {
 
       // do something with
returned results
 
}_______________________________________________
aspectj-users mailing list
aspectj-users< at >eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: Accessing protected methods of parent class from within an aspect in another package

Andy Clement — 2012-05-25T15:22:26

This warning you mean?
"This affected type is not exposed to the weaver: com.somewhere
(needed for privileged access [Xlint:typeNotExposedToWeaver])"

That would happen in eclipse if the configurator wasn't correctly
mapping the maven configuration into an eclipse project configuration
(presuming you are importing the project 'as maven').

When imported you need the project containing the parent on the inpath
of the child project, not the classpath (as with the maven config) -
you should be able to look under the project properties of the project
containing the child to confirm whether the config is right.

Andy

On 25 May 2012 01:36, Sina <my.linked.account< at >googlemail.com> wrote:

Re: convert unchecked-exception to checked-exception

Straub Oliver — 2012-05-25T08:38:07

Hi Andy,

thank you for your "advice". It will solve the problem.
If I use:

   declare soft : PersistException: mypointcut();

The woven code will look like that:

        try {
            try {
                throw new PersistException();
            } catch (Exception exception) {

ThrowDSExceptionAspect.aspectOf().ajc$afterThrowing$......(exception);
                throw exception;
            }
        } catch (PersistException persistexception) {
            if (persistexception instanceof RuntimeException)
                throw persistexception;
            else
                throw new SoftException(persistexception);
        }

The "declare soft"-line will do just what i need: It avoids the
unhandled-exception-error and the woven code is meaningless in this
situation.
The drop of bitterness is that i have to be very carefull with this
solution. Couldn't we have a Solution without the "declare soft"-line?
The "after() throwing" advice will catch the Persist-Exception. The
Compiler does not need t

Re: Accessing protected methods of parent classfrom within an aspect in another package

Sina — 2012-05-25T08:36:45

Hi Andy,

That worked. 
An I can now call those protected methods from the parent class and it gets compiled and the code runs.
But I still get that warning from Eclipse. 
Dont' know what's wrong with Eclipse...

cheers,
Sina
 

On May 25, 2012, at 1:07 AM, Andy Clement wrote:

Re: convert unchecked-exception to checked-exception

Andy Clement — 2012-05-24T21:40:57

Hi,

In your particular situation you could:

 declare soft : PersistException : mypointcut();

then the DSException wouldn't get softened.

I did just prototype a compiler change that would mean the woven code
looked like this:

try {
   try {
       throw new PersistException();
   } catch(Exception exception) {
      ThrowDSExceptionAspect.aspectOf().ajc$afterThrowing$com_gid_bip_dataservice_aj_ThrowDSExceptionAspect$1$e66f2abe(exception);
      throw exception;
   }
} catch(Exception exception1) {
    if(exception1 instanceof RuntimeException)
       throw exception1;
    else {
    if (exception1 instanceof DSException) { // NEW CHECK, don't wrap
if OK to throw
      throw exception1;
    } else {
       throw new SoftException(exception1);
    }
    }
}

which also appears to get you what you want.  The DSException is not
wrapped because it is declared to be thrown at the joinpoint.  This
feels like a variation of declare soft though (so maybe a syntax
variation to request this behaviour) - and I'm not

Re: Accessing protected methods of parent class from within an aspect in another package

Andy Clement — 2012-05-24T20:37:31

Hi,

This does characterise exactly what you are hitting:


The accessor needs to be added to the parent and we can't do that
because we haven't been given access to it.  And that, indeed, is what
the message is telling us:

 "This affected type is not exposed to the weaver: com.somewhere
(needed for privileged access [Xlint:typeNotExposedToWeaver])"

I can imagine a modification to the weaver that attempted to add the
accessor solely at the point in the hierarchy that needed it (so into
'Child' in my example).

But to get you going now, really, you have to provide the weaver
access to make that change to Parent.  This would involve putting the
library containing the parent on the inpath rather than the classpath.
 I think in maven terms this gets called 'weaveDependencies' in your
pom setup.  If you put the library on there that contains Parent it
will get woven into the same output folder as the current
compile/weave step and have the accessor added.

cheers,
Andy

On 24 May 2012 11:17, Sina <my.linked.acc

Re: Some Noob Design Questions

Andy Clement — 2012-05-24T20:00:09

Hi,

There isn't a right/wrong way to do it (one way isn't really 'faster'
than the other), it comes down to thinking about what your aspect is
trying to achieve.  All the interfaces you want to add are related to
'testing', perhaps you want a Testing aspect that applies everything
you need across your codebase, that would be fine.  But if your
interfaces fall into categories - like, maybe interfaces for unit
testing and interfaces for integration testing, then you might create
a UnitTesting aspect and an IntegrationTesting aspect.  Same thing
applies to the methods.  The aspect is a unit of modularization for a
crosscutting concern (like 'logging', 'profiling' or whatever) - if it
makes sense for you to think about it as one concern, then capture it
in just the one aspect.

Another (related) factor to keep in mind is will you ever want some
subset of the interfaces/methods to be applied.  If you do then you
may want to break it into multiple aspects so you can pick and choose
what gets applied on a particul

Re: Accessing protected methods of parent classfrom within an aspect in another package

Sina — 2012-05-24T18:17:44

Hi Andy,

First of all: the autocomplete function in my IDE (Eclipse 3.7.1) does not list the protected method as child's methods. (Is this the normal behavior?)
Second : when I write c.foo() in my aspect I get this warning from eclipse: 

"This affected type is not exposed to the weaver: com.somewhere (needed for privileged access [Xlint:typeNotExposedToWeaver])"
there are some differences between your config and mine.

1- Instead of exposing the Child class I'm exposing the parent class.
I don't think that should be problem, since I tried exposing both of classes in a dummy project and that has worked.

2-I'm using maven and I have different modules. My aspect and the child class are in the same maven module, but the Parent is in another module.
The output of the parent module will be provided as a jar file to the module in which the child exists. (using dependencies in pom.xml)

As it seems "ajc" can not weave the code into the parent class since it is in another project.
If this is true, do you suggest a

Some Noob Design Questions

El Lunes — 2012-05-24T10:00:44

Hallo

I am pretty new to AspectJ and I want to add interfaces to some classes. I
have to do this with AspectJ, because I need these interfaces for testing
but I am not allowed to change the code.
It was no problem to add the interfaces but I am not sure where to put the
code. Is it better to create only one aspect that adds all the interfaces
or should I use one aspect per interface?

I have the same question regarding added methods. One aspect per class or
on aspect that adds all methods to all classes?

Thanks for your help!
_______________________________________________
aspectj-users mailing list
aspectj-users< at >eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

convert unchecked-exception to checked-exception

Straub Oliver — 2012-05-24T09:06:04

Hello,
there has been long discussions on checked vs. unchecked exceptions.
I don't want to start this discussion again.

I know, the opposite behaviour can be achieved by "declare soft ..."

In my case i have to convert any exception to a layer-specific checked
exception.
This behaviour shall be controllable (on/off) with the presence of a
method-annotation.
Here an example:

  < at >DSExceptionTranslator
  private void anyMethod() throws DSException {
      throw new PersistException();
  }

Obvious the above code will normally generate an unhandled-exception-error.
I expected the following advice to solve that.

  after() throwing (Exception ex) throws DSException : mypointcut() {
      throw new DSException(ex);
  }

But the unhandled-exception-error did not disappear!

So i added a "declare soft":

  declare soft : Exception : mypointcut();

The unhandled-exception-error disappears, but this did not solve my problem
because the generated code looks like this:

try {
   try {
       throw new PersistException

Re: Use of aop.xml

Andy Clement — 2012-05-23T15:03:17

Hi,

If your aspects are 'ready to go' (i.e. non-abstract), you can just
define a trivial aop.xml that lists them:

<aspectj>
 <aspects>
  <aspect name="com.foo.MyAspect"/>
 </aspects>
</aspectj>

In face you can create that file automatically if you compile with
-outxml specified, it will create a suitable aop.xml listing all the
aspects you are compiling.

If you want to be more flexible in the wiring, it is possible to
define the pointcuts in aop.xml, and wire them to Java methods that
get treated like advice.  For example:

<aspectj>
  <aspects>
<concrete-aspect name="MyAspect">
  <before pointcut="execution(* Hello.say2(..)) AND args(message)"
   invokeClass="SomeRegularJavaClass"
   invokeMethod="someMethod(JoinPoint tjp, java.lang.String message)"/>
  <after pointcut="execution(* Hello.say2(..)) AND args(message)"
   invokeClass="SomeRegularJavaClass"
   invokeMethod="someOtherMethod(JoinPoint tjp, java.lang.String message)"/>
</concrete-aspect>
  </aspects>
</aspectj>

This kind of usage is discussed

Use of aop.xml

Bhavuk soni — 2012-05-23T10:45:50

Hi,

I am working on a similar solution like yours, where i have to weave an
aspect during execution of a method.
I am working on a solution where mock dependencies for junits are done with
AspectJ(without spring)
and during execution of a test method those dependencies should be weaved so
that the real calls to the classes/ DB can be replaced by mock classes.

I am done with my aspect code, but i am unable to weave this aspect to the
code, point is that i have to do this using aop.xml.

The project structure is like that

1.Aspects- Here all the aspects are written, they are not ABSTRACT, as the
requirement is like that

2.Tests - Here all the tests are written

The test project .classpath has refrences to aspects and the code base
project.

If you can help with a small snippet , it would be great.

Thanks,
Bhavuk
_______________________________________________
aspectj-users mailing list
aspectj-users< at >eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: Issue with WAR file

Jean Andre — 2012-05-22T17:00:11

Thank you Andy for your answer. Well, when we work under IDE, everything 
is smooth enough to avoid developpers to take care about many details. The 
WAR or even an EAR projet can be converted to an AspectJ project and 
something handles correctly the problem of compiling and weaving the 
aspects. WAR and EAR files are not more than specialized JAR file with 
well-known conventions and rules. It is why we have expected similar 
behavior with IAJC task but we have to recognize we have surrestimated the 
capabilities of this specialized task. We have to returned back to the 
starting point by following your recommended approach.

Best regards,

JA.





De :    Andy Clement <andrew.clement< at >gmail.com>
A :     aspectj-users< at >eclipse.org
Date :  2012-05-22 11:56
Objet : Re: [aspectj-users] Issue with WAR file
Envoyé par :    aspectj-users-bounces< at >eclipse.org



Hi,

This is related to the other war discussion we had - AspectJ has no
knowledge beyond understanding a jar.  Similar to how javac has no
understanding

Re: Fwd: trigger all calls/sets from an annotated parameter within a method

Andy Clement — 2012-05-22T16:29:34

Hi,

I'm afraid you can't do that (easily) - we don't know/preserve enough
about local variables.  The slightly messy way to do it would be:

At the execution joinpoint for the method, remember which parameter
objects are annotated, some kind of sequence of these (for different
arg positions):
before(B b): execution(* *(< at >MyAnno (*),..)) && args(b) // arg in first
position
before(B b): execution(* *(*,< at >MyAnno (*),..)) && args(b) // arg in
second position
remember 'b'

Then, when call/set is made within that code, look at the object upon
which the method is being called (target) and check if it was an
annotated one.
before(B b):  (call(* *(..)) || set(* *)) && target(b) {
  if (b is in my list) {
    System.out.println("triggered");
  }
}

Using some kind of stack to push (on entry)/pop (on exit) the
contextual information you are keeping about the method.

cheers,
Andy

On 21 May 2012 08:50, Frederick Egli <frederick.egli< at >gmail.com> wrote:

Re: Accessing protected methods of parent class from within an aspect in another package

Andy Clement — 2012-05-22T16:18:08

Hi Sina,

That should work, the use of 'privileged' should cause generation of
an accessor method that can then be used by the aspect.

here is my sample:

==== 8< ==== Parent.java
package com.somewhereelse;

public class Parent {

protected void foo() {
System.out.println("foo!");
}
}
===== 8< ====
===== 8< ==== Child.java
package com;

import com.somewhereelse.Parent;

public class Child extends Parent {

public static void main(String[] args) {
new Child().m();
}

public void m() {

}
}
===== 8< ==== Overthere.aj
package xxx;
import com.Child;

privileged aspect Overthere {

before(Child c): execution(* Child.m(..)) && this(c) {
c.foo();
}
}
===== 8< ====


Join point 'method-execution(void com.Child.m())' in Type 'com.Child'
(Child.java:11) advised by before advice from 'xxx.Overthere'
(Overthere.aj:6)

foo!

Here is the accessor in the Parent class:

Compiled from "Parent.java"
public class com.somewhereelse.Parent extends java.lang.Object{
    public com.somewhereelse.Parent();
    pr

Re: Issue with WAR file

Andy Clement — 2012-05-22T15:55:58

Hi,

This is related to the other war discussion we had - AspectJ has no
knowledge beyond understanding a jar.  Similar to how javac has no
understanding either.

Of course, this doesn't mean we can't add it.  But the recommended
approach at the moment is to use the other tools available to do
pre-processing (unpacking) and post-processing (repacking) - tools
like the ant jar task.  How about producing output to some other jar
and then using another ant task that runs after the compile to merge
the contents back into the right place in your war file?

I'm a bit surprised things behaved at all given that the input was a
war file - I'd have expected the leading directories on the front of
the package names to have given the weaver problems.

cheers,
Andy

On 18 May 2012 09:50, Jean Andre <Jean.Andre< at >intact.net> wrote:

Accessing protected methods of parent class fromwithin an aspect in another package

Sina — 2012-05-21T16:25:12

Hi there.

I have Parent class and a child one. The parent class has some protected  methods.
My pointcut works on methods of the child class. The problem is that I want to access protected methods of the parent in my Aspect, but they are not 
visible from within my Aspect.

All these 3 classes (Parent, Child, Aspect) are in different packages. 

I read here http://dev.eclipse.org/mhonarc/lists/aspectj-users/msg03270.html
that using privileged  modifier will solve the problem but it does not work for me.
Any idea??

Sina_______________________________________________
aspectj-users mailing list
aspectj-users< at >eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users