[
https://issues.apache.org/jira/browse/LOG4J2-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649162#comment-13649162
]
Bob Kerns commented on LOG4J2-159:
----------------------------------
Sorry, I have to retract my prior verification -- it was a testing failure -- I
was expecting one of my Junit tests to pick up the unintended output, rather
than inspecting it myself.
I don't think this can work as intended. Making it a fragment unifies the
classloaders of core and API, but API isn't where the configuration files will
reside.
I think what it should do is:
1) remove the Fragment-Host: header.
2) Try the thread context classloader.
3) Walk up the stack, trying each classloader encountered in turn, until we
find a configuration.
4) Fail if none found.
The tries in 2-3 would each be one iteration of the current check (including
trying to use the system property -- it may only be available in one of the
classloaders).
The search could be reversed, giving preference to the outermost layer to
control logging. This has its merits, but the code that's closer to the actual
use of the API is more likely to supply a compatible configuration. A more
complete solution might be to merge them somehow.
But I vote for the initial pass to be inner-to-outer. You can get the reverse
result by supplying your own thread context classloader to take control.
It's worth noting that Eclipse supplies a thread context classloader that does
a similar search. But I think we should do our own, for the cases where the
thread context classloader has been replaced, and does not locate a
configuration.
I'll see about pulling the sources and coming up with a tested patch later this
weekend.
> log4j.xml loading from classpath not working correct in osgi environment
> ------------------------------------------------------------------------
>
> Key: LOG4J2-159
> URL: https://issues.apache.org/jira/browse/LOG4J2-159
> Project: Log4j 2
> Issue Type: Bug
> Components: API, Core
> Affects Versions: 2.0-beta3
> Environment: win7, eclipse 3.7 64bit
> Reporter: Jan Winter
> Assignee: Ralph Goers
> Priority: Trivial
> Fix For: 2.0-beta5
>
>
> I have problems while loading log4j.xml configuration file in osgi
> environment.
> I have the following started equinox container:
> +--------------------------------------------------------------------------------------------------------------------------------
> | osgi> ss log4j
> |
> | Framework is launched.
> |
> | id State Bundle
> | 58 RESOLVED my.log4j.xml.fragment
> | Master=136
> | 136 RESOLVED org.apache.commons.log4j-api_2.0.0.beta3
> | Fragments=58
> | 137 RESOLVED org.apache.commons.log4j-core_2.0.0.beta3
> +--------------------------------------------------------------------------------------------------------------------------------
> The log4j2 config file is packaged under my.log4j.xml.fragment.jar/log4j.xml.
> If I have the upper bundle-configuration
> - than the following output happens:
> +--------------------------------------------------------------------------------------------------------------------------------
> | ERROR StatusLogger Unable to locate a logging implementation, using
> SimpleLogger
> | FATAL Log4j_2 log4j-2.0.x logging
> | ERROR Log4j_2 log4j-2.0.x logging
> +--------------------------------------------------------------------------------------------------------------------------------
> *QUICKFIX* If I update the
> org.apache.commons.log4j-core_2.0.0.beta3.jar!/META-INF/MANIFEST.MF
> - append: Fragment-Host: org.apache.commons.log4j-api
> - than log4j2 configuration is loaded and work.
> +--------------------------------------------------------------------------------------------------------------------------------
> | osgi> ss log4j
> |
> | Framework is launched.
> |
> | id State Bundle
> | 58 RESOLVED my.log4j.xml.fragment
> | Master=136
> | 136 RESOLVED org.apache.commons.log4j-api_2.0.0.beta3
> | Fragments=58, 137
> | 137 RESOLVED org.apache.commons.log4j-core_2.0.0.beta3
> | Master=136
> +--------------------------------------------------------------------------------------------------------------------------------
--
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
