7 messages in org.apache.commons.devRE: java.util.Service| From | Sent On | Attachments |
|---|---|---|
| Jörg Schaible | Mar 9, 2006 4:59 am | |
| Craig McClanahan | Mar 9, 2006 9:03 am | |
| Simon Kitching | Mar 9, 2006 12:36 pm | |
| Jörg Schaible | Mar 9, 2006 12:56 pm | |
| Jörg Schaible | Mar 9, 2006 11:29 pm | |
| Jörg Schaible | Mar 10, 2006 12:07 am | |
| robert burrell donkin | Mar 11, 2006 3:07 am |
| Subject: | RE: java.util.Service | |
|---|---|---|
| From: | Jörg Schaible (Joer...@Elsag-Solutions.com) | |
| Date: | Mar 10, 2006 12:07:51 am | |
| List: | org.apache.commons.dev | |
Hi Simon,
Simon Kitching wrote on Thursday, March 09, 2006 9:37 PM:
On Thu, 2006-03-09 at 09:04 -0800, Craig McClanahan wrote:
On 3/9/06, Jörg Schaible <Joer...@elsag-solutions.com> wrote:
Hi folks,
do we have something like the java.util.Service class introduced with JDK 1.6 withing Jakarta? This is basically a proper API to access the Service Provider mechanism described here:
http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html#Service %20Provider
The closest analog is probably the "Commons Discovery" package, which utilizes a variety of strategies to do service discovery (including, IIRC, the META-INF service lookup trick).
As it happens, I've just implemented Service functionality as part of a JCL 2.x experimental prototype (including unit tests). You're welcome to the code..
http://svn.apache.org/repos/asf/jakarta/commons/proper/logging /contrib/simon/jcl2/core/java/org/apache/commons/logging/Utils.java
http://svn.apache.org/repos/asf/jakarta/commons/proper/logging /contrib/simon/jcl2/core/
Regretfully I don't have a lot of confidence in the commons-discovery code. There are *so* many weird classpath-related situations that can occur inside containers that any code of more than trivial complexity is almost certain to be wrong in some circumstances. If you want Service support, I would recommend *just* implementing Service support rather than using commons-discovery.
Seems currently the best. Discovery has a lot of "bloat" due to it's 1.1
compatibility code. Also it fiddles itself with the sequence of found resources
(see impl of o.a.c.d.jdk.JDK12Hook.findResources), so you cannot rely on the
behaviour of your container anymore :-/
Your implementation though does not handle multpile providers - it's just not
necessary for jcl.
- Jörg