You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Mark Struberg <st...@yahoo.de> on 2011/07/26 23:19:10 UTC
[sandbox] [classscan] classscan API design review needed
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Simone Tripodi <si...@apache.org>.
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 <si...@apache.org> wrote:
>
>> From: Simone Tripodi <si...@apache.org>
>> Subject: Re: [sandbox] [classscan] classscan API design review needed
>> To: "Commons Developers List" <de...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Simone Tripodi <si...@apache.org>.
what about scanner/handler? :P
just my 2 cents, alles gute
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Fri, Jul 29, 2011 at 10:20 AM, Mark Struberg <st...@yahoo.de> wrote:
> 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 <jc...@carmanconsulting.com> wrote:
>
>> From: James Carman <jc...@carmanconsulting.com>
>> Subject: Re: [sandbox] [classscan] classscan API design review needed
>> To: "Commons Developers List" <de...@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" <st...@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 <si...@apache.org>
>> wrote:
>> >
>> >> From: Simone Tripodi <si...@apache.org>
>> >> Subject: Re: [sandbox] [classscan] classscan API
>> design review needed
>> >> To: "Commons Developers List" <de...@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-unsubscribe@commons.apache.org
>> >> For additional commands, e-mail: dev-help@commons.apache.org
>> >>
>> >>
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Jakob Korherr <ja...@gmail.com>.
Hi,
What about provider and subscriber or something similar? server/client
really sounds very heavyweight..
Regards,
Jakob
2011/7/29 James Carman <jc...@carmanconsulting.com>:
> Why the client / server nomenclature? Makes it sound too heavyweight
> On Jul 28, 2011 4:20 PM, "Mark Struberg" <st...@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 <si...@apache.org> wrote:
>>
>>> From: Simone Tripodi <si...@apache.org>
>>> Subject: Re: [sandbox] [classscan] classscan API design review needed
>>> To: "Commons Developers List" <de...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Mark Struberg <st...@yahoo.de>.
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 <jc...@carmanconsulting.com> wrote:
> From: James Carman <jc...@carmanconsulting.com>
> Subject: Re: [sandbox] [classscan] classscan API design review needed
> To: "Commons Developers List" <de...@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" <st...@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 <si...@apache.org>
> wrote:
> >
> >> From: Simone Tripodi <si...@apache.org>
> >> Subject: Re: [sandbox] [classscan] classscan API
> design review needed
> >> To: "Commons Developers List" <de...@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by James Carman <jc...@carmanconsulting.com>.
Why the client / server nomenclature? Makes it sound too heavyweight
On Jul 28, 2011 4:20 PM, "Mark Struberg" <st...@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 <si...@apache.org> wrote:
>
>> From: Simone Tripodi <si...@apache.org>
>> Subject: Re: [sandbox] [classscan] classscan API design review needed
>> To: "Commons Developers List" <de...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [sandbox] [classscan] classscan API design review needed
Posted by Mark Struberg <st...@yahoo.de>.
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 <si...@apache.org> wrote:
> From: Simone Tripodi <si...@apache.org>
> Subject: Re: [sandbox] [classscan] classscan API design review needed
> To: "Commons Developers List" <de...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Simone Tripodi <si...@apache.org>.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Mark Struberg <st...@yahoo.de>.
Hi Simo!
I think we need to meet somewhere in the middle anyway.
My code is most times pretty much targeted at a certain problem. Thus making it sometimes hard to extend later. The meiyo interfaces I looked at are otoh so generic that they could probably also serve as RFC-2324 HTCPCP/1.0 implementation - just kidding ;)
Nah serious, a few Ideas from Meyio (e.g. the Callback for the Filter) are really cool and we should incorporate them into classscan. A few other interfaces are imo a bit too generic.
The hardest nut will most probably be the design of the Filter.
The requirements are:
1.) performance
2.) exclude/include logic for packages
3.) must be able to collect different things for different classcan-clients
4.) perform the scan only once (should we allow lazy scanning?)
Some classscan-clients maybe first need to read some config files for getting exclude/include info.
I imagine to set the 'heavy granular' criterias like
* what to collect (class info, annotations on classes, annotations on fields, annotations on methods)
* which archives to collect
upfront.
The rest might get filtered via callbacks in a tree like manner. E.g. if a Filter from one classcan-client returns that it doesnt need this package, then we don't need to invoke this classcan-client until we are finished processing.
LieGrue,
strub
PS: the moinmoin wiki really su***s. It refuses to send me a register/pwd_recovery mail :( Will dump this info into the wiki once I get access.
--- On Wed, 7/27/11, Simone Tripodi <si...@apache.org> wrote:
> From: Simone Tripodi <si...@apache.org>
> Subject: Re: [sandbox] [classscan] classscan API design review needed
> To: "Commons Developers List" <de...@commons.apache.org>, gudnabrsam@gmail.com
> Date: Wednesday, July 27, 2011, 7:44 PM
> 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 <gu...@gmail.com>
> wrote:
> > http://wiki.apache.org/commons/classscan
> >
> > On Wed, Jul 27, 2011 at 9:59 AM, Jakob Korherr <ja...@gmail.com>
> wrote:
> >> +1
> >>
> >> Regards,
> >> Jakob
> >>
> >> 2011/7/27 Matt Benson <gu...@gmail.com>:
> >>> On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr
> <ja...@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 <si...@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 <st...@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-unsubscribe@commons.apache.org
> >>>>>> For additional commands, e-mail:
> dev-help@commons.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Simone Tripodi <si...@apache.org>.
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 <gu...@gmail.com> wrote:
> http://wiki.apache.org/commons/classscan
>
> On Wed, Jul 27, 2011 at 9:59 AM, Jakob Korherr <ja...@gmail.com> wrote:
>> +1
>>
>> Regards,
>> Jakob
>>
>> 2011/7/27 Matt Benson <gu...@gmail.com>:
>>> On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr <ja...@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 <si...@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 <st...@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-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Matt Benson <gu...@gmail.com>.
http://wiki.apache.org/commons/classscan
On Wed, Jul 27, 2011 at 9:59 AM, Jakob Korherr <ja...@gmail.com> wrote:
> +1
>
> Regards,
> Jakob
>
> 2011/7/27 Matt Benson <gu...@gmail.com>:
>> On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr <ja...@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 <si...@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 <st...@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Jakob Korherr <ja...@gmail.com>.
+1
Regards,
Jakob
2011/7/27 Matt Benson <gu...@gmail.com>:
> On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr <ja...@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 <si...@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 <st...@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Matt Benson <gu...@gmail.com>.
On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr <ja...@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 <si...@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 <st...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Jakob Korherr <ja...@gmail.com>.
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
2011/7/27 Simone Tripodi <si...@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 <st...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [sandbox] [classscan] classscan API design review needed
Posted by Simone Tripodi <si...@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 <st...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org