On Jun 9, 2011, at 1:29 PM, Simone Tripodi wrote: > Hi all guys, > before start working on Digester3 I experimented on GitHub, taking > inspiration from Google Guice APIs, embedded EDSLs in configuration > classess to solve 2 different kind of problems: > > * ClassPath scanning[1]: declare with fluent APIs a class path > scanner, filering classes users are interested in via fluent logic > language, and declaring actions have to be performed, once interested > classes have found. We already discussed about that idea time ago, but > it has been improved; > > * Class scanning[2]: Java users often create framework/libraries > based on Java5 MetaData Annotations interpreted at runtime, the > pattern they usually have to apply is: given a class, visiting all the > class inheritance hierarchy, and getting fields/constructors/methods > for each class; once found an (AnnotatedElement, Annotation) pair, > they have to perform an action. > So, the implemented classes aim to reduce the boilerplate and > redundant code simply by declaring actions that have to be performed > once the pairs (AnnotatedElement, Annotation) are found. >
I accomplished this in the work I've been doing on Log4J 2.0 by borrowing on some code I found somewhere else at Apache. You can see it at https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/ResolverUtil.java. It is used by https://svn.apache.org/repos/asf/logging/log4j/branches/BRANCH_2_0_EXPERIMENTAL/rgoers/log4j2-core/src/main/java/org/apache/logging/log4j/core/config/plugins/PluginManager.java. Of course, I have no idea if these bear any relationship to what you have done. Ralph
