RMI classloading

[gi...@optusnet.com.au]

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.

Thanks,
Gianny

Re: RMI classloading

[Jeremy Boynes <jb...@apache.org>]

Dain Sundstrom wrote:
> On Mar 18, 2005, at 2:42 PM, Jeremy Boynes wrote:
> 
>> Dain Sundstrom wrote:
>>
>>> 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.
>>
>>
>> I think we should start with the most basic as RMI classloading is 
>> built into the VM and that is what we are using by default for JMX 
>> remoting.
> 
> 
> I think we should stop using RMI there also.
> 

RMI is the only JMX remoting protocol required by the spec - anything 
else is going to impose additional dependencies on anything that wants 
to talk to the server. We can obviously support additional protocols but 
we should continue to support the basics.

--
Jeremy

Re: RMI classloading

[Dain Sundstrom <ds...@gluecode.com>]

On Mar 18, 2005, at 2:42 PM, Jeremy Boynes wrote:

> Dain Sundstrom wrote:
>> 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.
>
> I think we should start with the most basic as RMI classloading is 
> built into the VM and that is what we are using by default for JMX 
> remoting.

I think we should stop using RMI there also.

> Everything else would add additional dependencies on the client.
>
> That's not to say we shouldn't add it to the other protocols, just 
> that we need the lowest common denominator.

The problem is we need to know the target GBean to load retrieve the 
class from so plain old RMI class loading isn't going to work...  well 
I suppose you could use the lame vm annotation stuff.  Anyway, I just 
don't think using RMI is a good option for a real server.

-dain

Re: RMI classloading

[Jeremy Boynes <jb...@apache.org>]

Dain Sundstrom wrote:
> 
> 
> 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.
> 

I think we should start with the most basic as RMI classloading is built 
into the VM and that is what we are using by default for JMX remoting.
Everything else would add additional dependencies on the client.

That's not to say we shouldn't add it to the other protocols, just that 
we need the lowest common denominator.

--
Jeremy

Re: RMI classloading

[Mark <de...@hotmail.com>]

The nested exception case is interesting since there is value in 
recreating an exception on the client side.  From what I recall, Corba 
does not have a standard way a sending back an arbitrary server 
exception to the client.

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:
>
>> gianny.damour@optusnet.com.au wrote:
>>
>>> 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
>>>
>> That sounds pretty cool. What do you think Mark?
>
>
> 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
>
>
> .
>

Re: RMI classloading

[Dain Sundstrom <ds...@gluecode.com>]

On Mar 17, 2005, at 6:06 PM, Alan D. Cabrera wrote:

> gianny.damour@optusnet.com.au wrote:
>
>> 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
>>
> That sounds pretty cool. What do you think Mark?

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

Re: RMI classloading

["Alan D. Cabrera" <ad...@toolazydogs.com>]

gianny.damour@optusnet.com.au wrote:

>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
>
That sounds pretty cool. What do you think Mark?


Regards,
Alan