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
>
