Defining OSGi Capabilities for Specific SwitchYard Functionality

[rcernich]

Hey all,

Currently, there is an issue in our Karaf deployments where applications may fail intermittently because core dependencies have not been initialized (installed/activated) before the application.  This is born out by the intermittent test failures in our release builds.  A specific example is the CXF quickstart, which relies on transformers contributed by the core transform plugin (i.e. OOTB transforms).  Sometimes, the transform plugin is not registered with the SwitchYard extender before the quickstart, which ends up leaving these transforms out.  A simple fix is to add a package import that would require the transform bundle to be initialized before the quickstart.  This is probably not ideal for users, but is a decent workaround for the problem.

I think a better solution would be to have each component provide a capability, e.g. soap component might Provide-Capability: org.switchyard.component.soap;version="2.0.0".  Application bundles would then require the specific capabilities they need, e.g. Require-Capability: org.switchyard.component.soap;version="[2.0,2.1)".  This will ensure the soap bundle is installed before the application bundle, which should eliminate most of the timing problems that might arise during installation/deployment.  I also propose creating a core SwitchYard capability that would bring in everything required for the framework (e.g. transform, validate, api, serializer, etc.).

We could also take this a step further and add a uses clause to the provided capabilities to help align package versions during resolution.  This would help provide a consistent classpath.  That said, I don't think this is a requirement at this time.

Any thoughts, opinions, comments, concerns....

Rob

[kcbabo]

This sounds like a sensible approach to me.  I haven't used the require-capability support in Karaf, so can't comment on whether this will work though. :-)

[rcernich]

Keith Babo wrote:

This sounds like a sensible approach to me.  I haven't used the require-capability support in Karaf, so can't comment on whether this will work though. :-)

And that's the $64,000 question, isn't it?

[rcernich]

I've prototyped this OSGi capability stuff and it can be found on the following branches on github:

rcernich/core at osgi-capabilities · GitHub

rcernich/components at osgi-capabilities · GitHub

rcernich/quickstarts at osgi-capabilities · GitHub

rcernich/release at osgi-capabilities · GitHub

I didn't really declare any capabilities in core, other than transform and validate (because I was trying to fix an issue with transforms), but I could see creating various capabilities related to core functionality.  I've wrapped all the generic "engine" stuff into a core, org.switchyard capability, which is provided by the SwitchYard extender bundle (i.e. switchyard-karaf-deploy).  I've added capabilities for each component bundle as well (e.g. org.switchyard.component.camel.cxf).  I modified the CXF quickstart to use the capabilities, which really just amounts to making sure all those related bundles are activated prior to the quickstart.

You'll notice some comments around org.switchyard.serial, which is a capability which provides a serialization impl, in this case one based on jackson.  I think a better way to go is to register a service for this capability and have it resolve that way (as opposed to using capabilities).

Next steps:

I'd like to see about creating a SwitchYardBundleClassLoader which aggregates the applications bundle or CDI classloader with the bundle classloaders for each required capability.  I thin this should allow us to remove the dynamic imports that we're declaring today.

Let me know what you think,

Rob