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:43:21 GMT
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 <james@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 <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