A couple of alternatives spring to mind.
1. If you're able and prepared to use a signed applet, the security
issues may go away.
2. You could handle Logger initialisation in a static block, catch
exceptions and provide a dummy implementation of Logger so that the
remainder of your code doesn't th
Chained exceptions were only introduced in JDK 1.4, so if there is a
requirement to run on JDK 1.3 (which we do) that might explain it.
Keith
-Original Message-
From: James Stauffer [mailto:[EMAIL PROTECTED]
Sent: 02 September 2005 18:00
To: Log4J Users List
Subject: Logging chained Exc
>> In the absence of var-args (recently introduced in JDK 1.5), this approach
>> would require us to add many new methods, taking 3, 4, 5, 6, etc. arguments.
Surely you could wrap the java.text.MessageFormat API?
It uses {0}, {1}, {2}, ... and an Object[] - this can be used for any number of
ar
Just my $0.02.
I agree with your use of FATAL, ERROR and DEBUG.
I also use ERROR in some cases when logging something that has gone wrong, even
though the result is predictable.
I use WARN for things that should not cause the application to fail, but are
not the "expected" use case, and may cau
Make all references to Logger objects either static, or transient.
That way there should be no attempt to serialize them.
Hope this helps
Keith
-Original Message-
From: Currimbhoy Shahyan [mailto:[EMAIL PROTECTED]
Sent: 02 December 2004 15:34
To: 'Log4J Users List'
Subject: Another probl
y
On Fri, 2004-11-19 at 02:21, Keith Hatton wrote:
> java.beans.Introspector.setBeanInfoSearchPath(new String[0]);
>
> I forget whether this eliminates the BeanInfo requests completely, or just
> reduces them.
>
> Hope this helps
> Keith
>
>
> -Original Message
java.beans.Introspector.setBeanInfoSearchPath(new String[0]);
I forget whether this eliminates the BeanInfo requests completely, or just
reduces them.
Hope this helps
Keith
-Original Message-
From: Jerry Seutter [mailto:[EMAIL PROTECTED]
Sent: 16 November 2004 21:51
To: log4j-user
Subj
Hi Michael,
I haven't had any direct experience of the type you describe, but I have a couple of
thoughts:
1. If you're using Java 1.4, you might be able to examine the stack trace
programatically, and not call any logging in your toString() if you realise that
you're already in a logging call
In the Weblogic console (or equivalently, somewhere in the weblogic.xml descriptor)
there is a "Prefer Web-Inf Classes" option, which I believe reverses (should that be
"standardizes"?) the classloader preference. Maybe this would help?
Keith
-Original Message-
From: Jacob Kjome [mailt
You might also consider using system-level logging (e.g. with NTEventLogAppender or
SyslogAppender, depending on the platform) or a SocketAppender from each application
to a listener in a fourth JVM on the box.
Keith
-Original Message-
From: Dennis Cook [mailto:[EMAIL PROTECTED]
Sent:
>> I believe Ceki's assertion that wrapping is the best and
safest thing to do from a software engineering standpoint. But, my users
and my boss care more about how fast the application performs. <<
Do no logging at all. That will be fastest. Of course, it may not be right, but you've
just sai
Ah! I knew there was a reason why I made my Loggers normal instance variables, I think
this was probably it from when I was playing around with WebSphere.
Just declare your logger as
private transient Logger logger = Logger.getLogger(...);
and remember to reinitialise it in ejbActivate(). It
It's consistent with the general rule that the JVM raises a subclass of Error when you
shouldn't normally attempt to recover from the failure condition. There was nothing
directly wrong with your request for class X; the error is that class X requires class
Y, which couldn't be found (and is pre
Hi Juergen,
I'm not sure that you would really use the SocketAppender, unless you were planning to
send IIOP messages down the socket yourself, which sounds like a lot of work
Maybe you could write an IDL interface and use the stub in an Appender class, so that
messages are sent to a CORBA se
Hi Ajay,
A real hack would be to redirect System.err to a file, then all calls to
printStackTrace() will magically go to that file. Use System.setErr(...) to do this.
Keith
-Original Message-
From: Ajay [mailto:[EMAIL PROTECTED]
Sent: 20 February 2004 04:06
To: Log4J Users List
Subject
>> I would log to the database. In the same transaction as the operation you
want to log about. <<
Beware ... this approach will never record any failed transactions, because the
logging will be rolled back along with everything else!
It really depends on what you really mean by 'reliability'. I
16 matches
Mail list logo
