If struts fails to find the action configuration it will try to use an
instance of com.opensymphony.xwork2.UnknownHandlerManager to create a valid
configuration. So this seems like the extension point I need.


On Tue, Nov 13, 2012 at 12:38 AM, Ken McWilliams
<ken.mcwilli...@gmail.com>wrote:

> I thought it would be interesting if I could create an interceptor stack
> from already defined interceptors and store that definition in a database.
> I also wanted to store action mappings (packages, actionName, method) along
> with the name of the class which was to be associated with the action.
>
> Anyways I'm a bit stuck...
>
> First I thought I would create an DynamicInterceptorInterceptor which
> would maintain it's own configuration and call the interceptors in turn.
> But I think ActionProxy and ActionInvocation are supposed to be doing
> something when calling Interceptors so that probably isn't good, and all
> actions would target DynamicActionAction... this too I think has problems.
>
> Then I though well if ActionProxy manages all the calls to the interceptor
> and Action I could hide some configuration in there (by creating my own
> ActionProxyFactory). If the actionProxy signature (ActionInvocation inv,
> String namespace, String actionName, String methodName,
>             boolean executeResult, boolean cleanupContext) matches one for
> my magic DB action then I'll simply trick all the calls to invoke what
> needs to be invoked using some special logic.
>
> I'm not that familiar with struts2 thinking but it seems like this
> solution would be quite ugly. What would be most ideal is to create a user
> defined ConfigurationProvider which augments the existing configuration
> with additional configuration.
>
> Any advice?
>
> For fun I was thinking if I could get that working I could make a web
> based UI to edit Struts2 configuration (just the interceptor stack for
> now), save that and reload the configuration. That would be pretty neat. If
> it could then write a proper struts.xml file that would be pretty cool too.
>
> Anyways this isn't for production, this is to better understand the
> framework and do something interesting.
>

Reply via email to