Ales Justin wrote:
> All of this already exists. ;-)
>
>> * 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
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:
Interesting findings. Although keep in mind we have a few other paths
where scanning occurs, usually post-classloading. Anything that uses the
MDR for example (AOP is one example)
--
Jason T. Greene
JBoss, a division of Red Hat