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]>
