commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Boris Unckel" <>
Subject Re: [logging] J2EE resource adapter
Date Mon, 05 Dec 2005 13:31:57 GMT

> > IMHO you're better off implementing such a functionality for a
> > specific logger implementation and enable it in that configuration.
> > 
> > Thoughts?
> > 
> > - Jörg
> > 
> Jörg, thanks for your feedback. I know that it is just a wrapper. That's 
> an advantage in my opinion. Because the resource adapter could then be 
> used with any logging framework. The timestamp problem has also occurred 
> to me. It can not be solved by using Log4J directly either. I don't mean 
> the rar should go into the standard JCL distribution. It could be an 
> add-on package.
> Ortwin
I think this is a bad idea. Not in sense of the technical
design/implementation, but looking at the use-case:
To document business transactions you have to collect informations about
them. I am working at a IT center for banks. A simple transaction could
modifiy an account and the customer who owns the account. I would have to
document three things: the usecase (changing name becaus of marriage), the
id of the account, the id of the customer and old/new value of his/her name.
Doing this with a logging framework would mean to pass everthing to a
String, we could discuss csv or a readable form
(4711,2323,changename,maier,schmidt or CustomerID[4711] AccountId[2323]
UseCase[changename] OldValue[Maier] NewValue[Schmidt]).
Having these things in a file is a bad idea in my opinion. This is a classic
case for a structured persistence, a database.

One part is a very good idea:
To establish a RAR Handler/Appender for logging (meant as classic logging
for debug/info/error program information). This has a technical reason:
File access is limited by the J2EE specification (most vendors allow more,
but the spec describes restricted access), see [1] section 6.2ff, especially

To conform to J2EE one has to use a Resource Adaptor for logging.
I know that this is different to actual practice and technical restrictions
of J2EE Application server implementations, but may change in future. I.E.
when the security permissions are enforced by the AppServers by Code, not by



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message