1 Reply Latest reply on Aug 19, 2005 10:50 AM by adrian.brock

    Recent changes

    kabirkhan
    kabirkhan Aug 19, 2005 9:07 AM

      I made some changes on Thursday, which Adrian pointed out might cause problems. Here's a little analysis of those changes and what JBoss classes they affect outside of AOP.

      Change 1
      ========
      Rename MethodInfo -> MethodJoinPoint

      This change can easily be ported to 1.3 branch

      Affected classes outside AOP:
      JMS (Not released yet)
      ----------------------
      - org.jboss.jms.client.container.JMSInvocationHandler.java
      - org.jboss.jms.client.container.JMSMethodInvocation.java

      EJB3
      ----
      - The various EJB3 Containers (StatelessContaner, StatefulContainer etc.)
      - EJBContainerInvocation


      Change 2
      ========
      Split ClassAdvisor into ClassAdvisor (interface) and ClassAdvisorImpl (class)
      Split Advisor into Advisor (interface) and AdvisorImpl (class)

      These changes should be portable to 1.3 branch too

      Affected classes outside AOP:
      JMS (Not released yet)
      ----------------------
      - org.jboss.jms.client.container.JMSAdvisor.java (Not released yet)


      Change 3
      ========
      Split AspectManager into AOPManager (interface) and AspectManager (class)
      Split Domain into Domain (interface) and DomainImpl (class)

      These changes should be portable to 1.3 branch too

      Affected classes outside AOP:
      Aspects
      -------
      - org.jboss.test.kernel.AspectTestCase.java (Not released yet)
      - org.jboss.test.kernel.AspectXmlTestCase.java (Not released yet)
      - org.jboss.aspects.kernel.schema.* (Not released yet)
      - org.jboss.aspects.kernel.* (Not released yet)


      So the three main things affected are EJB 3, JMS and the kernel aspects. The changes I have made can easily be backported to the Jboss AOP 1.3 branch.

      I am assuming that when we release EJB 3 final, that we will release a new version of Jboss AOP too and have EJB 3 require that as we have done in the past?

      JMS and the kernel/aspect stuff are not released yet, so isn't it fair to have them depend on a future JBoss AOP release?

      If I am talking utter rubbish, please let me know and I will revert my changes :-)

      • 1974 Views
      • Tags:
        • 1. Re: Recent changes
          adrian.brock Aug 19, 2005 10:50 AM (in response to kabirkhan)

          The issue is about backwards compatibility.

          * Why did you need to change the names?
          * Why can't you just leave

          /** @deprecated use MethodJoinpoint */
public class MethodInfo extends MethodJoinpoint
{
}


          * Add the interface to the existing classes without changing the name 
          public class ClassAdvisor implements IClassAdvisor {}


          That way you don't break people's code.
          AOP, JMS and EJB3 are standalone binary distributions that
          are used across versions and by other people.

          Yes, you can fix jboss-head or jboss.4.0.3+, but what about

          * Somebody that wants to use the next EJB3 release with 4.0.2
          * The other JBoss code that is not in the JBossAS sourcetree but uses those classes
          * Users's code

          AOP is a final released product. Any major changes should be
          deferred to AOP2.0 (in a separate cvs branch).

          We already have a similar issue with jgroups 2.2.7 -> 2.2.8

          Lastly, in most circumstances, you wouldn't have to worry about this.
          Stuff like JMS/EJB3 would be using my wished for "proxy" container
          (unified container/interceptors) abstraction that doesn't require the user
          to get so deeply involved in "implementation details" of AOP.

            • Actions