commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [sandbox] [classscan] classscan API design review needed
Date Thu, 28 Jul 2011 12:02:19 GMT
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 <simonetripodi@apache.org> wrote:

> From: Simone Tripodi <simonetripodi@apache.org>
> Subject: Re: [sandbox] [classscan] classscan API design review needed
> To: "Commons Developers List" <dev@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 <gudnabrsam@gmail.com>
> wrote:
> > http://wiki.apache.org/commons/classscan
> >
> > On Wed, Jul 27, 2011 at 9:59 AM, Jakob Korherr <jakob.korherr@gmail.com>
> wrote:
> >> +1
> >>
> >> Regards,
> >> Jakob
> >>
> >> 2011/7/27 Matt Benson <gudnabrsam@gmail.com>:
> >>> On Wed, Jul 27, 2011 at 4:25 AM, Jakob Korherr
> <jakob.korherr@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 <simonetripodi@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 <struberg@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


Mime
View raw message