struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Struts Wiki] Update of "RoughSpots" by Bob Lee
Date Wed, 19 Apr 2006 20:05:46 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.

The following page has been changed by Bob Lee:

      * [plightbo] + 1 again.
      * [mrdon] This I don't agree with.  From a framework developer, I understand the logic,
but from a user, it is arrogant.  I think we should allow people to extend Struts in ways
we haven't imagined, and restricting access like this says, "We know more than you and will
force you to do it our way."
+     * [crazybob] I don't think we should make everything final or anything, but I do think
we should differentiate between the published API and the implementation through package organization,
excluding stuff from the Javadocs, etc. Users can know that we won't change the published
API out from under them, but that if they depend on implementation classes, we may break them
(reluctantly). It's the polite thing to do, and it frees us up to refactor and improve our
    1. Remove `destroy()` and `init()` from `Interceptor`. They don't make much sense until
the interceptor lifecycle is specified (see next item). I've never needed them, yet it's a
pain to implement empty methods every time I implement an interceptor. Users can use the constructor/finalizer
or we can create additional lifecycle interfaces.
@@ -89, +90 @@

      * [jcarreira] We don't want to allow for extension?
      * [crazybob] Extension through interfaces and methods? Yes. Public/protected fields?
Absolutely not!
      * [mrdon] I dunno, are you planning to make protected getters/setters for every field?
 I've found protected fields to be invaluable when extending frameworks (again, subscribing
to the believe we should let the user do what they want and not artifically restrict them).
 I do wish you could declare the fields _only_ available to subclasses and not to the whole
+     * [crazybob] Absolutely, methods instead of fields. Methods enable us to hook access
if need be, change the underlying implementation, manage thread safety, protect our own code
against unexpected conditions/states, etc. Fields are OK within a package, but when it comes
to public APIs, better safe than sorry a year from now.
    1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is better.
@@ -170, +172 @@

    * [MJ] With JDK 1.5 as a requirement for SAF2-based projects, users may be inclined to
take a look at [ Stripes] first. It
is compact, it features event-dispatching, built-in validation and conversion, Action and
!ActionForm being one entity, and it allows to forgo XML config files by using annotations.
The last feature alone is worth sack o'gold. If SAF2 is going to require JDK 1.5, it should
allow XML-free configuration, at least for simple use cases.
    * [plightbo] I use JDK 1.5 as well. I think we really should think about doing this. Non-1.5
options exist (WebWork 2.2 and Struts 1.3), and we're really at a close point where it is
no longer unreasonable to require 1.5 (1.6 will have been out for almost 6 months by the time
we hit a final release).
    * [mrdon] I'd like to use Java 5, but use retroweaver to continue to support 1.4.  If
we keep XML in addition to annotations, that should be very doable.
+     * [crazybob] Sounds good. We'll also need to handle JDK-1.5 only APIs (concurrency for

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

View raw message