I dislike to have to make a class Serializable just because some stupid framework (or stupid use of some non-stupid framework) requires it.
I guess it was a mistake to make org.apache.logging.log4j.spi. AbstractLogger Serializable in the first place. On Thu, Oct 15, 2015 at 6:56 AM, Ralph Goers <[email protected]> wrote: > Well, MessageFactory is not Serializable but AbstractMessageFactory is. If > the MessageFactory used by the Logger is serializable we could include it. > If it is not we would have to treat it as transient. Upon deserialization > we may find that the MessageFactory implementation doesn’t exist on the > target platform, in which case we would have to just use the default. > > Ralph > > On Oct 14, 2015, at 8:27 PM, Gary Gregory <[email protected]> wrote: > > What if a logger does not use the default message factory? > > Gary > > > -------- Original message -------- > From: Ralph Goers <[email protected]> > Date: 10/14/2015 19:32 (GMT-08:00) > To: Log4J Developers List <[email protected]> > Subject: Re: Is there anything besides the Logger name that uniquely > identifies a Logger? > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>>> >>>> >>>> >>>> >>>> -- >>>> E-Mail: [email protected] | [email protected] >>>> 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 <[email protected]> >>> >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> 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 <[email protected]> > > > > -- [image: MagineTV] *Mikael Ståldal* Senior software developer *Magine TV* [email protected] Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com Privileged and/or Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such a person), you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email.
