commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [sandbox] [classscan] classscan API design review needed
Date Wed, 27 Jul 2011 14:36:39 GMT
On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr <> wrote:
> Hi Mark, Simone,
> I would prefer a way in which the classscan-clients can tell the
> classscan-server in what they are interested in via an API like Mark
> proposed (e.g. subscribe()) before the scanning of a specific artifact
> (e.g. jar) starts. I guess this could be kinda like the
> ProcessAnnotatedType API in CDI. For example, the classscan-server
> discovers a jar, then asks all its clients if the jar should be
> scanned (--> clients can perform checks for beans.xml or
> faces-config.xml) and if at least one client says yes, it will be
> scanned. Then the classscan-server knows exactly which
> jars/wars/packages/... need to be scanned and which don't (thus
> improving performance). Then while scanning, the classscan-server
> calls the specific callback methods only on the subscribed
> classscan-clients.
> Regards,
> Jakob

Hi, Jakob--
  I know that retaining the ability to select particular classpath
elements (or in xbean-finder terms, Archives) for scanning by a
particular client is one of Mark's top priorities, so this is
definitely on the table.  Maybe we should start a page in the Commons
wiki to enumerate all the desired features and hopefully a comfortable
set of APIs will start to gel.


> 2011/7/27 Simone Tripodi <>:
>> 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
>> cooperate!!!
>> WDYT? Hope there will be the chance to release yet another great
>> commons tool soon!!!
>> All the best,
>> Simo
>> [1]
>> 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:
> --
> Jakob Korherr
> blog:
> twitter:
> work:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message