3

I am doing my first steps with Struts 2 and the struts2-convention-plugin, currently working on a CRUD action class (SongCrudAction) with some typical create(), edit(), view() and delete() action methods. All those methods are annotated with @Action.

Generally, I'd like to inherit the useful default behavior from ActionSupport, but that also includes inheriting the execute() method.

Using the configuration browser, I can see that there is an action named song-crud pointing to it. That song-crud action is obsolete and I'd like to get rid of it, as I've got my own action methods for all desired operations. I guess, thanks to Struts2 conventions, that song-crud action is assumed although I haven't declared it anywhere.

In this particular case, one possible solution would be to give some reasonable meaning to the execute() method, e.g. I could use it for the view() operation. A drawback would be that the action class should then be renamed (or annotated?) according to the execute() method's behavior (e.g. ViewSongAction instead of SongCrudAction). Otherwise, the view action's URL would be inappropriate (i.e. /view-song?id=5 would fit better than /song-crud?id=5).

On the other hand, renaming the class would be ugly, too, because it's just a CRUD and not a view action class.

Anyway, the general problem remains: whenever I inherit from ActionSupport, it presents me with an execute() method which may or may not be useful for what I'm doing.

So, it seems reasonable to somehow tell Struts 2 to exceptionally forget about the execute() method in my CRUD action class. Is that right, and how can I achieve that? Is there a better solution?

Roman C
  • 49,761
  • 33
  • 66
  • 176
user1992821
  • 268
  • 2
  • 6
  • Which method execute do you want to forget? – Roman C Mar 07 '13 at 11:01
  • SongCrudAction.execute() is inherited from ActionSupport and should not appear as "song-crud.action" in the configuration browser. – user1992821 Mar 07 '13 at 11:04
  • if you extend the ActionSuppost then you should override the execute method. – Roman C Mar 07 '13 at 11:07
  • OK, but that would mean to "...give some reasonable meaning..." (see above) with drawbacks as described, right? – user1992821 Mar 07 '13 at 11:12
  • Thank you, Roman C. It seems to be a common approach to use the execute() method in the context of a "Post-Back Default", as I found out here: http://struts.apache.org/release/2.2.x/docs/action-configuration.html#ActionConfiguration-PostBackDefault. – user1992821 Mar 07 '13 at 11:52

1 Answers1

0

The execute method will run by default if you not specify the method attribute in the action config. And if you not use DMI to run your methods. The ActionSupport is already implemented the execute method as it implemented the Action interface. But the note that appear with exclamation image below looks really strange.

If there is no execute method and no other method specified in the configuration the framework will throw an exception.

that is true anyway, the opposite if you have the execute method, and other methods then which method will be executed? You could omit the method attribute in the action config and use DMI to call any method in the action including the execute method if no method is specified.

Roman C
  • 49,761
  • 33
  • 66
  • 176
  • Well, I was actually trying to omit struts.xml and use conventions + annotations instead. When using XML configuration, I guess it's a different story. In that case, it should easily be possible to prevent the inherited execute() method from ever being called: I could just declare all my CRUD actions with an explicit method name (other than "execute"), so how could I call execute() then? However, when using conventions + annotations, the callable actions are automatically inferred from "what's there", and the question would be if there is a way to "omit" some of them. – user1992821 Mar 07 '13 at 13:11
  • No matter of how do you create your actions configuration via XML or annotations if you omit the explicit method declaration the execute method will be called if you don't have such method then exception will be thrown as stated above. If you want to prevent the execute method the best way is to use an abstract action that extends the `ActionSupport` that overrides the execute method with `String execute(){return ERROR;}` But I don't recommend to do so. With execute you don't required explicitly define methods. – Roman C Mar 07 '13 at 13:23
  • 1
    OK, thank you very much. I guess I will just use the above mentioned "Post-Back Default" pattern in order to "exploit" the execute method, so there's no need to somehow "hide" or "disable" it. – user1992821 Mar 07 '13 at 13:41