Alright, what I've got here is code all in Logger (no AbstractLogger), so no equals() or hashCode() in AbstractLogger. The current LoggerContext is used to reconstruct the Logger which seems to make sense. Only the two fields from AbstractLogger are serialized in a proxy class. I'll have this committed shortly.
On 18 October 2015 at 09:45, Gary Gregory <[email protected]> wrote: > The problem we had in tel he past was with the life cycle class IIRC. > > Gary > > > -------- Original message -------- > From: Matt Sicker <[email protected]> > Date: 10/18/2015 02:39 (GMT-08:00) > To: Log4J Developers List <[email protected]> > Subject: Re: Is there anything besides the Logger name that uniquely > identifies a Logger? > > Alright, thanks for the heads up. > > On 18 October 2015 at 04:24, Remko Popma <[email protected]> wrote: > >> Hi Matt, sorry, but please don't add equals/hashCode implementation to >> AbstractLogger. Concrete subclasses are okay of course. >> We had a few issues with this with another abstract Log4j class (can't >> find the Jira ticket now). >> >> On Sun, Oct 18, 2015 at 2:00 PM, Matt Sicker <[email protected]> wrote: >> >>> Alright, I've got a pretty simple Serializable proxy class written. I'd >>> like to add equals() and hashCode() to AbstractLogger to aid in unit tests >>> and to formalize this concept of Logger uniqueness. >>> >>> On 16 October 2015 at 22:01, Matt Sicker <[email protected]> wrote: >>> >>>> 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]> >>>> >>> >>> >>> >>> -- >>> Matt Sicker <[email protected]> >>> >> >> > > > -- > Matt Sicker <[email protected]> > -- Matt Sicker <[email protected]>
