[ 
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

Reply via email to