Hi Jason,
I think you have made a pretty convincing case. I usually avoid actively marketing
log4j because it is mostly a futile effort. The choice of a logging API is not
necessarily a rational process. Either people fall in love with log4j at first sight
or they don't, in which case they come up with one excuse or another.
I can perhaps reiterate my argument that if in the future you want to dump log4j in
favor of JSR47 you can do so quite quickly. The basic pattern in the JSR47 and log4j
APIs is the same:
X log = X.getInstance("some.name");
.
.
.
log.debug("hello");
log.info("world.");
where X is called "Category" in log4j and "Logger" in JSR47. The search-and-replace
pattern follows.
The question is not if you can but if you want to [replace log4j with JSR47]. Regards,
Ceki
ps: We are looking for a log4j-evangelist. You start with a salary of $0.0 but get a
30% raise every year. It's all tax-free and deductible too!
At 12:46 09.06.2001 -0400, Jason van Zyl wrote:
>Hi,
>
>One of the final issues I am dealing with in separating
>out the services is logging.
>
>I posted some questions to the list that Ceki has answered
>and after doing some thinking I would like to propose
>the sole use of log4j in Turbine for logging.
>
>Right now as I see it there is no point in creating our
>own API for logging. Log4j is far more comprehensive than
>anything we could come up with and I think log4j is flexible
>enough to deal with almost any situation.
>
>I think in the very near future the two options for application
>logging will be log4j and the JSR 047 logging API. I see
>no point in creating a mini API for logging when we have
>log4j. I think this will buy us the experience of the log4j
>community and will give us all the fabulous features in
>log4j.
>
>As Ceki (lead on log4j) has noted, log4j and the JSR 047
>logging API are very similar and he states that it would
>not be hard to move from one to other if so desired.
>
>And I don't believe there is any lack of flexibility
>if we use log4j. If developers already have logging
>systems that they have invested in than it is just
>as easy to make a log4j appender as it is to make
>an adapter that implements any interface we come up
>with.
>
>I think the logging system that we have is a bit convoluted
>and could use an overhaul. I know from experience that trying
>to add database logging wasn't exactly simple. It would have
>been a lot easier if I could have simply made an log4j
>appender. Using log4j in a conventional way would also
>buy us class level logging which would be very useful
>for testing and debugging.
>
>I don't think there is really any downside in using log4j.
>It is certainly flexible enough and we can totally off load
>the job of logging to log4j where it belongs and remove
>logging code from Turbine completely which I think would
>greatly simply things.
>
>I am getting to point where trying to separate our
>various bits of functionality into components is
>a real PITA when it comes to logging. I think log4j
>would provide a clean consistent method for logging.
>The only other real competitor is the logging JSR
>which isn't complete, will require 1.4, and isn't
>as feature rich as log4j. And I really do think
>rolling our own logging system is a waste of time.
>
>Ceki, do you have any comments? Do you see any
>disadvantages in using log4j in a system like
>Turbine? After reading everything I could get my
>hands for the last couple of days I'm sold on
>log4j. Do you have any experiences that you
>might be able to share to try and help me convince
>the rest of the Turbine developers?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
