Can I use Guice to discover all implementations of a type?

[Johnl]

I'm experimenting with guice right now and trying to replace
functionality, in our application, currently provided by WebBeans.

Using Modules is fine when I'm doing explicit wiring but we also
discover all implementing classes of a type like so:

Set<Bean<?>> impls = WebBeansManager.resolveByType
(myInterface.class);

I can then instantiate these and wire them into my application ( A Set
of RESTful Web Services). I can also supply an optional binding to Web
Beans, if required.

I dont know all of these Web Services at compile time, since each
customer config is different and may contain extension jars, so I need
to discover them dynamically at runtime startup by inspecting the
classpath. I know there are other ways of doing this but I'd
appreciate an example of doing this with guice (if its possible).

Thanks!

John

[Eelco Hillenius]

Unless I missed something obvious, it's such functionality isn't built
in. I implemented it myself two weeks ago. Here's the code that does
that: http://pastebin.com/f6bff61bc. It isn't pretty in anyway, but it
does the job for me. You also need ASM on your classpath (or copied to
your own packages like many people do).

Eelco

[limpb...@gmail.com]

Thanks Eelco.

If anyone is interested and has the time, it would be great to see a
cleaned up version of this for general use. I suspect lots of
developers will start with JSR-299 (since it's tied to Java EE) and
then upgrade to Guice when JSR-299 doesn't meet their needs anymore.

[Eelco Hillenius]

> If anyone is interested and has the time, it would be great to see a
> cleaned up version of this for general use.

Heh. Well, I didn't want to bring it up after this thread:
http://groups.google.com/group/google-sitebricks/browse_thread/thread/1161c23765621f99/3bcd96cd84b52b86?lnk=gst&q=eelco#3bcd96cd84b52b86
:-)

Anyway, I do think it would be a nice option to have, even though it's
easy enough to implement yourself.

> I suspect lots of
> developers will start with JSR-299 (since it's tied to Java EE) and
> then upgrade to Guice when JSR-299 doesn't meet their needs anymore.

Interesting... is that a nice way of saying that you believe web beans
got to be a design by committee child, or just that Guice would be
better suited for some rare corner cases etc?

Cheers,

Eelco

[limpb...@gmail.com]

On Oct 13, 6:44 pm, Eelco Hillenius <eelco.hillen...@gmail.com> wrote:
> Heh. Well, I didn't want to bring it up after this thread:http://groups.google.com/group/google-sitebricks/browse_thread/thread...
> :-)

Yeah, I'm not a fan of classpath scanning either. But I do like the
idea of having a smooth migration path from JSR-299 to Guice.

> Interesting... is that a nice way of saying that you believe web beans
> got to be a design by committee child, or just that Guice would be
> better suited for some rare corner cases etc?

I like Guice, but I'm biased. I'd like to see a thorough comparison of
the two!

[Brian Pontarelli]

Java.net Commons has a scanning thingy that uses ASM. You could just
yank it out and fix it up a bit:

https://java-net-commons.dev.java.net/source/browse/java-net-commons/trunk/src/java/main/net/java/lang/
https://java-net-commons.dev.java.net/source/browse/java-net-commons/trunk/src/java/main/net/java/lang/ClassClassLoaderResolver.java?rev=198&view=markup
https://java-net-commons.dev.java.net/source/browse/java-net-commons/trunk/src/java/main/net/java/lang/AbstractClassLoaderResolver.java?rev=198&view=markup

You'll have to wait an hour to view these links because Java.net is
the world's worst website, but the classes work nicely and I use them
in JCatapult on pretty large codebases.

-bp

[Renat Zubairov]

I was just thinking, would it be enough just to know all Guice
services which implement a given interface?

On Oct 14, 6:13 pm, Brian Pontarelli <br...@pontarelli.com> wrote:
> Java.net Commons has a scanning thingy that uses ASM. You could just  
> yank it out and fix it up a bit:
>

> https://java-net-commons.dev.java.net/source/browse/java-net-commons/...https://java-net-commons.dev.java.net/source/browse/java-net-commons/...https://java-net-commons.dev.java.net/source/browse/java-net-commons/...

[John Logsdon]

Firstly, thanks to everyone who took the time to answer my question and provide a solution so quickly!

Actually, in the end I realised that for my Use Case (Find all implementing classes for an interface at startup) that a perfectly good solution exists already in Java 6 - java.util.ServiceLoader. It doesnt require any additional jars and just does exactly what I want. On reflection I'm not sure this kind of functionality should be in Guice anyway since it's Discovery not DI. With all th ebad experience we've had with webbeans I'm all for projects that just do the one thing very well!

We've also replaced Webbeans DI with Guice and we're now web-bean widows and happy for it! Everything just works now and we can get on with solving the problem we set out to in the first place!

Congrats for getting 330 approved. We're all in your camp now!

John

2009/10/15 Renat Zubairov <renat.z...@gmail.com>

--
John Logsdon
CEO
NetDev Limited  
+44 1273 773661  
+44 7899 811245
http://www.netdev.co.uk
Registered in England and Wales
Company Number 04741258

[Eelco Hillenius]

> Actually, in the end I realised that for my Use Case (Find all implementing
> classes for an interface at startup) that a perfectly good solution exists
> already in Java 6 - java.util.ServiceLoader. It doesnt require any
> additional jars and just does exactly what I want. On reflection I'm not
> sure this kind of functionality should be in Guice anyway since it's
> Discovery not DI. With all th ebad experience we've had with webbeans I'm
> all for projects that just do the one thing very well!

Good it works for your use case. It would be nice to have a more
generic scanning though, so that we can support other cases as well
(like classes with a @Singleton annotation).

Eelco