You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2014/04/20 20:00:46 UTC
Why don't we have a java.util.logging bridge?
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 <bo...@gmail.com>
Re: Why don't we have a java.util.logging bridge?
Posted by Matt Sicker <bo...@gmail.com>.
Posted an initial version to JIRA for you all to take a look at.
On 20 April 2014 15:56, Matt Sicker <bo...@gmail.com> 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 20 April 2014 15:43, Remko Popma <re...@gmail.com> wrote:
>
>> Something for 2.1?
>>
>> Sent from my iPhone
>>
>> On 2014/04/21, at 5:45, Matt Sicker <bo...@gmail.com> 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 <bo...@gmail.com> wrote:
>>
>>> 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 <bo...@gmail.com> wrote:
>>>
>>>> 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.
>>>>
>>>> When it comes to improving the SLF4J bridge, I think we could include
>>>> support for converting JDK Level names to markers as a neat addition.
>>>>
>>>> Also, I think a possible solution would be to implement a custom
>>>> LogManager, add documentation to the effect that you need to set that
>>>> system property to use it, and do some reflection on startup to see if
>>>> we're using the custom LogManager. If we're using a different one, we can
>>>> just set the root logger's handlers like the slf4j-jdk14 class does.
>>>>
>>>> I'll work on a proof of concept and see how feasible this is.
>>>>
>>>>
>>>> On 20 April 2014 13:24, Ralph Goers <ra...@dslextreme.com> wrote:
>>>>
>>>>> 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
>>>>> LogManager is via a system property. I could swear I tried to do this once
>>>>> and came to the conclusion that the only sane way to create a bridge was to
>>>>> do what SLF4J does, and I don’t see the point of creating code that does
>>>>> the exact same thing in exactly the same way.
>>>>>
>>>>> That said, if you can come up with a better way to implement the
>>>>> bridge I am all for it.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Apr 20, 2014, at 11:00 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> 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 <bo...@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Why don't we have a java.util.logging bridge?
Posted by Matt Sicker <bo...@gmail.com>.
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 <re...@gmail.com> wrote:
> Something for 2.1?
>
> Sent from my iPhone
>
> On 2014/04/21, at 5:45, Matt Sicker <bo...@gmail.com> 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 <bo...@gmail.com> wrote:
>
>> 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 <bo...@gmail.com> wrote:
>>
>>> 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.
>>>
>>> When it comes to improving the SLF4J bridge, I think we could include
>>> support for converting JDK Level names to markers as a neat addition.
>>>
>>> Also, I think a possible solution would be to implement a custom
>>> LogManager, add documentation to the effect that you need to set that
>>> system property to use it, and do some reflection on startup to see if
>>> we're using the custom LogManager. If we're using a different one, we can
>>> just set the root logger's handlers like the slf4j-jdk14 class does.
>>>
>>> I'll work on a proof of concept and see how feasible this is.
>>>
>>>
>>> On 20 April 2014 13:24, Ralph Goers <ra...@dslextreme.com> wrote:
>>>
>>>> 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
>>>> LogManager is via a system property. I could swear I tried to do this once
>>>> and came to the conclusion that the only sane way to create a bridge was to
>>>> do what SLF4J does, and I don’t see the point of creating code that does
>>>> the exact same thing in exactly the same way.
>>>>
>>>> That said, if you can come up with a better way to implement the bridge
>>>> I am all for it.
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Apr 20, 2014, at 11:00 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>> 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 <bo...@gmail.com>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Why don't we have a java.util.logging bridge?
Posted by Remko Popma <re...@gmail.com>.
Something for 2.1?
Sent from my iPhone
> On 2014/04/21, at 5:45, Matt Sicker <bo...@gmail.com> 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 <bo...@gmail.com> wrote:
>> 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 <bo...@gmail.com> wrote:
>>> 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.
>>>
>>> When it comes to improving the SLF4J bridge, I think we could include support for converting JDK Level names to markers as a neat addition.
>>>
>>> Also, I think a possible solution would be to implement a custom LogManager, add documentation to the effect that you need to set that system property to use it, and do some reflection on startup to see if we're using the custom LogManager. If we're using a different one, we can just set the root logger's handlers like the slf4j-jdk14 class does.
>>>
>>> I'll work on a proof of concept and see how feasible this is.
>>>
>>>
>>>> On 20 April 2014 13:24, Ralph Goers <ra...@dslextreme.com> wrote:
>>>> 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 LogManager is via a system property. I could swear I tried to do this once and came to the conclusion that the only sane way to create a bridge was to do what SLF4J does, and I don’t see the point of creating code that does the exact same thing in exactly the same way.
>>>>
>>>> That said, if you can come up with a better way to implement the bridge I am all for it.
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Apr 20, 2014, at 11:00 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>>>
>>>>> 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 <bo...@gmail.com>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Why don't we have a java.util.logging bridge?
Posted by Matt Sicker <bo...@gmail.com>.
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 <bo...@gmail.com> wrote:
> 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 <bo...@gmail.com> wrote:
>
>> 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.
>>
>> When it comes to improving the SLF4J bridge, I think we could include
>> support for converting JDK Level names to markers as a neat addition.
>>
>> Also, I think a possible solution would be to implement a custom
>> LogManager, add documentation to the effect that you need to set that
>> system property to use it, and do some reflection on startup to see if
>> we're using the custom LogManager. If we're using a different one, we can
>> just set the root logger's handlers like the slf4j-jdk14 class does.
>>
>> I'll work on a proof of concept and see how feasible this is.
>>
>>
>> On 20 April 2014 13:24, Ralph Goers <ra...@dslextreme.com> wrote:
>>
>>> 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
>>> LogManager is via a system property. I could swear I tried to do this once
>>> and came to the conclusion that the only sane way to create a bridge was to
>>> do what SLF4J does, and I don’t see the point of creating code that does
>>> the exact same thing in exactly the same way.
>>>
>>> That said, if you can come up with a better way to implement the bridge
>>> I am all for it.
>>>
>>> Ralph
>>>
>>>
>>>
>>>
>>>
>>> On Apr 20, 2014, at 11:00 AM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>> 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 <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Why don't we have a java.util.logging bridge?
Posted by Matt Sicker <bo...@gmail.com>.
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 <bo...@gmail.com> wrote:
> 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.
>
> When it comes to improving the SLF4J bridge, I think we could include
> support for converting JDK Level names to markers as a neat addition.
>
> Also, I think a possible solution would be to implement a custom
> LogManager, add documentation to the effect that you need to set that
> system property to use it, and do some reflection on startup to see if
> we're using the custom LogManager. If we're using a different one, we can
> just set the root logger's handlers like the slf4j-jdk14 class does.
>
> I'll work on a proof of concept and see how feasible this is.
>
>
> On 20 April 2014 13:24, Ralph Goers <ra...@dslextreme.com> wrote:
>
>> 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
>> LogManager is via a system property. I could swear I tried to do this once
>> and came to the conclusion that the only sane way to create a bridge was to
>> do what SLF4J does, and I don’t see the point of creating code that does
>> the exact same thing in exactly the same way.
>>
>> That said, if you can come up with a better way to implement the bridge I
>> am all for it.
>>
>> Ralph
>>
>>
>>
>>
>>
>> On Apr 20, 2014, at 11:00 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> 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 <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
Matt Sicker <bo...@gmail.com>
Re: Why don't we have a java.util.logging bridge?
Posted by Matt Sicker <bo...@gmail.com>.
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.
When it comes to improving the SLF4J bridge, I think we could include
support for converting JDK Level names to markers as a neat addition.
Also, I think a possible solution would be to implement a custom
LogManager, add documentation to the effect that you need to set that
system property to use it, and do some reflection on startup to see if
we're using the custom LogManager. If we're using a different one, we can
just set the root logger's handlers like the slf4j-jdk14 class does.
I'll work on a proof of concept and see how feasible this is.
On 20 April 2014 13:24, Ralph Goers <ra...@dslextreme.com> wrote:
> 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
> LogManager is via a system property. I could swear I tried to do this once
> and came to the conclusion that the only sane way to create a bridge was to
> do what SLF4J does, and I don’t see the point of creating code that does
> the exact same thing in exactly the same way.
>
> That said, if you can come up with a better way to implement the bridge I
> am all for it.
>
> Ralph
>
>
>
>
>
> On Apr 20, 2014, at 11:00 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> 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 <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Why don't we have a java.util.logging bridge?
Posted by Ralph Goers <ra...@dslextreme.com>.
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 LogManager is via a system property. I could swear I tried to do this once and came to the conclusion that the only sane way to create a bridge was to do what SLF4J does, and I don’t see the point of creating code that does the exact same thing in exactly the same way.
That said, if you can come up with a better way to implement the bridge I am all for it.
Ralph
On Apr 20, 2014, at 11:00 AM, Matt Sicker <bo...@gmail.com> wrote:
> 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 <bo...@gmail.com>