incubator-projects mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <>
Subject Re: Altrmi: additional facades not working
Date Thu, 27 Mar 2003 13:13:30 GMT
 --- Peter Klotz <> wrote: > Hi Paul,
> > What is not an interface(facade) must be serializable. Exceptions should
> > be OK. Is the exception in question a derivative of RuntimeException?
> It was not it inherited from Exception but now I made it inherit from
> RuntimeException.

OK, or delcare it in the interface method sig...
> > Did you get to change the order of the additional facades (most derived
> > types first), in the publish() method call?

> I did: SIMONException, OVException, SIMONMessageGroup, SIMONObject
> So the super-class last.

OVException is new right? I am guessing it should not be an additional facade, but instead
serializable exception.

> What about the order when I have a interface that includes methods that
> return another interface e.g. SIMONUserResps return in a method
> SIMONMessageGroup.

You mean ..

  interface SIMONMessageGroup {
    SIMONUserResps foo();
The order is for interfaces of increasingly derived types.  Most derived types first.  Can
send me teh source to the interfaces?

> Do I have to have SIMONMessageGroup before any interface that uses it?
> I tried to place it like this.

It is about derivation not usage.

> SIMONException is the exception that is used in the SIMONDataSource main
> interface, OVException is thrown in some of the objects that are used
> there such as SIMONMessageGroup. both inherit now from RuntimeException. I
> do not directly implement Serializable so far.

I need to see the source dude, I am getting increasingly lost here.

> Well but it didn't help.
> Still same behaviour, empty return value works, real object return value
> does not (NullPointerException).
> There is one thing that you should know, the actual classes that implement
> the SIMON* interfaces use JNI also the OVException. I suppose that as I'm
> using ClientSideClassFactory there are no implementation class objects
> transfered to the client side from the server or? 

correct.  JNI is fine on the server side.

> Because the client does
> not have the C lib that is used by the JNI on the server-side.

> Altrmi only transfers interfaces to te client side, right?

Not even. For the moment all the interfaces and dependant value objects and exception must
be in teh client side VMs classloader.  The proxies (stubs) can be sent on demand. for that
they can be created on demand.

> I had problems with the ServerSideClassFactory so I hope I don't need it.
> I'd rather use the pre-generated Proxy classes on the client side
> directly.

Is often easier.  EOB uses server side, but it is an advanced use of AltRMI.


- Paul

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message