Announcement Announcement Module
Collapse
No announcement yet.
RMI ClassCastException RmiInvocationWrapper_Stub Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • 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
    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

    Comment


    • #3
      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.

      Comment


      • #4
        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

        Comment


        • #5
          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.

          Comment


          • #6
            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

            Comment


            • #7
              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.

              Comment


              • #8
                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

                Comment


                • #9
                  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.

                  Comment


                  • #10
                    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

                    Comment


                    • #11
                      Hi, I'm a little late in this thread, but I'd like to say that this case is clearly explained in the remote section of the spring reference (coupling with spring in the client, etc.).
                      As Andreas says, it might be better to unwrap the service exposing it through plain RMI to allow non spring clients to connect normally.

                      Federico.

                      Comment

                      Working...
                      X