Howdy,
You could always read the log4j configuration file yourself, using just the normal
java.util.Properties class. Look for properties whose name ends in "File", and try to
do a new File(...) on the value of these properties.
Yoav Shapira
Millennium ChemInformatics
>-Original Message-
David,
Your question is more appropriate for the log4j-user email list.
Have you looked into using the MDC to store the session id? You can then
output the current sessionid as part of the message. The stock pattern
layout uses the %X escape sequence to print out MDC key/value pairs.
-Mark
>
Richard,
What do you want to use this value for? What would you like the value to
be?
-Mark
ps Sorry for the delay, things got busy here are work too...:-)
---
Ceki/Mark,
Can you add a toString() method to the
A
He he he, work shmork :-)
I figured that returning the appender's name would be
handy.
Basically, I have a List of Objects - Strings,
appenders, and Loggers. These objects are displayed
in a JList. So, either the toString() method is
overridden to display something pretty and nice (like
the appe
Hello all,
I finally have more time as a major deadline has passed at work. I was
thinking about writing an improved JDBC appender. My intention is to
create a new appender from scratch. As discussed previously, I figured
I would have an abstract base class with an abstract getConnection()
> I figured
> I would have an abstract base class with an abstract getConnection()
> class and two concrete derivatives; one for getting the
> connection from
> a JNDI context and one for getting the connection from the
> DriverManager.
This isn't too bad an idea, but I'm personally against a
Paul Smith wrote:
I figured
I would have an abstract base class with an abstract getConnection()
class and two concrete derivatives; one for getting the
connection from
a JNDI context and one for getting the connection from the
DriverManager.
This isn't too bad an idea, but I'm personally ag
Raymond,
> I finally have more time as a major deadline has passed at
> work. I was
> thinking about writing an improved JDBC appender. My intention is to
> create a new appender from scratch. As discussed previously,
> I figured
> I would have an abstract base class with an abstract getCo
> Well, in terms of cleaner code, I don't think that introducing inner
> classes is the way to go. Personally I think it will be much
> easier for
> the end-user to understand that if they are using a
> DataSource from JNDI
> they use the JNDIPreparedStatementAppender with set A of
> options
Hi
Inner classes are a bad thing, maily becase they are not protected in
the same way as regular classes.
I think that the abstract class aproach is a good idea. I take it that
the configuration can be done through the log4j properties fil.
Hermod
-Opprinnelig melding-
Fra: Paul Smith [
Hi
Maybe you should take a look at the DBCP stuff that is used in Tomcat,
with regards to instatiation etc.
-Opprinnelig melding-
Fra: Raymond DeCampo [mailto:[EMAIL PROTECTED]
Sendt: 1. april 2003 05:14
Til: [EMAIL PROTECTED]
Emne: JDBC Appender
Hello all,
I finally have more time as
Joshua Blocks "Effective Java" advocates Composition over inheritence, and
I've very much warmed to that approach now, hence my preference.
I'd agree that the use of inner classes is maybe not the best. I'd actually
meant that they are private static inner classes, used by a lookup via a
handle
Hi
With the danger of derailing the subject I do appreciate you thoughts.
The discussion of containment vs. inheritance is a long and weildy one
and better done some somewhere else.
Hermod
-Opprinnelig melding-
Fra: Paul Smith [mailto:[EMAIL PROTECTED]
Sendt: 1. april 2003 08:58
Til: 'Lo
Hello all,
I finally have more time as a major deadline has passed at work. I was
thinking about writing an improved JDBC appender. My intention is to
create a new appender from scratch. As discussed previously, I figured I
would have an abstract base class with an abstract getConnection()
14 matches
Mail list logo
