>> ********** Are JDK logging or Log4J ready for J2EE?
>>
>> See
>> http://www.acelet.com/whitepaper/AreJdkLoggingOrLog4JReadyForJ2ee.html
>> for html formated file.
>>
>> JDK 1.4 (J2SE) introduces a new package java.util.logging.
>> JDK 1.4 logging is a cousin of Log4J. Both of them are
>> excellent logging systems in single JVM. In this article, we
>> mainly discuss JDK logging. Most things, if not all, are
>> applicable for Log4J as well.
>>
>> J2EE is a distributed computing environment. There are
>> many machines working together. There is a clustering
>> environment. The implementation of containers is not defined
>> by J2EE specifications. So implementation of containers is
>> different from vendor to vendor or from version to version.
>> Even within one server instance, there may be many JVMs.
>>
>> Are JDK logging and Log4J ready for distributed computing
>> environment? Are they ready for J2EE? No.
>
>Yes. Log4J works. I'm using it. I'm using it as we speak.
How do you dynamically configure (log level, filter...) it
in a clustering environment?
>>
>> JDK leaves a back door widely open for un-synchronized
>> control of the system
>>
>> Let us use log threshold as an example to analyses the
>> dangerous un-synchronized control.
>>
>> In JDK logging, both log require and log control code are
>> within one class: java.util.logging.Logger. You use
>> java.util.logging.log( ) to require log. You use
>> java.util.logging.setLevel( ) to control log by setting log
>> threshold. That is good in one JVM. This arrangement
>> encourage programmers to control logging in application code.
>> This is a very serious problem in distributed computing
>> environment. When certain condition meets, setLevel( ) will
>> be called in one component (EJB, JSP or helper class). The
>> scope of that log threshold change is in one JVM. Other
>> components in the clustering run in different JVMs. They do
>> not know that change. All components are dynamically loaded
>> in the cluster. We do not know which copy of which component
>> runs on which JVM at a particular time. We only know that
>> from that time on, they may use different log thresholds.
>
>I refer you to the packages java.security AND java.security.acl. They've
>been part of the JDK since release 1.2, which is the worst-case scenario
>requirement for J2EE. They allow you to control which programs can
>control log threshold. That, without even mentioning that Log4J is
>open-source.
>
>>
>> If your application is developed in house, you may hire a
>> logging police to discipline your developers not to control
>> logging configuration in application code. But, if your
>> libraries and components come from other source. It is
>> impossible to do so.
>>
>> The problem is that there is no clear separation between log
>> request (logging methods) and log control (management
>> methods). The request of logging is invoked from application
>> code. But logging behavior should be managed in a separated
>> central program. This is out of J2SE design scope.
>
>It can be managed separatedly.
>
>>
>> JDK logging is an API, not a system
>>
>> The default persistent mechanism in JDK logging is file
>> saving. This is prohibited by J2EE specification. You need to
>> implement your own persistent mechanism. Although the API is
>> standard, but the whole thing will not be standardized
>> anymore. Recently Log4J published a built-in hook to use JMS
>> as a centralized persistent logging mechanize. But
>> asynchronized JMS as the mechanism is not the best choice. It
>> can not guarantee log messages be chronological.
>
>Their socket listener implementation can very much do so. They're
>timestamped at the origin point, and you may optionally restamp them at
>the central server. The logging level may also be managed at the central
>server.
>
If you try the following program:
class t {
public static void main(String[] args) throws Exception {
long[] time = new long[10000];
for (int i = 0; i < time.length; i++)
time[i] = System.currentTimeMillis();
for (int i = 0; i < time.length; i++)
System.out.println(i + ": " + time[i]);
}
}
You will find "timestamped at the origin point" is not good
enough. Do not forget that the resolution of network clock
synchronization will not be better than 10 milliseconds.
>>
>> There is no built-in mechanism to dynamically re-configure
>> the log system keeping all parties in sync. It is difficult
>> to implement too.
>
>That's true for any syncronization mechanism; it makes more sense to
>have a central log machine and to filter there.
>>
>> There is a long way to go to build a standard logging system
>> based on JDK logging.
>
>I respectfully disagree. Just minor glitches a couple of helper classes
>and reading manuals thorougly.
>
>>
>> Other issues
>>
>> There are other issues too. For example, JDK logging API is
>> not simple, there is a learning curve. When things are
>> complicated, there will be chances to introduce logging bugs
>> from application code. Performance is a concern too. But all
>> other issues are minor ones comparing to the issued we
>> discussed above.
>
>Sample code to instantiate a logger in a class:
>
> private static org.apache.log4j.Category log =
>org.apache.log4j.Category.getInstance(MYEJB.class);
>
>And use it:
>
> try {
> ...
> } catch (CreateException ce) {
> log.error("Couldn't create a MYEJBDep entity", ce);
> }
>
===========================================================================
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".
