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

[emuckenhuber]

"dimitris at jboss.org" wrote : Rather than keep going with the dog-fight, why not putting down the exact requirements/usecase for this module (papaki), or is this already discussed elsewhere?
  | 

I haven't found a discussion on the goals of papaki - so i'll just add a few thoughts. Not all related to papaki, but just describing some of the problems i see with the annotation scanning. Maybe that helps that we can define clearer requirements what papaki should provide and what has to be done elsewhere.

* unified API, independent of the scanning strategy (precompiled or runtime) - as when writing deployers integration code it should not matter where this information comes from. The precompiled index has to be optional, since the spec requires runtime scanning. So either a precompiled index exists or we have to generate it during deployment time.
So that we really have a reusable index, which should be used by all deployers and we only do scanning once (or use the index).

* 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.
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.

* jboss-mdr integration - this index should be reused in the MDR as well, as mentioned earlier in this thread.

* 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.

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

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