[aspectj-users] AspectJ 1.9.22.1 maintenance release (Java 22)
Dear AspectJ users, we are pleased to announce AspectJ maintenance release 1.9.22.1. It still supports Java 22, just like 1.9.22. See the release notes (link below) for more details concerning bugfixes and enhancements. AJDT for Eclipse 4.31 (2024-03) were also refreshed to contain the new release. Resources For more detailed release information, please read the release notes. The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.31 (2024-03). Unfortunately, updates sites for previous Eclipse versions are no longer compatible with AspectJ 1.9.22.1, because the latter depends on upstream Eclipse changes. So if you want to use ADJT builds with Eclipse IDE, you need to upgrade to 2024-03. Otherwise, you can only use AspectJ 1.9.22.1 via Maven build, not via direct IDE. Documentation for AspectJ can be found here on the Eclipse project website. There also is a short guide describing options for setting up a development environment. See here for more information about how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.14. Enjoy AspectJ! 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] AspectJ versioning question
Here is the CVE I was talking about, just found it again. It was in 1.9.19: https://github.com/eclipse-aspectj/aspectj/issues/192 -- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch via aspectj-users schrieb am 01.05.2024 um 10:46: > Yes, 1.8.14 was unusual. That was before UI was an AspectJ > committer, though. > > Concerning the hypothetical CVE report, let us walk through that door > if and when we stand in front of it. It always depends on the > circumstances, but actually I see no reason why Java 8 users should > not use e.g. 1.9.22. Installing an extra JDK on the build machine > and pointing to that during compile-time weaving is not rocket > science and in no way impedes you in using the compile results on > Java 8. Besides, many bugs and even one CVE I personally remember > were fixed in more recent versions, i.e. it might be beneficial even > for legacy projects to recompile and use more recent AspectJ > dependencies. > > It should be super easy to upgrade. Have you tried? > > > Mclachlan, Alan via aspectj-users schrieb am 30.04.2024 um 15:02: > >> 1.8.14 must have been unusual then, because I did see it released >> after the 1.9.xx branch was in progress. >> >> For a team on 1.8.x facing a hypothetical CVE report, how hard is >> the upgrade to 1.9.22 likely to be? Sounds like a Java build time >> version upgrade may be needed. >> >> >> From: Alexander Kriegisch >> >>> Thanks for your inquiry. >>> >>> AspectJ generally does not release updates for older versions. >>> Usually, more recent versions are backward compatible. E.g., you >>> can use the current 1.9.22 to compile with 1.8 source/target or >>> use LTW on Java 8. Only in your build environment when using AJC >>> directly or aspectjtools.jar via Maven oder Gradle plugin, you >>> would need Java 17, because the upstream Eclipse compiler >>> requires it. >>> >>> >>> Mclachlan, Alan via aspectj-users schrieb am 30.04.2024 um >>> 13:13: >>> >>>> I read up on the supported Java versions situation on the >>>> github issue tracker. I have some related questions around the >>>> v1.8.x line: >>>> >>>> 1. Is the project still releasing fixes on the 1.8.x line, at >>>> least while Java 8 is still in support? I ask because I think >>>> the last one was 1.8.14 in 2019. Say a CVE shows up, would you >>>> be likely to release a 1.8.15 with a fix? >>>> >>>> 2. Are the 1.8.x minor releases compatible, in the >>>> semantic-versioning sense of the word? i.e would a hypothetical >>>> 1.8.15 be a drop-in replacement? I ask because this project >>>> doesn't explicitly follow semantic versioning, although I >>>> suspect it may have back in the 1.8 days? >>>> >>>> Apologies if these are answered elsewhere, if so I didn't >>>> manage to find them on the website. >>>> >>>> The context of my ask is OWASP A06 analysis of our SBOM, not to >>>> motivate for any project action. ___ 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 versioning question
Yes, 1.8.14 was unusual. That was before UI was an AspectJ committer, though. Concerning the hypothetical CVE report, let us walk through that door if and when we stand in front of it. It always depends on the circumstances, but actually I see no reason why Java 8 users should not use e.g. 1.9.22. Installing an extra JDK on the build machine and pointing to that during compile-time weaving is not rocket science and in no way impedes you in using the compile results on Java 8. Besides, many bugs and even one CVE I personally remember were fixed in more recent versions, i.e. it might be beneficial even for legacy projects to recompile and use more recent AspectJ dependencies. It should be super easy to upgrade. Have you tried? -- Alexander Kriegisch https://scrum-master.de Mclachlan, Alan via aspectj-users schrieb am 30.04.2024 um 15:02: > Thanks for the quick response Alexander. > > 1.8.14 must have been unusual then, because I did see it released after the > 1.9.xx branch was in progress. > > For a team on 1.8.x facing a hypothetical CVE report, how hard is the upgrade > to 1.9.22 likely to be? > Sounds like a Java build time version upgrade may be needed. > > regards > > Alan McLachlan > Chief Architect - Merchant > T +27 21 525 5008 / M +27 81 334 5946 > ACI Worldwide, Building A, The Estuaries, Century City, Milnerton, Cape Town, > 7435, South Africa. > http://www.aciworldwide.com/ > > -Original Message- > From: aspectj-users On Behalf Of > Alexander Kriegisch via aspectj-users > Sent: Tuesday, April 30, 2024 1:30 PM > To: aspectj-users@eclipse.org > Cc: Alexander Kriegisch > Subject: Re: [aspectj-users] AspectJ versioning question > > [You don't often get email from aspectj-users@eclipse.org. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe. > > > Hi Alan. > > Thanks for your inquiry. > > AspectJ generally does not release updates for older versions. Usually, more > recent versions are backward compatible. E.g., you can use the current 1.9.22 > to compile with 1.8 source/target or use LTW on Java 8. > Only in your build environment when using AJC directly or aspectjtools.jar > via Maven oder Gradle plugin, you would need Java 17, because the upstream > Eclipse compiler requires it. > > Regards > -- > Alexander Kriegisch > https://scrum-master.de/ > > > Mclachlan, Alan via aspectj-users schrieb am 30.04.2024 um 13:13: > >> I read up on the supported Java versions situation on the github issue >> tracker. >> I have some related questions around the v1.8.x line: >> >> 1. Is the project still releasing fixes on the 1.8.x line, at least while >> Java 8 is still in support? >> I ask because I think the last one was 1.8.14 in 2019. Say a CVE shows up, >> would you be likely to release a 1.8.15 with a fix? >> >> 2. Are the 1.8.x minor releases compatible, in the semantic-versioning sense >> of the word? >> i.e would a hypothetical 1.8.15 be a drop-in replacement? >> I ask because this project doesn't explicitly follow semantic versioning, >> although I suspect it may have back in the 1.8 days? >> >> Apologies if these are answered elsewhere, if so I didn't manage to find >> them on the website. >> >> The context of my ask is OWASP A06 analysis of our SBOM, not to motivate for >> any project action. >> >> regards >> >> Alan McLachlan >> ACI Worldwide >> http://www.aciworldwide.com/ > ___ > aspectj-users mailing list > aspectj-users@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/aspectj-users > > [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] > <http://www.aciworldwide.com/> > This email message and any attachments may contain confidential, proprietary > or non-public information. The information is intended solely for the > designated recipient(s). If an addressing or transmission error has > misdirected this email, please notify the sender immediately and destroy this > email. Any review, dissemination, use or reliance upon this information by > unintended recipients is prohibited. Any opinions expressed in this email are > those of the author personally. > ___ > 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 versioning question
Hi Alan. Thanks for your inquiry. AspectJ generally does not release updates for older versions. Usually, more recent versions are backward compatible. E.g., you can use the current 1.9.22 to compile with 1.8 source/target or use LTW on Java 8. Only in your build environment when using AJC directly or aspectjtools.jar via Maven oder Gradle plugin, you would need Java 17, because the upstream Eclipse compiler requires it. Regards -- Alexander Kriegisch https://scrum-master.de Mclachlan, Alan via aspectj-users schrieb am 30.04.2024 um 13:13: > I read up on the supported Java versions situation on the github issue > tracker. > I have some related questions around the v1.8.x line: > > 1. Is the project still releasing fixes on the 1.8.x line, at least while > Java 8 is still in support? > I ask because I think the last one was 1.8.14 in 2019. Say a CVE shows up, > would you be likely to release a 1.8.15 with a fix? > > 2. Are the 1.8.x minor releases compatible, in the semantic-versioning sense > of the word? > i.e would a hypothetical 1.8.15 be a drop-in replacement? > I ask because this project doesn't explicitly follow semantic versioning, > although I suspect it may have back in the 1.8 days? > > Apologies if these are answered elsewhere, if so I didn't manage to find them > on the website. > > The context of my ask is OWASP A06 analysis of our SBOM, not to motivate for > any project action. > > regards > > Alan McLachlan > ACI Worldwide > www.aciworldwide.com ___ aspectj-users mailing list aspectj-users@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/aspectj-users
[aspectj-users] AJDT and E2M Connector updates for Eclipse 2024-03
Dear AspectJ users,there are updates for both AspectJ Development Tools (AJDT) and Eclipse-to-Maven (E2M) Connector for AJDT. Both of them now support Eclipse IDE 2024-03 (4.31). For AJDT, there was a version before, but it had a problem with Equinox OSGi weaving in Eclipse. So, if that is your use case, I think I have solved that problem, which is why I recommend you to update AJDT. The E2M Connector is newly available for 2024-03 since today. The update sites on repo.t5.fi (maintained by Miika Vesti) have been down for a while now, and I could not reach him. So, I quickly forked and re-published a slightly updated 2022-12 version and a new 2024-03 version on new aspectj.dev update sites as a workaround. Actually, I do not need yet another project I know next to nothing about to maintain on top of AJDT, AspectJ proper and AspectJ Maven Plugin, but without the connector, Eclipse users cannot import AspectJ compiler settings from AspectJ Maven, which would be suboptimal. Disclaimers: Just like AJDT, but even more so, the E2M Connector is maintained on a best-effort basis and neither thoroughly understood nor properly tested. I am not even an active Eclipse user. My main IDE is IntelliJ IDEA. I barely have any free cycles for AJDT and E2M, so please do not expect me to maintain versions for older versions of Eclipse. My goal is to just keep them running on the latest release, which at the moment is 2024-03. As soon as I update them for more recent Eclipse releases, the previous ones are usually promptly abandoned. You can find the update sites for both tools here. Hope this helps-- Alexander Kriegischhttps://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
Re: [aspectj-users] add instance members to a class
Yes, Lombok is also an easy means to implement that requirement. If you
do not need Aspects for anything else, take a look at Lombok. Of course,
just like for AspectJ you need both build-time and IDE tooling in order
to work comfortably with Lombok. Steve is thinking about using marker
annotations anyway. Of course, in AspectJ you could add the members
without adding any marker annotations, as long as you can express the
set of target classes in a pointcut, which is often possible. Another
thing to consider is that Lombok does not play nice with AspectJ out of
the box, i.e you also use AspectJ for other things, you need to tweak
your build process to mix both tools. Using AspectJ only for member
(field/method) introduction as well as all other types of cross-cutting
concerns would be one-stop shopping. Depending on the situation, you can
make an informed choice to use either A or B or both at the same time.
@Tim: By instance method he means non-static methods. It is a commonly used
term.
--
Alexander Kriegisch
https://scrum-master.de
n614cd--- via aspectj-users schrieb am 29.03.2024 16:12 (GMT +01:00):
> I would instead use project Lombok annotations for the getter/setter. Lombok
> annotations are respected in most IDEs for compile support, and also for
> many build tools.
>
> What do you mean by "instance" method?
>
> Tim
>
> -Original Message-
> From: aspectj-users On Behalf Of Steve
> White via aspectj-users
> Sent: Friday, March 29, 2024 10:47 AM
> To: aspectj-users@eclipse.org
> Cc: Steve White
> Subject: [aspectj-users] add instance members to a class
>
> Hi,
>
> I'm just learning about AspectJ. I haven't been able to determine if I can
> apply it to my problem.
>
> The problem is to add an instance member, together with getters/setters, to
> certain existing classes. This seems to be an example of a crosscutting
> concern.
>
> So far, I have managed with AspectJ only to produce classes with new static
> members.
>
> Is it possible with AspectJ to create an annotation, say @Labelled, so that
>
> @Labelled
> public class LabelledClass extends PlainClass{
> }
>
> so that instances of LabelledClass will have their own private String member
> "itsLabel", with a getter "getLabel()", and a setter "setLabel()". That is,
> so that LabelledClass effectively implements
>
> interface LabelledInterface{
> String getLabel();
> void setLabel( String label );
> }
>
> How would one go about this? Is something like this possible?
>
> If this kind of thing isn't possible, where can I find passages in the
> documentation that would clarify the situation?
>
> Thanks!
> ___
> 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] add instance members to a class
Hi Steve.
I think we know each other from GitHub issue #299. Welcome to the
mailing list channel, too.
First, a few links for you:
How to declare an interface and its implementation including fields and
accessor methods by means of inter-type declarations (ITD) in native
AspectJ syntax:
https://eclipse.dev/aspectj/doc/latest/progguide/progguide.html#language-interType
The chapter right below that one also showcases some basic AspectJ
examples, among them ITD ones. Just search for "declare parents", if
scrolling is too tedious.
The corresponding chapter explaining ITDs in annotation-style is here:
https://eclipse.dev/aspectj/doc/latest/adk15notebook/adk15notebook.html#ataspectj-itds
There, you find an example explaining how to achieve a similar result as
in native syntax in the less powerful (but still powerful enough)
annotation syntax by means of "@DeclareParents" and "@DeclareMixin",
respectively.
I hope this helps. If you need more support, please share an MCVE
(https://stackoverflow.com/help/mcve), ideally a GitHub project or in
old-school fashion by attaching a zip or tar.* archive to your next
message, and I will do my best to help you sort out the details.
Cheers
--
Alexander Kriegisch
https://scrum-master.de
Steve White via aspectj-users schrieb am 29.03.2024 15:47 (GMT +01:00):
> Hi,
>
> I'm just learning about AspectJ. I haven't been able to determine if
> I can apply it to my problem.
>
> The problem is to add an instance member, together with
> getters/setters, to certain existing classes. This seems to be an
> example of a crosscutting concern.
>
> So far, I have managed with AspectJ only to produce classes with new
> static members.
>
> Is it possible with AspectJ to create an annotation, say @Labelled, so that
>
> @Labelled
> public class LabelledClass extends PlainClass{
> }
>
> so that instances of LabelledClass will have their own private String
> member "itsLabel", with a getter "getLabel()", and a setter
> "setLabel()". That is, so that LabelledClass effectively implements
>
> interface LabelledInterface{
> String getLabel();
> void setLabel( String label );
> }
>
> How would one go about this? Is something like this possible?
>
> If this kind of thing isn't possible, where can I find passages in the
> documentation that would clarify the situation?
>
> Thanks!
> ___
> 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] Agent Embedder Maven Plugin and AspectJ load-time weaving
Hi AspectJ community!Over the years, it has been a FAQ, both on Stack Overflow and by people contacting me directly: I have an executable JAR (e.g. Spring Boot fat JAR), which I am starting with java -javaagent:/path/to/aspectjweaver.jar -jar my_app.jar Is there any way to add the AspectJ weaver and automatically start it when executing the JAR, so I do not have to use the -javaagent parameter on the command line? The good news first: Yes, since JRE 9 Java instrumentation provides the Launcher-Agent-Class mechanism, which you can leverage to embed any Java agent into an executable JAR and automatically launch the agent before the application in the JAR is started. The bad news are: The JRE feature is not so easy to use, because the java agent JAR cannot just be embedded into the containing executable JAR as a nested JAR but needs to be unpacked before embedding it, the executable JAR's manifest needs to be adjusted to make it aware of the embedded agent, the JRE only supports launching a single embedded Java agent in contrast to the JVM command line supporting multiple ones, the started agent cannot receive any option string in contrast to JVM command line agents via -javaagent:path/to/agent.jar=option1=one,option2=two, build plugins like the Spring Boot Maven Plugin do not support embedding agents. Agent Embedder Maven Plugin to the rescue! The plugin embeds one or multiple(!) java agents, takes care of unpacking them and modifying the manifest. You can even specify an option string per agent, i.e. the functionality is on par with the JVM command line. The multi-agent feature is achieved by a tiny launcher agent embedded into the executable JAR along with the actualy user agents. The launcher launches all your agents and passes to them the options you specified in your build plugin configuration. How does that help AspectJ LTW and Spring (Boot) users? Well, aspectjweaver.jar is one such aava agent you can embed into your executable (Spring Boot) JAR to be launched automatically. If you make sure to use a version 1.9.21.1 or newer - I recommend the latest 1.9.22 released earlier today - you do not even need to specify the infamous --add-opens parameter when running your application on JDK 16+ anymore. Simply launch your application with e.g. java -jar my-spring-boot.jar and enjoy native AspectJ weaving. You do not even need to configure anything else in Spring to activate it, because Spring detects the active weaving agent automatically. Before you ask: No, it does not work on JRE 8 or older, because the JVM only supports Launcher-Agent-Class since JRE 9. But you can run the Maven build on JRE 8 and also compile to target 8, if you like, as long as you run your executable JAR on JRE 9+. Yes, in theory a similar build plugin could also be implemented for Gradle or other build tools. But being a Maven person, I only did it for Maven. I hope that other developers will step up to fill in the gaps. No, I did not test the plugin with signed JARs. If you experience any problems or have usage questions, please use GitHub discussions. If you think you found a bug or have a feature request, GitHub issues. Enjoy -- Alexander Kriegischhttps://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] AspectJ 1.9.22 release (Java 22)
Dear AspectJ users, we are pleased to announce AspectJ release. AspectJ 1.9.22 supports Java 22, its final and preview features, such as: JEP 456: Unnamed Variables & Patterns JEP 459: String Templates (Second Preview) JEP 463: Implicitly Declared Classes and Instance Main Methods (Second Preview) JEP 447: Statements before super(...) (Preview) The following Java 22 features are API or JVM only, therefore irrelevant for the compiler and should just work out of the box: JEP 423: Region Pinning for G1 JEP 454: Foreign Function & Memory API JEP 458: Launch Multi-File Source-Code Programs JEP 462: Structured Concurrency (Second Preview) JEP 464: Scoped Values (Second Preview) JEP 457: Class-File API (Preview) JEP 461: Stream Gatherers (Preview) JEP 460: Vector API (Seventh Incubator) Usage hints Since 1.9.21, the AspectJ compiler AJC (contained in the aspectjtools library) no longer works on JDKs 11 to 16. The minimum compile-time requirement is now JDK 17 due to upstream changes in the Eclipse Java Compiler (subset of JDT Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime aspectjrt, but the compiler itself needs JDK 17+. Just like in previous AspectJ versions, both the runtime aspectjrt and the load-time weaver aspectjweaver still only require JRE 8+. History: Since 1.9.7, the AspectJ compiler AJC needed JDK 11+, before then JDK 8+. Since AspectJ 1.9.21.1, using --add-opens is no longer necessary for load-time weaving on JDK 16+! The additional JVM command-line option was necessary in all AspectJ versions up to 1.9.21. Resources For more detailed release information, please read the release notes. The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.31 (2024-03). Unfortunately, updates sites for previous Eclipse versions are no longer compatible with AspectJ 1.9.22, because the latter depends on upstream Eclipse changes. So if you want to use ADJT builds with Eclipse IDE, you need to upgrade to 2024-03. Otherwise, you can only use AspectJ 1.9.22 via Maven build, not via direct IDE. Documentation for AspectJ can be found here on the Eclipse project website. There also is a short guide describing options for setting up a development environment. See here for more information about how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.14. Enjoy AspectJ! 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
[aspectj-users] AspectJ 1.9.21.2 maintenance release
Dear AspectJ users, we are pleased to announce the AspectJ maintenance release 1.9.21.2 supporting Java 21. Please note that since 1.9.19, the minor-minor version indicates the corresponding latest Java release (byte code version) supported by the AspectJ compiler and weaver. I.e., 1.9.21.2 → Java 21. Improvements Previously, when targeting the same join point from multiple around advices in annotation-style @AspectJ syntax, there were limitations in functionality in concurrent (multi-threaded) situations, if the around advice code was not inlined. This was improved in AspectJ 1.9.9 (see also issue #128), but the improvement only applied to child threads directly created during aspect execution and would fail for pre-existing, long-lived threads, e.g. thread pools used by executor services. Furthermore, the improvement could lead to memory leaks, not cleaning up thread-local references to posssibly expensive objects. In such situations, users had to switch to native-syntax aspects which never had that problem to begin with due to their different internal structure. Now, issue #141 has been resolved, closing the gap and, as well as possible given their different internal structure, bringing @AspectJ aspects up to par with native-syntax aspects in concurrent situations, while simultaneously also addressing the memory leak issue #288. This is a substantial improvement, and annotation-style syntax users are strongly engouraged to upgrade. Thanks to user pagrawalgit for raising the memory leak issue and triggering me to think about the concurrency issue more broadly and finally solve both in one shot. Other changes and bugfixes The fix for issue #277 in AspectJ 1.9.21.1 introduced a regression bug in the optional weaving cache now fixed in issue #285. Thanks to user Kimming Lau for raising and re-testing both issues. Other notes about 1.9.21.x Since 1.9.21, the AspectJ compiler AJC (contained in the aspectjtools library) no longer works on JDKs 11 to 16. The minimum compile-time requirement is now JDK 17 due to upstream changes in the Eclipse Java Compiler (subset of JDT Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime aspectjrt, but the compiler itself needs JDK 17+. Just like in previous AspectJ versions, both the runtime aspectjrt and the load-time weaver aspectjweaver still only require JRE 8+. History: Since 1.9.7, the AspectJ compiler AJC needed JDK 11+, before then JDK 8+. Resources For more detailed release information, please read the release notes. The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.30 (2023-12). Unfortunately, updates sites for previous Eclipse versions , e.g. 4.26 (2022-12) and 4.23 (2022-03) are no longer compatible with AspectJ 1.9.21, because the latter dependes on upstream Eclipse changes. So if you want to use ADJT builds with Eclipse IDE, you need to upgrade to 2023-12. Otherwise, you can only use AspectJ 1.9.21 via Maven build, not via direct IDE. On top of that, you also need an extra update site for Eclipse 2023-12 itself. The IDE guide explains, why this is necessary. On GitHub, there also is a short guide describing options for setting up a development environment. See here for more information about how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.14. Enjoy AspectJ! 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
[aspectj-users] AspectJ 1.9.21.1 maintenance release
Dear AspectJ users, we are pleased to announce the AspectJ bugfix release 1.9.21.1 supporting Java 21. Please note that since 1.9.19, the minor-minor version indicates the corresponding latest Java release (byte code version) supported by the AspectJ compiler and weaver. I.e., 1.9.21.1 → Java 21. For load-time weaving (LTW) on JDK 16+, using --add-opens is no longer necessary! The additional JVM command-line option was necessary for LTW on JRE 16+ in all AspectJ versions up to 1.9.21. Since AspectJ 1.9.21.1, the LTW agent uses an alternative approach for defining new classes during weaving, which works without --add-opens - at least for now, i.e. JDKs 8 to 21. There still is no canonical (as in "not hacky") solution, because JDK-8200559 is still unresolved since 2018. The AspectJ documentation is now written in asciidoc format and processed by the Asciidoctor toolchain. Before, it was a mixture of DocBook XML and plain HTML files. While the content has not changed much, it now looks fresher, is easier to read (also online when browsing the GitHub repository), navigate and maintain and also easy to publish in different formats (multi-page HTML, single-page HTML, PDF). Those formats are also distributed on the website and with the AspectJ installer. A content overhaul is also overdue, but not part of this change. It is still basically the same: Everything up to AspectJ 1.5 is in the regular documentation. The changes since then can be extracted incrementally from various release notes. Please note: Since 1.9.21, the AspectJ compiler AJC (contained in the aspectjtools library) no longer works on JDKs 11 to 16. The minimum compile-time requirement is now JDK 17 due to upstream changes in the Eclipse Java Compiler (subset of JDT Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime aspectjrt, but the compiler itself needs JDK 17+. Just like in previous AspectJ versions, both the runtime aspectjrt and the load-time weaver aspectjweaver still only require JRE 8+. History: Since 1.9.7, the AspectJ compiler AJC needed JDK 11+, before then JDK 8+. Other resources: For more detailed release information, please read the release notes. The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.30 (2023-12). Unfortunately, updates sites for previous Eclipse versions , e.g. 4.26 (2022-12) and 4.23 (2022-03) are no longer compatible with AspectJ 1.9.21, because the latter dependes on upstream Eclipse changes. So if you want to use ADJT builds with Eclipse IDE, you need to upgrade to 2023-12. Otherwise, you can only use AspectJ 1.9.21 via Maven build, not via direct IDE. On top of that, you also need an extra update site for Eclipse 2023-12 itself. The IDE guide explains, why this is necessary. On GitHub, there also is a short guide describing options for setting up a development environment. See here for more information about how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.14. Enjoy AspectJ! 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] Hello world Agent with aspectjweaver
Why not just
use the aspectjweaver Java agent,
package your timing aspect and an aop.xml config file in an aspect library and
put the aspect library on the normal classpath?
Why write an extra agent, if AspectJ already has one that does what you need? You still did not explain anything that would require your complicated approach. Not that it would not work, if done correctly, but it seems to be totally unnecessary. Just use a regular LTW approach. No separate agent, no Maven Shade necessary.
-- Alexander Kriegischhttps://scrum-master.de
kypdk schrieb am 17.01.2024 20:33 (GMT +07:00):
First of all, thank you very much for your answer.Since the coding experiments I have made are AI-guided, I cannot say that they will be consistent.Very simply, to write a simple agent that calculates the total running time of the application I am making as an agent, from the after-before start and end time of the methods running on the JVM.I can do it with Aspectj using AOP technique.I want to do it for legacy applications running on JDK8.regards
Alexander Kriegisch via aspectj-users <aspectj-users@eclipse.org>, 17 Oca 2024 Çar, 12:25 tarihinde şunu yazdı:
This is not trivial. So please, provide a full reproducer project on GitHub including the target code to be woven, so I do not have to fill in the gaps here.
What I noticed at first glance is, that class StartAgent to be and do multiple things at once:
It is a java agent.
It tries to inject another java agent aspectjweaver into the bootstrap classloader, which begs the question why you are not doing that from the JVM command line, if you are already using a -javaagent parameter anyway. Then the springboard agent would not even be necessary. The next question would be why you think you need it on the bootstrap classloader at all.
It is an aspect, i.e. it is accessing classes from aspectjweaver from the system classloader already, before it even has a chance to inject the jar into the bootstrap classloader.
Your springboard agent should not directly import or reference any classes from aspectjweaver or aspectjrt before the weaver JAR has been added to the bootstrap loader. If later for any reason the springboard agent needs to kick off some action involving classes referencing weaver classes, you ought to load and start them via reflection, e.g. Class.forName etc.
It looks as if you are making a simple matter overly complicated. The justification for what you are trying to do could only be a very special use case, which you have failed to describe. So I have no way to be sure, whether there is not a simpler approach. Lacking additional evidence, I would assume there is.
BTW, are you on JDK 8 or on 9+? I am asking for a specific reason too early to discuss now.
--Alexander Kriegischhttps://scrum-master.de
kypdk via aspectj-users schrieb am 17.01.2024 03:20 (GMT +07:00):
Hello,What I want to do is to trigger the before advice on the agent when the methods run on the generator.jarCould you help me ,I would greatly appreciate it
regardsjava -javaagent:JavaAgent.jar -jar Generator.jar
import org.aspectj.lang.JoinPoint;import org.aspectj.lang.annotation.Aspect;import org.aspectj.lang.annotation.Before;import org.aspectj.weaver.loadtime.Agent;import java.io.IOException;import java.lang.instrument.Instrumentation;import java.util.jar.JarFile;@Aspectpublic class StartAgent {public static void premain(String agentArgs, Instrumentation instrumentation) {System.out.println("Java Agent Started");String aspectjWeaverPath = "aspectjweaver.jar";try {instrumentation.appendToBootstrapClassLoaderSearch(new JarFile(aspectjWeaverPath));} catch (IOException e) {System.out.println(e);}Agent.premain(agentArgs, instrumentation);}@Before("execution(* *(..))")public void beforeMethodExecution(JoinPoint joinPoint) {System.out.println("Before method execution: " + joinPoint.getSignature().toShortString());}}
org.apache.maven.pluginsmaven-shade-plugin3.2.4implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">StartAgenttruetrue${project.version}*:*META-INF/*.SFMETA-INF/*.DSAMETA-INF/*.RSApackageshade
___aspectj-users mailing listaspectj-users@eclipse.orgTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/aspectj-users
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubsc
Re: [aspectj-users] Hello world Agent with aspectjweaver
This is not trivial. So please, provide a full reproducer project on GitHub including the target code to be woven, so I do not have to fill in the gaps here.
What I noticed at first glance is, that class StartAgent to be and do multiple things at once:
It is a java agent.
It tries to inject another java agent aspectjweaver into the bootstrap classloader, which begs the question why you are not doing that from the JVM command line, if you are already using a -javaagent parameter anyway. Then the springboard agent would not even be necessary. The next question would be why you think you need it on the bootstrap classloader at all.
It is an aspect, i.e. it is accessing classes from aspectjweaver from the system classloader already, before it even has a chance to inject the jar into the bootstrap classloader.
Your springboard agent should not directly import or reference any classes from aspectjweaver or aspectjrt before the weaver JAR has been added to the bootstrap loader. If later for any reason the springboard agent needs to kick off some action involving classes referencing weaver classes, you ought to load and start them via reflection, e.g. Class.forName etc.
It looks as if you are making a simple matter overly complicated. The justification for what you are trying to do could only be a very special use case, which you have failed to describe. So I have no way to be sure, whether there is not a simpler approach. Lacking additional evidence, I would assume there is.
BTW, are you on JDK 8 or on 9+? I am asking for a specific reason too early to discuss now.
-- Alexander Kriegischhttps://scrum-master.de
kypdk via aspectj-users schrieb am 17.01.2024 03:20 (GMT +07:00):
Hello,What I want to do is to trigger the before advice on the agent when the methods run on the generator.jarCould you help me ,I would greatly appreciate it
regardsjava -javaagent:JavaAgent.jar -jar Generator.jar
import org.aspectj.lang.JoinPoint;import org.aspectj.lang.annotation.Aspect;import org.aspectj.lang.annotation.Before;import org.aspectj.weaver.loadtime.Agent;import java.io.IOException;import java.lang.instrument.Instrumentation;import java.util.jar.JarFile;@Aspectpublic class StartAgent {public static void premain(String agentArgs, Instrumentation instrumentation) {System.out.println("Java Agent Started");String aspectjWeaverPath = "aspectjweaver.jar";try {instrumentation.appendToBootstrapClassLoaderSearch(new JarFile(aspectjWeaverPath));} catch (IOException e) {System.out.println(e);}Agent.premain(agentArgs, instrumentation);}@Before("execution(* *(..))")public void beforeMethodExecution(JoinPoint joinPoint) {System.out.println("Before method execution: " + joinPoint.getSignature().toShortString());}}
org.apache.maven.pluginsmaven-shade-plugin3.2.4implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">StartAgenttruetrue${project.version}*:*META-INF/*.SFMETA-INF/*.DSAMETA-INF/*.RSApackageshade
___
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.21 with Java 21 support
Dear AspectJ users, we are pleased to announce the AspectJ bugfix release 1.9.21 supporting Java 21. Please note that since 1.9.19, the minor-minor version indicates the corresponding latest Java release (byte code version) supported by the AspectJ compiler and weaver. I.e., 1.9.21 → Java 21. Sorry for the delay. Actually, there was a Java 21 snapshot version early after the Java release. But unfortunately, even after holding back the AspectJ release for 3 months after JDK 21 general availability, waiting for Eclipse JDT Core and the Eclipse Java Compiler (ECJ) to catch up with Java 21 language features, even with Java 21 officially supported in Eclipse 2023-12, some preview features are still unimplemented in ECJ. Today, I decided to release anyway, because users have been asking for it. See release notes link below. Please note: Since 1.9.21, the AspectJ compiler AJC (contained in the aspectjtools library) no longer works on JDKs 11 to 16. The minimum compile-time requirement is now JDK 17 due to upstream changes in the Eclipse Java Compiler (subset of JDT Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime aspectjrt, but the compiler itself needs JDK 17+. Just like in previous AspectJ versions, both the runtime aspectjrt and the load-time weaver aspectjweaver still only require JRE 8+. History: Since 1.9.7, the AspectJ compiler AJC needed JDK 11+, before then JDK 8+. Other resources: For more detailed release information, please read the release notes. The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.30 (2023-12). Unfortunately, updates sites for previous Eclipse versions , e.g. 4.26 (2022-12) and 4.23 (2022-03) are no longer compatible with AspectJ 1.9.21, because the latter dependes on upstream Eclipse changes. So if you want to use ADJT builds with Eclipse IDE, you need to upgrade to 2023-12. Otherwise, you can only use AspectJ 1.9.21 via Maven build, not via direct IDE. On top of that, you also need an extra update site for Eclipse 2023-12 itself. The IDE guide explains, why this is necessary. On GitHub, there also is a short guide describing options for setting up a development environment. See AspectJ GitHub issue #95 for more information and for an example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! 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] About AspectJ
Alexander Kriegisch schrieb am 09.10.2023 12:49 (GMT +07:00): > Hi. > > Thanks for your question. The Baeldung page is just a quit entry-level I mean "quick", of course. > tutorial, not a course. It points to a course, but that is a Spring Boot > course. AspectJ is completely independent of Spring, even though Spring's > proxy-based "AOP lite" solution Spring AOP uses AspectJ syntax. > > You seem to have used a web search engine, Wikipedia or ChatGPT in order to > find this sentence containing "PARC". Both a web search and Wikipedia will > lead > you directly to the home page https://eclipse.dev/aspectj/, where you would > immediately find the "Docs" link to https://eclipse.dev/aspectj/docs.php, > where > you can find lots of material for learning AspectJ. > > If you like a more modern layout of the same documentation, there is a work-in > progress branch containing the docs in AsciiDoc format on GitHub under > https://github.com/eclipse-aspectj/aspectj/issues/76 - I really should finish > the job for the latter sometime soon, I simply never felt like digging in > again. > > An older, but still very much recommendable book by Ramnivas Laddad is > "AspectJ > in Action, 2nd edition". You can buy it as a hardcopy or read it online. Take > a > look here: > https://livebook.manning.com/book/aspectj-in-action-second-edition/about-this-book/ > It explains both AspectJ and some Spring specifics. But for Spring AOP (not > native AspectJ!), the Spring Core manual is also a good starting point. > > Hope this helps. > -- > Alexander Kriegisch > https://scrum-master.de > > > Turritopsis Dohrnii Teo En Ming via aspectj-users schrieb am 08.10.2023 20:44 > (GMT +07:00): > >> Subject: About AspectJ >> >> Good day from Singapore, >> >> I understand AspectJ is an aspect-oriented programming (AOP) extension >> created at PARC for the Java programming language. If I want to learn >> AspectJ, can I take the courses here? >> >> https://www.baeldung.com/aspectj >> >> Thank you. >> >> Regards, >> >> Mr. Turritopsis Dohrnii Teo En Ming >> Targeted Individual in Singapore >> Blogs: >> https://tdtemcerts.blogspot.com >> https://tdtemcerts.wordpress.com >> GIMP also stands for Government-Induced Medical Problems. >> ___ >> 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] About AspectJ
Hi. Thanks for your question. The Baeldung page is just a quit entry-level tutorial, not a course. It points to a course, but that is a Spring Boot course. AspectJ is completely independent of Spring, even though Spring's proxy-based "AOP lite" solution Spring AOP uses AspectJ syntax. You seem to have used a web search engine, Wikipedia or ChatGPT in order to find this sentence containing "PARC". Both a web search and Wikipedia will lead you directly to the home page https://eclipse.dev/aspectj/, where you would immediately find the "Docs" link to https://eclipse.dev/aspectj/docs.php, where you can find lots of material for learning AspectJ. If you like a more modern layout of the same documentation, there is a work-in progress branch containing the docs in AsciiDoc format on GitHub under https://github.com/eclipse-aspectj/aspectj/issues/76 - I really should finish the job for the latter sometime soon, I simply never felt like digging in again. An older, but still very much recommendable book by Ramnivas Laddad is "AspectJ in Action, 2nd edition". You can buy it as a hardcopy or read it online. Take a look here: https://livebook.manning.com/book/aspectj-in-action-second-edition/about-this-book/ It explains both AspectJ and some Spring specifics. But for Spring AOP (not native AspectJ!), the Spring Core manual is also a good starting point. Hope this helps. -- Alexander Kriegisch https://scrum-master.de Turritopsis Dohrnii Teo En Ming via aspectj-users schrieb am 08.10.2023 20:44 (GMT +07:00): > Subject: About AspectJ > > Good day from Singapore, > > I understand AspectJ is an aspect-oriented programming (AOP) extension > created at PARC for the Java programming language. If I want to learn > AspectJ, can I take the courses here? > > https://www.baeldung.com/aspectj > > Thank you. > > Regards, > > Mr. Turritopsis Dohrnii Teo En Ming > Targeted Individual in Singapore > Blogs: > https://tdtemcerts.blogspot.com > https://tdtemcerts.wordpress.com > GIMP also stands for Government-Induced Medical Problems. > ___ > 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.20.1 bugfix release with Java 20 support
Dear AspectJ users, we are pleased to announce the AspectJ bugfix release 1.9.20.1 supporting Java 20. Please note that since 1.9.19, the minor-minor version indicates the corresponding latest Java release (byte code version) supported by the AspectJ compiler and weaver. I.e., 1.9.20.1 → Java 20. Other resources: The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.26 (2022-12). It has not been updated to contain the current AspectJ release and still works in the current Eclipse 4.28 (2023-06) release. For more detailed release information, please read the release notes. On GitHub, there also is a short guide describing options for setting up a development environment. See AspectJ GitHub issue #95 for more information and for an example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! 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] AspectJ 1.9.20 with Java 20 support
The AJDT version for 2022-12+ now also is up to date and carries AspectJ 1.9.20 in its belly. Cheers Alexander Kriegisch (Xander) AspectJ team Alexander Kriegisch schrieb am 17.08.2023 07:42 (GMT +07:00): Dear AspectJ users, we are pleased to announce the AspectJ bugfix release 1.9.20 supporting Java 20. Please note that since 1.9.19, the minor-minor version indicates the corresponding latest Java release (byte code version) supported by the AspectJ compiler and weaver. I.e., 1.9.20 → Java 20. Sorry for the delay. Actually, there was a Java 20 snapshot version early after the Java release, and not much has changed in the almost 5 months since then, but I was simply quite busy. The good news are that at least the Java 20 release is out before the arrival of JDK 21 and about a dozen bug fixes and some small improvements found their way into AspectJ. Other resources: The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.26 (2022-12). It has not been updated to contain the current AspectJ release yet, but the version provided there still works in the current Eclipse 4.28 (2023-06) release. For more detailed release information, please read the release notes. On GitHub, there also is a short guide describing options for setting up a development environment. See AspectJ GitHub issue #95 for more information and for an example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! 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
[aspectj-users] AspectJ 1.9.20 with Java 20 support
Dear AspectJ users, we are pleased to announce the AspectJ bugfix release 1.9.20 supporting Java 20. Please note that since 1.9.19, the minor-minor version indicates the corresponding latest Java release (byte code version) supported by the AspectJ compiler and weaver. I.e., 1.9.20 → Java 20. Sorry for the delay. Actually, there was a Java 20 snapshot version early after the Java release, and not much has changed in the almost 5 months since then, but I was simply quite busy. The good news are that at least the Java 20 release is out before the arrival of JDK 21 and about a dozen bug fixes and some small improvements found their way into AspectJ. Other resources: The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.26 (2022-12). It has not been updated to contain the current AspectJ release yet, but the version provided there still works in the current Eclipse 4.28 (2023-06) release. For more detailed release information, please read the release notes. On GitHub, there also is a short guide describing options for setting up a development environment. See AspectJ GitHub issue #95 for more information and for an example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! 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] meta-data problem with aspectj-maven-plugin
Hi Eric.
I prefer Xander to Alex.
Concerning AspectJ Maven: I recommend to use a default directory layout, then you should be fine without needing to specify directories, in-/excludes etc.
Regarding AspectJ & Lombok: I remember your discussion with Andy back in 2014. For others, the basic info is here on Stack Overflow, also linking to the mailing list thread from back then. There are also solid workarounds for the problem, e.g.
using a delombok step before applying AspectJ compilation on the delomboked sources,
compiling with Maven Compiler & Lombok, then applying AspectJ binary weaving, either in a single module (not recommended) or in a separate module (my recommendation).
Some of my Stack Overflow answers:
https://stackoverflow.com/a/56999300/1082681 comes with a link to a GitHub repository showing a some alternatives.
https://stackoverflow.com/a/56999300/1082681 also describes how to get a specific approach working in IntelliJ IDEA.
-- Alexander Kriegischhttps://scrum-master.de
Eric B via aspectj-users schrieb am 11.08.2023 02:37 (GMT +07:00):
Thanks Alex,
My code was actually cut & paste; I'm not sure what happened with the email client
Your message helped me reapproach it, and I got it to work. I'm not sure what the plugin is doing, but I needed to identify the sources better than I was doing. By specifying exact sources that I was targeting to compile, the plugin works and is able to weave. Of course, I am once again running into my problems that I tried to work out with Andy 10yrs ago with Lombok, but that's a whole different topic to figure out.
In the meantime, I've managed to cobble together the necessary pieces for the team to work with.
Thanks!
Eric
On Wed, Aug 9, 2023 at 8:44 PM Alexander Kriegisch via aspectj-users <aspectj-users@eclipse.org> wrote:
Sorry, I sent half an answer. What I wrote before relates to
[WARNING] bad version number found in /Users/eric/dev/.m2/repository/org/aspectj/aspectjrt/1.9.19/aspectjrt-1.9.19.jar expected 1.9.8.RC1 found 1.9.19:
As for your compilation error, I really need a reproducer to get to the bottom of that. I cannot debug plain prose in that case.
--Alexander Kriegischhttps://scrum-master.de
Alexander Kriegisch via aspectj-users schrieb am 10.08.2023 07:27 (GMT +07:00):
Welcome back to the AspectJ world, Eric.
Next time, please post your code as formatted text, links to repositories or attachments, rather than as a screenshot. Please also note that this question is about AspectJ Maven Plugin rather than AspectJ itself, which would make it better suited to Stack Overflow. But I can answer here, too.
As you can see e.g. at https://mvnrepository.com/artifact/dev.aspectj/aspectj-maven-plugin/1.13.1, that plugin version depends on AspectJ 1.9.8.RC1, which can be updated to 1.9.19, the latter one being the version your own module depends on:
You are experiencing the situation that you have defined dependencies on AspectJ for your module, but did not synchronise the plugin's dependency. How to do that is described in https://dev-aspectj.github.io/aspectj-maven-plugin/usage.html#Upgrading_or_downgrading_AspectJ: Simply define a plugin dependency to the aspectjtools version in sync with what your module uses. This also enables you to compile up to the Java source/target level represented by that AspectJ version, in this case Java 19.
org.codehaus.mojo
aspectj-maven-plugin
1.13.1
org.aspectj
aspectjtools
${aspectj.version}
...
Besides, your module does not need aspectjweaver for CTW, only for LTW. So you can eliminate that from your dependency list and just keep aspectjrt.
Cheers
--Alexander Kriegischhttps://scrum-master.de
Eric B via aspectj-users schrieb am 09.08.2023 18:55 (GMT +07:00):
I've been away from AJ for a while, but needed to add it to my Java 17 project recently. This i my first time trying to use AJ with Java 11+.
I tried adding the aspectjrt and weaver dependencies to my POM and enabling CTW using the aspectj-maven-plugin as follows:
org.aspectj aspectjrt 1.9.19 org.aspectj aspectjweaver 1.9.19
dev.aspectj aspectj-maven-plugin 1.13.1 17 true true ignore UTF-8 compile test-compile
Yet when I try to compile anything, I get the following error which stumps me:
[INFO] --- aspectj:1.13.1:compile (default) @ poc-oauth-snowflake ---[INFO] Showing AJC message detail for messages of types: [error, warning, fail][WARNING] bad version number found in /Users/eric/dev/.m2/repository/org/aspectj/aspectjrt/1.9.19/aspectjrt-1.9.19.jar expected 1.9.8.RC1 found 1.9.19 :[ERROR] Internal compiler error: java.lang.Exception: java.lang.IllegalStateException: Error processing configuration meta-data on public org.springframework.boot.autoconfigure.jdbc.DataSourceProperties da
Re: [aspectj-users] meta-data problem with aspectj-maven-plugin
Sorry, I sent half an answer. What I wrote before relates to
[WARNING] bad version number found in /Users/eric/dev/.m2/repository/org/aspectj/aspectjrt/1.9.19/aspectjrt-1.9.19.jar expected 1.9.8.RC1 found 1.9.19 :
As for your compilation error, I really need a reproducer to get to the bottom of that. I cannot debug plain prose in that case.
-- Alexander Kriegischhttps://scrum-master.de
Alexander Kriegisch via aspectj-users schrieb am 10.08.2023 07:27 (GMT +07:00):
Welcome back to the AspectJ world, Eric.
Next time, please post your code as formatted text, links to repositories or attachments, rather than as a screenshot. Please also note that this question is about AspectJ Maven Plugin rather than AspectJ itself, which would make it better suited to Stack Overflow. But I can answer here, too.
As you can see e.g. at https://mvnrepository.com/artifact/dev.aspectj/aspectj-maven-plugin/1.13.1, that plugin version depends on AspectJ 1.9.8.RC1, which can be updated to 1.9.19, the latter one being the version your own module depends on:
You are experiencing the situation that you have defined dependencies on AspectJ for your module, but did not synchronise the plugin's dependency. How to do that is described in https://dev-aspectj.github.io/aspectj-maven-plugin/usage.html#Upgrading_or_downgrading_AspectJ: Simply define a plugin dependency to the aspectjtools version in sync with what your module uses. This also enables you to compile up to the Java source/target level represented by that AspectJ version, in this case Java 19.
org.codehaus.mojo
aspectj-maven-plugin
1.13.1
org.aspectj
aspectjtools
${aspectj.version}
...
Besides, your module does not need aspectjweaver for CTW, only for LTW. So you can eliminate that from your dependency list and just keep aspectjrt.
Cheers
--Alexander Kriegischhttps://scrum-master.de
Eric B via aspectj-users schrieb am 09.08.2023 18:55 (GMT +07:00):
I've been away from AJ for a while, but needed to add it to my Java 17 project recently. This i my first time trying to use AJ with Java 11+.
I tried adding the aspectjrt and weaver dependencies to my POM and enabling CTW using the aspectj-maven-plugin as follows:
org.aspectj aspectjrt 1.9.19 org.aspectj aspectjweaver 1.9.19
dev.aspectj aspectj-maven-plugin 1.13.1 17 true true ignore UTF-8 compile test-compile
Yet when I try to compile anything, I get the following error which stumps me:
[INFO] --- aspectj:1.13.1:compile (default) @ poc-oauth-snowflake ---[INFO] Showing AJC message detail for messages of types: [error, warning, fail][WARNING] bad version number found in /Users/eric/dev/.m2/repository/org/aspectj/aspectjrt/1.9.19/aspectjrt-1.9.19.jar expected 1.9.8.RC1 found 1.9.19 :[ERROR] Internal compiler error: java.lang.Exception: java.lang.IllegalStateException: Error processing configuration meta-data on public org.springframework.boot.autoconfigure.jdbc.DataSourceProperties dataSourceProperties() at org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:172) /Users/eric/dev/giis-finance/poc-oauth/src/main/java/poc/liquibase/oauth/service/AccessTokenService.java:0(no source information available)
Removing AJC, and java compiles fine.
Does anyone know what configuration meta-data AJC might be complaining about, or what I might have missed in my config?
I'm running with :
openjdk version "17.0.7" 2023-04-18OpenJDK Runtime Environment Homebrew (build 17.0.7+0)OpenJDK 64-Bit Server VM Homebrew (build 17.0.7+0, mixed mode, sharing)
Thanks!
Eric
___
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] meta-data problem with aspectj-maven-plugin
Welcome back to the AspectJ world, Eric.
Next time, please post your code as formatted text, links to repositories or attachments, rather than as a screenshot. Please also note that this question is about AspectJ Maven Plugin rather than AspectJ itself, which would make it better suited to Stack Overflow. But I can answer here, too.
As you can see e.g. at https://mvnrepository.com/artifact/dev.aspectj/aspectj-maven-plugin/1.13.1, that plugin version depends on AspectJ 1.9.8.RC1, which can be updated to 1.9.19, the latter one being the version your own module depends on:
You are experiencing the situation that you have defined dependencies on AspectJ for your module, but did not synchronise the plugin's dependency. How to do that is described in https://dev-aspectj.github.io/aspectj-maven-plugin/usage.html#Upgrading_or_downgrading_AspectJ: Simply define a plugin dependency to the aspectjtools version in sync with what your module uses. This also enables you to compile up to the Java source/target level represented by that AspectJ version, in this case Java 19.
org.codehaus.mojo
aspectj-maven-plugin
1.13.1
org.aspectj
aspectjtools
${aspectj.version}
...
Besides, your module does not need aspectjweaver for CTW, only for LTW. So you can eliminate that from your dependency list and just keep aspectjrt.
Cheers
-- Alexander Kriegischhttps://scrum-master.de
Eric B via aspectj-users schrieb am 09.08.2023 18:55 (GMT +07:00):
I've been away from AJ for a while, but needed to add it to my Java 17 project recently. This i my first time trying to use AJ with Java 11+.
I tried adding the aspectjrt and weaver dependencies to my POM and enabling CTW using the aspectj-maven-plugin as follows:
org.aspectj aspectjrt 1.9.19 org.aspectj aspectjweaver 1.9.19
dev.aspectj aspectj-maven-plugin 1.13.1 17 true true ignore UTF-8 compile test-compile
Yet when I try to compile anything, I get the following error which stumps me:
[INFO] --- aspectj:1.13.1:compile (default) @ poc-oauth-snowflake ---[INFO] Showing AJC message detail for messages of types: [error, warning, fail][WARNING] bad version number found in /Users/eric/dev/.m2/repository/org/aspectj/aspectjrt/1.9.19/aspectjrt-1.9.19.jar expected 1.9.8.RC1 found 1.9.19 :[ERROR] Internal compiler error: java.lang.Exception: java.lang.IllegalStateException: Error processing configuration meta-data on public org.springframework.boot.autoconfigure.jdbc.DataSourceProperties dataSourceProperties() at org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:172) /Users/eric/dev/giis-finance/poc-oauth/src/main/java/poc/liquibase/oauth/service/AccessTokenService.java:0(no source information available)
Removing AJC, and java compiles fine.
Does anyone know what configuration meta-data AJC might be complaining about, or what I might have missed in my config?
I'm running with :
openjdk version "17.0.7" 2023-04-18OpenJDK Runtime Environment Homebrew (build 17.0.7+0)OpenJDK 64-Bit Server VM Homebrew (build 17.0.7+0, mixed mode, sharing)
Thanks!
Eric
___
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.19 with Java 19 support
Update: AJDT was refreshed and now contains the latest AspectJ version. It still targets Eclipse 2022-03, but works on 2022-12, like I said. See below for the update site link. Errata: Of course 1.9.19 is not a "bugfix release". That was a copy & paste error. It is a regular release upgrading Java language support to JDK 19 level. Alexander Kriegisch schrieb am 21.12.2022 17:33 (GMT +01:00): Dear AspectJ users, we are pleased to announce the AspectJ bugfix release 1.9.19 supporting Java 19. Please note that from now on, the minor-minor version will indicate the corresponding latest Java release (byte code version) supported by the AspectJ compiler and weaver. I.e., 1.9.19 → Java 19. Sorry for the delay. Actually, there was a Java 19 snapshot version early after the Java release, but we wanted to wait for some upstream Eclipse Java Compiler (ECJ) bugs concerning Java 19 to be fixed before the AspectJ release. Finally, we decided to wait no longer and release anyway, even though not all Java preview feature edge cases are supported as well as with Javac. The release notes contain a link to a list of open ECJ issues we identified while testing AspectJ with Java 19 preview features. None of those issues come from AspectJ itself, they are inherited from ECJ. Other resources: The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.23 (2022-03). It has not been updated to contain the current AspectJ release yet, but the version provided there still works in the current Eclipse 4.26 (2022-12) release. For more detailed release information, please read the release notes. On GitHub, there also is a short guide describing options for setting up a development environment. See AspectJ GitHub issue #95 for more information and for an example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! 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
[aspectj-users] AspectJ 1.9.19 with Java 19 support
Dear AspectJ users, we are pleased to announce the AspectJ bugfix release 1.9.19 supporting Java 19. Please note that from now on, the minor-minor version will indicate the corresponding latest Java release (byte code version) supported by the AspectJ compiler and weaver. I.e., 1.9.19 → Java 19. Sorry for the delay. Actually, there was a Java 19 snapshot version early after the Java release, but we wanted to wait for some upstream Eclipse Java Compiler (ECJ) bugs concerning Java 19 to be fixed before the AspectJ release. Finally, we decided to wait no longer and release anyway, even though not all Java preview feature edge cases are supported as well as with Javac. The release notes contain a link to a list of open ECJ issues we identified while testing AspectJ with Java 19 preview features. None of those issues come from AspectJ itself, they are inherited from ECJ. Other resources: The current artifacts (runtime, weaver, compiler, matcher) are available on Maven Central. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.23 (2022-03). It has not been updated to contain the current AspectJ release yet, but the version provided there still works in the current Eclipse 4.26 (2022-12) release. For more detailed release information, please read the release notes. On GitHub, there also is a short guide describing options for setting up a development environment. See AspectJ GitHub issue #95 for more information and for an example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! 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] Passing instance of Aspect into a pointcut
> I think what I am looking for should be achievable
Well, then why did you not achieve it yet?
An if() pointcut in annotation-style syntax needs to be a static method, see here:
https://www.eclipse.org/aspectj/doc/next/adk15notebook/ataspectj-pcadvice.html#d0e3697
You also cannot just add an aspect instance argument, just because you dream about doing so.
-- Alexander Kriegischhttps://scrum-master.de
Alex Rojkov schrieb am 07.09.2022 18:31 (GMT +02:00):
Thanks for the answer Alexander,
I think what I am looking for should be achievable - at least judging from the code generated for the advice.
A reference to the instance of the Aspect is available in the call site of the isActive() method.
So that means to me that
1. isActive() can be an instance method ( I admit there are use-cases where it must be static )
2. when if() accepts an argument with a type of the Aspect type ( e.g. isActive(FooAspect aspect)) - instance of the Aspect can be resolved.
Thanks,
Alex
On Wed, Sep 7, 2022 at 8:44 AM Alexander Kriegisch <alexan...@kriegisch.name> wrote:
Hi Alex.
Your question is about Spring AOP rather than native AspectJ. Anyway, AFAIK you cannot inject a Spring bean into a static field, but of course you also cannot access an instance field from a static 'if()' method without some means to fetch a reference to the instance you wish to access. So if you think that an `if()` pointcut looks prettier than a condition at the beginning of an advice method, you are going to have to live with calling 'aspectOf()'.
Kind regards
--Alexander Kriegischhttps://scrum-master.de
Alex Rojkov schrieb am 06.09.2022 05:11 (GMT +02:00):
I have an Aspect that defines @Around advice.
@Aspect
class FooAspect {
@spring.Autowired Env env;
@Around(some())
public Object advice(String name) {
return env.get(name);
}
}
I'd like this Aspect to execute when env is not null and delegate to JoinPoint when it is null.
@Around(some())
public Object advice(String name, ProceedingJointPoint pjp) {
if (env != null) {
return env.get(name);
else
return pjp.proceed();
}
However, I'd like to avoid cluttering the advice and do something like this instead.
@Pointcut("if()")
public static boolean isActive(FooAspect aspect) {
return aspect.env != null;
}
@Around(isActive() && some())
public Object advice(String name, ProceedingJointPoint pjp) {
return env.get(name);
}
Question: is there a way to pass the instance of the advice to the isActive() pointcut?
I'd like to avoid using Aspects.aspectOf() to get hold of the instance.
Thanks,
Alex
___aspectj-users mailing listaspectj-users@eclipse.orgTo 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] Passing instance of Aspect into a pointcut
Hi Alex.
Your question is about Spring AOP rather than native AspectJ. Anyway, AFAIK you cannot inject a Spring bean into a static field, but of course you also cannot access an instance field from a static 'if()' method without some means to fetch a reference to the instance you wish to access. So if you think that an `if()` pointcut looks prettier than a condition at the beginning of an advice method, you are going to have to live with calling 'aspectOf()'.
Kind regards
-- Alexander Kriegischhttps://scrum-master.de
Alex Rojkov schrieb am 06.09.2022 05:11 (GMT +02:00):
I have an Aspect that defines @Around advice.
@Aspect
class FooAspect {
@spring.Autowired Env env;
@Around(some())
public Object advice(String name) {
return env.get(name);
}
}
I'd like this Aspect to execute when env is not null and delegate to JoinPoint when it is null.
@Around(some())
public Object advice(String name, ProceedingJointPoint pjp) {
if (env != null) {
return env.get(name);
else
return pjp.proceed();
}
However, I'd like to avoid cluttering the advice and do something like this instead.
@Pointcut("if()")
public static boolean isActive(FooAspect aspect) {
return aspect.env != null;
}
@Around(isActive() && some())
public Object advice(String name, ProceedingJointPoint pjp) {
return env.get(name);
}
Question: is there a way to pass the instance of the advice to the isActive() pointcut?
I'd like to avoid using Aspects.aspectOf() to get hold of the instance.
Thanks,
Alex
___
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] call and execution pointcut problem
> The problem is the usage of 'call'. No, it is not. The problem is what I explained: You do not fully understand how to correctly configure your build and test run in order to achieve that the 'call' pointcut works for the test class calling the target method. You simply need to make sure that your tests are also woven, that is all. > I decided to use 'execution' instead and then use StackTraceElement > for from a stacktrace to find the calling class and method. Think about it for a minute: Just in order to make your test work correctly and identify the caller from the aspect, you are changing your production aspect to manually and slowly parse a stack trace. Besides, as soon as you introduce more aspects, you might have to adjust the stack trace analysis, because the stack trace can change if another aspect intercepts the same joinpoint. But even without that it is the wrong way. By the way, if you use 'call' in combination with 'thisEnclosingJoinPointStaticPart' (native syntax) or 'JoinPoint.EnclosingStaticPart' (annotation syntax), you can directly determine the caller, if you need that in your aspect. Just make sure to configure the AspectJ compiler or load time weaver to also encompass your test class. You might want to find https://stackoverflow.com/a/66649082/1082681 or one of my other answers linked off of there helpful. -- 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
Re: [aspectj-users] call and execution pointcut problem
Hi Mikael. This is not a bug but to be expected. Please note that while 'execution()' is woven into the target method (callee), 'call()' is woven into the calling method (caller). However, the caller is your test, and probably you configured AspectJ Maven to use the 'compile' goal, but not the 'test-compile' goal. Or maybe your plugin configuration conflicts with Maven Compiler, which can happen if you are not using the default phase but a custom one, leading to Maven Compiler to recompile and overwrite code which previously was compiled by AspectJ Maven already. Without an MCVE [1] this is difficult to say. [1] https://stackoverflow.com/help/mcve -- Alexander Kriegisch https://scrum-master.de Mikael Petterson: > I have the following maven modules: > > 1.Aspects > > 2.Sim > > 3.Test > > Aspect looks like: > > (...) > @annotation(Deprecated) && (call(public * *(..)) || call(*.new(..))); > (...) > > I have built Aspect and weaved it into Sim module using the > > > > > tags. > > I add a @Deprecated method in Sim module on a class method. > > Then I let one of my tests in Test module call the method annotated > @Deprecated in Sim module. > > When using 'call' in the aspect I don't see the info, println in > aspect, of my deprecated method in Sim module being called. > > However if I change to 'execution' in my aspect then I can see that > the info of my method in Sim module being called. All other things the > same. > > Problem with this is I cannot see the calling class. There is no info > for that when using 'execution'. > > Is this is a bug? Or am I using it in the wrong way? ___ 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.9.1 minor release with JPMS compilation fixes
Dear AspectJ users, we are pleased to announce the AspectJ bugfix release 1.9.9.1. It contains fixes for some compiler options related to the Java Platform Module System (JPMS) which were not working, most importantly --add-modules, --add-exports and --add-reads. See issue #145. It is available on Maven Central already. The AspectJ installer can be found on GitHub. There is also an AJDT update site for Eclipse 4.23 (2022-03). For more detailed release information, please read the release notes. On GitHub, there also is a short guide describing options for setting up a development environment. See AspectJ GitHub issue #95 for more information and for an example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! The AspectJ team Alexander Kriegisch schrieb am 25.03.2022 00:00 (GMT +07:00): we are pleased to announce AspectJ release 1.9.9 with Java 18 support. It is available on Maven Central already. The AspectJ installer can be found on Aspectj.dev. There is also an AJDT update site for Eclipse 4.23 (2022-03). For more detailed release information, please read the release notes. ___ 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.9 final release with Java 18 support
Dear AspectJ users, we are pleased to announce AspectJ release 1.9.9 with Java 18 support. It is available on Maven Central already. The AspectJ installer can be found on Aspectj.dev. There is also an AJDT update site for Eclipse 4.23 (2022-03). For more detailes release information, please read the release notes. On GitHub there also is a short guide describing options for setting up a development environment. See AspectJ GitHub issue #95 for more information and for an example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! 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] aspectjtools fail with NPE during maven build
Dear Martin,
please don't just guess. Version 1.14 of Mojohaus AspectJ Maven supports
up to Java 16 and the dev.aspectj version 1.13.1 works with Java 17 (and
can be upgraded to anything more recent, as soon as new AspectJ versions
with future Java version support are released in the future). So while I
normally recommend the dev.aspectj version, because it has the biggest
feature set and latest AspectJ support, all three plugins should be OK
with Java 11, even the retired one you recommend. This is why I asked
for an MCVE [1]. I do not think that the plugin is the problem, even
though in theory there is always that possibility, of course. But let us
analyse rather than guess and confuse the people looking for help here,
shall we?
[1] https://stackoverflow.com/help/mcve
--
Alexander Kriegisch
https://scrum-master.de
Martin Gainty schrieb am 13.02.2022 21:41 (GMT +07:00):
>
> try version 1.1 of Wong's aspectj-maven-plugin
>
> com.nickwongdev
> aspectj-maven-plugin
> 1.12.6
>
>
> java - aspectj-maven-plugin 1.11 : missing tools.jar issue with jdk 11 -
> Stack Overflow
> <https://stackoverflow.com/questions/62976155/aspectj-maven-plugin-1-11-missing-tools-jar-issue-with-jdk-11>
>
> Buona Fortuna
>
>
>
>
> From: aspectj-users on behalf of
> raimon...@meganet.lt
> Sent: Saturday, February 12, 2022 7:38 AM
> To: aspectj-users@eclipse.org
> Subject: [aspectj-users] aspectjtools fail with NPE during maven build
>
>
> Hi,
>
>
> We are doing migration of our project to Java 11 and got blocked by this
> aspectjtools fail with NPE during maven build. Context:
>
> 1. Java 11 (AdoptOpenJDK jdk-11.0.10.9-hotspot)
>
> 2. aspectj-maven-plugin v1.14
>
> 3. aspectjtools v1.9.7
>
> 4. pom.xml snippet
>
>
>
> org.codehaus.mojo
>
> aspectj-maven-plugin
>
> 1.14
>
>
>
> 11
>
> 11
>
> 11
>
> true
>
> true
>
>
>
>
>
> xxx.xxx.xxx
>
> xxx-aspects
>
>
>
>
>
>
>
> **/*.aj
>
> **/*.class
>
>
>
> cantFindType=ignore
>
>
>
> ${project.build.directory}/classesToWeav
>
>
>
>
>
>
>
>
>
>
>
> process-classes
>
>
>
> compile
>
>
>
>
>
>
>
>
>
>
>
> org.aspectj
>
> aspectjtools
>
> 1.9.7
>
> compile
>
>
>
>
>
>
>
>
> 5. Stack trace:
>
> [ERROR] Failed to execute goal
> org.codehaus.mojo:aspectj-maven-plugin:1.14.0:compile (default) on project
> xxx: AJC compiler errors:
>
> [ERROR] abort ABORT -- (NullPointerException) null
>
> [ERROR] null
>
> [ERROR] java.lang.NullPointerException
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJmod.getModulesDeclaringPackage(ClasspathJmod.java:146)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathLocation.isPackage(ClasspathLocation.java:184)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJmod.findClass(ClasspathJmod.java:55)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.internalFindClass(FileSystem.java:544)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.findClass(FileSystem.java:464)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.findType(FileSystem.java:617)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.env.IModuleAwareNameEnvironment.findType(IModuleAwareNameEnvironment.java:101)
>
> [ERROR] at
> org.aspectj.ajdt.internal.core.builder.StatefulNameEnvironment.findType(StatefulNameEnvironment.java:101)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createPlainPackage(LookupEnvironment.java:1151)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildTypeBindings(CompilationUnitScope.java:136)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:487)
>
> [ERROR] at
> org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.buildTypeBindings(AjLookupEnvironment.java:1471)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:870)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:395)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:449)
>
> [ERROR] at
> org.aspectj.org.eclipse.jdt.internal
[aspectj-users] AspectJ 1.9.8 final release with Java 17 support
Dear AspectJ users, we have just released 1.9.8 (yes, finally). It is available on Maven Central already. The AspectJ installer can be found on Aspectj.dev. For more information, please read the release notes. See AspectJ GitHub issue #95 for more information and for an example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! The AspectJ team Alexander Kriegisch schrieb am 26.11.2021 15:43 (GMT +07:00): Dear AspectJ users, we have just released 1.9.8.RC3. It is available on Maven Central already. It fixes an Ant task problem from RC1 and RC2 as well as a compiler bug introduced in 1.9.5. See AspectJ GitHub issue #95 for more information and for en example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Alexander Kriegisch schrieb am 14.11.2021 09:20 (GMT +01:00): a few days ago we released 1.9.8.RC2. It fixes an upstream Eclipse Compiler bug. See AspectJ GitHub issue #95 for more information and for en example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. To everyone: Please test it in as many projects as possible. Your feedback is welcome. Alexander Kriegisch schrieb am 11.10.2021 12:10 (GMT +02:00): a couple of days ago we published the first release candidate for AspectJ 1.9.8 on Maven Central. If there are no blocker bugs, 1.9.8.RC1 might very well be identical to the final 1.9.8 release. What is new since 1.9.7: Cross-compilation via --release N now works as expected, see GitHub issue #70. This was never tested before since AspectJ 1.9.0 and has been fixed in 1.9.8.M1. Java 17 is now supported as a compilation source and target version. Compared to the previously released developer version, we integrated the final Java 17 support from ECJ on top of JDT Core 3.27. Due to upstream ECJ changes, now for compile-time or binary weaving you need to run the AJC compiler on JDK 11+. 1.9.8.M1 was the last version running on JDK 8. Preliminary release notes are here. The corresponding installer is available on AspectJ.dev. Alexander Kriegisch schrieb am 28.07.2021 15:47 (GMT +02:00): the AspectJ development team is pleased to announce that a few days ago we released version 1.9.8.M1, available on Maven Central. The new feature compared to 1.9.7 is that cross-compilation via --release N now works as expected, see GitHub issue #70. This was never tested before since AspectJ 1.9.0 and has been fixed. This little milestone release still supports up to JDK 16, no changes there. Additionally, we have started integrating Java 17 early access releases by integrating the beta-17 Eclipse Java Compiler (ECJ) branch into a development branch. So if you use version 1.9.8-SNAPSHOT from Maven Central's snapshot repository as described in GitHub issue #79, you can compile Java 17 source code and create Java 17 class files. The compiler features go as far as the ECJ implementation has progressed so far. I noticed that the new preview feature JEP 406: Pattern Matching for switch in ECJ is not completely done yet, but that is to be expected from an EA version. Otherwise, it seems to be pretty stable already. All AspectJ tests except the JEP 406 ones are green. ___ 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.8.RC3 with Java 17 support
Dear AspectJ users, we have just released 1.9.8.RC3. It is available on Maven Central already. It fixes an Ant task problem from RC1 and RC2 as well as a compiler bug introduced in 1.9.5. See AspectJ GitHub issue #95 for more information and for en example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. Enjoy AspectJ! The AspectJ team Alexander Kriegisch schrieb am 14.11.2021 09:20 (GMT +01:00): a few days ago we released 1.9.8.RC2. It fixes an upstream Eclipse Compiler bug. See AspectJ GitHub issue #95 for more information and for en example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. To everyone: Please test it in as many projects as possible. Your feedback is welcome. Alexander Kriegisch schrieb am 11.10.2021 12:10 (GMT +02:00): a couple of days ago we published the first release candidate for AspectJ 1.9.8 on Maven Central. If there are no blocker bugs, 1.9.8.RC1 might very well be identical to the final 1.9.8 release. What is new since 1.9.7: Cross-compilation via --release N now works as expected, see GitHub issue #70. This was never tested before since AspectJ 1.9.0 and has been fixed in 1.9.8.M1. Java 17 is now supported as a compilation source and target version. Compared to the previously released developer version, we integrated the final Java 17 support from ECJ on top of JDT Core 3.27. Due to upstream ECJ changes, now for compile-time or binary weaving you need to run the AJC compiler on JDK 11+. 1.9.8.M1 was the last version running on JDK 8. Preliminary release notes are here. The corresponding installer is available on AspectJ.dev. Alexander Kriegisch schrieb am 28.07.2021 15:47 (GMT +02:00): the AspectJ development team is pleased to announce that a few days ago we released version 1.9.8.M1, available on Maven Central. The new feature compared to 1.9.7 is that cross-compilation via --release N now works as expected, see GitHub issue #70. This was never tested before since AspectJ 1.9.0 and has been fixed. This little milestone release still supports up to JDK 16, no changes there. Additionally, we have started integrating Java 17 early access releases by integrating the beta-17 Eclipse Java Compiler (ECJ) branch into a development branch. So if you use version 1.9.8-SNAPSHOT from Maven Central's snapshot repository as described in GitHub issue #79, you can compile Java 17 source code and create Java 17 class files. The compiler features go as far as the ECJ implementation has progressed so far. I noticed that the new preview feature JEP 406: Pattern Matching for switch in ECJ is not completely done yet, but that is to be expected from an EA version. Otherwise, it seems to be pretty stable already. All AspectJ tests except the JEP 406 ones are green. ___ 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.8.RC2 with Java 17 support
Dear AspectJ users, a few days ago we released 1.9.8.RC2. It fixes an upstream Eclipse Compiler bug. See AspectJ GitHub issue #95 for more information and for en example project showing how to upgrade to the latest AspectJ version when using dev.aspectj:aspectj-maven-plugin:1.13.1. To everyone: Please test it in as many projects as possible. Your feedback is welcome. Enjoy AspectJ! -- The AspectJ team Alexander Kriegisch schrieb am 11.10.2021 12:10 (GMT +02:00): a couple of days ago we published the first release candidate for AspectJ 1.9.8 on Maven Central. If there are no blocker bugs, 1.9.8.RC1 might very well be identical to the final 1.9.8 release. What is new since 1.9.7: Cross-compilation via --release N now works as expected, see GitHub issue #70. This was never tested before since AspectJ 1.9.0 and has been fixed in 1.9.8.M1. Java 17 is now supported as a compilation source and target version. Compared to the previously released developer version, we integrated the final Java 17 support from ECJ on top of JDT Core 3.27. Due to upstream ECJ changes, now for compile-time or binary weaving you need to run the AJC compiler on JDK 11+. 1.9.8.M1 was the last version running on JDK 8. Preliminary release notes are here. The corresponding installer is available on AspectJ.dev. Alexander Kriegisch schrieb am 28.07.2021 15:47 (GMT +02:00): the AspectJ development team is pleased to announce that a few days ago we released version 1.9.8.M1, available on Maven Central. The new feature compared to 1.9.7 is that cross-compilation via --release N now works as expected, see GitHub issue #70. This was never tested before since AspectJ 1.9.0 and has been fixed. This little milestone release still supports up to JDK 16, no changes there. Additionally, we have started integrating Java 17 early access releases by integrating the beta-17 Eclipse Java Compiler (ECJ) branch into a development branch. So if you use version 1.9.8-SNAPSHOT from Maven Central's snapshot repository as described in GitHub issue #79, you can compile Java 17 source code and create Java 17 class files. The compiler features go as far as the ECJ implementation has progressed so far. I noticed that the new preview feature JEP 406: Pattern Matching for switch in ECJ is not completely done yet, but that is to be expected from an EA version. Otherwise, it seems to be pretty stable already. All AspectJ tests except the JEP 406 ones are green. ___ 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 Maven Plugin 1.13.1 by AspectJ.dev
Dear AspectJ users,in sync with AspectJ 1.9.8.RC1 with Java 17 support, I have also released AspectJ Maven Plugin by AspectJ.dev in version 1.13.1. All important differences to the MojoHaus version are explained on the GitHub read-me page. As usual, you find the plugin on Maven Central. The most prominent new features in comparison to the previous version 1.13 are: The plugin now depends on AspectJ 1.9.8.RC1 by default, i.e. it fully supports Java 17 out of the box. This however requires you to run your Maven build on JDK 11+. If you wish to downgrade the AspectJ version and build on JDK 8, you can do so. The updated plugin overview and usage pages explain the background and how you can downgrade. There is no upper bounds check anymore for source and target versions. I.e., in the future you do not need to upgrade the plugin just because you wish to an AspectJ compiler version supporting more recent Java versions. No matter if Java 18, 25 or 78, as long as you do not need new plugin features you can stay at the same AspectJ Maven version. Enjoy building your AspectJ projects with Maven-- Alexander KriegischAspectJ.dev ___ 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] An internal error occurred during: "Computing additional info". org/eclipse/jdt/internal/core/hierarchy/HierarchyResolver$AjcClosure1
Mikael, I am hosting the aspectj.dev update site on my private shared hosting webspace, being the owner of the domain. I never experienced that problem you report and can download the file it complains about by clicking on the link. Sometimes I see GitHub CI builds fail due to temporary glitches in site availability when using dependencies hosted on aspectj.dev. It seems as if my ISP is not doing the very best job there. Can you just try again? I think that should suffice. Eclipse or AJDT should not access sites when running, only when updating. With regard to Eclipse support, I think the two add-ons discussed here should still work. They do for me, at least. As much as I love IntelliJ IDEA, they are also neglecting AspectJ, so it is not a perfect solution either. But it is working, also in connection with Maven. Syntax highlighting, intelli-sense and some native syntax features could use improvement, though. Also, IDEA sometimes complains about native AspectJ pointcut types used in Spring projects, because despite compiling and running the code just fine, the editor seems to assume that when using Spring, the AOP tool used is always Spring AOP, which only supports a subset of AspectJ features. I think, as long as your leading system is Maven and you use either the dev.aspectj variant of aspectj-maven-pluging - recommended with a bias, because I am maintaining it, but also because it has more features than the Mohjohaus version - or, if sufficient for you, the Mojohaus version, and Maven import in Eclipse and IDEA is still working, you should have no reason to despair or even give up on AspectJ. Cheers -- Alexander Kriegisch https://scrum-master.de Mikael Petterson schrieb am 10.09.2021 14:30 (GMT +02:00): > > Hi Alexander, > > Thanks for information. > Yes resources working with open-source is often a problem. This has been > an issue since we started to use aspectj ( very powerful tool) with our > project. > > > And it seems that without these two: > > > AJDT > m2e connector > > > aspectj will become rather useless in Eclipse ( not blaming you in > anyway). Do you have any advice if we stay with Eclipse. Maybe we need a > different approach on how to use it. Or leave Eclipse for IntelliJ IDEA > > We installed it successfully but got this when running ( see below > excerpt) . > > > Does it access sites when running? > > > br, > > > //mike > > > !ENTRY org.eclipse.equinox.p2.core 4 0 2021-09-10 13:53:54.077 > !MESSAGE Provisioning exception > !STACK 1 > org.eclipse.equinox.p2.core.ProvisionException: Artifact not found: > https://aspectj.dev/eclipse/ajdt/419/content.xml.xz. > at > org.eclipse.equinox.internal.p2.repository.CacheManager.updateCache(CacheManager.java:430) > at > org.eclipse.equinox.internal.p2.repository.CacheManager.createCacheFromFile(CacheManager.java:136) > at > org.eclipse.equinox.internal.p2.metadata.repository.XZedSimpleMetadataRepositoryFactory.getLocalFile(XZedSimpleMetadataRepositoryFactory.java:60) > at > org.eclipse.equinox.internal.p2.metadata.repository.XZedSimpleMetadataRepositoryFactory.load(XZedSimpleMetadataRepositoryFactory.java:80) > at > org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.factoryLoad(MetadataRepositoryManager.java:63) > at > org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:775) > at > org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:676) > at > org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:110) > at > org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:105) > at > org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.doLoad(LoadMetadataRepositoryJob.java:126) > at > org.eclipse.equinox.p2.ui.LoadMetadataRepositoryJob.runModal(LoadMetadataRepositoryJob.java:110) > at > org.eclipse.equinox.internal.p2.ui.sdk.PreloadingRepositoryHandler$1.runModal(PreloadingRepositoryHandler.java:84) > at > org.eclipse.equinox.p2.operations.ProvisioningJob.run(ProvisioningJob.java:190) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) > Caused by: java.io.FileNotFoundException: > https://aspectj.dev/eclipse/ajdt/419/content.xml.xz > at > org.eclipse.equinox.internal.p2.transport.ecf.RepositoryStatusHelper.checkFileNotFound(RepositoryStatusHelper.java:298) > at > org.eclipse.equinox.internal.p2.transport.ecf.FileReader.checkException(FileReader.java:509) > at > org.eclipse.equinox.internal.p2.transport.ecf.FileReader.sendRetrieveRequest(FileRe
[aspectj-users] AspectJ 1.9.8.M1 release and Java 17-EA developer version
Dear AspectJ users, the AspectJ development team is pleased to announce that a few days ago we released version 1.9.8.M1, available on Maven Central. The new feature compared to 1.9.7 is that cross-compilation via --release N now works as expected, see GitHub issue #70. This was never tested before since AspectJ 1.9.0 and has been fixed. This little milestone release still supports up to JDK 16, no changes there. Additionally, we have started integrating Java 17 early access releases by integrating the beta-17 Eclipse Java Compiler (ECJ) branch into a development branch. So if you use version 1.9.8-SNAPSHOT from Maven Central's snapshot repository as described in GitHub issue #79, you can compile Java 17 source code and create Java 17 class files. The compiler features go as far as the ECJ implementation has progressed so far. I noticed that the new preview feature JEP 406: Pattern Matching for switch in ECJ is not completely done yet, but that is to be expected from an EA version. Otherwise, it seems to be pretty stable already. All AspectJ tests except the JEP 406 ones are green. Enjoy Aspect! -- 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
[aspectj-users] AspectJ Maven Plugin (aspectj.dev fork) 1.13 released
Dear AspectJ users,I have just released a new version of this plugin: dev.aspectj aspectj-maven-plugin 1.13 It is already available on Maven Central and has a few improvements compared to the MojoHaus version, such as a few additional options, easier configuration due to improved language level precedence, Java 17-EA support (if you use a current AspectJ 1.9.8 snapshot). The full Maven documentation site is here.-- Alexander Kriegischhttps://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] AspectJ 1.9.7.M3 is available
Hello AspectJ users! This time with the correct subject and correct quoted message, sorry sending a wrong one before. We really do have two releases, one for AspecT and one for the Maven plugin. We are making progress, so I just published bugfix release 1.9.7.M3. There are no new features compared to M2 (see below), but one AJ doc (javadoc-like AspectJ API doc generation) glitch under JDK 8 was identified and fixed. This actually came up while setting up integration tests for AspectJ Maven plugin and is a positive side effect of developing, testing and releasing them together. Kind regards -- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch schrieb am 24.05.2021 11:38 (GMT +07:00): > AspectJ 1.9.7.M2 is available on Maven Central. > > It supports Java 15 and 16 language features, e.g. > -- records, > -- text blocks, > -- pattern matching for instanceof, > -- hidden classes, > -- sealed classes (preview). > > The available artifacts are: > > org.aspectj:aspectjtrt:1.9.7.M2 > org.aspectj:aspectjweaver:1.9.7.M2 > org.aspectj:aspectjtools:1.9.7.M2 > org.aspectj:aspectjmatcher:1.9.7.M2 > > You use them in Maven and Gradle as usual, e.g. > > > org.aspectj > aspectjtrt > 1.9.7.M2 > > > I deployed the installer in the aspectj.dev repository for now, because > we do not publish it on Maven Central. You can download it from: > https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/installer-1.9.7.M2.jar > > If you wish to verify checksums, you find them in the containing folder: > https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/ > > Soon I am also going to publish an AspectJ Maven Plugin version based on > this AspectJ milestone release and announce it here on the mailing list. > > We are not planning to add any major new features before the final > release, so the current functionality is pretty much what will go into > the release. But we still have time for fixing bugs, while Eclipse still > performs some internal reviews, so your feedback is most welcome. ___ 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 Maven Plugin 1.13.M3 is available
Hello AspectJ users! In lock-step with AspectJ 1.9.7.M3, I also just release AspectJ Maven plugin 1.13.M3. It depends on the new AspectJ milestone, including its AJdoc bugfix for JDK 8. See my previous message on this mailing list. Kind regards -- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch schrieb am 26.05.2021 13:38 (GMT +07:00): > AspectJ Maven Plugin 1.13.M2 is available on Maven Central. > > It depends on AspectJ 1.9.7.M2 by default, i.e. it supports Java 15 and > 16. If you need AspectJ support for those JDK versions, please upgrade > the plugin version. > > Please note that the group ID has changed to 'dev.aspectj'. This will > hopefully be the permanent home for AspectJ Maven. Sorry for the > inconvenience, but previous maintainers have abandoned the plugin > (including Mojohaus), so I had to use a new group ID. Otherwise, you use > the plugin just like before: > > > dev.aspectj > aspectj-maven-plugin > 1.13.M2 > ... > > > Because I also have started contributing to AspectJ a short while ago, I > am hoping to keep AspectJ Maven in sync with new AspectJ versions and > compiler features. > > I have not published a Maven site with plugin documentation yet, but on > https://github.com/dev-aspectj/aspectj-maven-plugin you find a link to > the old plugin documentation, also mention the few new features this > plugin version has, namely: > > --→ CLI option --module-path > -- → CLI option --enable-preview > > IntelliJ IDEA will support the new plugin ID in the next release, I > already talked to JetBrains. I have not inquired about how Eclipse IDE > identifies the plugin yet, so I am not sure if that will work out of the > box. But you are fine with Maven. > > Please note: this is not some shady new fork but a continuation of the > work of others (see also project history in the GitHub read-me) and the > new official Maven plugin for AspectJ - well, as official as it can be > as something not being a direct AspectJ sub-project. > > As soon as AspectJ 1.9.7 is out, I am also going to publish the final > release of AspectJ Maven. > > Bestt regards > -- > Alexander Kriegisch > > > Alexander Kriegisch schrieb am 24.05.2021 11:38 (GMT +07:00): > >> AspectJ 1.9.7.M2 is available on Maven Central. >> >> It supports Java 15 and 16 language features, e.g. >> -- records, >> -- text blocks, >> -- pattern matching for instanceof, >> -- hidden classes, >> -- sealed classes (preview). >> >> The available artifacts are: >> >> org.aspectj:aspectjtrt:1.9.7.M2 >> org.aspectj:aspectjweaver:1.9.7.M2 >> org.aspectj:aspectjtools:1.9.7.M2 >> org.aspectj:aspectjmatcher:1.9.7.M2 >> >> You use them in Maven and Gradle as usual, e.g. >> >> >> org.aspectj >> aspectjtrt >> 1.9.7.M2 >> >> >> I deployed the installer in the aspectj.dev repository for now, >> because we do not publish it on Maven Central. You can download it >> from: >> https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/installer-1.9.7.M2.jar >> >> If you wish to verify checksums, you find them in the containing >> folder: https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/ >> >> Soon I am also going to publish an AspectJ Maven Plugin version based >> on this AspectJ milestone release and announce it here on the mailing >> list. >> >> We are not planning to add any major new features before the final >> release, so the current functionality is pretty much what will go into >> the release. But we still have time for fixing bugs, while Eclipse >> still performs some internal reviews, so your feedback is most >> welcome. > ___ > 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 Maven Plugin 1.13.M3 is available
We are making progress, so I just published bugfix release 1.9.7.M3. There are no new features compared to M2 (see below), but one AJ doc (javadoc-like AspectJ API doc generation) glitch under JDK 8 was identified and fixed. This actually came up while setting up integration tests for AspectJ Maven plugin and is a positive side effect of developing, testing and releasing them together. Kind regards -- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch schrieb am 26.05.2021 13:38 (GMT +07:00): > Hello AspectJ users! > > AspectJ Maven Plugin 1.13.M2 is available on Maven Central. > > It depends on AspectJ 1.9.7.M2 by default, i.e. it supports Java 15 and > 16. If you need AspectJ support for those JDK versions, please upgrade > the plugin version. > > Please note that the group ID has changed to 'dev.aspectj'. This will > hopefully be the permanent home for AspectJ Maven. Sorry for the > inconvenience, but previous maintainers have abandoned the plugin > (including Mojohaus), so I had to use a new group ID. Otherwise, you use > the plugin just like before: > > > dev.aspectj > aspectj-maven-plugin > 1.13.M2 > ... > > > Because I also have started contributing to AspectJ a short while ago, I > am hoping to keep AspectJ Maven in sync with new AspectJ versions and > compiler features. > > I have not published a Maven site with plugin documentation yet, but on > https://github.com/dev-aspectj/aspectj-maven-plugin you find a link to > the old plugin documentation, also mention the few new features this > plugin version has, namely: > > --→ CLI option --module-path > -- → CLI option --enable-preview > > IntelliJ IDEA will support the new plugin ID in the next release, I > already talked to JetBrains. I have not inquired about how Eclipse IDE > identifies the plugin yet, so I am not sure if that will work out of the > box. But you are fine with Maven. > > Please note: this is not some shady new fork but a continuation of the > work of others (see also project history in the GitHub read-me) and the > new official Maven plugin for AspectJ - well, as official as it can be > as something not being a direct AspectJ sub-project. > > As soon as AspectJ 1.9.7 is out, I am also going to publish the final > release of AspectJ Maven. > > Bestt regards > -- > Alexander Kriegisch > > > Alexander Kriegisch schrieb am 24.05.2021 11:38 (GMT +07:00): > >> AspectJ 1.9.7.M2 is available on Maven Central. >> >> It supports Java 15 and 16 language features, e.g. >> -- records, >> -- text blocks, >> -- pattern matching for instanceof, >> -- hidden classes, >> -- sealed classes (preview). >> >> The available artifacts are: >> >> org.aspectj:aspectjtrt:1.9.7.M2 >> org.aspectj:aspectjweaver:1.9.7.M2 >> org.aspectj:aspectjtools:1.9.7.M2 >> org.aspectj:aspectjmatcher:1.9.7.M2 >> >> You use them in Maven and Gradle as usual, e.g. >> >> >> org.aspectj >> aspectjtrt >> 1.9.7.M2 >> >> >> I deployed the installer in the aspectj.dev repository for now, >> because we do not publish it on Maven Central. You can download it >> from: >> https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/installer-1.9.7.M2.jar >> >> If you wish to verify checksums, you find them in the containing >> folder: https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/ >> >> Soon I am also going to publish an AspectJ Maven Plugin version based >> on this AspectJ milestone release and announce it here on the mailing >> list. >> >> We are not planning to add any major new features before the final >> release, so the current functionality is pretty much what will go into >> the release. But we still have time for fixing bugs, while Eclipse >> still performs some internal reviews, so your feedback is most >> welcome. ___ 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 Maven Plugin 1.13.M2 is available
Hello AspectJ users! AspectJ Maven Plugin 1.13.M2 is available on Maven Central. It depends on AspectJ 1.9.7.M2 by default, i.e. it supports Java 15 and 16. If you need AspectJ support for those JDK versions, please upgrade the plugin version. Please note that the group ID has changed to 'dev.aspectj'. This will hopefully be the permanent home for AspectJ Maven. Sorry for the inconvenience, but previous maintainers have abandoned the plugin (including Mojohaus), so I had to use a new group ID. Otherwise, you use the plugin just like before: dev.aspectj aspectj-maven-plugin 1.13.M2 ... Because I also have started contributing to AspectJ a short while ago, I am hoping to keep AspectJ Maven in sync with new AspectJ versions and compiler features. I have not published a Maven site with plugin documentation yet, but on https://github.com/dev-aspectj/aspectj-maven-plugin you find a link to the old plugin documentation, also mention the few new features this plugin version has, namely: --→ CLI option --module-path -- → CLI option --enable-preview IntelliJ IDEA will support the new plugin ID in the next release, I already talked to JetBrains. I have not inquired about how Eclipse IDE identifies the plugin yet, so I am not sure if that will work out of the box. But you are fine with Maven. Please note: this is not some shady new fork but a continuation of the work of others (see also project history in the GitHub read-me) and the new official Maven plugin for AspectJ - well, as official as it can be as something not being a direct AspectJ sub-project. As soon as AspectJ 1.9.7 is out, I am also going to publish the final release of AspectJ Maven. Bestt regards -- Alexander Kriegisch Alexander Kriegisch schrieb am 24.05.2021 11:38 (GMT +07:00): > AspectJ 1.9.7.M2 is available on Maven Central. > > It supports Java 15 and 16 language features, e.g. > -- records, > -- text blocks, > -- pattern matching for instanceof, > -- hidden classes, > -- sealed classes (preview). > > The available artifacts are: > > org.aspectj:aspectjtrt:1.9.7.M2 > org.aspectj:aspectjweaver:1.9.7.M2 > org.aspectj:aspectjtools:1.9.7.M2 > org.aspectj:aspectjmatcher:1.9.7.M2 > > You use them in Maven and Gradle as usual, e.g. > > > org.aspectj > aspectjtrt > 1.9.7.M2 > > > I deployed the installer in the aspectj.dev repository for now, > because we do not publish it on Maven Central. You can download it > from: > https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/installer-1.9.7.M2.jar > > If you wish to verify checksums, you find them in the containing > folder: https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/ > > Soon I am also going to publish an AspectJ Maven Plugin version based > on this AspectJ milestone release and announce it here on the mailing > list. > > We are not planning to add any major new features before the final > release, so the current functionality is pretty much what will go into > the release. But we still have time for fixing bugs, while Eclipse > still performs some internal reviews, so your feedback is most > welcome. ___ 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.7.M2 is available
Hello AspectJ users! AspectJ 1.9.7.M2 is available on Maven Central. It supports Java 15 and 16 language features, e.g. -- records, -- text blocks, -- pattern matching for instanceof, -- hidden classes, -- sealed classes (preview). The available artifacts are: org.aspectj:aspectjtrt:1.9.7.M2 org.aspectj:aspectjweaver:1.9.7.M2 org.aspectj:aspectjtools:1.9.7.M2 org.aspectj:aspectjmatcher:1.9.7.M2 You use them in Maven and Gradle as usual, e.g. org.aspectj aspectjtrt 1.9.7.M2 I deployed the installer in the aspectj.dev repository for now, because we do not publish it on Maven Central. You can download it from: https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/installer-1.9.7.M2.jar If you wish to verify checksums, you find them in the containing folder: https://aspectj.dev/maven/org/aspectj/installer/1.9.7.M2/ Soon I am also going to publish an AspectJ Maven Plugin version based on this AspectJ milestone release and announce it here on the mailing list. We are not planning to add any major new features before the final release, so the current functionality is pretty much what will go into the release. But we still have time for fixing bugs, while Eclipse still performs some internal reviews, so your feedback is most welcome. Best regards -- Andrew Clement Alexander Kriegisch ___ 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 + AJDT + AspectJ Maven development versions for Java 16 available
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 >> 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
[aspectj-users] AspectJ + AJDT + AspectJ Maven development versions for Java 16 available
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
Re: [aspectj-users] Is AspectJ compatible with Java 15?
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 -- Alexander Kriegisch https://scrum-master.de Davide Perini schrieb am 05.02.2021 16:54 (GMT +07:00): > As title. > Do you know is AspectJ is compatible with Java 15? > > I am trying to use it in my standalone app without Spring, using Java 15 > but it seems > that IntelliJ want the "aspectjtools" jar to work and that jar only > supports Java 14. > > Am I doing something wrong? > > Can I use AspectJ with Java 15, Maven and IntelliJ? ___ 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
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] Java 9+ modules questions
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. -- 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] Limiting runtime type of target/this objects in pointcut
Hi Andy, hi community!
There is no easy way to specify a pointcut like "match all getters of base
class and all subclasses, but exclude instances of the base class". I mean
something like this (found similarly in a StackOverflow question):
package de.scrum_master.app;
public class Base {
private int id = 11;
public int getId() {
return id;
}
}
package de.scrum_master.app;
public class Sub extends Base {
private String name = "John Doe";
public String getName() {
return name;
}
public static void main(String[] args) {
new Base().getId();
new Sub().getId();
new Sub().getName();
}
}
package de.scrum_master.aspect;
import de.scrum_master.app.Base;
public aspect MyAspect {
before(Base base) : execution(* Base+.get*()) && this(base) {
if (base.getClass().equals(Base.class))
return;
System.out.println(thisJoinPoint);
System.out.println(" " + thisJoinPoint.getTarget());
}
}
Console log:
execution(int de.scrum_master.app.Base.getId())
de.scrum_master.app.Sub@6500df86
execution(String de.scrum_master.app.Sub.getName())
de.scrum_master.app.Sub@402a079c
I cannot use something like
target(Base+) && !target(Base)
because if this is of course mutually exclusive and a pointcut like that would
never match anything. This imaginary syntax
target(!Base && Base++)
also does not work because this/target need exact type names, not patterns. So
there does not seem to be a way around something like binding this/target and
if (base.getClass().equals(Base.class)) return;
Okay, I could factor the check out into an if() pointcut, but that is just
syntactic sugar and not applicable to Spring AOP, only to AspectJ.
The workaround to manually annotate either the base class or all subclasses and
in-/exclude based on such annotations is also not nice and not easily feasible
via ITD. The only way to pull this off would be to use AspectJ's annotation
processing feature, which again would not work in Spring AOP and would also be
a major obstacle for unexperienced AspectJ users.
Have I overlooked anything? If so, what? If not, do you think this kind of
feature would be a helpful addition to the AspectJ pointcut syntax?
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
Re: [aspectj-users] Please upvote compile-time weaving in kotlin
Hi Matthew. I would not expect JetBrains to do anything in that area anytime soon, as nice that would be. The did not even improve AspectJ support in IntelliJ IDEA for years, many open tickets there. Expecting them to write an AspectJ compiler for Kotlin might be a little bit too much. For the time being, did you try binary weaving on your already compiled Kotlin classes? I know it is not exactly what you want, but you said that missing AspectJ support is blocking your company's Kotlin adoption. How far did you get with binary weaving? Which concrete problems occurred, if any? Regards -- Alexander Kriegisch https://scrum-master.de Matthew Adams schrieb am 20.11.2020 03:00 (GMT +07:00): > Please go upvote https://youtrack.jetbrains.com/issue/KT-43476 if > you'd like to see compile-time support in kotlin. ___ 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
Hard to say without seeing the whole application. But as for 30 ms latency, maybe the aspect code inside your advice method takes as much already.
Did you measure and compare the complete advice method execution time to the time it takes to call execute proceed(), i.e. the original method call as such?
Did you measure how expensive the whole xxxStore and LoggerStore stuff is?
There is an if() in your pointcut. What does the method evaluating the condition do? You omitted it here. Maybe that is also part of what costs time.
Another question is if you really use AspectJ or just Spring AOP? I am just asking to be 100% sure because your second pointcut targets a Spring package.
What about the advice code for the other pointcut? Is it the same or different?
In your around advice you only seem to call proceed() exactly once as the very last instruction and return its result unfiltered. Have you considered to just use a simple before advice instead in this case?
-- Alexander Kriegischhttps://scrum-master.de
Rajendra Bhat schrieb am 30.09.2020 09:24 (GMT +07:00):
Hi Alexander,
Any suggestions on below shared aspect.. ..?
Regards,
Rajendra Bhat
On Mon, Sep 28, 2020 at 11:14 AM Rajendra Bhat <rajhalk...@gmail.com> wrote:
Hi Alexander,
Thanks for your quick response.
We have added the below aspect, I believe it should not cause not much latency.
@Pointcut("execution(* xx.xx.xx.xx.rest.customfilter.doFilter"
+ "(javax.servlet.ServletRequest,javax.servlet.ServletResponse,javax.servlet.FilterChain)) && args(request,response,filterChain) && if()")
We used "around" the advice. Advice logic as below.
HttpServletRequest req = (HttpServletRequest) request;
if (!req.getRequestURI().startsWith("/admin")) {
String shadowHeader = req.getHeader("XXX");
String rugsUuidHeader = req.getHeader("XXX");
if (logger.isDebugEnabled()) {
logger.debug(shadowHeader + "--" + req.getRequestURI());
}
if (!StringUtil.isEmpty(shadowHeader)) {
xxxStore.getInstance().addContext(new xxxContext(shadowHeader));
xxxLogStore.getInstance().initializeShadowLog(xxxStore.getInstance().getContext().getCorrelationId());
} else if (!StringUtil.isEmpty(rugsUuidHeader)) {
xxxStore.getInstance().addContext(rugsUuidHeader);
}
}
return (jointPoint.proceed());
And another aspect on @Pointcut("execution( * org.springframework.messaging.MessageChannel.send(org.springframework.messaging.Message,long)) . in
This also around advice, inside we are doing if condition and log4j logging.
Could please advise below aspect is causing 30 ms latency, something else we need to tune..?
Regards,
Rajendra Bhat
On Sat, Sep 26, 2020 at 5:43 AM Andy Clement <andrew.clem...@gmail.com> wrote:
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 <alexan...@kriegisch.name> wrote:
Hi Rajendra.Thanks for the question and the hep dump screenshot. Compile timeweaving (CTW) would not solve your latency problem. In comparison toload time weaving (LTW) you would only save time for class-loadingduring application start-up. After LTW is done, the application'sperformance should be the same as with CTW.Memory consumption and performance impact of AspectJ are stronglycorrelated with what your aspects do and how broadly they are applied tothe target classes. So I am afraid without seeing your aspect codenobody will be able to help you. The number of aspects, pointcuts andadvice is way less relevant than scope (pointcut) and content (advicemethod implementation) of the aspects as such. For example, a simpleadvice like this can be potentially super expensive:before() : call(* *(..)) { doSomeExpensiveLogging(); useSomeExpensiveExternalResource();}Why? Because it would globally apply to each method call in your wholeapplication. This would be just as slow as if without AOP you would addthose method calls to each place in your code before calling methods. Inmost cases it is not AspectJ as such which causes huge overhead (eventhough both the runtime and the weaver of course consume a fewresources, which usually is no problem, but what the aspect does and howmany times. Hence, the problem usually sits in front of the keyboard,even though it is of course possible that there is a memory leak orother problem in AspectJ.Bottom line: Please provide more information, especially full aspectcode. aop.xml would also be nice.Regards--Alexander Kriegischhttps://scrum-master.deRajendra Bhat schrieb am 25.09.2020 09:36 (GMT +07:00):> we observed around 10% latency overhead after addi
Re: [aspectj-users] high JVM consumption on springboot-aspectj LTW
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
Re: [aspectj-users] Proceeding with all arguments in native syntax
Hi Andy.
Your idea is more sophisticated and more powerful too, no doubt. Me
being a Scrum/Agile guy, I would rather prefer to have a way to bind all
arguments like I proposed in AJ soon than waiting for another couple of
years for the "grand scheme" implementation. The ticket you pointed to
is from 2008 and I know you don't have a lot of free cycles. So I guess
if your idea was easy to implement, you might have done so already. IMO
a small improvement now is better than a big one which never happens.
But of course, if you are ready to tackle the feature you just
suggested, it would be great too. :) Or maybe the two features are the
same order of magnitude with regard to complexity, even though that
would surprise me.
Cheers
--
Alexander Kriegisch
https://scrum-master.de
Andy Clement schrieb am 06.09.2020 01:07 (GMT +07:00):
>
>
> 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 <mailto:alexan...@kriegisch.name> > 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 thinki
Re: [aspectj-users] Proceeding with all arguments in native syntax
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] Proceeding with all arguments in native syntax
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
Re: [aspectj-users] AspectJ at Github
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 >> 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 >> <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
Re: [aspectj-users] AspectJ at Github
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
Re: [aspectj-users] AspectJ 1.9.6 (Java14) released
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
Re: [aspectj-users] Can I force around advice (especially for constructors) to be inlined?
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 Kriegischhttps://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 Kriegischhttps://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: Is there such an option? I did not find any obvious compiler switch. 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 <alexan...@kriegisch.name> 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
Re: [aspectj-users] Can I force around advice (especially for constructors) to be inlined?
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 Kriegischhttps://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:
Is there such an option? I did not find any obvious compiler switch.
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 <alexan...@kriegisch.name> 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.println("Constructing Sub -> " + this);this.name = name; } @Override public String toString() {return "Sub@" + this.hashCode() + " [name=" + name + ", id=" + id + "]"; }}
package de.scrum_master.app;public class AnotherSub extends Base{ private final String name; public AnotherSub(int id, String name) {super(id);System.out.println("Constructing AnotherSub -> " + this);this.name = name; } @Override public String toString() {return "AnotherSub@" + this.hashCode() + " [name=" + name + ", id=" + id + "]"; }}
package de.scrum_master.aspect;import de.scrum_master.app.Base;import de.scrum_master.app.Sub;public aspect ConstructorAspect { void around() : execution(Base+.new(..)) && target(Sub) {return; }}
package de.scrum_master.app;public class Application { public static void main(String[] args) {System.out.println(new Sub(11, "Xander"));System.out.println("--");System.out.println(new AnotherSub(22, "Someone")); }}
As you can see, I did the following:
Cre
[aspectj-users] Can I force around advice (especially for constructors) to be inlined?
Hi Andy.
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.println("Constructing Sub -> " + this);this.name = name; } @Override public String toString() {return "Sub@" + this.hashCode() + " [name=" + name + ", id=" + id + "]"; }}
package de.scrum_master.app;public class AnotherSub extends Base{ private final String name; public AnotherSub(int id, String name) {super(id);System.out.println("Constructing AnotherSub -> " + this);this.name = name; } @Override public String toString() {return "AnotherSub@" + this.hashCode() + " [name=" + name + ", id=" + id + "]"; }}
package de.scrum_master.aspect;import de.scrum_master.app.Base;import de.scrum_master.app.Sub;public aspect ConstructorAspect { void around() : execution(Base+.new(..)) && target(Sub) {return; }}
package de.scrum_master.app;public class Application { public static void main(String[] args) {System.out.println(new Sub(11, "Xander"));System.out.println("--");System.out.println(new AnotherSub(22, "Someone")); }}
As you can see, I did the following:
Create a base class Base with two subclasses Sub and AnotherSub.
The aspect tries to
suppress constructor execution for one Sub (with the intent to "mock" it, just imagine its methods get advised by additional behaviour),
but not for AnotherSub (not a mock target) of the subclasses.
The aspect does this by
making sure that super class constructors are also suppressed via execution(Base+.new(..)),
excluding anything that is not the target type via target(Sub) and finally
simply not proceeding to the constructor by just returning from the around advice.
Now this works beautifully whenever creating a Sub instance, but fails whenever creating an AnotherSub instance:
Sub@1211076369 [name=null, id=0]--Constructing Base -> AnotherSub@1551870003 [name=null, id=0]Exception in thread "main" java.lang.IllegalAccessError: Update to non-static final field de.scrum_master.app.Base.id attempted from a different method (init$_aroundBody0) than the initializer method at de.scrum_master.app.Base.init$_aroundBody0(Base.java:8)at de.scrum_master.app.Base.(Base.java:6)at de.scrum_master.app.AnotherSub.(AnotherSub.java:7)at de.scrum_master.app.Application.main(Application.java:7)
The explanation is pretty straightforward if we look at the console log and the class definitions:
The Base class has a final instance field.
AspectJ factors the Base constructor code out into a private helper method Base.init$_aroundBody0 and dispatches to it from the instrumented constructor Base. instead of initialising the field directly from there.
While this does no harm for the "mock target" class Sub because there the helper method is never called (the no-op around advice kicks),
it fails miserably when creating an AnotherSub instance because then the helper method does get called but a helper method must not violate the JVM rule that final fields can only be initialised directly from a constructor (or during declaration).
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:
Is there such an option? I did not find any obvious compiler switch.
If not, do you see any chance to implement it, given technical feasibility?
Best regards
-- Alexander Kriegischhttps://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
Re: [aspectj-users] Cannot access private field/method declared via ITD from target class
Ain't that a gotcha for someone who has used AspectJ for a few years and
thought he knew a little something about it? You never cease to amaze me
with your teachings, thank you so much. :-)
--
Alexander Kriegisch
https://scrum-master.de
Andrew Clement:
> From what I recall the visibility is expressed with respect to the
> aspect - so indeed the class can’t see it. I don’t *think* that
> used to work.
>
> This is from a time I think when we were more purist about aspects -
> and perhaps it is being a bit too strict these days - when what you
> really want to do is add a new private field to a type, you can’t.
> Perhaps there is another visibility to be expressed ‘private to the
> target and the aspect’ (private shared?).
>
>
>> Alexander Kriegisch:
>>
>> I might remember wrong, but I think this used to work at some point
>> in the past, or at least it should. But before I file a Bugzilla
>> ticket, I would like to have your opinion, Andy. Declaring something
>> like
>>
>> private int MyClass.myField = 0;
>>
>> private int Account.getMyField() {
>> return myField;
>> }
>>
>> basically works and the aspect itself can access the field and the
>> method. But the class they are declared on cannot and Ajc says:
>>
>> [error] The method getMyField() from the type MyClass is not visible
>>
>> For a full MCVE which you can just copy & paste and for my other
>> findings, please see my answer here:
>>
>> https://stackoverflow.com/a/61450184/1082681
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/aspectj-users
[aspectj-users] Is privileged aspect the default now? (was: Cannot access private field/method declared via ITD from target class)
On a side note: Whether I use a privileged aspect or not does not make
any difference. Besides, it never does seem to make any difference. Is
'privileged' the default now? It must have been for quite a while,
though.
--
Alexander Kriegisch
https://scrum-master.de
Alexander Kriegisch schrieb am 27.04.2020 08:10 (GMT +07:00):
> I might remember wrong, but I think this used to work at some point in
> the past, or at least it should. But before I file a Bugzilla ticket, I
> would like to have your opinion, Andy. Declaring something like
>
> private int MyClass.myField = 0;
>
> private int Account.getMyField() {
> return myField;
> }
>
> basically works and the aspect itself can access the field and the
> method. But the class they are declared on cannot and Ajc says:
>
> [error] The method getMyField() from the type MyClass is not visible
>
> For a full MCVE which you can just copy & paste and for my other
> findings, please see my answer here:
>
> https://stackoverflow.com/a/61450184/1082681
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/aspectj-users
[aspectj-users] Cannot access private field/method declared via ITD from target class
Hi Andy.
I might remember wrong, but I think this used to work at some point in
the past, or at least it should. But before I file a Bugzilla ticket, I
would like to have your opinion, Andy. Declaring something like
private int MyClass.myField = 0;
private int Account.getMyField() {
return myField;
}
basically works and the aspect itself can access the field and the
method. But the class they are declared on cannot and Ajc says:
[error] The method getMyField() from the type MyClass is not visible
For a full MCVE which you can just copy & paste and for my other
findings, please see my answer here:
https://stackoverflow.com/a/61450184/1082681
Kind 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
Re: [aspectj-users] LTW and JRE classes
Sorry Andy, I forgot to mention the recursive invocation problem when using the weaver as a system classloader. I tried to work around it by putting everything on 'aj.class.path' which made the exception go away but did not do anything with regard to aspect weaving. -- Alexander Kriegisch https://scrum-master.de Andy Clement: > Re: > -Djava.system.class.loader=org.aspectj.weaver.loadtime.WeavingURLClassLoader > > 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. > > > Alexander Kriegisch: > >> 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: >> >> > 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 k
Re: [aspectj-users] LTW and JRE classes
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: >>> >>> https://github.com/eclipse/org.aspectj/tree/master/tests/features160/weavingJavaxPackage >>> >>> I really need some help to get started here. >>> >>> >>> 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. >>>> >>>> >>>> Alexander Kriegisch: >>>> >>>>> The AspectJ documentation
Re: [aspectj-users] LTW and JRE classes
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'". -- Alexander Kriegisch https://scrum-master.de 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: >> >> https://github.com/eclipse/org.aspectj/tree/master/tests/features160/weavingJavaxPackage >> >> I really need some help to get started here. >> >> >> 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. >>> >>> >>> Alexander Kriegisch: >>> >>>> 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? ___ 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
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] LTW and JRE classes
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
Re: [aspectj-users] Trying to weave but get error
Martin Gainty schrieb am 20.03.2020 18:36 (GMT +07:00):
> be careful including artifacts from untested repositories..see below
This is available on Maven Central. Furthermore, it is open source and as I
said, the fork was created because the original plugin was not maintained for a
very long time. Both Nick and I contacted the Mojohaus people and asked them to
review and accept the pull request, then publish a new upstream release - so
far without any effect. For the last few years this 'nickwongdev' fork has been
the only clean way to work with AspectJ in Maven with Java versions 9+. So
please gather some information next time before irritating other people with
unspecific warning messages. Thank you.
--
Alexander Kriegisch
https://scrum-master.de
> From: aspectj-users-boun...@eclipse.org
> on behalf of Mikael Petterson
>
> Sent: Friday, March 20, 2020 3:04 AM
> To: aspectj-users@eclipse.org
> Subject: Re: [aspectj-users] Trying to weave but get error
>
>
> Hi,
>
>
> I replaced mojohaus version with
>
>
> com.nickwongdev
>
> aspectj-maven-plugin
>
> ${aspectj.maven.plugin.version}
>
>
> and these versions:
>
>
> 1.12.6
> 1.9.5
>
>
> Still the same problem.
>
>
> Two questions comes to my mind:
>
>
> I my multi-module project is it possible to exclude the failing module?
> Today I have added settings for aspectj in parent pom.xml
>
> MG>if you only have one artifact to exclude try
> MG>--projects '!module-to-exclude'
>
> If it is a classpath problem how could it have been working before I
> introduced aspectj? Would it not be possible to add generated classes to
> classpath for aspectj?
>
>
> MG> yes using directory parameter within configuration by executing
> build-helper-maven-plugin
>
> org.codehaus.mojo
> build-helper-maven-plugin
> 1.12
>
>
> add-test-resource
> generate-test-sources
>
> add-test-resource
>
>
>
>
> path/to/additional/test/resources
>
> **/folder-to-exclude/**
> MG>
> MG>hth MG>Martin
>
>
> //mike
>
>
>
>
> Från: aspectj-users-boun...@eclipse.org
> för Alexander Kriegisch
>
> Skickat: den 19 mars 2020 07:37
> Till: aspectj-users@eclipse.org
> Ämne: Re: [aspectj-users] Trying to weave but get error
>
>
> >>> The version of aspectj-maven-plugin is for jdk 11 support. It was
> >>> urgent at the time.
>
> >
> https://github.com/mojohaus/aspectj-maven-plugin/commit/c4164ff
>
> No, this commit was about Java 9/10 support.
>
> >> -- AspectJ version
>
> > [Mikael] 1.9.1
>
> That release also was about Java 10 support:
> https://www.eclipse.org/aspectj/doc/released/README-191.html
>
> Java 11 support came one release later:
> https://www.eclipse.org/aspectj/doc/released/README-192.html
>
> 1.9.3 was Java 12, 1.9.4 had a couple of important bugfixes, 1.9.5
> supports Java 13.
>
> My recommendation is to use this fork:
> https://mvnrepository.com/artifact/com.nickwongdev/aspectj-maven-plugin/1.12.6
>
> It should support AspectJ 1.9.5 (please also upgrade) and up to Java 13.
> The Mojohaus maintainer knows about it and got a pull request. IntelliJ
> IDEA's new 2020.x version will support it too for importing AspectJ
> projects.
>
> > ...\InjectedFunctionForRegressionChecker.java:6:0::0
> > The import ...RegressionSetInjectableFunctionAction cannot be resolved
>
> This rather seems to be some kind of classpath problem, maybe not even
> directly related to AspectJ, but impossible to say for sure without the
> MCVE.
>
>
> --
> 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] Trying to weave but get error
Mikael,
I hope you understand that I want to stop speculating until I have an MCVE
reproducing the problem.
Regards
--
Alexander Kriegisch
https://scrum-master.de
Mikael Petterson schrieb am 20.03.2020 14:04 (GMT +07:00):
>
> Hi,
>
>
> I replaced mojohaus version with
>
>
> com.nickwongdev
>
> aspectj-maven-plugin
>
> ${aspectj.maven.plugin.version}
>
>
> and these versions:
>
>
> 1.12.6
> 1.9.5
>
>
> Still the same problem.
>
>
> Two questions comes to my mind:
>
>
> I my multi-module project is it possible to exclude the failing module?
> Today I have added settings for aspectj in parent pom.xml
> If it is a classpath problem how could it have been working before I
> introduced aspectj? Would it not be possible to add generated classes to
> classpath for aspectj?
>
>
> br,
>
>
> //mike
>
>
>
>
> Från: aspectj-users-boun...@eclipse.org
> för Alexander Kriegisch
>
> Skickat: den 19 mars 2020 07:37
> Till: aspectj-users@eclipse.org
> Ämne: Re: [aspectj-users] Trying to weave but get error
>
>
> >>> The version of aspectj-maven-plugin is for jdk 11 support. It was
> >>> urgent at the time.
>
> >
> https://github.com/mojohaus/aspectj-maven-plugin/commit/c4164ff
>
> No, this commit was about Java 9/10 support.
>
> >> -- AspectJ version
>
> > [Mikael] 1.9.1
>
> That release also was about Java 10 support:
> https://www.eclipse.org/aspectj/doc/released/README-191.html
>
> Java 11 support came one release later:
> https://www.eclipse.org/aspectj/doc/released/README-192.html
>
> 1.9.3 was Java 12, 1.9.4 had a couple of important bugfixes, 1.9.5
> supports Java 13.
>
> My recommendation is to use this fork:
> https://mvnrepository.com/artifact/com.nickwongdev/aspectj-maven-plugin/1.12.6
>
> It should support AspectJ 1.9.5 (please also upgrade) and up to Java 13.
> The Mojohaus maintainer knows about it and got a pull request. IntelliJ
> IDEA's new 2020.x version will support it too for importing AspectJ
> projects.
>
> > ...\InjectedFunctionForRegressionChecker.java:6:0::0
> > The import ...RegressionSetInjectableFunctionAction cannot be resolved
>
> This rather seems to be some kind of classpath problem, maybe not even
> directly related to AspectJ, but impossible to say for sure without the
> MCVE.
>
>
> --
> 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] Trying to weave but get error
>>> The version of aspectj-maven-plugin is for jdk 11 support. It was >>> urgent at the time. > https://github.com/mojohaus/aspectj-maven-plugin/commit/c4164ff No, this commit was about Java 9/10 support. >> -- AspectJ version > [Mikael] 1.9.1 That release also was about Java 10 support: https://www.eclipse.org/aspectj/doc/released/README-191.html Java 11 support came one release later: https://www.eclipse.org/aspectj/doc/released/README-192.html 1.9.3 was Java 12, 1.9.4 had a couple of important bugfixes, 1.9.5 supports Java 13. My recommendation is to use this fork: https://mvnrepository.com/artifact/com.nickwongdev/aspectj-maven-plugin/1.12.6 It should support AspectJ 1.9.5 (please also upgrade) and up to Java 13. The Mojohaus maintainer knows about it and got a pull request. IntelliJ IDEA's new 2020.x version will support it too for importing AspectJ projects. > ...\InjectedFunctionForRegressionChecker.java:6:0::0 > The import ...RegressionSetInjectableFunctionAction cannot be resolved This rather seems to be some kind of classpath problem, maybe not even directly related to AspectJ, but impossible to say for sure without the MCVE. -- 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
Re: [aspectj-users] Trying to weave but get error
> I wish it was that easy. We have 24 modules in a maven multi-module > project. I was not implying for you to expose your full project but to condense it into an MCVE [1] reproducing the problem because there are many things I don't know such as: -- Java version -- AspectJ version -- AspectJ Maven version and what exactly was changed in your (or someone else's) fork. There is one semi official fork I also use for Java 9+ AspectJ projects, but I have no idea if you are using that one or not. -- Is the error an AspectJ problem as it seems from the stack trace or maybe related to the Maven plugin? -- Which source file(s) does it fail to compile or weave? -- Do you use compile-time or binary weaving? And several others. So please provide an MCVE. It could be as simple as a source file reproducing the error when compiled manually by ajc (AspectJ compiler) or a small Maven project. Whether the project also contains the source code generation step or you just copy some generated files into the project is not so important as long as the problem is **reproducible**. [1] https://stackoverflow.com/help/mcve > I guess I need to make sure the generated sources are compiled before > ajc. Actually no, that should not be necessary. Ajc is a full drop-in replacement for Javac. Regards -- Alexander Kriegisch https://scrum-master.de Mikael Petterson schrieb am 18.03.2020 21:29 (GMT +07:00): > > Hi, > > > I wish it was that easy. We have 24 modules in a maven multi-module > project. > > > One module has java template classes and then in another module, > module-actions, we generate java code from these templates: > > > [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ module-actions > ---^M > > [INFO] Deleting C:\Users\me\git\prod\module-actions\target^M > > [INFO] ^M > > [INFO] --- build-helper-maven-plugin:3.0.0:add-source (add-source) @ > module-actions ---^M > > [INFO] Source directory: > C:\Users\me\git\prod\module-actions\target\generated-sources\annotations > added.^M > > [INFO] ^M > > [INFO] --- aspectj-maven-plugin:1.11.1-FORK:compile (compile_with_aspectj) > @ module-actions ---^M > > > The version of aspectj-maven-plugin is for jdk 11 support. It was urgent > at the time. > > > I guess I need to make sure the generated sources are compiled before ajc. > > > br, > > > //mike > > > > > Från: aspectj-users-boun...@eclipse.org > för Alexander Kriegisch > > Skickat: den 18 mars 2020 12:36 > Till: aspectj-users@eclipse.org > Ämne: Re: [aspectj-users] Trying to weave but get error > > > Hi Mikael. > > How about a reproducible POM + Java + AspectJ project, maybe on GitHub? > > I also don't know what kind of fork you are using: > > > aspectj-maven-plugin:1.11.1-FORK > > Thanks for an update with more info. :-) > -- > Alexander Kriegisch > https://scrum-master.de > > > Mikael Petterson schrieb am 18.03.2020 19:27 (GMT +07:00): > > > > Hi, > > > > > > We are trying to compile to compile a project ajc and get: > > > > > > Failed to execute goal > > org.codehaus.mojo:aspectj-maven-plugin:1.11.1-FORK:compile > > (compile_with_aspectj) on project msran-jcat-extension-actions: AJC > > compiler errors: > > > > [ERROR] error Unexpected error during ACG processing: > > java.lang.NullPointerException > > > > > > I know you are not maintainer of aspectj-maven-plugin but since you are > > more familiar with the core I wonder if you have any ideas? > > > > > > br, > > > > > > //mike > > > > > > Here is the more details of stacktrace: > > > > > > java.lang.NullPointerException > > > > > > at > > > org.aspectj.org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.sourceStart(SourceTypeBinding.java:2472) > > > > > > at > > > org.aspectj.org.eclipse.jdt.internal.compiler.lookup.MethodBinding.sourceStart(MethodBinding.java:1331) > > > > > > at > > > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.TypeElementImpl$SourceLocationComparator.determineSourceStart(TypeElementImpl.java:98) > > > > > > at > > > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.TypeElementImpl$SourceLocationComparator.getSourceStart(TypeElementImpl.java:71) > > > > > > at > > > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.TypeElementImpl$SourceLocationComparator.compare(TypeElementImpl.java:64) > > > > > > at > > > org.aspectj
Re: [aspectj-users] Trying to weave but get error
Hi Mikael. How about a reproducible POM + Java + AspectJ project, maybe on GitHub? I also don't know what kind of fork you are using: > aspectj-maven-plugin:1.11.1-FORK Thanks for an update with more info. :-) -- Alexander Kriegisch https://scrum-master.de Mikael Petterson schrieb am 18.03.2020 19:27 (GMT +07:00): > > Hi, > > > We are trying to compile to compile a project ajc and get: > > > Failed to execute goal > org.codehaus.mojo:aspectj-maven-plugin:1.11.1-FORK:compile > (compile_with_aspectj) on project msran-jcat-extension-actions: AJC > compiler errors: > > [ERROR] error Unexpected error during ACG processing: > java.lang.NullPointerException > > > I know you are not maintainer of aspectj-maven-plugin but since you are > more familiar with the core I wonder if you have any ideas? > > > br, > > > //mike > > > Here is the more details of stacktrace: > > > java.lang.NullPointerException > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.sourceStart(SourceTypeBinding.java:2472) > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.lookup.MethodBinding.sourceStart(MethodBinding.java:1331) > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.TypeElementImpl$SourceLocationComparator.determineSourceStart(TypeElementImpl.java:98) > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.TypeElementImpl$SourceLocationComparator.getSourceStart(TypeElementImpl.java:71) > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.TypeElementImpl$SourceLocationComparator.compare(TypeElementImpl.java:64) > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.TypeElementImpl$SourceLocationComparator.compare(TypeElementImpl.java:1) > > > at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355) > > > at java.util.TimSort.sort(TimSort.java:220) > > > at java.util.Arrays.sort(Arrays.java:1512) > > > at java.util.ArrayList.sort(ArrayList.java:1462) > > > at java.util.Collections.sort(Collections.java:175) > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.TypeElementImpl.getEnclosedElements(TypeElementImpl.java:165) > > > at > com.ericsson.msran.generator.util.ElementUtil.getEnumValues(ElementUtil.java:566) > > > at > com.ericsson.msran.generator.check.ActionAttributeCodingRules$3.check(ActionAttributeCodingRules.java:89) > > > at > com.ericsson.msran.generator.check.ActionAttributeCodingRules$3.check(ActionAttributeCodingRules.java:1) > > > at > com.ericsson.msran.generator.check.CodingRule.doCheck(CodingRule.java:70) > > > at > com.ericsson.msran.generator.check.CodingRuleExecutor$1.check(CodingRuleExecutor.java:39) > > > at > com.ericsson.msran.generator.check.CodingRuleScanner.visitVariable(CodingRuleScanner.java:35) > > > at > com.ericsson.msran.generator.check.CodingRuleScanner.visitVariable(CodingRuleScanner.java:1) > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.VariableElementImpl.accept(VariableElementImpl.java:57) > > > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:146) > > > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:133) > > > at > javax.lang.model.util.ElementScanner6.visitType(ElementScanner6.java:178) > > > at > com.ericsson.msran.generator.check.CodingRuleScanner.visitType(CodingRuleScanner.java:29) > > > at > com.ericsson.msran.generator.check.CodingRuleScanner.visitType(CodingRuleScanner.java:1) > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.TypeElementImpl.accept(TypeElementImpl.java:136) > > > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:146) > > > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:133) > > > at > javax.lang.model.util.ElementScanner6.visitPackage(ElementScanner6.java:167) > > > at > org.aspectj.org.eclipse.jdt.internal.compiler.apt.model.PackageElementImpl.accept(PackageElementImpl.java:51) > > > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:146) > > > at javax.lang.model.util.ElementScanner6.scan(ElementScanner6.java:133) > > > at > com.ericsson.msran.generator.check.CodingRuleExecutor.checkAll(CodingRuleExecutor.java:46) > > > at > com.ericsson.msran.generator.ActionAnnotationProcessor.checkCodingRules(ActionAnnotationProcessor.java:228) > > > at > com.ericsson.msran.generator.ActionAnnotationProcessor.process(ActionAnnotationProcessor.java:149) > > > at > org.aspe
Re: [aspectj-users] Upgrade AspectJ Maven plugin to Java 11 (AspectJ 1.9.4)
Ping! -- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch schrieb am 05.06.2019 12:59 (GMT +07:00): > Hi Andy. > > Honestly, I didn't expect an answer from you. AFAIK you are not a committer in > that project, at least not according to GitHub. Also, I am not sure there is > much to sort out (other than code review) because there is a PR already: > > https://github.com/mojohaus/aspectj-maven-plugin/pull/45 > > It contains the changed/forked "nickwongdev" version. > > Best regards > -- > Alexander Kriegisch > https://scrum-master.de > > > Andy Clement schrieb am 05.06.2019 00:31: > >> 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! >> >> >> On Fri, 31 May 2019 at 21:44, Alexander Kriegisch >> >>> 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. :-) > > ___ > 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] @DeclareParents with 'defaultImpl' not working when used in an aspect library
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] How to use Spring AOP + AspectJ LTW combined in one application?
Hello community. Usually I am answering questions, not asking them. This one is an exception: https://stackoverflow.com/q/57899672/1082681 After one week without feedback on SO I decided to ask around here. Please note that there also is a sample project for you to clone and play around with, no need to start from zero. -- 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
Re: [aspectj-users] Getting the method arguments of a Pointcut using args
> Yes an allArgs designator would be nice to have which would simplify > the things. My workaround using the ThreadLocal is enough for now as > it would unblock the use case but it was also nice to know the > workaround only using AspectJ even though my code is in an application > using Spring framework and unfortunately Spring doesn’t support > percflow instantiation model. Well, you asked on the AspectJ mailing list, I had no idea it was about Spring AOP. But AspectJ can be used from within Spring instead of or in combination with Spring AOP, as described in this Spring manual chapter: https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-using-aspectj > Regarding the designator I haven’t created any issue on Bugzilla and > let the decision to be made by Andy Clement about the issue and its > priority :) Well, if you don't create the ticket it will surely be forgotten. If you do create it, it will still be Andy to decide about it. But obviously it is not so important for you because workarounds do exist in both AspectJ and Spring AOP, even though they involve manual bookkeeping. So we can close this issue. It was a nice discussion, talk to you next time. -- 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
Re: [aspectj-users] Getting the method arguments of a Pointcut using args
What you are implementing is called a wormhole pattern, only in your case you want to generalise it with respect to the caller arguments. For that you would need a hypothetical pointcut designator allArgs(myParameter) which does not exist and which would bind the whole Object[] as produced by Pointcut.getArgs() to a pointcut or advice parameter with a corresponding type. I admit it would be nice to have. If you believe you need it and cannot live with a workaround, feel free to create a Bugzilla ticket for it for future consideration. I cannot speak for Andy Clement, so I have no idea if he would consider implementing it or if he even has free cycles to do so.
As you said, you could use a singleton aspect with ThreadLocal variable in order to achieve what you want. As an alternative, I want to show you how you can do it with percflow instantiation. Which alternative you choose will depend on how many aspect instances would have to be created in your case and if that would become a problem or not. I recommend to just give it a try:
package de.scrum_master.aspect;import org.aspectj.lang.JoinPoint;import org.aspectj.lang.ProceedingJoinPoint;import org.aspectj.lang.annotation.Around;import org.aspectj.lang.annotation.Aspect;import org.aspectj.lang.annotation.Before;import de.scrum_master.app.CallerAnnotation;@Aspect("percflow(execution(* *(..)) && @annotation(de.scrum_master.app.CallerAnnotation))")public class AnotherAspect { private CallerAnnotation callerAnnotation; private Object[] callerArgs; @Before("execution(* *(..)) && @annotation(callerAnnotation)") public void executeCaller(JoinPoint joinPoint, CallerAnnotation callerAnnotation) {this.callerAnnotation = callerAnnotation;callerArgs = joinPoint.getArgs(); } @Around("execution(public void callee(String, Integer))") public Object executeCallee(ProceedingJoinPoint joinPoint) throws Throwable {System.out.println(joinPoint);System.out.println(" Caller annotation: " + callerAnnotation);System.out.println(" Caller arguments:");for (Object arg : callerArgs) System.out.println("" + arg);System.out.println(" Callee arguments:");for (Object arg : joinPoint.getArgs()) System.out.println("" + arg);return joinPoint.proceed(); }}
The console log for my previously posted sample code if you only replace the aspect:
execution(void de.scrum_master.app.SampleClazz.callee(String, Integer)) Caller annotation: @de.scrum_master.app.CallerAnnotation(value="xyz") Caller arguments:de.scrum_master.app.Foo@527740a2de.scrum_master.app.Bar@13a5fe33 Callee arguments:x11execution(void de.scrum_master.app.SampleClazz.callee(String, Integer)) Caller annotation: @de.scrum_master.app.CallerAnnotation(value="abc") Caller arguments:22 Callee arguments:y22
Kind regards-- Alexander Kriegischhttps://scrum-master.de
Sina Golesorkhi schrieb am 07.09.2019 19:31:
Hi Alexander,
Thanks for response. Please find my comments below.
On Sep 5, 2019, at 5:30 AM, Alexander Kriegisch <alexan...@kriegisch.name> wrote:
Hi Sina.
Your request sounds a bit like ordering Mousse au Chocolat without chocolate in a restaurant.
Interesting metaphor but I don’t see it being the case here :)
Your advice has two very specific Foo and Bar parameters, but the corresponding pointcut should not bind them to method parameters. Where else would they come from then? What is the problem anyway? Please give me a reason for wishing to avoid making the pointcut specific to the method signature, then maybe I can help you find a solution for your problem.
The idea is to be able to annotate a method to tag it so that you can define an Aspect in which you extract some information from the annotation and the annotated method, hence @CallerAnnotation * *(..)). The reason that I’m using * * (..) is because the I don’t want the Aspect to become aware of signature of the annotated method as this won’t scale if I’m going to use the annotation on top of different methods with different signatures.
If I have to bind the the Pointcut definition to a specific method signature then I’m losing the generalization that I get through the annotation. If I only had one PointCut and my final JoinPoint was the annotated method then I could have easily used the thisJoinPoint.getArgs() in order to get the method arguments but since I’m using cflowbelow and combining that Pointcut with another Pointcut to catch the JoinPoint of the callee() method I can only access the args() of the callee method but not the annotated method.
I’m afraid that this is not possible only using AspectJ. My expectation was to be able to get an Object[] which contains the arguments of the annotated method without the need to specify its signature.
One way that I can think of would be to have two different advices one for the ann
Re: [aspectj-users] Getting the method arguments of a Pointcut using args
Hi Sina.
Your request sounds a bit like ordering Mousse au Chocolat without chocolate in a restaurant. Your advice has two very specific Foo and Bar parameters, but the corresponding pointcut should not bind them to method parameters. Where else would they come from then? What is the problem anyway? Please give me a reason for wishing to avoid making the pointcut specific to the method signature, then maybe I can help you find a solution for your problem.
Just guessing you want to re-use the method execution pointcut for another advice, but this time more generically without specific parameters, you can just do it like this (full MCVE follows):
package de.scrum_master.app;public class Foo {}
package de.scrum_master.app;public class Bar {}
package de.scrum_master.app;import static java.lang.annotation.ElementType.METHOD;import static java.lang.annotation.RetentionPolicy.RUNTIME;import java.lang.annotation.Retention;import java.lang.annotation.Target;@Retention(RUNTIME)@Target(METHOD)public @interface CallerAnnotation { String value();}
package de.scrum_master.app;public class SampleClazz { @CallerAnnotation("xyz") public void caller(Foo foo, Bar bar) {callee("x", 11); } @CallerAnnotation("abc") public void anotherCaller(int number) {callee("y", number); } public void callee(String s, Integer i) {} public static void main(String[] args) {SampleClazz sampleClazz = new SampleClazz();sampleClazz.caller(new Foo(), new Bar());sampleClazz.anotherCaller(22); }}
package de.scrum_master.aspect;import org.aspectj.lang.JoinPoint;import org.aspectj.lang.ProceedingJoinPoint;import org.aspectj.lang.annotation.Around;import org.aspectj.lang.annotation.Aspect;import org.aspectj.lang.annotation.Before;import org.aspectj.lang.annotation.Pointcut;import de.scrum_master.app.Bar;import de.scrum_master.app.CallerAnnotation;import de.scrum_master.app.Foo;@Aspectpublic class MyAspect { @Pointcut("execution(* *(..)) && @annotation(callerAnnotation)") protected void executeAnnotation(CallerAnnotation callerAnnotation) {} @Pointcut("executeAnnotation(callerAnnotation) && args(foo, bar)") protected void executeAnnotationWithArgs(CallerAnnotation callerAnnotation, Foo foo, Bar bar) {} @Pointcut("cflowbelow(executeAnnotation(callerAnnotation))") protected void executeBelowAnnotation(CallerAnnotation callerAnnotation) {} @Pointcut("cflowbelow(executeAnnotationWithArgs(callerAnnotation, foo, bar))") protected void executeBelowAnnotationWithArgs(CallerAnnotation callerAnnotation, Foo foo, Bar bar) {} @Pointcut(value = "execution(public void callee(String, Integer))") protected void executeCallee() {} @Around("executeCallee() && executeBelowAnnotationWithArgs(callerAnnotation, foo, bar)") public Object finalAdvice(ProceedingJoinPoint joinPoint, CallerAnnotation callerAnnotation, Foo foo, Bar bar) throws Throwable {System.out.println("[finalAdvice] " + joinPoint);System.out.println(" " + callerAnnotation);System.out.println(" " + foo);System.out.println(" " + bar);return joinPoint.proceed(); } @Before("executeCallee() && executeBelowAnnotation(callerAnnotation)") public void anotherAdvice(JoinPoint joinPoint, CallerAnnotation callerAnnotation) throws Throwable {System.out.println("[anotherAdvice] " + joinPoint);System.out.println(" " + callerAnnotation); }}
See how executeAnnotation(callerAnnotation) is re-used? Maybe this is what you want, maybe not, I have no idea.
BTW, the console log looks like this:
[finalAdvice] execution(void de.scrum_master.app.SampleClazz.callee(String, Integer)) @de.scrum_master.app.CallerAnnotation(value="xyz") de.scrum_master.app.Foo@370736d9 de.scrum_master.app.Bar@5f9d02cb[anotherAdvice] execution(void de.scrum_master.app.SampleClazz.callee(String, Integer)) @de.scrum_master.app.CallerAnnotation(value="xyz")[anotherAdvice] execution(void de.scrum_master.app.SampleClazz.callee(String, Integer)) @de.scrum_master.app.CallerAnnotation(value="abc")
Regards-- Alexander Kriegischhttps://scrum-master.de
Sina Golesorkhi schrieb am 05.09.2019 01:45:
Hi there I have the following code sample
@Aspect
public class MyAspect {
@Pointcut("cflowbelow(execution(@CallerAnnotation * *(..)) && @annotation(callerAnnotation))")
protected void executeBelowAnnotation(final CallerAnnotation callerAnnotation) {
}
@Pointcut(value = "execution(public void callee(String, Integer))")
protected void executeCallee() {
}
@Around("executeCallee() && executeBelowAnnotation(callerAnnotation)")
public Object finalAdvice(final ProceedingJoinPoint joinPoint, final CallerAnnotation callerAnnotation)
throws Throwable {
return joinPoint.proceed();
}
}
public class SampleClazz() {
@CallerAnnotation("xyz")
public void caller(Foo foo, Bar bar){
this.callee();
}
private void callee(String s, Integer i){
// Do Something
}
}
and I would like to know
Re: [aspectj-users] Anyway to use AJ to _prevent_ field assignment at initialization of an object?
I just wanted to show how to use an around advice on field write access. Actually in your case it is simpler. Assuming the bogus constructor looks like this in my previous code:
public DefaultCacheResolverFactory() { System.out.println("DefaultCacheResolverFactory: no-args constructor"); throw new RuntimeException("oops!");}
You can just change the aspect to:
package de.scrum_master.aspect;import de.scrum_master.app.CacheManager;import de.scrum_master.app.DefaultCacheResolverFactory;public aspect CacheResolverFactoryReplacer { DefaultCacheResolverFactory around() : call(DefaultCacheResolverFactory.new()) {return new DefaultCacheResolverFactory(new CacheManager("aspect")); }}
-- Alexander Kriegischhttps://scrum-master.de
Eric B schrieb am 09.08.2019 19:42:
Thanks for the great example Alexander.
But to make you SSCCE example more inline with what is happening, the no-arg constructor for DefaultCacheResolverFactory should be throwing a runtime exception.
Consequently, just using a set() alone will still throw the exception since the no-arg cstor is still being called.
I can wrap the set() with a cflow() as you suggested and catch the exception, but in an ideal world, I would rather prevent the call to the no-arg cstor altogether.
So essentially, I would be looking at doing something like:
Around(cflow(initialization(CacheLookupUtil.new(..)) && call(DefaultCacheResolverFactory.new())){
return new DefaultCacheResolverFactory( new CacheManager();
}I haven't tried that yet, but I believe it should get me where I need to get.
Thanks,
Eric
On Thu, Aug 8, 2019, 9:48 PM Alexander Kriegisch <alexan...@kriegisch.name wrote:
I replicated your situation with dummy classes:
package de.scrum_master.app;public class InvocationContext {}
package de.scrum_master.app;public interface CacheResolverFactory { CacheManager getCacheManager();}
package de.scrum_master.app;public class DefaultCacheResolverFactory implements CacheResolverFactory { private CacheManager cacheManager = new CacheManager("default"); public DefaultCacheResolverFactory() {System.out.println("DefaultCacheResolverFactory: no-args constructor"); } public DefaultCacheResolverFactory(CacheManager cacheManager) {System.out.println("DefaultCacheResolverFactory: constructor with CacheManager");this.cacheManager = cacheManager; } @Override public CacheManager getCacheManager() {return cacheManager; }}
package de.scrum_master.app;public class CacheManager { private String name; public CacheManager(String name) {this.name = name; } @Override public String toString() {return "CacheManager [name=" + name + "]"; }}
package de.scrum_master.app;public abstract class AbstractCacheLookupUtil { public abstract void doSomething();}
package de.scrum_master.app;public class CacheLookupUtil extends AbstractCacheLookupUtil { private CacheResolverFactory defaultCacheResolverFactory = new DefaultCacheResolverFactory(); @Override public void doSomething() {System.out.println(defaultCacheResolverFactory.getCacheManager()); } public static void main(String[] args) {new CacheLookupUtil().doSomething(); }}
Now if you run that code, the console log says:
DefaultCacheResolverFactory: no-args constructorCacheManager [name=default]
No surprise here.
Now you can use LTW (load-time weaving) and a set() pointcut like this:
package de.scrum_master.aspect;import de.scrum_master.app.CacheResolverFactory;import de.scrum_master.app.DefaultCacheResolverFactory;import de.scrum_master.app.CacheLookupUtil;import de.scrum_master.app.CacheManager;public aspect CacheResolverFactoryReplacer { void around(CacheResolverFactory cacheResolverFactory) :set(CacheResolverFactory CacheLookupUtil.*) &&args(cacheResolverFactory) {proceed(new DefaultCacheResolverFactory(new CacheManager("aspect"))); }}
The console log changes to:
DefaultCacheResolverFactory: no-args constructorDefaultCacheResolverFactory: constructor with CacheManagerCacheManager [name=aspect]
Now as you can see, the no-args resolver factory constructor is still executed but the resulting object is no longer assigned to the member because the advice proceeds with the object you want to be assigned instead.
If you want to be very specific in your aspect and limit setting the member during constructor execution or object initialisation, you can always add && cflow(execution(CacheLookupUtil.new(..))) or && cflow(initialization(CacheLookupUtil.new(..))) to your pointcut.
--Alexander Kriegischhttps://scrum-master.de
Eric B schrieb am 08.08.2019 21:20:
I'm using the JCache API, in which a design decision made by the JSR-107 team in implementing the Reference Implementation is causing me a significant headache. The class in question is:
org.jsr107.ri.annotations.cdi.CacheLookupUtil from packa
Re: [aspectj-users] Anyway to use AJ to _prevent_ field assignment at initialization of an object?
I replicated your situation with dummy classes:
package de.scrum_master.app;public class InvocationContext {}
package de.scrum_master.app;public interface CacheResolverFactory { CacheManager getCacheManager();}
package de.scrum_master.app;public class DefaultCacheResolverFactory implements CacheResolverFactory { private CacheManager cacheManager = new CacheManager("default"); public DefaultCacheResolverFactory() {System.out.println("DefaultCacheResolverFactory: no-args constructor"); } public DefaultCacheResolverFactory(CacheManager cacheManager) {System.out.println("DefaultCacheResolverFactory: constructor with CacheManager");this.cacheManager = cacheManager; } @Override public CacheManager getCacheManager() {return cacheManager; }}
package de.scrum_master.app;public class CacheManager { private String name; public CacheManager(String name) {this.name = name; } @Override public String toString() {return "CacheManager [name=" + name + "]"; }}
package de.scrum_master.app;public abstract class AbstractCacheLookupUtil { public abstract void doSomething();}
package de.scrum_master.app;public class CacheLookupUtil extends AbstractCacheLookupUtil { private CacheResolverFactory defaultCacheResolverFactory = new DefaultCacheResolverFactory(); @Override public void doSomething() {System.out.println(defaultCacheResolverFactory.getCacheManager()); } public static void main(String[] args) {new CacheLookupUtil().doSomething(); }}
Now if you run that code, the console log says:
DefaultCacheResolverFactory: no-args constructorCacheManager [name=default]
No surprise here.
Now you can use LTW (load-time weaving) and a set() pointcut like this:
package de.scrum_master.aspect;import de.scrum_master.app.CacheResolverFactory;import de.scrum_master.app.DefaultCacheResolverFactory;import de.scrum_master.app.CacheLookupUtil;import de.scrum_master.app.CacheManager;public aspect CacheResolverFactoryReplacer { void around(CacheResolverFactory cacheResolverFactory) :set(CacheResolverFactory CacheLookupUtil.*) &&args(cacheResolverFactory) {proceed(new DefaultCacheResolverFactory(new CacheManager("aspect"))); }}
The console log changes to:
DefaultCacheResolverFactory: no-args constructorDefaultCacheResolverFactory: constructor with CacheManagerCacheManager [name=aspect]
Now as you can see, the no-args resolver factory constructor is still executed but the resulting object is no longer assigned to the member because the advice proceeds with the object you want to be assigned instead.
If you want to be very specific in your aspect and limit setting the member during constructor execution or object initialisation, you can always add && cflow(execution(CacheLookupUtil.new(..))) or && cflow(initialization(CacheLookupUtil.new(..))) to your pointcut.
-- Alexander Kriegischhttps://scrum-master.de
Eric B schrieb am 08.08.2019 21:20:
I'm using the JCache API, in which a design decision made by the JSR-107 team in implementing the Reference Implementation is causing me a significant headache. The class in question is:
org.jsr107.ri.annotations.cdi.CacheLookupUtil from package org.jsr107.ri:cache-annotations-ri-cdi:1.1.0.
This is the layout of the class:
public class CacheLookupUtil extends AbstractCacheLookupUtil { @Inject private BeanManagerUtil beanManagerUtil; private CacheKeyGenerator defaultCacheKeyGenerator = new DefaultCacheKeyGenerator(); private CacheResolverFactory defaultCacheResolverFactory = new DefaultCacheResolverFactory(); ...
...
}
My problem is the assignment of the defaultCacheResolverFactory, or to be even more specific the construction of the DefaultCacheResolverFactory() without arguments when initializing the object. The default constructor used throws an exception which is extremely difficult to catch given that the DI framework is instantiating the object.
Is there anyway I can use AspectJ to modify that assignment? Ideally, I would like to prevent the construction of the DefaultCacheResolverFactory with no args, and replace it with a call to new DefaultCacheResolverFactory(CacheManager) instead.
So my issue is not just being able to assign the field (which I would be able to do in a CacheLookupUtil constructor advice, but also prevent the construction of the DefaultCacheResolverFactory().
Can you think of any kind of pointcut(s) that I could use to catch that condition? I figure I need an Around advice against a pointcut which picks up the constructor of the DefaultCacheResolverFactory (so I can return my own object instead), but from what I understand I cannot use around with the initialization pointcut.
Any suggestions what I can try?
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://www.eclipse.org/mailman/listinfo/aspectj-users
Re: [aspectj-users] Upgrade AspectJ Maven plugin to Java 11 (AspectJ 1.9.4)
Hi Conrad, you should be fine to use the release 1.9.4 version of AspectJ, no need to use master unless there are some bleeding-edge changes you intend to use in your planned AspectJ compiler modification. FYI, Since 1.9.3 AspectJ already supports Java 12, Java 11 has been in longer still. Other than that I am not sure about the purpose of your post. I cannot detect any questions in there. Regards -- Alexander Kriegisch https://scrum-master.de Conrad Bell schrieb am 30.07.2019 01:40: > Hello Andy, Alexander: > > Your posts strike me as quite serendipitous. I am a PhD student in > Computer Science. Part of my research will involve modifications to > the AspectJ compiler. My goal is to work in a Java 11 environment, so > I just installed the latest eclipse, Java 11 SDK, and cloned AspectJ > master. I am still working through "xyz cannot be resolved to a > type" errors so maybe I’m not far along to hit this problem? I am > new to Maven, but if I can help then point me in the right direction. > That goes for any other tasks that need doing to get AspectJ to Java > 11. > > > Alexander Kriegisch: > >> Honestly, I didn't expect an answer from you. AFAIK you are not a >> committer in that project, at least not according to GitHub. Also, I >> am not sure there is much to sort out (other than code review) >> because there is a PR already: >> >> https://github.com/mojohaus/aspectj-maven-plugin/pull/45 >> >> It contains the changed/forked "nickwongdev" version. >> >> >> Andy Clement schrieb am 05.06.2019 00:31: >> >>> 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! >>> >>> >>> On Fri, 31 May 2019 at 21:44, Alexander Kriegisch >>>> >>>> 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. :-) ___ 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
FYI, I just added https://bugs.eclipse.org/bugs/show_bug.cgi?id=548448. It contains new findings about how to successfully create an output JAR via "Export..." menu as well as some open questions about AJDT options which don't seem to add any value/dunctionality to the default JDT ones. Please read and comment, even if implementation is low on your priority list. I really like to understand. Thank you. Cheers -- Alexander Kriegisch https://scrum-master.de 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! > > > Alexander Kriegisch: > >> 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. ___ 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] privileged aspects and Load-Time Weaving
You give up quickly and you think you know that AspectJ is not helpful even
though you haven't laid out the problem. Give it a try. As a developer you
should be able to explain the problem without disclosing company internals.
Maybe binary weaving would be a quick and easy solution for you if e.g. you
have binaries without source. But if you don't explain, probably we will never
know, will we? How can you hope for someone to help you solve a problem you
don't even fully explain? Good luck -- Alexander Kriegisch
Ursprüngliche Nachricht Von: REV Tamas
Datum: 18.06.19 15:42 (GMT+07:00) An: aspectj-users@eclipse.org Betreff: Re:
[aspectj-users] privileged aspects and Load-Time Weaving Hello,Thank you for
your detailed answer!I don't think I may explain our situation.All I can say is
that I'm looking for the least painful shortcut. Now I know that this is not
AspectJ.So I keep looking.Thanks,TamasOn Tue, Jun 18, 2019 at 3:57 AM Alexander
Kriegisch wrote:The problem is not privileged
access, you are rather dealing with a hen-and-egg type of problem here. Let's
imagine you want a setup like this:
Aspect library (to be used via LTW)
AspectPrivate
Application
ClassWithPrivate
TestPrivate
Now probably you don't want any dependencies between aspect library and
application, but
the aspect imports an application class,
the test program is trying to access methods unavailable during its compile
time,
thus the aspect library has a dependency on the application library and vice
versa.
Ergo: It simply does not make sense to use AspectJ's introduction feature (also
known as ITD or inter-type declaration) like this in an LTW scenario. In most
cases AOP is about adding cross-cutting behaviour and there you can work with
jokers like "*" or "..", i.e. you do not need to use precise class names. Even
if you do, the worst that could happen is an "advice does not match" warning
during compilation of the aspect library. It would still work during runtime
after aspect weaving. But member access and/or method introduction only work
with specific class names, so if you need that you should use compile-time
weaving. Think about it, you are not just decorating classes with behaviour
before or after existing methods, you are introducing new members or methods,
i.e. changing the class structure itself. This is to be done during compile
time.
So much for the technical part. I still think your question might be suffering
from the XY problem. Maybe you should rather explain what you want to achieve
and not how you think it should best be achieved. Ask yourself questions like:
Why would I want to access private class members in the first place?
What happens if I refactor the target class, e.g. rename a member? (In your
example the aspect would break and need to be refactored too.)
Why am I limited to LTW here? Or maybe I just think I am and there are other
possible solutions.
What is it I want to achieve? (Maybe your answer is: "I want to reduce
boiler-plate code and auto-generate getters and setters for all or some of my
beans." And maybe then you find out that you could do that via AspectJ's
annotation processing feature or by using another tool such as Lombok or by
using Groovy instead of Java or ...)
Kind regards-- Alexander Kriegisch
https://scrum-master.de
REV Tamas schrieb am 17.06.2019 18:35:
Hello,
I would like to use a privileged access and weave it at load-time.
I did not see anywhere that it was not possible to do so.
On the other hand, I could only make it work with compile-time weaving so far.
Could you please help me to make it work (or just tell me it is not possible)?
I was playing with this mock project:
https://stackoverflow.com/questions/10721037/aspectj-access-private-fields
Code excerpt:
public class ClassWithPrivate {
private String s = "myStr";
}
==
package com.example.aspect;
import com.example.ClassWithPrivate;
privileged public aspect AccessPrivate {
public String ClassWithPrivate.getS() {
return this.s;
}
public void ClassWithPrivate.setS(String str) {
this.s = str;
}
}
==
package com.example;
public class TestPrivate {
public static void main(String[] args) {
ClassWithPrivate test = new ClassWithPrivate();
System.out.println(test.getS());
test.setS("hello");
System.out.println(test.getS());
}
}
I installed ADT to eclipse and now I can see the aspect weaved into the
bytecode.I saw this when I decompiled the code:public class ClassWithPrivate{
public void setS(String paramString) {
AccessPrivate.ajc$interMethod$com_example_aspect_AccessPrivate$com_example_ClassWithPrivate$setS(this,
paramString); } public String getS() { return
AccessPrivate.ajc$interMethod$com_example_aspect_AccessPrivate$com_example_ClassWithPrivate$getS(this);
} private String
[aspectj-users] AJDT does not include aop.xml into output JAR
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
Re: [aspectj-users] privileged aspects and Load-Time Weaving
The problem is not privileged access, you are rather dealing with a hen-and-egg type of problem here. Let's imagine you want a setup like this:
Aspect library (to be used via LTW)
AspectPrivate
Application
ClassWithPrivate
TestPrivate
Now probably you don't want any dependencies between aspect library and application, but
the aspect imports an application class,
the test program is trying to access methods unavailable during its compile time,
thus the aspect library has a dependency on the application library and vice versa.
Ergo: It simply does not make sense to use AspectJ's introduction feature (also known as ITD or inter-type declaration) like this in an LTW scenario. In most cases AOP is about adding cross-cutting behaviour and there you can work with jokers like "*" or "..", i.e. you do not need to use precise class names. Even if you do, the worst that could happen is an "advice does not match" warning during compilation of the aspect library. It would still work during runtime after aspect weaving. But member access and/or method introduction only work with specific class names, so if you need that you should use compile-time weaving. Think about it, you are not just decorating classes with behaviour before or after existing methods, you are introducing new members or methods, i.e. changing the class structure itself. This is to be done during compile time.
So much for the technical part. I still think your question might be suffering from the XY problem. Maybe you should rather explain what you want to achieve and not how you think it should best be achieved. Ask yourself questions like:
Why would I want to access private class members in the first place?
What happens if I refactor the target class, e.g. rename a member? (In your example the aspect would break and need to be refactored too.)
Why am I limited to LTW here? Or maybe I just think I am and there are other possible solutions.
What is it I want to achieve? (Maybe your answer is: "I want to reduce boiler-plate code and auto-generate getters and setters for all or some of my beans." And maybe then you find out that you could do that via AspectJ's annotation processing feature or by using another tool such as Lombok or by using Groovy instead of Java or ...)
Kind regards-- Alexander Kriegisch
https://scrum-master.de
REV Tamas schrieb am 17.06.2019 18:35:
Hello,
I would like to use a privileged access and weave it at load-time.
I did not see anywhere that it was not possible to do so.
On the other hand, I could only make it work with compile-time weaving so far.
Could you please help me to make it work (or just tell me it is not possible)?
I was playing with this mock project: https://stackoverflow.com/questions/10721037/aspectj-access-private-fields
Code excerpt:
public class ClassWithPrivate {
private String s = "myStr";
}
==
package com.example.aspect;
import com.example.ClassWithPrivate;
privileged public aspect AccessPrivate {
public String ClassWithPrivate.getS() {
return this.s;
}
public void ClassWithPrivate.setS(String str) {
this.s = str;
}
}
==
package com.example;
public class TestPrivate {
public static void main(String[] args) {
ClassWithPrivate test = new ClassWithPrivate();
System.out.println(test.getS());
test.setS("hello");
System.out.println(test.getS());
}
}
I installed ADT to eclipse and now I can see the aspect weaved into the bytecode.I saw this when I decompiled the code:public class ClassWithPrivate{ public void setS(String paramString) { AccessPrivate.ajc$interMethod$com_example_aspect_AccessPrivate$com_example_ClassWithPrivate$setS(this, paramString); } public String getS() { return AccessPrivate.ajc$interMethod$com_example_aspect_AccessPrivate$com_example_ClassWithPrivate$getS(this); } private String s = "mystr";}
So here is the question: Is it possible to do it with load-time weaving?I disabled ADT, then I added the aspect to the aop.xml as I normally do. However,the class that tried to access the privileged methods, that gave a compile error.Thanks,Tamas
___
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)
Hi Andy. Honestly, I didn't expect an answer from you. AFAIK you are not a committer in that project, at least not according to GitHub. Also, I am not sure there is much to sort out (other than code review) because there is a PR already: https://github.com/mojohaus/aspectj-maven-plugin/pull/45 It contains the changed/forked "nickwongdev" version. Best regards -- Alexander Kriegisch https://scrum-master.de Andy Clement schrieb am 05.06.2019 00:31: > 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! > > > On Fri, 31 May 2019 at 21:44, Alexander Kriegisch > >> 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. :-) ___ 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] Upgrade AspectJ Maven plugin to Java 11 (AspectJ 1.9.4)
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
Re: [aspectj-users] 1.9.4 released
Maybe you are right and just the version numbers are off. Here are screenshots from the plugin info in my Eclipse installation. The time stamps in the version numbers (2019-05-10 20:27) indicate something newer than 1.9.2 but the version number is 1.9.2 or @AJVERSION@ which looks like some non-expanded placeholder. -- Alexander Kriegischhttps://scrum-master.de Andy Clement schrieb am 31.05.2019 22:49: 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 <alexan...@kriegisch.name> wrote: > http://download.eclipse.org/tools/ajdt/410/dev/updateSomehow in Eclipse 2018-12 the latest update is still based on AspectJ 1.9.2.--Alexander Kriegischhttps://scrum-master.deAndrew 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 listaspectj-users@eclipse.orgTo 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
Re: [aspectj-users] 1.9.4 released
> 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
Re: [aspectj-users] There is an AspectJ maven build configuration
Hi Andy.
Sorry for the late feedback and thank you for investing time there. I
just ran the latest master @370f291c ("1.9.3RC1 final bits") on my
Windows box and "mvn install" terminated successfully after ~29 minutes.
I also quickly looked into the installer JAR (without running it)and the
contents look as expected.
Great job! :-)
Cheers
--
Alexander Kriegisch
https://scrum-master.de
Andrew Clement schrieb am 05.03.2019 00:21:
> Just to add I’ve done some work on the maven build and for me it now runs
> clean on windows. I had to do a few things:
>
> - adjust some test expectations to allow for carriage returns
> - fix some tests involving / vs \ :)
> - most importantly there was a jar lock remaining in place and windows
> doesn’t like that (won’t let you delete the jar if someone has it locked)
> and this was affecting tests. I had to tweak part of AspectJ to make sure no
> lock left in place (I’d probably call this a real bug that is now fixed).
>
> cheers,
> Andy
>
>> On Feb 11, 2019, at 5:05 PM, Alexander Kriegisch
>> wrote:
>>
>> Great news, Andy, thank you so much. This weekend or the next I guess I
>> will take a look.
>>
>> One question, just in case: Would PRs against the GitHub repo be okay?
>>
>>
>> Regards
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>>
>> Andrew Clement schrieb am 12.02.2019 06:29:
>>
>>> It is alive. AspectJ, well overdue, now has as rudimentary maven
>>> build. It builds on the few systems I’ve tried it on although some
>>> of the tests seem to be a bit flaky on windows (I’ve not run the
>>> tests on windows for a long time so I don’t think it is due to the
>>> maven process, it just never used to be this easy to run them on a
>>> different OS). If anyone wants to help polish it, please do, I’m not
>>> a maven guru. There are some of the jar dependencies that need
>>> converting from local jar references to real dependencies from a
>>> repository but I haven’t had a chance to work out the exact version
>>> numbers. You can ‘mvn install’ and it will build
>>> aspectjrt/aspectjweaver/aspectjtools and then you can consume them
>>> from your local repo (although the poms need a bit of work). There is
>>> an installer project that builds the installer distribution we also
>>> make available. I’ve imported it into eclipse using m2e, I haven’t
>>> tried it with IntelliJ - I’d be interested to know if that works.
>>>
>>> If nothing else this may make it easier for folks to consume snapshot
>>> builds that include workarounds or early fixes as they can more easily
>>> build/install it locally now.
>>>
>>> If anyone wants to try it out, please do, raise bugs, contribute fixes
>>> :)
>>>
>>> There are extra benefits I snuck in:
>>> -- I deleted the projects ending in ‘5’ (created when Java5 was
>>> separate to Java 1.4) and merged them into the non 5 variants.
>>> -- bcel-builder is no longer a ’special project’ you had to
>>> build separately. It is just a regular sub-module
>>> -- If you do want to run the tests in eclipse, I added a few lines
>>> explanation in the new README at
>>> https://github.com/eclipse/org.aspectj
>>>
>>> I guess the true test of this will be when I try to use it to release
>>> 1.9.3 but as it produces the same artifacts, I should be able to use
>>> the same release process there.
>>
>> ___
>> 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 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] java agent: spring-instrument.jar vs aspectjweaver.jar
I am not a Spring expert, but as nobody else has answered so far, I will: In many cases it seems to actually make sense to activate both agents. Some applications do not even start correctly or do weaving correctly if not both agents are used, as my reply there on SO implies: https://stackoverflow.com/a/25723050/1082681 Sorry I cannot enlighten you more, but I hope this helps anyway. -- Alexander Kriegisch https://scrum-master.de Andrei Ivanov schrieb am 08.03.2019 18:45: > > > Hi, > What's the difference between using spring-instrument.jar as a java agent > vs aspectjweaver.jar? > > > My current experimentations indicate that spring-instrument.jar is > required by Spring to enable LTW, > > but that will happen at a later stage and some classes might already be > loaded by then and miss the LTW transformations, which bit me in one case > already. > > > Using aspectjweaver.jar seems to enable the class instrumentation from the > begining, but I can no longer use the AspectJWeaverMessageHandler > > provided by Spring as it's not yet visible in the main classloader, since > it's packaged in my web app and also Spring complains that the classloader > is missing > > some infrastructure provided by spring-instrument.jar, which makes me > think that I maybe could use both java agents. > > Or maybe in this case I shouldn't enable LTW in the Spring configuration > at all? > > > Thank you > ___ 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] AspectJ third-party class is not weaved in weblogic
> First, it's not possible to upload code to git as full deployment is > very complex. That is incorrect. It **is** possible, it might just be somewhat difficult because you need to extract a simplified MCVE reproducing your problem from your code base. An MCVE is not your full application, by the way - did you follow the link and read what MCVE means? > I will try to play with classpath and see if it changes anything, If you prefer to **play** (trial & error) instead of someone else to help you **analyse** the situation, be my guest and do that. Just don't ask on a mailing list then because if you need answers, the community needs sufficient information first. No offense meant, I am just explaining a basic fact. > After additional weblogic log analyze, third party class loaded twice > (from different jars locations) , the first time is loaded from > weblogic's server/lib/consoleapp/APP-INF/lib, and it happens BEFORE > aop.xml is loaded. > > Can it be the reason? Absolutely. There is no way it could work if the weaving agent is loaded after the classes it should weave because the weaving agent itself hooks into the classloading mechanism and transforms the classes while they are being loaded. I hope you can find out how to fix the classloading. Good luck! -- 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
Re: [aspectj-users] AspectJ third-party class is not weaved in weblogic
Correction, see below: Alexander Kriegisch schrieb am 03.03.2019 10:11: Without an MCVE it is difficult to say anything definitive, but in general you seem to have one of two possible problems: Class visibility issues due to classloader isolation inside your container (application server): Maybe the two classloaders loading the aspect JAR and the WAR/EAR to be woven are isolated from each other. Class-loading order: Maybe your aspect JAR is loaded after the target classes have already been woven loaded. There might be other possible causes, I am by no means a container expert because I mainly work with Java SE and without application servers. I think you need to change your configuration in order to address this issue. What to do exactly is beyond my knowledge. Maybe Andy knows more. Maybe it would also help to push an MCVE to GitHub for everyone to reproduce to problem. -- Alexander Kriegisch https://scrum-master.de yev yev schrieb am 02.03.2019 16:19: I am trying to "Weave" a third-party jar with AspectJ using aspectj agent. First test case: MyAspectJImpl.jar - contains class with my aspect and aop.xml (with debug enabled)inside Meta-inf with correct mapping, and a test main class. third-party.jar aspectJ core jars. I execute main class in commandline java -javaagent:aspectjweaver.jar -cp ... on console see that that third party class was weaved, and my implementation works. Second test case: I move to weblogic aspectj agent is set in script that starts weblogic. thirparty jar is added to classpath in that script. in weblogic log I see that my aop was loaded [ChangeAwareClassLoader@48537e4f] info AspectJ Weaver Version 1.7.1 built on Thursday Sep 6, 2012 at 16:39:22 GMT [ChangeAwareClassLoader@48537e4f] info register classloader weblogic.utils.classloaders.ChangeAwareClassLoader@48537e4f [DependencyClassLoader@4d5932c7] info using configuration But this time i don't see in the log: debug weaving '' I do see other weavings classes (from other aop.xml that are also deployed). (i verified that other aop.xmls don't exclude the thirdparty ) for example: [GenericClassLoader@62b46385] debug weaving 'com.core.BasicSessionBean' (this class is inside an ear which is deployed) I also verified that third party class was loaded (verbose:class). Any idea how to identify why that class was not weaved? The only difference that I see, that weaved classes are inside deployed ear file. Thirdparty classes are inside jar that added to classpath when starting weblogic.Server. I can provide aop.xml but I don't think it's important because it worked in my first test case. ___ 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] AspectJ third-party class is not weaved in weblogic
Without an MCVE it is difficult to say anything definitive, but in general you seem to have one of two possible problems: Class visibility issues due to classloader isolation inside your container (application server): Maybe the two classloaders loading the aspect JAR and the WAR/EAR to be woven are isolated from each other. Class-loading order: Maybe your aspect JAR is loaded after the target classes have already been woven. There might be other possible causes, I am by no means a container expert because I mainly work with Java SE and without application servers. I think you need to change your configuration in order to address this issue. What to do exactly is beyond my knowledge. Maybe Andy knows more. Maybe it would also help to push an MCVE to GitHub for everyone to reproduce to problem. -- Alexander Kriegisch https://scrum-master.de yev yev schrieb am 02.03.2019 16:19: I am trying to "Weave" a third-party jar with AspectJ using aspectj agent. First test case: MyAspectJImpl.jar - contains class with my aspect and aop.xml (with debug enabled)inside Meta-inf with correct mapping, and a test main class. third-party.jar aspectJ core jars. I execute main class in commandline java -javaagent:aspectjweaver.jar -cp ... on console see that that third party class was weaved, and my implementation works. Second test case: I move to weblogic aspectj agent is set in script that starts weblogic. thirparty jar is added to classpath in that script. in weblogic log I see that my aop was loaded [ChangeAwareClassLoader@48537e4f] info AspectJ Weaver Version 1.7.1 built on Thursday Sep 6, 2012 at 16:39:22 GMT [ChangeAwareClassLoader@48537e4f] info register classloader weblogic.utils.classloaders.ChangeAwareClassLoader@48537e4f [DependencyClassLoader@4d5932c7] info using configuration But this time i don't see in the log: debug weaving '' I do see other weavings classes (from other aop.xml that are also deployed). (i verified that other aop.xmls don't exclude the thirdparty ) for example: [GenericClassLoader@62b46385] debug weaving 'com.core.BasicSessionBean' (this class is inside an ear which is deployed) I also verified that third party class was loaded (verbose:class). Any idea how to identify why that class was not weaved? The only difference that I see, that weaved classes are inside deployed ear file. Thirdparty classes are inside jar that added to classpath when starting weblogic.Server. I can provide aop.xml but I don't think it's important because it worked in my first test case. ___ 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] There is an AspectJ maven build configuration
Hi Andy. I was quite busy, but a few days ago I cloned the repo and successfully ran the build with "skip tests". I had to switch from JDK 11 to 8, though, because with Oracle JDK 11 there was some problem with generating Javadocs. I guess Maven did not find the generator. I have not looked into it, just wanted to make you aware of it. Yesterday I ran a full build (mvn clean install) and had a test failure. I wanted to see if there were more failing tests on my Windows machine and just ran it again with -Dmaven.test.failure.ignore=true. The build completed after about 23 minutes on my machine and there were a couple more failures in one test class in addition to the failure I had seen before. I am attaching both Surefire logs here for you and just wanted to ask if these failures are currently to be expected due to some work in progress or platform-specific issue or if it is worth looking into that further. Best regards -- Alexander Kriegisch https://scrum-master.de Andrew Clement schrieb am 13.02.2019 05:37: One question, just in case: Would PRs against the GitHub repo be okay? Yes, I think so. But there are some shenanigans necessary to ensure the commit is signed off for easy acceptance, I discussed it in here with another guy who contributed that way - not even sure we got to a conclusion, but if they are signed off in an easy form for me to integrate, that’ll obviously reduce the time they take to process. https://github.com/eclipse/org.aspectj/pull/5 Andy On Feb 11, 2019, at 5:05 PM, Alexander Kriegisch <alexan...@kriegisch.name> wrote: Great news, Andy, thank you so much. This weekend or the next I guess I will take a look. One question, just in case: Would PRs against the GitHub repo be okay? Regards -- Alexander Kriegisch https://scrum-master.de Andrew Clement schrieb am 12.02.2019 06:29: It is alive. AspectJ, well overdue, now has as rudimentary maven build. It builds on the few systems I’ve tried it on although some of the tests seem to be a bit flaky on windows (I’ve not run the tests on windows for a long time so I don’t think it is due to the maven process, it just never used to be this easy to run them on a different OS). If anyone wants to help polish it, please do, I’m not a maven guru. There are some of the jar dependencies that need converting from local jar references to real dependencies from a repository but I haven’t had a chance to work out the exact version numbers. You can ‘mvn install’ and it will build aspectjrt/aspectjweaver/aspectjtools and then you can consume them from your local repo (although the poms need a bit of work). There is an installer project that builds the installer distribution we also make available. I’ve imported it into eclipse using m2e, I haven’t tried it with IntelliJ - I’d be interested to know if that works. If nothing else this may make it easier for folks to consume snapshot builds that include workarounds or early fixes as they can more easily build/install it locally now. If anyone wants to try it out, please do, raise bugs, contribute fixes :) There are extra benefits I snuck in: -- I deleted the projects ending in ‘5’ (created when Java5 was separate to Java 1.4) and merged them into the non 5 variants. -- bcel-builder is no longer a ’special project’ you had to build separately. It is just a regular sub-module -- If you do want to run the tests in eclipse, I added a few lines explanation in the new README at https://github.com/eclipse/org.aspectj I guess the true test of this will be when I try to use it to release 1.9.3 but as it produces the same artifacts, I should be able to use the same release process there. ___ 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 --- Test set: org.aspectj.internal.lang.reflect.AjTypeTest --- Tests run: 44, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.14 sec --- Test set: org.aspectj.tests.TestsModuleTests --- Tests run: 2974, Failures: 9, Errors: 0, Skipped: 0, Time elapsed: 1,039.092 sec <<< FAILURE! testOptionalAspects_pr398588(org.aspectj.systemtest.ajc172.Ajc172Tests) Time elapsed: 2.621 sec <<< FAILURE! junit.framework.AssertionFailedError: expecting output: AspectJ Weaver Version register classloader using configuration register aspect AspectA deactivating aspect register aspect AspectB register aspect AspectC register aspect AspectD deactivating aspect 'AspectD' as it requires type 'a.b.c.Anno2' whic
Re: [aspectj-users] Is there an AJDT version for Eclipse 2018-12?
I forgot to mention for my first try with "update installed software": -- I think the error comes from another update site, not from the AJDT one. -- The new AJDT packages finally showed up anyway after I clicked OK on the error message. -- Probably the installation failed there for the same reason it failed via "install new software": because the source code package was not available for download. -- Alexander Kriegisch https://scrum-master.de Alexander Kriegisch schrieb am 22.02.2019 08:00: > Thanks, Andy. > > Actually errors are being shown when trying to contact the update site via > Eclipse's update function: > > Unable to read repository at http://download.eclipse.org/eclipse/updates/4.10. > No repository found at > http://download.eclipse.org/eclipse/updates/4.10/categories. > > Next I tried the "install new software" and selected the new update site. I > selected all three packages for installation: > > An error occurred while collecting items to be installed > session context was:(profile=C__Program Files_Eclipse_2018-12_eclipse, > phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, > action=). > Unable to read repository at > http://download.eclipse.org/tools/ajdt/410/dev/update/ajdt-e410-2.2.4.201902212122/features/org.eclipse.contribution.weaving.source_2.2.4.201902212122.jar. > Connection reset > > On my third try I only chose the two software packages and unselected the > source code package. Finally the installation succeeded and now I can also use > "New aspect". > > Besides, in my new 2018-12 installation AJ code assist did not work, simply > because it was not active in the settings for AspectJ. After I activated it, > everything now seems to work normally and I can also compile with level 1.8 up > to 11. Thank you so much! > > Cheers > > > Andrew Clement schrieb am 22.02.2019 02:20: > >> There isa now a 410 update site that fixes this. >> >> http://download.eclipse.org/tools/ajdt/410/dev/update >> >> >>> On Feb 20, 2019, at 3:22 PM, Andrew Clement >>> wrote: >>> >>> Yep, I see it when I do new aspect. The problem is that the tests for AJDT >>> aren’t being run on a regular basis and certainly not against current >>> eclipse versions. You can tell things aren’t in an ideal state because we >>> are using a 4.8 update site for 4.10. The use of JDT weaving in AJDT makes >>> that project so much harder to work with. Let me try and at least look at >>> the >>> source in a 4.10 eclipse to see what it complains about. >>> >>> >>>> On Feb 19, 2019, at 7:25 PM, Alexander Kriegisch >>>> wrote: >>>> >>>> I can install AJDT from the 4.8 update channel into Eclipse 2018-12, but it >>>> does not work correctly, throwing errors during "new Aspect" and code >>>> completion, such as >>>> >>>> java.lang.NoClassDefFoundError: >>>> org/eclipse/jdt/internal/corext/codemanipulation/StubUtility >>>> >>>> Is there a functioning AJDT version (even a development snapshot) anywhere? ___ 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] Is there an AJDT version for Eclipse 2018-12?
Thanks, Andy. Actually errors are being shown when trying to contact the update site via Eclipse's update function: Unable to read repository at http://download.eclipse.org/eclipse/updates/4.10. No repository found at http://download.eclipse.org/eclipse/updates/4.10/categories. Next I tried the "install new software" and selected the new update site. I selected all three packages for installation: An error occurred while collecting items to be installed session context was:(profile=C__Program Files_Eclipse_2018-12_eclipse, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). Unable to read repository at http://download.eclipse.org/tools/ajdt/410/dev/update/ajdt-e410-2.2.4.201902212122/features/org.eclipse.contribution.weaving.source_2.2.4.201902212122.jar. Connection reset On my third try I only chose the two software packages and unselected the source code package. Finally the installation succeeded and now I can also use "New aspect". Besides, in my new 2018-12 installation AJ code assist did not work, simply because it was not active in the settings for AspectJ. After I activated it, everything now seems to work normally and I can also compile with level 1.8 up to 11. Thank you so much! Cheers -- Alexander Kriegisch https://scrum-master.de Andrew Clement schrieb am 22.02.2019 02:20: > There isa now a 410 update site that fixes this. > > http://download.eclipse.org/tools/ajdt/410/dev/update > > Cheers, > Andy > >> On Feb 20, 2019, at 3:22 PM, Andrew Clement wrote: >> >> Yep, I see it when I do new aspect. The problem is that the tests for AJDT >> aren’t being run on a regular basis and certainly not against current >> eclipse versions. You can tell things aren’t in an ideal state because we >> are using a 4.8 update site for 4.10. The use of JDT weaving in AJDT makes >> that project so much harder to work with. Let me try and at least look at the >> source in a 4.10 eclipse to see what it complains about. >> >> Cheers, >> Andy >> >>> On Feb 19, 2019, at 7:25 PM, Alexander Kriegisch >>> wrote: >>> >>> I can install AJDT from the 4.8 update channel into Eclipse 2018-12, but it >>> does not work correctly, throwing errors during "new Aspect" and code >>> completion, such as >>> >>> java.lang.NoClassDefFoundError: >>> org/eclipse/jdt/internal/corext/codemanipulation/StubUtility >>> >>> Is there a functioning AJDT version (even a development snapshot) anywhere? >>> -- >>> 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 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] Is there an AJDT version for Eclipse 2018-12?
I can install AJDT from the 4.8 update channel into Eclipse 2018-12, but it does not work correctly, throwing errors during "new Aspect" and code completion, such as java.lang.NoClassDefFoundError: org/eclipse/jdt/internal/corext/codemanipulation/StubUtility Is there a functioning AJDT version (even a development snapshot) anywhere? -- 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
