Hello, > > 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 6.2.3. 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 properties. Regards Boris [1] http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
