how about just using Log4J from Apache.
Fast, Free and open source and doesn't make the ejbs violate the IO spec
Filip
~
Namaste - I bow to the divine in you
~
Filip Hanik
Software Architect
[EMAIL PROTECTED]
www.filip.net
>-----Original Message-----
>From: A mailing list for Enterprise JavaBeans development
>[mailto:[EMAIL PROTECTED]]On Behalf Of Wei Jiang
>Sent: Thursday, June 21, 2001 8:24 AM
>To: [EMAIL PROTECTED]
>Subject: Logging in J2EE/EJB world
>
>
>********** Logging in J2EE/EJB world ********
>
>***** Overview
>
>The needs and scenarios in a distributed computing environment are very
>different from desktop computing. Server programs must be available 24 x 7
>and you can not assume your server is monitored by human all the time. So,
>server programs need logging: log errors and log events.
>
>The development environment is different as well. When you develop a
>desktop program you use a debugger to set break points. When something is
>wrong, you can simply restart your program. Unfortunately, this is not the
>case for server programs. In the first phase of development, you can run
>both server and client on your desktop machine and fix all bugs you can
>find. In the real world the situation is much more complex when many
>clients concurrently access your server. Things get even more complicated
>when your server load balances and failovers. It is impossible to set break
>points when the server is in production. The only thing you can do is
>tracing log message.
>
>
>***** Features we need for logging
>
>Logging facilities should be dynamically configurable. Un-wanted log
>messages should be easily filtered out: they are too noisy and there is
>always a performance penalty associated with logging.
>
>Logging messages should be persistent. When they are persistent, they are
>the resource for tracing. So a source code level tracing is a natural
>companion of logging.
>
>Logging must be centralized. In a distributed environment (clustering) the
>your server can dynamically move EJBs and other components from one
>physical machine to another due to load balancing and failover. If logging
>messages stay on local machine, log messages will be all over those
>machines and it would be very difficult to analysis these messages.
>
>Logging must be chronological. When your server is concurrently accessed by
>many clients, there are time dependency issues.
>
>Logging must be easy to use. If it is too complicated, it will be error
>prone. Logging part of the program will not be tested as thoroughly as the
>main part. When something happens and you want see log messages, it is the
>worst time to find out that you have a bug in logging or you did not
>configured logging system correctly.
>
>Alert facilities must be companions of logging. If some thing happens, you
>need administrator's attention.
>
>There only one practical persistent solution: use database to store logging
>messages. There are some implementation and operation issues too. For
>example, your log database should not be a part of your transaction. If
>some thing happens, the log message should not be ROLLBACKed. Just like log
>message printed on your screen, you can not take them back. So the
>connection between log system and log database must be a dedicated one.
>
>In a clustering environment, there are many physical machines and many
>servers. Your logging attributes (configuration information) must be stored
>in a central place, for example, the log database. Logging system must
>fetch logging attributes from the log database. There is a performance
>penalty to pay. But the penalty may not be severe for you application. On
>the other hand, if your system is stable, you should be able to download
>log attributes from the log database to the local machine and use
>attributes from local machine instead. This will give you a performance
>boost.
>
>Log method call should provide caller's class name, method name, time stamp
>and other information. If you hard code this information, your program
>would be very difficult to maintain. So you need a tool to rectify these
>information before you deploy your EJBs or other components.
>
>
>***** Rejected options
>
>EJB specification prohibits file IO. So logging on files are not
>acceptable, although many server leave a back door for you. There are some
>other issues as well.
>
>Asynchronized JMS as the mechanism is not the best choice. It can not
>guarantee log messages be chronological.
>Suppose you have machine A which logs message "first". Later machine B logs
>message "second". JMS guarantees delivery, but does not guarantee timing.
>You may see the message "second" before "first".
>
>You can get around of this problem by fetching a unique id from a central
>place each time a log method is called. But the extra remote access would
>be expensive. Another work-a-round is use time stamp as log id in a
>synchronized time network system. But the resolution of time stamp may not
>be good enough (usually at millisecond level) and may not be unique if you
>have many physical machines.
>
>You will get more performance overhead by using JMS than direct database
>access. On the surface, you call JMS based log method and it returns
>immediately, so your main program goes faster. But the part of JMS on your
>local machine will compete computing resources (both memory and CPU) with
>your main program.
>
>
>***** SuperLogging is designed to resolve above issues
>
>SuperLogging of Super is designed to resolve above issues. You can get it
>from http://www.acelet.com. It is free for users of open source server. It
>is free for development. The features:
>
> * SuperLogging is platform neutral and vendor neutral.
> * An open source wrapper is provided, if you want switch to other
> logging software, you do not need to modify your source code. You only
> need to modify this wrapper which is just a router, only a few lines.
> * Log threshold: filter out low level logging requests.
> * Class registration: filter out not-registered classes.
> * Log mode: Verbose, Quiet and Conditional.
> * Scope:
> Global Dynamic: get log attributes from the central place each time.
> Global Static: download log attributes to local machine.
> Singleton: working within one JVM: does not need the central place.
> * Trace: source code level trace: when you click on a line of message,
> the source code shows up and the line in question will be marked.
> * It is a fail-stop facility. If the log database is down, an alert
> message will be sent and logging will be quiet and your EJBs can still
> run as usual.
> * Redress: a tool to rectify some log information.
>
>
>********** Comments welcome **********
>
>
>__________________________________________________
>Do You Yahoo!?
>Get personalized email addresses from Yahoo! Mail
>http://personal.mail.yahoo.com/
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
