Yes, I would suggest adding non-space delimiters between fields (dashes) or around fields (square brackets)...
On Sat, Feb 23, 2013 at 8:05 AM, Tech Mail <[email protected]> wrote: > Thank you Ralph, Scott, > > Can (VFS)LogFilePatternReceiver this class be improved to accept pattern > layout string as log format? So that there is no error in manually > changing the format? > > Also how does the headers, fields constructed back if the data itself has > the field separators. > > Is there any field terminator I can provide in pattern layout instead of > space? Some times MDC context is empty and some times data in MDC context > has spaces which when reconstructed the fields has wrong data. How do I > handle this? > > Thanks, > Yogi > > On Feb 22, 2013, at 11:42 PM, Ralph Goers <[email protected]> > wrote: > > > I think you are mistaken on the number of Appenders that are missing. > > > > Log4j 2 does have a SocketAppender. It supports both TCP and UDP and > accepts a Layout to allow whatever is sent to be formatted any way you > want. The existing SocketServer expects a serialized event. The XMLLayout > could be used instead. In fact, the SyslogAppender just extends the > SocketAppender and hard codes the layout to match either the BSD or RFC > 5424 syslog layout. > > > > There are both a JMSTopicAppender and a JMSQueueAppender. There is a > Receiver for each, although they probably don't conform to what you would > want. > > > > Of course there is a FileAppender that accepts any layout. There is no > Receiver. > > > > You are correct that there is currently not a DBAppender or Receiver. > > > > I don't know what it means to say Log4j 2 doesn't have non-Log4j 1.x > appenders. > > > > When I started working on Log4j 2 I don't recall any of the receivers > being part of the codebase but in some companion layer. I have no problem > with having them being added. > > > > If you really feel something is missing you are welcome to commit it. > > > > Ralph > > > > On Feb 22, 2013, at 4:58 PM, Scott Deboy wrote: > > > >> I forgot the two main socket appenders of course: > >> SocketAppender -> SocketReceiver > >> SocketHubAppender -> SocketHubReceiver (allow reverse-connects from the > >> 'receiver' to the 'appender') > >> > >> > >> On Fri, Feb 22, 2013 at 4:51 PM, Scott Deboy <[email protected]> > wrote: > >> > >>> There are quite a few appenders and associated receivers in log4j 1.x. > >>> Most of these appenders and all of these receivers are missing in > log4j2: > >>> > >>> MulticastAppender->MulticastReceiver > >>> UDPAppender and non-log4j appenders which support generating events > over > >>> UDP which conform to log4j's dtd (log4net, etc)->UDPReceiver > >>> *FileAppender with a regular text layout->(VFS)LogFilePatternReceiver > >>> *FileAppender with an xml layout->LogFileXMLReceiver > >>> non-log4j appenders which support generating events over TCP which > conform > >>> to log4j's dtd (log4perl, etc)->XMLSocketReceiver > >>> JMSAppender->JMSReceiver > >>> DBAppender->DBReceiver (DBAppender uses a predefined schema) > >>> Custom DB definition->CustomSQLDBReceiver > >>> > >>> There may be others, those are the ones I can remember off the top of > my > >>> head. > >>> > >>> Scott > >>> > >>> > >>> On Fri, Feb 22, 2013 at 4:44 PM, Scott Deboy <[email protected] > >wrote: > >>> > >>>> In log4j1.x, yes, receivers can be configured via the 'plugin' > element in > >>>> log4j.xml and eventually end up appending received events to the local > >>>> log4j system, which are then picked up by locally defined appenders. > This > >>>> is how Chainsaw works - it programmatically registers its own > appender to > >>>> pull in events appended by the configured receivers. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> On Fri, Feb 22, 2013 at 4:37 PM, Ralph Goers < > [email protected]>wrote: > >>>> > >>>>> Not in the configuration as yet. However, I've implemented a > couple of > >>>>> "servers" that are independent "main programs" that can receive log > events. > >>>>> I am assuming that the main difference is that the receiver would > not be a > >>>>> main but would be embedded in the application. > >>>>> > >>>>> Where are they documented? > >>>>> > >>>>> Ralph > >>>>> > >>>>> > >>>>> On Feb 22, 2013, at 3:51 PM, Scott Deboy wrote: > >>>>> > >>>>>> Log4j2 has no concept of receivers, correct? > >>>>>> > >>>>>> > >>>>>> On Fri, Feb 22, 2013 at 3:39 PM, Ralph Goers < > >>>>> [email protected]>wrote: > >>>>>> > >>>>>>> Scott, > >>>>>>> > >>>>>>> Yogi has been asking other questions about Log4j 2 so I'm not clear > >>>>> if his > >>>>>>> question applies to that or 1.x. Or does the > >>>>> VFSLogFilePatternReceiver > >>>>>>> work with Log4j 2? > >>>>>>> > >>>>>>> Ralph > >>>>>>> > >>>>>>> > >>>>>>> On Feb 22, 2013, at 3:32 PM, Scott Deboy wrote: > >>>>>>> > >>>>>>>> If you want the events to end up in log4j (being processed by an > >>>>>>> appender, > >>>>>>>> it's very easy, just define a (VFS)LogFilePatternReceiver in your > >>>>> log4j > >>>>>>>> configuration file. > >>>>>>>> > >>>>>>>> If you instead want the LogEvents so you can do something else > with > >>>>> them, > >>>>>>>> you can use the (VFS)LogFilePatternReceiver outside of log4j, just > >>>>>>>> construct it, call appropriate setters, and call activateOptions. > >>>>>>> Wherever > >>>>>>>> the receiver calls doPost, you can instead hold on to the > generated > >>>>>>> event. > >>>>> > http://svn.apache.org/repos/asf/logging/chainsaw/trunk/src/main/java/org/apache/log4j/varia/LogFilePatternReceiver.java > >>>>>>>> > >>>>>>>> The VFS version supports Commons-VFS sources (sftp, etc): > >>>>> > http://svn.apache.org/repos/asf/logging/chainsaw/trunk/src/main/java/org/apache/log4j/chainsaw/vfs/VFSLogFilePatternReceiver.java > >>>>>>>> > >>>>>>>> Scott > >>>>>>>> > >>>>>>>> > >>>>>>>> On Fri, Feb 22, 2013 at 2:23 PM, Yogi Nerella < > [email protected] > >>>>>> > >>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> Any tools which can take a log file and the pattern string and > >>>>> generate > >>>>>>> the > >>>>>>>>> events? > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> Yogi > >>>>>>> > >>>>>>> > >>>>>>> > --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>> For additional commands, e-mail: > [email protected] > >>>>> > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
