[ https://issues.apache.org/jira/browse/LOG4J2-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649380#comment-13649380 ]
Bob Kerns commented on LOG4J2-238: ---------------------------------- Generally, what Unsafe offers is available in other forms. For example, the LMAX disruptors use it to do what java.util.concurrent.atomic.AtomicIntegerArray provides -- which calls the same Unsafe operations under the hood. I don't know why it's using Unsafe to do these operations instead -- perhaps Java 1.4 compatibility? But making the packages optional will at least allow LOG4J2 to load, sans Async loggers. And to get Async loggers, all I need to do is provide a modified, OSGi'd version of the LMAX Disruptors. Since that doesn't exist right now, nobody can load LOG4J Core in OSGi, unless we make it optional. Until LMAX Disruptors are easily available in OSGi, It would be nice to make Async loggers work if LMAX Disruptors are not present, via blocking queues. A shame, really; LMAX Disruptors are perfect for this usage! As for CachedClock and CourseCachedClock, I don't see any reason they can't use Object.wait(long) for this purpose. It's slightly more complex to use because you have to synchronize on some object, and handle the Interrupted exception I don't have a good understanding of Maven, especially its OSGi packaging. (Though it uses bnd, which I do understand). But to be optional in the OSGi manifest, the package imports must look like this: Import-Package: com.example.optpkg;resolution:=optional That is, resolution:=optional must appear as one of the items after the ';' for each optional package. That is generated using bnd; the property that drives it is ${osgi.import}, which is being set in the parent pom. It's currently being set as * however -- prepending comma-separated package entries for the packages you want to control directly should do the trick. This should be done locally, rather than in the parent. But perhaps all this Maven stuff provides a better, more automated way? I don't seem to quite have enough Maven integration loaded to fully look at the Maven issues; I'm getting lifecycle configuration errors for felix and mojo, and a lot of missing artifacts. Maybe I can be more helpful if I get that sorted out. Also, I see <_nouses>true</_nouses> in the pom. This is probably not a good idea, though it may be an apparent workaround for a problem elsewhere. The uses clauses -- ugly as they are -- prevent problems when different plugins ask want conflicting versions of packages. > OSGi dependency failures in core > -------------------------------- > > Key: LOG4J2-238 > URL: https://issues.apache.org/jira/browse/LOG4J2-238 > Project: Log4j 2 > Issue Type: Bug > Components: Core > Affects Versions: 2.0-beta5 > Environment: OSGi (Eclipse 4.2.2, but I think the issue is generic > OSGi) > Reporter: Bob Kerns > Labels: OSGi > > To get the core module to load, in addition to re-fixing what was almost > fixed in LOG4J2-159 I had to make several packages optional. > * com.lmax.disruptor > * com.lmax.disruptor.dsl > * com.lmax.disruptor.util > These provided a dependency on sun.misc, which I could hack around to make > available but isn't normally available in OSGi and thus not a dependency I > can easily put into a product. I believe the dependency is on sun.misc.Unsafe > I'd like to use it... > There is also a direct dependency somewhere on > * sun.misc (also Unsafe) > * com.sun.tools.jconsole -- I think this unlikely to be used in an OSGi > environment, so optional is appropriate. > * org.codehaus.jackson > * org.codehaus.jackson.map > These would be easy enough to satisfy, but since most people won't need JSON > logging, the dependency should be optional. > I think the correct minimal fix is just to make them all optional in the > manifest. Eliminating the need for sun.misc would be a good further step -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org