Out of all the message factories, it looks like LocalizedMessageFactory is only one that needs special treatment because you cannot serialize a resource bundle. But we have the name, so that should be good enough.
Gary On Thu, Oct 15, 2015 at 7:49 AM, Matt Sicker <[email protected]> wrote: > Well, as AbstractLogger is indeed Serializable, it looks like there's no > way to remove that at this point. Making the MessageFactory Serializable > sounds feasible. Are there any other components that may need to be > serialized? If not, I can go ahead with the implementation. > > On 15 October 2015 at 09:15, Mikael Ståldal <[email protected]> > wrote: > >> 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. >> > > > > -- > 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
