yes, in openejb we set a finder / module but we don't manage what does a lib when we delegate.
IMHO it means a lib should be able to get already scanned stuff or allow spi (or equivalent) to do this job. but globally i think everybody is agree we need to make less useless scanning - Romain 2011/10/21 Mark Struberg <[email protected]> > 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 > >>> > >> > > > > > > >
