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
