The service-mix dilemma
The Apache Felix Resolver integration requires that all wiring candidates are registered with the resolver. This is true for ordinary bundles, fragments, the system bundle and our dynamically generated service mix bundles. The resolver will not return a wire to a bundle that is not known to it.
OSGi capabilities and requirements get constructed from the OSGi metadata. Those reqs/caps are mapped to an equvilant notion of resolver reqs/caps. The 1000$ question is, what are the caps/reqs of a deployment that does not contain a valid OSGi manifest.
The MC classloading layer has a notion of ExportAll, which effectivly exports all packages from a given deployment. OSGi on the other hand does not have that notion and neither should it IMHO because it defeats the fundamental concepts of package modularity.
As an example I implemented an OSGiKernelDeploymentDeployer that generates OSGiMetaData from a KernelDeployment. Effectivly, I adds an Export-Package attribute for every top-level bean class
// Add an Export-Package definition from the bean's package
for (BeanMetaData bmd : beansMetaData)
{
String className = bmd.getBean();
if (className != null && className.startsWith("java.") == false)
{
String packageName = className.substring(0, className.lastIndexOf("."));
builder.addExportPackages(packageName);
}
else
{
log.debug("Ignore export package for: " + bmd);
}
}
This code is not meant to be complete not correct. Instead it can serve as a starting point for the discaussion of how arbitrary non-osgi deployments can be mapped to OSGiMetaData.
This code in place, I can successfully run the ServiceMixTestCase . Note, how in some places it is necessary to provide the OSGiMetaData explicitly, because the top level beans do not expose all the packages required by the test.
Deployment beans = createDeployment("beanA", null, A.class, C.class);
BeanMetaDataBuilder bmd = BeanMetaDataBuilder.createBuilder("C", C.class.getName());
addBeanMetaData(beans, bmd.addPropertyMetaData("a", bmd.createContextualInject()).getBeanMetaData());
// Bundle-SymbolicName: beanA
// Export-Package: org.jboss.test.osgi.service.support.a,org.jboss.test.osgi.service.support.c
OSGiMetaDataBuilder osgimd = OSGiMetaDataBuilder.createBuilder(beans.getName());
addOSGiMetaData(beans, osgimd.addExportPackages(A.class, C.class).getOSGiMetaData());
addDeployment(beans);
With this code and the felix resolver in the framework, I then tried to integrate everyting in the OSGi Runtime and JBossAS. As suspected the AS blows through the roof because every deployment that has a KernelDeployment is now subject to OSGi classloading rules and resolver wiring.
What I learned from this lesson is:
#1 The framework testsuite is insufficient to cover even the fundamental use cases that occur in AS
#2 Until #1 is solved, I cannot merge stuff into master unless I've tried it out in the AS
#3 The service-mix rules are still very much conceptually undefined
The last item (#3) is a long outstanding issue that we need to resolve in order to go forward with the service-mix idea. IMHO, OSGi metadata provisioning (even conceptionaly) needs to be explicit (i.e. manifest or alternative MD source) or be derrived by clearly defined rules. (i.e. export all packages is likely to be invalid for deployments that want to take part in OSGi wiring)
Currently, the jbosgi code base is quite unstable, which was caused by an invalid update of the framework due to #1. I will now try to move forward with the felix resolver in place, but with service-mix disabled in the OSGi runtimes. (i.e. in AS the framework will be as isolated as felix and equinox). Like with every other OSGi functionality, we can only claim that it is there if it works in AS.
Failures that show up in AS, need to be isolated and added to the framework testsuite. Its important that we reach a level of coverage at the framework level which allows us to be confident that it'll also work in AS.
cheers
-thomas
