I'd love to zip up the whole project and stick it somewhere but it's
pretty dependent on the environment I'm running it in (LDAP server for
auth, etc etc). I could probably produce a neutered version of it
that'll run anywhere, but it'll take a while as it's quite big..
As for classloaders, here's my debug statements:
log.info("ParseInterceptor's class loader is:" +
ParseInterceptor.class.getClassLoader().toString());
log.info("Action's class loader is: " +
action.getClass().getClassLoader().toString());
log.info(action.getClass().getClassLoader() ==
ParseInterceptor.class.getClassLoader());
And the output:
INFO ParseInterceptor - ParseInterceptor's class loader
is:WebappClassLoader
delegate: false
repositories:
/WEB-INF/classes/
----------> Parent Classloader:
org.apache.catalina.loader.standardclassloa...@fa7e74
15:36:08,198 INFO ParseInterceptor - Action's class loader is:
WebappClassLoader
delegate: false
repositories:
/WEB-INF/classes/
----------> Parent Classloader:
org.apache.catalina.loader.standardclassloa...@fa7e74
15:36:08,198 INFO ParseInterceptor - true
Suggests to me they're getting loaded by the same classloader.
Something bloody funky is going on and I'm probably going to just roll
the interceptors functionality into an action instead, but
intellectual curiosity remains to be satisfied as to what the funk is
causing this.
Cheers for the help,
Andy.
On 30 Jan 2009, at 15:03, Dave Newton wrote:
If you have a small project you could host somewhere that might
help, or just zip up all the source. Clearly this can't happen
(ignoring for the moment that it is), but the framework obviously
relies on this working so I'd have to assume something funky is
going on.
Dave
Andy Sykes wrote:
I dug around in the ServletConfig interceptor and modified my code
to mimic how it handles this situation - retrieve the Action as an
Object type, test for instanceof <Interface>, the cast to it. For
some reason, that still does not work.
As a test case, I'm mimicking the code exactly. My action extends
ActionSupport and implements SessionAware.
In the interceptor, I retrieve the action as an Object, test if
it's an instanceof SessionAware, then cast. Logging statements show
that the cast never happens. If I try to skip the test and cast
directly, I get a CCE. However, the ServletConfigInterceptor is
able to do exactly the same thing without getting a CCE.
Either there's some messed up going on in my dev environment, or
I'm being really dumb, or.. god knows. I've cleared out all the old
libraries and I'm just running with the bare essentials.
Test case:
public class ParseInterceptor extends AbstractInterceptor {
private static final Logger log =
Logger.getLogger(ParseInterceptor.class);
@Override
public String intercept(ActionInvocation invocation) throws
Exception {
final Object action = invocation.getAction();
if (action instanceof SessionAware) {
log.error("Action is an instance of SessionAware.");
}
return invocation.invoke();
}
}
For reference, the relevant sections in the ServletConfigInterceptor:
public class ServletConfigInterceptor extends AbstractInterceptor
implements StrutsStatics {
public String intercept(ActionInvocation invocation) throws
Exception {
final Object action = invocation.getAction();
final ActionContext context =
invocation.getInvocationContext();
...snip...
if (action instanceof SessionAware) {
((SessionAware)
action).setSession(context.getSession());
}
}
}
On 30 Jan 2009, at 12:22, Andy Sykes wrote:
No, I don't 'need' the cast to Action. However, if I cast what I
get back from ActionInvocation.getAction() straight to
SessionAware or similar, it still chucks a CCE.
I'm using Netbeans, and I'm pretty sure there's no crazy stuff
going on with the classloader - all my struts jars are in my
context's lib directory.
On 30 Jan 2009, at 11:57, Nils-Helge Garli Hegvik wrote:
Do you really need the first cast to Action? Anyway, could it be
that
you're having conflicting struts and/or application jars several
places in your classloader hierarchy? That could explain certain
"should never happen" incidents...
Nils-H
On Fri, Jan 30, 2009 at 12:39 PM, Andy Sykes <a.sy...@ucl.ac.uk>
wrote:
Hi Wes,
No, I'm not using Spring at all.
The Action never passes the test of being an instanceof
Parseable. If I make
the action only implement SessionAware, and test if my action is
an
instanceof SessionAware, the test is never passed!
Colour me confused!
Andy.
On 30 Jan 2009, at 00:55, Wes Wannemacher wrote:
On Thursday 29 January 2009 19:49:39 Andy Sykes wrote:
Hi all,
I've written an interceptor with a PreResultListener that gets
the
action with ActionInvocation.getAction(), then casts it to an
interface ("Parseable", in this case). This lets me call a
particular
method on the action just prior to the result being rendered.
The action implements Parseable and SessionAware.
When I do the cast, I get an ClassCastException for
com.opensymphony.xwork2.ActionSupport. If I take it down to one
interface (SessionAware) and cast the action to it, I still
get a CCE.
What's weirder is I'm pretty sure this code worked on Struts
2.0.11.
Here's a suitably simplified version of what I'm attempting to
do:
public String intercept(ActionInvocation invocation) throws
Exception {
invocation.addPreResultListener(new PreResultListener() {
public void beforeResult(ActionInvocation invocation,
String resultCode) {
Action action = (Action)invocation.getAction();
if (action instanceof Parseable) {
((Parseable)action).parse();
}
}
});
Any ideas what the hell is going on here?
Is it possible that you are using Spring to instantiate your
actions via
the
Spring plugin? It would seem that if the action passes the
test, then the
cast
is legal. I ask about Spring in case the action is a proxied
bean... It
comes
up from time to time that Spring created beans don't always
seem to
inherit
every method that you would think... If Spring is in the mix,
try having
Spring use CGLIB... I've had some luck that way, vs. dynamic
JDK proxies.
-Wes
--
Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh
and more
http://www.manning.com/wannemacher
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
