RE: controlling the status logger output?

Just realized that maybe you meant we write our own application and handle the rollover in that app when you stated "That said, if you are concerned you can redirect stdout and implement the rolling yourself.". Thanks, Nick From: nic...@msn.com To: log4j-user@logging.apache.org Subject: RE:

Re: Zero conf is not showing logs even it's connected

I got following exception on my console, if it's hard to read it, you can see it on the stackoverflow: http://stackoverflow.com/questions/35784129/how-to-configure-port-in-apache-chainsaw-with-log4j2 WARNING: SocketListener(WS00943.local.).run() exception java.io.IOException: DNSIncoming

Re: Zero conf is not showing logs even it's connected

I'll need to dig in to this. The advertiserURI isn't coming across for some reason. Scott On 3/7/16, Bilguun Ariunbold wrote: > Thanks Scott, I've used the developer snapshot that you mentioned but still > no luck. If you see the screen shot that I attached,

Re: Log4j2 Backwards Compatibility

Most of our configuration would be rudimentary, from doing a sampling of the various config files I can just see many many instances of customized levels for loggers with quite simplistic file appenders / rolling appenders / Console appender. What I really want to do is utilize the LMAX Disruptor

Re: controlling the status logger output?

Log4j 2 has a BurstFilter that can be used for throttling. Ralph > On Mar 7, 2016, at 9:19 AM, Nicholas Duane wrote: > > I was asking about what's getting logged as I figured we shouldn't have that > much in there to be too worried about disk space consumption. The appender

Re: Log4j2 Backwards Compatibility

From the get-go Log4j implemented a new plugin system to make it easier for users to add their own components. In addition, new components such as global filters and markers were added. Finally, since the internal architecture changed none of the existing Log4j 1.x appenders or layouts could be

Re: controlling the status logger output?

On Mon, Mar 7, 2016 at 11:19 AM, Nicholas Duane wrote: > I guess we could write our own application which takes stdin and writes to > files and this could do the rolling file work. I would think something > like that might already exist in linux. > > Thanks, > Nick > take a

RE: controlling the status logger output?

I was asking about what's getting logged as I figured we shouldn't have that much in there to be too worried about disk space consumption. The appender in question is an https appender we wrote. If it encounters an exception is calls LOGGER.error(). We should have some throttling around that

Re: Log4j2 Backwards Compatibility

Was there a discussion at the outset of 2.X as to abandon support for the pre-existing ( if laboriously heavy ) configuration files as they stood ? A cost / benefit analysis ? It was obviously considered a blocking point to design backwards compatibility modules for the re-factored codeline

Re: Log4j2 Backwards Compatibility

Nobody ever said XSLT is simple ;) But the standard appenders and whatnot could probably be migrated to the equivalent appenders in 2.x. On 7 March 2016 at 10:04, Ralph Goers wrote: > I suspect it isn’t quite as simple as that. Many of the appenders use > different

Re: Log4j2 Backwards Compatibility

Ditto. Ralph is right. It's not really about the format but the different classes and options. Cheers, Paul On Mon, Mar 7, 2016 at 10:04 AM, Ralph Goers wrote: > I suspect it isn’t quite as simple as that. Many of the appenders use > different parameters, class

Re: Log4j2 Backwards Compatibility

I suspect it isn’t quite as simple as that. Many of the appenders use different parameters, class names aren’t specified any more, and the way parameters are specified is different. Ralph > On Mar 7, 2016, at 8:52 AM, Matt Sicker wrote: > > There is no current support for

Re: Log4j2 Backwards Compatibility

I would more than likely be forced to utilize a parser rather than an XSLT to transform their pre-existing files. Thanks for the info though. It'll be helpful when bringing the case for upgrade. Its a pretty dramatic modification to our codeline if done, 100's of poms owned by 10's of dev-teams /

Re: Zero conf is not showing logs even it's connected

Thanks Scott, I've used the developer snapshot that you mentioned but still no luck. If you see the screen shot that I attached, WS00943 is my machine's local domain, smdi.com is network's domain, 10.20.91.29 is my machine's ip address. It seems like it's trying to connect to

Re: controlling the status logger output?

If you set the status level to ERROR the StatusLogger should generate very little output. That said, if you are concerned you can redirect stdout and implement the rolling yourself. Ralph > On Mar 7, 2016, at 8:39 AM, Nicholas Duane wrote: > > We've written some appenders and

Re: controlling the status logger output?

The only thing I can think of is logrotate, but I'm not sure if that would work properly. StatusLogger is intentionally simple so that it will always work regardless of the rest of the system. On 7 March 2016 at 09:39, Nicholas Duane wrote: > We've written some appenders and I

Re: Log4j2 Backwards Compatibility

There is no current support for the previous format, but the docs do give examples on how to convert to the new format: http://logging.apache.org/log4j/2.x/manual/migration.html Patches are always welcome to add support for the old config format, but it's non-trivial. The new formats are very

Log4j2 Backwards Compatibility

Hi Log4j Usergroup, I have a question regarding support for the previous 1.x configuration files. I wish to upgrade the version of Log4j across my companies platform, however when we deploy our software we expose public logger xml files for our clients to customize as they wish, this means that

controlling the status logger output?

We've written some appenders and I think the prescribed approach is to use the status logger in log4j2 components, is that correct? The problem we're running into is that we redirect stdout to a file and thus that file can grow unbounded. It seems there's no way to have something like a