Complex EJB applications support many clients, run in clustered environments, and contain a multitude of transactions; these can chip away at the usefulness of typical homegrown loggers. The Logging chapter, from the EJB Cookbook, focuses on using Log4j, a fast and extensible open source logging framework that can provide solutions to EJB logging problems.

Download and Review Chapter 8 on EJB Logging

Now JDK 1.4 has been around for a bit, I wonder how many people are using the logging API in the JDK itself, compared to external libraries like log4j, jakarta-commons logging, etc.

Any thoughts?

Following got posted in forum.java.sun.com a week back. Just posting it here, because this was the first ever "harsh" feedback I saw on JDk 1.4 logging. Look at http://forum.java.sun.com/thread.jsp?forum=4&thread=348977 for more details.

<quote>
Are you guys insane? Have you seen the jdk1.4 logging implementation? I have seldom seen such bad code!

By the way, does anyone know who wrote it? Apparently Graham Hamilton was in charge of the API specs, but who wrote the implementation? Its javadocs don't contain @author tags, which is understandable considering how bad it is.

Well, the API specs aren't that good either. 3(!) predefined debug levels. C'mon! You seldom need more than one, never more than two, and if you do you could define your own inbetween (although the implementation makes that unforgivably hard) And the names "fine, finer, finest"... you have got to be kidding me! And why not make a destinction between recoverable errors and fatal errors? Stupid, stupid. And don't get me started on the configuration file where handler configuration is on a per class basis... it's so Ugly™ that your mind goes numb just by looking at it.

For the last couple of days I've been trying to extend and replace parts of the implementation to make it usable (even through the jakarta commons logging wrapper system), but it's nearly impossible when so many static methods (which thus cannot be overridden) are used and when almost all attributes and methods of all classes are private (and thus cannot be overridden nor even used by a subclass).

- Marcus Sundman
</quote>

You listed commons-logging but its really different from all the rest and personally I think every application should be built using it.

Commons-logging is really an interface to logging systems and allows you at deploy time to plug in either log4j, jdk14 or logkit as the underlying logging system without changing your code.

Its really like vendor independent logging...

I love it -- though I actually use log4j under the hood so to speak.
Rob

I completely agree.

Commons logging is really what JDK1.4 logging should have been (ie pluggable API + implementation).

I would much prefer use something that is natively available in the JDK (less hassle) - but java.utils.logging lacks the wealth of appenders and viewers that exist for log4j - so its log4j for us.

-Nick

Some required reading on Log4J, JDK 1.4 logging, and wrappers like Commons Logging:

JSR47 vs. log4j

Think again

How does the Java logging API stack up against log4j?

IMHO a very important issue is flexible configuration in a container environment, i.e. a server and multiple applications running on it. Log4j is very flexible in this respect: You can choose the level of shared configuration by placing log4j.jar(s) accordingly, if you follow the basic classloader guidelines.

Even in a web container that uses Log4j itself, like Tomcat 4.1, it is not hard to configure Log4j for web applications. The classloader hierarchy in the Servlet spec (SRV.9.7.2) suggests to load a web application's JAR files in preference to container libraries, hence a web application can have its own log4j.jar and config file without hassle. Even with normal classloader hierarchy, you can put the container's log4j.jar and configuration in its internal library directory, like server/lib resp. server/classes in Tomcat 4, and achieve the same.

Quite on the contrary, J2SE 1.4 logging has the major hindrance that it only allows one central configuration per VM, including one single configuration file. IMHO this is not acceptable for server environments, as I want to be able to configure container logging at the container
level, and web app logging at the web app level. J2SE 1.4 logging only allows redirection by package names, not by classloader. So it's not only about central configuration: Just think about the same library deployed in various web apps on the same server: Normally, I want the various library instances to log into the log file of the respective web app, not all in a central file. As far as I understand it, this is not possible with java.util.logging.

All things considered, I consider J2SE 1.4 logging just a basic framework with sparse features, especially compared to Log4J's richness - and, as elaborated above, with awkward configuration. It may be enough for basic logging needs of standalone applications, but definitely not for demanding server environments. Is there actually anyone using it in the latter, assumably with custom handler and formatter implementations?

Personally, I'm not a fan of logging wrappers like Jakarta Commons Logging either. What's the added value compared to direct Log4J usage? Being able to switch the logging implementation at startup time is nice but overrated, IMHO. For most applications, the ability to migrate the code without much effort is more important, and that's not hard from J2SE 1.4 logging to Log4J and vice versa.

Commons Logging may make sense for small reusable components like the other Commons libraries. But as far as I see, almost all applications that choose Commons Logging use Log4J underneath anyway. Why do they restrict themselves to this API subset? Furthermore, there are numerous reports on configuration hassles with Commons Logging in container environments. Hence, I simply do not consider it worth the hassle.

Juergen

Well an argument for everyone using commons-logging is that for example I make use of several third party products, some using log4j, some use logkit, some have there home grown logging systems(both small and large vendors) and I have no choice but to use all these and get stuck with whatever limitatiosn a particular implementation has and have several different log files and configurations whereas I would like to be able to run them all into log4j.

If they all used commons-logging I could do that easyly

It would be nice to say everyone should use only log4j but its not realistic as people have differnet "favourites" the main point about commons is its somewhat agnostic and lets you have more control.
as for prb with common-logging I havent found any prb myself it was the easiest thing to set up I have ever encountered, just drop in the jars and it was working

As I said, I can see the value of Commons Logging when used in reusable base components that want to write into a log. You as the application developer that integrates them into a custom application can then choose Log4J or whatever you like, no matter what the component developer prefered.

But concerning your own application, what's the value of using Commons Logging there? If you prefer Log4J anyway, you will probably never run your application on a different logging toolkit. So why not use Log4J directly, including functionality not offered by the wrapper?

Finally, aren't most people using Log4J? Jakarta may have both Log4J and LogKit fans among their developers and thus benefit from a logging wrapper in their common components. But most other open source projects that I know of choose Log4J, or Commons Logging including a Log4J distribution.

Juergen

Well taking the packages I uses most.
1) IBATIS - home grown logging
2) Velocity - logkit
3) Oracle XSQL - new beta version switched from home grown to JDK logging
4) Oracle JCache - home grown

So errm No!

-- from my perspective -- and this is the point I was trying to make there are many different logging implementations I am sure that each felt at the time theirs was the best solution, -- everyone goes on about database independence being important and not wanting to know about the details of database persistance -- well for me thats x100 for logging -- I dont care about the nuts and bolts I want to call a standard API and I dont care about the underlying implementation, if someone comes out with something in 6 months from now thats makes log4j look old I want to be able to just drop it in.
I just want to say "log this" and its done. I want to see when I am debugging my app that I can open the log and see XSQL calling my object which then calls the cache system which finds the object and returns it instead of as now having 3 log files and trying to tie up which statement are linked together.

Rob

> Well taking the packages I uses most.

Very statistically relevant...

> 1) IBATIS - home grown logging
> 2) Velocity - logkit
> 3) Oracle XSQL - new beta version switched from home grown to JDK logging
> 4) Oracle JCache - home grown

These niche packeges don't represent "most people" (that would be the countless servlets, EJBs, JSPs of custom J2EE apps), nor most popular software (that would be application servers and development tools).

> So errm No!

Well, if those all love their respective logging toolkits, they will probably not switch to Commons Logging. You assume that the only distinctive aspect of a logging is its implementation. I assume that many people love to use their toolkit's API - not some simplifying wrapper around it. If those people were forced to use a wrapper, then the choice of toolkit underneath it would not be so important to them.

I'm simply not what wrapper's added value is, compared to standardizing on a single logging solution. The latter may be an illusion (although Log4J is very common, despite all counter examples). But a wrapper's promise only holds true if a single wrapper solution gets used very pervasively, and that seems like an illusion, too.

---

Wouldn't it, accordingly, make sense to build such a wrapper around all persistence toolkits, a kind of "Commons Persistence" - wrapping JDO, Hibernate, TopLink, CocoBase etc, maybe even EJB CMP? IMHO it doesn't at all, as each toolkit has its own distinctive advantages, in the implementation but especially in the API. Or should there be a Commons RPC - wrapping RMI, JAX-RPC, AltRMI, Hessian, Burlap etc. Or a Commons Web MVC - wrapping Struts, WebWork, Maverick etc. Or shouldn't these all be JSRs, i.e. standard APIs? Of course, this seems close to satire - but then on the other hand, it's not. Using multiple layers of abstraction is not a general necessity for every aspect of an object-oriented system. Abstraction should be chosen carefully, case by case.

I don't mind choosing Log4J, Hibernate, whatever today - and switch to something different tomorrow, in the course of a new major release of my custom application, needing to change my code. Why is everybody so obsessed with code-level compatibility of every library? Your code will evolve anyway, and so will your base libraries. If you decide to switch to a new major version of a library, or an entirely different one for the same aspect, then you will not do that casually. IMHO having to adapt the application code on a reasonable scale is perfectly acceptable, if the changes are clear and make sense.

Else, you are stuck with the dictatorship of backward compatibility - a very good tradeoff when dealing with J2SE and J2EE themselves, but a not so good one elsewhere. 2 examples: The Struts team chose to stay backward compatible to a very high degree, and it shows - look at all those deprecations from 0.5 to 1.0 to 1.1, the current JavaDoc is quite a mess, and they are still dragging along some old design flaws. On the other hand, the Hibernate team chose to do a major overhaul for 2.0, trying to avoid arbitrary changes but applying numerous important refactorings that break 1.x compatibility.

---

Note that I don't want to dismiss wrappers like Commons Logging as a whole. Again, it does make sense for reusable base components with logging needs (caveat: the need for pervasiveness). It's not so clear for application servers and higher level application frameworks, why shoulnd't they have their own log configuration and log files? And IMHO it hardly adds any value for custom applications. You simply ain't gonna need it.

Juergen

We are using log4j. It meets our requirements and its very easy to configure and use. We are using JDK 1.3 (Weblogic 7.0), so using JDK 1.4 logging was not even an option for this project. If we were using JDK1.4, I still think that we would still use log4j as it seems to be more broken in and reliable solution at this point.

I did not find any discussion about thread safety issue there. It should be an important issue. Both Log4J and JDK logging are designed for one JVM only. They leave a back door widely open for un-synchronized control of the system.

See Are Jdk Logging Or Log4J Ready For J2ee?

Asynchronous JMS as the mechanism can not guarantee log messages be chronological. See
Rejected options

See Logging with whereabouts using open source and freeware

Please See SuperLogging. It allow you do source code tracing, dynamic reconfigure in clustering environment.

Perfecting J2EE!

<quote>
Asynchronous JMS as the mechanism can not guarantee log messages be chronological. See
Rejected options
</quote>

It is nice to promote Acelet but this is not really true. You have JMS implementations that ensure ordered delivery of messages using vectorial clocks.

Emmanuel

<Emmanuel>
You have JMS implementations that ensure ordered delivery of messages using vectorial clocks.
</Emmanuel>

Can you elaborate more please? I googled "vectorial clock", but did not find anything.

Support you have machine A and B. The network clock is synchronized. But, the tolerate of error for network clock
is 10 milliseconds, at best. If both send logging request "about the same time", which one be recorded first?

Suppose the JMS server which is used by machine A is down at the time machine A logs. The logging message will be delivered when the JMS is up and running again. But, the log message will be recorded at the time JMS is available, not the log request time. Meanwhile machine B continuously logs. How can it be chronological?

Of course, you can always fetch a clock or get an unique id from a central place. But that requires an extra remote access with performance penalty.

Usually, applications are very well tested in limited environment. When they are on production, there are still problems from time to time. Most likely when many application requests happen AT THE SAME TIME. So, the ability to distinguish the order at "the same time" is important.

why is ordered delivery a problem with jms?
having the date and time when the LoggingEvent was generated i could just sort the log by this field

<quote>
why is ordered delivery a problem with jms?
having the date and time when the LoggingEvent was generated i could just sort the log by this field
</quote>

The timestamp you got from JVM is not unique. The resolution
of your clock is 10 milliseconds. To make things worse, the
tolerance of error of network clock synchronization is
another 10 milliseconds, at best. The following program
may suprise you:

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]); }

Perfecting J2EE!

Where does SuperLogger log to in order to "solve" this problem? The database?

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

yes.

Perfecting J2EE!

Wei Jiang,

There are three big problems with logging to the database:

1) The database can go down, and where would the log go? A lot of the logging occurs when there are problems with the database, for example.

2) The database has a high latency, so even with one application server, it would be very slow for most logging purposes. I've seen production apps that log more than a million items (per server JVM) in one business day; with a good database system, it would take a couple of hours out of the day just for writing logs.

3) The database scales poorly (after a point, its performance degrades rapidly) as application servers are added to the cluster. Usually, architects are trying to figure out how to do _less_ with the database, not use it for something like logging. With a 20 or 30 node cluster writing logs to a shared database, you'd need an e12k just to process the logging.

On the other hand, once the data is in the database, it could be relatively easy to manage / search through / monitor / etc. I just think it's good to be clear what the technical (and cost) downsides are.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

Hi Cameron,

1. Data source.
You need a "data source" to store log messages. If you do not use database,
what do you use? The only alternative is file.

Files are machine dependent
and will not work in clustering environment. If you do write separated logging
file on each machine, how can you merge these files together in a chronological
way, so you can read them?

You can have a central machine to collect log messages from all machines and write
to a file. Then the question is: that is the difference between this solution and
a database? Actually you are implementing your own "home grow database".

The reason to log is to read it when needed. If you just want write fast and do not
care reading, you do not need logging. Database is easier to read and maintain than file or
"home grow database".

2. Dedicated log database.

Logging is expensive. This is reality, just like security.
If you have a lot of log messages, a separated log database would be a better solution.
If you have a million log messages per server JVM per day,
you probably need a dedicated log machine.

3. Performance.

Regular relational databases are slow. One important reason is the transaction.
But logging does not need transaction. Log message should never roll-back. So, you can
use mysql (classic version, no transaction). That would be faster than Oracle, probably 10
times.

Log database access is much simple than regular SQL statements. Dedicated log database
 is less likely to have problem and less likely to have performance degrades.

If you have millions of log messages, you can use object database (not relational). That would be
very fast: close to direct file access level. We would be more than happy to do that for you.
We are also working on other options to improve database performance.

Perfecting J2EE!

Very interesting in the object database you mentioned here. Can you please list some of them (free)? and do they have a good JDBC driver?

Thanks.

If you're worried about managing the volume of log information your J2EE or other app generates, I agree you need a better solution than a traditional RDBMS to store all that information. Using Oracle, the cost for storing your log data might outstrip your development and deployment costs for the original application!

I've heard of Addamark and their Log Management System (LMS) (look at http://www.addamark.com). They claim to centralize log storage in a generated in a distributed environment, compressing the original log files to consume as little as 2% of the original. The log data is parsed and stored into a SQL table that looks like much like a traditional DB (without all the transactional, etc. overhead of a traditional DB). You query tables using SQL, extensible with embedded Perl. You deploy their product on a cluster of commodity PCs, and they claim their architecture stores and queries information at 10x a traditional RDBMS for much less cost.

They have a good customer list, including Yahoo, Nielsen (NetRatings), Terra/Lycos, Agilent, and I hear rumors they're making a big splash in the security space for banks and other financial institutions.

The timestamp you got from JVM is not unique. The resolution of your clock is 10 milliseconds. To make things worse, the tolerance of error of network clock synchronization is another 10 milliseconds, at best.

And -- what has that to do with JMS? Who states that queuing in JMS is based on timestamps? It is based on the sequence of arrival. Or do you think that JMS impls use System.currentTimeMillis() only to order messages in queues? Wrong!

Btw, to be taken seriously, you should at least add your company address to your 'super' web site, otherwise someone might think your're a schoolboy.

-- Andreas

Andreas,

That was a response to an earlier posting which mentioned to use a kind of timestamp to identify each log message.

JMS specification says that the order of JMS messaging is not defined. JMS guarantees delivery, but not timing.

BTW, thanks for your suggestion.

Perfecting J2EE!

JMS specification says that the order of JMS messaging is not defined.

You might check JMS spec 1.1, section 4.4.10. You can expect to receive messages in order, within the same priority, with the same persistence mode, sent from the same session to the same destination. So if you send your log messages through a single session to a queue, you receive them in the order they were sent.

Order is undefined if you use multiple sessions to send the messages to the same destination.

-- Andreas

<quote>
Order is undefined if you use multiple sessions to send the messages to the same destination


Thank you.

The discussion here is in J2EE world which is a distributed computing environment with multiple servers, multiple sessions, load balancing
and fail-over.

Perfecting J2EE!

Andreas knows something about J2EE. He only wrote the most popular JMS implementation in the universe (SwiftMQ).

Imagine 10 app server... each one have 100 thread running...thread 1 on app server 1 is inserting 'AS1-T1', thread 2 'AS2-T2', etc etc
can you ensure that the table is in the right order ('AS1-T1','AS2-T1'...) ?(without locking or rollback)

Do we realy need chronological logging ?

regards
Adam AC

Yes. SuperLogging guarantees the chronological order: the order of happening regardless how many servers, sessions running at the same time with load-balacing and fail-over.

Is chronological logging needed? Depends on your application. My web server logs some information for me, so I know how many people visited my site. Is the order important? No. Is the accuracy important? No.

If your logging is for serious information, the chronological order is important.

You need to know what happens in your j2ee application. Suppose a hacker
hacked in. The order of his/her activity is important for you. If you have
an accurate log, it will help you to patch your security hole.

As I discussed in this thread earlier: Usually, applications are very well tested in limited environment. When they are on production, there are still problems from time to time. Most likely when many application requests happen AT THE SAME TIME. So, the ability to distinguish the order at "the same time" is important.

Perfecting J2EE!

The discussion here is in J2EE world which is a distributed computing environment with multiple servers, multiple sessions, load balancing and fail-over.

I followed the thread. I only wanted to correct some mistakes in your statements concerning JMS ordering.

However, actually I don't understand what your problem is. If you log from different sources over different JMS sessions (different servers), the messages will certainly arrive at your receiver (your database) in the sequence of arrival (thus, undefined). If this is a problem, how do you solve it with your SuperLogging? Sequenzing it by yourself?

I checked the javadocs of your log classes and I missed a simple but important flag: enabled. Where is it? I mean, to log in this manner

logger.log(<bunch of String concats>);

isn't that optimal. Better is

if (logger.enabled)
  logger.log(<bunch of String concats>);

Of course, toggling enabled/disabled dynamically would be nice.

There's another German product called qflog which seems to be similar to your SuperLogger, however, with a much nicer documentation.

-- Andreas

<quote>
However, actually I don't understand what your problem is. If you log from different sources over different JMS sessions (different servers), the messages will certainly arrive at your receiver (your database) in the sequence of arrival (thus, undefined). If this is a problem, how do you solve it with your SuperLogging? Sequenzing it by yourself?


Chronological order is important for serious application, see my earlier discussion in this thread.
We solve this problem by using non-asynchronous mechanism.

<quote>
I checked the javadocs of your log classes and I missed a simple but important flag: enabled. Where is it? I mean, to log in this manner


You mean switch the log system on and off? You can dynamically set the mode to be Quiet, Conditional or Verbose. You can register a class or set log level for fine configuration as well.

I browsed the doc you mentioned. It is quite different from SuperLogging. For example, I did not find any discussion about thread safety issue: Can all server instances in clustering dynamically use the same configuration?

Perfecting J2EE!

No, I meant this:

if (logger.enabled)
  logger.log(<bunch of String concats>);

I browsed the doc you mentioned. It is quite different from SuperLogging. For example, I did not find any discussion about thread safety issue: Can all server instances in clustering dynamically use the same configuration?

You might ask the author of that package.

-- Andreas

<quote>
if (logger.enabled)
  logger.log(<bunch of String concats>);


You mean enable an application class? Yes. You register/unregister a class
dynamically using a Swing tool of SuperLogging.

Perfecting J2EE!

> if (logger.enabled)
>   logger.log(<bunch of String concats>);
>
>
> You mean enable an application class? Yes. You register/unregister a class
> dynamically using a Swing tool of SuperLogging.

No. ;-)

I simply mean to avoid the <bunch of String concats> in my app if logging is disabled. I haven't found it in your javadocs.

If you don't have it, add it, it's important since it degrades performance alot and creates huge of garbadge.

See you,
Andreas

int <b>Tracking the lifecycle of an EJB</b>
They use the <b>RollingFileAppender</b> according to the latest error reports from apache there are people running into issues using that class with NT. the link

look like there is some issues with the timing of the logging and where the logging is put. Could have several days worth of logging in a file that is suppost to only have one days worth of content. may be worth checkign out if you intend to use that functionality

I have a real problem with people providing code that doesnt compile in a cut and paste. I.E. the LoggerInitializationServlet I had to do some not so serious fixes to get this to work. I know it is for informational purposes but still does cheese me off.

Does the servlet initialization solution depend on the classloading strategy that an app server uses? Since PropertyConfigurator.configure is a static method, I figure that the solution will not work if the EJB and web app are in sibling classloaders. Each of these siblings would have their own PropertyConfigurator class instance. So changing the initialization file for Log4j in the web app, won't change anything in the Log4j system in the Ejb app???????

Does the servlet initialization solution depend on the classloading strategy that an app server uses?

I think so. I have had real grief trying to do the right thing with my app server (silverstream/novell extend). Deploying apps as an ear allows me to use a servlet to do the initalisation but takes a crazy length of time. Deploying stuff as EJB jars and WARs makes more sense, is a bit more reasonable in terms of time but makes log4j initalisation really akward. Its just so easy in jboss....

Quentin

Still, with the sugested solution you have a single point of failure for the logging mechanism in the cluster.
There are serveral techniques to create active-passive logger deployment to overcome this problem, but sure it will not be as simple as described in the chapter.

Ronen Lewit
CEO, IT Specialist
Risotech LTD

getServletContext() doesnt work in an ear file.

I thought that the EJB spec prohibits the use of java.io within a bean (see http://www.jguru.com/faq/printableview.jsp?EID=8993 for details). Doesn't this put a hamper on standard file and XML logging (although JDBC and JMS logging are still options)?

I also agree that any discussion about logging these days should include information on the Jakarta-Commons-Logging API.

Yes. File io is prohibited by EJB spec.

Currently, many J2EE servers turn blind eyes to this issue allowing you to do file io. This issue and other issues I discussed earier in this topic are time bombs which are ignored by some developers for now.

Perfecting J2EE!

I thought that the EJB spec prohibits the use of java.io within a bean

But half the APIs you will use from a bean will do file I/O.

For example, if you use java.util.Date, it can do file I/O. (At a client, we saw all the threads blocked on a read from disk ... the stack trace showed the culprit: java.util.Date, which BTW was being called from an EJB.)

In fact, IIRC, java.lang.String single-handedly violates around half of the rules for what EJBs are not permitted to do.

Doesn't this put a hamper on standard file and XML logging ... ?

No, not really. Just make sure you are using a well-tested logging implementation that encapsulates all of that functionality, and don't do any I/O directly from your EJBs.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Easily share live data across a cluster!

This is a version of my reply over at jguru EID 8893.

If certain parts of the EJB spec can be broken, then why do the EJB authors use the words "must not" instead of "should not". This sounds a little like Bill Clinton, define "is". Maybe the authors should have referenced RFC 2119. In there it states:

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.

Should we could debate the term absolute.

I'm sure there is not any read/write static variable in, oh let's say, Logging.java ;)
(An enterprise Bean must not use read/write static fields...)

How about any synchronized methods in FileAppender.java? Nahhh
(An enterprise Bean must not use thread synchronization primitives to synchronize execution of multiple instances.)

This is less of a criticism of log4j than it is of the authors of the EJB Specification. Maybe as part of the J2EE Container certification process, Sun should check to see if the container enforces programming restrictions.

But what does it apply to? The EJB or the JDBC driver that the EJB uses?

> (An enterprise Bean must not use read/write static fields...)

Ahh, good point. Then an EJB "MUST NOT" log at all. My opinion is anyway that logging / tracing should be provided from the container in some proprietary way, e.g. by intercepting the calls.

-- Andreas

I think that the best solution is to extend the toolkit used (eg log4j) encapsulating that one of the vendor (es. WebSphere). WebLogic already supplies a log4j-appender. It would be beautiful if there were a log4j-appender that wrap WebSphere-JRAS logging system.

An other possibility could be to create a logger based on JCA instead on JMS (JCA has little prohibitions, so you can log to a file)

Ciao, Diego

If you are considering using commons-logging, you might read a document authored by the primary on log4j that seriously questions the advisability of this approach (http://www.qos.ch/logging/thinkAgain.html).

Several years ago, in the days of JDK 1.1 there was no standard collections API. As a result, many projects had settled on a de facto standard of using the JGL Collection framework that was freely available. At the time, many folks complained about the JDK API being too simple and lacking many of the features of the JGL library (e.g. filters, algorithms, etc.).

Here we are years later, and JGL has gone the way of the dinosaur (people may have heard about it, but not many have actually used it).

The same thing now appears to be happening with the JDK logging API versus Log4J.

The JDK API is not as feature rich as Log4J from both an API and implementation perspective. However, once JDK 1.4 becomes the de facto JDK, odds are that you are going start seeing everything start using it and abandoning Log4J (well, my guess is that the Log4J team will port most of their implementations to comply with the JDK API).

>> However, once JDK 1.4 becomes the de facto JDK, odds are that you are going start seeing everything start using it and abandoning Log4J.

I realize this is a 10 year old thread. But I came across (yes, while vanity googling) and felt compelled to respond. I'm pleased as punch, 10 years and several JDK releases later, to report that log4j is still widely used in preference to the JDK logging API. A number of sites I've contracted at are now using slf4j as the facade (similar to commons logging) but still use log4j as the underlying logger engine, not java.util.logging. The expected "ecosystem" of extension classes to fill the gap between log4j and JDK implementations have not, AFAICT, manifested.

Regards to Ceki and everyone involved with log4j for creating something of such incredible usefulness and lasting value.

 

Jim Cakalic

We use Websphere Application Server 4.x

We decided to use Log4j 1.2.8 and Commons Logging 1.0.3

We configure Log4j using an XML config file: log4j.xml

Hi There,

I can't seem to find the download for the article "Logging Your J2EE Application with the Log4j Logging Framework". Everytime I clicked on the link I would get a "requested file not found...".

I'd love to read the article if that's still available for public review.

Thanks,

Mike