problems with interface within EJB remote interface

[Jurjen van Geenen]

Hi,

I have an ejb remote interface that uses interfaces for some of the return types of its methods like ValueType1Iface below;

public ValueType1Iface doSomething();

I also have an implementating class ValueType1Impl at the server side. Now if I include the implementation in the ejb-client jarfile, everything runs fine. If I exclude the file, I get the following error;

=========== Caused by ================
java.rmi.MarshalException: CORBA MARSHAL 0x4942f89a No; nested exception is:
org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : null vmcid: IBM minor code: 89A completed: No
at com.ibm.CORBA.iiop.UtilDelegateImpl.mapSystemException(UtilDelegateImpl.java:204)
at javax.rmi.CORBA.Util.mapSystemException(Util.java:84)
at nl.kvk.service.zoja._TstProviderServiceSessionFacade_Stub.getValue1(_TstProviderServiceSessionFacade_Stub.java:442)
at nl.kvk.service.zoja.TstProviderServiceEJBChannel.getValue1(TstProviderServiceEJBChannel.java:23)
at nl.kvk.service.zoja.TstConsumer.main(TstConsumer.java:43)
Caused by: org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : null vmcid: IBM minor code: 89A completed: No
at com.ibm.rmi.iiop.CDRInputStream.read_value(CDRInputStream.java:1855)
at nl.kvk.service.zoja._TstProviderServiceSessionFacade_Stub.getValue1(_TstProviderServiceSessionFacade_Stub.java:431)
... 2 more
============End cause=================

Cananyone help? I tried installing an 'allow all' securitymanager, this didn't help. I'm using websphere 5.1, IBM JDK 1.4.2. on both the client and server.

Thanks in advance,

Jurjen van Geenen

[Marco Barenkamp]

Hi,

You have to deliver the implementation class on the client side.
Otherwise, the returned value cannot be deserialized.

Example:
The remote client VM gets an object of class PersonImpl that implements Person. If you only provide the Person interface on the clientside, the
object cannot be unmarshalled (deserialized).
Therefore, you need PersonImpl.

In general, that is no problem, because you are responsible for both sides. But you might ask, what about a non java client or what about when you don't know the exact class on the server?

Corba provides a solution for these questions. If you would use Corba,
the Corba framework would generate an empty PersonImpl class for you. This class
is just a template and you must fill in some neccessary code like attributes and/or getter/setter, for example.
But nevertheless , the clientside would provide the PersonImpl class in that way. That's the usual way.

Veel plezier. Groetjes :-)
[ August 04, 2005: Message edited by: Marco Barenkamp ]

[Isaac Shabtay]

I am experiencing exactly the same problem, and I agree with what mentioned above.

The EJB specification states that all classes & interfaces required in the client's side of things - be available for the client. Now, mind you, RMI *does* support downloading "remote" classes through the wire. However, EJB apparently doesn't use this feature, regardless of your JVM's security settings (RMI requires a SecurityManager to be installed, with specific permissions to allow remote code download).

In my opinion this is a strong deficiency in the EJB specification. The client-JAR should contain only the client-side of things. A true separation between interface to implementation can only be achieved if the implementation classes are NOT included in the client JAR. This deficiency causes us some good headaches. I am surprised, and disappointed, to see that not a lot has been done in order to mitigate this deficiency.

At least, we would expect WebSphere Application Server to give us some useful indication as to what happened... WebSphere 5.0 didn't even throw an exception! It would just treat the value as "null".

If you found any workaround, please let me know as I'd be happy to know about it.


Cheers.


Isaac