Hallo Mark!!!

>
> 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

Got it, my fault that didn't pay enough attention on your previous
messages. IIUC these are some J2EE spec, right? I'm asking because I'm
not really familiar with J2EE - always worked with alternative
solutions.

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.
>

I continue annoying people with EDSL because I immagine a scenario
where a single Configuration class for classscanner could easily
specify all the settings with an Embedded DSL, included resources that
have to be skipped, something like following below.
So, why overkill? It is pure Java that can be quickly mapped to
whatever we need - defining a textual/properties/xml/json/... file,
parsing and mapping it to Java structures requires IMHO more effort -
and it can be achieved in a second step, just extending the
Configuration class.

Promised that I won't you get bored anymore with that topic ;) :P
Have a nice day, alles gute!!!
Simo

new AbstractConfiguration()
       {

           @Override
           public void configure()
           {
               excludeArchive( jar or zip );
               excludePackage( "a.b.c" ); // a.b.c only, for example
               excludePackage( "d.e.f.*" ); // d.e.f and all
subpackages, for example

               ifMatches( inSubpackage( "org.apache.commons.classscaner" ).
                               and( isPublic() )
                               .and( not( isAbstract() ) )
                               .and( not( isAnnotation() ) )
                               .and( not( classNameMatches( ".*TestCase" ) ) ) )
                         .handleWith( new ClassPathEntryHandler()
                         {

                             public void doHandle( String path,
Class<?> classPathEntry )
                             {
                                 doWhatEverWeNeed();
                             }

                         } );
           }

       }

> 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

Reply via email to