commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <>
Subject Re: [sandbox] [classscan] classscan API design review needed
Date Wed, 27 Jul 2011 07:10:26 GMT
Hi Mark!!!
after had a (quick, honestly) look at your APIs I'm more convinced we
can merge our efforts to provide our users a kickass library to scan
the classpath.

Your ScanJob class could be configured with my Meiyo EDSL filters[1]
instead of passing parameters to the constructor, allowing users
expressing more complex ScanJob settings, like excluding/including
classes under specific packages annotated whit specific annotations
that implement interface X etc etc etc
I have the feel that while you focused on performances, I was more
focused on end users APIs, it would be a shame if we do not

WDYT? Hope there will be the chance to release yet another great
commons tool soon!!!
All the best,


On Tue, Jul 26, 2011 at 11:19 PM, Mark Struberg <> wrote:
> Hi folks!
> We need a few idea and brainstorming on the filter/selection mechanism for our new classscan-api
(yes, 3 's' in classscan).
> There are some specs which require some marker files to actually enable the class scanning.
E.g. the JSR-299 CDI spec defines that only jars with META-INF/beans.xml get scanned. For
JSR-314 (JSF2) you need to have a META-INF/faces-config.xml marker file present.
> Other frameworks don't have such a restriction, but most do.
> There are 2 ways to handle this:
> 1.) each classscan-client tells the classscan-server the list of marker files it needs.
> 2.) The classscan-client registers a Filter callback (similar to Simos mechanism) and
the classcan-server calls a 'scanningJarStarted(...)' and scanningJarEnded (bet we find some
better name which also would fit in OSGi environments) and the Filter can call some veto()
or subscribe() to the classscan-server.
> We also need some way to include + exclude packages from the scanning. Any idea on the
API is welcome. The current ScanJob class (see my github [1]) which was supposed to be an
upfront information doesn't work out in the end I fear. But maybe it's a starting point for
our discussion.
> txs and LieGrue,
> strub
> [1]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message