Hi David, Rob
I have not used bundle fragments personally, but I can see how it is a clever
solution. Presumably, the fragments get hitched to the core bundle and thus
share its loader so that all other bundles see it as one bundle on one loader?
In my own code, I decided to put all the osgi service references in a separate
bundle. I use compendium stuff and dealing with some of it with error handling
& reporting is quite messy, probably in part because I don't fully understand
what I am doing. All my other bundles then refer to this and can worry less
about errors and at least know that any misunderstandings are collected in one
place. I do see the requirement not to pollute Restlet with OSGi calls which
are irrelevant to mainstream users. There are some things, I gather, that just
don't work well or at all with OSGi. One seems to be finding Restlet
extensions. Could it be made into an Interface (perhaps it already is?) and
then have a default implementation searching META-INF/services and somehow
provide for hitching in an alternative OSGi implementation?
I don't know how many of these show-stopper OSGi issues exist. Would be
worthwhile gathering them concisely in one place with room for (a) ideal
solution (b) workarounds.
I worked a bit with Knopflerfish committers as I had a problem using KF
GWT-Http-Service which was a wrapper around HttpService to do classLoader
switching. Deep down in RPC reflection-based serialisation GWT would switch
loaders and not get the right one for OSGi. I can't really remember all the
details now, but I recall fuzzily that if this corner of GWT had allowed the
Contexts to be defined with a user-specified class loader, life would have been
easier. Perhaps GWT does by now. Once I had my problem solved I stopped
following the issue. My point here is that sometimes the provisions to
accomodate OSGi are not onerous, just giving a method another argument that is
left null for the non-OSGi user.
I read up yesterday a bit about Java Modules but not far enough to know how it
deals with finding other modules that may not be there. Most of the blogs
seemed to about whether versions should have three digits or four!
Back to your summing up. It really seems a great shame that to make Restlet
work reliably with OSGi every user would need to do his own custom build just
be able to specify a different jar manifest! Or else always include all
extensions as fragments.
I understand the OSGi service model and that it should have no startup order
dependencies and you rightly say that to achieve that may be too polluting and
too much work. On the other hand having something that does not work is not
very good either. Is there a middle ground to make Restlet function as a
reliable library under OSGi by not using any start(bundle) and just let the
user code deal with taking care of ensuring all the bundles are present before
using them. This would be what David might call a "half-way" solution but to
me better than none if the full solution is out of reach. Perhaps it fits what
David has in mind with his #1.
The show-stopper problem seems to be the method Restlet uses to find extensions
and that seems to need a bit of code specific to OSGi, something like:
RestLetEngine{
static osgiHook;
}
AnyRestletExtension{ // This would have to be added to thirty odd extensions!!
...
if( osgiHook != null) osgiHook.registerExtension( this)
..
}
// No osgi dependencies
Interface ExtensionFinder{
void registerExtension( Extension ex);// {} implementation for non-osgi
Extension[] getExtensions( class exClass); // always implemented
}
import osgi.*;// osgi dependencies
// An OSGi-enabler bundle
class OSGiHookImplBundle implements ExtensionFinder, Activator{
public void start(BundleContext arg0){
RestLetEngine.setOsgiHook(this); // inject OSGi present!
}
public void registerExtension( Extension ex){
osgi.register(ex);
}
// Get classes implementing interface exClass (any sub-class of Extension
Extension[] getExtensions( class exClass){
return osgi.getExtensions( exClass);
}
P.S. Don't laugh - I'm not a seasoned software professional! You probably
know better ways.
------------------------------------------------------
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2382610
