10:59 a.m.
"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/mai...
|
| 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#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...