I'll take a look at this after I'm done with the async stuff

On 08/04/2009 03:28 PM, David Blevins wrote:
>
> 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
>
>


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