Announcement Announcement Module
No announcement yet.
HttpInvoker with complex objects as parameters fails Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • HttpInvoker with complex objects as parameters fails

    I'd like to use HttpInvoker as an alternative to RMI due to firewall.

    Using Jetty I get NoSuchMethodExceptions when calling a remote method using complex objects as parameters. Using the same configuration etc. with a method only having Strings for example as parameters ... the whole show rocks!

    The complex object I want to transfer as parameter directly inherits from Serializable. I do not override toString() method. Just plain ... as to start making this remoting work.

    By the way, using RMI locally it also works with my complex objects. BTW, Is HttpInvoker a true alternative to RMI???

    Here my example interface:

    public List searchAccount(Account account);

    public List searchAccount(String accountId);

    public List searchAccount();

    Please help

    Many thanks,

    PS: Am using the latest Spring 1.2 RC1

    PPS: Here the cause for my exception:

    Caused by: java.lang.NoSuchMethodException: $Proxy0.searchAccount(org.test.model.Account)
    at java.lang.Class.getMethod(Unknown Source)
    at ion.invoke(
    at InvocationExecutor.invoke(DefaultRemoteInvocationE
    at ionBasedExporter.invoke(RemoteInvocationBasedExpor
    at ionBasedExporter.invokeAndCreateResult(RemoteInvoc
    at org.springframework.remoting.httpinvoker.HttpInvok erServiceExporter.handleRequest(HttpInvokerService
    at org.springframework.web.servlet.mvc.SimpleControll erHandlerAdapter.handle(SimpleControllerHandlerAda
    at org.springframework.web.servlet.DispatcherServlet. doDispatch(
    at org.springframework.web.servlet.DispatcherServlet. doService(
    at org.springframework.web.servlet.FrameworkServlet.s erviceWrapper(
    at org.springframework.web.servlet.FrameworkServlet.d oPost(
    at javax.servlet.http.HttpServlet.service(HttpServlet .java:760)
    at javax.servlet.http.HttpServlet.service(HttpServlet .java:853)
    at org.mortbay.jetty.servlet.ServletHolder.handle(Ser
    at org.mortbay.jetty.servlet.WebApplicationHandler.di spatch(
    at org.mortbay.jetty.servlet.ServletHandler.handle(Se
    at org.mortbay.http.HttpContext.handle(HttpContext.ja va:1723)
    at org.mortbay.jetty.servlet.WebApplicationContext.ha ndle(
    at org.mortbay.http.HttpContext.handle(HttpContext.ja va:1673)
    at org.mortbay.http.HttpServer.service(HttpServer.jav a:879)
    at org.mortbay.http.HttpConnection.service(HttpConnec
    at org.mortbay.http.HttpConnection.handleNext(HttpCon
    at org.mortbay.http.HttpConnection.handle(HttpConnect
    at org.mortbay.http.SocketListener.handleConnection(S
    at org.mortbay.util.ThreadedServer.handle(ThreadedSer
    at org.mortbay.util.ThreadPool$

  • #2
    I'm having exactly the same problem. Guess it requires a very simple solution. So please reply.




    • #3
      Could you share your configuration? A few things to check (off the top of my head):
      - Be sure the same version of the service interface is used on both the client and the server sides.
      - Be sure the same version of the parameter objects is used on both the client and the server sides.
      - Be sure you are setting the correct interface for the "serviceInterface" property when defining your HttpInvokerServiceExporter bean. Make sure it matches the interface you set for the "serviceInterface" property when you set up your "HttpInvokerProxyFactoryBean" on the client side.
      - Be sure your client is connecting to the right server.

      - Andy


      • #4
        It does sound like it might be an issue with the versions of the service interface being inconsistent - particularly if you're saying the searchAccount(String) method works.

        I did some benchmarking over the weekend with HttpInvoker and used a method call that took a List as parameter. The list contained about 30 String objects and 6 domain objects (themselves with various types of attributes). This worked fine - don't know if your object graph is significantly more complex than that but I think if complexity was an issue you'd get some exception from the underlying serialization and not the one you're actually getting.



        • #5
          Did anyone ever figure this one out?

          I have the same problem.

          It works in Weblogic and Oc4j, but I receive the same error in Tomcat. In all instances, I had to put the "DTOs" in the server classpath.

          It seems that in tomcat, the service doesn't recognize the DTO object. I wonder if it has anything to do with the serialVersionUID... Maybe the the codebaseUrl attribute can be a workaround?
          Last edited by hozo; Feb 4th, 2006, 07:06 PM.


          • #6
            Ok, fixed it.

            For anyone else having the same problem...

            I included the Serializable in both the .war and the jar (placed in the server classpath).

            Weblogic and oc4j's classloader must be looking at the server classpath 1st and war/lib 2nd or something. So the client and server always used the same "DTO" class.

            Tomcat's classloader looks at the war first then the server common lib. My client uses the DTO from the jar. Tomcat saw it as a different class. Thus, it could not find the method signature and threw a NoSuchMethodException.

            Solution: remove DTO class from war and place only in jar. put jar in server classpath/commonlib