Re: [aspectj-users] Compile error with aspectj

[Andy Clement]

Hey. Nothing obvious leaps out to me but it would be easier to look at in a
sample project (I'm interested in the build configuration for example).
That kind of problem seems pretty fundamental which suggests a config thing
- or maybe a modules thing, are you attempting to build using Java9+ module
packaging/resolution of the dependencies? The absolute simplest thing would
be raise a https://github.com/eclipse/org.aspectj/issues with a sample
project attached that exhibits the problem, but I understand that can be a
bit of work. At minimum it would be good to see the pom/equivalent.

cheers,
Andy

On Fri, 14 Jan 2022 at 03:20, Mikael Petterson 
wrote:

> Hi,
>
> I have tried 1.9.7 and 1.9.8 up to RC3 but with no success to compile with
> the new elastic search client 7.16.2.
>
> I have added class content here.
>
> Do you see anything odd?
>
> br.
>
> //mike
>
>
> [INFO] Join point 'method-call(java.lang.Object
> java.lang.Class.newInstance())' in Type
> 'com.ericsson.commonlibrary.statisticscollectorframework.listeners.DataInjector'
> (DataInjector.java:183) advised by before advice from
> 'com.ericsson.commonlibrary.statisticscollectorframework.aspectj.DeprecatedMethodsAspect'
> (DeprecatedMethodsAspect.aj:30) [with runtime test]
> [ERROR] The import org.elasticsearch.common.unit.TimeValue cannot be
> resolved
>
> C:\Users\eraonel\git\statistics-collector-framework\src\main\java\com\company\commonlibrary\statisticscollectorframework\service\ElasticSearchService.java:42
> import org.elasticsearch.common.unit.TimeValue;
>^^
>
> [ERROR] The import org.elasticsearch.common.xcontent.XContentType cannot
> be resolved
>
> C:\Users\eraonel\git\statistics-collector-framework\src\main\java\com\company\commonlibrary\statisticscollectorframework\service\ElasticSearchService.java:43
> import org.elasticsearch.common.xcontent.XContentType;
>^
>
> [ERROR] XContentType cannot be resolved to a variable
>
> C:\Users\eraonel\git\statistics-collector-framework\src\main\java\com\company\commonlibrary\statisticscollectorframework\service\ElasticSearchService.java:267
> indexRequest = new IndexRequest(indexName, type).source(document,
> XContentType.JSON);
>
>
> [ERROR] TimeValue cannot be resolved
>
> C:\Users\eraonel\git\statistics-collector-framework\src\main\java\com\company\commonlibrary\statisticscollectorframework\service\ElasticSearchService.java:268
> indexRequest.timeout(TimeValue.timeValueSeconds(10));
>
>
> [ERROR] XContentType cannot be resolved to a variable
>
> C:\Users\eraonel\git\statistics-collector-framework\src\main\java\com\company\commonlibrary\statisticscollectorframework\service\ElasticSearchService.java:280
> indexRequest = new IndexRequest(indexName).source(document,
> XContentType.JSON);
>
>
>
> This is Timevalue class:
>
>
> /*
>  * Copyright Elasticsearch B.V. and/or licensed to Elasticsearch B.V.
> under one
>  * or more contributor license agreements. Licensed under the Elastic
> License
>  * 2.0 and the Server Side Public License, v 1; you may not use this file
> except
>  * in compliance with, at your election, the Elastic License 2.0 or the
> Server
>  * Side Public License, v 1.
>  */
>
> package org.elasticsearch.core;
>
> import java.util.Locale;
> import java.util.Objects;
> import java.util.concurrent.TimeUnit;
>
> public class TimeValue implements Comparable {
>
> /** How many nano-seconds in one milli-second */
> public static final long NSEC_PER_MSEC =
> TimeUnit.NANOSECONDS.convert(1, TimeUnit.MILLISECONDS);
>
> public static final TimeValue MINUS_ONE = timeValueMillis(-1);
> public static final TimeValue ZERO = timeValueMillis(0);
> public static final TimeValue MAX_VALUE =
> TimeValue.timeValueNanos(Long.MAX_VALUE);
>
> private static final long C0 = 1L;
> private static final long C1 = C0 * 1000L;
> private static final long C2 = C1 * 1000L;
> private static final long C3 = C2 * 1000L;
> private static final long C4 = C3 * 60L;
> private static final long C5 = C4 * 60L;
> private static final long C6 = C5 * 24L;
>
> private final long duration;
> private final TimeUnit timeUnit;
>
> public TimeValue(long millis) {
> this(millis, TimeUnit.MILLISECONDS);
> }
>
> public TimeValue(long duration, TimeUnit timeUnit) {
> if (duration < -1) {
> throw new IllegalArgumentException("duration cannot be
> negative, was given [" + duration + "]");
> }
> this.duration = duration;
> this.timeUnit = timeUnit;
> }
>
> public static TimeValue timeValueNanos(long nanos) {
> return new TimeValue(nanos, TimeUnit.NANOSECONDS);
> }
>
> public static TimeValue timeValueMillis(long millis) {
> return new TimeValue(millis, TimeUnit.MILLISECONDS);
> }
>
> public static TimeValue timeValueSeconds(long seconds) {
> return new TimeValue(seconds, TimeUni

[aspectj-users] AspectJ 1.9.7 released

[Andy Clement]

Hi everyone,

I'm pleased to announce AspectJ 1.9.7 is released.

To read more about the enhancements (like Java 15 and 16 support), take a
look at the readme here

.

The most serious change in 1.9.7 is actually to the project infrastructure.
I want to thank Alexander Kriegisch who has spent a significant amount of
effort on AspectJ 1.9.7 bringing it into the 21st century and making the
repository more approachable for new developers. This includes tackling
perhaps the most difficult problem which is how we manage the patch we make
to the Eclipse Compiler for Java in order to add AspectJ support. Rather
than a manually patched repo that was dropped as a binary into AspectJ, the
patched JDT Core is now a project in its own right:
https://github.com/eclipse/aspectj.eclipse.jdt.core. This repo can now be
kept up to date via regular git commands, and is now consumed as a proper
dependency by AspectJ.

If you want to get to grips with developing AspectJ, I encourage you to
checkout the repository readme
.

We are also now all in on GitHub. With 1.9.7 AspectJ is not a mirror of an
eclipse git repository, it is now a real repository against which pull
requests can be filed and processed. As part of this move we are also fully
embracing GitHub issues (rather than bugzilla) - so please raise anything
at GitHub in the future.

You can grab the standalone installer from the AspectJ releases page at
GitHub:
https://github.com/eclipse/org.aspectj/releases/tag/V1_9_7

And finally, the release is up at maven central !

Enjoy!
The AspectJ Team
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Openjdk11 and Security Manager

[Andy Clement]

I'd be nervous about that kind of change but interested to hear what you
learn.

Repository is here: https://github.com/eclipse/org.aspectj


Andy

On Wed, 9 Jun 2021 at 13:16, Constantin Moisei 
wrote:

> Thanks both Andy and Tim!
>
> As Tim pointed out we don't control the weaving, it happens during the app
> startup.
>
> I could look into what Tim mentions here, to just use compile time weaving
> but I need to do some research.
>
> My original thought was to create an alternate factory and allow it to use
> it's getClass().getClassloader(). I mean that could be a fix. I didn't
> check the source it but how is the classloader handled at this line
> (ReflectionBasedReferenceTypeDelegateFactory.java:40)
>
> >at java.base/java.lang.Class.forName(Class.java:398)
>  >at
> org.aspectj.weaver.reflect.ReflectionBasedReferenceTypeDelegateFactory.createDelegate
> (ReflectionBasedReferenceTypeDelegateFactory.java:40)
>
> Talking about sources, where is the repo ? I could create my own variant
> to see if I can bypass the issue.
>
>
> On Wed, 9 Jun 2021 at 15:05,  wrote:
>
>> I doubt you have any options here for runtime weaving. The classloader in
>> this case is controlled by Spring, and the security managers likely have a
>> tight multi-tenant designed security policy.
>>
>> The best bet, even with Spring is to change to compile-time weaving; this
>> was the answer for an app I developed in the same situation.
>>
>> Also, note that Java 11, and later versions of Spring all are getting
>> better at access control and fixing holes. Earlier versions of Spring used
>> to take advantage of the security holes in the JVM to work, many of these
>> security holes are getting closed off.
>>
>> You will also see more of these issues in the next LTS release (15 I
>> think is the number).
>>
>>
>>
>>
>>
>> Tim
>>
>>
>>
>> *From:* aspectj-users  *On Behalf Of *Andy
>> Clement
>> *Sent:* Wednesday, June 9, 2021 3:59 PM
>> *To:* aspectj-users@eclipse.org
>> *Subject:* Re: [aspectj-users] Openjdk11 and Security Manager
>>
>>
>>
>> Hey,
>>
>>
>>
>> I'm not an expert on Java Security unfortunately (you might find a few of
>> those folks if you ask this on Stack overflow?).
>>
>>
>>
>> With your reference to it working for one classloader and not another,
>> how feasible is it to set the context classloader to the one you find that
>> works? Or will that break something else?
>> (Thread.currentThread().setContextClassLoader(..))
>>
>>
>>
>> It is possible some doPrivileged blocks are missing in the reflection
>> area but then I see the doPrivileged call deeper in the checkPackageAccess
>> call, so maybe raising up the privileged check will just make it fail
>> sooner.
>>
>>
>>
>> cheers,
>>
>> Andy
>>
>>
>>
>> On Wed, 9 Jun 2021 at 10:00, Constantin Moisei <
>> constantin.moi...@gmail.com> wrote:
>>
>> Hello,
>>
>>
>> I am running into a weird exception on an open jdk 11 vm with a tight
>> security manager policy.
>>
>> What kind of control do I have to
>> ReflectionBasedReferenceTypeDelegateFactory ?
>>
>> In the past I had issues with how I get/handle the classloader but found
>> a way to bypass it. However it was my own code so I could deal with it. Now
>> I am facing a similar issue via the latest aspectj 1.9.6
>>
>>  //ClassLoader loader = Thread.currentThread().getContextClassLoader(); 
>> //doesn't work
>>
>>  ClassLoader loader = this.getClass().getClassLoader(); //< this works
>>
>> Note that granting the permission is not a viable solution. It will be
>> almost impossible to convince the vm owners to modify the policy. Has to be
>> a different way.
>>
>> Here's the full exception
>>
>> Caused by: java.security.AccessControlException: access denied 
>> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.loader")
>>at 
>> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>>at 
>> java.base/java.security.AccessController.checkPermission(AccessController.java:897)
>>at 
>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
>>at 
>> java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1238)
>>at java.base/java.la

Re: [aspectj-users] Openjdk11 and Security Manager

[Andy Clement]

Hey,

I'm not an expert on Java Security unfortunately (you might find a few of
those folks if you ask this on Stack overflow?).

With your reference to it working for one classloader and not another, how
feasible is it to set the context classloader to the one you find that
works? Or will that break something else?
(Thread.currentThread().setContextClassLoader(..))

It is possible some doPrivileged blocks are missing in the reflection area
but then I see the doPrivileged call deeper in the checkPackageAccess call,
so maybe raising up the privileged check will just make it fail sooner.

cheers,
Andy

On Wed, 9 Jun 2021 at 10:00, Constantin Moisei 
wrote:

> Hello,
>
> I am running into a weird exception on an open jdk 11 vm with a tight
> security manager policy.
>
> What kind of control do I have to
> ReflectionBasedReferenceTypeDelegateFactory ?
>
> In the past I had issues with how I get/handle the classloader but found a
> way to bypass it. However it was my own code so I could deal with it. Now I
> am facing a similar issue via the latest aspectj 1.9.6
>
>  //ClassLoader loader = Thread.currentThread().getContextClassLoader(); 
> //doesn't work ClassLoader loader = this.getClass().getClassLoader(); //< 
> this works
>
> Note that granting the permission is not a viable solution. It will be
> almost impossible to convince the vm owners to modify the policy. Has to be
> a different way.
>
> Here's the full exception
>
> Caused by: java.security.AccessControlException: access denied 
> ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.loader")
>   at 
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>   at 
> java.base/java.security.AccessController.checkPermission(AccessController.java:897)
>   at 
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
>   at 
> java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1238)
>   at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:691)
>   at java.base/java.lang.ClassLoader$1.run(ClassLoader.java:689)
>   at java.base/java.security.AccessController.doPrivileged(Native 
> Method)
>   at 
> java.base/java.lang.ClassLoader.checkPackageAccess(ClassLoader.java:689)
>   at java.base/java.lang.Class.forName0(Native Method)
>   at java.base/java.lang.Class.forName(Class.java:398)
>   at 
> org.aspectj.weaver.reflect.ReflectionBasedReferenceTypeDelegateFactory.createDelegate(ReflectionBasedReferenceTypeDelegateFactory.java:40)
>   at 
> org.aspectj.weaver.reflect.ReflectionWorld.resolveDelegate(ReflectionWorld.java:111)
>   at 
> org.aspectj.weaver.World.resolveToReferenceType(World.java:363)
>   at org.aspectj.weaver.World.resolve(World.java:258)
>   at org.aspectj.weaver.World.resolve(World.java:180)
>   at org.aspectj.weaver.World.resolve(World.java:326)
>   at 
> org.aspectj.weaver.reflect.ReflectionWorld.resolve(ReflectionWorld.java:103)
>   at 
> org.aspectj.weaver.reflect.ReflectionWorld.resolve(ReflectionWorld.java:93)
>   at 
> org.aspectj.weaver.reflect.ReflectionBasedReferenceTypeDelegateFactory.toResolvedTypeArray(ReflectionBasedReferenceTypeDelegateFactory.java:214)
>   at 
> org.aspectj.weaver.reflect.ReflectionBasedReferenceTypeDelegateFactory.createResolvedMethod(ReflectionBasedReferenceTypeDelegateFactory.java:107)
>   at 
> org.aspectj.weaver.reflect.ReflectionBasedReferenceTypeDelegateFactory.createResolvedMember(ReflectionBasedReferenceTypeDelegateFactory.java:98)
>   at 
> org.aspectj.weaver.reflect.ReflectionBasedReferenceTypeDelegate.getDeclaredMethods(ReflectionBasedReferenceTypeDelegate.java:290)
>   at 
> org.aspectj.weaver.ReferenceType.getDeclaredMethods(ReferenceType.java:571)
>   at 
> org.aspectj.weaver.ResolvedType.addAndRecurse(ResolvedType.java:271)
>   at 
> org.aspectj.weaver.ResolvedType.getMethodsWithoutIterator(ResolvedType.java:265)
>   at 
> org.aspectj.weaver.ResolvedType.lookupResolvedMember(ResolvedType.java:420)
>   at 
> org.aspectj.weaver.JoinPointSignatureIterator.findSignaturesFromSupertypes(JoinPointSignatureIterator.java:178)
>   at 
> org.aspectj.weaver.JoinPointSignatureIterator.findSignaturesFromSupertypes(JoinPointSignatureIterator.java:202)
>   at 
> org.aspectj.weaver.JoinPointSignatureIterator.findSignaturesFromSupertypes(JoinPointSignatureIterator.java:202)
>   at 
> org.aspectj.weaver.JoinPointSignatureIterator.hasNext(JoinPointSignatureIterator.java:69)
>   at 
> org.aspectj.weaver.patterns.SignaturePattern.matches(SignaturePattern.java:298)
>   at 
> org.aspectj.weaver.patterns.KindedPointcut.matchInternal(KindedP

Re: [aspectj-users] AspectJ + AJDT + AspectJ Maven development versions for Java 16 available

[Andy Clement]

The gap would be some of the more advanced intertype declaration usage. All
the advice language constructs and basic declare parents is possible with
annotation style today.

Andy

On Thu, 29 Apr 2021 at 05:12, Timothy Spear  wrote:

> Andy, Alexander,
>
> What is the gap between the custom language and the annotations?
> Has anyone proposed a tool to convert AsspectJ to annotations?
>
> Tim
>
> On Thu, Apr 29, 2021 at 7:52 AM Alexander Kriegisch <
> alexan...@kriegisch.name> wrote:
>
>> Thanks all for your encouragement.
>>
>> Concerning "AspectK", I think that it is not going to happen anytime
>> soon or at all, given the developer resource situation and my currently
>> modest level of knowledge, especially concerning parsing, AST,
>> compilation.
>>
>> What makes it so hard to keep AspectJ up to date is the native syntax
>> support. AJC is an ECJ fork. Imagine a parallel Kotlinc fork on top of
>> that. Getting rid of native syntax altogether, only supporting
>> annotation-style AOP, would be the easiest to maintain according to
>> Andy. This is not even considering keeping IDE support up to date. For
>> Eclipse this is done in AJDT, which is a nightmare to maintain, and for
>> IntelliJ JetBrains implemented it themselves, but never really finished
>> the job IMO. But then we would lose both the elegant, expressive syntax
>> and several features which just do not work in @AspectJ style. Anyway,
>> focusing on the present situation, you do have options to apply aspects
>> to Kotlin code, using LTW or binary weaving. If Andy ever gets around to
>> supporting invokedynamic (think: intercepting lambdas), I think that it
>> would be a step forward for all of CTW, LTW and binary weaving.
>>
>> Bottom line: We need to prioritise. I am doing this for fun, so I am
>> going to do whatever strikes me as interesting and is within the range
>> of my current capabilities. I might be able to do more in the future, if
>> by some miracle Andy ever gets bored of his awesome daytime job and has
>> time to mentor me. ;-)
>>
>> Anyway, we sent a message that AspectJ is far from dead, even though not
>> exactly running like a race horse.
>>
>> Cheers
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>>
>> Matthew Adams schrieb am 28.04.2021 21:06 (GMT +07:00):
>>
>> > Awesome.  I'm also a long-time AspectJ user and occasional supporter
>> (I'm a
>> > former SpringSource consultant from way back 2007-2008 and founding
>> > co-committer of Spring Data Cassandra).
>> >
>> > I've been working primarily in the Node.js space for the last 7+ years,
>> but
>> > have been keeping a little bit of an eye on developments in the Java
>> ecosystem.
>> > Kotlin has really caught my eye, and, after having been spoiled in Java
>> for so
>> > many years with AspectJ, I was hoping that I'd see first-class support
>> for AOP
>> > in Kotlin via "AspectK" or something, since, by the time we ceased Java
>> > development, ajc was our only compiler, if you can believe it.
>> >
>> > I know this is a lot to ask because I've felt Andy's been way
>> underresourced
>> > over the years and have truly feared the day Andy decides to hang it
>> up, but
>> > I'd really like to see a new compiler akc, similar to ajc, only for
>> Kotlin.
>> >
>> > Honestly, I don't understand why SpringSource/Pivotal/... doesn't
>> allocate more
>> > resources to such a crucial and awesome technology as AspectJ.
>> Further, given
>> > Spring's substantial adoption of Kotlin, why more effort hasn't gone
>> into a
>> > sister/twin effort for AOP in Kotlin (what I call "AspectK").
>> >
>> > What will it take for AspectK to be recognized as necessary and
>> resources
>> > allocated to it?
>> >
>> >> On Apr 28, 2021, at 2:43 AM, Alexander Kriegisch <
>> alexan...@kriegisch.name>
>> >> wrote:
>> >>
>> >> Hello AspectJ users community!
>> >>
>> >> You might know me as a fellow user who over the years asked or answered
>> >> questions, raised bugs or commented here. I also answer questions about
>> >> AspectJ and Spring AOP on StackOverflow, in order to unburden Andy
>> >> Clement as a maintainer from user support a little bit.
>> >>
>> >> Somewhat new is my role as an active contributor to the code bases of
>> 

Re: [aspectj-users] AspectJ + AJDT + AspectJ Maven development versions for Java 16 available

[Andy Clement]

I'll jump on the thread. Alexander has been doing some awesome (overdue)
work here, particularly around making it easier to keep pace with Java -
this has become even more urgent as the release cadence for Java has
accelerated. I don't see aspectj.dev as some rogue location, it is
Alexander working with me (well not really supported enough by me, but we
are communicating!) to get AspectJ to a better place for the future.  I can
see aspectj.dev replace repo.spring.io as the place for snapshot builds
going forward. With releases going into central as usual.  Alexanders work
means a Java 15/16 release is very close, when my plan was to just support
them all at the next LTS (17).

thanks Alexander!

cheers,
Andy

On Wed, 28 Apr 2021 at 07:06, Matthew Adams  wrote:

> Awesome.  I'm also a long-time AspectJ user and occasional supporter (I'm
> a former SpringSource consultant from way back 2007-2008 and founding
> co-committer of Spring Data Cassandra).
>
> I've been working primarily in the Node.js space for the last 7+ years,
> but have been keeping a little bit of an eye on developments in the Java
> ecosystem.  Kotlin has really caught my eye, and, after having been spoiled
> in Java for so many years with AspectJ, I was hoping that I'd see
> first-class support for AOP in Kotlin via "AspectK" or something, since, by
> the time we ceased Java development, ajc was our only compiler, if you can
> believe it.
>
> I know this is a lot to ask because I've felt Andy's been way
> underresourced over the years and have truly feared the day Andy decides to
> hang it up, but I'd really like to see a new compiler akc, similar to ajc,
> only for Kotlin.
>
> Honestly, I don't understand why SpringSource/Pivotal/... doesn't allocate
> more resources to such a crucial and awesome technology as AspectJ.
> Further, given Spring's substantial adoption of Kotlin, why more effort
> hasn't gone into a sister/twin effort for AOP in Kotlin (what I call
> "AspectK").
>
> What will it take for AspectK to be recognized as necessary and resources
> allocated to it?
>
> > On Apr 28, 2021, at 2:43 AM, Alexander Kriegisch <
> alexan...@kriegisch.name> wrote:
> >
> > Hello AspectJ users community!
> >
> > You might know me as a fellow user who over the years asked or answered
> > questions, raised bugs or commented here. I also answer questions about
> > AspectJ and Spring AOP on StackOverflow, in order to unburden Andy
> > Clement as a maintainer from user support a little bit.
> >
> > Somewhat new is my role as an active contributor to the code bases of
> >  ** AspectJ,
> >  ** AJDT (AspectJ Development Tools) for Eclipse IDE,
> >  ** AspectJ Maven Plugin.
> >
> > It all started with reading source code because I did not understand
> > something or wanted to know how to fix a tiny issue, then baby step by
> > step it somehow escalated into adding Java 15+16 support to AspectJ,
> > Java 13-16 support to AspectJ Maven and making AJDT work with the new
> > AspectJ version in its belly on Eclipse IDE 4.19 (2021-03). All of this
> > stuff is available for you to test, feedback is welcome. As I do not
> > have commit and deploy rights on Eclipse projects (yet), I just set up a
> > little Maven repository on my domain aspectj.dev.
> >
> > More details in this comment I posted on a recently merged GitHub pull
> > request:
> >
> > https://github.com/eclipse/org.aspectj/pull/41#issuecomment-826066012
> >
> > Best regards
> > --
> > Alexander Kriegisch
> > https://scrum-master.de
> > ___
> > aspectj-users mailing list
> > aspectj-users@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Is AspectJ compatible with Java 15?

[Andy Clement]

yeah, Java has started moving a little too quickly for my liking :) It is
quite complex folding in all the JDT changes each time (that process could
be improved, practically automated if the diffs were a bit neater I think).
I'm almost tempted to just update for LTS releases, possibly intermediate
ones if there is a key language change worth exposing, rather than chasing
every one.

cheers,
Andy

On Fri, 5 Feb 2021 at 09:05, Davide Perini 
wrote:

> Hi Alexander,
> thanks for your answer.
>
> Just using text blocks so not a big deal but I'm using JavaFX 15 so I
> can't comment for the JavaFX part.
>
> Thank you
> Davide
>
>
> Il 05/02/2021 11:28, Alexander Kriegisch ha scritto:
> > Ciao Davide.
> >
> > The latest stable release 1.9.6 [1] is compatible with Java 14. Which
> Java 15 features unavailable in Java 14 do you need? If you can compile to
> language level 14 or lower, binary weaving (post-compile or load time)
> should be fine. If your source code does not use any Java 15 features,
> direct compilation with 'ajc' should also be not problem.
> >
> > [1] https://www.eclipse.org/aspectj/doc/released/README-196.html
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Java 9+ modules questions

[Andy Clement]

I think you've found all there is. No-one is banging on the door for it to
improve - I don't actually see much use of the module system out there in
the wild so nothing has moved forward.

cheers,
Andy

On Thu, 17 Dec 2020 at 22:42, Alexander Kriegisch 
wrote:

> Okay I found these tests:
> https://github.com/eclipse/org.aspectj/tree/master/tests/bugs190/modules
>
> They are executed according to this configuration:
>
> https://github.com/eclipse/org.aspectj/blob/master/tests/src/test/resources/org/aspectj/systemtest/ajc190/ajc190.xml
>
> But I found no cases there in which both application and aspect module
> have module info files. The aspect always seems to be compiled without
> module info. In a way I understand that, because aspects are kind of
> orthogonal (as in cross-cutting) to aspects. Usually we do not want an
> application to be dependent on aspects and some more generic aspects
> should run with many different types of applications. So here we are
> hitting JMS limits. As a result, I cannot e.g. put an aspect module on
> an application module's module path in order to access e.g. an
> annotation contained in the aspect library along with the aspect. Ajc
> throws compile errors in this case. I would have to factor out the
> annotation into a separate module, so the application can use the
> annotation without the aspect. But then again the application must not
> contain a module info file, otherwise I get compile errors again because
> it cannot find the aspect (JMS) module. For now, whatever I am trying to
> do, the artifact containing aspect-woven code must refrain from defining
> a module info, AFAIU effectively breaking the encapsulation intended by
> previous JMS usage and putting everything into the default module,
> basically reverting it back to Java 8 standard.
>
> As for myself, I never used JMS before because for me it seems to bring
> more problems than benefits. For pure OOP-style applications JMS might
> work nicely and promote encapsulation and clean service interfaces,
> which is definitely something we would want. In order to marry the JMS
> concept with AOP though, I think the way it is implemented now makes the
> two of them more or less incompatible.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Alexander Kriegisch schrieb am 18.12.2020 09:59 (GMT +07:00):
>
> > All documentation I can find concerning JMS support in AspectJ 1.9.x
> > is this: https://www.eclipse.org/aspectj/doc/released/README-190.html
> >
> > I also see a few unimplemented features:
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=526242
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=526243
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=526244
> >
> > After adding support for 'ajc --module-path' to AspectJ Maven plugin I
> > experimented a bit with multi-module projects and found that it seems
> > to be impossible to do binary weaving by putting any AspectJ module (I
> > mean both Maven and JMS module with module-info.java) on the
> > aspect-path. In the read-me mentioned above there is just an example
> > of weaving the other way around, i.e. putting the target application
> > on the aspect module's in-path. Is that due to the missing
> > implementation of #526243? It does not help much if Ajc can compile
> > projects with module-info files but does not respect JMS semantics in
> > multi-module projects.
> >
> > Maybe I am doing something wrong. Are there any instructive tests in
> > the AspectJ source code you could point me to? The AspectJ module
> > structure is complicated, it is kind of difficult to find anything
> > there.
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Enum Value matching facility

[Andy Clement]

Hey,

It is quite an old issue. I thought I'd done something around enum matching
but I can't find it - I think maybe it was just in the context of enums
used in annotation values. Re-reading the issue now I don't see exactly
what it is asking for "Enum code requires Enum value JoinPoints." - if it
is enum specific joinpoints, I am super nervous about adding new joinpoints
because suddenly they will start affecting all existing code that was using
wildcards.  If you just want to guard on joinpoints related to enum related
operations there are type category patterns in
https://www.eclipse.org/aspectj/doc/released/README-169.html

Is it asking for static matching (vs runtime/dynamic matching) in join
points related to enums, that feels like it could be done without new join
points, just needs some improvements in the matching algorithm to recognize
enums in use.

cheers,
Andy

On Wed, 21 Oct 2020 at 07:12, Mohan Radhakrishnan <
radhakrishnan.mo...@gmail.com> wrote:

> Hi,
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=248681#c2
>
> This was a very old request I raised. I think the comment there means this
> is already implemented.
>
> But AJDT doesn't apply the pointcut. Was this implemented ?
>
> Thanks,
> Mohan
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] high JVM consumption on springboot-aspectj LTW

[Andy Clement]

There is a patch (and github fork) here
https://bugs.eclipse.org/bugs/show_bug.cgi?id=565450 that someone made that
is supposed to help I think - it isn't integrated because I haven't had
time to try it out and review it. If you feel like building an AspectJ to
try it out, that might be more evidence we should get integrated sooner
rather than later.

Andy

On Thu, 24 Sep 2020 at 20:18, Alexander Kriegisch 
wrote:

> Hi Rajendra.
>
> Thanks for the question and the hep dump screenshot. Compile time
> weaving (CTW) would not solve your latency problem. In comparison to
> load time weaving (LTW) you would only save time for class-loading
> during application start-up. After LTW is done, the application's
> performance should be the same as with CTW.
>
> Memory consumption and performance impact of AspectJ are strongly
> correlated with what your aspects do and how broadly they are applied to
> the target classes. So I am afraid without seeing your aspect code
> nobody will be able to help you. The number of aspects, pointcuts and
> advice is way less relevant than scope (pointcut) and content (advice
> method implementation) of the aspects as such. For example, a simple
> advice like this can be potentially super expensive:
>
> before() : call(* *(..)) {
>   doSomeExpensiveLogging();
>   useSomeExpensiveExternalResource();
> }
>
> Why? Because it would globally apply to each method call in your whole
> application. This would be just as slow as if without AOP you would add
> those method calls to each place in your code before calling methods. In
> most cases it is not AspectJ as such which causes huge overhead (even
> though both the runtime and the weaver of course consume a few
> resources, which usually is no problem, but what the aspect does and how
> many times. Hence, the problem usually sits in front of the keyboard,
> even though it is of course possible that there is a memory leak or
> other problem in AspectJ.
>
> Bottom line: Please provide more information, especially full aspect
> code. aop.xml would also be nice.
>
> Regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Rajendra Bhat schrieb am 25.09.2020 09:36 (GMT +07:00):
>
> > we observed around 10% latency overhead after adding aspectj LTW.
> > during the heap dump I observed lot memory consumption related to the
> > aspectj.
> >
> > Around 400 MB consumed by Aspecj, I have added 2 to 3 inteception.
> >
> > hereby attached heap dump details.
> >
> > please advise how to overcome on this..? We cannot use compile-time
> > weaving, because we adding aspect on the external jar.
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Proceeding with all arguments in native syntax

[Andy Clement]

I'm not totally surprised casting the joinpoint didn't work, I just hoped
:) I think we can probably get that to work. On the face of it your
proposal sounds reasonable for binding args. However, I still find it very
ugly that you can't just get the parameters that met the pointcut
constraints and get rid of all that code that retests whether they are
annotated, which is why I pointed to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233718

aspect X {
  // Note this advice will match and run multiple times - once for each
param
  void around(String paramToScrub): call(* *(..,@Scrubbed (String),..)) &&
args(paramToScrub) {  return proceed(scrubString(paramToScrub));
  }
  // More optimal perhaps, less nesting, probably easier to implement
  void around(org.aspectj.lang.MatchedArg[] args): call(* *(..@Scrubbed
(String),..)) && args(matchedArgs) {
 for (MatchedArg arg:args)
   arg.setValue(scrubString(arg.getValue());
 return proceed(args);
  }
}

Andy

On Fri, 4 Sep 2020 at 18:44, Alexander Kriegisch 
wrote:

> Bug 233718 is not really what I was concerned about.
>
> Casting thisJoinPoint to ProceedingJoinPoint was an idea I also had
> before, but the subsequent proceed(args) call returns null. If you run
> this aspect in native syntax against the sample classes in my SO
> answer...
>
> package de.scrum_master.aspect;
>
> import java.lang.annotation.Annotation;
> import java.lang.reflect.Method;
>
> import org.aspectj.lang.ProceedingJoinPoint;
> import org.aspectj.lang.SoftException;
> import org.aspectj.lang.reflect.MethodSignature;
>
> import de.scrum_master.app.Scrubbed;
>
> public aspect StringScrubberAspect {
>   Object around() : call(public * *(.., @de.scrum_master.app.Scrubbed
> (String), ..)) {
> Method method = ((MethodSignature)
> thisJoinPoint.getSignature()).getMethod();
> Object[] args = thisJoinPoint.getArgs();
> Annotation[][] parameterAnnotations = method.getParameterAnnotations();
> for (int argIndex = 0; argIndex < args.length; argIndex++) {
>   for (Annotation paramAnnotation : parameterAnnotations[argIndex]) {
> if (paramAnnotation instanceof Scrubbed)
>   args[argIndex] = scrubString((String) args[argIndex]);
>   }
> }
> try {
>   System.out.println(thisJoinPoint instanceof ProceedingJoinPoint);
>   Object result = ((ProceedingJoinPoint) thisJoinPoint).proceed(args);
>   System.out.println(result);
>   return result;
> } catch (Throwable t) {
>   throw new SoftException(t);
> }
>   }
>
>   private String scrubString(String string) {
> return string.replaceAll("[Ee]", "#");
>   }
> }
>
> ... the console log will be:
>
> true
> null
> true
> null
>
> How about extending 'args()' functionality in order to allow binding to
> an Object[] parameter which does not occur anywhere in the pointcut
> literal, automatically binding the equivalent of JoinPoint.getArgs() to
> it and thus allowing to proceed with the same bound parameter in both
> native and @AspectJ syntax? That would be kind of elegant, probably
> manageable from the perspective of pointcut parsing because there is no
> really new syntax, and the functionality to proceed with an Object[] is
> already in the code base, which is why it works in @AspectJ syntax.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Andy Clement schrieb am 05.09.2020 02:05 (GMT +07:00):
>
> > I feel like there are some bugs that talk around this topic, but I
> > can't quite find the one I'm thinking of. I found
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=233718 and it was
> > interesting to read what I was writing 12 years ago :) I feel like i
> > prototyped an improved arg matching system but I hit something
> > seriously complex before finishing, and wrote about it in bugzilla
> > somewhere...
> >
> > I don't think you are missing anything. Mixing the syntaxes should be
> > ok I think. Can you cast thisJoinPoint to a ProceedingJoinPoint in
> > AspectJ syntax around advice and use it? I can't quite remember.
> >
> >
> > On Thu, 3 Sep 2020 at 22:41, Alexander Kriegisch wrote:
> >
> >> Check this out:
> >> https://stackoverflow.com/a/63735393/1082681
> >>
> >> Is there anything I have overlooked? If so, how would I do that in
> >> native syntax? If not, would it be hard to implement?
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Proceeding with all arguments in native syntax

[Andy Clement]

I feel like there are some bugs that talk around this topic, but I can't
quite find the one I'm thinking of. I found
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233718 and it was interesting
to read what I was writing 12 years ago :)  I feel like i prototyped an
improved arg matching system but I hit something seriously complex before
finishing, and wrote about it in bugzilla somewhere...

I don't think you are missing anything. Mixing the syntaxes should be ok I
think. Can you cast thisJoinPoint to a ProceedingJoinPoint in AspectJ
syntax around advice and use it? I can't quite remember.

cheers,
Andy

On Thu, 3 Sep 2020 at 22:41, Alexander Kriegisch 
wrote:

> Hi Andy.
>
> Check this out: https://stackoverflow.com/a/63735393/1082681
>
> Is there anything I have overlooked? If so, how would I do that in
> native syntax? If not, would it be hard to implement?
>
> Cheers
> --
> Alexander Kriegisch
> https://scrum-master.de
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] AspectJ at Github

[Andy Clement]

Indeed I know it would be easy if pure GitHub, but it is an eclipse project
with connections to eclipse and the security permissions etc are managed on
the eclipse side by scripts syncing eclipse accounts with Github settings.
I don't know how they would handle the change. Maybe the leftover
forwarding thing would mean things 'just work' but my experiences over the
last few weeks make me skeptical.

cheers,
Andy

On Fri, 14 Aug 2020 at 15:59, Lars Grefer  wrote:

> Renaming a repository at GitHub should™ be no problem.
>
> If a repository is renamed using the GitHub UI, all links pointing at the
> old name will be forwarded to the new name/location.
>
> Lars
>
> Am 2020-08-14 23:36, schrieb Andy Clement:
>
> That reason would be lost in the mists of time. There is the related
> aspectj-shadows project that feeds into this one that is called
> org.aspectj.shadows too, but that is still a mirror rather than real repo
> at github. I'm open to a rename, depending on the pain and suffering it
> will cause. Things already feel a thousand times better than before though.
> (Thanks Lars for all the PRs !).
>
> Andy
>
> On Fri, 14 Aug 2020 at 13:52, Lars Grefer  wrote:
>
>> One small question about that: Why is the repository named "org.aspectj"
>> and not just "aspectj"?
>> The latter would produce nicer and more concise names and URLs.
>>
>> Greetings
>>   Lars Grefer
>>
>>
>> Am 2020-07-31 17:23, schrieb Andy Clement:
>>
>> Up until yesterday what was on Github was a mirror for AspectJ. This
>> meant you couldn't raise issues against it (you had to go back to
>> bugzilla), also any PRs that were submitted were very difficult to handle
>> because project committers couldn't process them easily.
>>
>> Today, the copy of aspectj at https://github.com/eclipse/org.aspectj should
>> be a full proper, Github repo! Woohoo!  The issues tab is alive and PRs
>> should work properly.
>>
>> cheers,
>> Andy
>>
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/aspectj-users
>>
>>
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] AspectJ at Github

[Andy Clement]

That reason would be lost in the mists of time. There is the related
aspectj-shadows project that feeds into this one that is called
org.aspectj.shadows too, but that is still a mirror rather than real repo
at github. I'm open to a rename, depending on the pain and suffering it
will cause. Things already feel a thousand times better than before though.
(Thanks Lars for all the PRs !).

Andy

On Fri, 14 Aug 2020 at 13:52, Lars Grefer  wrote:

> One small question about that: Why is the repository named "org.aspectj"
> and not just "aspectj"?
> The latter would produce nicer and more concise names and URLs.
>
> Greetings
>   Lars Grefer
>
>
> Am 2020-07-31 17:23, schrieb Andy Clement:
>
> Up until yesterday what was on Github was a mirror for AspectJ. This meant
> you couldn't raise issues against it (you had to go back to bugzilla), also
> any PRs that were submitted were very difficult to handle because project
> committers couldn't process them easily.
>
> Today, the copy of aspectj at https://github.com/eclipse/org.aspectj should
> be a full proper, Github repo! Woohoo!  The issues tab is alive and PRs
> should work properly.
>
> cheers,
> Andy
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] AspectJ at Github

[Andy Clement]

I don't plan on ignoring bugzilla in the near term, so I'll be keeping an
eye on both. I just feel migrating the 756 open issues, most of which will
never be addressed, creates an immediate mess in the project. I don't have
the cycles to review all 756 to see which subset might be fixed, or which
are good for first timers. Whereas the github project is almost a clean
slate at the moment and maybe can be kept on top of now in that state.

It took me an extra week just now to get commit rights to the repository,
bugzilla migration feels like a can of worms I don't want to get into right
now (maybe in the future, who knows). Wherever users raise issues, I will
be taking a look.

In some good news, I've already processed a couple of PRs against the
github project, so that is working now and someone kindly added the github
action support so builds are now happening! Exciting
https://github.com/eclipse/org.aspectj/actions?query=workflow%3A%22Java+CI+with+Maven%22

cheers,
Andy

On Sat, 1 Aug 2020 at 21:02, Alexander Kriegisch 
wrote:

> Talk is cheap, I am aware of that. So if I request Bugzilla issues to be
> migrated to GitHub issues and on top of that also request redirection, I
> know I am not the guy who has to do all the work. My argument here is
> that old issues are still a valuable source of information, even closed
> ones. IMO they are just as important as documentation, especially
> because documentation has not been updated for so long and everything
> about new features or bugfixes in AspectJ is only documented as release
> notes pointing to lists of issues.
>
> It looks like others have done such migrations before, here are a few
> links, [1] pointing to [2] and also mentioning re-using information
> created during the migration in order to implement redirection. [2] also
> mentions a dry-run option and links to some derivative tools based in
> itself. Maybe something there could be useful.
>
> The Python script under [3] looks more simplistic, I do not know if it
> would be adequate.
>
> There are also some answers under [4], maybe one of them could be
> helpful.
>
> [1] https://www.theozimmermann.net/2017/10/bugzilla-to-github/
> [2] https://github.com/berestovskyy/bugzilla2github
> [3]
> https://github.com/wilzbach/bugzilla-migration/blob/master/bugzilla2github.py
> [4] https://stackoverflow.com/q/7281304/1082681
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Andy Clement schrieb am 02.08.2020 07:09 (GMT +07:00):
> >
> >
> > I didn't dive into the details with the webmaster (yet) - he simply
> > offered archiving our bugzilla or continuing to use bugzilla - no
> > migration mentioned but I wouldn't want a full migration anyway, there is
> > too much old irrelevant stuff in there. I haven't spoken to him about
> > possible forwarding options either. If I could coordinate 'open bugzillas
> > updated in the last 1-2 years' or something like that for a migration,
> I'd
> > possibly try that.
> >
> > My current plan (obviously the laziest option) is just to continue with
> > both and gradually folks will stop using bugzilla, it doesn't get a ton
> of
> > traffic anyway. Github issues are the future from my point of view. The
> > README on the project should indicate that and anywhere else I can
> mention
> > it should also get updated to indicate that.
> >
> > cheers,
> > Andy
> >
> >
> > On Fri, 31 Jul 2020 at 20:17, Alexander Kriegisch
> > mailto:alexan...@kriegisch.name>
> > > wrote:
> >
> >> This is good news indeed, Andy. Thank you and everyone involved for
> >> this.
> >>
> >> For now there are no existing issues there, so I would like to know if
> >> in the future there will be two issue tracking systems or if there is
> >> any plan to migrate the Bugzilla issues to GitHub too. Or maybe Bugzilla
> >> will stay the leading system? Bugzilla contains lots of historical, but
> >> still relevant information, release notes, mailing list discussions and
> >> StackOverflow comments/answers are pointing there etc. But it is ugly,
> >> difficult to use, there is no text formatting etc. So migrating
> >> everything to GitHub in a batch process and automatically adding links
> >> (even if only as comments) from the Bugzilla issue to the corresponding
> >> GitHub issue would be a good thing to do. Automatic redirection would be
> >> even better, but probably difficult technically. In any case Bugzilla
> >> could stay active in a read-only mode.
> >>
> >> Having said that and reading it again, it sounds way more difficult than

Re: [aspectj-users] AspectJ at Github

[Andy Clement]

I didn't dive into the details with the webmaster (yet) - he simply offered
archiving our bugzilla or continuing to use bugzilla - no migration
mentioned but I wouldn't want a full migration anyway, there is too much
old irrelevant stuff in there. I haven't spoken to him about possible
forwarding options either. If I could coordinate 'open bugzillas updated in
the last 1-2 years' or something like that for a migration, I'd possibly
try that.

My current plan (obviously the laziest option) is just to continue with
both and gradually folks will stop using bugzilla, it doesn't get a ton of
traffic anyway. Github issues are the future from my point of view. The
README on the project should indicate that and anywhere else I can mention
it should also get updated to indicate that.

cheers,
Andy

On Fri, 31 Jul 2020 at 20:17, Alexander Kriegisch 
wrote:

> This is good news indeed, Andy. Thank you and everyone involved for
> this.
>
> For now there are no existing issues there, so I would like to know if
> in the future there will be two issue tracking systems or if there is
> any plan to migrate the Bugzilla issues to GitHub too. Or maybe Bugzilla
> will stay the leading system? Bugzilla contains lots of historical, but
> still relevant information, release notes, mailing list discussions and
> StackOverflow comments/answers are pointing there etc. But it is ugly,
> difficult to use, there is no text formatting etc. So migrating
> everything to GitHub in a batch process and automatically adding links
> (even if only as comments) from the Bugzilla issue to the corresponding
> GitHub issue would be a good thing to do. Automatic redirection would be
> even better, but probably difficult technically. In any case Bugzilla
> could stay active in a read-only mode.
>
> Having said that and reading it again, it sounds way more difficult than
> just migrating the Git repo.
>
> Best regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Andy Clement schrieb am 31.07.2020 22:23 (GMT +07:00):
> >
> >
> > Up until yesterday what was on Github was a mirror for AspectJ. This
> meant
> > you couldn't raise issues against it (you had to go back to bugzilla),
> > also any PRs that were submitted were very difficult to handle because
> > project committers couldn't process them easily.
> >
> >
> > Today, the copy of aspectj at
> > https://github.com/eclipse/org.aspectj should be a full
> > proper, Github repo! Woohoo! The issues tab is alive and PRs should work
> > properly.
> >
> >
> > cheers,
> >
> > Andy
> >
> >
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] AspectJ at Github

[Andy Clement]

Up until yesterday what was on Github was a mirror for AspectJ. This meant
you couldn't raise issues against it (you had to go back to bugzilla), also
any PRs that were submitted were very difficult to handle because project
committers couldn't process them easily.

Today, the copy of aspectj at https://github.com/eclipse/org.aspectj should
be a full proper, Github repo! Woohoo!  The issues tab is alive and PRs
should work properly.

cheers,
Andy
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] AspectJ 1.9.6 (Java14) released

[Andy Clement]

 > Will there be an AJDT release containing AJ 1.9.6?

There will be a dev build with 1.9.6 in it.


> Are there plans to use aspectjmatcher in Spring AOP instead of
 aspectjweaver? The latter only seems useful in Spring if used in
 connection with AspectJ LTW. This could be a great step ahead for
 Spring AOP with regard to making it more lightweight.

I think there will be some experiments now the artifact is out there. I'm
in touch with someone on the Spring team who was keeping an eye out for the
formal release of the artifact.

And heads up: the non-writable AspectJ at github where I cannot process PRs
is about to be replaced with a full workable version. This should enable
github issues to be used going forward too. I've manually processed all the
PRs I reasonably could - there was one giant one that I've moved to a
bugzilla issue so it isn't lost. They will all vanish when the project is
replaced.

cheers,
Andy


On Wed, 22 Jul 2020 at 20:09, Alexander Kriegisch 
wrote:

> Thanks Andy and Joseph for your work. Joseph really debugged into the
> guts of AspectJ, quite impressive! The artifacts have hit Maven Central
> and I had no issues upgrading one of my small private projects. Two
> questions:
>
>   1. Will there be an AJDT release containing AJ 1.9.6?
>
>   2. Are there plans to use aspectjmatcher in Spring AOP instead of
>  aspectjweaver? The latter only seems useful in Spring if used in
>  connection with AspectJ LTW. This could be a great step ahead for
>  Spring AOP with regard to making it more lightweight.
>
> Regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Andy Clement schrieb am 23.07.2020 03:01 (GMT +07:00):
> >
> >
> > Slightly later than I intended, AspectJ 1.9.6 is now available! It
> > includes support for Java14. There is a small example using the new
> Record
> > syntax in the readme:
> >
> > https://www.eclipse.org/aspectj/doc/released/README-196.html
> >
> >
> > One of the key issues fixed here was an intermittent verify error during
> > weaving:
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=550705 which
> > is fixed by a patch from Joseph MacFarlane (thanks Joseph). A tricky one
> > to get to the bottom of.
> >
> >
> > For the first time with 1.9.6 there is also an AspectJ matcher jar
> > published (aspectjmatcher) - this can be used for matching pointcuts
> > without bringing in all the weaver infrastructure. It can be useful in
> > some contexts (eg Spring AOP) where the matching is necessary but no
> > weaving. In particular I have seen cases where native-images (produced
> > with GraalVM) for Spring applications can benefit from just including the
> > matcher rather than the weaver, if that is all they need.
> >
> >
> > I am waiting for it to sync to central, it is on the regular download
> > page: https://www.eclipse.org/aspectj/downloads.php
> >
> >
> > My goal for 1.9.7 will be to *try* and sort out the github situation so
> we
> > can properly work on the project there (issue tracking and pull requests)
> >
> >
> > cheers,
> >
> > Andy
> >
> >
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] AspectJ 1.9.6 (Java14) released

[Andy Clement]

Slightly later than I intended, AspectJ 1.9.6 is now available! It includes
support for Java14. There is a small example using the new Record syntax in
the readme:
https://www.eclipse.org/aspectj/doc/released/README-196.html

One of the key issues fixed here was an intermittent verify error during
weaving: https://bugs.eclipse.org/bugs/show_bug.cgi?id=550705 which is
fixed by a patch from Joseph MacFarlane (thanks Joseph). A tricky one to
get to the bottom of.

For the first time with 1.9.6 there is also an AspectJ matcher jar
published (aspectjmatcher) - this can be used for matching pointcuts
without bringing in all the weaver infrastructure. It can be useful in some
contexts (eg Spring AOP) where the matching is necessary but no weaving. In
particular I have seen cases where native-images (produced with GraalVM)
for Spring applications can benefit from just including the matcher rather
than the weaver, if that is all they need.

I am waiting for it to sync to central, it is on the regular download page:
https://www.eclipse.org/aspectj/downloads.php

My goal for 1.9.7 will be to *try* and sort out the github situation so we
can properly work on the project there (issue tracking and pull requests)

cheers,
Andy
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Can I force around advice (especially for constructors) to be inlined?

[Andy Clement]

Yes, I had you banned because you keep causing me work ;)

No, but seriously - i just logged out then in ok, not aware of any issues.

Andy

On Fri, 29 May 2020 at 02:45, Alexander Kriegisch 
wrote:

> Hi Andy.
>
> I just wanted to create two Bugzilla tickets, but I cannot log into my
> Eclipse account anymore, even though I am 100% sure my e-mail & password
> are correct because I store them in a password manager and always use them
> to log in. Are there any known problems with the server or user database?
>
> I hope I will not forget to create the tickets later.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Andy Clement schrieb am 29.05.2020 02:54 (GMT +07:00):
>
> This was a deliberate decision back in the day, not to inline.  By keeping
> them separate you could iterate on the aspect (change the advice) without
> needing to rebuild the whole system. It also, initially, was necessary to
> enable debugging to work properly because the mapping attributes weren't
> possible in the old days (where you indicate the content of one class file
> is the result of different source files).
>
> The existence of the org.aspectj.matcher artifact as a separate entry to
> compiler/weaver was for cases where the matching infrastructure wanted to
> be used standalone. But I've never tried integrating it with another
> backend. Spring AOP does point cut matching but only against a subset of
> the possible joinpoints.
>
> I think forcing inlining (or at least attempting to, there are cases where
> it is hard - I think around advice proceed cases) would be a good option to
> have these days.
>
> cheers,
> Andy
>
> On Wed, 27 May 2020 at 20:58, Alexander Kriegisch <
> alexan...@kriegisch.name> wrote:
>
>> Actually it would be really good if inlining could be forced, e.g.
>> globally with a compiler switch or per aspect/advice with an annotation,
>> e.g. @Inline, if necessary with additional annotation parameters
>> instructing the compiler to only inline into constructors or whatever. The
>> annotation would work as a compiler directive in both native syntax and
>> @AspectJ style.
>>
>> As for this concrete case, of course it should be fixed in the compiler.
>> It fails at least since Java 11 (I assume since Java 9 but I have no JDK 9
>> installed in order to test). The problem does not occur in Java 8.
>>
>> The idea to (optionally) do more or even heavy inlining would be really
>> helpful for people who want to retransform loaded classes and not just
>> weave them during class loading. That would open up whole new ways of
>> AspectJ application incl. JDK weaving during runtime. I have played with
>> byte code engineering frameworks a bit lately, e.g. advising bootstrap
>> classes via ByteBuddy advice. I have also implemented what I showed you
>> here in Javassist, and it also works with bootstrap classes, even already
>> loaded ones, as long as all transformations are inlined. The downside is
>> the boilerplate I need in order to identify "joinpoints" for my
>> transformations because I cannot use AspectJ's matcher. Well, in theory
>> maybe I could (like Spring AOP does), but not the rest of AspectJ. There
>> are so many interesting options with inlining, until three weeks ago I had
>> no idea how much is possible.
>>
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>>
>>
>> Andrew Clement schrieb am 28.05.2020 00:03 (GMT +07:00):
>>
>> Of course, this is hard to detect by a compiler such as Ajc, but if there
>> was an option to force inlining the around advice for the constructor, this
>> scheme would work. So my questions are:
>>
>>1. Is there such an option? I did not find any obvious compiler
>>switch.
>>2. If not, do you see any chance to implement it, given technical
>>feasibility?
>>
>> The only force option you have is -XnoInline which forces the opposite of
>> what you want ;)
>>
>> Not 100% sure but the check about who can initially set some of those
>> fields seems more policed lately than in older versions of Java. (There
>> have been a few bugs reported about the ajc specific static initializer
>> block setting final static fields that never triggered an access error
>> before. I hadn’t seen it with instance fields though until you showed
>> this).  What version of Java are you trying it on? Did you try it on Java 8
>> to compare? (Just out of interest, I’m not saying that is the fix).
>>
>> I suspect we do need to do more inlining to fix this across the board.
>>
>>
>>
>

Re: [aspectj-users] Can I force around advice (especially for constructors) to be inlined?

[Andy Clement]

This was a deliberate decision back in the day, not to inline.  By keeping
them separate you could iterate on the aspect (change the advice) without
needing to rebuild the whole system. It also, initially, was necessary to
enable debugging to work properly because the mapping attributes weren't
possible in the old days (where you indicate the content of one class file
is the result of different source files).

The existence of the org.aspectj.matcher artifact as a separate entry to
compiler/weaver was for cases where the matching infrastructure wanted to
be used standalone. But I've never tried integrating it with another
backend. Spring AOP does point cut matching but only against a subset of
the possible joinpoints.

I think forcing inlining (or at least attempting to, there are cases where
it is hard - I think around advice proceed cases) would be a good option to
have these days.

cheers,
Andy

On Wed, 27 May 2020 at 20:58, Alexander Kriegisch 
wrote:

> Actually it would be really good if inlining could be forced, e.g.
> globally with a compiler switch or per aspect/advice with an annotation,
> e.g. @Inline, if necessary with additional annotation parameters
> instructing the compiler to only inline into constructors or whatever. The
> annotation would work as a compiler directive in both native syntax and
> @AspectJ style.
>
> As for this concrete case, of course it should be fixed in the compiler.
> It fails at least since Java 11 (I assume since Java 9 but I have no JDK 9
> installed in order to test). The problem does not occur in Java 8.
>
> The idea to (optionally) do more or even heavy inlining would be really
> helpful for people who want to retransform loaded classes and not just
> weave them during class loading. That would open up whole new ways of
> AspectJ application incl. JDK weaving during runtime. I have played with
> byte code engineering frameworks a bit lately, e.g. advising bootstrap
> classes via ByteBuddy advice. I have also implemented what I showed you
> here in Javassist, and it also works with bootstrap classes, even already
> loaded ones, as long as all transformations are inlined. The downside is
> the boilerplate I need in order to identify "joinpoints" for my
> transformations because I cannot use AspectJ's matcher. Well, in theory
> maybe I could (like Spring AOP does), but not the rest of AspectJ. There
> are so many interesting options with inlining, until three weeks ago I had
> no idea how much is possible.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
>
> Andrew Clement schrieb am 28.05.2020 00:03 (GMT +07:00):
>
> Of course, this is hard to detect by a compiler such as Ajc, but if there
> was an option to force inlining the around advice for the constructor, this
> scheme would work. So my questions are:
>
>1. Is there such an option? I did not find any obvious compiler switch.
>2. If not, do you see any chance to implement it, given technical
>feasibility?
>
> The only force option you have is -XnoInline which forces the opposite of
> what you want ;)
>
> Not 100% sure but the check about who can initially set some of those
> fields seems more policed lately than in older versions of Java. (There
> have been a few bugs reported about the ajc specific static initializer
> block setting final static fields that never triggered an access error
> before. I hadn’t seen it with instance fields though until you showed
> this).  What version of Java are you trying it on? Did you try it on Java 8
> to compare? (Just out of interest, I’m not saying that is the fix).
>
> I suspect we do need to do more inlining to fix this across the board.
>
>
>
> On May 21, 2020, at 2:52 AM, Alexander Kriegisch 
> wrote:
>
> Today I got a tricky one. I thought about opening a Bugzilla ticket, but
> this is actually more of a question, maybe a future feature request if what
> I want is technically possible at all. So it depends on your answer if I
> shall open a ticket or not.
>
> The requirement is simple (to explain, not to implement): I want to
> around-advise constructors in order suppress any side effects from
> happening there. The purpose would be to (ab)use AspectJ in order to create
> some kind of mock object which does not do anything expensive while being
> constructed. BTW, actually I am thinking about doing this with a library
> like ASM, but first I wanted to play with AspectJ in order to see what is
> possible there and create a proof of concept. But let me not get ahead of
> myself and set the stage first:
>
>  --
>
> package de.scrum_master.app;
>
> public class Base {
>   protected final int id;
>
>   public Base(int id) {
> System.out.println("Constructing Base -> " + this);
> this.id = id;
>   }
> }
>
> --
>
> package de.scrum_master.app;
>
> public class Sub extends Base{
>   private final String name;
>
>   public Sub(int id, String name) {
> super(id);
> System.out.printl

Re: [aspectj-users] Support for java 14

[Andy Clement]

First snapshots with Java14 are available. If you have a chance, please
kick the tires on it:

AspectJ 1.9.6.BUILD-SNAPSHOT


snapshots
snapshots
https://repo.spring.io/snapshot


It does work with Java14 features:

===8<=
public record Person(String firstName, String lastName, int age) {}
===8<=

===8<=
public class UsingPersonRecord {
  public static void main(String[] argv) {
Person p = new Person("A","B",99);
System.out.println(p);
System.out.println(p.firstName());
  }
}
===8<=

===8<=
public aspect TraceRecordComponents {
  before(): execution(public * *()) {
System.out.println(thisJoinPointStaticPart);
  }
}
===8<=
$ ajc --enable-preview -14 Person.java UsingPersonRecord.java
TraceRecordComponents.java

$ java --enable-preview UsingPersonRecord
execution(String Person.toString())
Person[firstName=A, lastName=B, age=99]
execution(String Person.firstName())
A

cheers,
Andy


On Tue, 14 Apr 2020 at 17:07, Andy Clement  wrote:

> Damn, someone noticed 14 was out :)  I hope to get to it in April. Out of
> interest are there any particular features you need from that version of
> Java?
>
> cheers,
> Andy
>
> On Tue, 14 Apr 2020 at 06:39, Ihor Mochurad  wrote:
>
>> I would like to know the answer to this question as well as my
>> organization would like to switch to java14 and lack of AspectJ support is
>> the blocker.
>>
>> On Tue, Apr 14, 2020 at 3:48 AM Mikael Petterson <
>> mikaelpetter...@hotmail.com> wrote:
>>
>>> Hi,
>>>
>>> Any plans to support java 14? When ?
>>>
>>> br,
>>>
>>> //mike
>>>
>>>
>>>
>>>
>>> ___
>>> aspectj-users mailing list
>>> aspectj-users@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/aspectj-users
>>>
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/aspectj-users
>>
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Support for java 14

[Andy Clement]

Damn, someone noticed 14 was out :)  I hope to get to it in April. Out of
interest are there any particular features you need from that version of
Java?

cheers,
Andy

On Tue, 14 Apr 2020 at 06:39, Ihor Mochurad  wrote:

> I would like to know the answer to this question as well as my
> organization would like to switch to java14 and lack of AspectJ support is
> the blocker.
>
> On Tue, Apr 14, 2020 at 3:48 AM Mikael Petterson <
> mikaelpetter...@hotmail.com> wrote:
>
>> Hi,
>>
>> Any plans to support java 14? When ?
>>
>> br,
>>
>> //mike
>>
>>
>>
>>
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/aspectj-users
>>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] LTW and JRE classes

[Andy Clement]

Hey

Re: -Djava.system.class.loader=org.aspectj.weaver.loadtime.Weavi
ngURLClassLoader

Been a while since I've tried that, I half expected that property not to
work, but (on Java8) if I set it and I set aj.aspect.path then I see
WeavingURLClassLoader kick in and try to work - it gets stuck in a
recursive invocation problem though. Not sure what that is.

Caused by: java.lang.IllegalStateException: recursive invocation
at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1443)
at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1429)
at java.util.ServiceLoader.loadInstalled(ServiceLoader.java:568)
at java.util.ResourceBundle.(ResourceBundle.java:376)
at org.aspectj.weaver.WeaverMessages.(WeaverMessages.java:19)
at
org.aspectj.weaver.bcel.ClassPathManager.addPath(ClassPathManager.java:103)


Re: weaving java/javax
I think we've often said if you need to do that, do it offline and used a
patched rt.jar/equivalent as it is more reliable. I can fully believe the
JDK has moved on in terms of class loading mechanisms and AspectJ hasn't
kept up.

cheers,
Andy

On Mon, 6 Apr 2020 at 05:15, Alexander Kriegisch 
wrote:

> One more question: What exactly is it good for to be able to replace the
> system classloader by WeavingURLClassLoader via:
>
>
> -Djava.system.class.loader=org.aspectj.weaver.loadtime.WeavingURLClassLoader
>
> For me this does not do anything without an additional weaving agent
> attached via '-javaagent:...'. Can you explain, maybe?
>
> Source code reference:
>
> https://github.com/eclipse/org.aspectj/blob/8c6b3ae13b105ce9bb9559de0ee4752cab5ba81c/loadtime/src/org/aspectj/weaver/loadtime/WeavingURLClassLoader.java#L48
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Alexander Kriegisch:
>
> > I tried '-verbose:class' both with normal LTW configuration and with
> > the weaving agent additionally prepended to the boot classpath via
> > '-Xbootclasspath/p:/my/path/aspectjweaver.jar"'. Except for the weaver
> > classes being loaded earlier in the latter case, the result is the
> > same:
> >
> > Only classes from AppClassLoader yield any AspectJ log message, woven
> > or not. JRE classes are being ignored, I see no other classloader
> > being attached. Actually there does not seem to be any specific debug
> > logging for names of attached classloaders at all, I only indirectly
> > see things like "[AppClassLoader@18b4aac2] debug not weaving
> > 'a.b..C'".
> >
> >
> > Andy Clement:
> >
> >>> Furthermore, both '-verbose:class' and '-verbose=class' yield
> >>> warnings
> >>
> >> That's not a weaver option, it is a JVM option for showing class
> >> loading. I thought pairing that with the -debug weaver option might
> >> show java types being loaded by the JVM and if there was no immediate
> >> weaver message then they weren't getting to the weaver.
> >>
> >> It is interesting what classloaders weavers get attached to. I can't
> >> what the current class loader hierarchy is in Java8 - do you only see
> >> the one weaver attached to application related class loader?
> >>
> >>
> >> Alexander Kriegisch:
> >>
> >>> Actually, I am still running Java 8, so modules are not an issue
> >>> here.
> >>>
> >>> Furthermore, both '-verbose:class' and '-verbose=class' yield
> >>> warnings:
> >>>
> >>> [MethodUtil@1e51f2fa] warning Cannot configure weaver with option
> >>> '-verbose:class': unknown option
> >>>
> >>> I run with these settings:
> >>>
> >>> 
> >>>   
> >>>   
> >>>   
> >>> 
> >>>
> >>> I see nothing on the console indicating that any JRE classes are
> >>> even visible to the classloader. I even created a main class
> >>> starting my other main class via Class.forName(), Class.getMethod()
> >>> and Method.invoke() in order to avoid javax or java JRE imports in
> >>> my main class, trying to avoid that the weaver kicks in too late. It
> >>> seems as if the weaver does not get attached to the right
> >>> classloader. Should I do more than just '-javaagent:...' and also
> >>> add the weaver to the boot classpath or something?
> >>>
> >>> I found a test related to javax classes, but that one is kinda
> >>> cheating because it tests with own classes in javax package not with
> >>> real JRE classes:
>

Re: [aspectj-users] Failing unit test that worked with java 1.8 is failing with java 11 using aspectj

[Andy Clement]

Hey,

Yes, both those bugs are fixed. They both relate to fields created by
AspectJ infrastructure.  The difference with this one is that it is a field
whose access is dictated by the JVM/Javac. It may not be quite as trivial
because removing 'final' from the serialVersionUID (I presume you are
asking AspectJ to add those fields?) creates some code that a compiler
would not create. If you try compiling a serializable object with a
serialVersionUID that is not marked final, you get a warning about the
visibility. Now is that just a javac concern and the code runs fine?
Mayyybeee. I'm just running all the AspectJ tests now with that field
changed to non final.

So it is another manifestation of those issues you linked but for a
slightly more tricky field to deal with. If you have a second, please raise
an issue, I can append what happens with the tests to that.

cheers,
Andy

On Mon, 30 Mar 2020 at 04:57, Mikael Petterson 
wrote:

> Hi,
>
> We tried to build our project, using
>
> 1.12.6
> 1.9.5
>
> But I met unit test errors:
> java.lang.IllegalAccessError: Update to static final field
> com.company.common.rm.Cell.serialVersionUID attempted from a different
> method (ajc$preClinit1) than the initializer method 
>   at com.company.common.rm.Cell.ajc$preClinit1(Cell.java:1)
>   at com.company.common.rm.Cell.ajc$preClinit(Cell.java:1)
>   at com.company.common.rm.Cell.(Cell.java:1)
>   at
> jdk.internal.reflect.GeneratedSerializationConstructorAccessor8.newInstance(Unknown
> Source)
>   at
> java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490)
>   at
> org.objenesis.instantiator.sun.SunReflectionFactoryInstantiator.newInstance(SunReflectionFactoryInstantiator.java:48)
>   at org.objenesis.ObjenesisBase.newInstance(ObjenesisBase.java:73)
>   at
> org.mockito.internal.creation.instance.ObjenesisInstantiator.newInstance(ObjenesisInstantiator.java:19)
>   at
> org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.createMock(InlineByteBuddyMockMaker.java:184)
>   at
> org.mockito.internal.util.MockUtil.createMock(MockUtil.java:35)
>   at org.mockito.internal.MockitoCore.mock(MockitoCore.java:63)
>   at org.mockito.Mockito.mock(Mockito.java:1908)
>   at org.mockito.Mockito.mock(Mockito.java:1817)
>   at
> com.company.common.rm.RmPropsimTest.setUp(RmPropsimTest.java:85)
>
> Any ideas?
>
>
> We found the following issues has been resolved:
>
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=516279
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=537825
>
> Are they?
>
> br,
>
> //mike
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] LTW and JRE classes

[Andy Clement]

> Furthermore, both '-verbose:class' and '-verbose=class' yield warnings

That's not a weaver option, it is a JVM option for showing class loading. I
thought pairing that with the -debug weaver option might show java types
being loaded by the JVM and if there was no immediate weaver message then
they weren't getting to the weaver.

It is interesting what classloaders weavers get attached to. I can't what
the current class loader hierarchy is in Java8 - do you only see the one
weaver attached to application related class loader?

cheers,
Andy

On Sat, 28 Mar 2020 at 00:31, Alexander Kriegisch 
wrote:

> Hi Andy.
>
> Actually, I am still running Java 8, so modules are not an issue here.
>
> Furthermore, both '-verbose:class' and '-verbose=class' yield warnings:
>
>   [MethodUtil@1e51f2fa] warning
>   Cannot configure weaver with option '-verbose:class':
>   unknown option
>
> I run with these settings:
>
> 
>   
>   
>   
> 
>
> I see nothing on the console indicating that any JRE classes are even
> visible to the classloader. I even created a main class starting my
> other main class via Class.forName(), Class.getMethod() and
> Method.invoke() in order to avoid javax or java JRE imports in my main
> class, trying to avoid that the weaver kicks in too late. It seems as if
> the weaver does not get attached to the right classloader. Should I do
> more than just '-javaagent:...' and also add the weaver to the boot
> classpath or something?
>
> I found a test related to javax classes, but that one is kinda cheating
> because it tests with own classes in javax package not with real JRE
> classes:
>
>
> https://github.com/eclipse/org.aspectj/tree/master/tests/features160/weavingJavaxPackage
>
> I really need some help to get started here.
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Andy Clement schrieb am 28.03.2020 00:51 (GMT +07:00):
> >
> >
> > I feel like they used to work but there were gotchas. For example the JVM
> > loads up some types before the LTW infrastructure can even get involved
> > and those can't be woven. I don't actually recall if we have testcases
> for
> > this but I wouldn't be surprised if they weren't there. I guess you have
> > tried them and they don't work - I wonder if you were test weaving
> > something that would be loaded early? It would be interesting to attempt
> > it with a -verbose:class and verify not attempting to weave things loaded
> > before the 'LTW is active' type messages come out. Will it work with
> > modules in recent Javas? That seems unlikely.
> >
> > But it could be the kind of classloaders in use in regular Java now don't
> > allow weaver attachment, I honestly haven't kept up to speed on that -
> and
> > maybe that prevents them working at all. A run of LTW with the debug
> > option on for the weaver should show the types the weaver is being
> exposed
> > to. If those are java/javax then they should be weavable.
> >
> > cheers,
> > Andy
> >
> >
> > On Fri, 27 Mar 2020 at 04:03, Alexander Kriegisch
> > mailto:alexan...@kriegisch.name>
> > > wrote:
> >
> >> Hallo Andy and other maintainers.
> >>
> >> The AspectJ documentation still mentions things like
> >>
> >> -Xset:weaveJavaxPackages=true
> >> -Xset:weaveJavaPackages=true
> >>
> >> or for LTW
> >>
> >> 
> >> 
> >> 
> >>
> >> (I think "java..*" would be correct syntax, BTW.)
> >>
> >> None of these work. Yes, there are valid cases in which users might want
> >> to use LTW on JRE classes. The only way I could ever weave into the JRE
> >> (execution joinpoints, not just call from my own woven code) was binary
> >> weaving and creating my own (subset of) JRE, prepending it to the boot
> >> classpath. But that's not nice and I never tried with modularised Java
> >> 9+, which might work or not.
> >>
> >> Before I create a Bugzilla ticket I would like to get a maintainer
> >> opinion. Is there any chance to make this work with AspectJ LTW? Is is
> >> maybe possible already and I just do it wrong?
> >>
> >> Regards
> >> --
> >> Alexander Kriegisch
> >> https://scrum-master.de
> >> ___
> >> aspectj-users mailing list
> >> aspectj-users@eclipse.org
> >> <mailto:aspectj-users@eclipse.org>
> >> To unsubscribe from this list, visit
> >> https://www.eclipse.org/mailman/listinfo/aspectj-users
> >
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] LTW and JRE classes

[Andy Clement]

I feel like they used to work but there were gotchas. For example the JVM
loads up some types before the LTW infrastructure can even get involved and
those can't be woven. I don't actually recall if we have testcases for this
but I wouldn't be surprised if they weren't there.  I guess you have tried
them and they don't work - I wonder if you were test weaving something that
would be loaded early?  It would be interesting to attempt it with a
-verbose:class and verify not attempting to weave things loaded before the
'LTW is active' type messages come out.  Will it work with modules in
recent Javas? That seems unlikely.

But it could be the kind of classloaders in use in regular Java now don't
allow weaver attachment, I honestly haven't kept up to speed on that - and
maybe that prevents them working at all. A run of LTW with the debug option
on for the weaver should show the types the weaver is being exposed to. If
those are java/javax then they should be weavable.

cheers,
Andy

On Fri, 27 Mar 2020 at 04:03, Alexander Kriegisch 
wrote:

> Hallo Andy and other maintainers.
>
> The AspectJ documentation still mentions things like
>
>   -Xset:weaveJavaxPackages=true
>   -Xset:weaveJavaPackages=true
>
> or for LTW
>
>   
>   
>   
>
> (I think "java..*" would be correct syntax, BTW.)
>
> None of these work. Yes, there are valid cases in which users might want
> to use LTW on JRE classes. The only way I could ever weave into the JRE
> (execution joinpoints, not just call from my own woven code) was binary
> weaving and creating my own (subset of) JRE, prepending it to the boot
> classpath. But that's not nice and I never tried with modularised Java
> 9+, which might work or not.
>
> Before I create a Bugzilla ticket I would like to get a maintainer
> opinion. Is there any chance to make this work with AspectJ LTW? Is is
> maybe possible already and I just do it wrong?
>
> Regards
> --
> Alexander Kriegisch
> https://scrum-master.de
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] AspectJ 1.9.5 (Java13) released

[Andy Clement]

Hi,

The latest update site contents here:
http://download.eclipse.org/tools/ajdt/410/dev/update

Now include AspectJ 1.9.6 build snapshot today (so all the 1.9.5 changes).
I know the version tag on the OSGi bundles mention 1.9.2 but trying to
change that to 1.9.6 I just broke everything so I reverted that -- for the
moment you would just have to trust that the contents of that version are
AspectJ 1.9.6 snapshot.

cheers,
Andy

On Tue, 4 Feb 2020 at 06:16, Peter Kirschner  wrote:

> Hi everybody,
>
> Will there be also an update for the Eclipse AJDT ?
> Latest version which I find is
>
> https://download.eclipse.org/tools/ajdt/410/dev/update/ajdt-e410-2.2.4.201911072000/
>
> Or is there another download location for it?
>
> kind regards,
>
> Peter
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] @DeclareParents with 'defaultImpl' not working when used in an aspect library

[Andy Clement]

I'll have a look when I get a chance.

cheers!
Andy

On Mon, 30 Dec 2019 at 18:37, Alexander Kriegisch 
wrote:

> Hi Andy!
>
> Please check out https://stackoverflow.com/a/59538952/1082681 (there is
> also a GitHub link) and tell me if it makes sense to file a bug ticket
> or you won't fix it anyway and just document the problem because
> @DeclareMixin works as an alternative in this situation. I would think
> it ought to be fixed as long as 'defaultimpl' is not deprecated.
>
> Kind regards
> --
> Alexander Kriegisch
> https://scrum-master.de
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] AspectJ 1.9.5 (Java13) released

[Andy Clement]

AspectJ 1.9.5 is now available. It includes support for Java13. There is a
small example using the new text blocks in the readme:
https://www.eclipse.org/aspectj/doc/released/README-195.html

Perhaps the most important fix in here relates to applying multiple
annotation style around advices on the same join point - if this has been
failing for you since 1.9.3, please try 1.9.5. It regressed due to a fix to
try and get the nesting of an around advice chain working reliably for
annotation style advice - at the time I was concerned about the lack of
tests and turns out I was right to be concerned!

I think it is in central now (I've certainly sent it up there) and it is on
the regular download page: https://www.eclipse.org/aspectj/downloads.php

I had one bug in from someone worrying about the references to the Java
Unsafe in weaver jar. Please be aware that Unsafe is only used if you are
on an older JDK (like 8). If you are on Java11, it will not be using Unsafe.

cheers,
Andy
___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Where is AJDT release build for eclipse 2019-06/4.12?

[Andy Clement]

Hmmm, right now they tend to be done as requested as I can't quite keep up
:)  But it may just be the metadata in the marketplace entry - have you
tried just using the AJDT build from the dev update site?
http://download.eclipse.org/tools/ajdt/410/dev/update ? (I know it says 410
but I think its what we use in  STS builds on later eclipses)

cheers,
Andy

On Fri, 13 Sep 2019 at 14:12, Matthew Adams  wrote:

> Hi all,
>
> Just wondering if AJDT releases are keeping up with eclipse releases.  I'm
> using 2019-06 (4.12) with Xtext, and need AspectJ, but the one on the
> eclipse Marketplace (
> https://marketplace.eclipse.org/content/aspectj-development-tools) isn't
> compatible with my version of eclipse (dragging & dropping "Install" button
> onto eclipse), and I only see dev builds for eclipse up to 2.10 at
> https://www.eclipse.org/ajdt/downloads/
>
> What's the currently advisable way to install AJDT for eclipse
> 2019-06/4.12 & later?
>
> TIA,
> Matthew
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] AJDT does not include aop.xml into output JAR

[Andy Clement]

I couldn't honestly tell you if that used to work. Feel free to raise a
bug, but I can't tell you it'd be at the top of my list ;) PRs welcome!

Andy

On Mon, 17 Jun 2019 at 20:05, Alexander Kriegisch 
wrote:

> I just opened one of my old LTW projects in Eclipse with current AJDT. I
> have src/META-INF/aop.xml and when I build to the default bin folder I see
> that bin/META-INF/aop.xml exists as expected. But when I activate "output
> JAR" in the AspectJ build settings, the generated JAR only contains
> META-INF/MANIFEST.MF with content
>
> Manifest-Version: 1.0
> Created-By: AspectJ Compiler
>
> but no aop.xml. This seems to be a bug, unless I am doing something
> stupid, putting my META-INF directory into the wrong place or so. If it is
> old or new I cannot remember. Anyway, it is a definite shortcoming, no
> matter whether it is a regression or has always been that way.
>
> Andy, any comments?
> --
> Alexander Kriegisch
> https://scrum-master.de
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Upgrade AspectJ Maven plugin to Java 11 (AspectJ 1.9.4)

[Andy Clement]

Thanks for mentioning that, I keep forgetting it. Wish I had the cycles to
sort that out, but I just can't seem to manage it. I am happy to support
anyone who does though!

cheers,
Andy

On Fri, 31 May 2019 at 21:44, Alexander Kriegisch 
wrote:

> I know that this mailing list is not for the AJM plugin but maybe the
> maintainers read it as they don't seem to read their tickets (or are too
> busy maybe, no offense meant).
>
> Java 11 and AspectJ 1.9.4 have been out for a while, but AJ Maven is
> still on version 1.11, supporting only Java 8 AFAIK. So if anyone wants
> to build with JDK 11 they have to use a forked plugin version such as
> com.nickwongdev:aspectj-maven-plugin:1.12.1. I think this is kinda
> suboptimal. Maybe someone can take the time to upgrade the plugin. :-)
>
> Best regards
> --
> Alexander Kriegisch
> https://scrum-master.de
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] 1.9.4 released

[Andy Clement]

Hmm, I feel like it might be saying that but it isn't true, since I tested
the IDE fixes 1.9.4 includes. So maybe the version stamp didn't get updated
correctly for the artifact (to 1.9.4 from 1.9.2).

I'll fix that up next time I do an update. Unless someone tells me the IDE
fixes aren't in fact in there, in which case it becomes more urgent (and
puzzling!)

cheers,
Andy

On Fri, 31 May 2019 at 05:53, Alexander Kriegisch 
wrote:

> > http://download.eclipse.org/tools/ajdt/410/dev/update
>
> Somehow in Eclipse 2018-12 the latest update is still based on AspectJ
> 1.9.2.
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Andrew Clement schrieb am 13.05.2019 22:19:
>
> > AspectJ 1.9.4 has been released. As described in the readme (
> > https://www.eclipse.org/aspectj/doc/released/README-194.html ) there
> > are two key changes in 1.9.4:
> >
> > - The new maven build process now being used damaged the ability for
> > the 1.9.3 aspectjweaver.jar to be used as an agent for load-time
> > weaving. This has been fixed.
> >
> > - In the IDE many folks were noticing a ClassCastException - this was
> > due to using a different version of java to run their IDE vs for the
> > project they were working on and AspectJ not handling it. For example
> > if using Java8 for the IDE and working on a Java11 project, there
> > would be a ClassCastException for “Object�? because Java8
> > couldn’t understand the new form of packaging in Java9+ for system
> > classes. This has been all tidied up and AJDT dev builds from
> > http://download.eclipse.org/tools/ajdt/410/dev/update include those
> > changes.
> >
> > 1.9.4 should be in central now, or can be grabbed from the downloads
> > page: https://eclipse.org/aspectj/downloads.php
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Formal support for Kotlin?

[Andy Clement]

Yeah, feel free to create one, we should have a place to collect
comments/feedback.

cheers,
Andy

On Tue, 14 May 2019 at 14:32, Matthew Adams  wrote:

> Understood, Andy.  Should I create an issue so that we can track this?
>
> On May 14, 2019, at 10:14 AM, Andy Clement 
> wrote:
>
> I would probably need to see a lot of demand before exploring an ajc like
> experience for Kotlin. It would be a very large amount of effort and binary
> weaving of the class files can get you a long way. If I had cycles to work
> on the compile time experience I'd probably prefer to put that into
> improving the annotation based model, but I know that isn't great for folks
> relying on inter type declarations and static checking at compile time.
>
> cheers,
> Andy
>
> On Tue, 14 May 2019 at 06:46, Matthew Adams 
> wrote:
>
>> No, Martin, I’m not experiencing these problems, and my mentioning Spring
>> was tangential.
>>
>> I’m basically asking that ajc support Kotlin source files.
>>
>> On May 13, 2019, at 5:43 PM, Martin Gainty  wrote:
>>
>> from what i see its not a matter of spring like or dislike..its a matter
>> of keeping JDK class file consist
>>
>> aj => .java => .class
>>
>> kt => .java => .class
>>
>> but this same scenario goes fubar when you switch JDKs ..this is an
>> example
>>
>> aj => 1_dot_eight.java => 1_dot_eight.class
>>
>> kt  => 1_dot_nine.java => 1_dot_none.class
>>
>> because spring is native compiled to 1.8 class format ..all .aj and all
>> .kt dsl files will compile to 1.8 class
>> access to class files in jar is no problem
>> doing reflection e.g. Class.forName(One_dot_eight); also no problem
>>
>> things fall apart quickly with aj, kt or .java files when you mix 1.8
>> class files with 1.9 class files
>>
>> (1.9 lambda functions fubar on accessing 1.8 class files)
>>
>> maven folk say full compile the whole lot to your runtime JDK will
>> supposedly cure this scenario
>>
>> is this what you're experiencing?
>>
>> martin-
>>
>> https://stackoverflow.com/questions/36780990/convert-inter-type-declaraton-from-aj-to-java-with-aspect-annotations
>>
>> https://stackoverflow.com/questions/34957430/how-to-convert-a-kotlin-source-file-to-a-java-source-file
>>
>> <https://stackoverflow.com/questions/34957430/how-to-convert-a-kotlin-source-file-to-a-java-source-file>
>> How to convert a kotlin source file to a java source file - Stack
>> Overflow - Stack Overflow - Where Developers Learn, Share, & Build Careers
>> <https://stackoverflow.com/questions/34957430/how-to-convert-a-kotlin-source-file-to-a-java-source-file>
>> To convert a Kotlin source file to a Java source file you need to (when
>> you in Android Studio):. Press Cmd-Shift-A on a Mac, or press Ctrl-Shift-A
>> on a Windows machine.. Type the action you're looking for: Kotlin Bytecode
>> and choose Show Kotlin Bytecode from menu. Press Decompile button on the
>> top of Kotlin Bytecode panel.; Now you get a Decompiled Java file along
>> with Kotlin file in a ...
>> stackoverflow.com
>>
>>
>>
>> <https://stackoverflow.com/questions/36780990/convert-inter-type-declaraton-from-aj-to-java-with-aspect-annotations>
>> aop - Convert Inter-Type declaraton from .aj to .java with Aspect
>> annotations - Stack Overflow - Stack Overflow - Where Developers Learn,
>> Share, & Build Careers
>> <https://stackoverflow.com/questions/36780990/convert-inter-type-declaraton-from-aj-to-java-with-aspect-annotations>
>> What you want is not possible with @AspectJ style, you need to use the
>> more powerful native syntax. (Why do you want to switch anyway?) The reason
>> behind this is that the Java compiler can only convert @DeclareParents to a
>> form in which Village is a subclass of whatever interface implementation
>> you define in your aspect, for example something like this:
>> stackoverflow.com
>>
>>
>> --
>> *From:* aspectj-users-boun...@eclipse.org <
>> aspectj-users-boun...@eclipse.org> on behalf of Matthew Adams <
>> matt...@matthewadams.me>
>> *Sent:* Monday, May 13, 2019 5:53 PM
>> *To:* aspectj-users@eclipse.org
>> *Subject:* [aspectj-users] Formal support for Kotlin?
>>
>> Hi all,
>>
>> I’ve been doing some googling around to see what I can find with regard
>> to using AspectJ with Kotlin.  Things don’t look particularly great at
>> first glance:
>> https://stackoverflow.com/questions/44364633/asp

Re: [aspectj-users] Formal support for Kotlin?

[Andy Clement]

I would probably need to see a lot of demand before exploring an ajc like
experience for Kotlin. It would be a very large amount of effort and binary
weaving of the class files can get you a long way. If I had cycles to work
on the compile time experience I'd probably prefer to put that into
improving the annotation based model, but I know that isn't great for folks
relying on inter type declarations and static checking at compile time.

cheers,
Andy

On Tue, 14 May 2019 at 06:46, Matthew Adams  wrote:

> No, Martin, I’m not experiencing these problems, and my mentioning Spring
> was tangential.
>
> I’m basically asking that ajc support Kotlin source files.
>
> On May 13, 2019, at 5:43 PM, Martin Gainty  wrote:
>
> from what i see its not a matter of spring like or dislike..its a matter
> of keeping JDK class file consist
>
> aj => .java => .class
>
> kt => .java => .class
>
> but this same scenario goes fubar when you switch JDKs ..this is an example
>
> aj => 1_dot_eight.java => 1_dot_eight.class
>
> kt  => 1_dot_nine.java => 1_dot_none.class
>
> because spring is native compiled to 1.8 class format ..all .aj and all
> .kt dsl files will compile to 1.8 class
> access to class files in jar is no problem
> doing reflection e.g. Class.forName(One_dot_eight); also no problem
>
> things fall apart quickly with aj, kt or .java files when you mix 1.8
> class files with 1.9 class files
>
> (1.9 lambda functions fubar on accessing 1.8 class files)
>
> maven folk say full compile the whole lot to your runtime JDK will
> supposedly cure this scenario
>
> is this what you're experiencing?
>
> martin-
>
> https://stackoverflow.com/questions/36780990/convert-inter-type-declaraton-from-aj-to-java-with-aspect-annotations
>
> https://stackoverflow.com/questions/34957430/how-to-convert-a-kotlin-source-file-to-a-java-source-file
>
> 
> How to convert a kotlin source file to a java source file - Stack Overflow
> - Stack Overflow - Where Developers Learn, Share, & Build Careers
> 
> To convert a Kotlin source file to a Java source file you need to (when
> you in Android Studio):. Press Cmd-Shift-A on a Mac, or press Ctrl-Shift-A
> on a Windows machine.. Type the action you're looking for: Kotlin Bytecode
> and choose Show Kotlin Bytecode from menu. Press Decompile button on the
> top of Kotlin Bytecode panel.; Now you get a Decompiled Java file along
> with Kotlin file in a ...
> stackoverflow.com
>
>
>
> 
> aop - Convert Inter-Type declaraton from .aj to .java with Aspect
> annotations - Stack Overflow - Stack Overflow - Where Developers Learn,
> Share, & Build Careers
> 
> What you want is not possible with @AspectJ style, you need to use the
> more powerful native syntax. (Why do you want to switch anyway?) The reason
> behind this is that the Java compiler can only convert @DeclareParents to a
> form in which Village is a subclass of whatever interface implementation
> you define in your aspect, for example something like this:
> stackoverflow.com
>
>
> --
> *From:* aspectj-users-boun...@eclipse.org <
> aspectj-users-boun...@eclipse.org> on behalf of Matthew Adams <
> matt...@matthewadams.me>
> *Sent:* Monday, May 13, 2019 5:53 PM
> *To:* aspectj-users@eclipse.org
> *Subject:* [aspectj-users] Formal support for Kotlin?
>
> Hi all,
>
> I’ve been doing some googling around to see what I can find with regard to
> using AspectJ with Kotlin.  Things don’t look particularly great at first
> glance:
> https://stackoverflow.com/questions/44364633/aspectj-doesnt-work-with-kotlin
>
> There are of course many more hits, but it appears the current state of
> the art is to compile with kotlin, then apply AspectJ to the kotlin .class
> files.
>
> Problem is, we have some libraries that we can only compile via ajc due to
> their design, so I’m wondering what thought has been given to adding kotlin
> language support to ajc.  I didn’t see any issues requesting Kotlin
> language support in ajc so far.  Kotlin looks promising, and it appears
> that Spring also is liking Kotlin enough to add support for it.  I’d love
> to have my Kotlin & AspectJ, too.
>
> Any comments, folks?
>
> -matthew
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delive

Re: [aspectj-users] JDK 12 support?

[Andy Clement]

I am hoping to get a 1.9.3 out very shortly, but that won't be Java12
compatible. If JDT is up to date I can get something out pretty quickly for
Java12 I imagine. Changing the syntax is always a little annoying as I have
to remerge and regenerate the parser, and the new syntax around switch
expressions suggests that'll be necessary. Shouldn't be rocket science
though, just manual effort.

cheers,
Andy

On Mon, 4 Mar 2019 at 12:22, Adam Rauch  wrote:

> Yes it is. Oracle has announced they are happy to provide long-term
> support to anyone who pays them for a commercial Java license. As of March
> 19, Oracle will no longer provide JDK 11 security / patch releases to the
> public. (Hence "end of public support".) Will AdoptOpenJDK or Amazon
> Coretto or somebody else step in to deliver OpenJDK 11 patch releases for
> free? Yet to be seen...
>
> Our clients have said they aren't interested in paying Oracle for their
> commercial runtime and they plan to simply switch to each major OpenJDK
> release at or shortly after it comes out. We plan to support this approach,
> but it means migrating all of our code to the latest JDK shortly after it's
> released.
>
> Oracle's official licensing / support policy:
> https://www.oracle.com/technetwork/java/javaseproducts/overview/javasesubscriptionfaq-4891443.html
>
> My attempt to summarize the Java rapid release cadence and Oracle's
> licensing changes to our clients:
> https://www.labkey.com/the-java-shake-up-what-it-means-to-labkey-and-you/
>
> Adam
> On 3/4/2019 11:53 AM, Andrei Ivanov wrote:
>
> Hmm,
> Isn't version 11 a LTS release?
> https://www.oracle.com/technetwork/java/java-se-support-roadmap.html
>
> On Mon, Mar 4, 2019 at 9:20 PM Adam Rauch  wrote:
>
>> With JDK 12 releasing in a couple weeks (which, of course, means "end of
>> public support" for JDK 11), I'm curious if there are plans to release a
>> JDK 12-compatible version of AspectJ.
>>
>> We're happy to provide some testing coverage on the new version, as we
>> did with 1.9.2.
>>
>> Thanks,
>> Adam Rauch
>> LabKey Software
>>
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/aspectj-users
>>
>
> ___
> aspectj-users mailing listaspectj-us...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, visithttps://www.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://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] ITD for type patterns, not just exact types

[Andy Clement]

On one hand it is resources, but I also think if you asked me to implement
ITDs today from scratch I wouldn’t do it in the same way anymore. Adding
new features that also extend use of that model I don’t like don’t get me
excited (especially when they result in me hacking JDT with more dirty
changes). Does type pattern matching for ITDs fall into that category?
Maybe, not sure. But rewriting it all, that would be a bunch of work.

On contributions: People do contribute now and again - and in fact I’d say
I’ve seen more contributions in the last year than in the preceeding 5
years. We only have APT support because somebody put in a lot of time a
couple of years ago to add it. But yes, it is mostly me - there are a
couple in the Spring Tools team who help me with AJDT because I don’t speak
Eclipse Plugin very well. They could work on AspectJ bugs in a pinch but I
can’t recall the last time there was an urgent bug, it is more like folks
demanding urgent support for the next Java level. I’m always happy to help
anyone get to grips with things and contribute but, yes, the build/test
infrastructure no doubt turns quite a few off because it is certainly not
as easy as it could be. And we don’t have so many of those ‘getting
started’ bugs for folks to grab. I'm going to do the maven build thing and
try and break down that barrier.

I know DeclareMixin isn't perfect and far from a total clean replacement
for what you can do with ITDs. I'm not sure I'd say it is totally  'non
static' though because once you've done the build those new methods are in
that target and can be called directly from any downstream code consuming
what you built as a dependency. But I know if trying to access those
members whilst in the same project it requires nasty casts. Working as a
pure weaver would also mean AJDT doesn't need to weave JDT, in fact AJDT
becomes much simpler, we can just use standard JDT tooling with an extra
builder that just does weaving.  I guess I'm just at the point that for any
new feature that introduces native syntax I'd be at least evaluating what
the non native syntax would be like and the pros/cons.

cheers,
Andy

On Jan 21, 2019, at 7:57 PM, Alexander Kriegisch 
wrote:

As for @DeclareMixin, I can se nothing new there in comparison to my native
syntax approach. You might remember that I very much favour native syntax,
even though it means more work for you with regard to (A)JDT. ;-) I would
be sad to see it go away. I can add all kinds of stuff via "declare
parents" or "@DeclareMixin", but all non-static. Even if my interface
contains Java 8 static methods, they will not be declared in (as in
compiled into) the mixin target class but remain on the interface. I.e., I
cannot use it like "MyTargetClass.logger" but only by ways of
"MyAspectMixinInterface.getLogger()", which would also mean that it is the
very same logger instance for every mixin target class. Usually you want a
different logger for each class in order to see its name logged during
usage.

Regards
-- 
Alexander Kriegisch
https://scrum-master.de


Andrew Clement schrieb am 22.01.2019 03:58:

I think there may be issues open for ITD on type patterns, I had a very
quick
look but couldn’t find them but it has been talked about before certainly.

I am wary of anything that makes ITDs more complicated as there are a few
‘hacks’ in JDT already to support them and I don’t really want to add any
more. I even had a vague thought (don’t panic) about removing code style
syntax and just using annotation style syntax (provided we had some form of
feature parity - annotation style syntax isn’t complete enough yet for
this).
I’ve been thinking about it for a while but the new speed with which Java is
moving is making the patching job something that has to be done more
frequently, and it isn’t fun. This would leave all development time simply
to
improve the weaving and fix bugs there.

But at least the type pattern syntax per se and the corresponding matching
rules already exist for normal (non-ITD) pointcuts, so maybe just the parser
needs to be extended and of course ITD generation itself (the process of
actually adding the same members, methods or constructors to a set of target
classes instead of a to single one) as well.


I’m really not sure what needs doing without digging into it, and I can’t
honestly say when I’ll find time for that. But I recognize the power of the
feature. How far can you get with a pattern on DeclareMixin?

Cheers,
Andy

On Jan 19, 2019, at 7:42 PM, Alexander Kriegisch 
wrote:

Hi Andy.

Do you think there is a chance to implement a feature request about enabling
ITD for groups of classes instead of having to know exact class names
beforehand? A typical example is that people on StackOverflow often ask
about
declaring static loggers via ITD. If this could be done in a more generic
way
by utilising type name patterns instead of fixed type names, I think it
would
be a huge and useful improvement. The only workaround thus far is to use
an

Re: [aspectj-users] Warning when using lombok's with aspectj

[Andy Clement]

I haven't done much investigation work into the combination. If you do it
in two steps you'd be fine (Lombok then binary weave) but that won't work
if you are doing static introductions from aspects that you need around for
your code to compile in the first place. If you tweaked Lombok to
additionally recognize the aspectj compiler like it recognizes JDT, that
may work (since AspectJ is based on the JDT compiler with a different
package name) but I've never tried it - you'd need to rebuild Lombok
yourself to try it out. Feels like that wouldn't be a totally unreasonable
contribution back to Lombok if it did behave.

cheers,
Andy

On Wed, 23 Jan 2019 at 23:59, Mikael Petterson 
wrote:

> Hi,
>
> Is there a way around this:
>
> https://github.com/rzwitserloot/lombok/issues/995
>
> br,
>
> //mikael
> 
> Can lombok work with aspectJ and maven together. · Issue #995 ·
> rzwitserloot/lombok · GitHub
> 
> Join GitHub today. GitHub is home to over 28 million developers working
> together to host and review code, manage projects, and build software
> together.
> github.com
>
>
>
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Generate ajdoc for site

[Andy Clement]

Thanks for sharing what worked for you !!!

Andy

On Wed, 12 Dec 2018 at 23:08, Mikael Petterson 
wrote:

> Hi Andy,
>
> Yes I have tried using it on the command line and it looks good.
>
> I think I worked out the xml in maven to get it working. I present it here
> ( so not just ripping the befenfits but also giving back what I can 😊 )
>
> 
> 
>   
>
> org.codehaus.mojo
> aspectj-maven-plugin
> ${aspectj.maven.plugin.version}
> 
>  ${java.version}
>  ${java.version}
>  ${java.version}
>  true
>  ${project.build.sourceEncoding}
>  true
>  true
>  true
>  warning
>  builddef-${project.name}.lst
>  
>   **/package-info.java
>  
> 
> 
>  
>   compile_with_aspectj
>   
>compile
>test-compile
>   
>  
>  
>
> * *
>
> *  ajdoc *
>
> *   *
>
> *   aspectj-report *
>
> *   *
>
> *  site *
> * *
> 
> 
>  
>   org.aspectj
>   aspectjtools
>   ${aspectj.version}
>  
> 
>
>   
>  
>
>
> 
>
> * *
>
> *  *
>
> *   *
>
> *   org.codehaus.mojo *
>
> *   aspectj-maven-plugin *
>
> *   ${aspectj.maven.plugin.version} *
>
> **
>
> *true *
>
> *true *
>
> *${java.version} *
>
> **
>
> **
>
> * *
>
> *  *
>
> *  aspectj-report *
>
> *  *
>
> * *
>
> **
> *  *
> **
>
> br,
>
> //mike
>
>
>
>
> --
> *Från:* aspectj-users-boun...@eclipse.org <
> aspectj-users-boun...@eclipse.org> för Andy Clement <
> andrew.clem...@gmail.com>
> *Skickat:* den 28 november 2018 19:26
> *Till:* aspectj-users@eclipse.org
> *Ämne:* Re: [aspectj-users] Generate ajdoc for site
>
> ajdoc is the one area of AspectJ I don't really know much about, other
> than trying to keep it limping along as Java versions update.
>
> Have you tried running ajdoc on the command line, does it do the right
> thing? If so then we know ajdoc is at least ok and we just have to work out
> the right XML incantation. Could be a good stack overflow question, unless
> a maven ajdoc expert is hanging out in here?
>
> cheers,
> Andy
>
> On Mon, 26 Nov 2018 at 02:02, Mikael Petterson <
> mikaelpetter...@hotmail.com> wrote:
>
> Hi,
>
> I have added the following in my pom.xml:
>
> 
> 
>  
>   
>org.codehaus.mojo
>aspectj-maven-plugin
>${aspectj.maven.plugin.version}
>
> true
> true
> ${java.version}
>
>
> 
>  
>   aspectj-report
>  
> 
>
>
>   
>  
> 
>
> When I execute:
>
>
> mvn clean compile site:site
>
> I see the following:
>
> [INFO] 1 report configured for maven-jxr-plugin:2.5: jxr
> [INFO] configuring report plugin
> org.codehaus.mojo:aspectj-maven-plugin:1.11.1-FORK
> [INFO] 1 report configured for aspectj-maven-plugin:1.11.1-FORK:
> aspectj-report
> [INFO] Rendering site with default locale English (en)
> [INFO] Relativizing decoration links with respect to localized project
> URL: http:///site/java-runtime-stats/collector/
> [INFO] Rendering content with
> org.apache.maven.skins:maven-fluido-skin:jar:1.7 skin.
> [INFO] Skipped "About" report
> (maven-project-info-reports-plugin:3.0.0:index), file "index.html" already
> exists.
> [INFO] Skipped "AspectJ Report" report
> (aspectj-maven-plugin:1.11.1-FORK:aspectj-report), file "index.html"
> already exists.
>
> And no reports is generated for ajdoc.
>
> Any idea what I am missing?
>
> br,
>
> //mikael
>
>
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Generate ajdoc for site

[Andy Clement]

ajdoc is the one area of AspectJ I don't really know much about, other than
trying to keep it limping along as Java versions update.

Have you tried running ajdoc on the command line, does it do the right
thing? If so then we know ajdoc is at least ok and we just have to work out
the right XML incantation. Could be a good stack overflow question, unless
a maven ajdoc expert is hanging out in here?

cheers,
Andy

On Mon, 26 Nov 2018 at 02:02, Mikael Petterson 
wrote:

> Hi,
>
> I have added the following in my pom.xml:
>
> 
> 
>  
>   
>org.codehaus.mojo
>aspectj-maven-plugin
>${aspectj.maven.plugin.version}
>
> true
> true
> ${java.version}
>
>
> 
>  
>   aspectj-report
>  
> 
>
>
>   
>  
> 
>
> When I execute:
>
>
> mvn clean compile site:site
>
> I see the following:
>
> [INFO] 1 report configured for maven-jxr-plugin:2.5: jxr
> [INFO] configuring report plugin
> org.codehaus.mojo:aspectj-maven-plugin:1.11.1-FORK
> [INFO] 1 report configured for aspectj-maven-plugin:1.11.1-FORK:
> aspectj-report
> [INFO] Rendering site with default locale English (en)
> [INFO] Relativizing decoration links with respect to localized project
> URL: http:///site/java-runtime-stats/collector/
> [INFO] Rendering content with
> org.apache.maven.skins:maven-fluido-skin:jar:1.7 skin.
> [INFO] Skipped "About" report
> (maven-project-info-reports-plugin:3.0.0:index), file "index.html" already
> exists.
> [INFO] Skipped "AspectJ Report" report
> (aspectj-maven-plugin:1.11.1-FORK:aspectj-report), file "index.html"
> already exists.
>
> And no reports is generated for ajdoc.
>
> Any idea what I am missing?
>
> br,
>
> //mikael
>
>
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Pointcut parser skips superfluous closing parenthesis and everything that follows

[Andy Clement]

You know I feel like I've seen that before, and done the same debugging you
did. It may even be an open issue on Spring AOP. I don't mind a ticket to
make us a little more strict there.

cheers,
Andy.

On Sun, 25 Nov 2018 at 01:53, Alexander Kriegisch 
wrote:

> Hi Andy.
>
> I found something on SO, debugged a bit through the AspectJ source code
> and saw that this happens:
>
> https://stackoverflow.com/a/53466329/1082681
>
> I tested with AspectJ 1.8.9 and have not verified whether it is the same
> in 1.8.13 or 1.9.2. If so, do you think this is worth a Bugzilla ticket
> with regard to the PatternParser class?
>
> Regards
> --
> Alexander Kriegisch
> https://scrum-master.de
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Tips about AspectJ and Java Module System to improve modularity

[Andy Clement]

Hey!

Honestly the big hurdle with AspectJ 1.9.0 was just to support the module
system, i.e. how they had repackaged the JDK. There are many things we
could do, but haven't found the bandwidth yet. The faster release cadence
for the JDK means we seem to be spending more time just keeping up (see the
1.9.2 that just came out to support Java11).

If you look in the 1.9.0 readme I put a small example of working with
AspectJ and the module system:
https://www.eclipse.org/aspectj/doc/released/README-190.html - both a
source and binary weaving example. We do ship the AspectJ elements
(weaver/runtime/compiler) as automatic modules so they will play nicely in
that world. Perhaps the key drawback at the moment is that if you do use
aspects to connect some modules together that may require updates to the
module-info file and currently AspectJ does not 'weave' that to update it -
you have to do it manually. We also don't have inpath equivalents of
module-path (i.e. an inpath where module constraints are enforced).  Wish I
had more for you but that's as far as I've gotten lately.

cheers,
Andy

On Wed, 31 Oct 2018 at 13:08, Julio Beverido  wrote:

> Dear AspectJ Community,
>
> I’m a rookie in AspectJ and recently i’ve been researching about the Java
> Module System combined with AspectJ to improve modularity. I was wondering
> if you could help me with some tips that can allow me to work with the
> available AspectJ material in order to do good modular practices.
>
> Best regards,
>
> Julio Beverido
>
>
>
> Enviado desde Correo 
> para Windows 10
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] [WARNING] can not build thisJoinPoint lazily for this advice since it has no suitable guard

[Andy Clement]

You could use an lint option to turn that off. See
https://www.baeldung.com/aspectj where he uses:

ignore

Andy

On Fri, 26 Oct 2018 at 01:08, Mikael Petterson 
wrote:

> Hi Andy!
>
> I managed to solve the test compilation problem for my  aspect using
> stackoverflow 😊
>
> Now when I compile I see the following warning:
>
>  [WARNING] can not build thisJoinPoint lazily for this advice since it
> has no suitable guard [Xlint:noGuardForLazyTjp]
>
> /repo/eraonel/git/java-runtime-stats/target/classes!com/ericsson/commonlibrary/javaruntimestats/aspects/DeprecatedMethodsAspect.class:34
>
>
>
> What do I need to do to get rid of the warning?
>
>
> br,
>
>
> //mikael
>
>
> This is my aspect:
>
>
> public aspect DeprecatedMethodsAspect  {
>
> private  DeprecatedMethods deprecatedMethods = new
> DeprecatedMethodsImpl();
>
> //Pointcuts to match joinpoint.
> pointcut deprecated() :
> @annotation(Deprecated) && (call(public * *(..)) ||
> call(*.new(..)));
>
> pointcut beta() :
> @annotation(com.google.common.annotations.Beta);
>
> pointcut deprecatedMethods() :
> deprecated() && !beta();
>
>
> before() : deprecatedMethods() {  //This is the line that compiler
> warns for.
> deprecatedMethods.collect(thisJoinPoint);
> }
>
> @VisibleForTesting
> public void setDeprecatedMethods(DeprecatedMethods deprecatedMethods) {
> this.deprecatedMethods = deprecatedMethods;
> }
>
>
>
> }
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Aspect enabled

[Andy Clement]

Hi Mikael,

In order to support the woven advice at runtime, there are a few types you
need to have around. For this reason when you run your woven app you should
also include the small aspectjrt.jar (aspectj runtime). It defines some
common types like exception types that AspectJ might throw.  If you did
compile time weave then there isn't anything else you need to do when you
run it (you don't need the weaver agent for example).

Andy

On Tue, 23 Oct 2018 at 06:26, Mikael Petterson 
wrote:

> Hi,
>
> I have an aspect ( aspectj ) in a library. I make another java app
> dependent on this library. Then I weave the aspect library in at compile
> time e.g. building the java application.
> Will the aspect be enabled, when pointcut matches, by default when I run
> the application? I guess I don't have to do anything extra or?
>
> br,
>
> //mikael
>
>
>
>
> ___
> 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

Re: [aspectj-users] Java 11 Compatibility check: AspectJ

[Andy Clement]

I've been working towards an RC3 - I wanted to get some specific bug fixes
in and I was working with someone on getting a pull request into shape that
I could accept. That is all in now, just tested the final change I wanted
that fixes an AJDT issue related to annotation processing. So I think I'm
good to cut this RC3, if that goes ok then final in a few days.

Andy

On Mon, 15 Oct 2018 at 03:47, Lubo Pecho  wrote:

> Hello, when do you expect to release final version of 1.9.2. Or have I
> missed something?
>
> On Tue, Oct 2, 2018 at 6:44 AM Andy Clement 
> wrote:
>
>> AspectJ 1.9.2.RC2 is now in the usual maven milestone repo where we put
>> the non final releases:
>>
>> 
>> maven.springframework.org
>> SpringSource milestones
>> http://maven.springframework.org/milestone
>> 
>>
>> This RC2 brings things more in line with the very latest JDT Core, which
>> we needed for some fixes related to the new nest based access control
>> attributes in JDK11 ( http://openjdk.java.net/jeps/181 ).
>>
>> cheers,
>> Andy
>>
>> On Oct 1, 2018, at 9:48 AM, Andy Clement 
>> wrote:
>>
>> Hey,
>>
>> I was tied up at Spring One last week, not to mention my laptop broke.
>> I’m now back in the office and I hope to further polish up 1.9.2 this week.
>> I will get the RC into maven central first so those that want to consume it
>> can kick the tires on it that way. Yes, the ClassNotFoundException you
>> mention is exactly what I’d expect to see using an old AspectJ.
>>
>> I’d appreciate any/all feedback on this RC so that 1.9.2 can be a decent
>> release. If I get some feedback that it seems to be behaving for folks then
>> that’ll give me confidence to maybe release it at the end of this week.
>>
>> cheers,
>> Andy
>>
>> On Oct 1, 2018, at 6:27 AM, Lubo Pecho  wrote:
>>
>> Thanks, I did not realize all the aspectj libraries would be packed
>> inside the jar. It seems I got past the ClasstNotFoundException. Of course
>> we will need to do full regress tests. Is there any estimate, when the
>> 1.9.2 version could became final?
>>
>>
>> On Mon, Oct 1, 2018 at 2:30 PM Andrei Ivanov 
>> wrote:
>>
>>> Hi Lubo,
>>> You can use the RC1 in the link from the mail you've replied to test it,
>>> it was created for this purpose :)
>>>
>>> On Mon, Oct 1, 2018 at 2:01 PM Lubo Pecho  wrote:
>>>
>>>> We're trying to run our application with LTW on openjdk 11. Is the
>>>> aspectjweaver ready for java 11? The old aspectjweaver seems not to
>>>> generate any ajc runtime classes.
>>>>
>>>> It always fails on equivalent excpetion.
>>>>
>>>> Caused by: java.lang.ClassNotFoundException:
>>>> somepackage.SomeClass$AjcClosure{someNumber}
>>>>
>>>> Would it be possible to build aspectjweaver 1.9.2 release candidate. We
>>>> need to upgrade to java 11 in november, so we'd like to test it to
>>>> determine, if we need to find some other solution.
>>>>
>>>> With Regards,
>>>> Lubos Pecho
>>>> ___
>>>> 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
>>
>> ___
>> 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
>
> ___
> 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

Re: [aspectj-users] Java 11 Compatibility check: AspectJ

[Andy Clement]

AspectJ 1.9.2.RC2 is now in the usual maven milestone repo where we put the non 
final releases:

maven.springframework.org
SpringSource milestones
http://maven.springframework.org/milestone

This RC2 brings things more in line with the very latest JDT Core, which we 
needed for some fixes related to the new nest based access control attributes 
in JDK11 ( http://openjdk.java.net/jeps/181 <http://openjdk.java.net/jeps/181> 
).

cheers,
Andy

> On Oct 1, 2018, at 9:48 AM, Andy Clement  wrote:
> 
> Hey,
> 
> I was tied up at Spring One last week, not to mention my laptop broke. I’m 
> now back in the office and I hope to further polish up 1.9.2 this week. I 
> will get the RC into maven central first so those that want to consume it can 
> kick the tires on it that way. Yes, the ClassNotFoundException you mention is 
> exactly what I’d expect to see using an old AspectJ.
> 
> I’d appreciate any/all feedback on this RC so that 1.9.2 can be a decent 
> release. If I get some feedback that it seems to be behaving for folks then 
> that’ll give me confidence to maybe release it at the end of this week.
> 
> cheers,
> Andy
> 
>> On Oct 1, 2018, at 6:27 AM, Lubo Pecho > <mailto:tomorro...@gmail.com>> wrote:
>> 
>> Thanks, I did not realize all the aspectj libraries would be packed inside 
>> the jar. It seems I got past the ClasstNotFoundException. Of course we will 
>> need to do full regress tests. Is there any estimate, when the 1.9.2 version 
>> could became final?
>> 
>> 
>> On Mon, Oct 1, 2018 at 2:30 PM Andrei Ivanov > <mailto:andrei.iva...@gmail.com>> wrote:
>> Hi Lubo,
>> You can use the RC1 in the link from the mail you've replied to test it, it 
>> was created for this purpose :)
>> 
>> On Mon, Oct 1, 2018 at 2:01 PM Lubo Pecho > <mailto:tomorro...@gmail.com>> wrote:
>> We're trying to run our application with LTW on openjdk 11. Is the 
>> aspectjweaver ready for java 11? The old aspectjweaver seems not to generate 
>> any ajc runtime classes.
>> 
>> It always fails on equivalent excpetion.
>> 
>> Caused by: java.lang.ClassNotFoundException: 
>> somepackage.SomeClass$AjcClosure{someNumber}
>> 
>> Would it be possible to build aspectjweaver 1.9.2 release candidate. We need 
>> to upgrade to java 11 in november, so we'd like to test it to determine, if 
>> we need to find some other solution.
>> 
>> With Regards,
>> Lubos Pecho
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org <mailto: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 
>> <https://dev.eclipse.org/mailman/listinfo/aspectj-users>___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org <mailto: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 
>> <https://dev.eclipse.org/mailman/listinfo/aspectj-users>___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org <mailto: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

Re: [aspectj-users] Java 11 Compatibility check: AspectJ

[Andy Clement]

Hey,

I was tied up at Spring One last week, not to mention my laptop broke. I’m now 
back in the office and I hope to further polish up 1.9.2 this week. I will get 
the RC into maven central first so those that want to consume it can kick the 
tires on it that way. Yes, the ClassNotFoundException you mention is exactly 
what I’d expect to see using an old AspectJ.

I’d appreciate any/all feedback on this RC so that 1.9.2 can be a decent 
release. If I get some feedback that it seems to be behaving for folks then 
that’ll give me confidence to maybe release it at the end of this week.

cheers,
Andy

> On Oct 1, 2018, at 6:27 AM, Lubo Pecho  wrote:
> 
> Thanks, I did not realize all the aspectj libraries would be packed inside 
> the jar. It seems I got past the ClasstNotFoundException. Of course we will 
> need to do full regress tests. Is there any estimate, when the 1.9.2 version 
> could became final?
> 
> 
> On Mon, Oct 1, 2018 at 2:30 PM Andrei Ivanov  > wrote:
> Hi Lubo,
> You can use the RC1 in the link from the mail you've replied to test it, it 
> was created for this purpose :)
> 
> On Mon, Oct 1, 2018 at 2:01 PM Lubo Pecho  > wrote:
> We're trying to run our application with LTW on openjdk 11. Is the 
> aspectjweaver ready for java 11? The old aspectjweaver seems not to generate 
> any ajc runtime classes.
> 
> It always fails on equivalent excpetion.
> 
> Caused by: java.lang.ClassNotFoundException: 
> somepackage.SomeClass$AjcClosure{someNumber}
> 
> Would it be possible to build aspectjweaver 1.9.2 release candidate. We need 
> to upgrade to java 11 in november, so we'd like to test it to determine, if 
> we need to find some other solution.
> 
> With Regards,
> Lubos Pecho
> ___
> 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 
> ___
> 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

Re: [aspectj-users] Java 11 Compatibility check: AspectJ

[Andy Clement]

Hey Michael,

I will try to get some kind of build together before end of next week when
I head to Spring One. If that goes well an initial release could be end of
the month. It should just be an update to the latest Eclipse JDT that
supports it - this is quite a mechanical process. If there aren't big
disturbances coming in (like modules was), the release may even come sooner.

cheers
Andy

On Thu, 13 Sep 2018 at 08:09, scmikes  wrote:

> Quick question,
>
> Since java 8 and java  10 both reach end of life at the end of January, we
> are going from java 8 to java 11.
>
>
> I know there are many balls in the air, is there a build that works on java
> 11 today, or is there any very rough target for release?
>
> I have been asked to determine when we should assign resource to this.
>
> Thank you very much,
> Michael
>
>
>
> --
> Sent from:
> http://aspectj.2085585.n4.nabble.com/AspectJ-users-f2077686.html
> ___
> 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

Re: [aspectj-users] Debug aspect

[Andy Clement]

Looking at your zip the AccessingDeprecatedMethodTest.class isn’t woven with 
the aspect, were you expecting that particular class to be woven?

The message ‘woven class’ means “this class has been through the weaver”, not 
that it has been modified. Using something like the showWeaveInfo option will 
tell you what is actually getting woven.


I built your maven project for the aspect library then I applied the aspect to 
your testcode like this (removing the testng reference from the source):


ajc -classpath 
$CLASSPATH:/Users/aclement/.m2/repository/com/google/guava/guava/20.0/guava-20.0.jar
 -inpath ../aspect/target/aspect-0.0.1-SNAPSHOT.jar 
src/test/java/externalApp/AccessingDeprecatedMethodTest.java -d output 
-showWeaveInfo

Join point 'method-call(void 
com.ericsson.aspectlib.ClassWithDeprecatedMethod.aMethod())' in Type 
'externalApp.AccessingDeprecatedMethodTest' 
(AccessingDeprecatedMethodTest.java:17) advised by before advice from 
'com.ericsson.aspectlib.DeprecatedMethodLogger' 
(aspect-0.0.1-SNAPSHOT.jar!DeprecatedMethodLogger.class:25(from MyAspect.aj))

Now I know it was woven and if I look in the byte code I can see it:

javap -verbose -private AccessingDeprecatedMethodTest.class

  public void test();
descriptor: ()V
flags: ACC_PUBLIC
Error: unknown attribute
  org.aspectj.weaver.MethodDeclarationLineNumber: length = 0x8
   00 00 00 0F 00 00 00 F0
Code:
  stack=4, locals=2, args_size=1
 0: new   #23 // class 
com/ericsson/aspectlib/ClassWithDeprecatedMethod
 3: dup
 4: invokespecial #25 // Method 
com/ericsson/aspectlib/ClassWithDeprecatedMethod."":()V
 7: astore_1
 8: aload_1
 9: invokestatic  #56 // Method 
com/ericsson/aspectlib/DeprecatedMethodLogger.aspectOf:()Lcom/ericsson/aspectlib/DeprecatedMethodLogger;
12: getstatic #58 // Field 
ajc$tjp_0:Lorg/aspectj/lang/JoinPoint$StaticPart;
15: getstatic #60 // Field 
ajc$tjp_1:Lorg/aspectj/lang/JoinPoint$StaticPart;
// HERE IS THE ADVICE CALL
18: invokevirtual #64 // Method 
com/ericsson/aspectlib/DeprecatedMethodLogger.ajc$before$com_ericsson_aspectlib_DeprecatedMethodLogger$1$b9499fc0:(Lorg/aspectj/lang/JoinPoint$StaticPart;Lorg/aspectj/lang/JoinPoint$StaticPart;)V
// HERE IS THE DEPRECATED METHOD CALL
21: invokevirtual #26 // Method 
com/ericsson/aspectlib/ClassWithDeprecatedMethod.aMethod:()V

So from my point of view sounds like debugging wasn’t working because the class 
isn’t woven?

cheers
Andy

> On Aug 16, 2018, at 12:39 AM, Mikael Petterson  
> wrote:
> 
> The zip file with the projects are accessible from here.
> 
> https://1drv.ms/u/s!AtUfupFUBjWahS272GhHVxPht1bN 
> 
> 
> br,
> 
> //mike
> 
>  
>  
> Från: aspectj-users-boun...@eclipse.org 
>   > för Mikael Petterson 
> mailto:mikaelpetter...@hotmail.com>>
> Skickat: den 14 augusti 2018 13:34
> Till: Eric B; aspectj-users@eclipse.org 
> Ämne: Re: [aspectj-users] Debug aspect
>  
> Hi
> 
> I tried setting the inline compilation. See here:
> 
> 
> 
> 
> But no difference. So I add my projects here as a zip if someone is 
> interested.
> 
> br,
> 
> //mike
> 
> 
> 
>  
>  
> Från: aspectj-users-boun...@eclipse.org 
>   > för Eric B  >
> Skickat: den 14 augusti 2018 11:35
> Till: aspectj-users@eclipse.org 
> Ämne: Re: [aspectj-users] Debug aspect
>  
> Depending on your aspect, ajc may try to compile in inline in your class.  
> I'm not sure what conditions the compiler checks for inline compilation.  The 
> surest way is to use a decompiler to check the output class file and see if 
> you aspect has been inlined or not.  If it has, there is an experimental flag 
> you can set in your plugin definition XnoInline ( 
> <>https://www.mojohaus.org/aspectj-maven-plugin/compile-mojo.html#XnoInline 
> ). 
>  
> 
> Additionally, if I remember correctly, there is also a setting in ellipse 
> ajdt that configures the same.
> 
> Thanks,
> 
> Eric
> 
> 
> 
> On Tue, Aug 14, 2018, 6:58 AM Mikael Petterson,  > wrote:
> Just adding a picture of my setup.
> 
> 
>  
>  
> Från: aspectj-users-boun...@eclipse.org 
>   > för Mikael Petterson 
> mailto:mikaelpetter...@hotmail.com>>
> Skickat: den 14 augusti 2018 08:46
> Till: aspectj-users@eclipse.org 
> Ämne: [aspectj-users] Debug aspect
>  
> Hi,
> 
> I have an application A in Eclipse th

Re: [aspectj-users] Can't compile in IntelliJ with OpenJDK 9

[Andy Clement]

I expect this is an issue about finding the jar containing Object. It is
located a little differently on Java9 but given that your Ant builds works
fine with OpenJDK9 (I presume the same 9.0.7.1), hmm. I might be able to
add some diagnostics to a AJ9 build that would tell us where it is having
trouble locating the jar containing Object, if no-one can help you with the
intellij setup (I'm not an active intellij user) - did you try stack
overflow with that question?

cheers,
Andy

On Sun, 19 Aug 2018 at 02:17, Adam Retter 
wrote:

> We are using AspectJ 1.9.1.
>
> We compile our code in two ways - 1) using Apache Ant 1.10.2 and, 2)
> using IntelliJ 2008.2 Pro.
>
> In IntelliJ when our project is set to use OpenJDK 8 as the SDK, all
> compiles just fine and we are happy. However, as soon as we change the
> SDK to OpenJDK 9 (9.0.7.1) we get the following compile error:
>
> Error: Module 'eXist-db' production:
> org.aspectj.bridge.AbortException: can't determine superclass of
> missing type java.lang.Object
> [Xlint:cantFindType]
>
> In IntelliJ we have the AspectJ plugin installed, and the Java
> Compiler is set to AJC, the following checkboxes are all checked on:
> 1. Use '--release' option for cross-compilation (Java 9 and later)
> 2. Generate debug info
> 3. Delegate to javac
>
> Our Module in IntelliJ has the AspectJ option set for "Post-compile weave
> mode".
>
> Can someone help us to get this compiling in IntelliJ with OpenJDK 9
> please?
> For comparison - our Ant build works just fine with AspectJ on OpenJDK 9.
>
>
> --
> 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

Re: [aspectj-users] Java 11 Compatibility check: AspectJ

[Andy Clement]

1. Library Name: 

AspectJ

2. Latest version: 

1.9.1


3. Latest version Is the library compatible with Java 11 Compatible? (Y/N)

4. Is the library supported with Java 11? (Y/N)
5. (If “N” in compatibility or support) What is the versions that would be
compatible and Supported?

6. Date of support availability?

It'll run on Java 11 but doesn't support source/target of Java11, you will
need 1.9.2 for Java 11 support. Out in a few weeks when I find a minute to
pick up the latest JDT.


> Appreciate your response by 19.08.2018.

Sorry I was out on vacation for the last few weeks.




On Thu, 16 Aug 2018 at 00:15, Dragan, Krzysztof  wrote:

> Hi,
> We are reaching out to you to check Java 11 compatibility of the library
> AspectJ.
>
>
>
> Could you help us by answering the following questions:
>
>
> 1. Library Name: 
> 2. Latest version: 
> 3. Latest version Is the library compatible with Java 11 Compatible? (Y/N)
> 4. Is the library supported with Java 11? (Y/N)
> 5. (If “N” in compatibility or support) What is the versions that would be
> compatible and Supported?
> 6. Date of support availability?
>
>
>
> Appreciate your response by 19.08.2018.
>
>
>
> Thanks,
> Krzysztof Dragan,
> PTC Inc. Contractor
>
>
> ___
> 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

Re: [aspectj-users] AspectJ Compiler 1.8.10 errors out on wrong classpath

[Andy Clement]

Sorry for the late reply, I was on vacation.

> b) Why was this behavior changed and when?

Recently class path handling needed a lot of work in AspectJ because of
module support (so supporting Java9). We had to start embracing more of the
JDT processing of class path entries rather than doing our own simplistic
thing. This disturbed quite a few things but I fixed up what I found as
problems. Looks like you've found another issue though. The bug you found
is 15years old so I don't think it is that. I would raise an issue against
AspectJ.

> PDE Build with AspectJ is not really in use that much
I could imagine that is true.

If there were a JDT setting for that, I wonder if using that will now 'turn
off' those warnings for JDT as we are using the JDT code more for class
path processing.

cheers,
Andy


On Sat, 11 Aug 2018 at 10:13, thofmann  wrote:

> Hi everyone,
>
> I am trying to migrate an old PDE Build to a newer version of Eclipse, AJDT
> and thus AJC. Up until now the build used AJDT 1.6.x and the Java Source
> and
> Target Level was set to 1.6.
> The project should now be switched to used Java 8.
>
> I upgraded Eclipse to 4.6.3 and AJDT to 2.2.4.201703272045. When the PDE
> build now tries to build a project with aspects it errors out with errors
> like this:
>
> Sat Aug 11 18:51:49 CEST 2018
> [error] incorrect classpath:
> D:\SomeProject\build-output\rcs\plugins\antlr_2.7.6\antlr-2.7.6.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\org.apache.commons.lang_2.2.0\commons-lang.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.fwk_1.13.2.20160726-1434\@dot
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.fwk.common.spec.error_1.13.2.20160726-1434\@dot
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.fwk.common.spec.trace_1.13.2.20160726-1434\@dot
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.fwk.ass.perflog.internal.websphereadminservice_1.13.2.20160726-1434\@dot
> incorrect classpath:
> D:\SomeProject\build-output\rcs\plugins\com.somename.container.plugin\res
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\bin
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\@dot
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\res
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\somename.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\login.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\jndiprovider.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\transport.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\httpsupport.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\datamodel.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\context.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\logging.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\util.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\ejb.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\plugins\com.somename.application.rcs.standalone.logging\lib\support.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\nestedJars\org.eclipse.equinox.registry_3.5.101.R37x_v20110810-1611\runtime_registry_compatibility.jar
> incorrect classpath:
>
> D:\SomeProject\build-output\rcs\nestedJars\com.ibm.icu_4.4.2.v20110823\icu-data.jar
>
> These classpath entries really do not exist. The problem is that they are
> set in the build.xml file for the project that gets generated from the PDE
> build.
>
> I already debugged the PDE build build file generation. There are no
> options
> that I can use to not generate these classpath entries.
>
> This was no problem before. So my question now is
> a) is there some way that I can tell AJC not to complain about missing
> classpath entries?
> b) Why was this behavior changed and when?
> c) Is this a bug in AJC?
>
> I found this bug but no further information:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=37383
>
> I find it strange that I cannot find more information about this issue but
> it might well be that PDE Build with AspectJ is not really 

Re: [aspectj-users] Incorrect Code Generation on 1.9.1

[Andy Clement]

Did you mean to apply your within condition to all of those call pointcuts?
Right now your pointcut reads:

  within && call || call || call || call || call || call

and because && is higher precedence than || then your within() restriction
only applies to the first call.  It says "I'm interested in all these calls
anywhere except for getErrorStream() calls which I'm only interested in if
getErrorStream() isn't called from com.company.example code".  If you meant
to say "I'm interested in all these calls if they are made outside of the
com.company.example code" then you need

  within && (call || call || call || call || call || call)

Once encoded in an attribute we actually use an OR construct that only
takes two operands, this means your:

within && call || call || call || call || call || call || call

becomes
  (within && call) || (call || (call || (call || (call || 

and that is what you see  in the compiled aspect you looked inside. So this:

@AfterThrowing(pointcut="((!within(com.company.example..*) && call(*
java.net.HttpURLConnection.getErrorStream())) || (call(*
java.net.HttpURLConnection.getResponseCode()) || (call(*
java.net.HttpURLConnection.getResponseMessage()) || (call(* javax.net.ssl.
HttpsURLConnection.getLocalCertificates()) || (call(* javax.net.ssl.
HttpsURLConnection.getCipherSuite()) || (call(* javax.net.ssl.
HttpsURLConnection.getServerCertificates()) || (call(* javax.net.ssl.
HttpsURLConnection.getPeerPrincipal()) || (call(* javax.net.ssl.
HttpsURLConnection.getLocalPrincipal()) || (call(*
java.net.URLConnection.connect())
|| (call(* java.net.URLConnection.getContent()) || (call(*
java.net.URLConnection.getContentEncoding()) || (call(*
java.net.URLConnection.getContentLength()) || (call(*
java.net.URLConnection.getContentType()) || (call(*
java.net.URLConnection.getDate())
|| (call(* java.net.URLConnection.getExpiration()) || (call(*
java.net.URLConnection.getHeaderField()) || (call(*
java.net.URLConnection.getHeaderFieldDate())
|| (call(* java.net.URLConnection.getHeaderFieldKey()) || (call(*
java.net.URLConnection.getHeaderFields()) || (call(*
java.net.URLConnection.getInputStream())
|| call(* java.net.URLConnection.getLastModified())",
throwing="ex", argNames="ex")

is right, based on your pointcut. But if you meant to apply the within to
all your calls, then it wouldn't look like this. We do rewrite pointcuts
during compilation, so don't expect what you find encoded in the aspect to
be exactly the same as what you typed. But will be what you typed in your
source code in a DNF form with various internal components sorted to put
those that can be cheaply evaluated first.

Now, having said all that what is happening with your exception? You might
find if you included the parentheses so within() applies to all of your
calls, maybe it behaves, but when I see this:

java.lang.RuntimeException: Problem processing attributes in
com/company/example/android/aspects/URLConnectionExceptionsAspect.class
Caused by: org.aspectj.apache.bcel.classfile.ClassFormatException:
Index 151 into constant pool (size:150) is invalid
at 
org.aspectj.apache.bcel.classfile.ConstantPool.getConstant(ConstantPool.java:119)


My first suspicion is that something has transformed the aspect in between
when it got compiled and when it got used. If there is any other tool that
transforms the class files it can damage the aspect if it isn't aware of
what it is dealing with.  For example, if you compiled the aspect and then
ran something on the compiled class that threw away constant pool entries
that didn't look like they were being used, well it might throw out entries
it shouldn't because it didn't realize they were referenced from the
additional attributes in the class file.

So is there anything running on your compiled aspects before they get used?

Andy


On Mon, 30 Jul 2018 at 19:37, Andreas Marschke 
wrote:

> Hi all!
>
> I am working on a larger project where we define Aspects in their own *.aj
> files.
>
> In a recent trial against an Android project using Java 8 I found the
> exception as attached (exception.txt)
>
> Reviewing the source code, the corresponding line looks like this:
>
> after() throwing (Exception ex) : (!within(com.company.example..*) &&
> call (* java.net.HttpURLConnection.getErrorStream()) ||
> call (* java.net.HttpURLConnection.getResponseCode()) ||
> call (* java.net.HttpURLConnection.getResponseMessage()) ||
> call (* javax.net.ssl.HttpsURLConnection.getLocalCertificates()) ||
> call (* javax.net.ssl.HttpsURLConnection.getCipherSuite()) ||
> call (* javax.net.ssl.HttpsURLConnection.getServerCertificates()) ||
> call (* javax.net.ssl.HttpsURLConnection.getPeerPrincipal()) ||
> call (* javax.net.ssl.HttpsURLConnection.getLocalPrincipal()) ||
> call (* java.net.URLConnection.connect()) ||
> call (* java.net.URLConnection.getContent()) ||
> call (* java.net.URLConnection.getContentEncoding()) ||
> call

Re: [aspectj-users] weave all methods in rt.jar

[Andy Clement]

I think you have to take a little care when weaving rt.jar - for example if
your advice uses types you will be weaving then you will end up in a loop
(the advice gets called, calls back into the type you advised, which in
turns calls back into the advice, etc, etc). It might be the
java/lang/Object issue you are seeing is a manifestation of this problem. I
would target a specific simple type that you know your advice won't be
touching and verify your weave/run_with_woven is basically working before
broadly applying it across the JDK, and even then you'll probably want to
exclude some types (String, Object, etc).

Andy


On Sun, 29 Jul 2018 at 20:01, Sui, Li  wrote:

> Hi there
>
>
> I would like to instrument all methods in rt.jar. Here is my code
>
>
> public aspect CallInterceptor {
> pointcut allMethods():
> !within(CallInterceptor)  && execution(* *(..));
>
> before() : allMethods() {
> Signature sig=thisJoinPointStaticPart.getSignature();
> String method=sig.getDeclaringTypeName()+"."+sig.getName();
> System.out.println("enter "+method);
> }
>
> after() : allMethods() {
> System.out.println("exit");
> }
> }
>
>
> After weaving, I prepended weaved rt.jar to boot classpath and got the
> following error:
> *Error occurred during initialization of VM*
> *java/lang/NoClassDefFoundError: java/lang/Object*
>
> any help would be appreciated.
>
> Cheers
> Li
>
> ___
> 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

Re: [aspectj-users] Plans to support Java 11

[Andy Clement]

Hey,

Yep, 1.9.1 supports Java 10, we'll need an upgrade for Java11. When I do
the next Eclipse JDT compiler upgrade I think I'll be picking that up, in
the not too distant future (likely few weeks as we are getting due a 1.9.2
that includes some other fixes too).

cheers,
Andy

On Thu, 26 Jul 2018 at 02:27, li jian  wrote:

> Hi
> I'm trying to compile with aspectj 1.9.1 and Java 11-EA(
> http://jdk.java.net/11/). And failed with following exception.
>
> [ERROR] Failed to execute goal
> org.codehaus.mojo:aspectj-maven-plugin:1.11:compile (default) on project
> xxx.abc: AJC compiler errors:
> [ERROR] error can't find critical required type java.lang.Object
>
> Seems aspectj is not supporting Java 11 for now. So, do we have a plan for
> that?
>
> Thanks a lot!
>
> --
> Jian
> ___
> 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

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Andy Clement]

I added a bug yesterday
https://bugs.eclipse.org/bugs/show_bug.cgi?id=535877 with
my minimal test code in. Basically annotation style just hasn't got equal
test coverage with code style so we are going to hit things like this
occasionally. Excluding via @Aspect annotation is quite a clever workaround
:)

Andy

On 13 June 2018 at 19:02, Eric B  wrote:

> I have worked around the issue by adding it to an  in the
>  tag, but I was a bit surprised I had to do that.  Reading your
> explanation now, makes it a little more clear.
>
> I tend to prefer annotation style aspects, simply because, in general,
> most other people who need to maintain the codebase are not very versed in
> aspect programming, and I don't want to introduce yet another syntax to the
> code.  I guess for now, I'll just leave it in the  although it
> might be more interesting to see if I can exclude it by type instead of by
> class name.  I'm guessing I could simply exclude it by the @Aspect
> annotation?
>
> 
>
> Do I need to file a bug for this?
>
> Thanks,
>
> Eric
>
>
> On Wed, Jun 13, 2018 at 4:08 PM, Andy Clement 
> wrote:
>
>> I did just recreate this, I suspect one reason is hasn’t shown up before
>> is because we don’t typically use annotation style aspects in test cases.
>> If your aspect is annotation style and not code style you will see the
>> aspectOf() issue.  I originally wrote mine as code style (the CTW aspect) -
>> everything fine. The minute I switched it to annotation style, exactly the
>> same problem as you.
>>
>> Andy
>>
>>
>> On Jun 13, 2018, at 12:43 PM, Andy Clement 
>> wrote:
>>
>> Let me try to interpret this from what I remember:
>>
>>
>> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982]
>> debug weaving 'org.webapp.sso.keycloak.aspec
>> t.ClientErrorExceptionHandler'
>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
>> info processing reweavable type 
>> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler:
>> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
>> error aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
>> woven into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
>> must be defined to the weaver (placed
>> on the aspectpath, or defined in an aop.xml file if using LTW).
>>
>>
>>
>> That suggests to me the weaver has encountered a type that *might* be a
>> candidate for modification (ClientErrorExceptionHandler) - per
>> http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html 
>> ‘weaving
>> XXX’ doesn’t mean XXX is being modified, it just means the weaver is
>> looking at it (terrible message, needs improvement) - and since you have
>> weave info on then if something about it matched a pointcut you’d see a
>> weave info message.
>>
>> Looking at the reweavable state is fine but maybe it isn’t currently
>> smart enough to make the distinction that it doesn’t matter that the
>> ClientErrorExceptionHandler isn’t on the aspect path because none of the
>> new aspects are matching it - I honestly can’t recall how that situation is
>> handled and would need to dig through the code. I’m surprised if that is
>> the case, but it could be. The fact that there is an error is probably why
>> the resultant system doesn’t work, once the error happens all bets are off.
>>
>> What I’d try for experiments:
>> - stick ClientErrorExceptionHandler on the aspect path. This means it can
>> be found by reweaving processing - is it all good now?
>> - include an exclude in the weaver XML for that
>> ClientErrorExceptionHandler - if excluding it entirely is the reweavable
>> state ignored?
>> - run with overweaving on - should avoid reweavable processing.
>>
>> I’m not saying there isn’t a problem here just collecting more data
>> points and looking at possible workarounds,
>>
>> cheers,
>> Andy
>>
>>
>> On Jun 12, 2018, at 8:42 AM, Eric B  wrote:
>>
>> Thanks for the link Andy.  I read through the overweaving description,
>> and I agree that it doesn't sound like it applies.
>>
>> The aspect missing the aspectOf() is part of the CTW.  All Aspects are
>> annotation based (@Aspect).  The LTW was built using ajc.  Without the CTW
>> aspects, everything runs smoothly; all I have done was add in an additional
>> jar with CTW aspect/classes.  The LTW still seems to be working, although I
>>

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Andy Clement]

I did just recreate this, I suspect one reason is hasn’t shown up before is 
because we don’t typically use annotation style aspects in test cases. If your 
aspect is annotation style and not code style you will see the aspectOf() 
issue.  I originally wrote mine as code style (the CTW aspect) - everything 
fine. The minute I switched it to annotation style, exactly the same problem as 
you.

Andy

> On Jun 13, 2018, at 12:43 PM, Andy Clement  wrote:
> 
> Let me try to interpret this from what I remember:
> 
> 
>> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
>> weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982] info 
>> processing reweavable type 
>> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler: 
>> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982] error 
>> aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven 
>> into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' must be 
>> defined to the weaver (placed
>> on the aspectpath, or defined in an aop.xml file if using LTW).
> 
> 
> That suggests to me the weaver has encountered a type that might be a 
> candidate for modification (ClientErrorExceptionHandler) - per 
> http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html 
> <http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html> 
> ‘weaving XXX’ doesn’t mean XXX is being modified, it just means the weaver is 
> looking at it (terrible message, needs improvement) - and since you have 
> weave info on then if something about it matched a pointcut you’d see a weave 
> info message.
> 
> Looking at the reweavable state is fine but maybe it isn’t currently smart 
> enough to make the distinction that it doesn’t matter that the 
> ClientErrorExceptionHandler isn’t on the aspect path because none of the new 
> aspects are matching it - I honestly can’t recall how that situation is 
> handled and would need to dig through the code. I’m surprised if that is the 
> case, but it could be. The fact that there is an error is probably why the 
> resultant system doesn’t work, once the error happens all bets are off.
> 
> What I’d try for experiments:
> - stick ClientErrorExceptionHandler on the aspect path. This means it can be 
> found by reweaving processing - is it all good now?
> - include an exclude in the weaver XML for that ClientErrorExceptionHandler - 
> if excluding it entirely is the reweavable state ignored?
> - run with overweaving on - should avoid reweavable processing.
> 
> I’m not saying there isn’t a problem here just collecting more data points 
> and looking at possible workarounds,
> 
> cheers,
> Andy
> 
> 
>> On Jun 12, 2018, at 8:42 AM, Eric B > <mailto:ebenza...@gmail.com>> wrote:
>> 
>> Thanks for the link Andy.  I read through the overweaving description, and I 
>> agree that it doesn't sound like it applies.
>> 
>> The aspect missing the aspectOf() is part of the CTW.  All Aspects are 
>> annotation based (@Aspect).  The LTW was built using ajc.  Without the CTW 
>> aspects, everything runs smoothly; all I have done was add in an additional 
>> jar with CTW aspect/classes.  The LTW still seems to be working, although I 
>> would have to do more in-depth tests to validate that they are still being 
>> triggered where they need to be.
>> 
>> My application is running under JBoss EAP 7/Wildfly 10, so I'm honestly not 
>> entirely sure if they are all using the same classloader.  Given that the 
>> CTW classes are in the ear/lib folder, as are the LTW aspects (both jars are 
>> found in ear/lib), I suspect that they both are in the same classloader, but 
>> I'm really not sure.  I know that WF has done a lot of work, separating 
>> classloaders by module (so that the different modules in an EAR each have 
>> different classloaders), but I suspect there must be a common one for all 
>> classes in the ear/lib folder.
>> 
>> All that being said, I enabled the aspectj dumper with the beforeandafter 
>> option:
>> 
>> 
>>  
>>  
>>  > />
>>  
>>  > />
>>  
>>  
>>  
>>  
>> 
>> 
>> and interestingly enough, in the _before folder, I see the problematic 
>> Aspect class properly woven, but in the after class, it reappears in its 
>> original non-woven form.  As 

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Andy Clement]

sLoader@2d758982] error 
> aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven 
> into 'org.webapp.sso.keycloak.administration.SessionAdministrationImpl' must 
> be defined to the weaver (p
> laced on the aspectpath, or defined in an aop.xml file if using LTW).
> 2018-06-12 10:21:51,802 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.administration.UserServiceImpl'
> 2018-06-12 10:21:51,834 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.administration.SessionAdministration'
> 2018-06-12 10:21:51,861 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.administration.AccountAdministrationImpl'
> 2018-06-12 10:21:51,877 ERROR [stderr]   [ModuleClassLoader@2d758982] info 
> processing reweavable type 
> org.webapp.sso.keycloak.administration.AccountAdministrationImpl: 
> org\webapp.sso\keycloak\administration\AccountAdministrationImpl.java
> 2018-06-12 10:21:51,877 ERROR [stderr]   [ModuleClassLoader@2d758982] error 
> aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven 
> into 'org.webapp.sso.keycloak.administration.AccountAdministrationImpl' must 
> be defined to the weaver (p
> laced on the aspectpath, or defined in an aop.xml file if using LTW).
> 2018-06-12 10:21:51,896 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.administration.UserService'
> 2018-06-12 10:21:51,932 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.config.KeycloakConfigBean'
> 2018-06-12 10:21:51,968 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.keycloak.admin.client.Keycloak'
> 2018-06-12 10:21:51,973 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.keycloak.admin.client.resource.UserResource'
> 2018-06-12 10:21:51,975 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.administration.AccountAdministration'
> 2018-06-12 10:21:52,011 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.administration.UserService'
> 2018-06-12 10:21:52,026 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> 2018-06-12 10:21:52,046 ERROR [stderr]   [ModuleClassLoader@2d758982] info 
> processing reweavable type 
> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler: 
> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
> 2018-06-12 10:21:52,046 ERROR [stderr]   [ModuleClassLoader@2d758982] error 
> aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven 
> into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' must be 
> defined to the weaver (placed
> on the aspectpath, or defined in an aop.xml file if using LTW).
> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982] info 
> processing reweavable type 
> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler: 
> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982] error 
> aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven 
> into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' must be 
> defined to the weaver (placed
> on the aspectpath, or defined in an aop.xml file if using LTW).
> 
> 
> For some reason, the LTW thinks it should be weaving my 
> ClientErrorExceptionHandler (the aspect) even though it isn't part of my 
> aop.xml?  Is there a way to enable pointcut matching/debugging so I can see 
> which pointcut is triggering the reweaving/rewriting of this @Aspect class?
> 
> Thanks,
> 
> Eric
> 
> 
> 
> On Mon, Jun 11, 2018 at 6:29 PM Andy Clement  <mailto:andrew.clem...@gmail.com>> wrote:
> By default if you weave aspects on top of aspects then we use a model where 
> we revert to the original class file before the first set of aspects was 
> applied and apply all of them (the original aspects plus the new ones) at the 
> same time to ensure consistency. This behavior is configurable using the 
> overweaving option ( 
> http://andrewclement.blogspot.com/2010/05/aspectj-overweaving.html 
> <http://andrewclement.blogspot.com/2010/05/aspectj-overweaving.html> ). I'm 
> not sure whether I suspect that though.
> 

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Andy Clement]

By default if you weave aspects on top of aspects then we use a model where
we revert to the original class file before the first set of aspects was
applied and apply all of them (the original aspects plus the new ones) at
the same time to ensure consistency. This behavior is configurable using
the overweaving option (
http://andrewclement.blogspot.com/2010/05/aspectj-overweaving.html ). I'm
not sure whether I suspect that though.

Is the aspect with the aspectOf() missing part of the CTW or the LTW?  Was
the LTW library built with javac or ajc? Building annotation style aspects
with javac can be done but it will mean they are 'unfinished' and don't
have aspectOf/hasAspect - those will be added later when a weaver sees them.
Is everything loaded by the same class loader?  If you were LTWing some
code but the aspects were loaded by a class loader not subject to weaving
then this might happen. But then I know you are showing decompiled output
that contains the missing methods.

I don't have an obvious answer but there are no known issues with mixing
things up like this, really shouldn't be a race condition. You could turn
on verbose output for LTW and see if the things you are expecting to get
modified *are* modified.

cheers,
Andy

On 11 June 2018 at 14:07, Eric B  wrote:

> I have a multi-module EAR application that is comprised of:
> - EJB jar
> - WAR
> - aspect library
> - supporting libs
>
> My AspectJ library is designed to be used as LTW; it has pointcuts
> targetting some of the 3rd party libs.
>
> I have now created a new jar module in which I would like to use CTW.  I
> have configured by build properly, and can see that all my jars in my new
> module have been properly woven during the build process.  However, when I
> include the new lib in my ear, I get the following error message:
>
> 16:43:39,689 ERROR [io.undertow.request] (default task-35) UT005023:
> Exception handling request to /webapp/updateUserAccount.do:
> java.lang.NoSuchMethodError: org.webapp.sso.keycloak.aspect.
> ClientErrorExceptionHandler.aspectOf()Lorg/webapp/sso/keycloak/aspect/
> ClientErrorExceptionHandler;
> at org.webapp.sso.keycloak.administration.
> AccountAdministrationImpl.updateUserPassword(AccountAdministrationImpl.
> java:1)
> at org.webapp.sso.keycloak.administration.
> AccountAdministrationImpl$Proxy$_$$_WeldClientProxy.updateUserPassword(Unknown
> Source)
>
>
>
> However, when I look at the decompiled code for
> ClientErrorExceptionHandler, I see it contains the aspectOf() method:
>
>
> @Aspect
> public class ClientErrorExceptionHandler
> {
>   public static ClientErrorExceptionHandler aspectOf()
>   {
> if (ajc$perSingletonInstance == null) {
>   throw new 
> NoAspectBoundException("org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler",
> ajc$initFailureCause);
> }
> return ajc$perSingletonInstance;
>   }
>
>   public static boolean hasAspect()
>   {
> return ajc$perSingletonInstance != null;
>   }
> ...
> ...
>
> So I'm not sure what is happening.  Can this be some form of a race
> condition between the Load Time weaver and the Compile Time code?  My LTW
> aspects are in a completely different jar file, with their own aop.xml that
> have nothing to do with my current package.
>
> I've also double checked that my new jar does not contain an aop.xml.
>
> How can I further debug this issue?
>
> Thanks,
>
> Eric
>
>
>
>
>
>
> ___
> 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

Re: [aspectj-users] I can not get the correct line number

[Andy Clement]

The reason this occurs is because after() returning advice is implemented by 
forwarding all ‘return’ byte codes through to the end of a method where some 
generated code is created to call the advice, then the actual return occurs:

 0: getstatic #24 // Field instance:LSample;
 3: ifnull14
 6: getstatic #24 // Field instance:LSample;
 9: dup
10: astore_0
11: goto  29 // would have been an ARETURN if no after 
returning advice
14: new   #1  // class Sample
17: dup
18: invokespecial #26 // Method "":()V
21: putstatic #24 // Field instance:LSample;
24: getstatic #24 // Field instance:LSample;
27: dup
28: astore_0
29: dup
30: astore_1
31: invokestatic  #35 // Method X.aspectOf:()LX;
34: aload_1
35: invokevirtual #39 // Method 
X.ajc$afterReturning$X$1$8f645123:(Ljava/lang/Object;)V
38: aload_0
39: areturn

Here you can see at 11, there is a goto 29 which goes to the ‘advice invocation 
logic’ where without the aspect it would have been an areturn (see instruction 
9 here - same code with no aspects):

 0: getstatic #24 // Field instance:LSample;
 3: ifnull10
 6: getstatic #24 // Field instance:LSample;
 9: areturn // Here is the areturn that gets rewritten to GOTO when 
advice applies.
10: new   #1  // class Sample
13: dup
14: invokespecial #26 // Method "":()V
17: putstatic #24 // Field instance:LSample;
20: getstatic #24 // Field instance:LSample;
23: areturn

Because the advice is inserted at the end of the method you end up getting the 
line number of the last return, and can never get the others.

Could after advice be implemented differently? Yes, it could be 
inlined/duplicated at each return location. That would give you what you want 
at the cost of increased byte code size - there isn’t currently an option to 
switch to that weaving behavior I’m afraid.


cheers,
Andy


> On Jun 6, 2018, at 8:25 AM, Hirokawa Yuya  wrote:
> 
> Hello
> 
> I am using @ AnfterReturning annotation.
> We create a function to keep line numbers as logs.
> 
> When there are multiple returns in the method,
> The line number always points to the last return.
> Is it impossible to get a line number other than the last return?
> 
> environment:
> org.aspectj:aspectjrt:1.9.1
> Android Studio 3.1.2
> Build #AI-173.4720617, built on April 14, 2018
> JRE: 1.8.0_152-release-1024-b02 amd64
> JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> Windows 10 10.0
> 
> app/gradle
> import org.aspectj.bridge.IMessage
> import org.aspectj.bridge.MessageHandler
> import org.aspectj.tools.ajc.Main
> 
> buildscript {
>repositories {
>jcenter()
>mavenCentral()
>}
> 
>dependencies {
>classpath 'org.aspectj:aspectjtools:1.9.1'
>}
> }
> apply plugin: 'com.android.application'
> 
> android {
>compileSdkVersion 27
>defaultConfig {
>applicationId "jp.co.hba.milesmimi"
>minSdkVersion 23
>targetSdkVersion 27
>versionCode 1
>versionName "1.0"
>testInstrumentationRunner 
> "android.support.test.runner.AndroidJUnitRunner"
>}
>buildTypes {
>release {
>minifyEnabled false
>proguardFiles getDefaultProguardFile('proguard-android.txt'), 
> 'proguard-rules.pro'
>}
>}
> 
>applicationVariants.all { variant ->
> 
>variant.javaCompiler.doLast {
>String[] args = ["-showWeaveInfo",
> "-1.9",
> "-inpath", javaCompile.destinationDir.toString(),
> "-aspectpath", javaCompile.classpath.asPath,
> "-d", javaCompile.destinationDir.toString(),
> "-classpath", javaCompile.classpath.asPath,
> "-bootclasspath", 
> project.android.bootClasspath.join(
>File.pathSeparator)]
> 
>MessageHandler handler = new MessageHandler(true)
>new Main().run(args, handler)
> 
>def log = project.logger
>for (IMessage message : handler.getMessages(null, true)) {
>switch (message.getKind()) {
>case IMessage.ABORT:
>case IMessage.ERROR:
>case IMessage.FAIL:
>log.error message.message, message.thrown
>break
>case IMessage.WARNING:
>case IMessage.INFO:
>log.info message.message, message.thrown
> 

Re: [aspectj-users] Met [org.aspectj.lang.NoAspectBoundException] while running a post-compile woven (bytecode woven) apache thrift library

[Andy Clement]

@Alexander

I wondered if you had an opinion on this. I’ve been working on this under 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=535086 
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=535086> . I can’t decide if you 
should have to specify privileged in order for pertypewithin to match against 
types not visible from the aspect. Currently I have it so that pertypewithin 
will no longer match private types or default vis types in another package 
unless you specify privileged. If you do specify privilege the visibility is 
raised for those types during weaving so they are accessible (the auto raising 
of visibility is not unusual, we do it for other reasons at times).


cheers,
Andy

> On May 24, 2018, at 10:14 AM, Andy Clement  wrote:
> 
> I think there is a visibility issue here - the creation of the aspect fails 
> because in trying to create it we use reflection to invoke a method in the 
> affected type (the type pertypewithin is hitting) and that reflection is 
> failing (silently) because the type isn't accessible. The type visibility 
> should probably have been raised if the type is hit by pertypewithin.
> 
> cheers,
> Andy
> 
> On 19 May 2018 at 04:01, Alexander Kriegisch  <mailto:alexan...@kriegisch.name>> wrote:
> Okay, I think I figured it out. It is not per se a problem with the 3rd party 
> code, I can reproduce it with or without Thrift. The core problem is that the 
> inner class you want to instrument in the library is non-public. To be exact, 
> it is a private, non-static inner class. But what really matters is that it 
> is anything but public/protected, static or not is not so important.
> 
> To Andy Clement: Maybe this is a shortcoming in AspectJ and we need a 
> Bugzilla ticket for it, but first I am going to post some sample code here:
> 
> package de.scrum_master.app;
> 
> public class Application {
>   private static class InnerStaticRunnable implements Runnable {
> @Override
> public void run() {
>   System.out.println("Running inner static runnable");
> }
>   }
> 
>   private class InnerRunnable implements Runnable {
> @Override
> public void run() {
>   System.out.println("Running inner runnable");
> }
>   }
> 
>   public void doSomething() {
> new InnerRunnable().run();
>   }
> 
>   public static void main(String[] args) {
> new SomeRunnable().run();
> new Application.InnerStaticRunnable().run();
> new Application().doSomething();
>   }
> }
> package de.scrum_master.aspect;
> 
> privileged aspect MyRunnables {
>   public interface InstrumentedRunnable {}
>   private long InstrumentedRunnable.myid = -1;
>   public long InstrumentedRunnable.getMyid() { return myid; }
>   public void InstrumentedRunnable.setMyid(long id) { myid = id; }
> 
>   declare parents : Runnable+ implements InstrumentedRunnable;
> 
>   after() returning(InstrumentedRunnable r) : 
> call(java.lang.Runnable+.new(..)) {
> System.out.println(thisJoinPoint);
> System.out.println("  Runnable: " + r);
> System.out.println("  Has aspect: " + 
> PerRunnable.hasAspect(r.getClass()));
> long id = PerRunnable.aspectOf(r.getClass()).getCounter();
> r.setMyid(id);
> PerRunnable.aspectOf(r.getClass()).incrementCounter();
>   }
> }
> package de.scrum_master.aspect;
> 
> privileged aspect PerRunnable pertypewithin(java.lang.Runnable+) {
>   public long counter = 0;
>   public long getCounter() { return counter; }
>   public void incrementCounter() { counter++; }
> 
>   after() : staticinitialization(*) {
> System.out.println("getWithinTypeName() = " + getWithinTypeName());
>   }
> }
> Now let's run the code after Ajc compilation and check the console log:
> 
> getWithinTypeName() = de.scrum_master.app.SomeRunnable
> call(de.scrum_master.app.SomeRunnable())
>   Runnable: de.scrum_master.app.SomeRunnable@5674cd4d
>   Has aspect: true
> Running some runnable
> getWithinTypeName() = de.scrum_master.app.Application$InnerStaticRunnable
> call(de.scrum_master.app.Application.InnerStaticRunnable(Application.InnerStaticRunnable))
>   Runnable: de.scrum_master.app.Application$InnerStaticRunnable@65b54208
>   Has aspect: false
> Exception in thread "main" org.aspectj.lang.NoAspectBoundException
> at de.scrum_master.aspect.PerRunnable.aspectOf(PerRunnable.aj:1)
> at 
> de.scrum_master.aspect.MyRunnables.ajc$afterReturning$de_scrum_master_aspect_MyRunnables$1$8a935d86(MyRunnables.aj:15)
> at de.scrum_master.app.Application.main(Application.java:24)
> Please note "Has aspect: false" right before the exception. Now change the 
> inner classes to publi

Re: [aspectj-users] Met [org.aspectj.lang.NoAspectBoundException] while running a post-compile woven (bytecode woven) apache thrift library

[Andy Clement]

I think there is a visibility issue here - the creation of the aspect fails
because in trying to create it we use reflection to invoke a method in the
affected type (the type pertypewithin is hitting) and that reflection is
failing (silently) because the type isn't accessible. The type visibility
should probably have been raised if the type is hit by pertypewithin.

cheers,
Andy

On 19 May 2018 at 04:01, Alexander Kriegisch 
wrote:

> Okay, I think I figured it out. It is not per se a problem with the 3rd
> party code, I can reproduce it with or without Thrift. The core problem is
> that the inner class you want to instrument in the library is non-public.
> To be exact, it is a private, non-static inner class. But what really
> matters is that it is anything but public/protected, static or not is not
> so important.
>
> To Andy Clement: Maybe this is a shortcoming in AspectJ and we need a
> Bugzilla ticket for it, but first I am going to post some sample code here:
> --
>
> package de.scrum_master.app;
>
> public class Application {
>   private static class InnerStaticRunnable implements Runnable {
> @Override
> public void run() {
>   System.out.println("Running inner static runnable");
> }
>   }
>
>   private class InnerRunnable implements Runnable {
> @Override
> public void run() {
>   System.out.println("Running inner runnable");
> }
>   }
>
>   public void doSomething() {
> new InnerRunnable().run();
>   }
>
>   public static void main(String[] args) {
> new SomeRunnable().run();
> new Application.InnerStaticRunnable().run();
> new Application().doSomething();
>   }
> }
>
> --
>
> package de.scrum_master.aspect;
>
> privileged aspect MyRunnables {
>   public interface InstrumentedRunnable {}
>   private long InstrumentedRunnable.myid = -1;
>   public long InstrumentedRunnable.getMyid() { return myid; }
>   public void InstrumentedRunnable.setMyid(long id) { myid = id; }
>
>   declare parents : Runnable+ implements InstrumentedRunnable;
>
>   after() returning(InstrumentedRunnable r) : 
> call(java.lang.Runnable+.new(..)) {
> System.out.println(thisJoinPoint);
> System.out.println("  Runnable: " + r);
> System.out.println("  Has aspect: " + 
> PerRunnable.hasAspect(r.getClass()));
> long id = PerRunnable.aspectOf(r.getClass()).getCounter();
> r.setMyid(id);
> PerRunnable.aspectOf(r.getClass()).incrementCounter();
>   }
> }
>
> --
>
> package de.scrum_master.aspect;
>
> privileged aspect PerRunnable pertypewithin(java.lang.Runnable+) {
>   public long counter = 0;
>   public long getCounter() { return counter; }
>   public void incrementCounter() { counter++; }
>
>   after() : staticinitialization(*) {
> System.out.println("getWithinTypeName() = " + getWithinTypeName());
>   }
> }
>
> --
>
> Now let's run the code after Ajc compilation and check the console log:
>
> getWithinTypeName() = de.scrum_master.app.SomeRunnable
> call(de.scrum_master.app.SomeRunnable())
>   Runnable: de.scrum_master.app.SomeRunnable@5674cd4d
>   Has aspect: true
> Running some runnable
> getWithinTypeName() = de.scrum_master.app.Application$InnerStaticRunnable
> call(de.scrum_master.app.Application.InnerStaticRunnable(Application.InnerStaticRunnable))
>   Runnable: de.scrum_master.app.Application$InnerStaticRunnable@65b54208
>   Has aspect: false
> Exception in thread "main" org.aspectj.lang.NoAspectBoundException
> at de.scrum_master.aspect.PerRunnable.aspectOf(PerRunnable.aj:1)
> at 
> de.scrum_master.aspect.MyRunnables.ajc$afterReturning$de_scrum_master_aspect_MyRunnables$1$8a935d86(MyRunnables.aj:15)
> at de.scrum_master.app.Application.main(Application.java:24)
>
> --
>
> Please note "Has aspect: false" right before the exception. Now change the
> inner classes to public or protected and the code works:
>
> getWithinTypeName() = de.scrum_master.app.SomeRunnable
> call(de.scrum_master.app.SomeRunnable())
>   Runnable: de.scrum_master.app.SomeRunnable@5674cd4d
>   Has aspect: true
> Running some runnable
> getWithinTypeName() = de.scrum_master.app.Application$InnerStaticRunnable
> call(de.scrum_master.app.Application.InnerStaticRunnable())
>   Runnable: de.scrum_master.app.Application$InnerStaticRunnable@65b54208
>   Has aspect: true
> Running inner static runnable
> getWithinTypeName() = de.scrum_master.app.Application$InnerRunnable
> call(de.scrum_master.app.Application.InnerRunna

[aspectj-users] AspectJ 1.9.1 released

[Andy Clement]

AspectJ 1.9.1 is released.

We are still working out how best to support the new rapid release plan for 
Java, where many of the frequent releases are not long term support releases 
(Java10 ends public updates in Sep 2018).  Just to try and stay up to date with 
Java functionality, AspectJ 1.9.1 actually integrates Java10 support.  Per the 
readme ( https://eclipse.org/aspectj/doc/released/README-191.html 
 ) you can use the 
new ‘var’ support.

public class Code3 {
public static void main(String []argv) {
var x = "hello";
System.out.println(x.getClass());
}
}

aspect X {
before(): call(* *.getClass()) && target(String) {
System.out.println(thisJoinPointStaticPart);
}
}

This will compile and weave just fine.

Grab 1.9.1 from maven central soon (it submitted, will take a day or so to 
sync) or from the downloads page: https://eclipse.org/aspectj/downloads.php 


Feedback is welcome.

cheers,
Andy___
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

Re: [aspectj-users] How to turn off Xlint messages in OSGi LTW

[Andy Clement]

You could try prefixing that with file if using an absolute path:

> org.aspectj.weaver.loadtime.configuration=file:/full/path/to/aop.xml


If you have tracing turned on your will see if it picks up these files in 
references to a method called ‘parseDefinitions’.

But I also looked around a bit, found this:

https://eclipse.googlesource.com/equinox/rt.equinox.incubator/+/refs/tags/M20120905-1500/aspects/tests/org.eclipse.equinox.weaving.tests.performance/config.ini
 
<https://eclipse.googlesource.com/equinox/rt.equinox.incubator/+/refs/tags/M20120905-1500/aspects/tests/org.eclipse.equinox.weaving.tests.performance/config.ini>

and that ties up with what I see in that code, if you don’t specify the ‘file:’ 
prefix then it assumes it is a relative path and will attempt to access it via 
a getResources() call on the class loaders involved.

The fact that the .ini I just linked includes that setting makes me think it 
will work under OSGi.

cheers,
Andy


> On Apr 18, 2018, at 12:16 AM, Bogus Abuser  wrote:
> 
> Hi Andy,
> Thanks for your response. I tried what you proposed but it didn't seem to 
> work.
> I added this property:
> 
> org.aspectj.weaver.loadtime.configuration=/full/path/to/aop.xml
> 
> And I have this in aop.xml:
> 
> 
> 
> 
> 
> 
> 
> If the above is correct then maybe your suspicion about possible 
> class-loading issue is also correct.
> Do you have other ideas how can I suppress warn/lint messages?
> 
> Cheers
> 
> 
> On Wed, Apr 18, 2018 at 1:09 AM, Andy Clement  <mailto:andrew.clem...@gmail.com>> wrote:
> I thought there was something in for that but I can't find it!
> 
> There is a property for pointing at a file URL that is your config file 
> (aop.xml):
> 
> org.aspectj.weaver.loadtime.configuration
> 
> But I'm not 100% sure how the class loader model under OSGi interferes with 
> the code that checks that property. Have you looked at Equinox Aspects that 
> discusses OSGi+AspectJ ( 
> https://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php
>  
> <https://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php>
>  - it might be a bit out of date).
> 
> Andy
> 
> On 17 April 2018 at 06:49, Bogus Abuser  <mailto:bogusabu...@gmail.com>> wrote:
> Hi friends,
> I'm using AspectJ 1.8 in OSGi with LTW and I'm wondering how to turn off all 
> the Xlint messages.
> I've tried:
> 
> aj.weaving.verbose=false
> org.aspectj.weaver.showWeaveInfo=false
> org.aspectj.osgi.verbose=false
> 
> but didn't seem to help.
> 
> As far as I can see in the doc I can declare -Xlint:ignore in aop.xml but I'd 
> like to do the same with a system property. Is it possible?
> If not how can I use aop.xml in OSGi?
> 
> Cheers!
> 
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org <mailto: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 
> <https://dev.eclipse.org/mailman/listinfo/aspectj-users>
> 
> 
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org <mailto: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 
> <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

___
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

Re: [aspectj-users] How to turn off Xlint messages in OSGi LTW

[Andy Clement]

I thought there was something in for that but I can't find it!

There is a property for pointing at a file URL that is your config file
(aop.xml):


org.aspectj.weaver.loadtime.configuration

But I'm not 100% sure how the class loader model under OSGi interferes with
the code that checks that property. Have you looked at Equinox Aspects that
discusses OSGi+AspectJ (
https://www.eclipse.org/equinox/incubator/aspects/equinox-aspects-quick-start.php
-
it might be a bit out of date).

Andy

On 17 April 2018 at 06:49, Bogus Abuser  wrote:

> Hi friends,
> I'm using AspectJ 1.8 in OSGi with LTW and I'm wondering how to turn off
> all the Xlint messages.
> I've tried:
>
> aj.weaving.verbose=false
> org.aspectj.weaver.showWeaveInfo=false
> org.aspectj.osgi.verbose=false
>
> but didn't seem to help.
>
> As far as I can see in the doc I can declare -Xlint:ignore in aop.xml but
> I'd like to do the same with a system property. Is it possible?
> If not how can I use aop.xml in OSGi?
>
> Cheers!
>
> ___
> 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

[aspectj-users] AspectJ 1.9.0 released

[Andy Clement]

AspectJ 1.9.0 is finally released, after multiple betas and release candidates. 
 The README can be found here:
https://eclipse.org/aspectj/doc/released/README-190.html 
 - thanks to everyone 
in the community who provided feedback, sample code and test cases to iron out 
as many issues as possible.

The key changes in 1.9.0:
- primary change is that it supports compiling/weaving Java 9 code/modules.
- some new APIs have been added to the runtime jar, these are used by the 
generated code when building join points. It should reduce the amount of class 
loading done at runtime. If you try it out (you need to turn on a flag to try 
it out), any feedback is welcome!
- Incorporates the Spring AOP improvements that were made in recent 1.8.X 
releases.

It should appear in central in the next day or so.

cheers,
Andy___
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

Re: [aspectj-users] How to use ajdoc generate Android Project doc?

[Andy Clement]

I’ve not used ajdoc in ages - this might be a good question for stackoverflow?

Andy

> On Mar 14, 2018, at 8:58 AM, zn z  wrote:
> 
> Hello, guys.
> 
> When I want to generate android library doc that depends on aspects, I get 
> error
> 
> Anyone know to use ajdoc or javadoc to generate doc of android project?
> 
> Please let me know, thank you very much.
> ___
> 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

Re: [aspectj-users] Compile-time signature

[Andy Clement]

I’ve made some modifications - basically changed all the thisJoinPoint and 
thisEnclosingJoinPoint code generation for all join point kinds. These are in 
the 1.9.0.BUILD-SNAPSHOT build available from the repository:


maven.springframework.org
http://maven.springframework.org/snapshot


or directly from here:

http://www.eclipse.org/downloads/download.php?file=/tools/aspectj/dev/aspectj-DEVELOPMENT-20180312080830.jar

Because I consider it experimental you need to opt in to trying it out, the 
option is:

-Xajruntimetarget:1.9

(This option has been used previously to deliberately target an old runtime, 
basically just added 1.9 as a target here)

But if the build plugin you are using doesn’t allow you to pass that through, 
you can set ASPECTJ_OPTS more globally as a system property/variable and it 
should be picked up:

export ASPECTJ_OPTS=“-Xajruntimetarget:1.9”

If you try it out, let me know how it goes.  I’d be interested in the impact on 
startup time and on size of the built artifacts.

cheers,
Andy

> On Feb 26, 2018, at 11:59 AM, Fabian Bergmark  
> wrote:
> 
> Ok! Yes sure!
> 
> On Feb 26, 2018 20:31, "Andy Clement"  <mailto:andrew.clem...@gmail.com>> wrote:
> I did do some initial exploration work and it turned out to be bigger impact 
> than I’d hoped. Doesn’t mean it won’t happen - just that it’ll take longer. 
> If I did get you a snapshot build with prototype code in it, would you be 
> able to try it out and see if it behaves in your situation?
> 
> cheers,
> Andy
> 
> > On Feb 26, 2018, at 4:41 AM, Fabian Bergmark  > <mailto:fabian.bergm...@gmail.com>> wrote:
> >
> > Any progress?
> >
> > Cheers,
> > Fabian
> >
> > 2018-01-10 19:48 GMT+01:00 Andy Clement  > <mailto:andrew.clem...@gmail.com>>:
> >> The proper optimization here is to use the LDC byte code that takes a
> >> constant class, rather than the string variant and then class loading. The
> >> original AspectJ used the string form because LDC didn't take a class
> >> originally.  Over the years a few places have been updated but not
> >> everywhere ( thisEnclosingJoinPoint is one of them that hasn't been done I
> >> think). Let me have a look at what I can do. For a while we had to tolerate
> >> both modes because LDC class was quite new, but it has been there so long
> >> now I think we can assume you are on a JVM that will have it.
> >>
> >> cheers,
> >> Andy
> >>
> >>
> >> On 10 January 2018 at 01:42, Fabian Bergmark  >> <mailto:fabian.bergm...@gmail.com>>
> >> wrote:
> >>>
> >>> I'm using both AspectJ and Proguard in a project. On of my aspects
> >>> inserts MDC-information in logging messages, including source location
> >>> and method:
> >>>
> >>> void around() : call(void org.slf4j.Logger.trace(..)) || call(void
> >>> org.slf4j.Logger.debug(..)) || call(void org.slf4j.Logger.info 
> >>> <http://org.slf4j.logger.info/>(..)) ||
> >>> call(void org.slf4j.Logger.warn(..)) || call(void
> >>> org.slf4j.Logger.error(..)) {
> >>>try (MDC.MDCCloseable c3 =
> >>> MDC.putCloseable("logging_aspect::location",
> >>> thisJoinPoint.getSourceLocation().toString());
> >>>  MDC.MDCCloseable c4 =
> >>> MDC.putCloseable("logging_aspect::method",
> >>> thisEnclosingJoinPointStaticPart.getSignature().toString())) {
> >>>proceed();
> >>>}
> >>>}
> >>>
> >>> However, when enabling obfuscation in proguard, this results in log
> >>> messages like:
> >>>
> >>> "mdc" : {
> >>>"logging_aspect::method" : "void
> >>>
> >>> java.lang.ClassNotFoundException.onCreateConnectionChannelResponse(ClassNotFoundException,
> >>> CreateConnectionChannelError, ConnectionStatus)",
> >>>"logging_aspect::location" : "File.java:299"
> >>> }
> >>>
> >>> I think there should be a way to access the Signature at the time of
> >>> compilation. This would also be faster (?) than looking up classes
> >>> during runtime.
> >>> ___
> >>> aspectj-users mailing list
> >>> aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org>
> >>> To change your delivery options, retrieve your password, or unsubscribe
> >>> from this list, vis

Re: [aspectj-users] Compile-time signature

[Andy Clement]

I did do some initial exploration work and it turned out to be bigger impact 
than I’d hoped. Doesn’t mean it won’t happen - just that it’ll take longer. If 
I did get you a snapshot build with prototype code in it, would you be able to 
try it out and see if it behaves in your situation?

cheers,
Andy

> On Feb 26, 2018, at 4:41 AM, Fabian Bergmark  
> wrote:
> 
> Any progress?
> 
> Cheers,
> Fabian
> 
> 2018-01-10 19:48 GMT+01:00 Andy Clement :
>> The proper optimization here is to use the LDC byte code that takes a
>> constant class, rather than the string variant and then class loading. The
>> original AspectJ used the string form because LDC didn't take a class
>> originally.  Over the years a few places have been updated but not
>> everywhere ( thisEnclosingJoinPoint is one of them that hasn't been done I
>> think). Let me have a look at what I can do. For a while we had to tolerate
>> both modes because LDC class was quite new, but it has been there so long
>> now I think we can assume you are on a JVM that will have it.
>> 
>> cheers,
>> Andy
>> 
>> 
>> On 10 January 2018 at 01:42, Fabian Bergmark 
>> wrote:
>>> 
>>> I'm using both AspectJ and Proguard in a project. On of my aspects
>>> inserts MDC-information in logging messages, including source location
>>> and method:
>>> 
>>> void around() : call(void org.slf4j.Logger.trace(..)) || call(void
>>> org.slf4j.Logger.debug(..)) || call(void org.slf4j.Logger.info(..)) ||
>>> call(void org.slf4j.Logger.warn(..)) || call(void
>>> org.slf4j.Logger.error(..)) {
>>>try (MDC.MDCCloseable c3 =
>>> MDC.putCloseable("logging_aspect::location",
>>> thisJoinPoint.getSourceLocation().toString());
>>>  MDC.MDCCloseable c4 =
>>> MDC.putCloseable("logging_aspect::method",
>>> thisEnclosingJoinPointStaticPart.getSignature().toString())) {
>>>proceed();
>>>}
>>>}
>>> 
>>> However, when enabling obfuscation in proguard, this results in log
>>> messages like:
>>> 
>>> "mdc" : {
>>>"logging_aspect::method" : "void
>>> 
>>> java.lang.ClassNotFoundException.onCreateConnectionChannelResponse(ClassNotFoundException,
>>> CreateConnectionChannelError, ConnectionStatus)",
>>>"logging_aspect::location" : "File.java:299"
>>> }
>>> 
>>> I think there should be a way to access the Signature at the time of
>>> compilation. This would also be faster (?) than looking up classes
>>> during runtime.
>>> ___
>>> 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
> ___
> 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

Re: [aspectj-users] Compile-time signature

[Andy Clement]

The proper optimization here is to use the LDC byte code that takes a
constant class, rather than the string variant and then class loading. The
original AspectJ used the string form because LDC didn't take a class
originally.  Over the years a few places have been updated but not
everywhere ( thisEnclosingJoinPoint is one of them that hasn't been done I
think). Let me have a look at what I can do. For a while we had to tolerate
both modes because LDC class was quite new, but it has been there so long
now I think we can assume you are on a JVM that will have it.

cheers,
Andy


On 10 January 2018 at 01:42, Fabian Bergmark 
wrote:

> I'm using both AspectJ and Proguard in a project. On of my aspects
> inserts MDC-information in logging messages, including source location
> and method:
>
> void around() : call(void org.slf4j.Logger.trace(..)) || call(void
> org.slf4j.Logger.debug(..)) || call(void org.slf4j.Logger.info(..)) ||
> call(void org.slf4j.Logger.warn(..)) || call(void
> org.slf4j.Logger.error(..)) {
> try (MDC.MDCCloseable c3 =
> MDC.putCloseable("logging_aspect::location",
> thisJoinPoint.getSourceLocation().toString());
>   MDC.MDCCloseable c4 =
> MDC.putCloseable("logging_aspect::method",
> thisEnclosingJoinPointStaticPart.getSignature().toString())) {
> proceed();
> }
> }
>
> However, when enabling obfuscation in proguard, this results in log
> messages like:
>
> "mdc" : {
> "logging_aspect::method" : "void
> java.lang.ClassNotFoundException.onCreateConnectionChannelRespo
> nse(ClassNotFoundException,
> CreateConnectionChannelError, ConnectionStatus)",
> "logging_aspect::location" : "File.java:299"
> }
>
> I think there should be a way to access the Signature at the time of
> compilation. This would also be faster (?) than looking up classes
> during runtime.
> ___
> 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

Re: [aspectj-users] Java 8 type annotations

[Andy Clement]

There is no AspectJ support for matching on type annotations right now.

You could use a declare @type and then match on annotations:

aspect X {

// If a member has @Anno, stick @Anno on the type
declare @type: hasmethod(@Anno * *(..)): @Anno;

// If the type has @anno, advise static initialization
before(): @within(Anno) && staticinitialization(*) {
System.out.println("Advising "+thisJoinPointStaticPart);
}
}

This will work in this kind of setup:

new Runnable() {
@Anno public void run() {
System.out.println("xyz");
}
}.run();

You will need to compile with -XhasMember to allow use of the hasmethod() 
pointcut.

cheers,
Andy

> On Jan 2, 2018, at 12:06 PM, Fabian Bergmark  
> wrote:
> 
> Is it possible to capture initialization of a class with specific type
> annotation, like
> 
> new @Link Runnable() { .. }
> 
> If not, would it be possible to capture initialization of a class
> which contains a method with a specific annotation?
> 
> Cheers
> ___
> 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

Re: [aspectj-users] relocation of aspectj classes in a java agent

[Andy Clement]

That’s an interesting requirement. I don’t know of others doing that but it 
isn’t totally unreasonable.  I’ve normally used jarjar to move packages, I 
wonder if there is a variant of that tool which also allows string replacement. 
It seems reasonably robust to modify Lorg/aspectj/lang prefixed strings to 
Lshadow/org/aspectj/lang in addition to moving the packages. That would 
probably get you a long way, and if there were any remaining issues we could 
modify aspectj to make it behave.

In the back of my mind I am concerned about code that is affected by 
differently packaged weavers and them maybe tripping each other up, but right 
now I can’t think of concrete situations that will fail.

Andy

> On Dec 26, 2017, at 5:23 AM, Shalom Ben-Zvii Kazaz  
> wrote:
> 
> Hi All
> We are developing a kind of jvm profiler and we want to use aspectj load time 
> weaving.
> we're going to use this tool for various application which we know nothing 
> about in advance. and we suspect that some of them are already using aspectj 
> in some way.
> We use gradle to package our tool and wanted to relocate the aspectj classes 
> but it looks impossible.
> I think its because aspectjweaver uses string constants to test if a class is 
> an aspect, something like that:
> 
> public final static UnresolvedType ASPECT_ANNOTATION = 
> UnresolvedType.forSignature("Lorg/aspectj/lang/annotation/Aspect;"
> 
> and when relocating the project dependencies our aspects doesn't import 
> or.aspectj.. anymore but shadow.org.aspectj.. and so the weaver complains 
> that the class is not an aspect and does not register our aspects.
> i tried various ways to solve it like excluding some classes or all the 
> org.aspectj.lang package but nothing worked. 
> I did try stackoverflow but didn't get any good help there.
> would appreciate if someone can help suggesting what we could do. of course i 
> could use pure asm to do that or bytebuddy but i find aspectj the best for 
> our needs.
> 
> Thank you
> 
> Shalom
> ___
> 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

Re: [aspectj-users] The constructor DeprecatedMethodLogger() is not visible when testing my aspect

[Andy Clement]

Typically you don’t instantiate aspects like that, their lifecycle is managed 
more internally to the aspect and can vary depending on the per-scope. (The 
default scope being singleton)

If you want an instance of an aspect, you’d call:

DeprecatedMethodLogger.aspectOf()

and this will give you the singleton instance for your aspect.

Andy


> On Dec 21, 2017, at 5:58 AM, Mikael Petterson  
> wrote:
> 
> Hi,
> 
> I am using aspectj 1.8.10 and we experience the following Eclipse:
> 
> In my test I have:
> 
> public class DeprecatedMethodLoggerTest {
> 
> private boolean debug = true;
> private DeprecatedMethodLogger deprecatedMethodLogger;
> 
> @Before
> public void setup() {
> deprecatedMethodLogger = new DeprecatedMethodLogger();
> }
> }
> 
> My aspect looks something along the lines:
> 
> aspect DeprecatedMethodLogger {
>
> //Instantiated once so we can get information here that only needs to be 
> fetched once.
> public DeprecatedMethodLogger() {
> addLifeHandling();
> 
> }
> 
> }
> 
> Both classes are in the same package.
> 
> Then Eclipse 4.6.3 complains about the following:
> 
> The constructor DeprecatedMethodLogger() is not visible 
> DeprecatedMethodLoggerTest.java 
> 
> What could be the reasons for this error message? Does the aspect have to be 
> public?
> 
> Any hints?
> 
> br,
> 
> //mike
> 
> 
>  
>  
> ___
> 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

Re: [aspectj-users] Accidental Debug Print within the AspectJ 1.8.12 release?

[Andy Clement]

Good catch !!  I had a dig around thinking they were something that crept in 
recently but it turns out they have been there a year or so (since last jdt 
upgrade). Usually tests pick those things up because we have tests that look 
for particular output and trip over extraneous output but it looks like we have 
none of those kinds of test for this area (the println relates to code executed 
when we need to create something to adjust the visibility of a member so it can 
be seen from another piece of code that ordinarily couldn’t see it).

I’ve taken them out of 1.8 release branch and 1.9. 

Andy

> On Dec 20, 2017, at 9:56 AM, Henrique Rebêlo  wrote:
> 
> Hi Andy,
> 
> I moved my project to use AspectJ 1.8.12 and yesterday I realized some prints 
> in my console while calling the ajc compiler... At some point I thought it 
> was in my code, but when I changed back to release 1.8.9 they disappeared...
> 
> I have some test files related to test JML specs [pre- and postconditions] in 
> AspectJML [it translates JML specs into AspectJ code to compile] and I got 
> the following with some files [I had lot of them]:
> 
> >>int Constraint4.val
>  >>int Constraint1.val
>  >>int Constraint2.val
>  >>int Constraint5.val
>  >>int constructor_spec.x
>  >>int Constraint3.valSuper
> 
> It seems a debug issue related to the field type and associated with the 
> class name. For example, in a class named Constraint4, we have a int field 
> val.
> 
> I just want to double check with you about these prints...
> 
> thanks
> 
> -- 
> ...
> Henrique Rebelo
> http://www.cin.ufpe.br/~hemr 
> Centro de Informática
> Universidade Federal de Pernambuco , Brazil
> ___
> 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

Re: [aspectj-users] ajc 1.8.10 fails with JDK9

[Andy Clement]

yep.

On 17 December 2017 at 09:26, Bogus Abuser  wrote:

> Btw, can I use AspectJ 1.9 with JDK 8?
>
> Thanks.
>
> On Fri, Dec 15, 2017 at 7:11 PM, Bogus Abuser 
> wrote:
>
>> I see, thank you!
>>
>> On Thu, Dec 14, 2017 at 9:22 PM, Andy Clement 
>> wrote:
>>
>>> For compilation/weaving of stuff on JDK9 you should use the 1.9.0 RC2
>>> that is out. This is what Spring Framework is using to compile its aspects
>>> code.
>>>
>>> 1.8 releases (1.8.13) can be used on JDK9 for simple situations like
>>> Spring AOP that is doing pointcut parsing/matching but isn't digging into
>>> type information like compilation does.
>>>
>>> cheers,
>>> Andy
>>>
>>> On 14 December 2017 at 06:15, Bogus Abuser 
>>> wrote:
>>>
>>>> Hi friends,
>>>> I'm happily and successfully using AspectJ 1.8.10 with JDK 8. However I
>>>> just tried to upgrade to JDK 9 and I get the following:
>>>>
>>>> [ant:iajc] [error] can't find critical required type
>>>> java.io.Serializable
>>>> [ant:iajc] [error] can't find critical required type java.lang.Cloneable
>>>> ...
>>>> ...
>>>>
>>>>
>>>> The same for java.lang.Integer and so on. Do I need to upgrade AspectJ
>>>> to 1.9 or there's something else I could do?
>>>>
>>>> Cheers!
>>>>
>>>> ___
>>>> 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
>>>
>>
>>
>
> ___
> 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

Re: [aspectj-users] ajc 1.8.10 fails with JDK9

[Andy Clement]

For compilation/weaving of stuff on JDK9 you should use the 1.9.0 RC2 that
is out. This is what Spring Framework is using to compile its aspects code.

1.8 releases (1.8.13) can be used on JDK9 for simple situations like Spring
AOP that is doing pointcut parsing/matching but isn't digging into type
information like compilation does.

cheers,
Andy

On 14 December 2017 at 06:15, Bogus Abuser  wrote:

> Hi friends,
> I'm happily and successfully using AspectJ 1.8.10 with JDK 8. However I
> just tried to upgrade to JDK 9 and I get the following:
>
> [ant:iajc] [error] can't find critical required type java.io.Serializable
> [ant:iajc] [error] can't find critical required type java.lang.Cloneable
> ...
> ...
>
>
> The same for java.lang.Integer and so on. Do I need to upgrade AspectJ to
> 1.9 or there's something else I could do?
>
> Cheers!
>
> ___
> 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

Re: [aspectj-users] ajc issues with interfaces using generics

[Andy Clement]

I've only just done the 1.8.12 release so 1.8.13 is a little way off
(christmas?). There may be a 1.9.0.RC2 before that (1.9.0 also includes the
fix).

cheers,
Andy

On 1 November 2017 at 15:44, Jason Britton  wrote:

> Fantastic!!!  Thank you for fixing!  How long does it take a SNAPSHOT to
> make it to release?
>
> On Wed, Nov 1, 2017 at 3:25 PM, Andy Clement 
> wrote:
>
>> It is fixed up. It was the order of processing as suspected, it can also
>> vary on the same OS ( I can make it fail on my mac by passing A last ).
>>
>> Because ordering is not supposed to be important we don’t sort source
>> file inputs. This means you can be at the mercy of what your JVM decides to
>> do.  As types go through the compilation pipeline they are initially
>> represented by an eclipse type then later on by a binary byte code based
>> type.  The code to verify the rules of declare parents was encountering one
>> of the types in one form when it worked and in the other when it failed.
>>
>> if you grab a 1.8.13.BUILD-SNAPSHOT from the maven repo
>> repo.spring.io/snapshot then you’ll pick up the fix. I confirmed that
>> fixes your sample.
>>
>> cheers,
>> Andy
>>
>> On Nov 1, 2017, at 12:05 PM, Jason Britton  wrote:
>>
>> Thanks for investigating.  What's strange is I'm using IntelliJ on a Mac
>> (using the Maven project) and I get the compilation error.
>>
>> On Wed, Nov 1, 2017 at 10:59 AM, Andy Clement 
>> wrote:
>>
>>> Thanks for the test project. It compiled fine for me on Mac but then I
>>> thought I’d try windows and sure enough over there it fails. It may be the
>>> order of the processing of the files (which can vary across OS), digging
>>> into it now.
>>>
>>> Andy
>>>
>>> On Oct 31, 2017, at 4:41 PM, Jason Britton  wrote:
>>>
>>> Hi Andy -
>>> Thanks for looking into.  I've created a public github repo with a maven
>>> project that recreates the issue here:  https://github.com/JOBr
>>> itton/aspectj-generics-issue
>>>
>>> Let me know if you are able to reproduce.  Thanks!
>>>
>>> Jason
>>>
>>> On Tue, Oct 31, 2017 at 1:19 PM, Andy Clement 
>>> wrote:
>>>
>>>> I recall in the early days of AspectJ 5 we had a mountain of issues
>>>> like this, but I thought they’d all been ironed out !
>>>>
>>>> Hmm, I guess there must be a little more to it, here are my source
>>>> files that simulate what you wrote:
>>>>
>>>> ---
>>>> import java.util.*;
>>>> interface A {
>>>> T setInputs(List inputs);
>>>> }
>>>> ---
>>>> import java.util.*;
>>>> public class AlreadyImplementsA {
>>>> public ConcreteTImpl setInputs(List inputs) {
>>>> return null;
>>>> }
>>>> }
>>>> ---
>>>> interface BaseI {}
>>>> ---
>>>> interface BaseT {}
>>>> ---
>>>> class ConcreteIImpl implements BaseI {}
>>>> ---
>>>> class ConcreteTImpl implements BaseT {}
>>>> ---
>>>> public aspect BindInterfaceA {
>>>>   declare parents: AlreadyImplementsA implements A>>> ConcreteIImpl>;
>>>> }
>>>> ---
>>>>
>>>>
>>>> -> ajc -1.8 A.java BaseT.java AlreadyImplementsA.java  BaseI.java
>>>> ConcreteIImpl.java ConcreteTImpl.java -outjar code.jar
>>>>
>>>>
>>>> -> ajc -inpath code.jar -showWeaveInfo BindInterfaceA.java -outjar
>>>> code2.jar
>>>> Extending interface set for type 'AlreadyImplementsA'
>>>> (AlreadyImplementsA.java) to include 'A'
>>>> (BindInterfaceA.java)
>>>>
>>>> -> javap -classpath code2.jar AlreadyImplementsA
>>>> Compiled from "AlreadyImplementsA.java"
>>>> public class AlreadyImplementsA implements A {
>>>>
>>>>
>>>> Are you applying the aspect via binary weaving?  I do notice a
>>>> difference in separate compilation vs all source:
>>>>
>>>> -> ajc -1.8 *.java -showWeaveInfo -outjar foo.jar
>>>> Extending interface set for type 'AlreadyImplementsA'
>>>> (AlreadyImplementsA.java) to include 'A'
>>>> (BindInterfaceA.java)
>>>>
>>>> -> javap -classpath foo.jar AlreadyImplementsA
>>>> Compiled from "AlreadyImplem

Re: [aspectj-users] ajc issues with interfaces using generics

[Andy Clement]

It is fixed up. It was the order of processing as suspected, it can also vary 
on the same OS ( I can make it fail on my mac by passing A last ).

Because ordering is not supposed to be important we don’t sort source file 
inputs. This means you can be at the mercy of what your JVM decides to do.  As 
types go through the compilation pipeline they are initially represented by an 
eclipse type then later on by a binary byte code based type.  The code to 
verify the rules of declare parents was encountering one of the types in one 
form when it worked and in the other when it failed.

if you grab a 1.8.13.BUILD-SNAPSHOT from the maven repo repo.spring.io/snapshot 
then you’ll pick up the fix. I confirmed that fixes your sample.

cheers,
Andy

> On Nov 1, 2017, at 12:05 PM, Jason Britton  wrote:
> 
> Thanks for investigating.  What's strange is I'm using IntelliJ on a Mac 
> (using the Maven project) and I get the compilation error.  
> 
> On Wed, Nov 1, 2017 at 10:59 AM, Andy Clement  <mailto:andrew.clem...@gmail.com>> wrote:
> Thanks for the test project. It compiled fine for me on Mac but then I 
> thought I’d try windows and sure enough over there it fails. It may be the 
> order of the processing of the files (which can vary across OS), digging into 
> it now.
> 
> Andy
> 
>> On Oct 31, 2017, at 4:41 PM, Jason Britton > <mailto:jbritto...@gmail.com>> wrote:
>> 
>> Hi Andy -
>> Thanks for looking into.  I've created a public github repo with a maven 
>> project that recreates the issue here:  
>> https://github.com/JOBritton/aspectj-generics-issue 
>> <https://github.com/JOBritton/aspectj-generics-issue>
>> 
>> Let me know if you are able to reproduce.  Thanks!
>> 
>> Jason
>> 
>> On Tue, Oct 31, 2017 at 1:19 PM, Andy Clement > <mailto:andrew.clem...@gmail.com>> wrote:
>> I recall in the early days of AspectJ 5 we had a mountain of issues like 
>> this, but I thought they’d all been ironed out !
>> 
>> Hmm, I guess there must be a little more to it, here are my source files 
>> that simulate what you wrote:
>> 
>> ---
>> import java.util.*;
>> interface A {
>>  T setInputs(List inputs);
>> }
>> ---
>> import java.util.*;
>> public class AlreadyImplementsA {
>>  public ConcreteTImpl setInputs(List inputs) {
>>  return null;
>>  }
>> }
>> ---
>> interface BaseI {}
>> ---
>> interface BaseT {}
>> ---
>> class ConcreteIImpl implements BaseI {}
>> ---
>> class ConcreteTImpl implements BaseT {}
>> ---
>> public aspect BindInterfaceA {
>>declare parents: AlreadyImplementsA implements A> ConcreteIImpl>;
>> }
>> ---
>> 
>> 
>> -> ajc -1.8 A.java BaseT.java AlreadyImplementsA.java  BaseI.java 
>> ConcreteIImpl.java ConcreteTImpl.java -outjar code.jar
>> 
>> 
>> -> ajc -inpath code.jar -showWeaveInfo BindInterfaceA.java -outjar code2.jar
>> Extending interface set for type 'AlreadyImplementsA' 
>> (AlreadyImplementsA.java) to include 'A' 
>> (BindInterfaceA.java)
>> 
>> -> javap -classpath code2.jar AlreadyImplementsA
>> Compiled from "AlreadyImplementsA.java"
>> public class AlreadyImplementsA implements A {
>> 
>> 
>> Are you applying the aspect via binary weaving?  I do notice a difference in 
>> separate compilation vs all source:
>> 
>> -> ajc -1.8 *.java -showWeaveInfo -outjar foo.jar
>> Extending interface set for type 'AlreadyImplementsA' 
>> (AlreadyImplementsA.java) to include 'A' 
>> (BindInterfaceA.java)
>> 
>> -> javap -classpath foo.jar AlreadyImplementsA
>> Compiled from "AlreadyImplementsA.java"
>> public class AlreadyImplementsA implements A {
>> 
>> Note that in the binary weaving case the type parameters are missing on the 
>> implements clause.
>> 
>> How are you building it? Can you adapt my steps above to show the fault.
>> 
>> cheers,
>> Andy
>> 
>>> On Oct 30, 2017, at 2:11 PM, Jason Britton >> <mailto:jbritto...@gmail.com>> wrote:
>>> 
>>> Hi -
>>> I'm running into a perplexing issue with AJC and I'm hoping someone else 
>>> has seen this before.
>>> 
>>> The target of my aspect is the class AlreadyImplementsA, we are simply 
>>> wanting to throw the 'implements A' onto this class.  AlreadyImplementsA 
>>> class already does indeed  implement every method defined by the interface 
>>> A but 

Re: [aspectj-users] ajc issues with interfaces using generics

[Andy Clement]

Thanks for the test project. It compiled fine for me on Mac but then I thought 
I’d try windows and sure enough over there it fails. It may be the order of the 
processing of the files (which can vary across OS), digging into it now.

Andy

> On Oct 31, 2017, at 4:41 PM, Jason Britton  wrote:
> 
> Hi Andy -
> Thanks for looking into.  I've created a public github repo with a maven 
> project that recreates the issue here:  
> https://github.com/JOBritton/aspectj-generics-issue 
> <https://github.com/JOBritton/aspectj-generics-issue>
> 
> Let me know if you are able to reproduce.  Thanks!
> 
> Jason
> 
> On Tue, Oct 31, 2017 at 1:19 PM, Andy Clement  <mailto:andrew.clem...@gmail.com>> wrote:
> I recall in the early days of AspectJ 5 we had a mountain of issues like 
> this, but I thought they’d all been ironed out !
> 
> Hmm, I guess there must be a little more to it, here are my source files that 
> simulate what you wrote:
> 
> ---
> import java.util.*;
> interface A {
>   T setInputs(List inputs);
> }
> ---
> import java.util.*;
> public class AlreadyImplementsA {
>   public ConcreteTImpl setInputs(List inputs) {
>   return null;
>   }
> }
> ---
> interface BaseI {}
> ---
> interface BaseT {}
> ---
> class ConcreteIImpl implements BaseI {}
> ---
> class ConcreteTImpl implements BaseT {}
> ---
> public aspect BindInterfaceA {
> declare parents: AlreadyImplementsA implements A ConcreteIImpl>;
> }
> ---
> 
> 
> -> ajc -1.8 A.java BaseT.java AlreadyImplementsA.java  BaseI.java 
> ConcreteIImpl.java ConcreteTImpl.java -outjar code.jar
> 
> 
> -> ajc -inpath code.jar -showWeaveInfo BindInterfaceA.java -outjar code2.jar
> Extending interface set for type 'AlreadyImplementsA' 
> (AlreadyImplementsA.java) to include 'A' 
> (BindInterfaceA.java)
> 
> -> javap -classpath code2.jar AlreadyImplementsA
> Compiled from "AlreadyImplementsA.java"
> public class AlreadyImplementsA implements A {
> 
> 
> Are you applying the aspect via binary weaving?  I do notice a difference in 
> separate compilation vs all source:
> 
> -> ajc -1.8 *.java -showWeaveInfo -outjar foo.jar
> Extending interface set for type 'AlreadyImplementsA' 
> (AlreadyImplementsA.java) to include 'A' 
> (BindInterfaceA.java)
> 
> -> javap -classpath foo.jar AlreadyImplementsA
> Compiled from "AlreadyImplementsA.java"
> public class AlreadyImplementsA implements A {
> 
> Note that in the binary weaving case the type parameters are missing on the 
> implements clause.
> 
> How are you building it? Can you adapt my steps above to show the fault.
> 
> cheers,
> Andy
> 
>> On Oct 30, 2017, at 2:11 PM, Jason Britton > <mailto:jbritto...@gmail.com>> wrote:
>> 
>> Hi -
>> I'm running into a perplexing issue with AJC and I'm hoping someone else has 
>> seen this before.
>> 
>> The target of my aspect is the class AlreadyImplementsA, we are simply 
>> wanting to throw the 'implements A' onto this class.  AlreadyImplementsA 
>> class already does indeed  implement every method defined by the interface A 
>> but for whatever reason, AJC complains that AlreadyImplementsA does Not 
>> implement A because of the method
>> 
>> T setInputs(List inputs);
>> 
>> I can have a whole multitude of other methods defined on the interface and 
>> AJC does not complain, it seems to have a problem with the fact that the 
>> argument to the method on the interface is an Interface (List) with a 
>> generic I.  As I have other AJC issues where the method argument is a Map of 
>> a generic type and AJC blows up on it as well.   
>> 
>> My aspect below
>> 
>> public aspect BindInterfaceA {
>> declare parents: AlreadyImplementsA implements A> ConcreteIImpl>;
>> 
>> }
>> 
>> My interface A referenced above has an interface method defined as shown 
>> below
>> 
>> public interface A {
>> 
>> T setInputs(List inputs);
>> }
>> 
>> The 'exact' AJC error message is 
>> AlreadyImplementsA must implement the inherited abstract method 
>> A.setInputs(Pjava/util/list;)
>> 
>> I am almost positive the problem all boils down to an interface with a 
>> generic being passed as a argument to the method (List inputs) in our 
>> case, which is causing AJC problems. 
>> Thanks for any advice you might have on getting past this.
>> 
>> Jason
>> 
>> ___
>&

Re: [aspectj-users] ajc issues with interfaces using generics

[Andy Clement]

I recall in the early days of AspectJ 5 we had a mountain of issues like this, 
but I thought they’d all been ironed out !

Hmm, I guess there must be a little more to it, here are my source files that 
simulate what you wrote:

---
import java.util.*;
interface A {
T setInputs(List inputs);
}
---
import java.util.*;
public class AlreadyImplementsA {
public ConcreteTImpl setInputs(List inputs) {
return null;
}
}
---
interface BaseI {}
---
interface BaseT {}
---
class ConcreteIImpl implements BaseI {}
---
class ConcreteTImpl implements BaseT {}
---
public aspect BindInterfaceA {
  declare parents: AlreadyImplementsA implements A;
}
---


-> ajc -1.8 A.java BaseT.java AlreadyImplementsA.java  BaseI.java 
ConcreteIImpl.java ConcreteTImpl.java -outjar code.jar


-> ajc -inpath code.jar -showWeaveInfo BindInterfaceA.java -outjar code2.jar
Extending interface set for type 'AlreadyImplementsA' (AlreadyImplementsA.java) 
to include 'A' (BindInterfaceA.java)

-> javap -classpath code2.jar AlreadyImplementsA
Compiled from "AlreadyImplementsA.java"
public class AlreadyImplementsA implements A {


Are you applying the aspect via binary weaving?  I do notice a difference in 
separate compilation vs all source:

-> ajc -1.8 *.java -showWeaveInfo -outjar foo.jar
Extending interface set for type 'AlreadyImplementsA' (AlreadyImplementsA.java) 
to include 'A' (BindInterfaceA.java)

-> javap -classpath foo.jar AlreadyImplementsA
Compiled from "AlreadyImplementsA.java"
public class AlreadyImplementsA implements A {

Note that in the binary weaving case the type parameters are missing on the 
implements clause.

How are you building it? Can you adapt my steps above to show the fault.

cheers,
Andy

> On Oct 30, 2017, at 2:11 PM, Jason Britton  wrote:
> 
> Hi -
> I'm running into a perplexing issue with AJC and I'm hoping someone else has 
> seen this before.
> 
> The target of my aspect is the class AlreadyImplementsA, we are simply 
> wanting to throw the 'implements A' onto this class.  AlreadyImplementsA 
> class already does indeed  implement every method defined by the interface A 
> but for whatever reason, AJC complains that AlreadyImplementsA does Not 
> implement A because of the method
> 
> T setInputs(List inputs);
> 
> I can have a whole multitude of other methods defined on the interface and 
> AJC does not complain, it seems to have a problem with the fact that the 
> argument to the method on the interface is an Interface (List) with a generic 
> I.  As I have other AJC issues where the method argument is a Map of a 
> generic type and AJC blows up on it as well.   
> 
> My aspect below
> 
> public aspect BindInterfaceA {
> declare parents: AlreadyImplementsA implements A ConcreteIImpl>;
> 
> }
> 
> My interface A referenced above has an interface method defined as shown below
> 
> public interface A {
> 
> T setInputs(List inputs);
> }
> 
> The 'exact' AJC error message is 
> AlreadyImplementsA must implement the inherited abstract method 
> A.setInputs(Pjava/util/list;)
> 
> I am almost positive the problem all boils down to an interface with a 
> generic being passed as a argument to the method (List inputs) in our 
> case, which is causing AJC problems. 
> Thanks for any advice you might have on getting past this.
> 
> Jason
> 
> ___
> 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

Re: [aspectj-users] How to ensure AspectJ aspects are LTW'ed by Wildfly's modules?

[Andy Clement]

> I suspected that AJ just uses whatever classloader is provided to it.

Yes, exactly. Because we don’t want to get into tricks around classloaders. I 
am a bit rusty but I think for weaving a particular type you can see the entry 
point in the type Aj is driven every time something is loaded once you’ve 
registered the agent:

public byte[] preProcess(String className, byte[] bytes, ClassLoader 
loader, ProtectionDomain protectionDomain) {

This is invoked by the ClassFileTransformer 
(java.lang.instrument.ClassFileTransformer) implementation in AspectJ called 
ClassPreProcessorAgentAdapter

The class file transformer is passed the loader and the bytes for a particular 
class. From the loader we determine the weaver instance which gives us the 
context to weave the bytes.  If that loader does not provide visibility to 
something, the weaver instance for that loader will not be able to see it. In 
your case if it is this module loader, and it is not delegating class/resource 
lookups to a parent then AspectJ will not find anything outside the module.  
I’d suspect there is a way to have common modules but I’ve no idea how wildfly 
allows that.

> So given that the AJ Weaver doesn't find the classes, I figure that WF is 
> doing something with/to it. 

Yep, me too.

>  Do you know if there are any docs or whitepapers I can read up on how the 
> classloader/instrumentation cycle works?  I couldn't find enough clarity on 
> the Oracle site.

Search up ClassFileTransformer but honestly, I might be wrong, but I don’t 
think that has much to do with it here. It is entirely down to how visibility 
from that loader should be setup in wildfly.  Write some code that has nothing 
to do with aspects and don’t attach the agent. Something like this in your 
application:

 Class.forName(“some type from aspects.jar”,false, 
this.getClass().getClassLoader()); - can that access them? 

If it can what about:

this.getClass().getClassLoader().getResourceAsStream(…class file reference…) - 
can that see them too?

If those are true then AspectJ ought to be able to see them.

> I haven't tried posting on StackOverflow yet figuring that I would likely get 
> a more targeted response from here or the wildfly-dev forums. 

Folks like scoring points answering questions on stackoverflow - you might get 
a good answer :)

cheers,
Andy


> On Oct 26, 2017, at 2:23 PM, Eric B  wrote:
> 
> I did try with my aspect.jar on the bootclasspath with -Xbootclasspath/a (I 
> would be surprised if  /a or a /p would make a difference).  Didn't make any 
> difference.
> 
> I haven't tried posting on StackOverflow yet figuring that I would likely get 
> a more targeted response from here or the wildfly-dev forums.  But to date, 
> it's tough to reconcile information from the two independent camps. :)
> I suspected that AJ just uses whatever classloader is provided to it.  That's 
> kind of what it looked like to me.  But I couldn't/don't understand how the 
> Agent bootstraps though.  From what I can tell, its the base JVM's 
> classloader that calls the Agent premain, and instructs it to instrument the 
> classes.  In which case, I would expect any visibility of that classloader to 
> extend to AJ as well.
> 
> So given that the AJ Weaver doesn't find the classes, I figure that WF is 
> doing something with/to it.  But in that case, I dont understand at all how 
> the JVM's instrumentation works; I guess I'm confused where in the cycle the 
> instrumentation is called when loading classes.  Do you know if there are any 
> docs or whitepapers I can read up on how the classloader/instrumentation 
> cycle works?  I couldn't find enough clarity on the Oracle site.
> 
> Thanks,
> 
> Eric
> 
> On Thu, Oct 26, 2017 at 3:07 PM, Andy Clement  <mailto:andrew.clem...@gmail.com>> wrote:
> Did you try your aspect jar on the bootclasspath ? (Just wondering if that 
> might help).
> 
> AspectJ deliberately avoids getting involved in class loader shenanigans 
> because it gets too complicated, hence relying on the delegation model in 
> place for the system it is being used with.  However you make a ‘common jar’ 
> available to all the individual module loaders in wildfly should work for 
> AspectJ, unless they are handling delegation for classes differently to 
> delegation for resource access. I don’t feel this is a new problem though, I 
> feel it has come up again and again over the years - surely somebody solved 
> it by now Did you try stack overflow? Sorry i don’t have any concrete 
> answers.
>  
> cheers,
> Andy
> 
> 
>> On Oct 26, 2017, at 11:37 AM, Eric B > <mailto:ebenza...@gmail.com>> wrote:
>> 
>> Thanks for the info.  I've been digging through AJ and WF code some mor

Re: [aspectj-users] How to ensure AspectJ aspects are LTW'ed by Wildfly's modules?

[Andy Clement]

Did you try your aspect jar on the bootclasspath ? (Just wondering if that 
might help).

AspectJ deliberately avoids getting involved in class loader shenanigans 
because it gets too complicated, hence relying on the delegation model in place 
for the system it is being used with.  However you make a ‘common jar’ 
available to all the individual module loaders in wildfly should work for 
AspectJ, unless they are handling delegation for classes differently to 
delegation for resource access. I don’t feel this is a new problem though, I 
feel it has come up again and again over the years - surely somebody solved it 
by now Did you try stack overflow? Sorry i don’t have any concrete answers.
 
cheers,
Andy

> On Oct 26, 2017, at 11:37 AM, Eric B  wrote:
> 
> Thanks for the info.  I've been digging through AJ and WF code some more to 
> try to figure this out, but am still not sure how the classloader is working. 
>  I'm starting Wildfly using the following arguments:
> 
> -Djboss.modules.system.pkgs=org.jboss.byteman,org.aspectj,test.aspectj,org.jboss.logmanager
> -javaagent:c:/dev/tmp/jboss-eap-7.0.0/modules/system/layers/base/org/aspectj/main/aspectjweaver-1.8.10.jar
> -Dorg.aspectj.weaver.showWeaveInfo=true"
> -Dorg.aspectj.weaver.loadtime.configuration=file:c:/tmp/poc/aop.xml
> -cp 
> C:/dev/Projects/jms/mixed-arch/ear-app/aspectj/target/aspectj-0.0.1-SNAPSHOT.jar
> 
> 
> So in it, I've defined an additional classpath pointing to my aspectj.jar 
> file.  My /tmp/poc/aop.xml contains the aspect definition of 
> "test.aspectj.TestAspect".
> I can now see that the AJ agent is looking for test.aspectj.TestAspect class. 
>  But it still isn't able to find it; I get the following errors thrown my the 
> AspectJ Weaver: 
> 
> 2017-10-26 12:11:39,889 ERROR [stderr] (MSC service thread 1-7) 
> [ModuleClassLoader@336f62a1] info register aspect test.aspectj.TestAspect
> 2017-10-26 12:11:54,632 ERROR [stderr] (MSC service thread 1-7) 
> [ModuleClassLoader@336f62a1] error The specified aspect 
> 'test.aspectj.TestAspect' cannot be found
> 
> I've confirmed that my class (test.aspectj.TestAspect) is indeed in the 
> aspectj-0.0.1-SNAPSHOT.jar.
> 
> So I get the impression that the aspectj-SNAPSHOT jar is not being made 
> visible to the individual module classloaders.  I've tried to debug the 
> weaver, and can see that it does indeed do the following:
> 
>   private URL toURL(String className) {
>   URL url = (URL) nameMap.get(className);
>   if (url == null) {
>   String classFile = className.replace('.', '/');
>   url = loaderRef.getClassLoader().getResource(classFile 
> + ".class");
>   nameMap.put(className, url);
>   }
>   return url;
>   }
> 
> where the loaderRef.getClassLoader() looks like it is the classloader that is 
> passed to the ClassFileTransformer.transform() method 
> (https://docs.oracle.com/javase/7/docs/api/java/lang/instrument/ClassFileTransformer.html
>  
> <https://docs.oracle.com/javase/7/docs/api/java/lang/instrument/ClassFileTransformer.html>).
>   But I'm not sure where/how to continue digging from here.  Which 
> classloader is this?  Is this the base java classloader?  If Wildfly defines 
> its own classloader (not sure if it does), will it be used instead?  On the 
> other hand, if the base java classloader is passed, why is the classloader 
> not able to find my test.aspectj.TestAspect class if it is in the jar that is 
> part of my -cp arguments?
> 
> 
> Thanks,
> 
> Eric
> 
> On Mon, Oct 23, 2017 at 1:45 PM, Andy Clement  <mailto:andrew.clem...@gmail.com>> wrote:
> Yes, it is a bit specific to wildfly but I can talk to what AspectJ does.  I 
> will also call out to an old article I wrote on debugging LTW: 
> http://andrewclement.blogspot.ca/2009/02/load-time-weaving-basics.html 
> <http://andrewclement.blogspot.ca/2009/02/load-time-weaving-basics.html> 
> (might be useful).
> 
> In the source for ClassLoaderWeavingAdaptor you will see three options for 
> files we look for:
> 
> META-INF/aop.xml  — the regular one
> META-INF/aop-ajc.xml — another option, useful in case you are using -outxml 
> to generate the XML and don’t want to damage some user config you are 
> maintaining (keep user stuff in aop-ajc.xml)
> org/aspectj/aop.xml — for OSGi usage but not specific to OSGi, can be used in 
> other scenarios.
> 
> Also in the same class you’ll see:
> 
> private final static String AOP_XML = Constants.AOP_USER_XML + ";" + 
> Constants.AOP_AJC_XML + ";" + Constants.AOP_OSGI_X

Re: [aspectj-users] adding interface to classes in jars that already have interface implementation

[Andy Clement]

Hey,

So sorry! I noticed I wrote this the other day but have left it in draft, 
finally sending now...

What you are doing looks OK but as you surmise your new code will only work if 
the aspect has had a chance to apply.  Let’s step through it. I’ll use real 
code:

=== 8<  A.java ==
public interface A {}

=== 8<  Impl.java ==
public class Impl implements A {}

Let’s build those:

ajc -1.9 A.java Impl.java -outjar original.jar



=== 8<  A.java ==
public interface B {}

Let’s build our new interface:
ajc -1.9 B.java -outjar b.jar


=== 8<  Azpect.java ==
aspect Azpect {
declare parents: A+ implements B;
}

=== 8<  Test.java ==
public class Test {
  public static void main(String []argv) {
 A impl = new Impl();
 B b = impl;
  }
}


So the Test program will only compile if the aspect can make the change it 
needs to:

ajc -1.9 -classpath ../aspectjrt.jar:original.jar:b.jar Test.java Azpect.java
Azpect.java:2 [warning] this affected type is not exposed to the weaver: A 
[Xlint:typeNotExposedToWeaver]
declare parents: A+ implements B;
^^
[Xlint:typeNotExposedToWeaver]
Test.java:4 [error] Type mismatch: cannot convert from A to B
B b = impl;

Notice here, it can’t. Because A.java is on the class path, it does not get 
woven (we need to write out a new version of A that extends B).

(Yes, in this case "A+ implements B" is being implemented as changing A to make 
it extend B rather than changing all implementors of A to also implement B).

There are a few options for tackling this. Perhaps the cleanest/simplest is to 
modify the jar with our changes before using it:

ajc -1.9 -inpath original.jar -outjar new.jar Azpect.java B.java -showWeaveInfo
Extending interface set for type 'A' (A.java) to include 'B' (Azpect.java)

Now we can use it:

ajc -1.9 -classpath ../aspectjrt.jar:new.jar Test.java

java -classpath new.jar:. Test

Works OK

We could get it to compile all in one go by combining those steps:

ajc -1.9 -inpath original.jar Azpect.java B.java Test.java -showWeaveInfo
Extending interface set for type 'A' (A.java) to include 'B' (Azpect.java)

java -classpath . Test

This works because we are making A/Impl available to the weaver as candidates 
for change by passing them on the inpath. But you are left with a mess of 
everything in the target folder.  You could use -outjar here but your test will 
then all be in your output jar.

I hope that helps explain what is happening.

Andy

> On Oct 21, 2017, at 12:18 PM, Jason Britton  wrote:
> 
> Hi - 
> I've got a bunch of generated classes across multiple jars that I cannot 
> change the source on, nor can I change how they are generated.  These 
> generated classes all implement interface "A"
> 
> I'd like to add another interface to all these generated classes to make use 
> of a handful of other methods they all already implement.  Essentially I'd 
> like to simply add in another "implements B" to their definitions at compile 
> time.  I've defined "B" interface and my aspect looks like this:
> 
>   public aspect ImplementBInterfaceAspect {
> 
>   declare parents : A+ implements B;
> 
>   }
> 
> Does that look correct?  I wrote some code that I thought would correctly 
> prove the new "implements B" was being weaved in correctly.  That code looks 
> like:
> 
>   // C implements A by source code definition, and should have be known 
> to "implements B" due to weaving of the aspect defined above
>   C cInstance = new C();
> 
>   // B is an interface, cInstance should be known to implements B if 
> weaving is taking place
>   B refToCInstance = cInstance;
> 
> The code above doesn't compile.  Complaining that cInstance cannot be 
> assigned to refToCInstance.  I'm now realizing that weaving must not happen 
> until after all existing code is already compiled??  Sorry for my beginner's 
> understanding of AspectJ.  What would be a better test to validate that my 
> desired weaving is happening?  
> 
> Thank you any clarity you can provide.
> 
> Jason 
> ___
> 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

Re: [aspectj-users] How to ensure AspectJ aspects are LTW'ed by Wildfly's modules?

[Andy Clement]

Yes, it is a bit specific to wildfly but I can talk to what AspectJ does.  I 
will also call out to an old article I wrote on debugging LTW: 
http://andrewclement.blogspot.ca/2009/02/load-time-weaving-basics.html 
 (might 
be useful).

In the source for ClassLoaderWeavingAdaptor you will see three options for 
files we look for:

META-INF/aop.xml  — the regular one
META-INF/aop-ajc.xml — another option, useful in case you are using -outxml to 
generate the XML and don’t want to damage some user config you are maintaining 
(keep user stuff in aop-ajc.xml)
org/aspectj/aop.xml — for OSGi usage but not specific to OSGi, can be used in 
other scenarios.

Also in the same class you’ll see:

private final static String AOP_XML = Constants.AOP_USER_XML + ";" + 
Constants.AOP_AJC_XML + ";" + Constants.AOP_OSGI_XML;
String resourcePath = 
System.getProperty("org.aspectj.weaver.loadtime.configuration", AOP_XML);

So you can override those 3 places and give it the path to something else if 
you want to by specifying that property. If the thing you provide starts with 
file then it will actually load direct from there:

if (nextDefinition.startsWith("file:")) {
try {
String fpath = new URL(nextDefinition).getFile();
File configFile = new File(fpath);

If you just run default then it will be making calls to 
getClassLoader().getResources(name); for those three variants above. So you are 
at the mercy of whatever the class loader is allowing you to see.

cheers,
Andy

> On Oct 21, 2017, at 7:19 PM, Eric B  wrote:
> 
> So this is probably more of a Wildfly question than an AspectJ question as 
> such, and I have already asked the Wildfly team about it, but I thought I 
> would try to get additional clarity from the AJ pros to understand exactly 
> how the LTW agent works.
> 
> My use case is that I want to use use AspectJ to advise some core classes in 
> Wildfly/undertow.  Specifically, I'm trying to advise some of the Undertow 
> HttpSession methods to get some more detailed logging when Sessions are 
> created/expire/etc.
> 
> To that extent, I've added AspectJ as a -javaagent which is launched on 
> startup of Wildfly.  I had to follow some of the steps listed at: 
> https://github.com/ChienChingLee/How-to-launch-Wildfly-9.0-with-AspectJ-1.8-LTW
>  
> .
>   But it works; I can see that the AJ weaver is loaded and present.
> 
> My problem now has to do with the way that the Wildfly classloaders work.  
> From my understanding, to avoid class conflict issues, the Application Server 
> is designed such that everything is broken down into individual modules, with 
> a separate classloader for each module.  Modules can declare dependencies on 
> other modules if they truly want/need to access classes defined in a 
> different module (see 
> https://docs.jboss.org/author/display/WFLY10/Class+Loading+in+WildFly 
> )
> 
> I've tried to configure AJ to have the loader available to all modules, so 
> now my question is how does AJ detect Aspects in the classpath?  Where/how 
> does it search for the aop.xml file?  Does the weaver search every jar that 
> is in the classpath for these files?  How does it determine which files to 
> scan in the classpath?  Does it simply delegate that to the classloader?  
> (ie: Class.getResourceAsStream("aop.xml"))?  I haven't dug through the AJ 
> code to see exactly what it does.
> 
> Right now, I'm a little stuck in that I'm not sure how to ensure that my 
> Aspects are loaded with every module in WF.  I've managed to reconfigure a 
> single module and it works, but the idea of reconfiguring every module 
> individually doesn't make sense.  
> 
> I tried to create an independent module in WF for it, and declaring it as a 
> global module but that didn't seem to work.  
> 
> I tried to add it to the startup parameters in the WF startup configuration 
> file, specifying it as -classpath path/to/myaspect.jar, but that only advised 
> the startup WF (org.jboss) classes and none of the modules.
> 
> Can anyone shed some more light how the LTW works in order to search/find and 
> weave classes?  Or if anyone has any brilliant ideas how I can configure my 
> WF server such that I can drop my asepcts.jar in a "generic" place to make it 
> woven into every module, I would appreciate it.
> 
> Thanks!
> 
> Eric
> ___
> 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 fro

[aspectj-users] AspectJ 1.8.12 and AspectJ 1.9.0.rc1 released

[Andy Clement]

Both AspectJ 1.8.12 and 1.9.0.rc1 have been released.

1.8.12 includes some slightly radical improvements that impact Spring AOP 
performance. The README has more details: 
https://www.eclipse.org/aspectj/doc/released/README-1812.html 


1.9.0.RC1 is the AspectJ to use if you are on Java9. It includes the Eclipse 
Java 9 JDT compiler. You can compile modules that include aspects. It also 
includes the Spring AOP changes that are in 1.8.12. Some examples of working 
with modules are in the readme: 
https://www.eclipse.org/aspectj/doc/released/README-190.html 


1.8.12 is in maven central, 1.9.0.RC1 is in the usual maven repository for non 
final releases: http://repo.spring.io/milestone

Feedback here or on bugzilla is appreciated. I encourage anyone using Spring 
AOP to kick the tires on 1.8.12 and let me know if it does not behave for you.

___
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

Re: [aspectj-users] Aspectjweaver.jar outputting on stderr vs stdout

[Andy Clement]

I don’t think anything was done. I’ve been a bit heads down on AspectJ 9 for 
the last little while. And if there isn’t a ticket, things tend to fall off the 
radar I’m afraid…  (And I don’t recall seeing one).

cheers,
Andy

> On Oct 20, 2017, at 10:37 AM, Eric B  wrote:
> 
> Hi Andy,
> 
> Was anything ever done about this, or a ticket opened for it?  I'm running AJ 
> 1.8.10 and still seeing the same behaviour, so I figure it was probably never 
> addressed (ticket or otherwise).
> 
> Thanks,
> 
> Eric
> 
> 
> On Thu, Oct 6, 2016 at 3:49 PM, Eric B  <mailto:ebenza...@gmail.com>> wrote:
> Ok - thanks for the confirmation.  I will have to let the team know that all 
> ERROR logs are not actual ERROR logs, but only INFO logs.
> 
> Eric
> 
> On Thu, Oct 6, 2016 at 3:26 PM, Andy Clement  <mailto:andrew.clem...@gmail.com>> wrote:
> First time I've ever looked at that bit of code but I do see the code says 
> this in the WeavingAdaptor:
> 
>   protected void createMessageHandler() {
>   messageHolder = new WeavingAdaptorMessageHolder(new 
> PrintWriter(System.err));
> 
> So all messages sent to that message handler will go to System.err, 
> regardless of severity. That seems a bit crappy. I guess presumably it was 
> done to avoid messages messing up whatever your app was doing on System.out 
> (possibly even just to make testing easier - look for app output on 
> System.out and look for weaver output on System.err).
> 
> It should be configurable but right now I can't see any way you can influence 
> it.
> 
> cheers,
> Andy
> 
> 
> 
> On 6 October 2016 at 11:36, Eric B  <mailto:ebenza...@gmail.com>> wrote:
> I'm using AspectJ 1.6 with JBoss 4.2.1 configured with LoadTimeWeaving.
> 
> I have added the aspectjweaver.jar to the startup parameters:
>  -javaagent:c:/dev/Java/aspectj1.6/lib/aspectjweaver.jar 
> 
> AspectJ is properly loaded and indeed is weaving my classes as 
> desired/expected.  However, any weaveinfo data that it is producing is being 
> logged as an "Error" as it appears in the stderr stream instead of the stdout:
> 
> 2016-10-06 13:31:40,310 ERROR [STDERR] [UnifiedClassLoader3@333cf5e3] 
> weaveinfo Join point 'method-call(business.impl.BusinessContext 
> business.ejb3.ManagerBean.getBusinessContext(izone.business.BusinessContextInfo))'
>  in Type 'business.ejb3.ManagerBean' (ManagerBean.java:112) advised by 
> afterThrowing advice from 'common.security.logger.AccessDeniedLoggerAspect' 
> (AccessDeniedLoggerAspect.java)
> 
> 
> According to the JBoss documentation, System.err stream is redirected into a 
> category called STDERR, which is what I see above.
> 
> Is there a way to configure the weaver to output on stdout instead?  Or is it 
> working this way by design?
> 
> Thanks,
> 
> Eric
> 
> 
> 
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org <mailto: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 
> <https://dev.eclipse.org/mailman/listinfo/aspectj-users>
> 
> 
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org <mailto: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 
> <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

___
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

Re: [aspectj-users] Missing stackmap generation for woven code

[Andy Clement]

You are only able to turn off the stackmap generation if targeting 1.6
because that is the level where they were optional.
(-Xset:generateStackMaps=false) at targets 1.7 and above your error
indicates this code is failing:


*try* {

Class reader = Class.forName("aj.org.objectweb.asm.ClassReader");

Class visitor = Class.forName("aj.org.objectweb.asm.ClassVisitor");

Method m = reader.getMethod("accept", *new* Class[] { visitor, Integer.
*TYPE* });

isAsmAround = m != *null*;

} *catch* (Exception e) {

isAsmAround = *false*;

}

For some reason we can't find those classes even though they should be in
the AspectJ jars you are using? (You could check your 1.8.10 artifacts
include them... but I can't see why not).  There is a 1.8.11 you could also
try but the packaging has not changed there. I am confused why the check
above is failing for you. You could raise an issue but without being able
to recreate I'm not sure how I'd diagnose things.  What JDK are you running
the build itself on, 1.8 I presume?

cheers,
Andy

On 10 October 2017 at 20:06, Eric B  wrote:

> Thanks Andy!
>
> I'll take a look into this and see if I can leverage it for my own use
> case.
>
> Also, please let me know if the Error that I am seeing is a bug in AJ, or
> expected behaviour.  Do you need me to open a ticket for that?
>
> Thanks,
>
> Eric
>
>
> On Tue, Oct 10, 2017 at 3:34 PM, Andy Clement 
> wrote:
>
>> The very basic visitor AspectJ uses is here: https://github.com/eclip
>> se/org.aspectj/blob/6d6738cfece6328027916681e67e54225531db38
>> /weaver/src/org/aspectj/weaver/bcel/asm/StackMapAdder.java
>>
>> cheers,
>> Andy
>>
>> On 10 October 2017 at 12:32, Andy Clement 
>> wrote:
>>
>>> Hey Eric,
>>>
>>> The error above is saying it can't find the asm rather than that there
>>> is an issue with missing stack maps. Although possibly the error is
>>> occurring because as a side effect of the missing stack maps, I'd need to
>>> check.
>>>
>>> > Are there libraries to manipulate/generate a stackmap?
>>>
>>> This is exactly what AspectJ is using Asm for. We weave/modify the
>>> bytecode and rather than incrementally try and patch up the stack maps, we
>>> just generate entirely fresh ones at the end of the process. A very basic
>>> Asm visitor to read/write the bytecode will produce them.  Which is why I'm
>>> surprised about the message - we aren't looking for existing ones to fix
>>> up, we are just looking for that version of asm to write out entirely new
>>> ones.
>>>
>>> cheers,
>>> Andy
>>>
>>>
>>> On 7 October 2017 at 05:49, Eric B  wrote:
>>>
>>>> While I don't disagree with your answer, I dont have the first clue how
>>>> to fix a legacy jdo library (circa 2004) that performs byte enhancement and
>>>> does not write the stackmap.Are there libraries to manipulate/generate
>>>> a stackmap?
>>>>
>>>> Is there anything else can I do in the meantime to unblock the
>>>> situation?
>>>>
>>>> Thanks
>>>> Eric
>>>>
>>>>
>>>> On Oct 7, 2017 12:11 AM, "Alexander Kriegisch" <
>>>> alexan...@kriegisch.name> wrote:
>>>>
>>>> I know that this is not the answer you are looking for, but my
>>>> suggestion is to heal the illness instead of taking pills against its
>>>> symptoms. Go fix your problem in the other module which requires noverify
>>>> in the first place. Generating broken bytecode does not sound like a wise
>>>> approach to me.
>>>>
>>>> --
>>>> Alexander Kriegisch
>>>>
>>>>
>>>> > Am 07.10.2017 um 02:55 schrieb Eric B :
>>>> >
>>>> > I'm running into a problem with AspectJ 1.8.10, and not sure how to
>>>> resolve this.
>>>> >
>>>> > I have a multi-module maven build.  One of my modules requires
>>>> running an ant task (using the antrun-maven-plugin) with the jvm -noverify
>>>> flag.  Consequently, I run the entire maven build using the -noverify flag.
>>>> >
>>>> > However, my last module in my build is an AspectJ module.  When I try
>>>> to compile it using the aspectj-maven-plugin, I get the following error
>>>> thrown:
>>>> >
>>>> > [ERROR] Failed to execute goal 
>>>> > org.codehaus.mojo:aspectj-maven-plugin:1.1

Re: [aspectj-users] Missing stackmap generation for woven code

[Andy Clement]

The very basic visitor AspectJ uses is here:
https://github.com/eclipse/org.aspectj/blob/6d6738cfece6328027916681e67e54225531db38/weaver/src/org/aspectj/weaver/bcel/asm/StackMapAdder.java

cheers,
Andy

On 10 October 2017 at 12:32, Andy Clement  wrote:

> Hey Eric,
>
> The error above is saying it can't find the asm rather than that there is
> an issue with missing stack maps. Although possibly the error is occurring
> because as a side effect of the missing stack maps, I'd need to check.
>
> > Are there libraries to manipulate/generate a stackmap?
>
> This is exactly what AspectJ is using Asm for. We weave/modify the
> bytecode and rather than incrementally try and patch up the stack maps, we
> just generate entirely fresh ones at the end of the process. A very basic
> Asm visitor to read/write the bytecode will produce them.  Which is why I'm
> surprised about the message - we aren't looking for existing ones to fix
> up, we are just looking for that version of asm to write out entirely new
> ones.
>
> cheers,
> Andy
>
>
> On 7 October 2017 at 05:49, Eric B  wrote:
>
>> While I don't disagree with your answer, I dont have the first clue how
>> to fix a legacy jdo library (circa 2004) that performs byte enhancement and
>> does not write the stackmap.Are there libraries to manipulate/generate
>> a stackmap?
>>
>> Is there anything else can I do in the meantime to unblock the situation?
>>
>> Thanks
>> Eric
>>
>>
>> On Oct 7, 2017 12:11 AM, "Alexander Kriegisch" 
>> wrote:
>>
>> I know that this is not the answer you are looking for, but my suggestion
>> is to heal the illness instead of taking pills against its symptoms. Go fix
>> your problem in the other module which requires noverify in the first
>> place. Generating broken bytecode does not sound like a wise approach to me.
>>
>> --
>> Alexander Kriegisch
>>
>>
>> > Am 07.10.2017 um 02:55 schrieb Eric B :
>> >
>> > I'm running into a problem with AspectJ 1.8.10, and not sure how to
>> resolve this.
>> >
>> > I have a multi-module maven build.  One of my modules requires running
>> an ant task (using the antrun-maven-plugin) with the jvm -noverify flag.
>> Consequently, I run the entire maven build using the -noverify flag.
>> >
>> > However, my last module in my build is an AspectJ module.  When I try
>> to compile it using the aspectj-maven-plugin, I get the following error
>> thrown:
>> >
>> > [ERROR] Failed to execute goal 
>> > org.codehaus.mojo:aspectj-maven-plugin:1.10:compile
>> (default) on project adams-aspects: AJC compiler errors:
>> > [ERROR] abort ABORT -- (BCException) Unable to find Asm for stackmap
>> generation (Looking for 'aj.org.objectweb.asm.ClassReader'). Stackmap
>> generation for woven code is required to avoid verify errors on a Java 1.7
>> or higher runtime
>> > [ERROR] when weaving type webapp.tiles.AthleteBasedForm
>> > [ERROR] when weaving classes
>> > [ERROR] when weaving
>> > [ERROR] when batch building BuildConfig[null] #Files=8 AopXmls=#0
>> > [ERROR]
>> >
>> >
>> > So I'm a bit in a bind.  I can't figure out any way to reconcile both
>> requirements - that module1 needs to run a plugin with the -noverify
>> parameter, and the aspectj plugin that needs to run it without.
>> >
>> > Is there anyway I can disable the need for the stackmap generation to
>> exist in AJ 1.8.10?  I've looked for parameters I can pass to ajc but can't
>> find any.
>> >
>> > Thanks,
>> >
>> > Eric
>> >
>> > ___
>> > 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
>>
>>
>>
>> ___
>> 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

Re: [aspectj-users] Missing stackmap generation for woven code

[Andy Clement]

Hey Eric,

The error above is saying it can't find the asm rather than that there is
an issue with missing stack maps. Although possibly the error is occurring
because as a side effect of the missing stack maps, I'd need to check.

> Are there libraries to manipulate/generate a stackmap?

This is exactly what AspectJ is using Asm for. We weave/modify the bytecode
and rather than incrementally try and patch up the stack maps, we just
generate entirely fresh ones at the end of the process. A very basic Asm
visitor to read/write the bytecode will produce them.  Which is why I'm
surprised about the message - we aren't looking for existing ones to fix
up, we are just looking for that version of asm to write out entirely new
ones.

cheers,
Andy


On 7 October 2017 at 05:49, Eric B  wrote:

> While I don't disagree with your answer, I dont have the first clue how to
> fix a legacy jdo library (circa 2004) that performs byte enhancement and
> does not write the stackmap.Are there libraries to manipulate/generate
> a stackmap?
>
> Is there anything else can I do in the meantime to unblock the situation?
>
> Thanks
> Eric
>
>
> On Oct 7, 2017 12:11 AM, "Alexander Kriegisch" 
> wrote:
>
> I know that this is not the answer you are looking for, but my suggestion
> is to heal the illness instead of taking pills against its symptoms. Go fix
> your problem in the other module which requires noverify in the first
> place. Generating broken bytecode does not sound like a wise approach to me.
>
> --
> Alexander Kriegisch
>
>
> > Am 07.10.2017 um 02:55 schrieb Eric B :
> >
> > I'm running into a problem with AspectJ 1.8.10, and not sure how to
> resolve this.
> >
> > I have a multi-module maven build.  One of my modules requires running
> an ant task (using the antrun-maven-plugin) with the jvm -noverify flag.
> Consequently, I run the entire maven build using the -noverify flag.
> >
> > However, my last module in my build is an AspectJ module.  When I try to
> compile it using the aspectj-maven-plugin, I get the following error thrown:
> >
> > [ERROR] Failed to execute goal 
> > org.codehaus.mojo:aspectj-maven-plugin:1.10:compile
> (default) on project adams-aspects: AJC compiler errors:
> > [ERROR] abort ABORT -- (BCException) Unable to find Asm for stackmap
> generation (Looking for 'aj.org.objectweb.asm.ClassReader'). Stackmap
> generation for woven code is required to avoid verify errors on a Java 1.7
> or higher runtime
> > [ERROR] when weaving type webapp.tiles.AthleteBasedForm
> > [ERROR] when weaving classes
> > [ERROR] when weaving
> > [ERROR] when batch building BuildConfig[null] #Files=8 AopXmls=#0
> > [ERROR]
> >
> >
> > So I'm a bit in a bind.  I can't figure out any way to reconcile both
> requirements - that module1 needs to run a plugin with the -noverify
> parameter, and the aspectj plugin that needs to run it without.
> >
> > Is there anyway I can disable the need for the stackmap generation to
> exist in AJ 1.8.10?  I've looked for parameters I can pass to ajc but can't
> find any.
> >
> > Thanks,
> >
> > Eric
> >
> > ___
> > 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
>
>
>
> ___
> 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

Re: [aspectj-users] How to get the enclosing class in a Pointcut

[Andy Clement]

If imported as a maven project the AJDT Configurator should kick in and 
configure the project correctly. Look in the project properties > builders, is 
it using AspectJ to build?

You can configure the AspectJ compiler properties to show eclipse info message 
for AspectJ weave info messages. That should tell you if it is actually 
weaving. Not sure why you need to run the ‘mvn clean compile’ in eclipse if the 
correct builder is building the project for you.  Maybe I’d like at where the 
output files are going, all to the right output folder?  If you are compile 
time weaving and not loadtime weaving running the tests should be just like for 
any other java project.

cheers,
Andy

> On Sep 25, 2017, at 9:58 PM, Mikael Petterson  
> wrote:
> 
> Hi Andy!
> 
> Yes now I got the message 😊
> 
> I have exactly the same code. I think it has something to do with the compile 
> and execution of my test case. I can see that ajc i done:
> 
> aspectj-maven-plugin:1.10:compile (compile_with_aspectj) @ resource-manager 
> ---
> [INFO] Showing AJC message detail for messages of types: [error, warning, 
> fail]
> [WARNING] invalid Class-Path header in manifest of jar file: 
> /repo/eraonel/.m2/repository/org/restlet/jse/org.restlet/2.3.3/org.restlet-2.3.3.jar
> invalid Class-Path header in manifest of jar file: 
> /repo/eraonel/.m2/repository/org/uncommons/maths/uncommons-maths/1.2.2a/uncommons-maths-1.2.2a.jar
> :
> 
> [INFO] Join point 'method-call(..)
> 
> However when I try to execute my test case I try to do it within Eclipse.
> I have a 'Run configuration'  for m2build making:
> 
> mvn clean compile 
> 
> Then I have another 'Run configuration', testng,  for my Demo test.
> 
> I execute it using a suite file that I have pointed out in Eclipse.
> 
> Is there anything that is different if I execute from within Eclipse?
> 
> br,
> 
> //mikael
> 
> 
>  
>  
> 
> 
> Från: Andy Clement  <mailto:andrew.clem...@gmail.com>>
> Skickat: den 22 september 2017 16:52
> Till: Mikael Petterson
> Kopia: aspectj-users@eclipse.org <mailto:aspectj-users@eclipse.org>
> Ämne: Re: [aspectj-users] How to get the enclosing class in a Pointcut
>  
> Hey, hope you get this email :)
> 
> Here is a complete program:
> 
>  8<  8<  Demo.java =
> public class Demo {
>   public static void main(String []argv) {
> new Demo().test();
>   }
> 
>   public void test() {
> Node node = new Node();
> Handler handler = node.getObjectHandler();
> //getBoards() is the deprecated method.
> Boards boards = handler.getBoards();
>   }
> }
> 
> aspect X {
>   pointcut deprecatedMethods() : call(public * *(..)) && 
> @annotation(Deprecated);
>   before() : deprecatedMethods() {
> System.out.println("Caller: 
> "+thisEnclosingJoinPointStaticPart.getSignature());
> System.out.println("Called: "+thisJoinPoint.getSignature());
>   }
> }
>  8<  8<  Demo.java =
> 
> ajc -1.8 Demo.java
> java Demo
> 
> Caller: void Demo.test()
> Called: Boards Handler.getBoards()
> 
> You could use a declare warning to achieve some of this but I don't think it 
> includes the enclosing join point as a key insert right now (see declare 
> warning in https://eclipse.org/aspectj/doc/released/README-169.html 
> <https://eclipse.org/aspectj/doc/released/README-169.html> ). Using declare 
> warning means you'd see the message at compile time and not runtime.
> AspectJ 1.6.9 Readme - Eclipse Oxygen 
> <https://eclipse.org/aspectj/doc/released/README-169.html>
> eclipse.org <http://eclipse.org/>
> It is now possible to ITD member types. The syntax is as would be expected. 
> This example introduces a new member type called Inner into type Foo: public 
> class Foo ...
> 
> cheers,
> Andy
> 
> On 22 September 2017 at 05:05, Mikael Petterson  <mailto:mikaelpetter...@hotmail.com>> wrote:
> Thx Any I really appreciated your help.
> 
> You where correct in your assumption:
> 
> "
> If you want to match calls *to* deprecated methods it would be more like:
> 
> call(public * *(..)) && @annotation(Deprecated)
> "
> 
> This is what I want to accomplish.
> 
> This is the structure of my maven project:
> 
> myapp
>   tests
>   nodes
> 
> In 'nodes' module I have a package called aspects where I have the aspect 
> DeprecatedMethodLogger.aj
> that I will 'weave' into the classes of nodes module.
> Under tests I have Demo class to trigger deprecated method call, getBoards(), 
> that is in nodes. This

Re: [aspectj-users] Plans for 1.9.0 release

[Andy Clement]

Thanks Mario, that one is on my list.

Related to JDK9 I just released a 1.8.11 to maven central. This will be a 
little more tolerant of Java9, for some use cases it will work on JDK9 (Spring 
AOP perhaps some basic weaving).

cheers,
Andy

> On Sep 26, 2017, at 2:42 AM, Mario Ivankovits  wrote:
> 
> Hi Andy!
> 
> The ant task has a minor bug.
> 
> The COMPLIANCE_INPUTS for 1.9 is missing the minus sign.
> Without that it is not possible to configure the compliance level and the 
> error
> [ant:iajc] [error   0]: error Compliance level '1.4' is incompatible with 
> target level '9'. A compliance level '9' or better is required
> shows up.
> 
> With this fix and the compliance configuration on the ant task I was able to 
> build our project and it seems to work as expected.
> 
> 
> Index: taskdefs/src/org/aspectj/tools/ant/taskdefs/AjcTask.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===
> --- taskdefs/src/org/aspectj/tools/ant/taskdefs/AjcTask.java(revision 
> d159d8d96ba83edca8ca7aefdd1ad785912f9164)
> +++ taskdefs/src/org/aspectj/tools/ant/taskdefs/AjcTask.java(revision )
> @@ -255,7 +255,7 @@
> 
> static final String[] TARGET_INPUTS = new String[] { "1.1", "1.2", 
> "1.3", "1.4", "1.5", "1.6", "1.7", "1.8", "1.9" };
> static final String[] SOURCE_INPUTS = new String[] { "1.3", "1.4", 
> "1.5", "1.6", "1.7", "1.8", "1.9" };
> -   static final String[] COMPLIANCE_INPUTS = new String[] { "-1.3", 
> "-1.4", "-1.5", "-1.6", "-1.7", "-1.8", "1.9" };
> +   static final String[] COMPLIANCE_INPUTS = new String[] { "-1.3", 
> "-1.4", "-1.5", "-1.6", "-1.7", "-1.8", "-1.9" };
> 
> private static final ICommandEditor COMMAND_EDITOR;
> 
> 
> 
> 
>> Am 25.09.2017 um 19:00 schrieb Andy Clement > <mailto:andrew.clem...@gmail.com>>:
>> 
>> Hey,
>> 
>> 1.9.0.BETA-7 is actually there now (spring milestones maven repo), published 
>> last night.This includes:
>> - update to latest JDT compiler
>> - Compilation/weaving performance on Java 9 now similar to Java8.
>> 
>> I am trying to get to an RC very soon but there are a few more things I must 
>> do before I consider it good enough, my rough target is end of the week but 
>> it depends on how many distractions I get :)
>> 
>> > right now 1.8.10 version doesn't work in such projects.
>> 
>> It would be helpful for anyone/everyone to share any issues you have with 
>> the 1.9 betas so I can make sure I have them on the TODO list, email here or 
>> bugzilla issues are fine.
>> 
>> many thanks,
>> Andy
>> 
>> 
>> On 23 September 2017 at 01:25, Krzysztof Krason > <mailto:krzysztof.kra...@gmail.com>> wrote:
>> Hello,
>> Is there a plan for releasing 1.9.0 version soon? I see that there is a 
>> 1.9.0.BETA-6 in Spring Milestones maven repo and I'm wondering if you have 
>> some plans on releasing it to maven central or creating 1.9.0 and releasing 
>> it there?
>> 
>> This would greatly help with projects that want to use Java 9 and AspectJ, 
>> right now 1.8.10 version doesn't work in such projects.
>> 
>> Regards,
>> Krzysztof Krason
>> 
>> 
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org <mailto: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 
>> <https://dev.eclipse.org/mailman/listinfo/aspectj-users>
>> 
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org <mailto: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

___
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

Re: [aspectj-users] Plans for 1.9.0 release

[Andy Clement]

Hey,

1.9.0.BETA-7 is actually there now (spring milestones maven repo),
published last night.This includes:
- update to latest JDT compiler
- Compilation/weaving performance on Java 9 now similar to Java8.

I am trying to get to an RC very soon but there are a few more things I
must do before I consider it good enough, my rough target is end of the
week but it depends on how many distractions I get :)

> right now 1.8.10 version doesn't work in such projects.

It would be helpful for anyone/everyone to share any issues you have with
the 1.9 betas so I can make sure I have them on the TODO list, email here
or bugzilla issues are fine.

many thanks,
Andy


On 23 September 2017 at 01:25, Krzysztof Krason 
wrote:

> Hello,
> Is there a plan for releasing 1.9.0 version soon? I see that there is a
> 1.9.0.BETA-6 in Spring Milestones maven repo and I'm wondering if you have
> some plans on releasing it to maven central or creating 1.9.0 and releasing
> it there?
>
> This would greatly help with projects that want to use Java 9 and AspectJ,
> right now 1.8.10 version doesn't work in such projects.
>
> Regards,
> Krzysztof Krason
>
>
> ___
> 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

Re: [aspectj-users] How to get the enclosing class in a Pointcut

[Andy Clement]

Hey, hope you get this email :)

Here is a complete program:

 8<  8<  Demo.java =
public class Demo {
  public static void main(String []argv) {
new Demo().test();
  }

  public void test() {
Node node = new Node();
Handler handler = node.getObjectHandler();
//getBoards() is the deprecated method.
Boards boards = handler.getBoards();
  }
}

aspect X {
  pointcut deprecatedMethods() : call(public * *(..)) &&
@annotation(Deprecated);
  before() : deprecatedMethods() {
System.out.println("Caller:
"+thisEnclosingJoinPointStaticPart.getSignature());
System.out.println("Called: "+thisJoinPoint.getSignature());
  }
}
 8<  8<  Demo.java =

ajc -1.8 Demo.java
java Demo

Caller: void Demo.test()
Called: Boards Handler.getBoards()

You could use a declare warning to achieve some of this but I don't think
it includes the enclosing join point as a key insert right now (see declare
warning in https://eclipse.org/aspectj/doc/released/README-169.html ).
Using declare warning means you'd see the message at compile time and not
runtime.

cheers,
Andy

On 22 September 2017 at 05:05, Mikael Petterson  wrote:

> Thx Any I really appreciated your help.
>
>
> You where correct in your assumption:
>
>
> "
> If you want to match calls *to* deprecated methods it would be more like:
>
> call(public * *(..)) && @annotation(Deprecated)
> "
>
>
> This is what I want to accomplish.
>
>
> This is the structure of my maven project:
>
>
> myapp
>
>   tests
>
>   nodes
>
>
> In 'nodes' module I have a package called aspects where I have the aspect
> DeprecatedMethodLogger.aj
>
> that I will 'weave' into the classes of nodes module.
>
> Under tests I have Demo class to trigger deprecated method call,
> getBoards(), that is in nodes. This is for testing purposes.
>
> Later on there will be calls not in myapp, but outside, that will make
> calls to deprecated methods in nodes module.
>
>
> *Demo.java*
>
>
> public class Demo extends Test{
>
> @Test
> public void test() {
>   Node node = new Node();
>   Handler handler = node.getObjectHandler();
>   //getBoards() is the deprecated method.
>   Boards boards = handler.getBoards();
>
>
> }
> }
>
>
>
> *DeprecatedMethodLogger.aj*
>
>
> pointcut deprecatedMethods() : call(public * *(..)) &&
> @annotation(Deprecated);
>
>
> before() : deprecatedMethods() {
>log("[Deprecated Method Usage]" +thisEnclosingJoinPointStaticPa
> rt.getSignature().getDeclaringTypeName()+" --> "+"\n");
> }
>
>
> This will print the 'Handler' class that calls the method getBoards()
> which is deprecated. I want:
>
>
> Caller:  Demo.test()
>
> Called: Handler.getBoards()
>
>
> What am I lacking?
>
>
> br,
>
>
> //mikael
>
>
>
>
>
>
>
> --
> *Från:* aspectj-users-boun...@eclipse.org  eclipse.org> för Mikael Petterson 
> *Skickat:* den 21 september 2017 11:35
> *Till:* Frank Pavageau; aspectj-users@eclipse.org
>
> *Ämne:* Re: [aspectj-users] How to get the enclosing class in a Pointcut
>
>
> Thx!
>
>
> I got your reply but why did I not get his? Do I need to make any changes
> to get them?
>
>
> br,
>
>
> //mike
>
>
>
>
>
>
>
> --
> *Från:* Frank Pavageau 
> *Skickat:* den 21 september 2017 07:54
> *Till:* aspectj-users@eclipse.org; Mikael Petterson
> *Ämne:* Re: [aspectj-users] How to get the enclosing class in a Pointcut
>
> 2017-09-21 9:46 GMT+02:00 Mikael Petterson :
>
>> So no input on this one?
>>
> Yes, Andy answered on the list itself : https://dev.eclipse.org/
> mhonarc/lists/aspectj-users/msg15087.html
>
> Regards,
> Frank
>
>
___
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

Re: [aspectj-users] How to get the enclosing class in a Pointcut

[Andy Clement]

Just want to 100% understand your requirement:

> I want to find which classes and methods  outside our application that calls 
> to our application classes with public methods that has annotation 
> @Deprecated.

You want to find calls to your API *from* code marked @Deprecated or you want 
to find calls made *to* @Deprecated code?

If you mean the latter then your pointcut isn’t quite right.


> pointcut deprecatedMethods() : call(public * *.*(..)) && 
> @withincode(Deprecated);

This says “match calls made to public methods *from* code marked @Deprecated”.

If you want to match calls *to* deprecated methods it would be more like:

“call(public * *(..)) && @annotation(Deprecated)”

In this second case the enclosingjoinpoint would be the Demo.test and the 
target of the call would be the deprecated method getBoards().

Is that any help?

cheers,
Andy


> On Sep 18, 2017, at 6:27 AM, Mikael Petterson  
> wrote:
> 
> Hi,
> 
> I have started to look into aspectj , now that I have a working dev 
> environment in Eclipse 😊
> 
> I want to find which classes and methods  outside our application that calls 
> to our application classes with public methods that has annotation 
> @Deprecated.
> 
> I have created the following 'pointcut':
> 
> pointcut deprecatedMethods() : call(public * *.*(..)) && 
> @withincode(Deprecated);
> before() : deprecatedMethods() {
>   log("[Deprecated Method Usage]" +" --> "+ 
> thisEnclosingJoinPointStaticPart.getSignature().toShortString+"\n");
> 
> }
> 
> The above will give something like:
> 
> [Deprecated Method Usage] --> HandlerImpl.getBoards(..)
> 
>  I can see which classes' methods with @Deprecated gets called. But I cannot 
> see  what the name of the enclosing class and method is, in this case 
> Demo.test() ( see below).
> 
> Is it possible to get this using aspectj?
> What would be the correct pointcut to use?
> 
> br.
> 
> //mike
> 
> 
> public class Demo extends Test{
> 
> @Test
> public void test() {
>   Node node = new Node();
>   Handler handler = node.getObjectHandler();
>   //getBoards() is the deprecated method.
>   Boards boards = handler.getBoards();
>   
>  
> }
> }
> 
> 
>  
>  
> ___
> 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

Re: [aspectj-users] AspectJ Future

[Andy Clement]

Hey,

I have to admit I'm not trying it on a daily basis but I thought AJDT was
OK - is the message you posted "Space to find context alternatives for
annotations." an indication of the error you are seeing? Doesn't
sound familiar to me.

As soon as I clear some space on my TODO list I am tackling a proper
AspectJ9 release (non beta) and that will be coupled with a round of
testing of AJDT using that new AspectJ. I'll be properly testing code style
and annotation style at that time.

cheers,
Andy


On 12 September 2017 at 09:23, Mikael Petterson  wrote:

> Hi,
>
>
> I have done some reading about AOP and it's implementation in java,
> aspectj.
>
> I decided to give it a try for our application so I downloaded it for
> Eclipse Neon 4.6.3 that I am using as IDE.
>
>
> I added an aspect but had to go back to using the "original syntax" and
> not annotation based since the ajdt did not support it.
>
>
> I checked the version I downloaded what was available for 4.6 however I
> can see that the following is not working.
>
>
> - Space to find context alternatives for annotations.
>
>
> Is there some setting I have to fix?
>
>
> br,
>
>
> //mike
>
>
>
>
>
>
> ___
> 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

Re: [aspectj-users] Errors while switching from load time weaving to compile time weaving using aspectj

[Andy Clement]

I’ll prefix this with I’m no maven expert :)  

You don’t seem to be specifying the version of the AspectJ compiler to use so I 
wonder if it is defaulting to a lower version. On here:

http://www.mojohaus.org/aspectj-maven-plugin/usage.html 


see where aspectjtools dependency version is set in the plugin config.  
(aspectjtools is compiler+weaver+runtime  - aspectjweaver is weaver+runtime - 
aspectjrt is just the runtime)

cheers,
Andy


> On Jul 17, 2017, at 7:25 AM, Bhuvan Rawal  wrote:
> 
> Hi,
> 
> Im trying to switch to aspectj compiler for our project which takes a lot of 
> time to weave during load time, so i thought of evaluating compile time 
> weaving using aspectj. Below are the steps I took:
> 
> 1. Added aspectjweaver to pom- latest stable version
> 
> org.aspectj
> aspectjweaver
> 1.8.10
> 
> 
> org.aspectj
> aspectjrt
> 1.8.10
> 
> 2. Added aspectj maven plugin to build
> 
> 
> 
> org.codehaus.mojo
> aspectj-maven-plugin
> 1.10
> 
> true
> 1.8
> 1.8
> ignore
> 1.8
> UTF-8
> true
> 
> 
> org.springframework
> spring-aspects
> 
> 
> 
> 
> 
> 
> compile
> test-compile
> 
> 
> 
> 
> 
> 
> 3. Enabled Aspectj mode in JpaRepository
> @EnableTransactionManagement(mode= AdviceMode.ASPECTJ)
> Now when im compiling my project Im getting some aspectj errors :
> 
> -> The parameter (parameter name) is not bound in [all branches of] pointcut
> -> use of ProceedingJoinPoint is allowed only on around advice 
> For the 2nd error , Ive verified, the advice is around not sure why this 
> error occurs then.
> 
> It works perfectly fine when I was using default Spring AOP load time 
> weaving. I tried finding my way out but could not hence posting here. (Saw 
> this blog 
>  
> which lists similar thing but it says it was fixed in version 1.7.2)
> 
> I tried doing the same using ajc plugin for my ide (previous observations 
> were using maven command line build). Similar errors occurred.
> 
> Any help would be appreciated!
> 
> Thanks,
> Bhuvan
> 
> ___
> 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

Re: [aspectj-users] Do cflow targets need to be woven?

[Andy Clement]

Yes, the cflow target is woven to indicate 'this cflow is being entered'
then at the real target place to weave it is a very simple/quick check to
see 'are we in the cflow?'. There would be a less optimal implementation
that looks at the stack trace at the actual join point target but we've
never investigated implementing that. I suppose as a sub-optimal workaround
you could inspect that stack yourself in your advice if you really can't
weave the actual cflow target.

cheers,
Andy

On 24 April 2017 at 21:21, Eric B  wrote:

> I'm trying to use cflow to limit the scope of my pointcut, but it when I
> add the cflow argument, the pointcut is not intercepting the call at all.
> In my build process, the cflow target is not part of the weaving at all.
> Does the cflow target need to be part of the build/weave process?  Or is my
> pointcut wrong?
>
> @Aspect
> class MultiChoiceNullAspect{
> @Pointcut("cflowbelow(execution( void 
> javax.faces.webapp.FacesServlet.service(..)
> ) && !within(MultiChoiceNullAspect))")
> public void facesServletCFlow(){}
> @Pointcut("facesServletCFlow() && execution( public
> org.model.questionnaire.MultiChoiceItem* get*(..))")
> public void multiChoiceObjects() {}
> @Around("multiChoiceObjects()")
> public Object emptyMultiChoice( final ProceedingJoinPoint pjp) throws
> Throwable{
> Object o = pjp.proceed();
> // if the return object is null, create an empty MultiChoice object
> instead
> if( o == null ){
> return new MultiChoiceItem();
> }
>
> return o;
> }
> }
>
>
>
> And my build instructions:
> 
> org.codehaus.mojo
> aspectj-maven-plugin
> 1.10
> 
> true
> ${java.version}
> ${java.version}
> ${java.version}
> UTF-8
> 
> 
> 
> 
> compile
> test-compile
> 
> 
> 
> 
> 
> org.aspectj
> aspectjtools
> ${aspectj.version}
> 
> 
> 
>
>
>
> Essentially, I'm trying to advise the execution of all getters that return
> MultiChoiceItem* when they are as part of the 
> javax.faces.webapp.FacesServlet.service()
> method/flow.
>
> Does the FacesServlet class need to be passed to the ajc compiler as
> well?  Or are the cflow() arguments just evaluated at runtime and don't
> need to be present in the compiler?  If the later, what am I doing wrong -
> why is my pointcut not triggering?
>
> Thanks,
>
> Eric
>
>
> ___
> 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

Re: [aspectj-users] How to weave JDK classes with AspectJ

[Andy Clement]

I don't think it is so hard to implement, no. It has come up a few times in
the past.

cheers,
Andy

On 22 March 2017 at 09:28, Alexander Kriegisch 
wrote:

> And any thoughts about the suggested compiler option? I remember it was
> discussed here or on Bugzilla before. It does not seem hard to implement,
> but I could be wrong.
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Andy Clement schrieb am 22.03.2017 17:07:
>
> > I see it :) Thanks for pulling this resource together that I can point
> > people at.
> >
> >
> > On Mar 22, 2017, at 8:17 AM, Alexander Kriegisch
> >  wrote:
> >
> >> Hi Andy.
> >>
> >> Especially for you I added this remark:
> >> https://github.com/kriegaex/SO_AJ_MavenWeaveJDK#possible-improvements
> >>
> >> ;-)
> >>
> >>
> >> Alexander Kriegisch schrieb am 22.03.2017 16:04:
> >>
> >>> Hi community.
> >>>
> >>> I have been asked so many times how to do this. Usually I just
> >>> answer that
> >>>   ** I have done it a few times in the past,
> >>>   ** it is an advanced topic and not suited for beginners,
> >>>   ** JDK weaving is rarely necessary (or makes any sense at all) and
> >>>  can usually be avoided by changing your application or aspect
> >>>  design,
> >>>   ** you should try to avoid it whenever possible.
> >>>
> >>> On the other hand, it is a nifty little exercise if you just want to
> >>> know how far you can go and how powerful AspectJ really is. Under
> >>> some circumstances it might even be justified to actually do it.
> >>>
> >>> So for what it is worth, instead of explaining myself over and over
> >>> again when being asked on StackOverflow or elsewhere, I have just
> >>> created a little demo Maven project on GitHub for you if you should
> >>> really decide to tread that troubled track (quoting Amy Winehouse,
> >>> the well-known software developer):
> >>>
> >>> https://github.com/kriegaex/SO_AJ_MavenWeaveJDK
> >>>
> >>> Use at your own risk! ;-)
>
> ___
> 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

Re: [aspectj-users] How to weave JDK classes with AspectJ

[Andy Clement]

I see it :) Thanks for pulling this resource together that I can point people 
at.

cheers
Andy


> On Mar 22, 2017, at 8:17 AM, Alexander Kriegisch  
> wrote:
> 
> Hi Andy.
> 
> Especially for you I added this remark:
> https://github.com/kriegaex/SO_AJ_MavenWeaveJDK#possible-improvements
> 
> ;-)
> -- 
> Alexander Kriegisch
> https://scrum-master.de
> 
> 
> Alexander Kriegisch schrieb am 22.03.2017 16:04:
> 
>> Hi community.
>> 
>> I have been asked so many times how to do this. Usually I just answer
>> that
>> ** I have done it a few times in the past,
>> ** it is an advanced topic and not suited for beginners,
>> ** JDK weaving is rarely necessary (or makes any sense at all) and can
>>usually be avoided by changing your application or aspect design,
>> ** you should try to avoid it whenever possible.
>> 
>> On the other hand, it is a nifty little exercise if you just want to
>> know how far you can go and how powerful AspectJ really is. Under some
>> circumstances it might even be justified to actually do it.
>> 
>> So for what it is worth, instead of explaining myself over and over
>> again when being asked on StackOverflow or elsewhere, I have just
>> created a little demo Maven project on GitHub for you if you should
>> really decide to tread that troubled track (quoting Amy Winehouse, the
>> well-known software developer):
>> 
>> https://github.com/kriegaex/SO_AJ_MavenWeaveJDK
>> 
>> Use at your own risk! ;-)
>> 
>> Best regards
> 
> ___
> 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