[jboss-dev] Improving scanning performance

Jason T. Greene jason.greene at redhat.com
Tue Jun 16 17:00:03 EDT 2009


Scott Marlow wrote:
> 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



More information about the jboss-development mailing list