When I got my "WebWork In Action" book, I saw it had the ability to give
names to actions. This feature I wanted in Struts 1.x because my action
paths are usually 3-5 directories deep in a command-like pattern. I find
it very very difficult to keep my action configs, forwards, and JSP tag
use a
Yep.
Craig
On 8/22/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
This is a test. Can anyone read this?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This is a test. Can anyone read this?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
test
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I was hoping someone would respond to the previous email
I think this might be a bug -- it looks like it is on the surface -- but
I need the inventors of the ComposableRequestProcessor to lend their
brains. The class performs a forward, not an include. Isn't that
obviously wrong? I think i
On 8/22/06, James Mitchell <[EMAIL PROTECTED]> wrote:
I'd say it's more a matter of doing what it has always done rather
than doing what others like it have done. What I mean is, adding
this should have no effect on existing applications. I know it may
seem confusing to someone comparing optio
I'd say it's more a matter of doing what it has always done rather
than doing what others like it have done. What I mean is, adding
this should have no effect on existing applications. I know it may
seem confusing to someone comparing option and options side by side,
but it's not nearly a
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
Folks,
Issue STR-2932 indicates that needs a filter attribute, much
like and .
https://issues.apache.org/struts/browse/STR-2932
I've submitted patches for both html and html-el taglibs to add the boolean
filter attribute, but a question remains on what the correct default should
be, true or f
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
Martin,
Pat just contacted me and I send him the links to the ICLA forms.
My former mail to him was lost somewhere, so that he did not receive our
request.
I'll keep you updated.
Rainer
-
Posted via Jive Forums
http://forums.op
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
On 8/22/06, Greg Reddin <[EMAIL PROTECTED]> wrote:
Nope, those errors were occurring before the last round of changes.
I haven't yet figured out what's causing them, but they are known
errors. Does it make the build fail?
No. I just wanted to add some automated tests for the app, and
discove
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 Aug 22, 2006, at 12:17 AM, Wendy Smoak wrote:
The app starts and deploys, however
- the 'Test Put Tag' link results in a blank page, and
- the 'Test Definition Tag' link throws an exception:
org.apache.jasper.JasperException: /testdef.jsp(3,0) According to the
TLD or the tag file, attribut
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
40 matches
Mail list logo
