Dave,
your comments helped me resolve the issue, see my comments below.
Dave Newton wrote:
A couple of comments, although with the configuration provided I'm not getting
as far as you are.
--- On Thu, 12/4/08, Robert Graf-Waczenski wrote:
<struts>
<package namespace="/blah/blurp"
name="com.blah.blurp"
extends="struts-default">
<action name="add"
class="com.blah.blurp.actions2.AddAction">
<result name="success"
type="redirect">
/JSP/blah/blurp/add.jsp
</result>
</action>
</package>
</struts>
My first concern is that this is a "redirect" directly to a JSP. That will
eliminate useful functioning of the S2 tags (I thought, anyway) since the request won't
be handled by the S2 request handling--meaning nothing will be on the stack at all.
If your goal is to redirect back to the action you should use
"redirectAction"--redirecting *directly* to a JSP that expects to be able to
access S2 functionality is almost certainly not what you want.
That was the culprit! I was unaware of the fact that the action must be
executed in order for the value stack to be prepared properly. I was
guessing in that direction already but wanted a guru to confirm this
first, which is what you did. Redirecting to a JSP that displays "form"
values is an old Struts1 habit which one must learn to avoid when
migrating to Struts2.
public class AddAction implements
ModelDriven<AddAction.SessionValues>,
ServletRequestAware
...
You may want to consider implementing SessionAware; it's simpler and avoids
coupling to the servlet spec.
I was considering this but decided against it because our app is coupled
to the service spec anyway and almost all of the rest of the app
requires certain request parameters to be present, for example in order
to display and log error details on our Struts1-based error page. In the
long run, more parts will be migrated to Struts2, so eventually the
coupling to the servlet spec will be less tight.
public String getmAddress() {
return mAddress;
} // ... and the other getters
I don't believe these are following the JavaBean spec, although I don't know if that's
what's causing any of your issues. IIRC they'd need to get getMAddress. That said,
stylistically I'm dead-set against exposing the internal naming convention to the
getters/setters, irrespective of if they're JavaBean-compliant names. (I tested w/ what I
thought were compliant names and a non-"redirect" type (which just won't work)
and both values appear.)
That's our naming spec and we have decided to also use this spec for
bean property names, hence the getters and setters.
Thanks for your help again, it is much appreciated!
Robert
