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 <[EMAIL PROTECTED]> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
