[JBoss Microcontainer Development POJO Server] - Re: integration with the Papaki annotation indexer/repositor
by alesj
"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.
Not to mention another very good example why re-using existing libs is good. ;-)
"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.
"emuckenhuber" wrote :
| * jboss-mdr integration - this index should be reused in the MDR as well, as mentioned earlier in this thread.
|
Yes.
But his is just a matter of properly populating MDR's MetaDataLoaders.
e.g. sort of an MetaDataLoaderToAEAdapter
"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 ;-)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262933#4262933
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262933
14 years, 6 months
[Embedded JBoss Development] - Re: Embedded and Bootstrap Development
by manuel.chinea
ALR,
i checked out the code last night and saw it. Also saw the jira issue and its dependency. If i undestand correctly, the sub-projects arde divided this way: bootstrap-api, bootstrap-spi and bootstrap-impl, and the depend from one another in this way: impl depends on spi, spi depends on api. Also, each one of them is spplitted in base, as and mc (as depends on mc, mc on base).
Now, the bug. checking the class BasicJBossASServerConfig, i see no reference to any server object. I also see BasicJBossASServerConfig has this annotation @ManagementObject(name = "jboss.system:type=ServerConfig"...). The closest "server" class i found is AbstractJBossASServerBase, which has this annotation @ManagementObject(name = AbstractJBossASServerBase.NAME_MANAGEMENT_OBJECT...). Now, i should use some lookup mechanism to get the server object in the config (1), or simply put a reference to the "server" object? (2) (i don't want to break any architectural or design decision here). If (1) is the answer, what would be the correct mechanism?. (or a third one, (1) + (2) using annotations?).
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4262929#4262929
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4262929
14 years, 6 months