Implementing an interface like that isn't trivial. The signatures of those
methods also vary depending on the aspect instantiation model you have
chosen (default singleton, but it could be pertype, perthis, etc). And it
is a shame for you to have to do that when the generated implementations
are just fine. Other instantiation models also introduce further methods
beyond those two.
The intention is that the only time your @Aspect is going to be used is
when weaving so it is isn't unreasonable for AspectJ to add those methods.
In old AspectJ versions we just to hunt for these things and finish them
off but finding them proved very costly. In more recent AspectJs you need
to tell us about them up front and make sure none of the exclusion filters
would cause them to be ignored. Something about your setup is causing them
not to be finished off - possibly a bug but it can be configuration
(accidentally causing them not to be included for weaving). As you saw, it
worked ok for my simple scenario with the LTW agent, so we need to
understand how your setup differs from that. If you can create a minimal
scenario that doesn't work, like mine, then I can debug it.
cheers
Andy
On 17 April 2013 01:09, Gokul <mail_goku...@yahoo.co.in> wrote:
> Thanks Ron, Alex and Andy for the prompt reply.
> Andy weaving works fine if I use ajc. Using javaagent to get the aspect to
> weave-able state is not working as suggested. It still throws
> NoSuchMethodError. Meantime I will address the problem by using ajc at
> compile time and do LTW.
> I would like to put forward the following to your notice. I may be greedy,
> but just as a user I would like - not to disturb either development
> environment or the runtime environment. To my knowledge it looks like core
> functionality which is weaving the aspect to the target class is achievable
> by using WeavingURLClassLoader, but getting aspect to a weave-able state
> requires either ajc or javaagent.
> Instead can AspectJ define an interface as follows:
>
> public interface LTWAspect {
> /* Need more documentation on what this method is expected to return*/
> public Class aspectOf();
> public .. hasAspect();
> }
>
> Any @Aspect can implement this interface and thus we can avoid ajc or
> inclusion of javaagent.
>
> Being said this I admit I am per-mature aspectj user and please correct me
> if I am wrong.
>
> Thanks
> Gokul
>
>
> ------------------------------
> *From:* Alexander Kriegisch <alexan...@kriegisch.name>
> *To:* "aspectj-users@eclipse.org" <aspectj-users@eclipse.org>
> *Sent:* Tuesday, 16 April 2013 9:14 PM
> *Subject:* Re: [aspectj-users] LTW: Are there any posibilities to avoid
> using ajc and overcome NoSuchMethodError
>
> As usual, Andy's answer is much smarter than mine. For them alone it makes
> sense to be on this list. Just saying... Compliments and thanks, you are
> one of my personal rock stars. :-)
>
> Alexander Kriegisch
>
> Am 16.04.2013 um 17:38 schrieb Andy Clement <andrew.clem...@gmail.com>:
>
> Actually the aspects do not need to be compiled with AspectJ. The aspects
> can be compiled with javac. *But* before they are usable they must be
> 'finished off' by ajc, but that can be done at loadtime. Here is my example:
>
> // Code.java
> public class Code {
> public static void main(String []argv) {
> new Code().m();
> }
>
> public void m() {}
> }
>
> // Doit.java
> import org.aspectj.lang.annotation.*;
> @Aspect
> public class Doit {
> @Around("execution(* m(..))")
> public void advice() {
> System.out.println("advice running");
> }
> }
>
> // META-INF/aop-ajc.xml
> <aspectj>
> <aspects>
> <!-- declare existing aspects to the weaver -->
> <aspect name="Doit"/>
> </aspects>
> <weaver options="-showWeaveInfo">
> <include within="*"/>
> </weaver>
> </aspectj>
>
> ====
> > javac Doit.java Code.java
>
> > java -javaagent:../lib/aspectjweaver.jar Code
>
> [AppClassLoader@1ef6a746] weaveinfo Join point 'method-execution(void
> Code.m())' in Type 'Code' (Code.java:6) advised by around advice from
> 'Doit' (Doit.java)
>
> advice running
>
>
>
> The aspect should get 'finished off' (and the necessary aspectOf() and
> hasAspect() added) by the weaver just before it gets used. That doesn't
> seem to be happening with your setup - does it work for you with the agent?
>
> On a quick look I think the problem might be that the
> WeavingURLClassLoader path into the system doesn't have a concept of
> unfinished aspects. You could try additionally including the aspect library
> in the classURLs list? That might be enough to remind it that it needs to
> finish it off.
>
> cheers
> Andy
>
>
>
> On 16 April 2013 05:55, Alexander Kriegisch <alexan...@kriegisch.name>wrote:
>
> Theoretically you can use ajc from aspectjtools.jar and compile on the
> fly, even thought this does not sound so nice.
>
> See my answer at http://stackoverflow.com/a/15837624/1082681 for a code
> sample.
>
> Alexander Kriegisch
>
> Am 16.04.2013 um 14:16 schrieb Ron DiFrango <
> rdifra...@captechconsulting.com>:
>
> Gokul,
>
> Even if you are using load time weaving, the aspects themselves have to be
> compiled with the aspect compiler. I don't think there is any way around
> this.
>
> Thanks,
>
>
> *Ron DiFrango*
> ------------------------------
> *From:* aspectj-users-boun...@eclipse.org [
> aspectj-users-boun...@eclipse.org] on behalf of Gokul [
> mail_goku...@yahoo.co.in]
> *Sent:* Tuesday, April 16, 2013 12:37 AM
> *To:* aspectj-users@eclipse.org
> *Subject:* [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:
>
> <aspectj>
> <aspects>
> <!-- declare existing aspects to the weaver -->
> <aspect name="net.XXX.pub.plugin.FatalWarningAdvice"/>
> </aspects>
> <weaver options="-showWeaveInfo">
> <include within="com.XXX.plugin..*"/>
> <include within="net.XXX.pub.plugin..*"/>
> </weaver>
> </aspectj>
>
> 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<URL> 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
>
>
> _______________________________________________
> 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 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
