[jboss-dev-forums] [JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor

[emuckenhuber]

"alesj" wrote : "emuckenhuber" wrote : 
  |   | * jboss-metadata - for example jboss-metadata is just asking the AE to get a list of classes which have a given top-level annotation (e.g. @Stateful). Then loading the class and do a separate annotation processing with java reflect. This is also because AE does not have enough information about inheritance, which is needed for all the EE annotation processing.
  |   | 
  | But then you should not use java reflect, but JBoss Reflect. ;-)
  | Why?
  | Because this info is already present if we use McAnn, as McAnn already uses JBoss Reflect, and Reflect caches this info.
  | 
  | And this also shows that things go hand in hand, and that this inheritance check should not be part of annotation scanning.
  | 

I was talking about where the problems are and not what should be done in the end.

Since this seems to be a discussion about the requirements of a annotation scanning API - we might want to think of an easy to use API which covers 80% of the use cases. I agree that JBoss Reflect should be used instead of java reflect, but only in special cases. 

I still think that the class hierachy should be in the annotation API. Whether reflect is caching stuff or not, it is not using the index to avoid duplicate work?

"alesj" wrote : 
  | "emuckenhuber" wrote : 
  |   | Beside jboss-metadata there are not many users of AnnotationEnvironment, but we really should avoid having things like getClassloader().loadClass(metaData.getClassName()).getAnnotation(X) if possible.
  |   | 
  | Sure, leave it to JBoss Reflect. It's already there.
  | And with Reflect running on top of Javassist it's gonna be lazy as possible.
  | 

As said the problem is not jboss-metadata alone - other deployers are doing the same. 

"alesj" wrote : 
  | "emuckenhuber" wrote : 
  |   | * jboss-mdr integration - this index should be reused in the MDR as well, as mentioned earlier in this thread.
  |   | 
  | Yes.
  | But this is just a matter of properly populating MDR's MetaDataLoaders.
  | e.g. sort of an MetaDataLoaderToAEAdapter
  | 

AFAIK it is not done yet, that's why i listed it here.

"alesj" wrote : 
  | "emuckenhuber" wrote : 
  |   | * inclusion/exclusion of deployments, .jars, classes - we need a way to exclude stuff from annotation scanning, as we are mostly just doing too much scanning. Basically we already have jboss-scanning.xml - which makes sense for our own deployments. Still we need a programmatic way of excluding stuff like:
  |   |  - if the deployment is not an EE5/EE6 deployment we can just skip any annotation scanning,
  |   |  - if isMetaDataComplete()
  |   |  - afaik the new servlet spec requires to exclude .jars (web-fragments), where we should be able to skip scanning as well.
  | This is all already there, in Deployers.
  | Either as part of ScanningMetaData or AnnotationScanner's DeploymentUnit filters.
  | * e.g. http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/server/src/main/org/jboss/deployment/JBossMetaDataDeploymentUnitFilter.java
  | 
  | Web deployers should just properly push required info about fragments to this mechanisms.
  | e.g. using ScanningMetaDataBuilder (which you promised to write ;-)
  | 

First there should be no need for this DeploymentUnitFilter.

I agree with David suggesting that the annotations should get pushed to the index. So AE should be lazy, only doing stuff when it's called by the deployers. Then we could get rid of a separate filter implementation for each meta data type.

At least for jboss-metadata the following two methods should be enough (well as far as i can recall) as long as there are context information like AnnotatedInfo with declaringClass, method signature and similar stuff - but i think that's already there.


  | 1) AE.getClassesWithTypeAnnotation(Stateless.class);
  | 
  | and
  | 
  | 2) AE.getAnnotationsForClass("org.jboss.test.MyStatelesBean");
  | 
  | maybe for completeness:
  | 
  | 3) AE.getAnnotation(String clazzName, Annotation annotation);
  | 

Which basically means that 1) tells AE to scan the deploymentUnit classpath and 2) tells AE to recursively scan the class (this should also take annotation outside of the deploymentUnit into account). Of course all operations should be matched against the index, and if it's not there it has to be scanned at runtime.

Maybe there is even a need to override the ScanningMetaData within the deployer - so that web can exclude libraries, but a 2nd deployer e.g. BeanMetaDataDeployer (or whatever) would need to get the unfiltered DeploymentUnit - so this library would be partially added to the index (if it's not already there...)

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4263014#4263014

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4263014