+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
[
https://issues.apache.org/jira/browse/LOG4J2-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13975202#comment-13975202
]
Matt Sicker commented on LOG4J2-547:
Added in revision 1588797 on the experimental bra
I know that the documentation says to use the slf4j JUL bridge, but that
seems excessive. Is there any reason we don't have our own bridge? Or is it
just a better idea to use the slf4j one?
--
Matt Sicker
I’ve answered this before and it always starts with "java.util.logging sucks” -
at least from the point of view of trying to use its API on top of something
else. (It sucks in other ways too but that is a different discussion).
Take a look at the LogManager class. The only way to replace the JDK
Well, looking at the LogManager source, I see what you're saying. The
global LogManager instance is a private static final field, so even with
reflection, you can't override that. So yes, you'd have to set the system
property before LogManager gets initialized, or it would need to be
user-specified
Speaking of which, that whole "private static final LogManager" is just as
bad as the current "private static final LoggerContextFactory" we've got in
LogManager. This needs to be replaceable after start-up to really be
powerful.
On 20 April 2014 13:57, Matt Sicker wrote:
> Well, looking at the
Scratch that (for the jul.LogManager); you can totally abuse reflection to
replace the LogManager at runtime!
On 20 April 2014 14:30, Matt Sicker wrote:
> Speaking of which, that whole "private static final LogManager" is just as
> bad as the current "private static final LoggerContextFactory"
Something for 2.1?
Sent from my iPhone
> On 2014/04/21, at 5:45, Matt Sicker wrote:
>
> Scratch that (for the jul.LogManager); you can totally abuse reflection to
> replace the LogManager at runtime!
>
>
>> On 20 April 2014 14:30, Matt Sicker wrote:
>> Speaking of which, that whole "private
At this point, I'm starting to think so. I'm trying to implement this using
the proper security contexts and such, and I'm already writing a new
reflection utility class.
On 20 April 2014 15:43, Remko Popma wrote:
> Something for 2.1?
>
> Sent from my iPhone
>
> On 2014/04/21, at 5:45, Matt Sic
So we can mark issues as to be fixed or implemented in 2.1.
--
Matt Sicker
Matt Sicker created LOG4J2-608:
--
Summary: Add support for a java.util.logging bridge.
Key: LOG4J2-608
URL: https://issues.apache.org/jira/browse/LOG4J2-608
Project: Log4j 2
Issue Type: New Featu
Sure, why not? That seems like a good way to triage issues. I would help us
see if some of these features should go in 2.0 if they will break BY in 2.1.
Gary
Original message From: Matt Sicker
Date:04/20/2014 21:09 (GMT-05:00)
To: Log4J Developers List
Subject: Could we
[
https://issues.apache.org/jira/browse/LOG4J2-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker updated LOG4J2-608:
---
Attachment: 608-1.0.patch
Here's what I did today. Almost seems to work (at least using OpenJDK 1.8)
Posted an initial version to JIRA for you all to take a look at.
On 20 April 2014 15:56, Matt Sicker wrote:
> At this point, I'm starting to think so. I'm trying to implement this
> using the proper security contexts and such, and I'm already writing a new
> reflection utility class.
>
>
> On 2
I just did a fresh checkout and am getting the following test failures:
Results :
Failed tests:
CustomConfigurationTest.testConfig:61 expected same: was not:
FileOutputTest.testConfig:44 File is empty
Tests run: 543, Failures: 2, Errors: 0, Skipped: 15
I thought we had agreed that the plugin processor would only be a compile time
dependency for things building plugins. I believe this now makes the
additional jar a runtime dependency, which was what we said we didn’t want.
Ralph
Begin forwarded message:
> From: mattsic...@apache.org
> Subj
16 matches
Mail list logo
