commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Commons Wiki] Update of "classscan" by Charles Honton
Date Sat, 07 Jul 2012 20:32:39 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 Charles Honton:

  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`.
- === Goals ===
+ == Goals ==
-  * Implementation details (BCEL, ASM, etc.) shouldn't be allowed to "bleed out" into client-facing
+  * Implementation details (BCEL, ASM, etc.) shouldn't be allowed to "bleed out" into consumer-facing
   * any `new URL()` handling in the scanner must be pluggable. The underlying file systems
on different systems are just too different.
   * Performance
   * Flexibility
+ == Desired Capabilities ==
+ === Filtering ===
+ ==== Marker File ====
+ Multiple frameworks have a "marker" file that indicates a jar is eligible for processing.
 A ClassScan consumer will want to be able to filter a jar based on the maker file criteria:
+  * JSR-299 CDI - META-INF/beans.xml
+  * JSR-314 (JSF2) - META-INF/faces-config.xml
+  * JPA - META-INF/persistence.xml
+  * service provider - META-INF/services/''''
+  * Servlet/JSP - WEB-INF/web.xml (this is also marked by war suffix)
+ ==== Content ====
+ Consumers will require different levels of granularity:
+  * Elements in classpath (Jar or File locations)
+  * Classes in each location
+  * Interfaces of each class
+  * Fields and/or methods of each class
+  * Annotations on each of the above
+ === Cache ===
+  * Scan classpath and classes once for multiple consumers
+  * Balance memory v. time
- == development ideas ==
+ == 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.
@@ -22, +45 @@

   * Defines basic SPIs for other high-level modules (assuming SPI approach)
    * spi to plug in URL handling
    * spi to plug in class digester
-   * spi to plug in introspection of different ClassLoader types 
+   * spi to plug in introspection of different ClassLoader types
+  * Hierarchy Walking
+  * Cache 
  ==== BCEL ====
   * BCEL-based class digester available
@@ -35, +60 @@

  ==== 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]`)
+ * Domain Specific Language parsers on top of hierarchy walker to filter which classes are
of interest
  ==== 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.? ====

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message