All of this already exists. ;-)I hacked my local trunk (6) build to use jboss-scanning.xml and don't see much of an impact on boot performance. Prior to the jboss-scanning.xml changes, we were scanning about 600 classes for annotations. After the changes, we scan zero classes for annotations (as per trace logging in o.j.d.p.a.GenericAnnotationResourceVisitor). My local timings are:
* You should have a AnnotationScanner deployer that scans jars for annotations and puts an annotation database somewhere in memory that other deployers can reference. (This might already exist, I don't know).
It is called AnnotationEnvironment, and it's part of the deployment's attachments.
It's already used to help Metadata get annotation info.
But how it's done in Metadata is bad/wrong.
* If a file META-INF/no.scan exists in a jar, then don't scan the file. This allows libraries to exclude themselves from scanning.
* If a file META-INF/scan.only exists it will contain a newline delimited list of class names to scan. Only scan those class names.
This is called jboss-scanning.xml.
- http://www.jboss.org/community/wiki/JBoss5custommetadatafiles
Started in 35s:304ms
Started in 33s:229ms
Started in 34s:445ms
After adding jboss-scanning.xml:
Started in 33s:324ms
Started in 34s:163ms
Started in 33s:957ms
We already exclude all of our boot.
See metadata-deployer-jboss-beans.xml:
- http://anonsvn.jboss.org/repos/jbossas/branches/Branch_5_x/server/src/etc/deployers/metadata-deployer-jboss-beans.xml
_______________________________________________
jboss-development mailing list
jboss-development@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development