You don't have to manage your disk space from within log4j. To conserve
hard-drive space, you can use classes in the java.util.zip package to zip
up your log files. You can schedule a nightly batch job that kicks off a
Java class that uses java.util.zip. The book "Java i/O" by O'Reilly gives
Our problem is that our log files grow horribly (and unavoidably)
quickly. About a gig a day. So I'd like to put the logs in a more
readable structure.
I don't want to zip the logs at the end of each day because, well,
because they aren't archives yet and they'll still get potentially
plenty of
Hi Alan & all,
I have a similar situation with one of my products. I am considering logging to a
local database.
BTW, there is a DailyRollingFileAppender already in there also.
for e.g. I have the following configuration for one of my loggers: -
log4j.logger.site=DEBUG, S2
log4j.appender.S2=or
Yes, but the problem with the DailyRollingFileAppender is it doesn't
roll based on size as well as date. I seem to have to choose between
the 2 when I want them both.
-Original Message-
From: Samir Shaikh [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 29, 2004 9:45 AM
To: Log4J Users Li
Hi,
>So I'm still leaning toward writing my own subclass of FileAppender
that
>merges the features of Daily and Rolling, with the Daily part of the
>functionality creating new Directories for the 'rolling' functionality
>to 'roll' within.
>
>In an ideal world there would be hooks inside FileAppen
look at JDBCAppender. If you have such huge log files, it may not be the best design
to log on disk.
-Original Message-
From: Alan Brown [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 29, 2004 9:48 AM
To: Log4J Users List
Subject: RE: An odd configuration need...
Yes, but the problem
Thanks for the heads up. But chances that I'll be allowed to use
beta-code on my production system (let alone cvs nightly builds) or
pretty remote. But I certainly look forward to using it when it's
released.
-Original Message-
From: Shapira, Yoav [mailto:[EMAIL PROTECTED]
Sent: Thurs
Hello all.
I currently have two configuration files: one for log4j and one for other
properties. The other properties file includes key=value pairs for system
information, such as the URL for finding EJBs (PROVIDER_URL =
iiop://123.456.78.910:9000). I would like to combine the two files so
Alan,
As Yoav mentioned in a previous email, log4j 1.3 (currently marked as
alpha-0) has exactly what you are looking for. The method of renaming,
archiving, etc are based on strategies and hooks within a special appender
extending FileAppender, very similar to what you have described. :-)
At
Thanks Ceki (for the great product as well as the 1.3 tip) but for the moment, alpha
builds are off limits for my production environment. For the moment I've written
myself a quick and dirty DirectoryRollingFileAppender that suits my very specific
needs (subclassing RollingFileAppender and borr
jk> http://wiki.apache.org/logging-log4j/Log4JProjectPages/UsefulCode
wjc> I'm a little confused by this cite. I presume you're talking
wjc> about the Log4jConfigurator example.
jk> Did you look at the code above the Log4jConfigurator example?
jk> Looks pretty similar to what you are doing below
Hi,
>Instead, I have finally gotten around to writing a bug report about
>the funky default behavior in log4j (which is my main reason for
>wondering it log4j is already configured).
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28692
I've -1's this (message below), but stopped short of m
At 09:16 PM 4/29/2004, Shapira, Yoav wrote:
Hi,
>Instead, I have finally gotten around to writing a bug report about
>the funky default behavior in log4j (which is my main reason for
>wondering it log4j is already configured).
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28692
I've -1's t
ys> I'm -1 on changing this: in the absence of explicit configuration,
ys> it's better to have more information than less, so the current
ys> default is best. Obviously there'll be scenarios where it's
ys> expensive and/or ill-fitting, but those people should explicitly
ys> configure log4j. The d
Hi,
>I don't understand your comments. With the current defaults there are
>no appenders, so *no* information is logged except a single console
I thought you meant the default configuration as in
BasicConfigurator.configure being called? Maybe I misunderstood your
original point.
>least reason
Is it possible to attach to an appender to a specific level? If all my code
is in sps.webec can I make an appender only log events under sps.webec?
I think what you're asking is part of Log4J central design philosophy.
Assuming you're following the standard method of logging (instantiating
a logger for each class with the fully qualified class name as the
logger name) what you want to do is add the following lines to your
log4j properties file
Do you have an XML example?
-Original Message-
From: Alan Brown [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 29, 2004 4:08 PM
To: Log4J Users List
Subject: RE: Appender attached to a specific level
I think what you're asking is part of Log4J central design philosophy.
Assuming you're
Sorry. There was a glaring error in my example. I copied it out of my
properties file and didn't change the first line... it should read
log4j.logger.sps.webec = DEBUG, A2
I don't have an xml version, but it must be the same format. The first
line states that all classes whose FQCN begins wit
So would the following log everything under sps.webec?
-Original Message-
From: Alan Brown [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 29, 2004 4:15 PM
To: Log4J Users List
Subject: RE: Appender attached to a specific level
Sorry. There was a glaring error in my exa
ys> That would be a good safe practice, yeah: if you're writing a
ys> library, and are relying on someone else to provide the
ys> configuration for logging, you should check that the logging was
ys> indeed configuration and if not take action (raise exception,
ys> configure it for your needs, whate
> Thanks Ceki (for the great product as well as the 1.3 tip)
> but for the moment, alpha builds are off limits for my
> production environment. For the moment I've written myself a
> quick and dirty DirectoryRollingFileAppender that suits my
> very specific needs (subclassing RollingFileAppend
Good point. Is there a list of known issues with 1.3 (so I can check if I
need to fix anything before I use it)? One thing is that there may be a
danger that some "interface" will change from now to release that will
require changes to how we use it -- pre-release software is often more in a
stat
> Good point. Is there a list of known issues with 1.3 (so I
> can check if I
> need to fix anything before I use it)? One thing is that
> there may be a
> danger that some "interface" will change from now to release that will
> require changes to how we use it -- pre-release software is
> oft
Often for a new release the code starts out with a lot of change and then
gradually stabilizes until release. It would be good to know about how
stable the code is. I realize that there are no guarantees and I don't
expect any. I just want an honest estimation of how stable/complete it is.
Do th
When I develop new code there are 3 stages (at least): in flux, basically
works, and works well. I understand that it won't be released until it
works well but I don't want to use it if the parts I need are still in flux.
If they basically work then I would consider it.
-Original Message-
If you want my own personal opinion (and not those of the log4j dev team as
a whole, although feel free to step in), I would place the CVS HEAD of log4j
in the "works pretty well" category, so somewhere after "basically works"
but maybe a touch before "works well".
Paul
> -Original Message-
Thanks. I'll try it. A lot of my code that is in production still only
"works pretty well". :-)
Also, did I do anything wrong with my enhancement submission? (I understand
if everyone is busy, etc but I was just wondering if I did something wrong.)
-Original Message-
From: Paul Smith [ma
> Also, did I do anything wrong with my enhancement submission?
> (I understand
> if everyone is busy, etc but I was just wondering if I did
> something wrong.)
If you posted it into Bugz, don't worry, we've seen it or will see it and it
won't get lost, but if you posted it to the dev list direc
The reason that my company won't use alpha code but will write on top of
released code is that we contain the scope of our risk. If I just write
one class and everything else is stable and trusted then our risk is
much lower than using an unstable release where our developers would
have to be resp
Actually, I think the title is a bit of a misnoma as it's disk space I'm
looking to cap the usage of.
I was wondering if anything in 1.3 would enable me to ensure I won't run
out of hard drive. I know it's cheap and all that but, depending on the
performance cost, I'd like to be able to guarant
> The reason that my company won't use alpha code but will
> write on top of
> released code is that we contain the scope of our risk. If I
> just write
> one class and everything else is stable and trusted then our risk is
> much lower than using an unstable release where our developers would
>
Just to clarify...
> Whenever I use Log4J, it could be said that I'm potentially
> introducing
> bugs.
Actually, whenever you use Microsoft products, or even a
Databaseserver you put portions of your risk in someone elses
hands, production or not
Altho
>
>
> Actually, I think the title is a bit of a misnoma as it's
> disk space I'm
> looking to cap the usage of.
>
> I was wondering if anything in 1.3 would enable me to ensure
> I won't run
> out of hard drive. I know it's cheap and all that but,
> depending on the
> performance cost, I'd
34 matches
Mail list logo
