Recent changes

[kabirkhan]

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 :-)

[adrian.brock]

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.