Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: RMI ClassCastException RmiInvocationWrapper_Stub

  1. #1
    Join Date
    Jan 2006
    Location
    Hamburg, Germany
    Posts
    19

    Default RMI ClassCastException RmiInvocationWrapper_Stub

    Hi,
    I have a project which is exposing an RMI-Service (Pojo) via Spring. Another project is trying to get Access to this service but not using Spring.

    Service:
    Code:
    <bean id="serviceExport" class="org.springframework.remoting.rmi.RmiServiceExporter">
    		<!-- <property name="registry" ref="rmi.registry"/>-->
    		<property name="serviceName" value="DataService"/>
    		<property name="service" ref="dataService" />
    		<property name="serviceInterface" value="de.idon.bo.dataService.DataServiceInterface"/>
    		<!-- defaults to 1099 
    		<property name="registryPort" value="1199"/>-->
    	</bean>
    Access:
    Code:
    DataServiceInterface dsi = (DataServiceInterface) Naming.lookup("rmi://myHost/DataService")
    What I get is:
    Code:
    java.lang.ClassCastException: org.springframework.remoting.rmi.RmiInvocationWrapper_Stub
          at rmitester.main(rmitester.java:28)
    I have no other idea how to access the exposed RMI-service. What am I doing wrong that I don't get my DataServiceInterface-Object?

    Thanks for helping.

  2. #2
    Join Date
    Aug 2004
    Posts
    2,715

    Default

    If the bean you are exporting is no valid remote bean (i.e. implementing Remote, all methods declare throwing RemoteException), it can still be exported by Spring. However, in that case you can only retrieve it via Spring on the client side.

    Regards,
    Andreas

  3. #3
    Join Date
    Jan 2006
    Location
    Hamburg, Germany
    Posts
    19

    Default

    I see.
    So my Pojo is 'surrounded' by an object which enables my to expose it as an RMI-service.
    I am wondering wether there might be a way to get my Pojo out of the wrapper_stub on the client side.
    Other solution would be using Spring. But this is the last option.

  4. #4
    Join Date
    Aug 2004
    Posts
    2,715

    Default

    I wonder why you refrain from using Spring on the client side?
    If you use dependency injection, your code would not even realize, that remoting takes place.

    If you do not want to use Spring, I think you have to either make your bean rmi-capable or have a look at how spring handles the wrapping behind the scenes and reimplement it yourself.

    Regards,
    Andreas

  5. #5
    Join Date
    Jan 2006
    Location
    Hamburg, Germany
    Posts
    19

    Default

    Quote Originally Posted by Andreas Senft
    I wonder why you refrain from using Spring on the client side?
    If you use dependency injection, your code would not even realize, that remoting takes place.

    If you do not want to use Spring, I think you have to either make your bean rmi-capable or have a look at how spring handles the wrapping behind the scenes and reimplement it yourself.

    Regards,
    Andreas
    I don't refrain from using Spring. But I am the one who has to convince his colleague to use it and as long as he is not willing to use Springs dependency injection but wants to use my RMI-Service we have a problem. He is complaining that using Spring makes him dependent on Spring.
    I will keep on trying to convince him.

  6. #6
    Join Date
    Aug 2004
    Posts
    2,715

    Default

    Quote Originally Posted by Phlebiac
    He is complaining that using Spring makes him dependent on Spring
    Well, that is not completely wrong. There has to be a compromise. Either to rely on Spring's services and have clean service interfaces or to not use Spring but bind yourself on RMI remote interfaces.
    Some dependencies are just necessary. The point is to make a good choice.

    Hope you manage to convince your colleague.

    Regards,
    Andreas

  7. #7
    Join Date
    Feb 2006
    Posts
    3

    Default

    I think we have to wrap somethine like spring if we don't want to build a none-spring-based client.

    In fact, there are lots of history apps not using spring,spring should supply alternative client solusion maybe.

  8. #8
    Join Date
    Aug 2004
    Posts
    2,715

    Default

    Actually Spring itself serves as a wrapper which allows you to abstract from remoting technology for example.

    I fail to see the benefit of wrapping the wrapper. In fact I have seen projects in trouble because of too much wrapping and abstracting.

    What kind of alternative client solution do you have in mind?

    Just my 2 cents,
    Andreas

  9. #9
    Join Date
    Jan 2007
    Posts
    1

    Default

    What kind of alternative client solution do you have in mind?
    Not sure if it is going to work yet, but invoking an RMI call from an Oracle Java Stored Procedure is a solution that I am trying to make work right now.

  10. #10
    Join Date
    Aug 2004
    Posts
    2,715

    Default

    Well, if the target object in your case is exposed via Spring I would indeed use a plain normal Remote object. This could be accessed in normal ways without using Spring classes.
    (Though I never did RMI in Java Stored Procedures, so I do not know if this works at all)

    Regards,
    Andreas

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •