You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@turbine.apache.org by Jason van Zyl <jv...@apache.org> on 2001/06/09 18:46:45 UTC
Turbine Logging and Log4j
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?
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Turbine Logging and Log4j
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> > From what I gathered of the Turbine 2.1 logging system, the main point
> > of it was not to provide implementations but to provide interfaces
> > behind which to hide pluggable implementations. I'm not very familiar
> > with Log4J--does it offer this "natively"?
>
> Yes, all you have to do is create an appender. There are many
> appenders that come with log4j, and they will probably handle
> 99% of what anyone would want to do. But if you have your own
> system you can simply make an appender that uses your own
> system within. I've made a few simple appenders and it's
> pretty easy.
Great, I'm looking forward to the revamp.
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Turbine Logging and Log4j
Posted by Jason van Zyl <jv...@apache.org>.
On 6/11/01 4:56 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@apache.org> writes:
>
>> I think it is necessary, and beneficial. We gain nothing by rolling
>> our own but we have a lot to gain by using log4j directly. The greatest
>> being the resources in the log4j community. I think the logging will
>> be simplified yet be very powerful. And by using log4j directly
>> I believe that Ceki will be very keen to help us and there's no
>> better resource than Ceki when it comes to logging.
>>
>> But also I believe the change will make the logging system
>> a great deal easier to manage. Most of the code will completely
>> disappear and be relegated to log4j. Creating simple appenders
>> for logging will also give a lot more flexibility. As I stated
>> before, trying to add database logging wasn't that easy.
>>
>> I am finishing off some services refactoring and then I will
>> try out log4j :-) I will post summaries of the changes before
>> I start checking in tonight as they are extensive (yet backward compatible
>> :-)) and it will probably take me 3-4 hours to check everything in.
>
>> From what I gathered of the Turbine 2.1 logging system, the main point
> of it was not to provide implementations but to provide interfaces
> behind which to hide pluggable implementations. I'm not very familiar
> with Log4J--does it offer this "natively"?
Yes, all you have to do is create an appender. There are many
appenders that come with log4j, and they will probably handle
99% of what anyone would want to do. But if you have your own
system you can simply make an appender that uses your own
system within. I've made a few simple appenders and it's
pretty easy.
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Turbine Logging and Log4j
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> I think it is necessary, and beneficial. We gain nothing by rolling
> our own but we have a lot to gain by using log4j directly. The greatest
> being the resources in the log4j community. I think the logging will
> be simplified yet be very powerful. And by using log4j directly
> I believe that Ceki will be very keen to help us and there's no
> better resource than Ceki when it comes to logging.
>
> But also I believe the change will make the logging system
> a great deal easier to manage. Most of the code will completely
> disappear and be relegated to log4j. Creating simple appenders
> for logging will also give a lot more flexibility. As I stated
> before, trying to add database logging wasn't that easy.
>
> I am finishing off some services refactoring and then I will
> try out log4j :-) I will post summaries of the changes before
> I start checking in tonight as they are extensive (yet backward compatible
> :-)) and it will probably take me 3-4 hours to check everything in.
>From what I gathered of the Turbine 2.1 logging system, the main point
of it was not to provide implementations but to provide interfaces
behind which to hide pluggable implementations. I'm not very familiar
with Log4J--does it offer this "natively"?
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Turbine Logging and Log4j
Posted by Jason van Zyl <jv...@apache.org>.
On 6/11/01 12:54 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@apache.org> writes:
>
>> 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.
>
> I know that Jon and the e-point folks spent a lot of time on the
> Logging service, but I'm am always in favor of simplification and
> narrow APIs. Jason, if you really think this is a necessary change,
> you have my +1.
I think it is necessary, and beneficial. We gain nothing by rolling
our own but we have a lot to gain by using log4j directly. The greatest
being the resources in the log4j community. I think the logging will
be simplified yet be very powerful. And by using log4j directly
I believe that Ceki will be very keen to help us and there's no
better resource than Ceki when it comes to logging.
But also I believe the change will make the logging system
a great deal easier to manage. Most of the code will completely
disappear and be relegated to log4j. Creating simple appenders
for logging will also give a lot more flexibility. As I stated
before, trying to add database logging wasn't that easy.
I am finishing off some services refactoring and then I will
try out log4j :-) I will post summaries of the changes before
I start checking in tonight as they are extensive (yet backward compatible
:-)) and it will probably take me 3-4 hours to check everything in.
> Daniel
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Turbine Logging and Log4j
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> 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.
I know that Jon and the e-point folks spent a lot of time on the
Logging service, but I'm am always in favor of simplification and
narrow APIs. Jason, if you really think this is a necessary change,
you have my +1.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Turbine Logging and Log4j
Posted by Ceki Gülcü <cg...@qos.ch>.
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: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org