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/07/25 17:29:37 UTC
Re: cvs commit:
jakarta-turbine/src/java/org/apache/turbine/services/security/impl/db/entit
y TurbineUser.java
On 7/25/01 1:44 AM, "dlr@apache.org" <dl...@apache.org> wrote:
> dlr 01/07/24 22:44:56
>
> Modified: src/java/org/apache/turbine/services/security/impl/db/entity
> TurbineUser.java
> Log:
> Only one call to Log.error() is necessary, and import should be up at
> the top of the file when fully qualified name is not needed to resolve
> class.
>
> Revision Changes Path
> 1.6 +3 -4
> jakarta-turbine/src/java/org/apache/turbine/services/security/impl/db/entity/T
> urbineUser.java
>
> Index: TurbineUser.java
> ===================================================================
> RCS file:
> /home/cvs/jakarta-turbine/src/java/org/apache/turbine/services/security/impl/d
> b/entity/TurbineUser.java,v
> retrieving revision 1.5
> retrieving revision 1.6
> diff -u -u -r1.5 -r1.6
> --- TurbineUser.java 2001/07/20 21:32:48 1.5
> +++ TurbineUser.java 2001/07/25 05:44:56 1.6
> @@ -61,6 +61,7 @@
> import javax.servlet.http.HttpSessionBindingEvent;
> import org.apache.turbine.services.security.TurbineSecurity;
> import org.apache.turbine.services.security.entity.User;
> +import org.apache.turbine.util.Log;
Don't couple fulcrum to turbine. There is a Log helper in the services
directory as a stop gap solution until a better logging solution is found.
I think the static Log helper is bad anyway, but it will do for now. At
any rate that's the wrong Log import:
org.apache.turbine.services.Log
> import org.apache.turbine.util.ObjectUtils;
>
> /**
> @@ -75,7 +76,7 @@
> * @author <a href="mailto:frank.kim@clearink.com">Frank Y. Kim</a>
> * @author <a href="mailto:cberry@gluecode.com">Craig D. Berry</a>
> * @author <a href="mailto:mpoeschl@marmot.at">Martin Poeschl</a>
> - * @version $Id: TurbineUser.java,v 1.5 2001/07/20 21:32:48 jon Exp $
> + * @version $Id: TurbineUser.java,v 1.6 2001/07/25 05:44:56 dlr Exp $
> */
> public class TurbineUser
> extends
> org.apache.turbine.services.security.impl.db.entity.BaseTurbineUser
> @@ -445,9 +446,7 @@
> }
> catch (Exception e)
> {
> -
> org.apache.turbine.services.Log.error("TurbineUser.valueUnbobund(): " +
> - e.getMessage());
> - org.apache.turbine.services.Log.error(e);
> + Log.error("TurbineUser.valueUnbobund(): " + e.getMessage(), e);
>
> // To prevent messages being lost in case the logging system
> // goes away before sessions get unbound on servlet container
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
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
utilites
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> I do not want to keep the wrapper, not in components that are meant
> to be embedded in other things.
As you're so strongly opposed to it, I (again) agree to not use it in
Turbine.
> > You make an excellent point about not binding the utilities to
> > Turbine's development cycle. However, a place for the utilites to
> > live should be created before their removal starts.
>
> All the utilties are still in the tree? They are just in a different
> directory indicating that they should be moved. I removed redundant
> utilties. But they are all still there, even utils that aren't used
> in Turbine itself.
I'd rather the utilities moved directly into their final location.
> >I agree that the
> > Commons is a fine place for this, and am willing to do the initial
> > switcheroo into the Commons if you will get the util package
> > established (I do not have commit and don't participate there much).
>
> Deal. We can definitely put things in the sandbox and every committer
> can get access to sandbox with a request to the list.
Great!
> The utilities can live in the adapter directory for a while, I'll
> post something to the commons this week. Maybe we can get a little
> package going where all projects can place their util code for
> perusal and possible aggregation into a single package.
That's exactly what I'm looking for. I'll post a follow-up message
indicating that I'd like to move Turbine's utilities in and requesting
commit.
I'm really dying to upgrade the version of Turbine used in Tigris, but
the duplication of source code in various JARs was making that very
painful. It looks like that's nearly sorted out, and I want to make
utility/logging class changes at the same time that I add the new
Turbine, Fulcrum, and Torque JARs. I find it harder to help out with
HEAD development when I'm not actually *using* the bleeding edge code.
:)
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Log class
Posted by Jason van Zyl <jv...@apache.org>.
On 7/31/01 4:43 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@apache.org> writes:
>
>> On 7/27/01 1:53 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>>
>>> Regardless, the static Log methods
>>> are extremely convenient.
>>
>> I think having:
>>
>> Category logger = Category.getInstance(classname) and
>> using the 'logger' reference in your code is just as easy.
>
> This is what we had before we moved from a WebMacro-based system to a
> more Turbine-based system. From that experience, let me assure that
> it's a pain compared to Turbine's super-simple Log wrapper when all
> you need to do is append to a text file.
I have been using the method above for about 8 months now in
my own projects and it has been nothing but a blessing. I definitely
don't agree with you on this. With a wrapper there is absolutely
no way to control the granularity of logging without changing
source code. It is entirely and completely inflexible.
You were using the above methods with log4j and had problems?
I have had zero problems, but have had tons of problems with
Log wrappers.
>>> I've had absolutely zero problem using the Log class outside of
>>> Turbine (in many Tigris projects).
>>
>> How were you using org.apache.turbine.util.Log outside of
>> Turbine? Using the logging service in other projects?
>
> The Log wrapper around Turbine's default logger *is* the logging
> system for Helm.
Well, we differ. I would never do that.
> i.e. We have Log.debug("some string") everywhere.
>
>>> A framework-level package like Turbine that integrates best of breed
>>> components is *exactly* where a Log wrapper belongs, *not* implemented
>>> in application code.
>>
>> That's what I meant. I called it the application level, but having
>> a Log wrapper would be all right in derived module classes
>> in Turbine, but I still think a base module that provided a reference
>> to a 'logger' does the same thing without having to maintain a wrapper.
>>
>> Log.debug(x);
>>
>> or
>>
>> logger.debug(x);
>
> Use of the second means that one must explicitly obtained a reference
> to a logger. I much prefer not having to do this.
If you don't than you are boxed into a logging mechanism that is
inflexible. As mentioned above you can achieve no granularity.
In fulcrum for example I would get a reference in every class,
this is how all logging will be done before long. Log4j and the
Sun logging API both do this. Ceki and the log4j group have probably
dealt with every logging issue that exists and I agree with their
recommendation. With components that log4j there is nothing to
stop you from making a Log wrapper for your framework or application,
helm in this case for you.
>>> This is almost no different from the 2.1 log system.
>>
>> Yes, but it was either log4j doing it, or we replicated something
>> done better in log4j.
>
> I agree with you. Replacing the existing system with straight Log4J
> is definitely the best ROI. It's the wrapper I would like to keep
> around.
I do not want to keep the wrapper, not in components that are meant
to be embedded in other things. The Log wrapper in fulcrum really
sucks. I've had to bend over backward to get the Log thing to work
so that I didn't have to replace all the Log statements. It worked
fine when everything was coupled and used Turbine for logging, but
when the separation occurred and the nastiness that ensued to get
the logging to work is indicative of misuse of the wrapper in
Fulcrum or Torque for example. Use a Log wrapper in your framework
if you want but not in a component, it's just the wrong place for
it. Look at all the traffic on the log4j list and look at the way
it's being used by literally hundreds of projects, no one uses
a Log wrapper because it's seen as bad practice.
The retrieval of a category in log4j, or logger with the Sun API, is
a small price to pay for the granularity provided, flexibility, and
ease of integration with other components. Log4j usage and the Sun API
that looks almost exactly like log4j is a good sign you're on the
right path. Any little tools I've made in the last six months I have
used the log4j/jsr27 method by grabbing a category instance in each
class and it has been totally painless using the tools in anything
and have seemless, coherent logging.
>>> I very much
>>> dislike the fact that you're eliminating a lot of the utility classes
>>> from Turbine
>>
>> Yes, I'm removing them from Turbine because I don't think they
>> belong there. They belong in the commons as that is the place
>> where we have established the resting place will be for
>> common utilities. Tying utilities that may vary should not
>> be bound to Turbine's development cycle.
>
> You make an excellent point about not binding the utilities to
> Turbine's development cycle. However, a place for the utilites to
> live should be created before their removal starts.
All the utilties are still in the tree? They are just in a different
directory indicating that they should be moved. I removed redundant
utilties. But they are all still there, even utils that aren't used
in Turbine itself.
>I agree that the
> Commons is a fine place for this, and am willing to do the initial
> switcheroo into the Commons if you will get the util package
> established (I do not have commit and don't participate there much).
Deal. We can definitely put things in the sandbox and every committer
can get access to sandbox with a request to the list.
>> There are 20 string utility classes scattered all over Jakarta, they
>> should be combined and placed in the commons. It does take a lot of
>> effort so an interim JAR is a good idea but I definitely don't
>> want to tie utilties to the core of Turbine and bundle them together.
>> Some of the utilities we house aren't even used in Turbine code, I
>> don't feel turbine should house this type of code.
>
> I would prefer to use pre-releases of a Commons Utility JAR than to
> put effort into a Turbine utility JAR, mainly to avoid having the
> classes move around again.
Yup, I agree.
>> You know how I feel about log wrappers, I think they are uncessary,
>> not beneficial and don't provide enough flexibility.
>
> Its simplicity is one of things which I like most about the Log
> wrapper.
I don't really find it that difficult using a category, and I don't
really think other developers will either. And it's too simple.
>>> Even if Turbine does not include these utilities in its own source
>>> tree, it should include a JAR which makes them available
>>> (jakarta-turbine-util for anything not easily placed into the
>>> Commons?).
>>
>> I'm fine with a separate JAR, but hopefully this stuff can go to
>> the commons.
>
> Yes.
The utilities can live in the adapter directory for a while, I'll
post something to the commons this week. Maybe we can get a little
package going where all projects can place their util code for
perusal and possible aggregation into a single package.
>
> Daniel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
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: Log class
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> On 7/27/01 1:53 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>
> > Regardless, the static Log methods
> > are extremely convenient.
>
> I think having:
>
> Category logger = Category.getInstance(classname) and
> using the 'logger' reference in your code is just as easy.
This is what we had before we moved from a WebMacro-based system to a
more Turbine-based system. From that experience, let me assure that
it's a pain compared to Turbine's super-simple Log wrapper when all
you need to do is append to a text file.
> > I've had absolutely zero problem using the Log class outside of
> > Turbine (in many Tigris projects).
>
> How were you using org.apache.turbine.util.Log outside of
> Turbine? Using the logging service in other projects?
The Log wrapper around Turbine's default logger *is* the logging
system for Helm.
i.e. We have Log.debug("some string") everywhere.
> > A framework-level package like Turbine that integrates best of breed
> > components is *exactly* where a Log wrapper belongs, *not* implemented
> > in application code.
>
> That's what I meant. I called it the application level, but having
> a Log wrapper would be all right in derived module classes
> in Turbine, but I still think a base module that provided a reference
> to a 'logger' does the same thing without having to maintain a wrapper.
>
> Log.debug(x);
>
> or
>
> logger.debug(x);
Use of the second means that one must explicitly obtained a reference
to a logger. I much prefer not having to do this.
> > This is almost no different from the 2.1 log system.
>
> Yes, but it was either log4j doing it, or we replicated something
> done better in log4j.
I agree with you. Replacing the existing system with straight Log4J
is definitely the best ROI. It's the wrapper I would like to keep
around.
> > I very much
> > dislike the fact that you're eliminating a lot of the utility classes
> > from Turbine
>
> Yes, I'm removing them from Turbine because I don't think they
> belong there. They belong in the commons as that is the place
> where we have established the resting place will be for
> common utilities. Tying utilities that may vary should not
> be bound to Turbine's development cycle.
You make an excellent point about not binding the utilities to
Turbine's development cycle. However, a place for the utilites to
live should be created before their removal starts. I agree that the
Commons is a fine place for this, and am willing to do the initial
switcheroo into the Commons if you will get the util package
established (I do not have commit and don't participate there much).
> There are 20 string utility classes scattered all over Jakarta, they
> should be combined and placed in the commons. It does take a lot of
> effort so an interim JAR is a good idea but I definitely don't
> want to tie utilties to the core of Turbine and bundle them together.
> Some of the utilities we house aren't even used in Turbine code, I
> don't feel turbine should house this type of code.
I would prefer to use pre-releases of a Commons Utility JAR than to
put effort into a Turbine utility JAR, mainly to avoid having the
classes move around again.
> You know how I feel about log wrappers, I think they are uncessary,
> not beneficial and don't provide enough flexibility.
Its simplicity is one of things which I like most about the Log
wrapper.
> > Even if Turbine does not include these utilities in its own source
> > tree, it should include a JAR which makes them available
> > (jakarta-turbine-util for anything not easily placed into the
> > Commons?).
>
> I'm fine with a separate JAR, but hopefully this stuff can go to
> the commons.
Yes.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Log class
Posted by Jason van Zyl <jv...@apache.org>.
On 7/27/01 1:53 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@apache.org> writes:
>
>> On 7/25/01 10:10 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>>
>>> Maintaining the Log wrapper class--whever it needs to live now--is
>>> very important to me. It's a brief and descriptive name, and is both
>>> much shorter to type than Category.getInstance() (or whatever it is)
>>> and much more clear as to its purpose.
>>
>> The naming can be made more clear, I don't actually have a problem
>> with category as hordes of people use log4j and know what it is.
>
> But what about those who don't?
As I said in a previous post to Fedor: log4j is small and you can easily
integrate whatever you use for logging by making an appender that
encapsulates any logging code.
> Regardless, the static Log methods
> are extremely convenient.
>
I think having:
Category logger = Category.getInstance(classname) and
using the 'logger' reference in your code is just as easy.
>> As for the Log wrapper, it's a bad idea especially in components
>> you wish to use outside the context of the initial package the
>> component was placed in. The Log wrapper is convenient in highly
>> coupled systems like Turbine 2.1, but it makes reusing the
>> any utility class or component difficult, inconvenient and
>> not possible in some cases.
>
> I've had absolutely zero problem using the Log class outside of
> Turbine (in many Tigris projects).
How were you using org.apache.turbine.util.Log outside of
Turbine? Using the logging service in other projects?
> [snipped argument against using Log wrappers]
>> I would say a Log wrapper might be minimally acceptable in an application,
>> though I still wouldn't recommend it, but definitely not in components
>> like fulcrum or torque.
>
> A framework-level package like Turbine that integrates best of breed
> components is *exactly* where a Log wrapper belongs, *not* implemented
> in application code.
That's what I meant. I called it the application level, but having
a Log wrapper would be all right in derived module classes
in Turbine, but I still think a base module that provided a reference
to a 'logger' does the same thing without having to maintain a wrapper.
Log.debug(x);
or
logger.debug(x);
>> I am all for ease of use. For example in fulcrum we could make 'log'
>> available to all the services and this is easy but you I think it is
>> still better to get the category instance in each class because you
>> can than easily create logs on a per service basis. Plus with log4j you
>> could easily send the logs for one service to syslog, and send the logs
>> for another to a file, or syslog, or an SMTP server or whatever other
>> appenders are available to log4j. The only thing you have to change
>> is the log4j properties file and I think that is most optimial solution.
>
> This is almost no different from the 2.1 log system.
Yes, but it was either log4j doing it, or we replicated something
done better in log4j.
> I very much
> dislike the fact that you're eliminating a lot of the utility classes
> from Turbine
Yes, I'm removing them from Turbine because I don't think they
belong there. They belong in the commons as that is the place
where we have established the resting place will be for
common utilities. Tying utilities that may vary should not
be bound to Turbine's development cycle. I think they should
be removed. I'm fine with a separate jar of utility code,
but the code should go to the commons.
> (it's my only complaint with anything you've ever done
> :). Turbine is a *framework*, and in addition to defining useful
> patterns for building applications, it should make available utility
> classes like StringUtils
There are 20 string utility classes scattered all over Jakarta, they
should be combined and placed in the commons. It does take a lot of
effort so an interim JAR is a good idea but I definitely don't
want to tie utilties to the core of Turbine and bundle them together.
Some of the utilities we house aren't even used in Turbine code, I
don't feel turbine should house this type of code.
> Log (which wraps the default Log4J
> Category), etc. (which the framework itself leverages internally).
You know how I feel about log wrappers, I think they are uncessary,
not beneficial and don't provide enough flexibility.
> Even if Turbine does not include these utilities in its own source
> tree, it should include a JAR which makes them available
> (jakarta-turbine-util for anything not easily placed into the
> Commons?).
I'm fine with a separate JAR, but hopefully this stuff can go to
the commons.
> Anyhow, I'll retract my official -1 (but I still feel it),
> since you are doing the lion's share of the work. I hope my reasoning
> on this matter clear.
Yup, I understand where you're coming from.
> Dan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
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: Log class
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> On 7/25/01 10:10 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
>
> > Maintaining the Log wrapper class--whever it needs to live now--is
> > very important to me. It's a brief and descriptive name, and is both
> > much shorter to type than Category.getInstance() (or whatever it is)
> > and much more clear as to its purpose.
>
> The naming can be made more clear, I don't actually have a problem
> with category as hordes of people use log4j and know what it is.
But what about those who don't? Regardless, the static Log methods
are extremely convenient.
> As for the Log wrapper, it's a bad idea especially in components
> you wish to use outside the context of the initial package the
> component was placed in. The Log wrapper is convenient in highly
> coupled systems like Turbine 2.1, but it makes reusing the
> any utility class or component difficult, inconvenient and
> not possible in some cases.
I've had absolutely zero problem using the Log class outside of
Turbine (in many Tigris projects).
[snipped argument against using Log wrappers]
> I would say a Log wrapper might be minimally acceptable in an application,
> though I still wouldn't recommend it, but definitely not in components
> like fulcrum or torque.
A framework-level package like Turbine that integrates best of breed
components is *exactly* where a Log wrapper belongs, *not* implemented
in application code.
> I am all for ease of use. For example in fulcrum we could make 'log'
> available to all the services and this is easy but you I think it is
> still better to get the category instance in each class because you
> can than easily create logs on a per service basis. Plus with log4j you
> could easily send the logs for one service to syslog, and send the logs
> for another to a file, or syslog, or an SMTP server or whatever other
> appenders are available to log4j. The only thing you have to change
> is the log4j properties file and I think that is most optimial solution.
This is almost no different from the 2.1 log system. I very much
dislike the fact that you're eliminating a lot of the utility classes
from Turbine (it's my only complaint with anything you've ever done
:). Turbine is a *framework*, and in addition to defining useful
patterns for building applications, it should make available utility
classes like StringUtils, Log (which wraps the default Log4J
Category), etc. (which the framework itself leverages internally).
Even if Turbine does not include these utilities in its own source
tree, it should include a JAR which makes them available
(jakarta-turbine-util for anything not easily placed into the
Commons?). Anyhow, I'll retract my official -1 (but I still feel it),
since you are doing the lion's share of the work. I hope my reasoning
on this matter clear.
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
Re: Log class
Posted by Jason van Zyl <jv...@apache.org>.
On 7/25/01 10:10 PM, "Daniel Rall" <dl...@finemaltcoding.com> wrote:
> Jason van Zyl <jv...@apache.org> writes:
>
>> Don't couple fulcrum to turbine. There is a Log helper in the services
>> directory as a stop gap solution until a better logging solution is found.
>> I think the static Log helper is bad anyway, but it will do for now. At
>> any rate that's the wrong Log import:
>>
>> org.apache.turbine.services.Log
>
> Maintaining the Log wrapper class--whever it needs to live now--is
> very important to me. It's a brief and descriptive name, and is both
> much shorter to type than Category.getInstance() (or whatever it is)
> and much more clear as to its purpose.
The naming can be made more clear, I don't actually have a problem
with category as hordes of people use log4j and know what it is.
As for the Log wrapper, it's a bad idea especially in components
you wish to use outside the context of the initial package the
component was placed in. The Log wrapper is convenient in highly
coupled systems like Turbine 2.1, but it makes reusing the
any utility class or component difficult, inconvenient and
not possible in some cases.
Take for example the connection pool in turbine. It depends on
the Log wrapper which is part of a larger system. The connection
pool as a component now is useless outside of Turbine. If the
connection classes used something like:
(1) Category logger = Cateogory.getInstance(category)
Where category would most likely be the classname. If it follows
the classname than it is very simple to setup categories that
may be defined by the components you are using in
your application. Say the connection pool is part of the
org.apache.util.dbcp package, than all you do is setup one line
in your log4j configuration:
log4j.category.org.apache.util.dbcp = <priority>, <appender>
And now you can capture any level of logging info from the component
with one simple addition to the lo4j configuration file. Or the app
configuration file as we do in turbine.
You could use (1) in any class, or you could have a component baseclass
and make say 'log' available to all components. Avalon does this sort
of thing. I believe it is 'm_logger' in Avalon or was the last time
I used it.
Using the (1) approach your utility classes are very portable.
I'm am a strong -1 for keeping any of the Log wrappers around in
any components that need to log. I've jumped though some hoops to get
the Log wrappers to work and it's not necessary. When I asked for advice
from Ceki on the log4j list he suggested the approach taken in (1), and
warned against using wrappers.
I would say a Log wrapper might be minimally acceptable in an application,
though I still wouldn't recommend it, but definitely not in components
like fulcrum or torque.
I am all for ease of use. For example in fulcrum we could make 'log'
available to all the services and this is easy but you I think it is
still better to get the category instance in each class because you
can than easily create logs on a per service basis. Plus with log4j you
could easily send the logs for one service to syslog, and send the logs
for another to a file, or syslog, or an SMTP server or whatever other
appenders are available to log4j. The only thing you have to change
is the log4j properties file and I think that is most optimial solution.
> Dan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: turbine-dev-help@jakarta.apache.org
--
jvz.
Jason van Zyl
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
Log class
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Jason van Zyl <jv...@apache.org> writes:
> Don't couple fulcrum to turbine. There is a Log helper in the services
> directory as a stop gap solution until a better logging solution is found.
> I think the static Log helper is bad anyway, but it will do for now. At
> any rate that's the wrong Log import:
>
> org.apache.turbine.services.Log
Maintaining the Log wrapper class--whever it needs to live now--is
very important to me. It's a brief and descriptive name, and is both
much shorter to type than Category.getInstance() (or whatever it is)
and much more clear as to its purpose.
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: turbine-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: turbine-dev-help@jakarta.apache.org