Now that I'm drinking the OSGi Kool-Aid, one of the main problems my projects face is component reliance on the Java Service Provider model (META-INF/services/... discovery) to find available bits. My Google-fu is apparently weak, because I haven't found any good, rational treatment of what the heck to do about it. The ones that bite me worst are:
Restlet -- using the service provider model to find extensions. Java scripting -- using the service provider model to find available scripting languages. I haven't found a way (under Eclipse or Equinox) to make the META-INF/services from one bundle visible to another bundle. Not saying it doesn't exist -- I'm an OSGi newbie -- but I haven't found one. My current workarounds involve putting way too much a priori knowledge (explicit imports of desired plugins, manual META-INF/services definitions) into the feature or application bundle definition. These workarounds defeat the whole point of OSGi pluggability, and can't go away too quickly for me. I'm hoping that one of the more knowledgeable OSGi minds on the list has a good idea of a better way to do this. It seems to me like I need to create an Activator when I bundle-ize a Restlet extension or scripting language, and have that Activator do something useful to signal the bundle's availability to the script engine or Restlet engine, instead of relying on service provider discovery. I feel like this can't be something I'm the first person to need or invent, but I can't find any good discussions out there of successful solution patterns. The fact that there are a lot of different ways of implementing the service provider model (sun.misc.Service, javax.tools.toolprovider, hand written jar scanning) seems to complicate the problem. I'm very interested in anybody's thoughts on how best to handle these cases. Help! - R ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1322152
