I guess another concept would be what Matt is talking about. It would be the different implementations of how to interpret the bytecode without embodying the entire class structure in-memory at runtime. Again, each of these "scanners" would still deliver events to the listeners the same way.
On Tue, Jun 5, 2012 at 12:33 PM, James Carman <ja...@carmanconsulting.com>wrote: > The way I see a class scanning library, it basically has these pieces of > functionality: > > 1. Defining what to search (locations, filters, etc.). In my mind, I see > a ClassFileSource abstraction or something. > 2. Defining what to do with stuff when you find it (perhaps an event-based > API with "listeners"). ClassScanListener (onField, onClass, onInterface, > onAnnotation, etc.)? > 3. Defining what to do with the information once you find it (some > listener might build up some database of information that you can query). > > I have not had a chance to play with what Charles has done here. I'm just > trying to get my ideas out there so I don't forget them! :) > > > On Tue, Jun 5, 2012 at 12:05 PM, Matt Benson <gudnabr...@gmail.com> wrote: > >> (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 >> >> >
