How to provide custom impl of ActionContext

[Bill Siggelkow <bi...@bellsouth.net>]

I have been trying to more closely follow the discussions on Struts use 
of Chain and have a few comments and questions on mechanisms for users 
to provide custom ActionContext impl.

It seems that the current mechanism  is to extend the 
ComposableRequestProcessor. First, I think having to extend the 
ComposableRequestProcessor is cumbersome and not in step with the 
benefits of using Chain ... a major of point, IMO, of using Chain is 
that we don't have to extend the request processor to add 
functionality. That being said, it seems like the most natural place, 
if implemented by Struts, would be the controller element. After all, 
the catalogName comes from the controllerConfig.

But to be honest, I think it would be cool if something like this could 
be handled in the chain-config.

<catalog name="struts">
  <chain name="servlet-standard" context="com.foo.MyActionContext">
   ...

Of course this would mean changes to the Command interface ... etc. -- 
Perhaps I will bring this up on the commons-dev list ...



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Best Way to use Custom ActionContext/Storing ActionContext in ThreadLocal

[Joe Germuska <Jo...@Germuska.com>]

Trying to unify these two threads:

"How to provide custom impl of ActionContext" 
http://thread.gmane.org/gmane.comp.jakarta.struts.devel/25876

"Storing current ActionContext in ThreadLocal" 
http://thread.gmane.org/gmane.comp.jakarta.struts.devel/25868

It would be great to get some ideas from people about the right way 
to allow users to use an alternate implementation of the 
ActionContext class.  I am generally ill-disposed to a factory class 
since it seems like so often factories also need configuration which 
makes discovery tedious, but having a factory class which was an 
Abstract class would also give us a convenient place to plug a static 
"currentActionContext" method.

If no configuration is necessary, we could simply stipulate 
"actionContextFactoryClass" as a String Property of ControllerConfig 
and at least move forward with that.  To be honest, for this specific 
case I'm not thinking of any configuration use cases, so maybe I 
shouldn't get hung up on it.

(Defining implementation classes and configuring them all in one 
place is the solution that Spring provides which I think makes so 
many people get so gung-ho about it.)

I think in writing this I've convinced myself to do it this way. 
Will give it a little time for responses but I'm likely to try to do 
this in the next couple of days.

Joe
-- 
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org

Re: How to provide custom impl of ActionContext

[Joe Germuska <Jo...@Germuska.com>]

At 10:01 AM -0500 3/12/05, Bill Siggelkow wrote:
>I have been trying to more closely follow the discussions on Struts 
>use of Chain and have a few comments and questions on mechanisms for 
>users to provide custom ActionContext impl.
>
>It seems that the current mechanism  is to extend the 
>ComposableRequestProcessor. First, I think having to extend the 
>ComposableRequestProcessor is cumbersome and not in step with the 
>benefits of using Chain ... a major of point, IMO, of using Chain is 
>that we don't have to extend the request processor to add 
>functionality. That being said, it seems like the most natural 
>place, if implemented by Struts, would be the controller element. 
>After all, the catalogName comes from the controllerConfig.
>
>But to be honest, I think it would be cool if something like this 
>could be handled in the chain-config.
>
><catalog name="struts">
>  <chain name="servlet-standard" context="com.foo.MyActionContext">
>   ...
>
>Of course this would mean changes to the Command interface ... etc. 
>-- Perhaps I will bring this up on the commons-dev list ...

Well, I did some things with context wrapping first which were more 
along these lines: the ActionContext was created when the 
"process-action" lookup chain was looked up, using the 
WrappingLookupCommand and the ContextWrapper class -- these are still 
in SVN, although they are no longer being used.

It seems important to guarantee that the Context being used is an 
ActionContext, which is one reason why right now it's happening in 
the RequestProcessor.  Also, it seems possible that one would want to 
do more than just instantiate a Context -- one might also want to 
populate it with certain properties in a consistent way.  Sure, you 
could do the population with a command, I guess.

However, on the current parallel thread "Storing current 
ActionContext in ThreadLocal", my last post acknowledged some reasons 
why changing the mechanism for getting an ActionContext.  I think now 
is a good time to have this discussion on either thread!

I'd be happy to move the stuff which is not being used in Struts into 
the commons-chain core if people see a use, whether or not it becomes 
how we set up the ActionContext.

Joe

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
"Narrow minds are weapons made for mass destruction"  -The Ex

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org