3 Replies Latest reply on Sep 5, 2014 5:51 PM by Rob Cernich

    Defining OSGi Capabilities for Specific SwitchYard Functionality

    Rob Cernich Master

      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