Does Log4J do:
1. Dynamicall re-configure logging attributes in a clustering environment?
2. Source code level tracing?
3. Alert?
JDK 1.4 comes with a logging API, which is similar to Log4J. It will
be the standard. It addresses logging in one JVM. It is j2Se, not
j2Ee. It mentions somewhere that a hook up will be defined for j2Ee later,
but no time frame provided. When the specification is defined, there
will be a need for server vendor neutral implementation for j2Ee.
SuperLogging is an implementation and will be specification compliant
when it is available. SuperLogging is a full featured logging system.
You can redirect log messages from Log4J to SuperLogging and use all
features from SuperLogging as well.
--- Filip Hanik <[EMAIL PROTECTED]> wrote:
> 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".
>
__________________________________________________
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".
