This content has been marked as final.
Show 7 replies
-
1. Re: Annotation scanning
kabirkhan Apr 21, 2008 7:09 AM (in response to alesj)One point: For the purposes of AOP, the classes must NOT be loaded when scanning for annotations. If they are loaded, then we can not do loadtime weaving. The annotation scanning should use javassist instead to look for annotations.
-
2. Re: Annotation scanning
adrian.brock Apr 22, 2008 5:47 AM (in response to alesj)"alesj" wrote:
So, what would be a good entry point into this in our classloading?
Part of ClassLoadingPolicy?
The entry point should be the module, which probably mean it delegates
to the ClassLoadingPolicy (when the module is implemented by ClassLoadingPolicy :-)
But this is only for the Class visitor.
The rest of the annotation processing should be in the deployers project.
To address Kabir'rs issue I'd suggest something like:public interface ClassVisitor { void visit(URL classURL, String className, ClassLoader cl); }
So you can do URL.openStream() and pass it to javassit. -
3. Re: Annotation scanning
adrian.brock Apr 22, 2008 5:53 AM (in response to alesj)"adrian@jboss.org" wrote:
To address Kabir'rs issue I'd suggest something like:public interface ClassVisitor { void visit(URL classURL, String className, ClassLoader cl); }
Actually I'd suggestpublic interface ClassVisitor { void visit(ClassContext cc); }
Then we can add new parameters and ease of use methods to ClassContext
as required. e.g.
ClassContext.getBytes();
which will do all the work to open the stream and read the bytes from it. -
4. Re: Annotation scanning
starksm64 Apr 22, 2008 1:20 PM (in response to alesj)"kabir.khan@jboss.com" wrote:
One point: For the purposes of AOP, the classes must NOT be loaded when scanning for annotations. If they are loaded, then we can not do loadtime weaving. The annotation scanning should use javassist instead to look for annotations.
If that's the case then to be general the metadata project/AnnotationMetaDataDeployer need to make this change. Currently they do load classes in the context of the deployment class loader during the POST_CLASSLOADER phase. We may be providing pass through support for other layers annotations though (webservices, rest, jpa) that need a view of the annotation. Are we going to have to pass the javassist view for these? -
5. Re: Annotation scanning
adrian.brock Apr 23, 2008 7:07 AM (in response to alesj)"scott.stark@jboss.org" wrote:
"kabir.khan@jboss.com" wrote:
One point: For the purposes of AOP, the classes must NOT be loaded when scanning for annotations. If they are loaded, then we can not do loadtime weaving. The annotation scanning should use javassist instead to look for annotations.
If that's the case then to be general the metadata project/AnnotationMetaDataDeployer need to make this change. Currently they do load classes in the context of the deployment class loader during the POST_CLASSLOADER phase. We may be providing pass through support for other layers annotations though (webservices, rest, jpa) that need a view of the annotation. Are we going to have to pass the javassist view for these?
There's no problem with passing the annotations as long as we don't load
the classes that have those annotations until AOP has had the chance to enhance them.
i.e.
* parse the class file using javassist
* read the annotation and create metadata
* aop enhances the classes
* services load the enhanced class from the classloader -
6. Re: Annotation scanning
alesj Apr 23, 2008 8:51 AM (in response to alesj)No idea where to start. :-)
"adrian@jboss.org" wrote:
The entry point should be the module, which probably mean it delegates
to the ClassLoadingPolicy (when the module is implemented by ClassLoadingPolicy :-)
Where in Module?
How/what to delegate to ClassLoaderPolicy (OK, probably preparing all these abstract methods that eventually get implemented in ClassLoaderPolicyModule)?
Who then triggers this?"adrian@jboss.org" wrote:
But this is only for the Class visitor.
What are we visiting?
Or where do we get class url?
What's the info we're gathering?
Or how to keep it? MDR as we do in MC?"adrian@jboss.org" wrote:
The rest of the annotation processing should be in the deployers project.
What do you consider as rest?
I can start hacking something on my own, but it's probably 99,9% chance of getting it wrong, if not even more. :-) -
7. Re: Annotation scanning
adrian.brock Apr 23, 2008 10:21 AM (in response to alesj)I just did a ** COMPLETELY UNTESTED** commit that shows the basic outline
of how I think it should work.
See: svn diff -c 72623
Once this works, i.e. it is tested, you can write a generic annotation deployer
that runs off the module.
Something like:public GenericAnnotationDeployer extends AbstractRealDeployer<Module> { public GenericAnnotationDeployer() { super(Module.class); setStage(DeploymentStages.POST_CLASSLOADER); } public void deploy(DeploymentUnit unit, Module module) { module.visit(new MyVisitor()); } public class MyVisitor extends ClassVisitor { public void visit(ResourceContext context) { // Annotation processing here } } }
This approach has a number of advantages:
1) This is a generic classloader resource visitor that understands the
classloading rules. i.e. nested roots are not processed twice, the
include/exclude filters are applied, etc.
2) Although the example above visits classes it is generic enough to work
for resources (or anything else you want to filter).
3) The current visit is implemented for the VFSClassLoader. But it could
be done for any classloader plugged in as a Module.
4) The VFS api is not exposed through this api so there can be no complaints
from other projects about JBoss dependencies. The ResourceContext
exposes things like the URL, name, classLoader, InputStream, bytes
of the resource which can be easily used in other projects.
5) It doesn't require any classloading to do the visit. It only requires
the classloader to exist. But this could be relaxed since we only require that
to include it in the ResourceContext in case somebody wants to actually
do classloading.
6) The deployer can get on with doing what it does best. Processing annotations
rather than worrying about classloading rules or where classes are located, etc.