xbean-finder provides the basic functionallity for class scanning, but currently each EE container part (CDI, JSF, EJB, JPA, Servlet, BVAL) invokes the class scanning on it's own. Thus xbean-finder (*) will get invoked n times, scanning the classpath n times...
the commons-classscaner proposal will use xbean-finder (or better: a cleaned up version with removed deprecated code) under the hood. LieGrue, strub (*) there is not only xbean-finder. Libs can also just use plain Java ClassLoader to scan for annotations. In OpenWebBeans we currently use scannotation for it (though thinking about moving to xbean-finder since quite a while). >________________________________ >From: Romain Manni-Bucau <[email protected]> >To: [email protected]; Mark Struberg <[email protected]> >Sent: Friday, October 21, 2011 10:18 AM >Subject: Re: openejb jrat > > >hmm, > > >a common scanner already exists through xbean no? > >- Romain > > > >2011/10/21 Mark Struberg <[email protected]> > >you also have to distinguish between: >> >> >>1.) classpath scanning time itself >>2.) information extraction from the scanned classes >> >>As a whole container, we can reduce 1.) because this part could be shared >>between OpenEJB, OpenWebBeans, Tomcat, MyFaces, etc (all libs which do >>classpathscanning on their own currently). A few weeks back I dropped a >>classscanner proposal to the commons list. >> >>A rudimentarily working example is on my github [1] though there is lots of >>work needed in the filtering part still. >> >>The fundamental idea is that once the first 'classscan-client' requests a >>scanning result, the 'classscan-server' will load all registerd >>'classscan-clients' and will ask them what they need to scan for (marker >>files, which annotations, etc). Then it will do all the scan (via davids >>xbean-finder) in 1 go and afterwards the 'classscan-clients' can get the >>result of the scan which they requested. If a 'classcan-client' doesn't need >>the information anymore (all needed info stored into internal data structures >>after the bootup for example), it can unregister() itself so the >>classscan-server can free the memory. >> >>a.) first benefit is that we only do one physical class scan and bytecode >>parsing -> safes time >>b.) most libraries use Class.getAnnotations() Method.getAnnotations(), etc >>which fill up the PermGenSpace heavily (and permanently) because there are no >>methods in the ClassLoader to drop this information later. If we just store >>this info in standard Maps (via xbean-finder), then we can just clear the >>maps and release the memory once it's not needed anymore >> >> >>LieGrue, >>strub >> >>[1] https://github.com/struberg/Apache-commons-classscanner >> >> >> >> >>----- Original Message ----- >>> From: Romain Manni-Bucau <[email protected]> >>> To: [email protected] >>> Cc: >>> Sent: Thursday, October 20, 2011 10:43 PM >>> Subject: openejb jrat >>> >>> Hi, >>> >>> following the start up time of openejb i wondered where we were loosing time >>> exactly (even if scanning seems to be a good candidate), >>> >>> to have results just extract the zip, run start.sh (or something similar, >>> there is only one line in the script ;)) and when the window is opened open >>> the file openejb.jrat). Then go to hierarchy tab and you'll...that 60% of >>> the startup time is due to scanning. >>> >>> here are the info: http://people.apache.org/~rmannibucau/jrat.output.zip >>> >>> >>> - Romain >>> >> > > >
