Well, I think the first thing is to figure out what should be pulled out. I
think we pretty much know what that is. Basically, anything that has "Http"
or "Servlet" in it.
Then the real trick is to figure out what should be put BACK in. Abstract
support for getRemoteUser is a must. I suppose some
Patrick Lightbody wrote:
> Well, for one, WebWork needs to completely remove itself from the "web".
> This is WW-12 and is critical towards this goal. For example,
> ActionContext.getRequest() returns an HttpSerlvetRequest object. All the
> servlet stuff needs to be abstracted away and then allow
>> Great stuff - I think there's a lot of cool things WW can do to become an
>> uber-command framework.
>
>Yup, but what? What is missing?
Well, for one, WebWork needs to completely remove itself from the "web".
This is WW-12 and is critical towards this goal. For example,
ActionContext.getReques
>> Great stuff - I think there's a lot of cool things WW can do to become an
>> uber-command framework.
>
> Yup, but what? What is missing?
It would be cool to have a simple ActionExecutor? Something like:
ActionExecutor.execute("actionName", paramsMap);
Then of course you could have asynchr
Mike Cannon-Brookes wrote:
> Great stuff - I think there's a lot of cool things WW can do to become an
> uber-command framework.
Yup, but what? What is missing?
> For example someone (Noah?) sent me via email his ActionPool implementation,
> which is a funky idea!
That is a really powerful thi
>> PS Does anyone else use WW without the web? (ie as a generic command pattern
>> framework?) I think there are a lot of improvements we could make in this
>> area.
>
> I've implemented a basic RMI framework for our content management
> product using it, and the ClientServletDispatcher. Trivial
Mike Cannon-Brookes wrote:
> PS Does anyone else use WW without the web? (ie as a generic command pattern
> framework?) I think there are a lot of improvements we could make in this
> area.
I've implemented a basic RMI framework for our content management
product using it, and the ClientServletD
Francisco,
Good point - I actually patched this a while ago locally and forgot to
commit it. But now I can't find the patch.
I think there were two problems, one is that ActionContext.getContext()
returns null (can't remember why) and the other is that
ParametersActionFactoryProxy tries to set t
I've got a problem with running ActionSupport based classes outside of
webwork servlet container, what happens in that when i invoke
ActionSupport.execute() it throws a NullPointerException which is caused by
it calling ActionContext.getContext() which in turn is calls
java.lang.ThreadLocal.get()
