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 2015/10/14 23:48:26 UTC
Is there anything besides the Logger name that uniquely identifies a Logger?
Perhaps besides a particular LoggerContext. I have an idea on how to
significantly simplify the serialization of Logger, and if we can simply
unserialize it based purely on its name, then that would save a lot of
trouble. I don't remember if we've discussed this idea in the past, but I
think this would be the best way to implement serialization in Logger. I
wouldn't want to pass a Logger over the wire and clobber a possibly
different configuration already in memory at the time, for instance.
--
Matt Sicker <bo...@gmail.com>
Re: Is there anything besides the Logger name that uniquely
identifies a Logger?
Posted by Matt Sicker <bo...@gmail.com>.
That's exactly what I was thinking. A simple writeReplace() and
readReplace() using the logger name and LogManager.getLogger(name).
On 14 October 2015 at 21:32, Ralph Goers <ra...@dslextreme.com> wrote:
> I am not sure why you would need or want to serialize any plugins. Logger
> basically references the LoggerContext and the PrivateConfig. Both of
> these should be transient as it makes very little sense for those to be
> deserialized on a target implementation. But even serializing the actual
> Logger makes very little sense. On the target system you would want to call
> LogManager.getLogger(name) to recreate it.
>
> What I would suggest is to use the Proxy pattern that is used by
> Log4jLogEvent to serialize and deserialize the Logger. What would be
> different is that the serialization would basically only serialize the
> logger name and deserialization would call LogManager.getLogger(name).
>
> Ralph
>
> On Oct 14, 2015, at 7:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Basically, to naively serialize a Logger, you need to serialize all the
> plugins associated with it. As most things in log4j-core can be classified
> as either plugins or "framework" code, that's really most of the codebase.
>
> On 14 October 2015 at 18:00, Gary Gregory <ga...@gmail.com> wrote:
>
>> If it's really 50%, then yeah, that's suspicious. I'd like to hear if
>> Ralph or Remko have any insights here.
>>
>> Gary
>>
>> On Wed, Oct 14, 2015 at 3:04 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> Most people use a static field to store the Logger, so most use cases
>>> don't require serialization. For instance fields, it might work better to
>>> declare it transient, and in that case, our implementation of Logger should
>>> not be Serializable at all. Otherwise, there are ways to serialize
>>> everything, but the way it looks, that will require making over 50% of the
>>> code base Serializable which doesn't smell right to me.
>>>
>>> On 14 October 2015 at 16:54, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>
>>>> It would be a neat trick to only use the logger name for ser/deser. But
>>>> a logger only exists in a LC, so how would you re-create the Logger object.
>>>> LogManager.getLogger(String) can't account for the message factory for
>>>> example. Would knowing the class within which the static Logger resides be
>>>> enough to know which LC to use? I do not see how :-( I think we need
>>>> Ralph's insight here.
>>>>
>>>> The alternative would be... to recommend that all Logger declarations
>>>> be transient? That does not seen realistic, especially accounting for code
>>>> you cannot change.
>>>>
>>>> Gary
>>>>
>>>> On Wed, Oct 14, 2015 at 2:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>>
>>>>> Perhaps besides a particular LoggerContext. I have an idea on how to
>>>>> significantly simplify the serialization of Logger, and if we can simply
>>>>> unserialize it based purely on its name, then that would save a lot of
>>>>> trouble. I don't remember if we've discussed this idea in the past, but I
>>>>> think this would be the best way to implement serialization in Logger. I
>>>>> wouldn't want to pass a Logger over the wire and clobber a possibly
>>>>> different configuration already in memory at the time, for instance.
>>>>>
>>>>> --
>>>>> Matt Sicker <bo...@gmail.com>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Is there anything besides the Logger name that uniquely identifies a Logger?
Posted by Ralph Goers <ra...@dslextreme.com>.
I am not sure why you would need or want to serialize any plugins. Logger basically references the LoggerContext and the PrivateConfig. Both of these should be transient as it makes very little sense for those to be deserialized on a target implementation. But even serializing the actual Logger makes very little sense. On the target system you would want to call LogManager.getLogger(name) to recreate it.
What I would suggest is to use the Proxy pattern that is used by Log4jLogEvent to serialize and deserialize the Logger. What would be different is that the serialization would basically only serialize the logger name and deserialization would call LogManager.getLogger(name).
Ralph
> On Oct 14, 2015, at 7:02 PM, Matt Sicker <bo...@gmail.com> wrote:
>
> Basically, to naively serialize a Logger, you need to serialize all the plugins associated with it. As most things in log4j-core can be classified as either plugins or "framework" code, that's really most of the codebase.
>
> On 14 October 2015 at 18:00, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
> If it's really 50%, then yeah, that's suspicious. I'd like to hear if Ralph or Remko have any insights here.
>
> Gary
>
> On Wed, Oct 14, 2015 at 3:04 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
> Most people use a static field to store the Logger, so most use cases don't require serialization. For instance fields, it might work better to declare it transient, and in that case, our implementation of Logger should not be Serializable at all. Otherwise, there are ways to serialize everything, but the way it looks, that will require making over 50% of the code base Serializable which doesn't smell right to me.
>
> On 14 October 2015 at 16:54, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
> It would be a neat trick to only use the logger name for ser/deser. But a logger only exists in a LC, so how would you re-create the Logger object. LogManager.getLogger(String) can't account for the message factory for example. Would knowing the class within which the static Logger resides be enough to know which LC to use? I do not see how :-( I think we need Ralph's insight here.
>
> The alternative would be... to recommend that all Logger declarations be transient? That does not seen realistic, especially accounting for code you cannot change.
>
> Gary
>
> On Wed, Oct 14, 2015 at 2:48 PM, Matt Sicker <boards@gmail.com <ma...@gmail.com>> wrote:
> Perhaps besides a particular LoggerContext. I have an idea on how to significantly simplify the serialization of Logger, and if we can simply unserialize it based purely on its name, then that would save a lot of trouble. I don't remember if we've discussed this idea in the past, but I think this would be the best way to implement serialization in Logger. I wouldn't want to pass a Logger over the wire and clobber a possibly different configuration already in memory at the time, for instance.
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com <ma...@gmail.com> | ggregory@apache.org <ma...@apache.org>
> Java Persistence with Hibernate, Second Edition <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/>
> Home: http://garygregory.com/ <http://garygregory.com/>
> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory>
>
>
> --
> Matt Sicker <boards@gmail.com <ma...@gmail.com>>
Re: Is there anything besides the Logger name that uniquely
identifies a Logger?
Posted by Matt Sicker <bo...@gmail.com>.
Basically, to naively serialize a Logger, you need to serialize all the
plugins associated with it. As most things in log4j-core can be classified
as either plugins or "framework" code, that's really most of the codebase.
On 14 October 2015 at 18:00, Gary Gregory <ga...@gmail.com> wrote:
> If it's really 50%, then yeah, that's suspicious. I'd like to hear if
> Ralph or Remko have any insights here.
>
> Gary
>
> On Wed, Oct 14, 2015 at 3:04 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> Most people use a static field to store the Logger, so most use cases
>> don't require serialization. For instance fields, it might work better to
>> declare it transient, and in that case, our implementation of Logger should
>> not be Serializable at all. Otherwise, there are ways to serialize
>> everything, but the way it looks, that will require making over 50% of the
>> code base Serializable which doesn't smell right to me.
>>
>> On 14 October 2015 at 16:54, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> It would be a neat trick to only use the logger name for ser/deser. But
>>> a logger only exists in a LC, so how would you re-create the Logger object.
>>> LogManager.getLogger(String) can't account for the message factory for
>>> example. Would knowing the class within which the static Logger resides be
>>> enough to know which LC to use? I do not see how :-( I think we need
>>> Ralph's insight here.
>>>
>>> The alternative would be... to recommend that all Logger declarations be
>>> transient? That does not seen realistic, especially accounting for code you
>>> cannot change.
>>>
>>> Gary
>>>
>>> On Wed, Oct 14, 2015 at 2:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> Perhaps besides a particular LoggerContext. I have an idea on how to
>>>> significantly simplify the serialization of Logger, and if we can simply
>>>> unserialize it based purely on its name, then that would save a lot of
>>>> trouble. I don't remember if we've discussed this idea in the past, but I
>>>> think this would be the best way to implement serialization in Logger. I
>>>> wouldn't want to pass a Logger over the wire and clobber a possibly
>>>> different configuration already in memory at the time, for instance.
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: Is there anything besides the Logger name that uniquely
identifies a Logger?
Posted by Remko Popma <re...@gmail.com>.
Users can just declare a transient field and access it through a helper
method that checks for null and initializes it if required.
I suspect that this is already how people handle serialization of
non-static Logger fields at the moment or otherwise they would see errors
when (de)serializing their class...
On Thu, Oct 15, 2015 at 8:00 AM, Gary Gregory <ga...@gmail.com>
wrote:
> If it's really 50%, then yeah, that's suspicious. I'd like to hear if
> Ralph or Remko have any insights here.
>
> Gary
>
> On Wed, Oct 14, 2015 at 3:04 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> Most people use a static field to store the Logger, so most use cases
>> don't require serialization. For instance fields, it might work better to
>> declare it transient, and in that case, our implementation of Logger should
>> not be Serializable at all. Otherwise, there are ways to serialize
>> everything, but the way it looks, that will require making over 50% of the
>> code base Serializable which doesn't smell right to me.
>>
>> On 14 October 2015 at 16:54, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> It would be a neat trick to only use the logger name for ser/deser. But
>>> a logger only exists in a LC, so how would you re-create the Logger object.
>>> LogManager.getLogger(String) can't account for the message factory for
>>> example. Would knowing the class within which the static Logger resides be
>>> enough to know which LC to use? I do not see how :-( I think we need
>>> Ralph's insight here.
>>>
>>> The alternative would be... to recommend that all Logger declarations be
>>> transient? That does not seen realistic, especially accounting for code you
>>> cannot change.
>>>
>>> Gary
>>>
>>> On Wed, Oct 14, 2015 at 2:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>>
>>>> Perhaps besides a particular LoggerContext. I have an idea on how to
>>>> significantly simplify the serialization of Logger, and if we can simply
>>>> unserialize it based purely on its name, then that would save a lot of
>>>> trouble. I don't remember if we've discussed this idea in the past, but I
>>>> think this would be the best way to implement serialization in Logger. I
>>>> wouldn't want to pass a Logger over the wire and clobber a possibly
>>>> different configuration already in memory at the time, for instance.
>>>>
>>>> --
>>>> Matt Sicker <bo...@gmail.com>
>>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
Re: Is there anything besides the Logger name that uniquely
identifies a Logger?
Posted by Gary Gregory <ga...@gmail.com>.
If it's really 50%, then yeah, that's suspicious. I'd like to hear if Ralph
or Remko have any insights here.
Gary
On Wed, Oct 14, 2015 at 3:04 PM, Matt Sicker <bo...@gmail.com> wrote:
> Most people use a static field to store the Logger, so most use cases
> don't require serialization. For instance fields, it might work better to
> declare it transient, and in that case, our implementation of Logger should
> not be Serializable at all. Otherwise, there are ways to serialize
> everything, but the way it looks, that will require making over 50% of the
> code base Serializable which doesn't smell right to me.
>
> On 14 October 2015 at 16:54, Gary Gregory <ga...@gmail.com> wrote:
>
>> It would be a neat trick to only use the logger name for ser/deser. But a
>> logger only exists in a LC, so how would you re-create the Logger object.
>> LogManager.getLogger(String) can't account for the message factory for
>> example. Would knowing the class within which the static Logger resides be
>> enough to know which LC to use? I do not see how :-( I think we need
>> Ralph's insight here.
>>
>> The alternative would be... to recommend that all Logger declarations be
>> transient? That does not seen realistic, especially accounting for code you
>> cannot change.
>>
>> Gary
>>
>> On Wed, Oct 14, 2015 at 2:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> Perhaps besides a particular LoggerContext. I have an idea on how to
>>> significantly simplify the serialization of Logger, and if we can simply
>>> unserialize it based purely on its name, then that would save a lot of
>>> trouble. I don't remember if we've discussed this idea in the past, but I
>>> think this would be the best way to implement serialization in Logger. I
>>> wouldn't want to pass a Logger over the wire and clobber a possibly
>>> different configuration already in memory at the time, for instance.
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: Is there anything besides the Logger name that uniquely
identifies a Logger?
Posted by Matt Sicker <bo...@gmail.com>.
Most people use a static field to store the Logger, so most use cases don't
require serialization. For instance fields, it might work better to declare
it transient, and in that case, our implementation of Logger should not be
Serializable at all. Otherwise, there are ways to serialize everything, but
the way it looks, that will require making over 50% of the code base
Serializable which doesn't smell right to me.
On 14 October 2015 at 16:54, Gary Gregory <ga...@gmail.com> wrote:
> It would be a neat trick to only use the logger name for ser/deser. But a
> logger only exists in a LC, so how would you re-create the Logger object.
> LogManager.getLogger(String) can't account for the message factory for
> example. Would knowing the class within which the static Logger resides be
> enough to know which LC to use? I do not see how :-( I think we need
> Ralph's insight here.
>
> The alternative would be... to recommend that all Logger declarations be
> transient? That does not seen realistic, especially accounting for code you
> cannot change.
>
> Gary
>
> On Wed, Oct 14, 2015 at 2:48 PM, Matt Sicker <bo...@gmail.com> wrote:
>
>> Perhaps besides a particular LoggerContext. I have an idea on how to
>> significantly simplify the serialization of Logger, and if we can simply
>> unserialize it based purely on its name, then that would save a lot of
>> trouble. I don't remember if we've discussed this idea in the past, but I
>> think this would be the best way to implement serialization in Logger. I
>> wouldn't want to pass a Logger over the wire and clobber a possibly
>> different configuration already in memory at the time, for instance.
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
Matt Sicker <bo...@gmail.com>
Re: Is there anything besides the Logger name that uniquely
identifies a Logger?
Posted by Gary Gregory <ga...@gmail.com>.
It would be a neat trick to only use the logger name for ser/deser. But a
logger only exists in a LC, so how would you re-create the Logger object.
LogManager.getLogger(String) can't account for the message factory for
example. Would knowing the class within which the static Logger resides be
enough to know which LC to use? I do not see how :-( I think we need
Ralph's insight here.
The alternative would be... to recommend that all Logger declarations be
transient? That does not seen realistic, especially accounting for code you
cannot change.
Gary
On Wed, Oct 14, 2015 at 2:48 PM, Matt Sicker <bo...@gmail.com> wrote:
> Perhaps besides a particular LoggerContext. I have an idea on how to
> significantly simplify the serialization of Logger, and if we can simply
> unserialize it based purely on its name, then that would save a lot of
> trouble. I don't remember if we've discussed this idea in the past, but I
> think this would be the best way to implement serialization in Logger. I
> wouldn't want to pass a Logger over the wire and clobber a possibly
> different configuration already in memory at the time, for instance.
>
> --
> Matt Sicker <bo...@gmail.com>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory