Eclipse IDE integration

[bill.burke]

I have never used eclipse, but a few things that would be nice with JBossAOP would be:

1. right click on a method, field, or constructor, apply an interceptor/advice to them

2. Highlight a method call or constructor call within code, right click, and apply an caller interceptor/advice

3. Display a dump of classes that are AOPized and what bindings affect them(we can do this as an XML dump now, or through the JBoss ManagementConsole).

Anything else you can think of. Use your creativity.

Bill

P.S. I guess I should at least install Eclipse if I want the integration ;)

[oz59]

Greetings.

Couple questions:

What kind of scope are you talking about?

Based on prior postings, would/is the target JVM strictly 1.5?

Apparently debuggers are for pussies*, but do you generally see JVMTI Bytecode Instrumentation aligning with the AOP framework's endeavors?

Thanks and best regards.

*http://jboss.org/jbossBlog/blog/bburke/?permalink=Debuggers+are+for+pussies.html

[bill.burke]

Oz,

JBoss AOP only support JDK 1.4 now. I'm getting with Professor Chiba to discuss what needs to be done for Javassist and who can work on it. JBoss AOP cannot support JDK 1.5 until Javassist is complete.

As far as Eclipse, I'm not a user, but it is far more than just a debugger. I've been told it has similar features to IntelliJ(my preferred IDE).

As far as JVMTI, please see my blog post:
http://jboss.org/jbossBlog/blog/bburke/?permalink=Dynamic+AOP+and+Hot+Swap%3F%3F.html
and
http://jboss.org/jbossBlog/blog/bburke/?permalink=Dynamic+AOP+and+Hot+Swap+revisited.html

I do not think the JVMTI is usable for AOP frameworks yet.

[h2o_polo]

1. right click on a method, field, or constructor, apply an interceptor/advice to them

2. Highlight a method call or constructor call within code, right click, and apply an caller interceptor/advice

Why do you need Eclipse, when you have a bunch of XDoclet tags to do what seems to be the same thing? Put a tag in your code, run XDoclet and get your jboss-aop.xml. XDoclet plugin does it nicely (that is once I get it to work with the latest Eclipse).

The third point you made makes a bit more sense to me, except here you can probably employ Eclipse to visualize the aspects. But would not that have to be done in the other direction? You get jboss-aop.xml, parse it, make a visual presentation? A step further would be to do the same thingy but on the live deployment [here I guess JMX would be handy].

By the way, is there any rich client jboss console (sort of like weblogic's)? Eclipse might be a good candidate for this sort of application, with its RCP.

Alex.

[bill.burke]

"alex.shneyderman" wrote:

1. right click on a method, field, or constructor, apply an interceptor/advice to them

2. Highlight a method call or constructor call within code, right click, and apply an caller interceptor/advice

Why do you need Eclipse, when you have a bunch of XDoclet tags to do what seems to be the same thing? Put a tag in your code, run XDoclet and get your jboss-aop.xml. XDoclet plugin does it nicely (that is once I get it to work with the latest Eclipse).

Well, in 1.0Beta, only metadata tags are support. I have yet to write other doclet integration. AND I did not write it in XDoclet (used QDox). Went to learn Xdoclet and saw this tremendous mess of XSL and XML and said, screw that. Wrote the metadata generation with qdox in 2 hours.

QUESTION: Does this matter? Does Eclipse need XDoclet templates to know how to expand them?

The third point you made makes a bit more sense to me, except here you can probably employ Eclipse to visualize the aspects. But would not that have to be done in the other direction? You get jboss-aop.xml, parse it, make a visual presentation? A step further would be to do the same thingy but on the live deployment [here I guess JMX would be handy].

By the way, is there any rich client jboss console (sort of like weblogic's)? Eclipse might be a good candidate for this sort of application, with its RCP.

Alex.

JBoss AOP integrates with JBoss web-console and has a command line XML dump facility. See Wiki here:

http://jboss.org/wiki/Wiki.jsp?page=DebuggingAndAnalysisTools

[h2o_polo]

QUESTION: Does this matter? Does Eclipse need XDoclet templates to know how to expand them?

If you only want the functionality similar to what QDox provides then you probably do not need them. But QDox only buys you the model, after you get it you have to walk the model and do the generation, as far as I understand from their docs.

The current version of Eclipse-XDoclet plugin just calls XDoclet to do its generation of code, and that is the reason it needs the XDoclet's modules and hence the templates. Another thing it needs it for is to make code assist work. Just by parsing META-INF/xtags.jar file it is getting automatic updates of the code assist possibilities.

Thinking of possibilites, is there a jboss-aop.dtd or schema anywhere?

Alex.

[bill.burke]

no DTD. Need to write one....DTD doesn't matter much as the pointcut language is embedded in a string.

Need to write a BNF grammar too on wiki.


As far as XDoclet vs. QDox. I think I will keep QDox for the annotation generation, but maybe XDoclet is the right approach for any new doclet stuff I will do.

Qdox is very easy to walk and generate the model.

Bill

[oz59]

Continuation of thread http://jboss.org/index.html?module=bb&op=viewtopic&t=47140&start=10.

Ok, I've got more questions, thoughts, and observations. Please provide your feedback.

It seems to me that Bill is leaning toward aop meta-data on aspects only. This makes perfect sense to me to more so realize their cleanly separate nature. With that in mind, there needs to be a way to make sure the actual aspect src is available in the workspace. This could potentially be done by the ide one way or another - maybe through auto-update (to supply official "JBoss approved" aspects) and then automatically pushing aspect classes (anyone's) to the server.

To add to the above statements, at this point, I'm thinking right-clicks would offer three things: update aspect meta-data, update xx-aop.xml, or launch a new aspect wizard (potentially w/ pertinent information already populated). Even though the Interceptor interface is easy, a wizard would/should make it absolutely trivial.

To further tie in w/ above statements, I'm curious if there's any generally accepted approach for server aspect recognition. For instance, would meta-data driven artifacts typically end up in the xx.aop jar (for more or less permanent system behavior?). Likewise, can the xx-aop.xml be thought of as less permanent? I very well may have implemented it wrong, but is it true xx.aop jar won't be recognized if deployed inside an .ear?

As far as seeing what aspects are applied, this could be quite misleading. For instance, the ide might not be completely aware of the aspect-suites already on the server. Could use some feedback on this. For actual gui realization, I'm thinking gutter decoration as well as view/properties page.

The web-console is cool. Those icons will be used again for consistency.

Sorry for the long post - please get back w/ your thoughts.
-oz

[bill.burke]

"oz59" wrote:
Continuation of thread http://jboss.org/index.html?module=bb&op=viewtopic&t=47140&start=10.

Ok, I've got more questions, thoughts, and observations. Please provide your feedback.

It seems to me that Bill is leaning toward aop meta-data on aspects only. This makes perfect sense to me to more so realize their cleanly separate nature. With that in mind, there needs to be a way to make sure the actual aspect src is available in the workspace. This could potentially be done by the ide one way or another - maybe through auto-update (to supply official "JBoss approved" aspects) and then automatically pushing aspect classes (anyone's) to the server.

I actually prefer the XML approach as the aspects should be just as oblivious as the classes they aspectize. In other words, bindings should be separate from aspects/advices.

That being said, just like in EJB land, people prefer to use tags sometimes. What I'd rather do that have the source available is to use JSR-175 and JDK 1.5. I have already extended Javassist to support annotations and it is portable to JDK 1.4, so the source is not needed. What would be needed is an annotation compiler (JDK 1.5 may be able to compile the code, and a JDK 1.4 runtime could read it, I still need to investigate). One problem still remains with tag driven shit....You still need an XML file to tell the runtime what aspects are available.

I'm thinking more in standalone JBoss AOP.....

"oz59" wrote:

To add to the above statements, at this point, I'm thinking right-clicks would offer three things: update aspect meta-data, update xx-aop.xml, or launch a new aspect wizard (potentially w/ pertinent information already populated). Even though the Interceptor interface is easy, a wizard would/should make it absolutely trivial.

Agreed. But we offer more than just an Interceptor. We also have an Aspect concept, where the aspect class's methods are advices you can apply/attach/bind anywhere.

"oz59" wrote:

To further tie in w/ above statements, I'm curious if there's any generally accepted approach for server aspect recognition. For instance, would meta-data driven artifacts typically end up in the xx.aop jar (for more or less permanent system behavior?). Likewise, can the xx-aop.xml be thought of as less permanent? I very well may have implemented it wrong, but is it true xx.aop jar won't be recognized if deployed inside an .ear?

There is no one master .xml file. An XML file is as permanent as any other
deployment.

"oz59" wrote:

As far as seeing what aspects are applied, this could be quite misleading. For instance, the ide might not be completely aware of the aspect-suites already on the server. Could use some feedback on this. For actual gui realization, I'm thinking gutter decoration as well as view/properties page.

The web-console is cool. Those icons will be used again for consistency.

Sorry for the long post - please get back w/ your thoughts.
-oz

So there are two modes for JBoss AOP. Standalone (outside JBoss app server) and with JBoss app server. Both use an AspectManager class that can be queried for information. The manager also has a dynamic api for registering/unregistering aspects/interceptors, bindings, or new metadata.

I think you should start with simple requirements and iterate: This is minimally what should be implemented:

1. right click on method, constructor, or field and tell me advices/interceptors attached. You should be able to navigate to the binding from here.

2. Right click on method constructor, field and select from a list of advices to bind to it.

3. From an aspect, advice, and/or interceptor right click and tell where it is bound to.

4. Given a pointcut expression show all points in IDE that match that given pointcut

5. Show unbounded bindings (management console does this)

6. Caller side bindings: within a piece of a method body, highlight a method call and specify that you want to apply an advice binding.

Hope this helps. It is better to just start doing something and iterate. In my experience it is impossible to write a GUI correctly the first time and it takes several iterations to get it right. It is better to release early and often so you get quick user feedback. So, what I'm saying is that we've talked enough and somebody needs to put together a prototype.

IMO, JBoss-AOP cannot succeed without good IDE integration. So, whoever takes this on will be my hero and you'll be a huge part of making JBoss AOP a success.

Because we are 100% pure Java, IDE tools will be easier to write.

Thanks,

Bill