Integration of aop/aspects into JBAS and other projects

[starksm64]

Ben Wang has created a web container aspect for fine-grained replication of session data. This brings up a previous issue of where aspects live and how they are deployed in non-trivial environments like JBAS.

Currently there are aspects like security living in the aspects module which do not belong in a standalone aspects library as evidenced by the module dependencies:

 <path id="dependentmodule.classpath">
 <path refid="jboss.common.classpath"/>
 <path refid="jboss.j2ee.classpath"/>
 <path refid="jboss.j2se.classpath"/>
 <path refid="jboss.jmx.classpath"/>
 <path refid="jboss.system.classpath"/>
 <path refid="jboss.security.classpath"/>
 <path refid="jboss.j2se.classpath"/>
 <path refid="jboss.system.classpath"/>
 <path refid="jboss.remoting.classpath"/>
 <path refid="jboss.cluster.classpath"/>
 <path refid="jboss.transaction.classpath"/>
 <path refid="jboss.aop.classpath"/>
 <path refid="jboss.server.classpath"/>
 <path refid="jboss.container.classpath"/>
 </path>

The aspects I am most familar with that do not belong here are the security aspects, which depend on implementation details of jbosssx as it is bundled into JBAS.

Throw in deployment ordering, hot deployment, class loader scoping, alignment of aspects with their sevices for ease of installation packaging, etc. and the current monolithic aspect is not managable.

So this thread is a starting point to discuss how we are going to manage the aop aspects.

[ben.wang]

Well, this is not exactly as an Aspect. But rather an switch inside Tomcat.

Still, I have a tc5-clutster.aop jar that needs to deploy under all/deploy. In addition, I need to access it from testsuite so my POJO can precompile with annotationc and aopc.

What's the best practice?

[ben.wang]

I am going ahead to create a tomcat module so I can reference it from testsuite. In addition, I am deploying tc5-cluster.aop (has jboss-aop.xml) under all/deploy. This is needed for http session fine-grained replication using aop.

I can modify the setup later on if there is a need.

[adrian.brock]

I believe the aspects belong in the module that implements them.

This is the only approach that will allow the aspect to evolve across versions
rather than trying to maintain a monolithic single integration package
jboss-aspects.

The aspect requires the rest of the implementation anyway, e.g. the
authentication/authorization advices require jbosssx.

[bill.burke]

It has actually been much easier to package it as this "monolithic" aspect library over the past few years. If there is a bug or feature addition in any of the aspects in the library, I can easily patch any version of JBoss. It would actually be more "monolithic" if the code was part of Branch_4_0 as I would not be able to do a new release of the aspect library (and EJB 3.0 for instance) without a complete rev of the entire application server. This is quite unacceptable to most users.

So, in summary, although I think it might be asthetically appropriate, I don't see how this change you suggest will make anybody's life easier. It sure will make the EJB3/AOP team's life much harder to do new releases.

[starksm64]

A standalone release of aop which includes a security aspect depending on the implementation details of jboss-4.0.x makes no sense.

[adrian.brock]

It has actually been much easier to package it as this "monolithic" aspect library over the past few years.

Ok, one contra example is code to integrate the deployer/classloader across versions:
http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-aspects/src/main/org/jboss/aop/deployment/

If there is a bug or feature addition in any of the aspects in the library, I can easily patch any version of JBoss.

How so, are you going to keep up and supply different versions of these advices
as the internal api changes?

It would actually be more "monolithic" if the code was part of Branch_4_0 as I would not be able to do a new release of the aspect library (and EJB 3.0 for instance) without a complete rev of the entire application server.

You need the implementation library anyway for the aspect to work. And the
implementation details (non-published api like SecurityAssociation) is going to
evolve independently across versions.

So, in summary, although I think it might be asthetically appropriate, I don't see how this change you suggest will make anybody's life easier.

Aesthetics are not an issue, it is about each module being responsible for
its own implementation.

It sure will make the EJB3/AOP team's

The EJB3/AOP team should concentrate on delivering containers and the invocation
model, not how to integrate security.
And see above about needing jbosssx.jar anyway.

This is the same mentality that led to the JBossCache project becoming bloated.

[adrian.brock]

The integration point is the annotation (which also belongs in JBossSX)
and that needs to be consistent with the features provided by each version.

@SecurityDomain("other")
@NewSecurityFeatureNotAvailableInJBoss32 // Shouldn't compile under 3.2.x
public void doSomething()
{
}