<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.java.aop.aspectj.general">
    <title>gmane.comp.java.aop.aspectj.general</title>
    <link>http://blog.gmane.org/gmane.comp.java.aop.aspectj.general</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7299"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7298"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7297"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7296"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7295"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7294"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7293"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7292"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7291"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7290"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7289"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7288"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7287"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7286"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7285"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7284"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7283"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7282"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7281"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7280"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7299">
    <title>Some Noob Design Questions</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7299</link>
    <description>&lt;pre&gt;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&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>El Lunes</dc:creator>
    <dc:date>2012-05-24T10:00:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7298">
    <title>convert unchecked-exception to checked-exception</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7298</link>
    <description>&lt;pre&gt;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:

  &amp;lt; at &amp;gt;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();
   } 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
       throw new SoftException(exception1);
}

As we can see, my new DSException is softened too and is thrown as a
SoftException.
It seems that the code for "declare soft" will always be weaved as last
step.
I tried "declare precedence" to control the weaving-process, but nothing
changes!

==== Is there any other way to avoid the unhandled-exception-error? ====

I found similar Questions in several lists, but the solutions all did not
work with the current release of AspectJ 1.6.12.M1 (ajdt 2.1.3).

Thank you in advance
_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>Straub Oliver</dc:creator>
    <dc:date>2012-05-24T09:06:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7297">
    <title>Re: Use of aop.xml</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7297</link>
    <description>&lt;pre&gt;Hi,

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

&amp;lt;aspectj&amp;gt;
 &amp;lt;aspects&amp;gt;
  &amp;lt;aspect name="com.foo.MyAspect"/&amp;gt;
 &amp;lt;/aspects&amp;gt;
&amp;lt;/aspectj&amp;gt;

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:

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

This kind of usage is discussed in detail in here:
http://www.eclipse.org/aspectj/doc/released/README-1612.html

cheers,
Andy

On 23 May 2012 03:45, Bhavuk soni &amp;lt;bhavuksoni&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Andy Clement</dc:creator>
    <dc:date>2012-05-23T15:03:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7296">
    <title>Use of aop.xml</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7296</link>
    <description>&lt;pre&gt;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&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>Bhavuk soni</dc:creator>
    <dc:date>2012-05-23T10:45:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7295">
    <title>Re: Issue with WAR file</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7295</link>
    <description>&lt;pre&gt;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 &amp;lt;andrew.clement&amp;lt; at &amp;gt;gmail.com&amp;gt;
A :     aspectj-users&amp;lt; at &amp;gt;eclipse.org
Date :  2012-05-22 11:56
Objet : Re: [aspectj-users] Issue with WAR file
Envoyé par :    aspectj-users-bounces&amp;lt; at &amp;gt;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 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 &amp;lt;Jean.Andre&amp;lt; at &amp;gt;intact.net&amp;gt; wrote:
solved
files.
-
both
as
folder
put
"ext/cglib-nodep-2.2.2.jar"/&amp;gt;
"ext/commons-lang-2.4.jar"/&amp;gt;
"ext/cssparser-0.9.6.jar"/&amp;gt;
"ext/hibernate-3.3.2.jar"/&amp;gt;
"ext/ojdbc14-10.2.0.4.jar"/&amp;gt;
"ext/pop-api-official.jar"/&amp;gt;
"ext/slf4j-api-1.6.4.jar"/&amp;gt;
_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>Jean Andre</dc:creator>
    <dc:date>2012-05-22T17:00:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7294">
    <title>Re: Fwd: trigger all calls/sets from an annotated parameter within a method</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7294</link>
    <description>&lt;pre&gt;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(* *(&amp;lt; at &amp;gt;MyAnno (*),..)) &amp;amp;&amp;amp; args(b) // arg in first
position
before(B b): execution(* *(*,&amp;lt; at &amp;gt;MyAnno (*),..)) &amp;amp;&amp;amp; 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(* *)) &amp;amp;&amp;amp; 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 &amp;lt;frederick.egli&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Andy Clement</dc:creator>
    <dc:date>2012-05-22T16:29:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7293">
    <title>Re: Accessing protected methods of parent class from within an aspect in another package</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7293</link>
    <description>&lt;pre&gt;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&amp;lt; ==== Parent.java
package com.somewhereelse;

public class Parent {

protected void foo() {
System.out.println("foo!");
}
}
===== 8&amp;lt; ====
===== 8&amp;lt; ==== 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&amp;lt; ==== Overthere.aj
package xxx;
import com.Child;

privileged aspect Overthere {

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


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();
    protected void foo();
    public void ajc$privMethod$xxx_Overthere$com_somewhereelse_Parent$foo();
}

So what is different about your configuration from mine?

cheers,
Andy

On 21 May 2012 09:25, Sina &amp;lt;my.linked.account&amp;lt; at &amp;gt;googlemail.com&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Andy Clement</dc:creator>
    <dc:date>2012-05-22T16:18:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7292">
    <title>Re: Issue with WAR file</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7292</link>
    <description>&lt;pre&gt;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 &amp;lt;Jean.Andre&amp;lt; at &amp;gt;intact.net&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Andy Clement</dc:creator>
    <dc:date>2012-05-22T15:55:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7291">
    <title>Accessing protected methods of parent class fromwithin an aspect in another package</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7291</link>
    <description>&lt;pre&gt;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&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>Sina</dc:creator>
    <dc:date>2012-05-21T16:25:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7290">
    <title>Fwd: trigger all calls/sets from an annotatedparameter within a method</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7290</link>
    <description>&lt;pre&gt;Hi all,

I'm trying to trigger all calls/sets from an annotated parameter within a
method. Consider the following example:

public class A {

    public void foo(&amp;lt; at &amp;gt;MyAnno B b1, B b2){
        b1.bar();         //this should trigger
        b1.field = 42;  //this should trigger

        b2.bar();         //should not trigger
        b2.field = 42;  //should not trigger
    }
}

public class B {
    public int field;
    public void bar() {    }
}

&amp;lt; at &amp;gt;Retention(RetentionPolicy.RUNTIME)
&amp;lt; at &amp;gt;Target(ElementType.PARAMETER)
public &amp;lt; at &amp;gt;interface MyAnno {
}


So far I have the following aspect. But of course this triggers all calls
and sets from all method parameters.

&amp;lt; at &amp;gt;Aspect
public class MyAspect {
    &amp;lt; at &amp;gt;Before("cflowbelow(execution(* *.*(..,&amp;lt; at &amp;gt;MyAnno (*),..))) &amp;amp;&amp;amp; (call(*
*(..)) || set(* *)) &amp;amp;&amp;amp; !within(MyAspect)")
    public void belowAdvice() {
        System.out.println("triggered");
    }
}

Is there any way to only trigger the calls and sets from the annotated (in
my case b1) parameter within a method (foo())?


Thanks in advance!

Fred
_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>Frederick Egli</dc:creator>
    <dc:date>2012-05-21T15:50:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7289">
    <title>Issue with WAR file</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7289</link>
    <description>&lt;pre&gt;Hello,

We have a problem and we tried to figure out if this problem can be solved 
by iajc. We have WAR file which contains the source and the &amp;lt; at &amp;gt;aspectJ 
files.
We use the ANT command  &amp;lt;iajc&amp;gt; inpath="my_original_War" -outJar="MyWar" - 
classpath="The full list of jar"

The weaven did not report any error, everything seems fine. BUT, when we 
tried to run the WAR file inside the EAR, it fails. We compared the both 
WAR and the  WAR produced by the Weaver did not have the same structure as 
the original WAR.

The WAR has an additional folder starting from the root : 
com\companyName\projectName\.... In fact, the weaver have put the src 
folder at the root of the WAR file instead of keeping the classes inside 
WEB-INF\classes. It it like having duplicated classes, with and without 
veaven.

For sure, it is not normal ?
Iis there a way to specify with IAJC  the destination folder where to put 
the weaven classes inside the WAR (I think, there are weaven classes ?)

What are our alternatives ?

Best regards and thank you for your quick feedback.

JA.

=============================================
The exact command for the weaver
=============================================

           &amp;lt;iajc inpath="Web_origine.war"
                 outjar="Web.war"
                 showWeaveInfo="false"&amp;gt; 
                &amp;lt;classpath&amp;gt;
                        &amp;lt;pathelement path = "ext/aspectjrt.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/javax.faces.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/annotations-4.2.0.Final.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/antlr-2.7.6.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/cglib-nodep-2.2.2.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/cof-service-api-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/cof-service-web-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-core-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-dm-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-email-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-il-services-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-java-services-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-moneris-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-pega-services-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-web-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-web-struts-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-web-tags-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/common-api-wi-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/commons-lang-2.4.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/commons-logging-1.1.1.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/commons-validator-1.4.0.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/cssparser-0.9.6.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/dom4j-1.6.1.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/guava-11.0.1.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/hibernate-3.3.2.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/hibernate-annotations-3.4.0.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/hibernate-commons-annotations-3.4.0.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/hibernate-entitymanager-3.4.0.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/hibernate-validator-4.2.0.Final.jar"/&amp;gt; 
                        &amp;lt;pathelement path = "ext/junit-4.10.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/log4j-1.2.16.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/ojdbc14-10.2.0.4.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.asm-3.0.6.RELEASE.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.beans-3.0.6.RELEASE.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.context-3.0.6.RELEASE.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.core-3.0.6.RELEASE.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.expression-3.0.6.RELEASE.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.jdbc-3.0.6.RELEASE.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.orm-3.0.6.RELEASE.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.transaction-3.0.6.RELEASE.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.web-3.0.6.RELEASE.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/pop-api-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/pop-services-official.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/richfaces-components-api-4.2.0.Final.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/richfaces-components-ui-4.2.0.Final.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/richfaces-core-api-4.2.0.Final.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/richfaces-core-impl-4.2.0.Final.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/sac-1.3.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/slf4j-api-1.6.4.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/slf4j-log4j12-1.6.4.jar"/&amp;gt;
                        &amp;lt;pathelement path = "ext/j2ee.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/commons-collections-3.2.1.jar"/&amp;gt;
                        &amp;lt;pathelement path = 
"ext/org.springframework.aop-3.0.6.RELEASE.jar"/&amp;gt; 
                &amp;lt;/classpath&amp;gt;

           &amp;lt;/iajc&amp;gt;_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>Jean Andre</dc:creator>
    <dc:date>2012-05-18T16:50:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7288">
    <title>Re: Aspect in an EAR file</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7288</link>
    <description>&lt;pre&gt;Yes, James is right, load time weaving can do the kinds of thing you
want to do but it will incur you a startup hit.

Using a javaagent each classloader in the system gets a weaver and
will use any aop.xml files it can 'reach' through its classpath to
configure itself.  So if one jar on that classpath defines an aop.xml
file containing an aspect, then that weaver associated with the
classloader will apply the aspect to everything loaded through that
same classloader.

Weaving will be about the same speed regardless of when you choose to
do it (compile time, post compile time, load time) but:
- load time weaving will weave things as they are loaded.  This may
sound obvious, but this does mean if something isn't loaded on a
particular run of the application then you won't weave it or incur the
cost of weaving it.  Whereas compile time weaving will weave
everything.
- beyond speed there is a memory overhead for a weaver that you will
incur.  But having said that we are including some basic caching in
the next version that will mean you can weave on first startup,
automatically store those woven entities, and then use the stored
cached versions on the subsequent starts. (reducing the memory and
performance impact).

Andy

On 18 May 2012 04:30, James Black &amp;lt;planiturthian&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Andy Clement</dc:creator>
    <dc:date>2012-05-18T16:06:27</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7287">
    <title>Re: Advice did not match</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7287</link>
    <description>&lt;pre&gt;I might need to see where you are applying it?

I created this tiny thing and your aspect worked just fine:

class Foo {
&amp;lt; at &amp;gt;Updates void foo(String s) {}
}

The advice did not match indicates that during the build of the code
containing the aspect it didn't find anything to apply it to.  If that
is because you are building it into an aspect library to use later,
you can just ignore the warning.  If you expected it to match
something though - I'd need to see what it isn't matching.  If it
isn't matching you can break it into smaller pieces to determine which
piece is causing the problem.

cheers
Andy

On 17 May 2012 11:40, hart404 &amp;lt;hart404&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Andy Clement</dc:creator>
    <dc:date>2012-05-18T15:55:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7286">
    <title>Re: Aspect in an EAR file</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7286</link>
    <description>&lt;pre&gt;I don't see why you can't do this, but you will take a performance hit as
it weaves at run time.

It is best if you can apply the aspects during compilation, but if that
isn't an option then run time is your other option.
On May 18, 2012 6:10 AM, "jbolger" &amp;lt;john.bolger&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>James Black</dc:creator>
    <dc:date>2012-05-18T11:30:44</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7285">
    <title>Aspect in an EAR file</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7285</link>
    <description>&lt;pre&gt;Hi,

Can you tell me if I can configure an aspect within an EAR to apply advice
against all code (including jars and wars) within the EAR and it's lib
(without having to define the aspect in each of the wars)?

Also in this case, which weaving style is most appropriate? Is it even
possible to perform compile/post-compile time weaving for an EAR when the
jars / wars it includes have already been built?

And finally, is any weaving style more performant than the other?

Thanks in advance,
John

--
View this message in context: http://aspectj.2085585.n4.nabble.com/Aspect-in-an-EAR-file-tp4644307.html
Sent from the AspectJ - users mailing list archive at Nabble.com.
&lt;/pre&gt;</description>
    <dc:creator>jbolger</dc:creator>
    <dc:date>2012-05-18T10:09:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7284">
    <title>Advice did not match</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7284</link>
    <description>&lt;pre&gt;Can anyone tell me why I'm getting "Advice did not match" on the after advice
in the following code, please?

package edu.uat.cs2011.observerpattern;

import java.util.ArrayList;
import java.util.List;

public aspect ObservableAspect {

declare parents: hasmethod(&amp;lt; at &amp;gt;Updates * *.*(..)) implements Observable;

private List&amp;lt;Observer&amp;gt; observers = new ArrayList&amp;lt;Observer&amp;gt;();

public void addObserver(Observer observer) {
observers.add(observer);
}

public void removeObserver(Observer observer) {
observers.remove(observer);
}

public void notifyObservers() {
for (Observer observer : observers) {
observer.update();
}
}

public pointcut mutations(Observable observable) : execution(&amp;lt; at &amp;gt;Updates *
*.*(..)) &amp;amp;&amp;amp; this(observable);

after(Observable observable) : mutations(observable) {
for (Observer observer : observers) {
observer.update();
}
}

}

--
View this message in context: http://aspectj.2085585.n4.nabble.com/Advice-did-not-match-tp4643399.html
Sent from the AspectJ - users mailing list archive at Nabble.com.
&lt;/pre&gt;</description>
    <dc:creator>hart404</dc:creator>
    <dc:date>2012-05-17T18:40:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7283">
    <title>Re: Corbetura + LTW</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7283</link>
    <description>&lt;pre&gt;Sorry I didn't reply sooner - at a conference right now.

Yes, we can work with cobertura but you have to be careful on ordering
when running it and AJ together.  There is at least one open bug in
this area:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=325362

cheers,
Andy

On 16 May 2012 08:09, Steve Ash &amp;lt;stevemash&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Andy Clement</dc:creator>
    <dc:date>2012-05-17T17:45:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7282">
    <title>Re: Corbetura + LTW</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7282</link>
    <description>&lt;pre&gt;Just for anyone that runs across this in the googles-- this was just
me being stupid.  I had not cleaned the workspace and the class files
that corbetura was instrumenting were already woven at compile time.
So compile time ajc -&amp;gt; corbetura instrumentation -&amp;gt; LTW caused this
blow up.  You can see the ajc stuff already in the class file that I
attached to my previous message.

Once I cleaned and re-ran letting javac build the original class files
then having corbetura instrument those and do LTW on the corbetura
classes  --- everything worked fine.

So to answer my original question -- it appears that with corbetura
2.5.1 and AspectJ Weaver 1.7.0.M1 -- LTW can weave into corbetura
instrumented classes.

Steve

On Tue, May 15, 2012 at 11:45 AM, Steve Ash &amp;lt;stevemash&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:
&lt;/pre&gt;</description>
    <dc:creator>Steve Ash</dc:creator>
    <dc:date>2012-05-16T15:09:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7281">
    <title>Corbetura + LTW</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7281</link>
    <description>&lt;pre&gt;I have run across a number of things on google so I know that this has
come up in the past, but I couldn't get a clear answer.  So sorry for
the re-post.

I am trying to use corbetura + aspectJ LTW and the weaver is blowing
up on the corbetura instrumented classes.  I am trying to dig in to
the class file to see if I can spot the exact problem, but wanted to
post and see if the expectation was that this would work or not.  I am
using the 1.7.0.M1 weaver and this is the stack trace:

SEVERE: com/argodata/empi/database/util/InsertIfMissingEntityLoader
org.aspectj.apache.bcel.classfile.ClassFormatException: File:
'com.argodata.empi.database.util.InsertIfMissingEntityLoader': Invalid
byte tag in constant pool: 0
        at org.aspectj.apache.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:192)
        at org.aspectj.apache.bcel.classfile.ClassParser.parse(ClassParser.java:131)
        at org.aspectj.weaver.bcel.Utility.makeJavaClass(Utility.java:467)
        at org.aspectj.weaver.bcel.BcelWeaver.processReweavableStateIfPresent(BcelWeaver.java:1387)
        at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1097)
        at org.aspectj.weaver.tools.WeavingAdaptor.getWovenBytes(WeavingAdaptor.java:472)
        at org.aspectj.weaver.tools.WeavingAdaptor.weaveClass(WeavingAdaptor.java:323)
        at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:99)
        at org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:54)

I have a few spring-aspects &amp;lt; at &amp;gt;Transactional annotations in there
weaving the before, after, and throwing advice for
TransactionalAspect.

I have attached the cobetura instrumented class file to this message
if that helps at all.

But I guess the main question is: should this work?  Or is this a
known limitation?

Thanks,

Steve
_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>Steve Ash</dc:creator>
    <dc:date>2012-05-15T16:45:52</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7280">
    <title>Re: How to specify classpath inside a WAR for theweaver ?</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7280</link>
    <description>&lt;pre&gt;It is what  I did : https://bugs.eclipse.org/bugs/show_bug.cgi?id=379530

Understood - Surfing on the net about having a such thing, there is a real 
need and many users are facing to this problem.
It will increase the interoperability between the java community and the 
tools will be more friendly for us.

In our case, the persons who are developping and using AspectJ are not the 
same as the persons who are building the project to deploy the ear. The 
competency is not the same. Building/Weaving a project should be "smooth" 
enough for this king of persons.

Best regards,

JA.






De :    Andy Clement &amp;lt;andrew.clement&amp;lt; at &amp;gt;gmail.com&amp;gt;
A :     aspectj-users&amp;lt; at &amp;gt;eclipse.org
Date :  2012-05-14 23:29
Objet : Re: [aspectj-users] How to specify classpath inside a WAR for the 
weaver ?
Envoyé par :    aspectj-users-bounces&amp;lt; at &amp;gt;eclipse.org



Hi,

I'm afraid that right now you can't tell AspectJ to look at jars
within jars.  It is probably not toooo difficult to implement though.
Might be worth raising an enhancement request:

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ

In the meantime you'll have to extract those into somewhere, but
unfortunately you will need to specify them all on a classpath.  You
can turn off that error (or dial it down to a warning) because it is
an Xlint, but it may mean it is not be weaving what you would like it
to (as it couldn't complete its analysis).

cheers,
Andy

On 14 May 2012 14:30, Jean Andre &amp;lt;Jean.Andre&amp;lt; at &amp;gt;intact.net&amp;gt; wrote:
F:\cruisecontrol-service-4\artifacts\MyApplication_01_SYSINT\20120509153156\MyApplication-1.0.0.49\CrmWeb_origine.war:0::0
150
_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>Jean Andre</dc:creator>
    <dc:date>2012-05-15T16:00:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7279">
    <title>Re: DeclareAnnotation Warnings</title>
    <link>http://permalink.gmane.org/gmane.comp.java.aop.aspectj.general/7279</link>
    <description>&lt;pre&gt;From what I can tell from adjusting the build.xml for ANT, I removed the
following line and the warnings vanished.

&amp;lt;aspectpath refid="compile.classpath"/&amp;gt;

 

Sorry for the confusion.

 

From: aspectj-users-bounces&amp;lt; at &amp;gt;eclipse.org
[mailto:aspectj-users-bounces&amp;lt; at &amp;gt;eclipse.org] On Behalf Of CRANFORD, CHRIS
Sent: Tuesday, May 15, 2012 10:35 AM
To: aspectj-users&amp;lt; at &amp;gt;eclipse.org
Subject: [aspectj-users] DeclareAnnotation Warnings

 

In a Spring project, the ANT build script shows the following warnings
during the IAJC task:

&amp;lt;Unknown&amp;gt; [warning] Found &amp;lt; at &amp;gt;DeclareAnnotation while current release does
not support it (see 'org.aspectj.weaver.bcel.AtAjAttributes')

 

I am using the AspectJ 1.6.12 runtime libraries.  

 

How can I avoid/prevent these warnings?
_______________________________________________
aspectj-users mailing list
aspectj-users&amp;lt; at &amp;gt;eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
&lt;/pre&gt;</description>
    <dc:creator>CRANFORD, CHRIS</dc:creator>
    <dc:date>2012-05-15T15:57:26</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.java.aop.aspectj.general">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.java.aop.aspectj.general</link>
  </textinput>
</rdf:RDF>

