struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject Re: POJO Actions and the ActionCommand interface (Re: Configuration inheritance, module init code)
Date Wed, 16 Mar 2005 04:48:55 GMT
On Tue, 15 Mar 2005 17:34:13 -0600, Joe Germuska <> wrote:
> I wrote:
> >Yes... I'm sorry that that discussion has stalled.  Although I don't
> >even know if that's an incremental step towards a POJO action --
> >it's practically all you need, plus a little more smarts in the
> >CreateAction command.  I'll go post a ping.
> OK, so I actually started looking at using POJOs for Actions, and
> it's a bit trickier than I'd thought, but I may want to use it on a
> current project, so if people want to talk about it, there's a chance
> I'll get it into Struts 1.3 sooner than later...

I'm not sure I see the reasoning / benefit of POJOs as Actions. The
implication is that some method that wasn't designed to be invoked as
a command / action can do something useful without knowing about the
request, mapping, form bean, etc. (If it has to know about those
things, then it might as well be a Command or an Action anyway. It's
certainly not a POJO at that point.) That seems so unlikely as to be
not worthwhile supporting.

> I like the general idea of saying that the "type" property can be an
> Action, a Command, or a pojo.  Perhaps there's no point in using
> Command when you can use a pojo too?

Actually, this type of overloading already leads to hard-to-track-down
problems in other parts of Struts. For example, we overload the 'path'
attribute of <forward>s so that it can be a path or a tile. If, for
some reason, your Tiles definitions don't get loaded at startup time,
the first time Struts tries to use a <forward> with a tile value, the
user gets a weird error about illegal path syntax.

In short, I'd discourage overloading attributes for multiple purposes,
because it will make it hard to determine what goes wrong when there's
a problem.

Martin Cooper

> My thought is that CreateAction would just check the type instance
> and if it wasn't an instance of Action, it would wrap it in a new
> class, ActionWrapper, which would take an instance and a method and
> then do the invocation in its execute method.
> Postulating something like ActionContextFactory.getCurrentInstance(),
> the ActionWrapper would look something like this:
> public class ActionWrapper extends Action {
> public ActionWrapper(Object instance, String method) {
>    this.instance = instance;
>    this.method = method;
> }
> public ActionForward execute(m,f,r,r) {
>    Object pojo = getInstance();
>    // perform reflection and invocation
>    return (ActionForward)
> ActionContextFactory.getCurrentInstance().getForwardConfig();
> }
> }
> Does that seem like a workable approach?
> Along the way I was also entertaining thoughts of getting
> ActionCommand in here, but then I kept thinking "why again didn't we
> change Action to have an 'execute(ActionContext)' method"?  But I
> guess if there's a way to execute POJOs then I have a ready way to
> get the current ActionContext, which is the real item of interest --
> especially if we are using a custom implementation of ActionContext
> with properties that reflect our application's request/session-scoped
> properties.
> Joe
> --
> Joe Germuska
> "Narrow minds are weapons made for mass destruction"  -The Ex
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message