Yes, I'm getting the message saying that there are errors on the controller.
The strange thing is if I remove the wiring, Struts will complain about not finding any configuration for the "input" result. So it seems as if the configuration is found and used, but something gets in its way. Unfortunately I still don't have a good enough overview of how the internal wiring of Struts works, which makes it hard for me to debug - but I guess I should look into it. However I've managed to come to the conclusion that "result" is null here (because I'm getting the "No result returned for action"-error): http://grepcode.com/file/repo1.maven.org/maven2/org.apache.struts/struts2-rest-plugin/2.2.3/org/apache/struts2/rest/RestActionInvocation.java#295 This should mean that findResult() of RestActionInvocation runs but cannot find a suitable result. However - as I explained earlier - I'm not certain in what order things get executed around here. :) //Christoffer Aaron Brown-7 wrote: > > The source for 2.2.3 that appears to apply to this situation can be read > here: > > http://grepcode.com/file/repo1.maven.org/maven2/org.apache.struts.xwork/xwork-core/2.2.3/com/opensymphony/xwork2/interceptor/DefaultWorkflowInterceptor.java#144 > > I referenced line 144 because that's where the doIntercept method is > defined, and this is where the processing logic is that returns the > result string. A few lines up you can see "inputResultName" defined > with a default of Action.INPUT as expected. However, inside > doIntercept, that result name can be overridden by settings within the > action or annotations on the action. I suspect there may be a version > difference in the processing of your annotations, but I could be > wrong. It looks as if, when annotations are present on an action > method, the doIntercept method expects to find a result string defined > with that action/method. I suppose if it's null, you'd get Action.NULL > back. There's a DEBUG level log statement inside that, any time > hasErrors is true, should drop a log entry about finding errors. Are > you seeing that error? I don't know if struts is distributed with > source included in the jar, but if so you could try setting a > breakpoint in this method to see what it's thinking. > > You could try removing your annotation setup and wiring your actions > with a struts.xml file instead? Probably a quicker check than reading > through all the annotation processing code. > > - Aaron > > -- > Aaron Brown : aa...@thebrownproject.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > -- View this message in context: http://struts.1045723.n5.nabble.com/Failed-validation-returns-Action-NONE-instead-of-Action-INPUT-in-Struts-2-2-3-tp4618385p4621970.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
