I have an old implementation of remote classloading for one of the initial 
server implementations.  Might help you get some ideas:

Basically this class served as the InitialContextFactory:
 - 
http://cvs.openejb.org/viewrep/openejb/openejb-sfnet/src/facilities/org/openejb/ri/server/RiInitCtxFactory.java?r=1.5

It plays a trick by loading the Context implementation from a network enabled 
classloader:
 - 
http://cvs.openejb.org/viewrep/openejb/openejb-sfnet/src/facilities/org/openejb/ri/server/RiClassLoader.java?r=1.5

Then anything deserialized by the Context implementation use the network 
enabled classloader as per normal classloading rules.

A little old and crufty, but used to work.  Our clients are bit different in 
the app client scenario, but similar tactics should be possible.  The cool part 
about it was that you only needed three classes in your client jar.  The rest 
would be downloaded from the server.  Very handy for keeping the client and 
server speaking the same version of the ejb protocol, even after a server 
upgrade.

-David

On Sat, Mar 26, 2005 at 05:50:05PM +1100, Gianny Damour wrote:
> Thanks for that David!
> 
> I have just checked in support for bit masking of IP addresses.
> 
> I am currently investigating the OpenEJB protocol to see how to hook 
> IIOP stub dowloading and more generally remote class loading.
> 
> Gianny
> 
> On 26/03/2005 12:11 AM, David Blevins wrote:
> 
> >Excellent, Gianny!
> >
> >That's been on my todo list for quite some time.  If you want another 
> >little chunk to do, you can rework the ServiceAccessController to make it 
> >implement actual bit masking of IP addresses rather than a straight equals.
> >
> >-David
> > 
> >

Reply via email to