Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.0.0
    • Component/s: None
    • Labels:
      None

      Description

      please see the discussion here
      [1]http://servicemix.396122.n5.nabble.com/caml-cxf-in-smx5-td5716189.html

        Issue Links

          Activity

          Freeman Fang created issue -
          Freeman Fang made changes -
          Field Original Value New Value
          Assignee Freeman Fang [ ffang ]
          Hide
          Freeman Fang added a comment -

          may need address it on cxf or camel side though, create a ticket here to track it before 5.0 release

          Show
          Freeman Fang added a comment - may need address it on cxf or camel side though, create a ticket here to track it before 5.0 release
          Hide
          Gert Vanthienen added a comment -

          You're probably right that this needs fixing in CXF and/or Camel, but is there a work-around we can implement in Apache ServiceMix 5.0.0 in the meanwhile? Something to get these assemblies working again (e.g. overriding the cxf-specs in our features file or installing the cxf-specs features together with something that would trigger the OBR resolution) until we get the root cause fixed?

          Show
          Gert Vanthienen added a comment - You're probably right that this needs fixing in CXF and/or Camel, but is there a work-around we can implement in Apache ServiceMix 5.0.0 in the meanwhile? Something to get these assemblies working again (e.g. overriding the cxf-specs in our features file or installing the cxf-specs features together with something that would trigger the OBR resolution) until we get the root cause fixed?
          Hide
          Freeman Fang added a comment -

          yes, a feature on smx side which include the org.apache.servicemix.specs.jsr339-api-m10 bundle without dependency="true" can do the trick

          Show
          Freeman Fang added a comment - yes, a feature on smx side which include the org.apache.servicemix.specs.jsr339-api-m10 bundle without dependency="true" can do the trick
          Hide
          filippo balicchia added a comment -

          Thanks for addressing If is ok for you I'll provide wa ASAP

          Show
          filippo balicchia added a comment - Thanks for addressing If is ok for you I'll provide wa ASAP
          Hide
          Freeman Fang added a comment -
          Show
          Freeman Fang added a comment - commit fix http://svn.apache.org/r1460616
          Freeman Fang made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          Freeman Fang added a comment -

          @Filippo,
          Just commit a quick, you can verify the snapshot.
          thanks

          Show
          Freeman Fang added a comment - @Filippo, Just commit a quick, you can verify the snapshot. thanks
          Hide
          Christian Müller added a comment -

          Could you please confirm my understanding of the expression 'dependency="true|false"' (or correct my understanding):
          Assume we have the following feature definition:

          <feature name="bar">
            <bundle>mvn:com.foo/bar1/1.0.0</bundle>
            <bundle dependency="false">mvn:com.foo/bar2/1.0.0</bundle>
            <bundle dependency="true">mvn:com.foo/bar3/1.0.0</bundle>
          </feature>
          
          <feature name="foo">
            <feature>bar</bundle>
            <bundle dependency="false">mvn:com.foo/foo1/1.0.0</bundle>
          </feature>
          
          • If we install feature 'bar', bundle 'bar1' will be installed (dependency="false" is the default which means the bundle will be installed).
          • If we install feature 'bar', bundle 'bar2' will be installed.
          • If we install feature 'bar', bundle 'bar3' will only be installed, if 'bar1' or 'bar2' has an import package declaration which will be fulfilled (exported) by 'bar3'. If this is not the case, the bundle 'bar3' will not be installed.
          • If we install feature 'foo', which has an import package declaration which will be fulfilled (exported) by 'bar3', 'bar3' will be installed.

          Right?

          I couldn't find a good documentation how it works exactly at https://cwiki.apache.org/KARAF/46-provisioning.html

          Show
          Christian Müller added a comment - Could you please confirm my understanding of the expression 'dependency="true|false"' (or correct my understanding): Assume we have the following feature definition: <feature name= "bar" > <bundle>mvn:com.foo/bar1/1.0.0</bundle> <bundle dependency= " false " >mvn:com.foo/bar2/1.0.0</bundle> <bundle dependency= " true " >mvn:com.foo/bar3/1.0.0</bundle> </feature> <feature name= "foo" > <feature>bar</bundle> <bundle dependency= " false " >mvn:com.foo/foo1/1.0.0</bundle> </feature> If we install feature 'bar', bundle 'bar1' will be installed (dependency="false" is the default which means the bundle will be installed). If we install feature 'bar', bundle 'bar2' will be installed. If we install feature 'bar', bundle 'bar3' will only be installed, if 'bar1' or 'bar2' has an import package declaration which will be fulfilled (exported) by 'bar3'. If this is not the case, the bundle 'bar3' will not be installed. If we install feature 'foo', which has an import package declaration which will be fulfilled (exported) by 'bar3', 'bar3' will be installed. Right? I couldn't find a good documentation how it works exactly at https://cwiki.apache.org/KARAF/46-provisioning.html
          Hide
          filippo balicchia added a comment -

          @Freeman Fang

          for me it's ok

          Show
          filippo balicchia added a comment - @ Freeman Fang for me it's ok
          Hide
          Freeman Fang added a comment -

          @Christian,

          For your question, first of all, all features should add resolver='(obr)', so that obr resolver can kick in, so that won't install redundant bundles
          And about the dependency=true flag for each bundle, bundles flagged as dependencies will be used to resolve constraints from other non dependencies bundles. Which means if there's no dependencies on such a bundle, it won't be installed.

          And back to your questions
          If we install feature 'bar', bundle 'bar1' will be installed (dependency="false" is the default which means the bundle will be installed).
          yes, if OSGi container not already have bundles which can provide packages&versions that bar1 can provide

          If we install feature 'bar', bundle 'bar2' will be installed.
          yes, if OSGi container not already have bundles which can provide packages&versions that bar2 can provide

          If we install feature 'bar', bundle 'bar3' will only be installed, if 'bar1' or 'bar2' has an import package declaration which will be fulfilled (exported) by 'bar3'. If this is not the case, the bundle 'bar3' will not be installed.
          yes, if OSGi container not already have bundles which can provide packages&versions that bar3 can provide

          If we install feature 'foo', which has an import package declaration which will be fulfilled (exported) by 'bar3', 'bar3' will be installed.
          No, I don't thinks so, bar3 already get resolved in feature bar and it won't re-resolved in feature foo by feature dependency, unless you explicitly add bar3 in feature foo.

          Freeman

          Show
          Freeman Fang added a comment - @Christian, For your question, first of all, all features should add resolver='(obr)', so that obr resolver can kick in, so that won't install redundant bundles And about the dependency=true flag for each bundle, bundles flagged as dependencies will be used to resolve constraints from other non dependencies bundles. Which means if there's no dependencies on such a bundle, it won't be installed. And back to your questions If we install feature 'bar', bundle 'bar1' will be installed (dependency="false" is the default which means the bundle will be installed). yes, if OSGi container not already have bundles which can provide packages&versions that bar1 can provide If we install feature 'bar', bundle 'bar2' will be installed. yes, if OSGi container not already have bundles which can provide packages&versions that bar2 can provide If we install feature 'bar', bundle 'bar3' will only be installed, if 'bar1' or 'bar2' has an import package declaration which will be fulfilled (exported) by 'bar3'. If this is not the case, the bundle 'bar3' will not be installed. yes, if OSGi container not already have bundles which can provide packages&versions that bar3 can provide If we install feature 'foo', which has an import package declaration which will be fulfilled (exported) by 'bar3', 'bar3' will be installed. No, I don't thinks so, bar3 already get resolved in feature bar and it won't re-resolved in feature foo by feature dependency, unless you explicitly add bar3 in feature foo. Freeman
          Freeman Fang made changes -
          Link This issue is duplicated by SM-2192 [ SM-2192 ]
          Krzysztof Sobkowiak made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          2h 9m 1 Freeman Fang 25/Mar/13 11:18
          Resolved Resolved Closed Closed
          736d 6h 8m 1 Krzysztof Sobkowiak 31/Mar/15 18:27

            People

            • Assignee:
              Freeman Fang
              Reporter:
              Freeman Fang
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development