> -----Original Message-----
> From: Bryan Pendleton [mailto:bryan.pendleton@...]
> Sent: 29 June 2001 21:04
> To: firstname.lastname@example.org
> Subject: RE: [xml-dbms] Log4J
> > as a general rule, I am a big fan of abstracting this sort
> of thing and
> > people swap modules in and out as they please. No matter
> how popular one
> > product is, you can always find somebody who thinks it's lousy and
> > swears by another product.
> These are wise words.
I prefer it too...however I know very little about log4j (though others
around me here @ work do as it's out std logger for our internal products).
> > That said, is there enough commonality among loggers that we
> > could hide them behind a simple interface like:
> Sure. I see absolutely nothing wrong with going through the exercise
> of defining exactly what it is that you need from a logging facility,
> then defining your own interface which describes those exact needs,
> then implementing that interface with some code which wraps around
> log4j and calls it to implement the functionality.
> Later, you could easily add other implementations which wrap your
> interface around other logging facilities.
> That's just common sense, and good engineering, and thus I never had
> any doubt that you guys would do exactly that :-)
Gee thanx <G>.
> From a detail point of view, though, I definitely recommend that you
> spend the time to read carefully through the log4j "short
> document (http://jakarta.apache.org/log4j/docs/manual.html),
> as well as
> the older and shorter version
> These guys have spent an immense amount of time thinking
> about this problem
> and working on it, and the log4j system is truly impressive.
I know & accept that they've done a good job.
> The hard part will be when you get down to defining your specific
> interface. Once you realize what log4j offers, my bet is that you will
> want to have most, if not all, of its features in your interface. For
> example, the Category hierarchy, the concept of priorities, and the
> ability to have multiple appenders with different layouts, is just so
> incredibly valuable that you will kick yourself if you skip
> those things.
My initial idea is to shove in Log4J such that I can get a grip on how it
works & what sort of interface would be required. The main "alternative"
implementation would be a simple System.out.println. i.e. if no logger was
defined in the properties file it would assume the System.out.println
implementation as that's the only one you could assume would be present.
> At that point, the question is whether you can find any other
> existing logging systems to evaluate so that you can decide whether
> your interface truly represents a least common denominator of the
> pluggable logging systems that you want to support.
> In practice, log4j is just so good that every other logging system out
> there (other than internal proprietary systems developed by companies
> such as my prior companies) has vanished, and everybody has
> switched to using log4j.
> OK, I'll climb off my "violent agreement with you" soapbox now.
I don't suppose you could look at helping with doing the logging bit?
I need to be able to wrap XD & to pull messages out of it & then take
actions based on those messages. The easiest example is if an error is
returned which shows that for some reason the message / xmlString has not
been committed in the DB (e.g. the ethernet cable has come out the back of
the DB server) then I would have to place the message onto a "Dead letter
Queue / topic" along with a message/note saying why it had failed & possibly
what action the administrator should take.
As an example you mentioned that you had placed logging code into the bit
where the prepared statements are executed. Could you send me that so that I
can look at it?