Hi James! Feel free to suggest a better name. For the client we also could use 'consumer' but not sure how to name the piece which does the actual scanning. Ideas?
txs and LieGrue, strub --- On Thu, 7/28/11, James Carman <jcar...@carmanconsulting.com> wrote: > From: James Carman <jcar...@carmanconsulting.com> > Subject: Re: [sandbox] [classscan] classscan API design review needed > To: "Commons Developers List" <dev@commons.apache.org> > Date: Thursday, July 28, 2011, 11:01 PM > Why the client / server > nomenclature? Makes it sound too heavyweight > On Jul 28, 2011 4:20 PM, "Mark Struberg" <strub...@yahoo.de> > wrote: > > Hi Simo! > > > > Sorry, I guess I was not clear enough! > > > > Some specs require us to pickup this info from some > config (e.g. > META-INF/beans.xml). The classscan-client needs to pickup > this configuration > from there and must tell it the classscan-server somehow. > This could be some > form of Domain Specific Language, but I'm not sure if this > isn't a complete > overkill here. > > > > It could be interesting to use the DSL approach for > the callback filters > of course. > > > > LieGrue, > > strub > > > > --- On Thu, 7/28/11, Simone Tripodi <simonetrip...@apache.org> > wrote: > > > >> From: Simone Tripodi <simonetrip...@apache.org> > >> Subject: Re: [sandbox] [classscan] classscan API > design review needed > >> To: "Commons Developers List" <dev@commons.apache.org> > >> Date: Thursday, July 28, 2011, 6:44 PM > >> Hallo Mark, > >> > >> > > >> > Some classscan-clients maybe first need to > read some > >> config files for getting exclude/include info. > >> > > >> > >> sorry for being repetitive but that's here too > that I > >> suggest adopting > >> the Meiyo's alike way of configuring the component > via EDSL > >> instead of > >> config files - there's no reason to adopt an > approach that > >> reminds old > >> J2EE/Spring configurations - unless we aim be > integrated > >> ;) > >> > >> I had the same problem with moinmoin but honestly > I don't > >> remember how > >> I figured out :/ > >> > >> Buona serata! ;) > >> Simo > >> > >> > --------------------------------------------------------------------- > >> 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
