Daniel: Perhaps you should view this problem a bit differently. Your problem is really one of organizing the log data. If you think about like that, then as long as the log messages contain enough information (e.g. client id, hostname, etc...), then you simply log all the data to single location (rolling files, Syslogd, Socket, etc...) and then write something on the receiving end that splits the logs according to your business requirements. This keeps your application simple, and it's overhead low, while also providing the reporting / organizational flexibility you need.
Tom Drake -----Original Message----- From: Mas�r Daniel [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 1:30 AM To: Log4J Users List Subject: RE: EJB and Log4J Thanks to all for valuable comments. Now I know what is behind mentioned constraint. In my case i can safely wrote files from EJB. Another thing: main goal of my logging solution is to don't serialize clients on log write operation. I want to create as many parallel log files as many concurrent client threads can be on EJB layer and reuse log files. As wrote Ingo lot of calls on log4j is serialized. So it seems that without rewrite of core components of log4j I don't know to avoid synchornization (sure there have to be some minimal synchornization)? Daniel Masar -----Original Message----- From: Ingo Adler [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 07, 2004 9:53 PM To: Log4J Users List Subject: Re: EJB and Log4J donald larmee|ALTERthought wrote: >As Michael indicated, it is generally an accepted practise to ignore >this aspect of the J2EE spec (for example, jboss usese log4j and >regularly writes flat log files...) > > > An application server (like JBoss) may use files or anything else it needs. The spec is about the applications running inside the application server. Nevertheless, the problem is not the usage of files, the problem is the synchronization which is done by log4j independent of the appender. Every call to a logger and most of the calls to an appender (derived from AppenderSkeleton) are synchronized. If you use the FileAppender anyway, don't write to the same file from different nodes in a clustered environment. Ingo. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
