struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: REST Showcase 2.1.2
Date Mon, 01 Sep 2008 13:57:13 GMT
Thanks Jeromy --

I'd rather sleep with my sister than embed annotations in my code.  This
notwithstanding, I understand your reluctance to add yet another permutation
to that lookup scheme.  I poked around in the code back in 2.0 and nearly
got a nose bleed.  I hope there are a ton of unit tests around that baby!
I'm getting the feeling that REST is not ready for prime time.  I too
wondered why it was excluding edit, editNew.  I'm sure there was a reason.


On Mon, Sep 1, 2008 at 8:09 AM, Jeromy Evans <> wrote:

> stanlick wrote:
>> Also, what is the naming convention for validation xml files using the
>> Code
>> Behind/REST plug-in?
>> I've tried several combinations of naming, but none seem to work.
> The short answer is: you can't. It doesn't work.
> Fortunately annotation validation works correctly in 2.1, so the approach
> I've used is:
>  - the action carries validation annotations on the applicable methods;
>  - the model's use XML validation
> as they can be used together and it's well suited to ModelDriven.
> The problem is that the DefaultValidatorFileParser in Xwork that reads the
> XML file has no way to specify which method it should be applied to.  It
> applies to the entire class.
> With wildcards in 2.0 you could get around this because the action "alias"
> included the method name.
> It's the same reason using "method='update'" spefied in struts.xml never
> worked properly with XML validation. The parameter was ignored by the XML
> validator. This had always frustrated me.
> Fortunately somebody fixed the annotation interceptor so it can distinguish
> between the methods being executed.  Unfortunately that fix
> (validateAnnotatedMethodOnly) is not enabled by the rest plugin by default.
> Further compounding the problem is that rest plugin has disabled validation
> for the edit, editNew and other relevant methods. (I'm not sure why...there
> must have been a reason for that).
> What I've done is replace the rest default stack with one that includes the
> validation interceptor with better configuration:
> <interceptor-ref name="validation">
>  <param name="excludeMethods">input,back,cancel,browse,index</param>
>  <param name="validateAnnotatedMethodOnly">true</param>
> </interceptor-ref>
> <interceptor-ref name="restWorkflow">
>  <param name="excludeMethods">input,back,cancel,browse,index</param>
> </interceptor-ref>
> I've been tempted to delve in a fix this but so far I've stayed out of
> xwork. The rest plugin does the right thing setting up the ActionInvocation
> with the action name and method name; the XML validation config reader just
> needs to use the method name to select the file (eg. to load
> OrdersControler-<action>-<method>-validation.xml if it exists).  But I feel
> it already searches for far too many combinations, so I've been reluctant to
> touch it.
> stanlinck also wrote:
>  Would you share the interceptor stack to fold paramsPrepareParamsStack
>> capabilities into the restDefaultStack?
> I haven't experimented with this much with the rest plugin as I try to
> avoid it .  It's reasonable logical...
> The actionMappingParams interceptor is the one responsible for setting the
> id, so it needs to appear before the prepare interceptor.
> If you need other params, before prepare, you also need params before
> prepare.
> The actionMappingParams and params are then required after prepare again.
> ie. set the id, load the object, set the id and params
> It's different because the ActionMapper obtained the id from URI.
> If you use other variables in the namespace you also need this interceptor
> before prepare.
> Hope that helps,
> Jeromy Evans
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message