[aspectj-users] LTW: Are there any posibilities to avoid using ajc and overcome NoSuchMethodError
Hi,
My project uses a custom plugin framework, where plugin's are JAR files loaded
at run-time by the framework using custom class loader. We have several plugin
JAR files that are to be loaded and AOP looks to be a perfect solution to add a
particular functionality across plugins.
Following are my Aspect definition and other implementation details:
package net.XXX.pub.plugin;
@Aspect
public class FatalWarningAdvice
{
@Around("target(net.XXX.pub.plugin.XXX.XXModelSerializable) &&
call(@ReportFatalError * *(..))")
public void handleFatalWarning(ProceedingJoinPoint joinPoint) throws
Throwable {
XXModelSerializable target = (XXModelSerializable)joinPoint.getTarget();
try {
joinPoint.proceed();
} catch(Throwable ex) {
throw new XXPluginException(target.getDetailedErrorMessage(ex));
}
}
/* Adding below method solves my problem, but are there any better way to
solve this problem ?
public static FatalWarningAdvice aspectOf() {
return new FatalWarningAdvice();
}*/
}
The above aspect is part of public.jar file. I have also defined aop.xml file
under META-INF folder as follows:
I want FatalWarningAdvice aspect to be weaved on runtime when plugin's are
loaded by the plugin framework. Following code demonstrated the same:
private synchronized ClassLoader getClassLoader(String jarName) throws
IOException {
ClassLoader classLoader = classLoaders.get(jarName);
if(null == classLoader) {
ClassLoader startupClassLoader =
PluginServiceImpl.class.getClassLoader();
File jarFile = new File(runtimeJarDir, jarName);
File aspectJarFile = new File("public.jar");
//classLoader = new NestedJarClassLoader(jarFile, tmpJarDir,
startupClassLoader);
//Below call provides list of URLs that will be input to AspectJ
weaver.
List classURLs = NestedJarClassLoader.getURLList(jarFile,
tmpJarDir);
classURLs.add(aspectJarFile.toURI().toURL());
classLoader = new WeavingURLClassLoader(classURLs.toArray(new
URL[classURLs.size()]), new URL[]{aspectJarFile.toURI().toURL()},
startupClassLoader);
classLoaders.put(jarName, classLoader);
}
return classLoader;
}
Upon executing the above code I get the following exception:
java.lang.NoSuchMethodError:
net.XXX.pub.plugin.FatalWarningAdvice.aspectOf()Lnet/XXX/pub/plugin/FatalWarningAdvice;
I could temporarily over come this problem by adding below lines of code in my
Aspect:
public static FatalWarningAdvice aspectOf() {
return new FatalWarningAdvice();
}
Are there any work-around to this problem ? One solution is to use ajc or iajc
but then I requires change to my build environment. As part of LTW are there
any possibility to avoid using ajc ?
Introducing ajc in the build process is a pain as it will affect the team, each
developer has to include the aspectj-tools.jar to ant library (to my
knowledge). Are there any possibilities for AspectJ to include these methods at
runtime ?
Thanks in advance
Gokul___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] A failure with complex generic type
Hi Hana, Looks like you found a new bug. Can you raise a bugzilla for it? (here https://bugs.eclipse.org/bugs/enter_bug.cgi?product=AspectJ ). If you could include the source code declarations involved then that would be helpful (I probably don't need the code itself, just the declarations). cheers, Andy On 15 April 2013 02:46, Giat, Hana wrote: > Using aspectjtools 1.7.2 I get the following exception: > > ** ** > > INFO: abort ABORT -- (IllegalStateException) Expecting .,<, or ;, but > found / while unpacking Lcom/a/a/b/t.com/a/a/b/ > af.com/a/a/b/ag;Ljava/util/ListIterator; > > Expecting .,<, or ;, but found / while unpacking > Lcom/a/a/b/t.com/a/a/b/af.com/a/a/b/ag;Ljava/util/ListIterator > ; > > java.lang.IllegalStateException: Expecting .,<, or ;, but found / while > unpacking Lcom/a/a/b/t.com/a/a/b/ > af.com/a/a/b/ag;Ljava/util/ListIterator; > > ** ** > > I see in readme that similar issues were supposed to be solved in 1.7.2 > (“complex generic types”). > > Is it another bug? My class seems to be ok and functioning, just fails on > weaving. > > ** ** > > Thanks, > > Hana > > ___ > 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] Annotation Values in Matching Expressions
I have the array support just about done, but then I got a bit bogged down
in the rest of the proposal that Matthew discusses in the bugzilla he
referenced. I'll try and get that array support out soon.
cheers
Andy
On 13 April 2013 22:09, Matthew Adams wrote:
> That's an enhancement. See
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=405016.
>
>
> On Fri, Apr 12, 2013 at 6:43 PM, Jay Roberts wrote:
>
>> Hi,
>>
>> I'd like to be able to do something like:
>>
>> @Around("execution(@javax.ws.rs.Consumes({MediaType.MULTIPART_FORM_DATA})
>> * *.*(..))")
>>
>>
>> where the matching uses the value of an annotation element.
>>
>> The compiler recognizes what I'd like to do, but admits:
>>
>> [ERROR] Compiler limitation: annotation value support not implemented for
>> type java.lang.String[]
>>
>> So I'm wondering one of two things:
>>
>> 1) Is this going to be implemented anytime soon?
>>
>> 2) Is there any sort of workaround to make this happen?
>>
>> Thanks!
>>
>> Jay Roberts
>>
>>
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>
>
> --
> mailto:matt...@matthewadams.me
> skype:matthewadams12
> googletalk:matt...@matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>
> ___
> 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] Usage question
Hi Archie, What you are trying to do sounds reasonable. The unusual thing I do notice is that you have the inpath and destdir set the same for your final iajc call. That could introduce weirdness. The only strict ordering policy for processing files is that aspects are processed before classes. This can mean on different runs of the compiler the classes are processed in a different order, and that should not matter. If it does matter, as you seem to be discovering, that is a bug. With inpath/destdir the same we may find whilst weaving a file and resolving references that on one run we resolve to something already woven, on another run we don't - so that is the first thing I'd change, weave to somewhere else. It may be leading to your type not exposed problems. You may find the build faster if you merge those final two steps...but it isn't strictly necessary. I presume the 'type not exposed to weaver' messages were for your types and not for JRE types? If we could distill down a simple scenario that displayed this problem, I am happy to debug into it. cheers, Andy On 12 April 2013 10:25, Archie Cobbs wrote: > I have a question about the proper usage of the ant task, as well > as a (possible) bug report. I'm using AspectJ 1.7.1. > > In my project I have a bunch of normal Java code and one custom aspect. > > I also have other pre-compiled aspects supplied in 3rd party JAR files > (e.g., Spring's @Transactional, etc.). > > I'm doing compile-time weaving. > > So the steps I have been following are: > >1. Compile normal *.java code using into build/classes >2. Compile aspects *.aj code using into build/classes >3. Apply aspects (both my own and 3rd party) using > > Here's the problem: was intermittently failing to weave classes. > And each time I ran the build, it would be a different set of classes. > > The classes that failed to weave would have the "this affected type is not > exposed to the weaver" warning emitted during weaving (step #3). The > classes warned (and not woven) would change each build. > > Here is how ant was being used when this problem was occurring > (abbreviated for clarity): > > > > > > > > > > > > > > >destDir="build/classes" > classpathRef="iajc.classpath" > source="1.6" > target="1.6" > verbose="true" > showWeaveInfo="true" > failonerror="true"> > > > > >destDir="build/classes" > classpathRef="iajc.classpath" > source="1.6" > target="1.6" > verbose="true" > showWeaveInfo="false" > failonerror="true" > aspectPathRef="aspect.classpath"/> > > The way that I fixed the problem was by removing build/classes from both > iajc.classpath and aspect.classpath (see highlights). > > The latter change was counter-intuitive because, after the "Compile custom > aspects" step, I thought my custom aspect would live in build/classes and > so need to be found there. > > So my question is: what is the proper way to do what I'm trying to do? > Must *.java/*.class and *.aj/*.class files be kept strictly separated? > > And the possible bug is: why does randomly fail to weave classes > just because classpathRef and/or aspectPathRef has more stuff in it? > > And even though the way I was doing it before may be improper usage, why > is there non-determinism in the result? That seems bad in itself. > > Thanks, > -Archie > > -- > Archie L. Cobbs > > > > ___ > 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
Binding all the args and/or allowing some sort of read only of the closure
state - actually, these are both useful and the read only of the closure state
really closes the loop so that a downstream aspect can see exactly what will be
executed upon. That info and the original getArgs both are necessary info for
what we are doing.
Thanks!
Jay
On Apr 15, 2013, at 8:36 AM, Brett Randall wrote:
> 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 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 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.
>>>
>>> Bret
Re: [aspectj-users] JoinPoint.getArgs() in multiple aspects on same joinpoint
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 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 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 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;i>>if(args[i] instanceof BadArg){
>>>
[aspectj-users] A failure with complex generic type
Using aspectjtools 1.7.2 I get the following exception:
INFO: abort ABORT -- (IllegalStateException) Expecting .,<, or ;, but found /
while unpacking
Lcom/a/a/b/t.com/a/a/b/af.com/a/a/b/ag;Ljava/util/ListIterator;
Expecting .,<, or ;, but found / while unpacking
Lcom/a/a/b/t.com/a/a/b/af.com/a/a/b/ag;Ljava/util/ListIterator;
java.lang.IllegalStateException: Expecting .,<, or ;, but found / while
unpacking
Lcom/a/a/b/t.com/a/a/b/af.com/a/a/b/ag;Ljava/util/ListIterator;
I see in readme that similar issues were supposed to be solved in 1.7.2
("complex generic types").
Is it another bug? My class seems to be ok and functioning, just fails on
weaving.
Thanks,
Hana
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users
