commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Commons Wiki] Update of "classscan" by MattBenson
Date Wed, 06 Jun 2012 00:38:27 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification.

The "classscan" page has been changed by MattBenson:
http://wiki.apache.org/commons/classscan?action=diff&rev1=4&rev2=5

- == classscan development ideas ==
+ The `[classscan]` component aims to provide a general-purpose library that can be used or
extended to satisfy any potential usage pattern requiring information about the identity and
structure of various classes provided by a given `ClassLoader`.
  
- The [classscan] component should provide a number of modules for composing "just the right"
scanning solution for a given context.  Some desire that these be configured using an SPI
approach.
+ === Goals ===
+  * Implementation details (BCEL, ASM, etc.) shouldn't be allowed to "bleed out" into client-facing
APIs.
+  * any `new URL()` handling in the scanner must be pluggable. The underlying file systems
on different systems are just too different.
+  * Performance
+  * Flexibility
  
+ == development ideas ==
+ These are '''ideas''' and might not all be adopted; that's what the consenus-building process
is for!
  
+  * Decompose into multiple modules to implement various subtasks in pluggable fashion.
+  * Define SPIs for aforementioned subtasks such that a given module can simply declare which
services it provides.
+  * For implementations of a given service that may/must wrap other implementations, consider
providing a default impl + a wrapper structure a la JSF
- === Requirements ===
-  * foo
-  * bar
-  * baz
-  * Implementation details (BCEL, ASM, etc.) shouldn't be allowed to "bleed out" into client-facing
APIs.
  
  === High-Level Modules ===
  
  ==== Core ====
-  Providing meta-model rooted at `org.apache.commons.classscan.MetaRegistry`
+  * Provides meta-model rooted at `org.apache.commons.classscan.MetaRegistry` but centering
on `oacc.MetaClassLoader` which emphasizes `[classscan]`'s per-classloader organization.
+  * Would define basic SPIs for other high-level modules (assuming SPI approach)
  
- ==== Scanner ====
+ ==== Scanners ====
   * BCEL-based impl available
   * xbean-finder could be plugged as a separate service impl
  
+ xbean-finder skips certain aspects of scanning (e.g. find all implementations of interface
`Foo`) unless configured otherwise.  This is an interesting concept that might be extended
profitably to an "iterative scan approach," allowing explicit requests for certain types of
information to trigger a "deeper" scan than that for which a given scanner impl is configured
to do by default.
+ 
  ==== Reactor ====
+ This is perhaps the right level at which to provide higher-level mechanisms for working
with the info in a `MetaClassLoader`.
- Based on the ideas of Mark Struberg and concepts in the [meiyo] sandbox component (expected
to be more or less subsumed by [classscan])
+ Based on the ideas of Mark Struberg and concepts in the `[meiyo]` sandbox component (expected
to be more or less subsumed by `[classscan]`)
+ 
+ ==== Cache ====
+ With this approach, `MetaRegistry` would have a default implementation that simply deferred
to the available '''scanner'''.  The default implementation could then be wrapped by a `MetaRegistry`
implementation that would provide a general-purpose cache for the class metadata (see "wrapper
structure" idea under "development ideas").  This way caching could be implemented independently,
and reusably, from scanning.  This might or might not be compatible with the "iterative scan
approach" ideated in the '''Scanners''' section.
  
  ==== Etc.? ====
  
- 
- ==== TODO ====
- 
-  * any new URL() handling in the scanner must be pluggable. The underlying file systems
on different systems are just too different.
- 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message