jbossretro/aop integration

[starksm64]

One screwed up situation in the 4.0 branch is the aspects module have both jdk5 and j2se1.4 source trees and seperate artifacts. Can this be unified to a jdk5 based source tree with source/target levels of 1.4 + jbossretro translation where needed?

[starksm64]

I guess my main question here is why should we be supporting an xdoclet like javadoc based mechanism rather than simply using java5 annotations with jbossretro translation? With the javadoc approach we have an obsolete technology that replicates and conflicts with the j2se5 to j2se1.4 translation we already have to support (see the recent org.jboss.lang.Enum issue).

[adrian.brock]

This is legacy.

It just needs us to "sit down" (talk) and understand
how we rationalize this legacy solution (javadoc) with the retro approach.

i.e. How much can retro rely on aop or vice versa.

[kabirkhan]

I have had a play with getting aop to work with jboss retro. In the standalone aop tests everything seems to work apart from annotation introductions with loadtime weaving.

The main gist of it is JBoss AOP uses its classpool repository to add the annotations and these are then woven into the class. Next the retro annotation helper comes along and tries to read the annotations using a ctclass from its classpool repository. Since that pool is empty it loads up the raw resource from the .class file which does not contain the introduced annotations.

I think when using aop and jboss retro that the aop classpool should be used in favour of the jboss retro one. Meaning we need some common interfaces for the pool stuff. Question is where should this live? I don't mind putting it in jboss retro since there will be some dependency on jboss retro when running with jdk 1.4, although having a dependency on jboss retro when running in jdk 5 might be strange...

An option might be to split out a jboss-retro-interfaces. jar

Thoughts?

[starksm64]

We should not have a runtime dependency on jbossretro when using jdk5. Can't the classpool api be in javassist itself since this is the common codebase?

[kabirkhan]

The classpool repository is a layer on top of what is offered by javassist. It is mainly there to deal with the deployment/undeployment of classloaders when running in jboss.

So I don't think it fits in javassist. Maybe we need a new classpool repository project?

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=77746

[adrian.brock]

The two classpool implementations need to be merged.

e.g. The jboss retro implementation understands context classloading
better (see fixmes in AOP code) and also doesn't need a specific
callback to avoid memory leaks.

e.g.2. The jboss retro implementation doesn't understand the
overriding of the class file into "/tmp" that the JBossClassPool does.

I think javassist would be the correct place for a full implementation
of a classpool that better understands context classloading.

[kabirkhan]

I've got the pool/repository stuff moved into javassist, and have created a javassist 3.3.0.snapshot and jboss retro 1.0.2.snapshot. AOP wraps/extends this pool as needed for the extra functionality.

The tests now pass on my machine, and I am in a position to have a pure jdk 5 codebase using jboss retro to run with jdk 1.4. I'll need to "re-annotate" some of the tests, i.e use JDK 5 annotations w/ retro instead of the annotationc JDK 1.4 ones.

Annotationc can be kept alive for a while, since annotions compiled in by that are readable by the retroed aop code. Meaning we have two ways to annotate code for use with AOP

1. JDK 5 code and jboss retro

@Foo
public class Blah{
 Set<String> test;
}

2. JDK 1.4 code and annotationc

/**
 *@@org.acme.Foo{
 */
public class Blah{
 Set test;
}

I'll keep this on hold for a few days, so if anybody can think of any issues with this switch to JDK 5 speak now

[adrian.brock]

I've got the pool/repository stuff moved into javassist, and have created a javassist 3.3.0.snapshot and jboss retro 1.0.2.snapshot.

You obviously didn't get my e-mail yesterday.

There should be no such thing as x.y.z.snapshot

It is either SNAPSHOT (if it is not tagged in CVS)
or a proper release, e.g. 3.3.0.alpha

Versioning stuff that cannot be reproduced is pointless
and just makes it harder to spot what needs to be fixed
when we get to a release.

[kabirkhan]

You obviously didn't get my e-mail yesterday.

Correct

There should be no such thing as x.y.z.snapshot

It is either SNAPSHOT (if it is not tagged in CVS)
or a proper release, e.g. 3.3.0.alpha

Versioning stuff that cannot be reproduced is pointless
and just makes it harder to spot what needs to be fixed
when we get to a release.

OK, I'll fix

[kabirkhan]

The AOP standalone project has been set up now to use a JDK 5 source tree and JBoss retro for compatibility w/ JDK 1.4.

To build, you need to use JDK 5 and have a local.properties file containing a jdk14.home property pointing to a JDK 1.4 dist.

$cd jboss-aop/aop
$build.sh
$build.sh -f build-tests-jdk14.xml tests
$build.sh -f build-tests-jdk50.xml tests