Cool. Feel free to ping me in freenode if you want; dblevins in
#openejb, #geronimo and #asfinfra.
-David
On Aug 7, 2009, at 9:30 AM, Filip Hanik - Dev Lists wrote:
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_jen...@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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
