Hi Aaron, Thanks a lot for that short wrap-up about OSGi.
> OSGi also supports transitive dependencies but since each bundle gets its > own classloader, a bundle must say which transitive dependencies it > re-exports. So even if you use slf4j, that doesn't mean any other OSGi > bundle in the same container can use it unless you either re-export it or > the other bundle requires it as a dependency. That part can be frustrating > but shouldn't be an issue for you. That's probably right as far as loggers are concerned. They're not exposed in the public API and entirely hidden in org.jooq.tools.JooqLogger. So I should be safe not exporting log4j and slf4j. > I think you should not re-export any > dependencies except if the dependency is necessary to use jOOQ (for example > when you need a type from a dependency to talk to jOOQ's API). What about javax.persistence and javax.validation? jOOQ-generated classes could be loaded with a different ClassLoader by OSGi. If those classes are annotated with javax.persistence.Column et al., will jOOQ's internals still see the same javax.persistence.Column annotation? I guess, the fact that Column is referenced from jOOQ's Javadoc shouldn't be an issue, though? > Out of curiosity: Why do you want to keep log4j in your code? I personally prefer that logging framework, and I think it is one of the most widely used ones: - 2029 hits for http://stackoverflow.com/questions/tagged/log4j - 364 hits for http://stackoverflow.com/questions/tagged/slf4j - 298 hits for http://stackoverflow.com/questions/tagged/logback But I'm not happy with having such (optional) dependencies. If there is any way of removing them, all the better. Reflection would be one way. But as we've seen with OSGi, that will cause issues - apart from being much slower, if every logger.isTraceEnabled() call has to be run through reflection. I'm hoping that this question here will get some good answer, too: http://stackoverflow.com/questions/11432212/java-class-with-possibly-missing-run-time-dependencies/11432484 2012/7/11 digulla <[email protected]>: > Am Dienstag, 10. Juli 2012 09:46:25 UTC+2 schrieb Lukas Eder: > >> Could you provide a pull request for that? Or show me how to do it? > > > OSGi has two modes to determine dependencies: > > 1. By specifying a bundle name and a version (a bit like Maven) > 2. By specifying a package name + optional version. > > The second mode means: Enumerate all visible bundles (the container will > decide what's visible) and add bundles which export the packages which I > require. > > It's a like saying "I need org.slf4j.Logger" and the container will find it > for you. > > So you need to identify package names of classes of dependencies that you > use. If you import "org.slf4j.Logger", then you need to add this line to > Import-Package: > > org.slf4j > > If you need a specific version, you can add: > > org.slf4j;version=1.6.1 > > If the dependency is optional, add "resolution:=optional": > > org.slf4j;version=1.6.1;resolution:=optional > > Note that there is a difference between OSGi and Maven versions. OSGi 1.6.1 > means [1.6.1,) in Maven (i.e. anything above instead this exact version). > > For a list of versions, see here: > http://download.eclipse.org/tools/orbit/downloads/drops/R20120526062928/ > > OSGi also supports transitive dependencies but since each bundle gets its > own classloader, a bundle must say which transitive dependencies it > re-exports. So even if you use slf4j, that doesn't mean any other OSGi > bundle in the same container can use it unless you either re-export it or > the other bundle requires it as a dependency. That part can be frustrating > but shouldn't be an issue for you. I think you should not re-export any > dependencies except if the dependency is necessary to use jOOQ (for example > when you need a type from a dependency to talk to jOOQ's API). > >> - I would like to use log4j for developing jOOQ >> - I would like to support log4j in org.jooq.tools.JooqLogger (with or >> without slf4j) > > > Out of curiosity: Why do you want to keep log4j in your code? > > Regards, > > A. Digulla
