+1 on using OSGi. Having a completely decoupled service like OSGi
handle dependencies is a great idea and I think that soon all the
major players in the application and service container solution spaces
will have finished the integration of OSGI into their systems.
Perhaps the 'vision' of JiniNextLevel is all about better integration
especially in terms of classloading (which I must say accounts for a
fair bit of problems in many cases). I have previously promoted
embracing OSGi as the classloading model used, but that went pretty
much on deaf ears before. I still think it makes sense, but won't put
up a fight over it again, and probably doesn't solve container
integration for now.
OSGI has a classloader model similar to Jini's (highly granular and
compartmentalized, possibly better documented as well) and one might
indeed manage a port to that model but any container that doesn't do
OSGI will still not work right. I have seen similar approaches to Ron
Mann's to solve this OSGI/Container integration problem via a bridge
servlet. So I guess if you ported Jini to that model you could save
yourself a package (Ron's) but that's about it.
Michael McGrady
Senior Engineer
Topia Technology, Inc.
1.253.720.3365
mmcgr...@topiatechnology.com
