geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: The way to scan annotation in Geronimo 3.0
Date Wed, 17 Mar 2010 19:37:40 GMT

On Mar 17, 2010, at 7:02 AM, Ivan wrote:

> Hi,
>    While working on Servlet 3.0, it is required to scan WebServlet  
> annotations in the specified jar file.

Can you be more specific about what you need?  Is this really scanning  
specific jars within a war, or an entire war inside an ear bundle?  If  
it is the second case, I think we should solve this by turning ears  
into one-bundle-per-module.

> In the past, we could use the classfinder with a temp url  
> classloader, while in the new OSGI environment, there is a  
> BundleClassFinder is added in the framework. But I could not  
> configure it to only scan the specific parts of the bundle. I am  
> thinking we might need to introduce some more functions to it :
>    a. Something like DiscoveryPolicy, with it, we could ask the  
> BundleClassFinder to scan parts of the bundle file according to the  
> url, like web-inf/a.jar. Or only scan the classes in the bundle  
> classpath.
>    b. Use ASM as much as possible, currently, seems that  
> BundleClassFinder may load all the classes in the scanning process.  
> It might be performance issue in the runtime.
>    Any comment ?

I needed some annotation scanning code for connector so I combined the  
asm code from xbean-finder (moved to an abstract superclass) and  
Jareks really nice bundle scanning code in BundleResourceFinder in  
kernel to come up with a BundleAnnotationFinder that does what I want  
so far.  See XBEAN-145 and rev 924429 in geronimo-kernel.

I don't have a problem with introducing a bundle-classpath filter in  
BundleResourceFinder if we actually need it.

I think all this scanning code should end up in somewhere more easily  
accessible than geronimo-kernel so e.g. openejb can use it.  I thought  
it would be a good idea to discuss where it should go before moving or  
duplicating it so I came up with the 2-part solution above.  One  
possibility is xbean-finder; I don't know if its a good idea to have  
one jar that deals with "finding" in both osgi and non-osgi  

david jencks

> -- 
> Ivan

View raw message