commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [Lang] a bit of commons-style code in search of a home
Date Mon, 13 Sep 2010 05:49:50 GMT
Hi Henry!
thanks for your interest :) I avoided even reading the Jersey source
code for the problem you mentioned (I'm not licensing expert but AFAIK
ASL2.0 is not compatible with Jersey's), I took the main inspiration
from Misko Hevery's classpath-explorer (ASL2.0) for the ClassPath
structure/bootstrap and MyBatis (I'm committer also in this project)
and Google Guice (both ASL2.0) for the Test/Matcher design (I renamed
them Filter).
Said that, do you see any potential to start importing that stuff in Lang?
Many thanks in advance, have a nice day,
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Mon, Sep 13, 2010 at 7:27 AM, Henri Yandell <flamefew@gmail.com> wrote:
> I like the sound of it :)
>
> I hope you've not used any code from Jersey though, it's license will
> overrule the AL 2.0 licensing.
>
> Hen
>
> On Sun, Sep 12, 2010 at 7:42 AM, Simone Tripodi
> <simone.tripodi@gmail.com> wrote:
>> Hi all guys,
>> during my last year of work I've met a replicated behavior in
>> different projects, like the classpath analysis. Scanning the
>> classpath could be useful to dynamically find services implementations
>> or to generate custom documentation, or some other uses nobody has not
>> envisioned yet.
>> Follow below a short list of met use cases:
>>
>> - Misko Hevery of Google developed a light yet powerful classpath
>> explorer, but it seems the project has a very low activity, you can
>> find more info on http://code.google.com/p/classpath-explorer/;
>>
>> - The MyBatis (formerly Apache iBatis) project added an utility class
>> to discover MyBatis components from the classpath
>> (http://code.google.com/p/mybatis/source/browse/trunk/src/main/java/org/apache/ibatis/io/ResolverUtil.java)
>>
>> - The Jersey (JAX-RS) project has a config parameter,
>> "com.sun.jersey.config.property.packages", where users can specify
>> packages where look for JSR311 components, like showed at "1.2.
>> Deploying the root resource" on
>> https://jersey.dev.java.net/nonav/documentation/latest/user-guide.html
>>
>> For this reason, I think that something from the threes can be reused
>> and improved to create a common stuff to scan the classpath.
>>
>> First of all, no more package-based filter policy only, but rather
>> something closer to an expression language, like
>>
>> ----
>>    Filter filter = and(
>>                    inSubpackage("com.acme"),
>>                    isPublic(),
>>                    not(isAbstract()),
>>                    not(isAnnotation()),
>>                    not(classNameMatches(".*TestCase"));
>> ----
>>
>> Second, since analyzing the classpath is an operation that could take
>> a long time, I think that the "scan" operation should accept one (or
>> optionally more) classpath handler, each one accepts one filter (as
>> described above) associated to one (or optionally more) classpath
>> entry handler. To be more clear, I'd like to show an example:
>>
>> ----
>> scan(new ClassPathHandler(and(
>>                    inSubpackage("com.acme"),
>>                    isPublic(),
>>                    not(isAbstract()),
>>                    not(isAnnotation()),
>>                    not(classNameMatches(".*TestCase"))),
>>                new ClassPathEntryHandler() {
>>
>>                    public void doHandle(ClassPathEntry classPathEntry)
{
>>                        Class<?> type = classPathEntry.getClazz();
>>                        // manipulate the class
>>                    }
>>
>>                },
>>                new ClassPathEntryHandler() {
>>
>>                    public void doHandle(ClassPathEntry classPathEntry)
{
>>                        if (log.isInfoEnabled()) {
>>                            log.info("Plugged in my ACME system " +
>> classPathEntry);
>>                        }
>>                    }
>>
>>                }
>>            ), new ClassPathHandler(any(), new ClassPathEntryHandler() {
>>
>>                public void doHandle(ClassPathEntry classPathEntry) {
>>                        if (log.isDebugEnabled()) {
>>                            log.debug("Plugged class " + classPathEntry);
>>                        }
>>                }
>>
>>            }))
>> ----
>>
>> Finally, the bootstrap:
>>  * a classpath could be created starting from the JVM one (the
>> System.getProperty("java.class.path")) or from a custom one (like the
>> one in a Servlet context);
>>  * a custom ClassLoader or the default
>> Thread.currentThread().getContextClassLoader() is needed to resolve
>> classpath entries to Class<?> object;
>>  * an error Handler (a default one is provided) is needed to catch
>> eventual errors that could occur while scanning the classpath.
>> That could be resumed in a chained builders, like:
>>
>> ----
>> ClassPath classPath =  new ClassPathBuilder()
>>                    .createFromJVM()
>>                    .usingDefaultClassLoader()
>>                    .usingDefaultErrorHandler();
>> ----
>>
>> A codebase for this already exists, I committed it on Google-Code
>> (http://code.google.com/p/meiyo/) and licensed it under ASL2.0. If you
>> guys agree I'd be more than happy to port it under Commons-Lang (at
>> least my instinct suggested Lang as the better place).
>>
>> WDYT? Thanks in advance and thanks for reading, I hop you'ven't got bored :P
>> Have a nice day,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.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