On 8/23/06, Ted Husted <[EMAIL PROTECTED]> wrote:
On 8/23/06, Erik Bertelsen <[EMAIL PROTECTED]> wrote:
> this is exactly my concern in this discussion: I want to be able to
> control all logging from my application in one place.
The question is whether Struts (and XWork and Spring) should c
Ted Husted said:
> The question is whether Struts (and XWork and Spring) should
> count as part of "your application" or not.
>
> What's being proposed is that we take Struts out of the "my
> application" logging loop, so that you are free to do
> whatever you like with your own application.
I
On 8/23/06, Erik Bertelsen <[EMAIL PROTECTED]> wrote:
this is exactly my concern in this discussion: I want to be able to
control all logging from my application in one place.
The question is whether Struts (and XWork and Spring) should count as
part of "your application" or not.
What's bei
2006/8/22, Martin Cooper <[EMAIL PROTECTED]>:
As long as the log output and log configuration for my end application is
unified - so Struts output and Commons component output go to the same
place
- then I'm OK with using something other than Commons Logging, if we have
to.
Dear all,
this
Whatever Struts ends up doing, we'll also do in XWork.
> On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
> > I'd rather use java.util.logging than
> commons-logging, but I think both
> > are overkill for a library.
>
> Of course, our library is an extension of the XWork
> library.
>
> Do we wan
On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
I'd rather use java.util.logging than commons-logging, but I think both
are overkill for a library.
Of course, our library is an extension of the XWork library.
Do we want to cooridnate what we do here with what XWork 2 does / should do?
Otherw
I created an issue ticket for this - and attached an implementation:
https://issues.apache.org/struts/browse/WW-1413
Niall
On 8/23/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 8/22/06, Bob Lee <[EMAIL PROTECTED]> wrote:
> On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
> >
> > Well, for
On 8/22/06, Bob Lee <[EMAIL PROTECTED]> wrote:
On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
>
> Well, for one, we only really need one logging instance for the whole
> library. Second, and admittedly this is subjective, the
> java.util.logging API is a horribly designed, obtuse API. I'd rat
On 8/22/06, Tim Fennell <[EMAIL PROTECTED]> wrote:
log.debug("And the answer is: ", myBigObject, " (didn't you
guess?).");
I like that.
Why does a difference of opinion always have to lead to someone
saying "I don't think you get what I'm saying"? Sigh. I get it just
fine, I just disagree.
So what you're saying effectively is that developers who are smart
enough/well trained enough to know to wrap expensive logging
stat
On 8/22/06, Martin Cooper <[EMAIL PROTECTED]> wrote:
On 8/22/06, Tim Fennell <[EMAIL PROTECTED]> wrote:
>
> On Aug 22, 2006, at 5:11 PM, Martin Cooper wrote:
>
> > if (isDebugLoggingEnabled()) {
> >log.debug("And the answer is: " + expensiveMethodCallHere());
> > }
> >
> > I don't know about
On 8/22/06, Tim Fennell <[EMAIL PROTECTED]> wrote:
On Aug 22, 2006, at 5:11 PM, Martin Cooper wrote:
> if (isDebugLoggingEnabled()) {
>log.debug("And the answer is: " + expensiveMethodCallHere());
> }
>
> I don't know about you, but I'm very thankful for that guard when
> debug
> logging is
On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
I think a couple extra classes is worth switching from this:
public Order createOrder(User user, Product product, int quantity) {
if ( log.isLoggable(Level.FINE) ) {
log.fine("Creating new order for user: " + user.username() +
This isn't an either/or decision. As I said before, there certainly are
cases where the guard is necessary and your example highlights one of
them. However, in most cases, it isn't and these cases could use a more
compact var-args logging call.
Don
Martin Cooper wrote:
On 8/22/06, Tim Fenn
On Aug 22, 2006, at 5:11 PM, Martin Cooper wrote:
if (isDebugLoggingEnabled()) {
log.debug("And the answer is: " + expensiveMethodCallHere());
}
I don't know about you, but I'm very thankful for that guard when
debug
logging is disabled (e.g. in production). Without it, I'm going to
make
On 8/22/06, Tim Fennell <[EMAIL PROTECTED]> wrote:
To add a little weight to Don's comments, the cost of allocating an
array really is *very* minor. To quote Brian Goetz[1], the cost of
allocating a new object in 1.4.2 and above is approximately 10
instructions (maybe more for an array, but rem
To add a little weight to Don's comments, the cost of allocating an
array really is *very* minor. To quote Brian Goetz[1], the cost of
allocating a new object in 1.4.2 and above is approximately 10
instructions (maybe more for an array, but remember that var-arg
calls are optimized at comp
There will always be cases where the isDebugEnabled method will be
necessary, but for the vast majority of cases, I think the varargs
solution is perfect. The very minor cost of an Object array, IMO, is
well worth the value of code clarity, simplicity, and maintainability.
Don
Laurie Harper
The var-args log message construction is definitely a nice bit of
syntactic sugar, but removing the guard seems unwise; sure, there's no
string concatenation in the call to log.debug, but there's an implicit
Object[] instantiation, which isn't much better. There's a reason every
major logging A
Don Brown wrote:
In this case, yes, we need to log, however, as a library, the only
messages the user will care about are those that are from the library
as a whole. If the user needs to filter at a package level a
library's log messages, that library has problems :)
Agreed, *up to* the point
On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
Well, I don't think adding external deps was ever on the table as the
discussion was prompted by wanting to get rid of them :) I'm fine with
extending j.u.logging, but would plan to add isDebugEnabled and debug
methods :)
Sounds great.
+1 I really like what Seam is doing. As soon as Velocity moves to
jdk5, you can bet we'll be doing much the same.
And yeah, it really only takes a few simple classes to have a much
nicer interface than j.u.logging. For Velocity, we basically have
two classes (Log and LogManager) and an interf
Bob Lee wrote:
I thought we were talking about logging for Struts internals. Are we
talking
about also exposing a utility class of some sort to users? Or is this
just
an example?
This is just an example.
Like I said in the other email, I'm all for varargs, but we should
probably
just hard
I thought we were talking about logging for Struts internals. Are we talking
about also exposing a utility class of some sort to users? Or is this just
an example?
Like I said in the other email, I'm all for varargs, but we should probably
just hard code it to j.u.logging and not worry about gett
+1 for varargs. We can always extend j.u.logging.Logger and add these
methods.
On 8/22/06, Tim Fennell <[EMAIL PROTECTED]> wrote:
I can't agree enough with using var-args for logging. Stripes has,
from the start, done something very similar to Seam. The main
difference is that instead of putt
I think a couple extra classes is worth switching from this:
public Order createOrder(User user, Product product, int quantity) {
if ( log.isLoggable(Level.FINE) ) {
log.fine("Creating new order for user: " + user.username() +
" product: " + product.name()
+ " qu
I can't agree enough with using var-args for logging. Stripes has,
from the start, done something very similar to Seam. The main
difference is that instead of putting placeholders into the message,
you just provide things in the order you want appended. I find that
convenient because you
On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
Well, for one, we only really need one logging instance for the whole
library. Second, and admittedly this is subjective, the
java.util.logging API is a horribly designed, obtuse API. I'd rather
see us write a small, clean API along the lines of
Well, for one, we only really need one logging instance for the whole
library. Second, and admittedly this is subjective, the
java.util.logging API is a horribly designed, obtuse API. I'd rather
see us write a small, clean API along the lines of Seam's logging class
that utilizes varargs to r
How is j.u.logging overkill, especially considering using it would mean one
less dependency? From our standpoint, the only thing we care about is Logger
anyway.
Bob
On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
I'd rather use java.util.logging than commons-logging, but I think both
are over
I'd rather use java.util.logging than commons-logging, but I think both
are overkill for a library. I think Nathan is spot on and we should
look to using Velocity's logging classes, imported into our codebase.
The whole logging "framework" we'd need would be like two or three classes.
Jarjar
Very cool. That looks like what i was looking for. Thanks :)
On 8/22/06, Bob Lee <[EMAIL PROTECTED]> wrote:
On 8/22/06, Ted Husted <[EMAIL PROTECTED]> wrote:
>
> Say, wasn't there a mention of some package that renamed packages
> dynamically or something? That's the real issue. Two versions o
If i might jump in here...
I whole-heartedly agree with Don. A couple years ago i would have
argued against him on this quite vigorously. But after several more
years of working close with both Struts (and VelocityStruts) which use
commons-logging and Velocity itself (which takes Don's approach
On 8/22/06, Ted Husted <[EMAIL PROTECTED]> wrote:
Say, wasn't there a mention of some package that renamed packages
dynamically or something? That's the real issue. Two versions of the
same package name on the same classpath.
jarjar
In the case of logging though, we should just use java.util
On 8/22/06, Don Brown <[EMAIL PROTECTED]> wrote:
At some point, I plan to replace commons-logging in Struts 2 with a
simple log framework. I can backport to Struts 1 if desired.
Why not just import the org.apache.common.logging source code and
rename it o.a.struts.logging? That way we don't ha
Commons Logging is a great example of the problems these small
third-party dependencies cause host applications :)
In this case, yes, we need to log, however, as a library, the only
messages the user will care about are those that are from the library
as a whole. If the user needs to filter at a
On 8/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
I think we should keep s2's dependencies down to an absolute minimum.
If you are writing an application, the more you reuse third-party
libraries the better, however, if you are writing a framework and/or
library, ideally, you should have none.
T
I think we should keep s2's dependencies down to an absolute minimum.
If you are writing an application, the more you reuse third-party
libraries the better, however, if you are writing a framework and/or
library, ideally, you should have none.
The main reason libraries should have as few dep
38 matches
Mail list logo
