-- from mailing list --
I'm trying to debug a problem when WebWork 2 invokes an Action method on an Action that has been proxied using CGLIB. I'm loading the Action from Spring, and I've attached an AOP interceptor to my Action.

The ObjectFactory support in WebWork was causing me some grief. I think my problem is in this method:

DefaultActionInvocation.invokeAction(Action, ActionConfig)

At the time this method in called, by action has been generated from the SpringObjectFactory (but this could be *any* ObjectFactory implementation).
Since my Action is proxied by CGLIB, its value during debug looks something like this:

action: com.opensymphony.xwork.Action =
 
{us.oh.state.dot.jpp.web.action.SignonAction$$EnhancerByCGLIB$$bb4d4da@11528
}

The next thing that happens is that actionConfig.getMethod() is called to obtain a java.lang.reflect.Method object. The main problem I see is that the
getMethod() method in ActionConfig asks the ObjectFactory to create another instance of the Action. At best, this is unnessesary since the Action can be passed into this method call from the DefaultActionInvocation. Under normal circumstances it wouldn't be so bad since the method it pulls is cached in the ActionConfig.

At worst, in my case, the second instantiation of the Action produces a class that is not addressable to the original Action request. Basically, it seems that CGLIB proxies of the same target object are not able to be cast to each other's proxied targets. This means the Method that is returned has a different Action than the Action it will be invoked upon.

I know that probably sounds confusing as hell. I'm not sure how to make it clearer. Here is the error message I get when calling method.invoke(action, new Object[0]);

212719 [http8080-Processor25] ERROR
com.opensymphony.webwork.dispatcher.ServletDispatcher - Could not execute action
java.lang.IllegalArgumentException: object is not an instance of declaring class
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39
)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl
.java:25)
        at java.lang.reflect.Method.invoke(Method.java:324)
        at
com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInv
ocation.java:304)
        

I resolved the issue in my local code base by having the
ActionConfig.getMethod() call take Action as a parameter. It is only called from DefaultActionInvocation.invokeAction(), so this is no problem.

Since ActionConfig caches the method call between requests, I needed to defeat the caching of methods when the Actions are different classes. I did this by hanging on to the Action in ActionConfig between calls to getMethod(Action). If the action is not an instance of the prior stored action, I eject the method. I can attach some patches if this seems like a reasonable approach.

Not sure how this affects the ActionConfig. All the unit tests pass anyway, and it solves the mismatch in the invokeAction method.