commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [classscan] organization
Date Tue, 05 Jun 2012 16:33:31 GMT
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 <gudnabrsam@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_Honton@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" <gudnabrsam@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_Honton@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:gudnabrsam@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-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message