As for remote interfaces, the client should already be able to access these. As for stubs, these can be auto generated and compiled on the client side or some form of proxying can be used to avoid stub generation. Stubs will implement the remote interface.
I have seen other vendors either place server specific stubs into a client side jar or the client side name service could download them from an http server that is running within the app server.
Mark
Dain Sundstrom wrote:
On Mar 17, 2005, at 6:06 PM, Alan D. Cabrera wrote:
[EMAIL PROTECTED] wrote:
That sounds pretty cool. What do you think Mark?Hi,
I would like to know if it would be helpful to have a RMI class server.
Currently, I see two potential usage:
* deployment: currently, we need to be carefull about the exceptions nested within
DeploymentException otherwise we will get a ClassNotFoundException. As a matter of
fact, by installing a security manager and with the correct policy file, "local
deployments" work properly. Indeed, as the ClassLoader used under the cover by
Configuration is a URLClassLoader, marshalled classes are "properly" annotated.
* IIOP: here I guess that we will need to download the stubs somehow to the clients.
If you think that this is a good thing to have, then I am happy to get it working
I think it would bee cool to have remote class loading, but I'm not sure about using the RMI wire protocol for this. I would expand the OpenEJB protocol to support remote class loading, and I believe IIOP has special hooks to do remote class loading javax.rmi.CORBA.Util, which in OpenEJB delegates to org.openejb.corba.util.UtilDelegateImpl.
-dain
.
