Hi!
I`ve restarted this thread as more information was aquired and other
questions aroused.
I have followed Dain advice and got my hands over log4j complete
manual. Great stuff I must say, really easy to follow.
However, browsing the book and the EJB specifications I have found the
following:
1
Sorry if I wasn't clear. I suggest you write a log4j appender with NIO
that has the features you need. Your application would continue to use
the enterprise log4j API but the underling implementation would have
the features you need. I suggest you buy the excellent log4j
documentation. Hey
Hi!
Thanks. I was actually looking through an oreilly book about NIO. The
only problem is how will this break the whole enterprise concept.
Don`t get me wrong, this is okay - thanks; but isn`t there something
in the enterprise arena. Having logs in an "enterprise manner" is no
new idea.
My conce
On Monday, March 24, 2003, at 09:49 AM, costin wrote:
I was thinking of wrapping the logging procedure into an transaction
but I don`t really know how the flushing of the files and all that is
handled by the virtual machine(some form of caching can prevent any
move I make).
The only way to get clo
Hi!
First of all thanks for the reply.
I know that the two attributes I`m looking for are basically exlusive
but to make my point clearer here.
The first priority is failure-proof. Logging in to a database isn`t
actually a solution. A lot of information will be kept in database for
no reason at al
"fast" and "failure-proof" are to a certain extent mutually exclusive.
If you want to be absolutely sre about your logging, than the log record
has to be written as part of the same transaction in which the event being
logged is executed. The ACID semantics of transactions ensure that
the log and
Hi!
I`ve approached this subject before on the list but I haven`t found
any satisfactory responses.
I have an application where logging is a HUGE priority. The usual
e-commerce one, where every "action" has to be logged. Now my
problem is this one.
Logging has to be fast and most i
