Women in Technology

Article:		Aspect-Oriented Programming and JBoss
Subject:		Uncompatible with J2EE
Date:		2003-06-06 00:32:00
From:		anonymous2
When you read about AOP carefully, you must conclude that it will still be impossible to have different version of the same (AOPied) class within JBoss at the same time. This directly implies that all problems mentioned at http://www.jboss.org/thread.jsp?forum=92&thread=28964 remain UNRESOLVED. I think AOP is a complex issue and an interesting idea and I will not juge about its benefits here. But I also see that it changes the feeling of the Java language to something more Smalltalk like. I also expect security issue to arise from AOP and feel that the original hierachical ClassLoader idea of Java is much more save for networked applications. The main point is still that AOP is NOT COMPATIBLE WITH THE J2EE SPECIFICATION. ejb-2_0-fr2-spec.pdf, chapter 24.2.7, page 500: "An enterprise bean?s remote home and remote interfaces are remote interfaces for Java RMI. The Container must ensure the semantics for passing arguments conforms to Java RMI. Non-remote objects must be passed by value. Specifically, the EJB Container is not allowed to pass non-remote objects by reference on inter-EJB invocations when the calling and called enterprise beans are collocated in the same JVM. Doing so could result in the multiple beans sharing the state of a Java object, which would break the enterprise bean?s semantics." Of course this implies that different version of a class with the same qualified name must be possible if they are in different packed archives. Kind regards, aanno

Showing messages 1 through 4 of 4.

• Uncompatible with J2EE
  2003-06-30 06:55:30  anonymous2 [View]
  
  
  You are damn right, JBoss AOP is working only for JBoss and the standalone pack is only good at hello world example.
  
  It should have been stated clearer by JBoss team: demo purpose only. I see no mention of future plan explaining JBoss standalone AOP roadmap, and I don't think JBoss has an advantage to maintain such a thing except for educational purpose.
  
  Alex
  Read a complete study on the JBoss standalone AOP on my stuff - sorry for the add. I just want the thing to be clearer: JBoss AOP standalone is only for demo purpose.
  http://besee.sourceforge.net/casestudy/jbossaop_standalone.html
  
  
• Uncompatible with J2EE
  2003-06-30 08:18:32  patriot1burke [View]
  
  
  Alex wrote:
  "You are damn right, JBoss AOP is working only for JBoss and the standalone pack is only good at hello world example.
  It should have been stated clearer by JBoss team: demo purpose only. I see no mention of future plan explaining JBoss standalone AOP roadmap, and I don't think JBoss has an advantage to maintain such a thing except for educational purpose.
  
  Alex
  Read a complete study on the JBoss standalone AOP on my stuff - sorry for the add. I just want the thing to be clearer: JBoss AOP standalone is only for demo purpose.
  http://besee.sourceforge.net/casestudy/jbossaop_standalone.html"
  
  Firstly, thank you Alex for your detailed tests and analysis. You found some bugs (the stupid Javassist stack trace) thanks.
  
  Now, let's start addressing the issues you had.
  
  1. JBoss AOP was originally implemented to support the middleware aspects for JBoss 4. I have not done enough testing and playing yet in the standalone space as you can already see. Apologies....We DO PLAN to have a usable standalone version.
  
  2. The stack trace is easily fixable.
  
  3. The reason that certain classloader scenarios don't work is that JBoss AOP must control the classloader, even if it is a child classloader. What I should do really is document how to do this. Apologies again. So much for release early, release often, but the feedback has been really good so far.
  
  4. The reason why AspectWerks does not have to have control over the ClassLoader is that it uses JMangler. JMangler uses the Java Debugger Interface, AFAICT, to provide hooks into loadtime class transformations for any class hierarchy. From what I have determined, they replace the default implementation of java.lang.ClassLoader using JDI interfaces for hot-swapping classes at runtime. So basically AspectWerks runs your java applications in the Debug mode of the JVM. Not sure what kind of affect this has on the system. But I plan on doing some performance measurements against AspectWerks and AspectJ to see. Somebody measured DR1 against AspectJ and the performance numbers were surprisingly similar. I'll do AspectWerks too.
  
  Bill
  
  
  
• Uncompatible with J2EE
  2003-06-30 08:29:03  patriot1burke [View]
  
  
  One more thing...
  
  We plan on adding a compiler in the near future because:
  
  1. For places where you don't have control of classloader.
  
  2. To ease application bootup time.
  
  We may look into using Java Debugger Interface to replace java.lang.ClassLoader with our own implementation as AspectWerkz/JMangler does. It seems like an interesting approach, but I'm not sure of the effects yet.
  
  Bill

• Uncompatible with J2EE
  2003-06-30 07:03:43  patriot1burke [View]
  
  
  aanno,
  
  Your comments are a bit misinformed. Please do some more research before posting next time. The ClassLoader and RMI semantics you talked about is a JBoss issue and not an JBoss AOP issue at all.
  
  1. RMI pass-by-value CAN be enforced in JBoss land.
  
  2. ClassLoaders can be scoped in JBoss land.
  
  3. JBoss AOP maintains serial version id of original class, so it is possible to serialize a JBoss AOPized class to a non-JBossAop client.
  
  Bill