(James's response came in while I was typing, and yes! He is correct!) On Tue, Jun 5, 2012 at 10:17 AM, Honton, Charles <charles_hon...@intuit.com> wrote: > Matt, > > What particular approaches do you have in mind?
It's not just me, and others (struberg? dblevins?) could probably describe things better. A simple example that is within my grasp: When you scan the classpath, the results can be cached so that subsequent classes' accesses of class scanning information don't incur the execution cost of a scan. This caching has associated memory costs, however, so it is conceivable that an application running in a memory-rich context can afford to improve performance with the cache, while some other application running in a memory-constrained context can opt to forego the cache. Taking an SPI approach then allows the library to be configured using appropriate modules with no further configuration required. Another module that will provide its own SPI will be more or less what you see at https://github.com/struberg/Apache-commons-classscanner/tree/master/classscan-api/src/main/java/org/apache/commons/classscan/api . > > > How is xbean-finder going to be plugged in? Is classscan to be dependent > upon xbean-finder or vice versa? What functionality will be required from > the dependency? > xbean-finder could be plugged in as an alternative to your existing bcel-based MetaRegistry implementation. Matt > Thanks, > chas > > On 6/5/12 7:26 AM, "Matt Benson" <gudnabr...@gmail.com> wrote: > >>I would still say that time is now. We are going to want to support >>different approaches to interacting with the class scanning library, >>some of which may not be mutually compatible. We are going to want to >>be able to plug in Geronimo's xbean-finder and see how it performs, >>etc. We have so many interested participants that IMO we really need >>the flexibility of multiple modules. >> >>Matt >> >>On Mon, Jun 4, 2012 at 10:47 PM, Honton, Charles >><charles_hon...@intuit.com> wrote: >>> I'd like to wait until we have use cases that require reorganization. >>>I suspect that we're not going to want to replace BCEL with asm, but we >>>might need to support additional URL types. (I'm sure we're going to >>>need to support the JBoss vfs URLs) Plugging in URL providers may be >>>smaller than a multi-module project. >>> >>> Regards, >>> chas >>> >>> -----Original Message----- >>> From: Matt Benson [mailto:gudnabr...@gmail.com] >>> Sent: Sunday, June 03, 2012 8:40 AM >>> To: dev@commons.apache.org >>> Subject: [classscan] organization >>> >>> I propose that we, in the immediate future, reorganize [classscan] >>> into multiple modules. I fully expect that by the time we get >>> everyone's input/features/alternative implementations for X/Y/Z in >>> place, we will want the flexibility. I am fine with starting small, >>> e.g. core/bcel modules, although I would expect that bcel might >>> eventually be moved beneath another division of "scanners" or the >>> like. >>> >>> The technical hurdle to doing this is that MetaRegistry currently >>> references oacc.bcel.Cache, mapping it to its SINGLETON reference. I >>> don't see that this is necessary; I would prefer that the bcel module >>> provide an entry in META-INF/services. It's not even necessary that >>> we upgrade to Java 6 for this; Java 6 users can use ServiceLoader >>> while those using Java 5 can use whatever workalike option they prefer >>> or instantiate the MetaRegistry implementation directly. In any case >>> core should not depend on a particular scanning package/module. I >>> don't JFDI because (a) I don't have time just at the moment, and (b) I >>> like consensus. Thoughts? >>> >>> Matt >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>For additional commands, e-mail: dev-h...@commons.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
