Have you tried using reflection to dump all the interfaces (and
corresponding classloaders) the action implements? Obviously, this
shouldn't be possible under normal circumstances...
Or if you're using maven 2, try running the app with the maven jetty
plugin (or if you're not, deploy to a different web container) and see
if the same thing happens.
Nils-H
On Fri, Jan 30, 2009 at 4:48 PM, Andy Sykes <a.sy...@ucl.ac.uk> wrote:
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
