The LocalizedMessageFactory constructor taking a ResourceBundle does raise an issue. Java 8 added a getBaseBundleName() method, but there's nothing for 7.
On 15 October 2015 at 17:42, Gary Gregory <[email protected]> wrote: > 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 > -- Matt Sicker <[email protected]>
