[
https://issues.apache.org/jira/browse/LOG4J2-238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13656257#comment-13656257
]
Bob Kerns commented on LOG4J2-238:
----------------------------------
OSGiLoggerContextFactory is a proxy, that dispatches to the real one that's
supplied to it as an OSGi service. The user can substitute a different
LoggerContextFactory by simply supplying a service with a higher
service.ranking property. But an enhancement would be add a property that
allows customization on a per-bundle basis.
For example, look at org.apache.logging.log4j.core.osgi.LoggerContextService,
which is the actual LoggerContextFactory that gets used by default. (It's a
subclass of Log4jContextFactory). It starts out:
{code:title=LoggerContextService.java}
@Component(name="log4j2", immediate=true, enabled=true,
policy=ConfigurationPolicy.IGNORE)
@Service(org.apache.logging.log4j.spi.LoggerContextFactory.class)
public class LoggerContextService extends Log4jContextFactory implements
org.apache.logging.log4j.spi.LoggerContextFactory {
@property(intValue=10)
public static final String SERVICE_RANKING = "service.ranking";
...
{code}
OSGiLoggerContextFactory finds all such services, and picks the one with the
highest value. Supplying @property(intValue=20) on your own implementation
allows you to customize it.
That's why OSGiLoggerContextFactory maintains an ordered set of services,
rather than specifying cardinality 0..1. Right now, it's duplicating what OSGi
will do in arbitrating services, but I made it explicit so we can customize it.
While I think we would like to have the ability to customize per bundle (done
similarly, with another property), I don't see that as a barrier to putting it
in for beta; even without the enhancement, it's a step forward and allows as
much customization as in a non-OSGi environment.
As for the other concerns, about ConfigurationFactory, and the possibility of
problems in a non-OSGi environment: Agreed, it should not go in just yet. I'll
try to get a chance soon to address the ConfigurationFactory, and test in a
non-OSGi environment. (I had hoped to do that last week, but I hope to get to
it in the next day or two). I should also test supplying a custom one.
If I did it right (test!) the only impact on non-OSGi environments, will be
that LogManager, while loading, will run the bit of code I added that tries to
load OSGiLoggerContextFactory, it won't load, and it will log it at the INFO
level, and then continue as it would before. Beyond that point, there should be
no OSGi-related code involved. There _are_ a few changes, such as refactoring
in Log4JContextFactory to allow LoggerContextService to override what
ContextSelector is created. These should all do the same thing as before.
ConfigurationFactory is an exception that needs to be fixed.
> 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
> Attachments:
> 0001-LOG4J2-238-and-Log472-159.-OSGi-coordination-of-API-.patch
>
>
> 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
