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 <simonetrip...@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 <strub...@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-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
