OSGi

[Peter Firmstone <ji...@zeus.net.au>]

All this talk of OSGi has probably got some people worried, don't worry, 
I'll create an experimental area on svn for the OSGi side of things, so 
you can dip your toes in first.

I have no intent of trying to map OSGi services to Jini Services or vice 
versa. 

I'd only be utilising the basic OSGi framework, so there wouldn't be any 
further dependencies to worry about, I'd include it all in the one 
download archive.  That would keep the different services models 
separate, as they should be, to be used where each service type makes 
sense. OSGi Services for local JVM services, as it is used now and Jini 
Services for remote, as I said I wont attempt to map these services as 
their intended purpose and design is different and specific for each 
niche.  You wouldn't try to map an SPI interface directly to a Jini 
service and vice versa, so why do it with OSGi.

The OSGi service registry is used to look up an OSGi service by its 
fully qualified class name.  In Jini you must match all the interfaces 
in a ServiceItem.  If you try using OSGi service semantics in remote 
services, you'll run into all sorts of problems with the visibility of 
interface inheritance hierachy's, ClassLoader visibility, unrecognised 
required dependency's and class not found exceptions.  This would occur 
because you don't know all the interfaces the proxy class must support, 
interfaces which must be visible to the proxy at the client at load 
time.  I know this from issues other projects have had with OSGi and 
reflective proxies and my own experiences with ClassLoader's

OSGi currently has the Oscar Bundle Repository, which is a http or https 
codebase.  I'm thinking of modifying this to utilise a Jini Service to 
download java bundles from.  This will allow codebase services to be 
discovered at runtime.

Cheers,

Peter.