In the servlet 3.0, while merging web-fragment and annotations, it says : --> After processing the web-fragment.xml, annotations from the corresponding fragment are processed to complete the effective metadata for the fragment before processing the next fragment. The following rules are used for processing annotations:
Also, according to sorting policy, if some webfagments are excluded (e.g. Absolute soring is used in web.xml, and some founded webfagments are not explicitly configured), those excluded jars should not be used for annotation scan, also TLD scan might be affected. Later, I would try to add something like filter to scanning classes. Scanning all the required classes/annotations is a good idea, but we might be some way to record where those classes are from. I hope that we could do all the annotations scanning together in the future. I agree that we move those code scanning classes to xbean, as they are not 'belonged to' the geronimo-kernel. 2010/3/18 David Jencks <[email protected]> > > 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 environments. > > thanks > david jencks > > -- >> Ivan >> > > -- Ivan
