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: http://wiki.apache.org/commons/classscan?action=diff&rev1=6&rev2=7 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 APIs. + * Implementation details (BCEL, ASM, etc.) shouldn't be allowed to "bleed out" into consumer-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 + == 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/''interface.to.be.implemented'' + * 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: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
