commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simonetrip...@apache.org>
Subject Re: [sandbox] [classscan] classscan API design review needed
Date Wed, 27 Jul 2011 19:44:10 GMT
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


Mime
View raw message