I think in theory what you are doing there is fine, but some kind of bug is
affecting things.
You could exclude the aspect from the first compile (by javac) - that may make
it behave. You could ‘exclude’ it in the first step or maybe give it a “.aj”
suffix meaning javac wouldn’t notice it and then add it in your secondary step.
cheers,
Andy
> On Jan 30, 2015, at 6:03 AM, Adam Retter <adam.ret...@googlemail.com> wrote:
>
>>> Also, at present we compile our whole code-base with javac and then
>>> use the Ant task to run iajc again over the whole codebase. I wonder
>>> if we could just use iajc to compile those classes that actually have
>>> Aspects? Perhaps that might work around all/some of the compile errors
>>> we are getting?
>>
>> If you are rebuilding everything with iajc, that does seem a duplication of
>> effort. You either should just build with iajc or build with javac and then
>> binary weave the aspects into what you built with iajc. This latter approach
>> would probably avoid this bug. So javac your java modules. ajc your aspects
>> and supply an inpath to that ajc call that is your javac built code, the
>> output would be the woven form of that code.
>>
>
> Thanks Andy, I am trying to take your suggestion to restrict what is
> compiled by AspectJ. We have one Aspect in our project called
> PermissionRequiredAspect which allows us to annotate certain methods
> within the codebase as needing a certain security context. Previously
> our Ant compilation looked like this -
>
> <javac includeAntRuntime="false" debug="${build.debug}"
> deprecation="${build.deprecation}" destdir="${build.classes}"
> encoding="UTF-8" optimize="${build.optimize}" srcdir="${src}"
> source="${build.compiler.source}" target="${build.compiler.target}"
> fork="true" memoryInitialSize="512m" memoryMaximumSize="1024m">
>
> <include name="org/**"/>
>
> <classpath>
> <path refid="classpath.core"/>
> <path refid="classpath.jetty"/>
> <path refid="classpath.aspectj"/>
> </classpath>
> </javac>
>
> <iajc debug="${build.debug}" deprecation="${build.deprecation}"
> destdir="${build.classes}"
> encoding="UTF-8" srcdir="${src}"
> source="${build.compiler.source}" target="${build.compiler.target}"
> fork="true" maxmem="1024m" showWeaveInfo="true">
>
> <include name="org/**"/>
>
> <classpath>
> <path refid="classpath.aspectj"/>
> <path refid="classpath.core"/>
> <path refid="classpath.jetty"/>
> </classpath>
> </iajc>
>
>
> Following your suggestion to reduce the amount of compilation done by
> iajc, I have now modified the iajc task to this:
>
> <iajc debug="${build.debug}" deprecation="${build.deprecation}"
> destdir="${build.classes}"
> encoding="UTF-8" srcdir="${src}"
> source="${build.compiler.source}" target="${build.compiler.target}"
> fork="true" maxmem="1024m" showWeaveInfo="true"
> inpath="${build.classes}">
>
> <include name="org/exist/security/PermissionRequiredAspect.java"/>
>
> <classpath>
> <path refid="classpath.aspectj"/>
> <path refid="classpath.core"/>
> <path refid="classpath.jetty"/>
> </classpath>
> </iajc>
>
>
> The good news is that the compilation now works with both Java 7 and
> Java 8. The bad news however, is that at runtime when I try to use the
> method of a class that was woven, I get this error message for
> example:
>
> [junit] Caused by: java.lang.ClassFormatError: Duplicate field
> name&signature in class file
> org/exist/security/PermissionRequiredAspect
> [junit] at java.lang.ClassLoader.defineClass1(Native Method)
> [junit] at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
> [junit] at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
> [junit] at java.net.URLClassLoader.defineClass(URLClassLoader.java:455)
> [junit] at java.net.URLClassLoader.access$100(URLClassLoader.java:73)
> [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:367)
> [junit] at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
> [junit] at java.security.AccessController.doPrivileged(Native Method)
> [junit] at java.net.URLClassLoader.findClass(URLClassLoader.java:360)
> [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> [junit] at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> [junit] at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> [junit] at
> org.exist.security.UnixStylePermission.setMode(UnixStylePermission.java:237)
> [junit] at
> org.exist.collections.Collection.setPermissions(Collection.java:1917)
>
> I guess there is something wrong with my compilation steps and that I
> need to remove something from compilation at some stage? Can you
> advise please?
>
> My aspect is here
> https://github.com/adamretter/exist/blob/aspectj-updates/src/org/exist/security/PermissionRequiredAspect.java
> and an example of where that aspect is used (via the
> PermissionRequired annotation is here) -
> https://github.com/adamretter/exist/blob/aspectj-updates/src/org/exist/security/UnixStylePermission.java#L234
>
> Thanks Adam.
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
_______________________________________________
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users
