tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: 3.0 annotations ?
Date Tue, 04 Aug 2009 21:28:02 GMT

On Aug 4, 2009, at 1:22 PM, Costin Manolache wrote:

> Thanks - so objectweb instead of BCEL.
> I'll try it out - it's a bit different from what I had in mind, it  
> looks
> like xbean-finder first finds all classes and
> than reads the files using the class loader ( but not Class.forName,  
> which
> is good ) and keeps track of all annotations.
>
> I was thinking of a simple File/zip based scanning, without any  
> class loader
> - and just select the few
> annotations we need and write a web.xml fragment as it goes, without  
> keeping
> anything in memory.

I've been thinking about adding in a sort of "filter" for the  
scanning.  Something that could be supplied in the constructor.   
Something simple like:

     public interface Filter {
         boolean accept(String annotationName);
     }

Then you would implement that and be guaranteed to only have metadata  
for the annotations you cared about.  In this case @Filter and  
@Servlet.   I actually already experimented with it in a little copy  
of the ClassFinder, would only take like 10 minutes to integrate the  
change in.

In terms of keeping things in memory, there really isn't that much in  
memory, especially if you filter out the annotations you don't care  
about.  As far as needing a classloader, that is only there so we can  
return a list of classes (or methods, or fields, etc.) when you ask  
for things that have a specific annotation.  Someone has to load the  
class to get the annotation data so it's just in the API for  
convenience.

Another thing I've been experimenting with is some additional byte  
code reading optimizations.  Basically if you know your annotations  
are class-level annotations only, you can get a boost in scan time by  
just reading the top of the class def and skipping the rest.  The  
technique is proven, just need to think of an elegant way to specify  
that is the behavior you want.

> I guess in 3.0 a deploy tool / phase is absolutely needed - we can't  
> have
> tomcat scan all files
> each time it starts up, so the user will have to do something to re- 
> initiate
> the scanning. Like touch
> web.xml, or run a re-deploy tool.
>
> I'm curious - why objectweb and not BCEL ?

We (OpenEJB) already had a bunch of code using ASM so that's what I  
went with -- I wrote it OpenEJB and moved it over into XBean later so  
others could use it.  I also know a couple ASM guys and find it's good  
getting direct tips for best performance as well as getting any  
features in we need.

-David


>
>
> On Tue, Aug 4, 2009 at 12:50 PM, David Jencks  
> <david_jencks@yahoo.com>wrote:
>
>> We use xbean-finder for this in geronimo/openejb/etc.
>>
>> http://repo2.maven.org/maven2/org/apache/xbean/xbean-finder/3.5/
>>
>> https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-finder
>>
>> We also have a servlet 3.0 spec jar I've been trying to keep up to  
>> date
>> with the glassfish javadocs.
>>
>>
>> https://repository.apache.org/content/repositories/snapshots/org/apache/geronimo/specs/geronimo-servlet_3.0_spec/1.0-EA-SNAPSHOT/
>>
>>
>> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec
>>
>> thanks
>> david jencks
>>
>>
>> On Aug 4, 2009, at 11:11 AM, Costin Manolache wrote:
>>
>> Hi, anyone working on the @Filter, @Servlet annotation scanner for
>>> tomcat-trunk ?
>>> If I'm understanding it correctly, tomcat will have to read all  
>>> files in
>>> classes and lib and look for the
>>> annotation - and I would guess the only reasonable option is  
>>> looking at
>>> bytecode.
>>> I checked BCEL - seems reasonably easy, but if anyone has  
>>> different code -
>>> I
>>> would rather reuse it in
>>> tomcat-lite :-)
>>>
>>> BTW - there is a typo in javax.servlet.ServletRegistration -  
>>> should be
>>> Dynamic, not Dynmaic.
>>> I can fix it next time I get some free time...
>>>
>>> Costin
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message