Hi Jakob, I'm worried I was not able to explain my ideas well; my intentions are not proposing to modify how classscan behaves, but rather how it looks! Having an expression language rather than a configuration based on n parameters is IMHO still a valid contribution that the existing sandbox component could bring in the new one. +1 to Matt's idea, I'll start adding my contributions as soon as possible. Have a nice day, all the best!!! Simo
http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Wed, Jul 27, 2011 at 7:13 PM, Matt Benson <gudnabr...@gmail.com> wrote: > http://wiki.apache.org/commons/classscan > > On Wed, Jul 27, 2011 at 9:59 AM, Jakob Korherr <jakob.korh...@gmail.com> > wrote: >> +1 >> >> Regards, >> Jakob >> >> 2011/7/27 Matt Benson <gudnabr...@gmail.com>: >>> On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr <jakob.korh...@gmail.com> >>> 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. >>> >>> Matt >>> >>>> >>>> 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 >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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 >> >> > > --------------------------------------------------------------------- > 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
