InvocationTargetException using HttpInvoker

[mark_in_gr]

I am attempting to access a method within a remote interface using HttpInvoker. However, I get an java.lang.reflect.InvocationTargetException exception.

Here is the relevant portions of the stacktrace:

java.lang.reflect.InvocationTargetException
        . . .
Caused by: java.lang.reflect.UndeclaredThrowableException
        at $Proxy21.setFilterState(Unknown Source)
        at com.xrite.ind.core.GroupTreeView.StandardNode.updateSampleCount(StandardNode.java:88)
        at com.xrite.ind.core.GroupTreeView.StandardNode.<init>(StandardNode.java:64)
        ... 53 more
Caused by: java.lang.NoSuchMethodException: $Proxy6.setFilterState(com.xrite.ind.backcheck.filter.IFilterState)
        at java.lang.Class.getMethod(Class.java:1605)
        at org.springframework.remoting.support.RemoteInvocation.invoke(RemoteInvocation.java:203)
        at org.springframework.remoting.support.DefaultRemoteInvocationExecutor.invoke(DefaultRemoteInvocationExecutor.java:38)
        at org.springframework.remoting.support.RemoteInvocationBasedExporter.invoke(RemoteInvocationBasedExporter.java:76)
        at org.springframework.remoting.support.RemoteInvocationBasedExporter.invokeAndCreateResult(RemoteInvocationBasedExporter.java:112)
        at org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter.handleRequest(HttpInvokerServiceExporter.java:117)
        at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(HttpRequestHandlerAdapter.java:47)
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:820)
        . . .

Question regarding the highlighted elements above; why does the UndeclaredThrowableException occur on $Proxy6 while the other refers to $Proxy21?

Does this have something to do with the method signature being called including an argument? Does this argument need to be set up within the HttpInvokerProxyFactoryBean client side and HttpInvokerServiceExporter server side bean declarations?

Here is the client side Spring context declaration file bean def:

<bean id="colorCriteraDao" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
      <property name="serviceUrl" value="http://localhost:8080/remoting/httpColorCriteraDao"/>
      <property name="serviceInterface" value="com.xrite.ind.backcheck.filter.IColorCriteraCreator"/>
      <property name="httpInvokerRequestExecutor">
	<bean class="org.springframework.remoting.httpinvoker.CommonsHttpInvokerRequestExecutor"/>
      </property>

Here is the factory class code which grabs the bean from the client Spring context:

public static IColorCriteraCreator getColorCriteraCreator()
    {
        return (IColorCriteraCreator) beanFactory.getBean("colorCriteraDao");
    }

Here is the client side code which obtains the bean via the proxy and calls the method:

IColorCriteraCreator crit = ClientFactoryImpl.getColorCriteraCreator();
        IFilterState fs = MainWindow.getInstance().getApp().getFilter();        
          crit.setFilterState(fs);

Here is the server side proxy exporter declaration in remoting-servlet.xml:

<bean name="/httpColorCriteraDao" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">
      <property name="service">
          <ref bean="colorCritera"/>
      </property>
      <property name="serviceInterface" value="com.xrite.ind.backcheck.filter.IColorCriteraCreator"/>      
    </bean>

Here is the applicationContext.xml server side settings which define the DAO beans referenced by remoting-servlet.xml

<bean id="colorCritera" class="com.xrite.ind.backcheck.filter.ColorCriteraCreator" >
        <property name="sessionFactory" ref="backcheckSessionFactory" />    
    </bean>

And here are the DAO Interface and Impl classes:

public interface IColorCriteraCreator
{    
    void setFilterState(IFilterState filterState);
    
}

public class ColorCriteraCreator implements IColorCriteraCreator
{
public void setFilterState(IFilterState filterState)
    {
        this.filterState = filterState;
    }
}

[mark_in_gr]

It seems that when the same method is called without an argument, this works. Also, when I have interface method calls on similar methods which accept a generic Object class instance, and this also works. However, when I pass an instance of one of my objects, I get the InvocationTargetException.

Does anyone know how to properly set up HttpInvoker Remoting to allow objects as arguments?

[jwray]

Mark,

All my service methods pass objects and they don't need special configuration. That's not your problems (although I don't use CommonsHttpInvokerRequestExecutor).

Try deleting the work directory under the jetty dir and rerunning. When I have strange classpath issues it's the first thing I do and it usually works.

Jonny

[mark_in_gr]

Try deleting the work directory under the jetty dir and rerunning. When I have strange classpath issues it's the first thing I do and it usually works.

Jonny

Is this still necessary when I am running Jetty embedded in my app?

[jwray]

Mark,

Not sure, I've never run embedded and I don't run from exploded directory structures, so I don't know for sure if jetty creates a working directory in these situations, but I'd guess so.

The problem I've come across occurs when you change versions of a library. When jetty creates the working dir it does not delete the old contents first, it just overwrites what is already there. Thus, old libraries and class files can easily be left on the classpath if nothing overwrites them in the current version. This has been the cause of every strange error of the sort you're seeing (eg NoSuchMethodException). When I see such errors I now assume I have conflicts on my classpath (ie old and new versions of the same class) and this jetty working directory is an easy was to be caught with such conflicts.

Took me 3 days to figure this out the first time it happened. Application worked on my test server but not the production, which should have been identical. Fun week that was.

Jonny

[mark_in_gr]

Ok . . . I removed the jar file which contained all the interfaces and impl classes from the WAR's WEB-INF/lib directory, and things now appear to be working. Let me explain a little better what I am trying to accomplish.

I have a Swing Client which I want to be able to have access to remote DAOs/Services by way of HttpInvoker. The client code must, of course, have as a dependency the interfaces exposed by the HttpInvokerProxyFactoryBean, while the actual DAO interfaces and impl classes, of course, need to be included within the web app. So, I simply used the same jar file as a dependency to both the client code and the web app.

The problem seems to be the fact that I am embedding Jetty from the same JVM as my client is running. The reason I wanted to actually go through the same Jetty/Web app mechanism when I run in pure standalone client mode as opposed to ONLY doing this when the client hits the remote version(the same web app running on a remote networked server) was to minimize refactoring on the client side. I felt that it would simply be a configuration issue by changing the value of the serviceUrl from, say, localhost, to the actual remote server host name.

There must be a way to do this. I guess I could have to separate build processes for the WAR file; one that includes the DAO/Service jar dependency in lib(for pure standalone) and one that does not.

Mark