| [cosmos-dev] SDD Classloading and Registry... |
|
In going over the SDD runtime code over the weekend (org.eclipse.cosmos.me.deployment.sdd.runtime),
it occurred to me that we might be able to take advantage of some the
facilities provided by OSGi to meet out classloading and service lookup needs. Specifically, I did a deeper dive around the IResolver
interface (org.eclipse.cosmos.me.deployment.sdd.runtime.cr.resolver.cim) which
currently has 3 implementers (DirectoryResolver, FileSystemResolver, and
OperatingSystemResolver). I was able to put together a POC where I published a
bundle which contained IResolver, Constraint, and ResolutionObject (this is the
common base shared by all resolvers). Then I published a base implementation
bundle containing DirectoryResolver, FileSystemResolver, and
OperatingSystemResolver. This Bundle’s activator registered these
services as follows, note the qname property…. public void
start(BundleContext context) throws Exception { Hashtable<String,
String> props; //
{http://docs.oasis-open.org/sdd/ns/cim-profile}CIM_OperatingSystem props
= new
Hashtable<String, String>(); props.put("qname", "{http://docs.oasis-open.org/sdd/ns/cim-profile}CIM_OperatingSystem"); regs.add(context.registerService(IResolver.class.getName(), new
OperatingSystemResolver(), props)); //
{http://docs.oasis-open.org/sdd/ns/cim-profile}CIM_FileSystem props
= new
Hashtable<String, String>(); props.put("qname", "{http://docs.oasis-open.org/sdd/ns/cim-profile}CIM_FileSystem"); regs.add(context.registerService(IResolver.class.getName(), new
FileSystemResolver(), props)); //
{http://docs.oasis-open.org/sdd/ns/cim-profile}CIM_Directory props
= new
Hashtable<String, String>(); props.put("qname", "{http://docs.oasis-open.org/sdd/ns/cim-profile}CIM_Directory"); regs.add(context.registerService(IResolver.class.getName(), new
DirectoryResolver(), props)); } Registering these services this way allows them to be
queried for later and then their resolve(…) methods can be invoked
through the IResolver interface and OSGi takes care of classloading and the service
registry using a widely know specification. This appears to eliminate the need
for an external configuration file that does the mapping between profile types
and handlers. One simply asks the OSGi registry for an appropriate handler and
one will be returned if it exists. I only mention this because I would hate to see use try to
invent yet another classloading/plugin/service registry environment. -Brad Bradley Beck |