RMI ClassCastException RmiInvocationWrapper_Stub

[Phlebiac]

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:
<bean id="serviceExport" class="org.springframework.remoting.rmi.RmiServiceExporte r">
<!-- <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:
DataServiceInterface dsi = (DataServiceInterface) Naming.lookup("rmi://myHost/DataService")

What I get is:

java.lang.ClassCastException: org.springframework.remoting.rmi.RmiInvocationWrap per_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.

[Andreas Senft]

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

[Phlebiac]

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.

[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

[Phlebiac]

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.

[Andreas Senft]

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

[itstarting]

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.

[Andreas Senft]

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

[warrenjm]

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.

[Andreas Senft]

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

[fschroder]

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.