commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Korherr <jakob.korh...@gmail.com>
Subject Re: [sandbox] [classscan] classscan API design review needed
Date Wed, 27 Jul 2011 09:25:17 GMT
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

2011/7/27 Simone Tripodi <simonetripodi@apache.org>:
> 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] http://s.apache.org/Vsb
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Tue, Jul 26, 2011 at 11:19 PM, Mark Struberg <struberg@yahoo.de> 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] https://github.com/struberg/Apache-commons-classscanner/blob/b45c1b6080e91f6e36f7b7a39aa1b2c4d7bde1e0/classscan-api/src/main/java/org/apache/commons/classscan/api/ScanJob.java
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



-- 
Jakob Korherr

blog: http://www.jakobk.com
twitter: http://twitter.com/jakobkorherr
work: http://www.irian.at

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message