struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <>
Subject Re: Issues upgrading from WebWork 2.2.3 to Struts 2.0.0 (SVN)
Date Wed, 30 Aug 2006 20:09:32 GMT
On 8/30/06, Don Brown <> wrote:
> I guess what I'm saying here is that the Struts learning curve should be
> as flat as possible, allowing developers to ease into the framework
> without forcing them to learn about things like custom interceptors and
> results when they don't have the need for them.

In my experience, the easiest way to flatten the learning curve is consistency.

Right now, our approach to default result types is inconsistent. Most
results work out of the box, but some require people to add optional
JARs to the distribution. For the "optional" results, we've started to
add apologetic logging statements, saying "Oops, I'm here, but my JAR
isn't, but you probably don't care anyway."

If we are going to have optional result types, then let's have
optional result types. Let's add an "optional" attribute, so that we
can render more meaningful logging statements.

1 When optional=true, and the support class is absent, then nothing is logged.

2 When optional=true, and the support class is present, then a DEBUG
logging statement saying the result is enabled is logged

3 When optional=false (the default), and the support class is absent,
a runtime exception is logged and thrown (fail fast).

4 When optional=false, and the support class is present, then nothing
is logged (the nominal case).

Even if we mark a result type optional in the configuration, we can
still override the setting in a package, so if we need to do a problem
determination, we can add the result again as "optional=false" in a
package, so that we can be sure the system sees the result, but not
the JAR.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message