headers
Mark Womack | 1 Apr 2003 02:30

RE: "Acorn" request for core log4j

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
AppenderSkeleton and the Logger objects?  I'm
displaying these in the gui, and thought that the
toString() method would be a great way of displaying
them (doesn't require me to cast from Object).  Any
objections?

Thanks,
Richard
Permalink | Reply | 501 comments |
headers
Richard Bair | 1 Apr 2003 02:36
Picon
Favicon

RE: "Acorn" request for core log4j

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 appender name), or I have to detect what type of
object is in the List and then either show its name,
or call toString(), etc depending on the object type. 
I may end up taking the latter approach anyway because
it gives me greater flexibilty in what I display in
the JList.  It just might be nice to print something
besides the object's hash in memory on a toString()
call by default.

Not very critical at this point.

Richard

--- Mark Womack <mwomack <at> bevocal.com> wrote:
> Richard,
> 
> What do you want to use this value for?  What would
> you like the value to
> be?
> 
> -Mark
(Continue reading)

Permalink | Reply | 501 comments |
headers
Raymond DeCampo | 1 Apr 2003 05:14
Picon

JDBC Appender

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() 
class and two concrete derivatives; one for getting the connection from 
a JNDI context and one for getting the connection from the DriverManager.

I just wanted to check in to see if anybody is working on this already. 
  I also have a couple of questions:

1)  The original JDBCAppender class has a buffer where it stored the 
events until a limit is hit.  I'm not sure I understand the rationale 
behind this.  Doesn't this cause most loggings to be fast but once in a 
while one client pays the bill for the rest?  It also seems to have been 
a source of bugs in the past.  Does anyone have a compelling reason for 
including it in the new appenders?

2)  Is there a good place to look to get a feel for how the 
configuration works?

Thanks,
Ray
Permalink | Reply | 16 comments |
headers
Paul Smith | 1 Apr 2003 05:17
Picon

RE: JDBC Appender

> 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 an Abstract class
here (and I'm no committer so take this with a grain of salt).  What would
be ideal is if the configuration of the JDBCAppender could be specified with
an option that describes the Strategy to obtain a Connection.   Just like
you provide a Layout impl for an appender as a attribute.

This way you have a single class, but have smaller inner classes with the
different ways of getting the connection.  I think this ends up being
cleaner code, and easier to understand (I think a lot of people get lost
with inheritence, and by that I include me).

> 1)  The original JDBCAppender class has a buffer where it stored the 
> events until a limit is hit.  I'm not sure I understand the rationale 
> behind this.  Doesn't this cause most loggings to be fast but 
> once in a 
> while one client pays the bill for the rest?  It also seems 
> to have been 
> a source of bugs in the past.  Does anyone have a compelling 
> reason for 
> including it in the new appenders?

You have a good point on the penalty (not sure if it does this, but if it
does, it is bad).  What would be more ideal is to buffer the events till
(Continue reading)

Permalink | Reply | 1 comment |
headers
Raymond DeCampo | 1 Apr 2003 06:20
Picon

Re: JDBC Appender

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 against an Abstract class
> here (and I'm no committer so take this with a grain of salt).  What would
> be ideal is if the configuration of the JDBCAppender could be specified with
> an option that describes the Strategy to obtain a Connection.   Just like
> you provide a Layout impl for an appender as a attribute.
> 
> This way you have a single class, but have smaller inner classes with the
> different ways of getting the connection.  I think this ends up being
> cleaner code, and easier to understand (I think a lot of people get lost
> with inheritence, and by that I include me).

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 and if 
they are using the traditional DriverManager they use 
URLPreparedStatementAppender (I'm open to suggestions on the name) with 
set B of options.  They never need to know that there is an abstract 
class that contains the common code.  Furthermore, it provides a clean 
way for an end-user to customize how they get their Connections if they 
are implementing pooling or such things themselves (i.e. extend the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Womack | 1 Apr 2003 07:09

RE: JDBC Appender

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 getConnection() 
> class and two concrete derivatives; one for getting the 
> connection from 
> a JNDI context and one for getting the connection from the 
> DriverManager.

That is one way.  Another way, similar to what Paul Smith was articulating,
would be to allow a configuration value for a class that implements a known
interface that returns a connection (and maybe a host of other behavior
information).  I could go either way; the most important point is the
clarity of design so that developers 

a) understand what needs to be overridden/written where.
b) understand what information is needed for configuration.

Your way might be better for configuration issues (trying to set the
configuration items on a "connection class" configuration could get hairy).

> 1)  The original JDBCAppender class has a buffer where it stored the 
> events until a limit is hit.  I'm not sure I understand the rationale 
> behind this.  Doesn't this cause most loggings to be fast but 
> once in a 
> while one client pays the bill for the rest?  It also seems
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Smith | 1 Apr 2003 07:12
Picon

RE: JDBC Appender

> 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 and if 
> they are using the traditional DriverManager they use 
> URLPreparedStatementAppender (I'm open to suggestions on the 
> name) with 
> set B of options.  They never need to know that there is an abstract 
> class that contains the common code.  Furthermore, it 
> provides a clean 
> way for an end-user to customize how they get their 
> Connections if they 
> are implementing pooling or such things themselves (i.e. extend the 
> class and implement the getConnection() method).

I think it will definately depend on peoples preference, but in the end,
it's just a JDBCAppender, with different ways of obtaining a connection (a
selectable ConnectionFactory if you will, in fact Mark just intimated the
same thing in an email that just popped in).  Ideally from a developers and
users point of view, the JavaDoc for the single class file would contain all
the docs they need to understand it.  Using an abstract class and having
separate Appender's could lead to inheritence explosion if additional ways
of obtaining the Connection are found (i.e. through a separate Pooling
implementation).

> Executing in a separate thread has consequences from within an EJB 
> container (i.e., it's a no-no).
(Continue reading)

Permalink | Reply | 0 comments |
headers
hermod.opstvedt | 1 Apr 2003 08:33
Picon

SV: JDBC Appender

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 [mailto:Paul.Smith <at> lawlex.com.au]
Sendt: 1. april 2003 05:18
Til: 'Log4J Developers List'
Emne: RE: JDBC Appender

> 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 an Abstract class
here (and I'm no committer so take this with a grain of salt).  What
would
be ideal is if the configuration of the JDBCAppender could be specified
with
an option that describes the Strategy to obtain a Connection.   Just
like
(Continue reading)

Permalink | Reply | 0 comments |
headers
hermod.opstvedt | 1 Apr 2003 08:36
Picon

SV: JDBC Appender

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:rdecampo <at> twcny.rr.com]
Sendt: 1. april 2003 05:14
Til: log4j-dev <at> jakarta.apache.org
Emne: JDBC Appender

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() 
class and two concrete derivatives; one for getting the connection from 
a JNDI context and one for getting the connection from the
DriverManager.

I just wanted to check in to see if anybody is working on this already. 
  I also have a couple of questions:

1)  The original JDBCAppender class has a buffer where it stored the 
events until a limit is hit.  I'm not sure I understand the rationale 
behind this.  Doesn't this cause most loggings to be fast but once in a 
while one client pays the bill for the rest?  It also seems to have been

a source of bugs in the past.  Does anyone have a compelling reason for
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Smith | 1 Apr 2003 08:57
Picon

RE: JDBC Appender

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 in the configuration, but probably best to have them as they're own
factory implementations as Mark suggested.

Another way to think of the non-abstract approach is the way the appender
gets it's connection could be similar to the way an Appender gets it's
Layout, via a configuration item.

cheers,

Paul

> -----Original Message-----
> From: hermod.opstvedt <at> dnb.no [mailto:hermod.opstvedt <at> dnb.no]
> Sent: Tuesday, 1 April 2003 4:34 PM
> To: log4j-dev <at> jakarta.apache.org
> Subject: SV: JDBC Appender
> 
> 
> 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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane