0

SLF4J has a nice mechanism, where the implementation is chosen at runtime, depending of what is available in the classpath. I would like to use such feature in several projects, for example to choose the communication layer or to choose a mock implementation.

I had a look at slf4j source to see how it's done and I could just write something similar. Before I start, I would like to know if some lightweight FOSS library exists for this kind of injection.

paradigmatic
  • 40,153
  • 18
  • 88
  • 147

4 Answers4

2

Unless you need specific configuration abilities as provided by Pico or Guice, you may get what you need from java.util.ServiceLoader.

Basically, all you have to do is to package your service implementation in a JAR file, include a text file with a list of all implementation classes in "META-INF/services/" and on you go.

jarnbjo
  • 33,923
  • 7
  • 70
  • 94
1

Have you looked at Weld, CDI is part of the EE6 spec but the Weld implementation also supports running in a Java SE environment. It has exactly what you are looking for, here is a link to the relative documentation:

http://seamframework.org/Weld one maven dependency for your SE app.
http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/environments.html#d0e5333 bootstrapping the Weld container in SE.

Producer methods to vary implementation at runtime:

http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/producermethods.html

Plus (in my very biased opinion) Weld rocks ;)

Justin
  • 4,097
  • 1
  • 22
  • 31
  • Apparently Weld supports runtim injection, but cannot decide what to inject just on what is present in the classpath. Am I wrong ? – paradigmatic Jul 26 '11 at 10:23
  • Sure you can your producer would be responsible for producing the correct implementation based on what is available on the classpath, how you check the classpath is up to you. I wrote a scanner using scannotation and annotated my implementation classes. Scannotation which does bytecode scanning so its blazzingly fast even in very large classpaths. But there are many ways you could do this. – Justin Jul 26 '11 at 10:31
  • I see. The problem is that I am looking for an helper library to look into the classpath... – paradigmatic Jul 26 '11 at 10:47
0

SLF4J's "mechanism" is simply that its API jar is compiled with code that refers to a class that is only provided by one of its "implementation" jars. No framework or library of any kind is needed for this. Simply write one module which is compiled against a class not in that module. Then your "implementation" modules provide that class when included in the project.

Edit: Oh, and this is basically OSGi writ small (very, very small). If you're going to use this kind of thing on a large scale, look to an OSGi container or Eclipse Virgo.

Ryan Stewart
  • 126,015
  • 21
  • 180
  • 199
  • SLF4J injection mechanism does much more than your description (sanity check, fallback for example). See `LoggerFactory` code. OSGi does not qualify as lightweight neither. – paradigmatic Jul 19 '11 at 21:46
  • OSGi is also not a library. It's an alternate way of deploying an app, but it takes care of everything you seem to be looking for. – Ryan Stewart Jul 20 '11 at 01:56
-3

Every java programmer should know how to use Spring.

Rocky Pulley
  • 22,531
  • 20
  • 68
  • 106