RE: [xml-dbms] Log4J
> -----Original Message-----I prefer it too...however I know very little about log4j (though others
> From: Bryan Pendleton [mailto:bryan.pendleton@...]
> Sent: 29 June 2001 21:04
> To: email@example.com
> 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.
around me here @ work do as it's out std logger for our internal products).
> > That said, is there enough commonality among loggers that weGee thanx <G>.
> > 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 :-)
> From a detail point of view, though, I definitely recommend that youI know & accept that they've done a good job.
> 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.
> The hard part will be when you get down to defining your specificMy initial idea is to shove in Log4J such that I can get a grip on how it
> 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.
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 otherI don't suppose you could look at helping with doing the logging bit?
> 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 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?