[
https://issues.apache.org/jira/browse/LOG4J2-513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13882458#comment-13882458
]
Matt Sicker commented on LOG4J2-513:
So far, one major refactoring that was required is separating out the class
that holds the LoggerContextFactory. For lack of a better class name, I've gone
with LoggerContextFactoryContext. This becomes an overridable anchor to the
system, where LogManager delegates out to the context class. Included in the
context class is the code from LogManager.static, and LogManager.static simply
calls that method with override=false.
Anyway, I've also added another bundle that includes a BundleActivator that
will load/reload the logger context factory using the proper class loader.
Needs more testing as I'm still learning how to use OSGi, but it seems simple
enough.
Use more OSGi-friendly class loading mechanisms.
Key: LOG4J2-513
URL: https://issues.apache.org/jira/browse/LOG4J2-513
Project: Log4j 2
Issue Type: Sub-task
Components: API
Affects Versions: 2.0-rc1
Environment: OSGi
Reporter: Matt Sicker
Labels: api, bundle, classloader, osgi
See for instance
[here|http://njbartlett.name/2012/10/23/dreaded-thread-context-classloader.html].
Currently, o.a.l.l.util.ProviderUtil has a findClassLoader() method that
depends on using the thread context class loader (TCCL). Now this method may
work in certain environments, but once you're in an OSGi environment, class
loaders are far more modular thanks to each bundle getting its own class
loader. The thread context class loader is oftentimes not the correct one in
such an environment.
I'll do more research on being compatible with OSGi without depending on
OSGi. In the meantime, this ticket will have to do.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
