[jira] Closed: (STR-2550) Support Easier Pluggability of custom ActionContext implementations

["Joe Germuska (JIRA)" <ji...@apache.org>]

     [ http://issues.apache.org/struts/browse/STR-2550?page=all ]
     
Joe Germuska closed STR-2550:
-----------------------------

    Fix Version: 1.3.0
     Resolution: Fixed

A step towards improving this was implemented in r330112, when code was committed to support specifying a custom ActionContext subclass in struts-config config file, rather than having to extend ComposableRequestProcessor.  

I'm still not extremely satisfied with how the ActionContext gets initialized after it is created, but since this hasn't gotten much attention from anyone else, it seems to me it can be closed, and if someone proposes a specific enhancement, a new ticket can be opened.

> Support Easier Pluggability of custom ActionContext implementations
> -------------------------------------------------------------------
>
>          Key: STR-2550
>          URL: http://issues.apache.org/struts/browse/STR-2550
>      Project: Struts Action 1
>         Type: Improvement

>   Components: Core
>     Versions: Nightly Build
>  Environment: Operating System: other
> Platform: Other
>     Reporter: Joe Germuska
>     Assignee: Joe Germuska
>     Priority: Minor
>      Fix For: 1.3.0
>  Attachments: ComposableRequestProcessor.java, ComposableRequestProcessor.patch.txt
>
> As has been discussed on struts-dev, it should be easy for people using Struts
> 1.3 to specify an alternate implementation of ActionContext.  Right now, one
> must extend ComposableRequestProcessor and override the contextInstance(...)
> method.  In practice, I've seen that this can lead to difficult to debug error
> conditions when the ActionContext is not initialized in the subclass in the same
> way that it is initialized in ComposableRequestProcessor.
> This initialization is somewhat problematic, since ServletActionContext is
> designed without a no-arg constructor, and commonly needs to have its "servlet"
> property set, even though that property is not part of the base "ActionContext"
> interface.
> I've put together a solution, but I'm not totally thrilled with it.  It allows a
> user to specify an ActionContext class in struts-config, and it tests the class
> to see if it has the constructor which would normally be used by
> ServletActionContext.  If it does, it uses it, and if it doesn't, it assumes a
> no-arg constructor.
> Then, in the initialization phase, it does an instanceof ServletActionContext
> test to see about setting the "servlet" property.
> All of this seems kind of crude, although functional.  Perhaps I should start
> regretting making ServletActionContext without a no-arg constructor, although I
> implemented a bunch of stuff around the commons-chain WebContext classes.  That
> could be changed, if that's one of the key issues.  There's still the general
> issue of various kinds of ActionContext initialization which need to happen as
> early as possible, and in a consistent fashion.
> If no one objects strenuously, I would probably go ahead and commit this after
> giving it a few more tests -- but I thought it was worth getting some other eyes
> on it, since I'm not thrilled with it.
> Another general thing: this marks the second time I've built out Struts
> functionality based on use of the new "arbitrary property" support in Struts
> 1.3.  We will probably want a certain consistency in naming for those
> properties, so if anyone has strong feelings about that, please speak up now
> before it gets too hard to change.
> Patches forthcoming.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira