Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Ralph Goers
Sounds good. This approach allows for many different serialization formats. It might be nice to have the CompactBinaryLayout even be “pluggable” to support things like Hessian, Protobuf, Thrift, etc. Of course, that would also require the LogEventBridge to have support as well. Ralph On Ju

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Gary Gregory
It sounds good to go with an initial Serializable format that is easy to maintain and provide an additional format later that is optimized. Gary On Fri, Jul 11, 2014 at 1:14 PM, Scott Harrington wrote: > OK! Agree. So the 2.1 enhancement request will be for a > CompactBinaryLayout on the sendi

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Scott Harrington
OK! Agree. So the 2.1 enhancement request will be for a CompactBinaryLayout on the sending side and corresponding LogEventBridge on the receiving side. I'll open it in JIRA when I get back from vacation and have a chance to work through an initial implementation, unless someone else beats me to

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Remko Popma
Yes that is what I had in mind. On Sat, Jul 12, 2014 at 1:53 AM, Scott Harrington wrote: > Yes it did appear toByteArray would do the job on the /sending/ side but > what about the /receiving/ side? We've got to put some bytes on the wire > that will come out as a LogEvent from the readObject()

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Scott Harrington
Yes it did appear toByteArray would do the job on the /sending/ side but what about the /receiving/ side? We've got to put some bytes on the wire that will come out as a LogEvent from the readObject() call in ObjectInputStreamLogEventBridge. You can't have the sender be Externalizable and the r

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Remko Popma
On Sat, Jul 12, 2014 at 12:52 AM, Remko Popma wrote: > What prevents you from writing a more compact representation of the > LogEvent (including all other LogEvent fields) to the byte array in the > {{toByteArray(LogEvent)}} method of an ExternalizableLayout? > (Just to clarify, I intended this q

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Remko Popma
What prevents you from writing a more compact representation of the LogEvent (including all other LogEvent fields) to the byte array in the {{toByteArray(LogEvent)}} method of an ExternalizableLayout? On Sat, Jul 12, 2014 at 12:45 AM, Scott Harrington wrote: > I looked at replacing SerializedLa

Re: All log4j appenders defined in log4j.properties in play

2014-07-11 Thread Jacob Kjome
First, your understanding is incorrect.  You can attach appenders to any logger, not just the root.  Second, there must be some other stray log4j config file being loaded, instead of this one, that logs to a file appender pointing at the same file as the one in this log4j.properties. I sugge

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Scott Harrington
I looked at replacing SerializedLayout and/or the toSerializable method but the real savings comes not from the Message itself but from all the other fields of the LogEvent, such as the Level, ContextMap, ContextStack, and the class descriptor (including superclasses) of the LogEvent itself. F

Re: log4j.properties gets loaded twice causing rollling to fail

2014-07-11 Thread Jacob Kjome
Why don't you place your webapp's log4j.properties file in WEB-INF/classes instead of WEB-INF/classes/properties?  That way, the webapp classloader won't ever see the tomcat log4j.properties, thus no rolling file appender conflicts. Jake On Fri, 11 Jul 2014 11:16:41 +0800  guowei wrote: De

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Remko Popma
That is a nice reduction in size! I also think the ExternalizedLayout idea is a very attractive option. That way there is no pressure to include this in any particular release, we can release it when we are confident that is ready. I also like the fact that it does not replace the current serializ

Re: All log4j appenders defined in log4j.properties in play

2014-07-11 Thread Matt Sicker
Check out the additivity setting. Plus, check out Log4j 2.0 as that's what we're all focused on right now! On 11 July 2014 01:01, Vishal Pore wrote: > My log4j.properties file is pasted below. My understanding is that we need > to add Appenders to the *root *logger for the appender to work. As

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Matt Sicker
I would second the ExternalizedLayout. Layouts are the way to go for compatibility and are simpler. Particularly useful for alternative serialization protocols, too. On 11 July 2014 06:41, Gary Gregory wrote: > I understand Ralph ' s concern but now is the time for this kind of > change. Other

Re: Make LogEvent implementations Externalizable

2014-07-11 Thread Gary Gregory
I understand Ralph ' s concern but now is the time for this kind of change.   Otherwise we will need even more clever solutions to get this kind of size improvement. I'd love to see some performance numbers. The size improvement is not negligible, which is great! Gary Original messag

RE: Make LogEvent implementations Externalizable

2014-07-11 Thread Gary Gregory
Very clever! I'd love to see the whole implementation and reports you are describing.  Gary Original message From: Scott Harrington Date:07/11/2014 00:23 (GMT-05:00) To: Log4J Users List Subject: Make LogEvent implementations Externalizable Ralph & co: I hear you're gea