AspectJ annotation support

I'm using the lastest dev release (M2 at the moment) and it seems that AspectJ annotation are supported.
But it looks like only a subset of the possibilities have been implemented.

I use "Chapter 9. An Annotation Based Development Style" (cf. http://www.eclipse.org/aspectj/doc/released/adk15notebook/ataspectj-pcadvice.html) as base documentation to write my annotated aspects and most of them are in error in IDEA.

Besides I'm using the AspectJ weaver plug-in and it's pretty difficult to assess what's working and what's not.

Is it a work in progress? I see included '@AspectJ support API' is v1.0. Is there different level of support for @Aspects??

cheers

14 comments
Comment actions Permalink

Hello nodje,

Besides I'm using the AspectJ weaver plug-in and it's pretty difficult
to assess what's working and what's not.


AFAIK only the subset used by Spring AOP is supported.

-tt


0
Comment actions Permalink

Hum, maybe my understanding was wrong, but it seems to me that you don't need Spring to apply @Aspects on classes. Why would IDEA limits itself to what Spring supports in this case?

There's probably a good reason behind it, it's just that I can't see it.

I've really been struggling with that, to the point that I have downloaded a version of eclipse.
I wish I will not have to configure that stuff, but if there's no more Aspect support in Selena's pipe, that'll be the option left to me, since AOP support in IDEA is not really enough to work with yet.

rgds

0
Comment actions Permalink

Why would IDEA limits itself to what Spring supports in this case?

Probably because the Spring userbase is something like fifty times larger than the AspectJ userbase. It's unfair, but realistic.

--Dave Griffith

0
Comment actions Permalink

right, put it this way it does make sense....
I just didn't realize IDEA team put this @Aspect support for Spring.
I remember some argument about this AspectJ support some time ago, and figured supporting @Aspect was a good way to go for IDEA.
Well, at least the basics are here. Should be easy to extend it some day...

0
Comment actions Permalink

Hello nodje,

Well, at least the basics are here. Should be easy to extend it some
day...


It's open-source, by the way.
http://svn.jetbrains.org/idea/Trunk/bundled/aop-common/

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Intellij guys, I just noticed your 'Navigate to intercepted methods' and 'Navigate to AOP interceptors' icons next to the 'Implements..' ones...
It's absolutely brilliant... awesome... no word for it. I didn't even dream for it..

Well, it does show only a little subset of all supposedly intercepted methods, but, it's here.

Dmitry, that's another good news. I'll have a look right away.
But does supporting the whole @Aspect spec is a goal for IDEA or is it still under discussion, or not even?

0
Comment actions Permalink

I downloaded the sources for aop-common. There's just an IML fils, no project file and it's asking for a TEMPLATE variable when trying to add it to an existing project.

Where are the howto/rules to participate to opensourced code?

Any tip?

cheers

0
Comment actions Permalink

Hello nodje,

I downloaded the sources for aop-common. There's just an IML fils, no
project file and it's asking for a TEMPLATE variable when trying to
add it to an existing project.


The .iml file in SVN is designed to be used as part of main IntelliJ IDEA
project. You should create your own .ipr file, and your own module of type
"Plugin", and add the sources from SVN to that.

We plan to provide ready-to-use .ipr/.iml files for all open-source plugins
later.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

Well, it does show only a little subset of all supposedly intercepted methods, but, it's here.

Yes, only the methods that Spring can intercept.

But does supporting the whole @Aspect spec is a goal for IDEA or is it still under discussion, or not even?

Now, only Spring AOP is supported, and we aren't planning to support the
whole AspectJ yet. It could be another (maybe third-party) plugin that
could take advantage of what's already implemented in aop-common.

0
Comment actions Permalink

Well, it does show only a little subset of all supposedly intercepted methods, but, it's here.

>>Yes, only the methods that Spring can intercept.
hum, in my case, it's a very generic aspect that catches all methods in BusinessServices: but the IDEA icon (sorry not being able to name it better) only catches some methods and of only 2 of my numerous services (in total only 10 are identified). And this is both way, meaning, if I go to a service method not identified by the aspect, there's also no icon specifying that the method is intercepted.

the Poincut is:
<<
@Pointcut("SystemArchitecture.businessService() && !execution(* org.xx..service.SubService.(..))")

@Pointcut("execution(* org.xx..service.Service.(..))")
public void businessService() {
}
>>

0
Comment actions Permalink

+
We plan to provide ready-to-use .ipr/.iml files for all open-source plugins
later.
+

Maybe no-one else on the planet cares, but I'd find that very valuable. If you included configured build.xml files with each plugin, even better.

--Dave Griffith

0
Comment actions Permalink

Hello nodje,

A JIRA ticket with more details would help:
http://www.jetbrains.net/jira/secure/CreateIssue!default.jspa

Useful (additional) details would be:
-snippet of spring xml used to configure the advice/beans
-if necessary, the signatures of the advised methods

While I haven't checked that latest state of the IDEA Spring AOP support,
some things to remember are these:
-AspectJ can advice any class, while Spring AOP advice only applies to *Spring
beans*
-AspectJ can advice static/private methods, while Spring AOP is limited to
non-private instance methods (due to its proxy-based interception model)

Taras


0
Comment actions Permalink


Dave Griffith wrote:

+ We plan to provide ready-to-use .ipr/.iml files for all
open-source plugins later. +

Maybe no-one else on the planet cares, but I'd find that very
valuable. If you included configured build.xml files with each
plugin, even better.


No, I care too:-) This would probably also increase the chance of
external contributions to the plugins by some fraction.

Bas

0
Comment actions Permalink

Hello Bas,

No, I care too:-) This would probably also increase the chance of
external contributions to the plugins by some fraction.


I care as well. :)
In addition to potential contributions for bundled plugins, it would provide
ready-to-run example code (with tests) for third-party plugins as well.

Taras


0

Please sign in to leave a comment.