JBossDeveloper

If I revert the ReentrantReadWriteLock to the backport concurrent util version
rather than Doug Lea's version
then RetroCheck will catch attempts to use the unsupported methods/classes yes.

Webservices doesn't use this class, so I don't think it is a high priority to get
complete coverage on this class just yet?

That's my point. If webservices doesn't use it, we shouldn't spend time ensuring its coverage. But we want a build to fail if they do use it in the future. I think that is what you are suggesting.

I've reverted to backport-concurrent-util and removed the tests that don't have
coverage.

This means there is still an issue with the ReentrantLockTest timing out
when run with the TCK tests.

I'm getting an error when running the check task against latest webservice retro binary:

[retrocheck] ==== /home/rcampbell/work/jboss-head/webservice/output/classes-retro/org/jboss/ws/tools/helpers/ToolsHelper.class
[retrocheck] Cannot find method java.lang.Class.getSimpleName()Ljava/lang/String;
[retrocheck] Cannot find method java.lang.Class.getSimpleName()Ljava/lang/String;

The scoped classpool is done.

Since I am now pruning the data, I still need to write some tests to check that
all the annotations are retained after the prune.

The other things to test (not sure how to do it in general) are:

* java2Compliance=false classloading

* aop generated classes where getResource() will fail
Bill has a JBossClassPool class that dumps pages the bytecode out to
a temporary file.

The other thing to look at is how this data gets garbage collected.
I think the AOPClassPool assumes it will get a notification
to unregisterClassLoader() via the Translator interface?

"scott.stark@jboss.org" wrote:

"adrian@jboss.org" wrote:
The other thing to look at is how this data gets garbage collected.
I think the AOPClassPool assumes it will get a notification
to unregisterClassLoader() via the Translator interface?

Yes, that is what I read when browsing through it and therefore wonder about its utility outside of jbossas. Wouldn't just a WeakHashMap be the suggested approach?

The classloader is now held as a weak reference.

I've also completed the tests for basic scoped annotations
and added support for field and constructor annotations.

I am integrating jbossretro into buildmagic and have found a webservice specific problem. Specifically, they copy classes from /server into their build before weaving:

<mkdir dir="${build.classes.retro.src}"/>
 <copy todir="${build.classes.retro.src}">
 <fileset dir="${build.classes}">
 <include name="javax/**"/>
 <include name="org/jboss/ws/**"/>
 </fileset>
 <fileset dir="${jboss.server.root}/classes">
 <include name="org/jboss/webservice/metadata/**"/>
 </fileset>
 </copy>

[retro] [warning] Trying to compile /home/rcampbell/work/jboss-head/webservice/output/classes14/org/jboss/webservice/metadata/jaxrpcmapping/PackageMapping.class and found it also within file:/home/rcampbell/work/jboss-head/server/output/lib/jboss.jar!/org/jboss/webservice/metadata/jaxrpcmapping/PackageMapping.class will not proceed.
 [retro] [warning] Trying to compile /home/rcampbell/work/jboss-head/webservice/output/classes14/org/jboss/webservice/metadata/jaxrpcmapping/ServiceInterfaceMapping.class and found it also within file:/home/rcampbell/work/jboss-head/server/output/lib/jboss.jar!/org/jboss/webservice/metadata/jaxrpcmapping/ServiceInterfaceMapping.class will not proceed.

I went ahead and checked this in. You can run it with

cd webservices; ant clean main -Dretro=true

"ryan.campbell@jboss.com" wrote:
Can this check be disabled? I'm passing the javac.classpath to the jbossretro task. I guess I could prune this manually, but this seems worse.