You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2010/06/26 18:19:25 UTC
DOSGI: Update to CXF 2.2.9
Hi
I've attached a patch to [1] which I've tried locally, things looks ok after
updating to 2.2.9, i.e, I run two demos manually, greeter & greeter_rest,
but the build itself is hanging in systests2/multi bundle tests.
Can someone please try the patch as well and confirm it's building ok or
hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
cheers, Sergey
[1] https://issues.apache.org/jira/browse/DOSGI-74
Re: DOSGI: Update to CXF 2.2.9
Posted by Daniel Kulp <dk...@apache.org>.
Maybe a startup ordering problem. I see a couple CXF bundles started before
the JAX-WS API bundle. Thus, they MAY get the 0.0 version from the runtime,
but those that start after the jax-ws api bundle would get the 2.1 version
from the bundle.
Dan
On Monday 28 June 2010 7:39:39 am David Bosschaert wrote:
> Hi Sergey,
>
> I think you need to dive a little deeper to see what the actual problem is.
> Let me know if you need help with this.
>
> Cheers,
>
> David
>
> On 28 June 2010 12:31, Sergey Beryozkin <sb...@gmail.com> wrote:
> > Hi David
> >
> > So
> > (version>=2.1.0)
> >
> > does not intersect with
> >
> > (version>=0.0.0)(!(version>=3.0.0)
> >
> > ?
> >
> > cheers, Sergey
> >
> > On Mon, Jun 28, 2010 at 10:34 AM, David Bosschaert <
> >
> > david.bosschaert@gmail.com> wrote:
> >> Hi Sergey,
> >>
> >> I tried your patch on my machine and can confirm that it seems to
> >> consistently hang in the multibundle system test. This wasn't the case
> >> before.
> >>
> >> The good news is that it's hanging because the multi-bundle distro is
> >> actually broken - it's so good to have tests :)
> >>
> >> I just tried it manually with Felix 3.0.1 and it tells me this
> >> org.apache.felix.framework.resolver.ResolveException: Constraint
> >> violation for package 'javax.xml.ws' when resolving module 7.0 between
> >> existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> >> (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> >> 0.javax.xml.ws BLAMED ON [[7.0] package;
> >> (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> >> package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
> >>
> >> Cheers,
> >>
> >> David
> >>
> >> g! lb
> >> START LEVEL 85
> >> ID|State |Level|Name
> >> 0|Active | 0|System Bundle (3.0.1)
> >> 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
> >> 2|Active | 1|Apache Felix Gogo Command (0.6.0)
> >> 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> >> 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
> >> 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> >> 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
> >> 7|Installed | 84|CXF dOSGi Remote Service Admin Implementation
> >> (1.2.0.SNA
> >> PSHOT)
> >> 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
> >> 9|Active | 83|CXF Local Discovery Service Bundle
> >> (1.2.0.SNAPSHOT) 10|Active | 51|geronimo-annotation_1.0_spec
> >> (1.1.1)
> >> 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0)
> >> 12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
> >> 13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0)
> >> 14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0)
> >> 15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0 (1.3.0)
> >> 16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0)
> >> 17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
> >> 18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4
> >> (1.5.4.1)
> >> 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7
> >> (3.2.7.1) 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4
> >> (2.0.4.1) 21|Active | 73|Apache ServiceMix Bundles:
> >> xmlresolver-1.2 (1.2.0.1) 22|Active | 72|Apache ServiceMix
> >> Bundles: asm-2.2.3 (2.2.3.1) 23|Active | 71|Apache ServiceMix
> >> Bundles: xmlschema-1.4.3 (1.4.3.1) 24|Active | 70|Apache
> >> ServiceMix Bundles: xmlsec-1.3.0 (1.3.0.1) 25|Active | 69|Apache
> >> ServiceMix Bundles: wsdl4j-1.6.1 (1.6.1.1) 26|Active | 68|Apache
> >> ServiceMix Bundles: jaxb-impl-2.1.6 (2.1.6.1) 27|Active |
> >> 67|OPS4J Pax Web - Service (0.5.1)
> >> 28|Active | 66|spring-osgi-extender (1.2.0)
> >> 29|Active | 65|spring-osgi-core (1.2.0)
> >> 30|Active | 64|spring-osgi-io (1.2.0)
> >> 31|Active | 63|Spring AOP (2.5.6)
> >> 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
> >> 33|Active | 61|SLF4J API (1.5.10)
> >> 34|Active | 60|AOP Alliance API (1.0.0)
> >> 35|Active | 59|Spring Context (2.5.6)
> >> 36|Active | 58|Spring Beans (2.5.6)
> >> 37|Active | 57|Spring Core (2.5.6)
> >> 38|Active | 56|JDOM DOM Processor (1.0.0)
> >> 39|Active | 55|Apache Commons Logging (1.1.1)
> >> 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
> >> g! start 7
> >> RE: org.apache.felix.framework.resolver.ResolveException: Constraint
> >> violation f
> >> or package 'javax.xml.ws' when resolving module 7.0 between existing
> >> import 13.0
> >> .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> >> )(version>=2.1.0)
> >> )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> >> (&(package=org.a
> >> pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> >> (&(package=javax.xml
> >> .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> >> org.osgi.framework.BundleException: Constraint violation for package
> >> 'javax.xml.
> >> ws' when resolving module 7.0 between existing import
> >> 13.0.javax.xml.wsBLAMED O N [[7.0] package;
> >> (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> >> 0.javax.xml.ws BLAMED ON [[7.0] package;
> >> (&(package=org.apache.cxf.jaxrs.provid
> >> er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
> >> )(version>=0.0.0)(!
> >> (version>=3.0.0)))]
> >>
> >> On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> >> > Hi
> >> >
> >> > I've attached a patch to [1] which I've tried locally, things looks ok
> >>
> >> after
> >>
> >> > updating to 2.2.9, i.e, I run two demos manually, greeter &
> >> > greeter_rest,
> >> >
> >> > but the build itself is hanging in systests2/multi bundle tests.
> >> >
> >> > Can someone please try the patch as well and confirm it's building ok
> >> > or hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done
> >> > IMHO
> >> >
> >> > cheers, Sergey
> >> >
> >> > [1] https://issues.apache.org/jira/browse/DOSGI-74
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: DOSGI: Update to CXF 2.2.9
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
If you could explain what else that 'Conflicting constraint' statement can
mean then it would help...
cheers, Sergey
On Mon, Jun 28, 2010 at 12:39 PM, David Bosschaert <
david.bosschaert@gmail.com> wrote:
> Hi Sergey,
>
> I think you need to dive a little deeper to see what the actual problem is.
> Let me know if you need help with this.
>
> Cheers,
>
> David
>
> On 28 June 2010 12:31, Sergey Beryozkin <sb...@gmail.com> wrote:
> > Hi David
> >
> > So
> > (version>=2.1.0)
> >
> > does not intersect with
> >
> > (version>=0.0.0)(!(version>=3.0.0)
> >
> > ?
> >
> > cheers, Sergey
> >
> > On Mon, Jun 28, 2010 at 10:34 AM, David Bosschaert <
> > david.bosschaert@gmail.com> wrote:
> >
> >> Hi Sergey,
> >>
> >> I tried your patch on my machine and can confirm that it seems to
> >> consistently hang in the multibundle system test. This wasn't the case
> >> before.
> >>
> >> The good news is that it's hanging because the multi-bundle distro is
> >> actually broken - it's so good to have tests :)
> >>
> >> I just tried it manually with Felix 3.0.1 and it tells me this
> >> org.apache.felix.framework.resolver.ResolveException: Constraint
> >> violation for package 'javax.xml.ws' when resolving module 7.0 between
> >> existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> >> (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> >> 0.javax.xml.ws BLAMED ON [[7.0] package;
> >> (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> >> package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
> >>
> >> Cheers,
> >>
> >> David
> >>
> >> g! lb
> >> START LEVEL 85
> >> ID|State |Level|Name
> >> 0|Active | 0|System Bundle (3.0.1)
> >> 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
> >> 2|Active | 1|Apache Felix Gogo Command (0.6.0)
> >> 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> >> 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
> >> 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> >> 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
> >> 7|Installed | 84|CXF dOSGi Remote Service Admin Implementation
> >> (1.2.0.SNA
> >> PSHOT)
> >> 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
> >> 9|Active | 83|CXF Local Discovery Service Bundle
> (1.2.0.SNAPSHOT)
> >> 10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
> >> 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0)
> >> 12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
> >> 13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0)
> >> 14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0)
> >> 15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0 (1.3.0)
> >> 16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0)
> >> 17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
> >> 18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4
> >> (1.5.4.1)
> >> 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7
> (3.2.7.1)
> >> 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4 (2.0.4.1)
> >> 21|Active | 73|Apache ServiceMix Bundles: xmlresolver-1.2
> (1.2.0.1)
> >> 22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
> >> 23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3
> (1.4.3.1)
> >> 24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0 (1.3.0.1)
> >> 25|Active | 69|Apache ServiceMix Bundles: wsdl4j-1.6.1 (1.6.1.1)
> >> 26|Active | 68|Apache ServiceMix Bundles: jaxb-impl-2.1.6
> (2.1.6.1)
> >> 27|Active | 67|OPS4J Pax Web - Service (0.5.1)
> >> 28|Active | 66|spring-osgi-extender (1.2.0)
> >> 29|Active | 65|spring-osgi-core (1.2.0)
> >> 30|Active | 64|spring-osgi-io (1.2.0)
> >> 31|Active | 63|Spring AOP (2.5.6)
> >> 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
> >> 33|Active | 61|SLF4J API (1.5.10)
> >> 34|Active | 60|AOP Alliance API (1.0.0)
> >> 35|Active | 59|Spring Context (2.5.6)
> >> 36|Active | 58|Spring Beans (2.5.6)
> >> 37|Active | 57|Spring Core (2.5.6)
> >> 38|Active | 56|JDOM DOM Processor (1.0.0)
> >> 39|Active | 55|Apache Commons Logging (1.1.1)
> >> 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
> >> g! start 7
> >> RE: org.apache.felix.framework.resolver.ResolveException: Constraint
> >> violation f
> >> or package 'javax.xml.ws' when resolving module 7.0 between existing
> >> import 13.0
> >> .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> >> )(version>=2.1.0)
> >> )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> >> (&(package=org.a
> >> pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> >> (&(package=javax.xml
> >> .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> >> org.osgi.framework.BundleException: Constraint violation for package
> >> 'javax.xml.
> >> ws' when resolving module 7.0 between existing import
> 13.0.javax.xml.wsBLAMED O
> >> N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and uses
> >> constraint
> >> 0.javax.xml.ws BLAMED ON [[7.0] package;
> >> (&(package=org.apache.cxf.jaxrs.provid
> >> er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
> >> )(version>=0.0.0)(!
> >> (version>=3.0.0)))]
> >>
> >> On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> >> > Hi
> >> >
> >> > I've attached a patch to [1] which I've tried locally, things looks ok
> >> after
> >> > updating to 2.2.9, i.e, I run two demos manually, greeter &
> greeter_rest,
> >> >
> >> > but the build itself is hanging in systests2/multi bundle tests.
> >> >
> >> > Can someone please try the patch as well and confirm it's building ok
> or
> >> > hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
> >> >
> >> > cheers, Sergey
> >> >
> >> > [1] https://issues.apache.org/jira/browse/DOSGI-74
> >> >
> >>
> >
>
Re: DOSGI: Update to CXF 2.2.9
Posted by David Bosschaert <da...@gmail.com>.
Hi Sergey,
I think you need to dive a little deeper to see what the actual problem is.
Let me know if you need help with this.
Cheers,
David
On 28 June 2010 12:31, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi David
>
> So
> (version>=2.1.0)
>
> does not intersect with
>
> (version>=0.0.0)(!(version>=3.0.0)
>
> ?
>
> cheers, Sergey
>
> On Mon, Jun 28, 2010 at 10:34 AM, David Bosschaert <
> david.bosschaert@gmail.com> wrote:
>
>> Hi Sergey,
>>
>> I tried your patch on my machine and can confirm that it seems to
>> consistently hang in the multibundle system test. This wasn't the case
>> before.
>>
>> The good news is that it's hanging because the multi-bundle distro is
>> actually broken - it's so good to have tests :)
>>
>> I just tried it manually with Felix 3.0.1 and it tells me this
>> org.apache.felix.framework.resolver.ResolveException: Constraint
>> violation for package 'javax.xml.ws' when resolving module 7.0 between
>> existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
>> (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
>> 0.javax.xml.ws BLAMED ON [[7.0] package;
>> (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
>> package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
>>
>> Cheers,
>>
>> David
>>
>> g! lb
>> START LEVEL 85
>> ID|State |Level|Name
>> 0|Active | 0|System Bundle (3.0.1)
>> 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
>> 2|Active | 1|Apache Felix Gogo Command (0.6.0)
>> 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
>> 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
>> 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
>> 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
>> 7|Installed | 84|CXF dOSGi Remote Service Admin Implementation
>> (1.2.0.SNA
>> PSHOT)
>> 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
>> 9|Active | 83|CXF Local Discovery Service Bundle (1.2.0.SNAPSHOT)
>> 10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
>> 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0)
>> 12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
>> 13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0)
>> 14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0)
>> 15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0 (1.3.0)
>> 16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0)
>> 17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
>> 18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4
>> (1.5.4.1)
>> 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7 (3.2.7.1)
>> 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4 (2.0.4.1)
>> 21|Active | 73|Apache ServiceMix Bundles: xmlresolver-1.2 (1.2.0.1)
>> 22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
>> 23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3 (1.4.3.1)
>> 24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0 (1.3.0.1)
>> 25|Active | 69|Apache ServiceMix Bundles: wsdl4j-1.6.1 (1.6.1.1)
>> 26|Active | 68|Apache ServiceMix Bundles: jaxb-impl-2.1.6 (2.1.6.1)
>> 27|Active | 67|OPS4J Pax Web - Service (0.5.1)
>> 28|Active | 66|spring-osgi-extender (1.2.0)
>> 29|Active | 65|spring-osgi-core (1.2.0)
>> 30|Active | 64|spring-osgi-io (1.2.0)
>> 31|Active | 63|Spring AOP (2.5.6)
>> 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
>> 33|Active | 61|SLF4J API (1.5.10)
>> 34|Active | 60|AOP Alliance API (1.0.0)
>> 35|Active | 59|Spring Context (2.5.6)
>> 36|Active | 58|Spring Beans (2.5.6)
>> 37|Active | 57|Spring Core (2.5.6)
>> 38|Active | 56|JDOM DOM Processor (1.0.0)
>> 39|Active | 55|Apache Commons Logging (1.1.1)
>> 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
>> g! start 7
>> RE: org.apache.felix.framework.resolver.ResolveException: Constraint
>> violation f
>> or package 'javax.xml.ws' when resolving module 7.0 between existing
>> import 13.0
>> .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
>> )(version>=2.1.0)
>> )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
>> (&(package=org.a
>> pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
>> (&(package=javax.xml
>> .ws)(version>=0.0.0)(!(version>=3.0.0)))]
>> org.osgi.framework.BundleException: Constraint violation for package
>> 'javax.xml.
>> ws' when resolving module 7.0 between existing import 13.0.javax.xml.wsBLAMED O
>> N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and uses
>> constraint
>> 0.javax.xml.ws BLAMED ON [[7.0] package;
>> (&(package=org.apache.cxf.jaxrs.provid
>> er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
>> )(version>=0.0.0)(!
>> (version>=3.0.0)))]
>>
>> On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com> wrote:
>> > Hi
>> >
>> > I've attached a patch to [1] which I've tried locally, things looks ok
>> after
>> > updating to 2.2.9, i.e, I run two demos manually, greeter & greeter_rest,
>> >
>> > but the build itself is hanging in systests2/multi bundle tests.
>> >
>> > Can someone please try the patch as well and confirm it's building ok or
>> > hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
>> >
>> > cheers, Sergey
>> >
>> > [1] https://issues.apache.org/jira/browse/DOSGI-74
>> >
>>
>
Re: DOSGI: Update to CXF 2.2.9
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi David
So
(version>=2.1.0)
does not intersect with
(version>=0.0.0)(!(version>=3.0.0)
?
cheers, Sergey
On Mon, Jun 28, 2010 at 10:34 AM, David Bosschaert <
david.bosschaert@gmail.com> wrote:
> Hi Sergey,
>
> I tried your patch on my machine and can confirm that it seems to
> consistently hang in the multibundle system test. This wasn't the case
> before.
>
> The good news is that it's hanging because the multi-bundle distro is
> actually broken - it's so good to have tests :)
>
> I just tried it manually with Felix 3.0.1 and it tells me this
> org.apache.felix.framework.resolver.ResolveException: Constraint
> violation for package 'javax.xml.ws' when resolving module 7.0 between
> existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> 0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
>
> Cheers,
>
> David
>
> g! lb
> START LEVEL 85
> ID|State |Level|Name
> 0|Active | 0|System Bundle (3.0.1)
> 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
> 2|Active | 1|Apache Felix Gogo Command (0.6.0)
> 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
> 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
> 7|Installed | 84|CXF dOSGi Remote Service Admin Implementation
> (1.2.0.SNA
> PSHOT)
> 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
> 9|Active | 83|CXF Local Discovery Service Bundle (1.2.0.SNAPSHOT)
> 10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
> 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0)
> 12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
> 13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0)
> 14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0)
> 15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0 (1.3.0)
> 16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0)
> 17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
> 18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4
> (1.5.4.1)
> 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7 (3.2.7.1)
> 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4 (2.0.4.1)
> 21|Active | 73|Apache ServiceMix Bundles: xmlresolver-1.2 (1.2.0.1)
> 22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
> 23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3 (1.4.3.1)
> 24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0 (1.3.0.1)
> 25|Active | 69|Apache ServiceMix Bundles: wsdl4j-1.6.1 (1.6.1.1)
> 26|Active | 68|Apache ServiceMix Bundles: jaxb-impl-2.1.6 (2.1.6.1)
> 27|Active | 67|OPS4J Pax Web - Service (0.5.1)
> 28|Active | 66|spring-osgi-extender (1.2.0)
> 29|Active | 65|spring-osgi-core (1.2.0)
> 30|Active | 64|spring-osgi-io (1.2.0)
> 31|Active | 63|Spring AOP (2.5.6)
> 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
> 33|Active | 61|SLF4J API (1.5.10)
> 34|Active | 60|AOP Alliance API (1.0.0)
> 35|Active | 59|Spring Context (2.5.6)
> 36|Active | 58|Spring Beans (2.5.6)
> 37|Active | 57|Spring Core (2.5.6)
> 38|Active | 56|JDOM DOM Processor (1.0.0)
> 39|Active | 55|Apache Commons Logging (1.1.1)
> 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
> g! start 7
> RE: org.apache.felix.framework.resolver.ResolveException: Constraint
> violation f
> or package 'javax.xml.ws' when resolving module 7.0 between existing
> import 13.0
> .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> )(version>=2.1.0)
> )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=org.a
> pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> (&(package=javax.xml
> .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> org.osgi.framework.BundleException: Constraint violation for package
> 'javax.xml.
> ws' when resolving module 7.0 between existing import 13.0.javax.xml.wsBLAMED O
> N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and uses
> constraint
> 0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=org.apache.cxf.jaxrs.provid
> er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
> )(version>=0.0.0)(!
> (version>=3.0.0)))]
>
> On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> > Hi
> >
> > I've attached a patch to [1] which I've tried locally, things looks ok
> after
> > updating to 2.2.9, i.e, I run two demos manually, greeter & greeter_rest,
> >
> > but the build itself is hanging in systests2/multi bundle tests.
> >
> > Can someone please try the patch as well and confirm it's building ok or
> > hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
> >
> > cheers, Sergey
> >
> > [1] https://issues.apache.org/jira/browse/DOSGI-74
> >
>
Re: DOSGI: Update to CXF 2.2.9
Posted by Daniel Kulp <dk...@apache.org>.
On Monday 28 June 2010 1:19:56 pm Sergey Beryozkin wrote:
> Hi Eoghan
>
> ServiceMix is shipping the config.properties and they may be specific to a
> specific Felix version ? Similarly for Equinox (even though most of the
> config.properties are probably reusable across diff versions)
> DOSGI RI does only ship the fragments of config properties which are built
> during the multi-bundle build...
>
> I'm just curious, why was the CXF import updated to include 0.0.0 ?
So it works with an "out of the box" setup of Equinox without requiring the
user to update funky setup things like the system.packages thing.
Dan
>
> cheers, Sergey
>
> On Mon, Jun 28, 2010 at 5:55 PM, Eoghan Glynn <eo...@gmail.com> wrote:
> > Have you tried overriding the org.osgi.framework.system.packages property
> > in
> > felix/conf/config.properties, with a list of packages specifically
> > excluding
> > javax.xml.ws.*?
> >
> > This is the approach taken by SMX to get around these sort of issues. See
> > for ex:
> >
> > wget
> >
> > https://www.apache.org/dist/servicemix/servicemix-4/4.2.0/apache-servicem
> > ix-4.2.0.tar.gz tar -xvzf apache-servicemix-4.2.0.tar.gz
> > less apache-servicemix-4.2.0/etc/config.properties
> >
> > Note the packages in the jre-1.6 list that are specifically commented to
> > avoid a 0.0.0.0 version dragged in from the system bundle upsetting
> > version-constrained imports.
> >
> > Cheers,
> > Eoghan
> >
> > On 28 June 2010 10:34, David Bosschaert <da...@gmail.com>
> >
> > wrote:
> > > Hi Sergey,
> > >
> > > I tried your patch on my machine and can confirm that it seems to
> > > consistently hang in the multibundle system test. This wasn't the case
> > > before.
> > >
> > > The good news is that it's hanging because the multi-bundle distro is
> > > actually broken - it's so good to have tests :)
> > >
> > > I just tried it manually with Felix 3.0.1 and it tells me this
> > > org.apache.felix.framework.resolver.ResolveException: Constraint
> > > violation for package 'javax.xml.ws' when resolving module 7.0 between
> > > existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> > > (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> > > package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
> > >
> > > Cheers,
> > >
> > > David
> > >
> > > g! lb
> > > START LEVEL 85
> > >
> > > ID|State |Level|Name
> > >
> > > 0|Active | 0|System Bundle (3.0.1)
> > > 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
> > > 2|Active | 1|Apache Felix Gogo Command (0.6.0)
> > > 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> > > 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
> > > 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> > > 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
> > > 7|Installed | 84|CXF dOSGi Remote Service Admin Implementation
> > >
> > > (1.2.0.SNA
> > > PSHOT)
> > >
> > > 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
> > > 9|Active | 83|CXF Local Discovery Service Bundle
> >
> > (1.2.0.SNAPSHOT)
> >
> > > 10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
> > > 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0
> > > (1.3.0) 12|Active | 50|osgi.compendium
> > > (4.1.0.build-200702212030) 13|Active | 81|Apache ServiceMix
> > > Specs :: JAXWS API 2.1 (1.3.0) 14|Active | 80|Apache
> > > ServiceMix Specs :: JAXB API 2.1 (1.3.0) 15|Active | 79|Apache
> > > ServiceMix Specs :: STAX API 1.0 (1.3.0) 16|Active | 78|Apache
> > > ServiceMix Specs :: SAAJ API 1.3 (1.3.0) 17|Active | 77|Apache
> > > CXF Minimal Bundle Jar (2.2.9)
> > > 18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4
> > >
> > > (1.5.4.1)
> > >
> > > 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7
> >
> > (3.2.7.1)
> >
> > > 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4
> > > (2.0.4.1) 21|Active | 73|Apache ServiceMix Bundles:
> > > xmlresolver-1.2
> >
> > (1.2.0.1)
> >
> > > 22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
> > > 23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3
> >
> > (1.4.3.1)
> >
> > > 24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0
> > > (1.3.0.1) 25|Active | 69|Apache ServiceMix Bundles:
> > > wsdl4j-1.6.1 (1.6.1.1) 26|Active | 68|Apache ServiceMix
> > > Bundles: jaxb-impl-2.1.6
> >
> > (2.1.6.1)
> >
> > > 27|Active | 67|OPS4J Pax Web - Service (0.5.1)
> > > 28|Active | 66|spring-osgi-extender (1.2.0)
> > > 29|Active | 65|spring-osgi-core (1.2.0)
> > > 30|Active | 64|spring-osgi-io (1.2.0)
> > > 31|Active | 63|Spring AOP (2.5.6)
> > > 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
> > > 33|Active | 61|SLF4J API (1.5.10)
> > > 34|Active | 60|AOP Alliance API (1.0.0)
> > > 35|Active | 59|Spring Context (2.5.6)
> > > 36|Active | 58|Spring Beans (2.5.6)
> > > 37|Active | 57|Spring Core (2.5.6)
> > > 38|Active | 56|JDOM DOM Processor (1.0.0)
> > > 39|Active | 55|Apache Commons Logging (1.1.1)
> > > 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
> > >
> > > g! start 7
> > > RE: org.apache.felix.framework.resolver.ResolveException: Constraint
> > > violation f
> > > or package 'javax.xml.ws' when resolving module 7.0 between existing
> > > import 13.0
> > > .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> > > )(version>=2.1.0)
> > > )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > (&(package=org.a
> > > pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> > > (&(package=javax.xml
> > > .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> > > org.osgi.framework.BundleException: Constraint violation for package
> > > 'javax.xml.
> > > ws' when resolving module 7.0 between existing import
> >
> > 13.0.javax.xml.wsBLAMED O
> >
> > > N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and uses
> > > constraint
> > >
> > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > >
> > > (&(package=org.apache.cxf.jaxrs.provid
> > > er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
> > > )(version>=0.0.0)(!
> > > (version>=3.0.0)))]
> > >
> > > On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> > > > Hi
> > > >
> > > > I've attached a patch to [1] which I've tried locally, things looks
> > > > ok
> > >
> > > after
> > >
> > > > updating to 2.2.9, i.e, I run two demos manually, greeter &
> >
> > greeter_rest,
> >
> > > > but the build itself is hanging in systests2/multi bundle tests.
> > > >
> > > > Can someone please try the patch as well and confirm it's building ok
> >
> > or
> >
> > > > hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
> > > >
> > > > cheers, Sergey
> > > >
> > > > [1] https://issues.apache.org/jira/browse/DOSGI-74
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: DOSGI: Update to CXF 2.2.9
Posted by Eoghan Glynn <eo...@gmail.com>.
OK, fair enough.
One other small issue with the attach-sources in cxf-dosgi-remote-service-
admin-interfaces being in the wrong phase (leaving the sources jar
unsigned).
Now fixed, so we should be good to go with this.
I'll go ahead and call the release vote ...
/Eoghan
On 19 July 2010 17:33, <da...@apache.org> wrote:
> Hi Eoghan,
>
> All I can say is that the system tests always work fine on my machine
> and that they also work fine on Hudson...
> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/
>
> Having said that, it's always a little tricky to get system tests
> right for all machines as there are so many things at play. Port
> numbers, timing, processor architecture, platform, they can all have
> an impact.
> I'm pretty sure the functionality tested by the system tests works,
> although the tests themselves might need a little tweaking to run on
> all machines (including yours - if you have any tips I would love to
> hear them :)
>
> Cheers,
>
> David
>
> On 19 July 2010 12:35, Eoghan Glynn <eo...@gmail.com> wrote:
> >
> > Hi David,
> >
> >> This exception happens when the remote service doesn't appear within
> >> the timeout... Any chance of running it again and see if it still
> >> fails?
> >
> > OK, I ran the build a few more times and didn't see the same failure, so
> > lets put that one down to a once-off aberration.
> >
> > However, when cutting the release I'm seeing an apparent hang in
> > org.apache.cxf.dosgi.systests2.single.TestImportService. I've attached
> the
> > tail of the console output so you can see if anything rings a bell there.
> >
> > For the moment the release is in limbo, i.e. the poms are updated, the
> tag
> > is laid down and the artifacts partially uploaded to the staging area in
> > Nexus. The upload doesn't look like its going to complete, seeing as the
> > test has been hung for the last half hour, so either way I'll be killing
> > that. However if you need to get any further fixes in, let me know and
> I'll
> > also roll back the changes in SVN and start from scratch next time.
> >
> > If on the other hand you're confident about the integrity of the tests, I
> > could potentially re-run the release with
> -Darguments=-Dmaven.test.skip=true
> > but I'm leery about doing so unless we're fairly happy that I'm seeing a
> > phantom issue here.
> >
> > Cheers,
> > Eoghan
> >
> >
> > On 19 July 2010 10:30, <da...@apache.org> wrote:
> >>
> >> Hi Eoghan,
> >>
> >> On 17 July 2010 12:59, Eoghan Glynn <eo...@gmail.com> wrote:
> >> >> Eoghan would you have some cycles?
> >> >
> >> > Yeah.
> >>
> >> Excellent!
> >>
> >> > A couple of things before I go ahead and cut the release:
> >> >
> >> > - can you update the release notes[1] with a summary of what's new in
> >> > this
> >> > release?
> >>
> >> Done.
> >>
> >> > - does this TimeoutException[2] in
> >> > TestExportService.testAccessEndpoint()
> >> > ring any bells?
> >>
> >> Not really, to be honest... It always passes for me :) It also passed
> >> on the last hudson run:
> >>
> >>
> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/org.apache.cxf.dosgi.systests$cxf-dosgi-ri-systests2-singlebundle/180/testReport/org.apache.cxf.dosgi.systests2.single/TestExportService/
> >>
> >> This exception happens when the remote service doesn't appear within
> >> the timeout... Any chance of running it again and see if it still
> >> fails?
> >>
> >> Best regards,
> >>
> >> David
> >
> >
>
Re: DOSGI: Update to CXF 2.2.9
Posted by da...@apache.org.
Hi Eoghan,
All I can say is that the system tests always work fine on my machine
and that they also work fine on Hudson...
http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/
Having said that, it's always a little tricky to get system tests
right for all machines as there are so many things at play. Port
numbers, timing, processor architecture, platform, they can all have
an impact.
I'm pretty sure the functionality tested by the system tests works,
although the tests themselves might need a little tweaking to run on
all machines (including yours - if you have any tips I would love to
hear them :)
Cheers,
David
On 19 July 2010 12:35, Eoghan Glynn <eo...@gmail.com> wrote:
>
> Hi David,
>
>> This exception happens when the remote service doesn't appear within
>> the timeout... Any chance of running it again and see if it still
>> fails?
>
> OK, I ran the build a few more times and didn't see the same failure, so
> lets put that one down to a once-off aberration.
>
> However, when cutting the release I'm seeing an apparent hang in
> org.apache.cxf.dosgi.systests2.single.TestImportService. I've attached the
> tail of the console output so you can see if anything rings a bell there.
>
> For the moment the release is in limbo, i.e. the poms are updated, the tag
> is laid down and the artifacts partially uploaded to the staging area in
> Nexus. The upload doesn't look like its going to complete, seeing as the
> test has been hung for the last half hour, so either way I'll be killing
> that. However if you need to get any further fixes in, let me know and I'll
> also roll back the changes in SVN and start from scratch next time.
>
> If on the other hand you're confident about the integrity of the tests, I
> could potentially re-run the release with -Darguments=-Dmaven.test.skip=true
> but I'm leery about doing so unless we're fairly happy that I'm seeing a
> phantom issue here.
>
> Cheers,
> Eoghan
>
>
> On 19 July 2010 10:30, <da...@apache.org> wrote:
>>
>> Hi Eoghan,
>>
>> On 17 July 2010 12:59, Eoghan Glynn <eo...@gmail.com> wrote:
>> >> Eoghan would you have some cycles?
>> >
>> > Yeah.
>>
>> Excellent!
>>
>> > A couple of things before I go ahead and cut the release:
>> >
>> > - can you update the release notes[1] with a summary of what's new in
>> > this
>> > release?
>>
>> Done.
>>
>> > - does this TimeoutException[2] in
>> > TestExportService.testAccessEndpoint()
>> > ring any bells?
>>
>> Not really, to be honest... It always passes for me :) It also passed
>> on the last hudson run:
>>
>> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/org.apache.cxf.dosgi.systests$cxf-dosgi-ri-systests2-singlebundle/180/testReport/org.apache.cxf.dosgi.systests2.single/TestExportService/
>>
>> This exception happens when the remote service doesn't appear within
>> the timeout... Any chance of running it again and see if it still
>> fails?
>>
>> Best regards,
>>
>> David
>
>
Re: DOSGI: Update to CXF 2.2.9
Posted by Eoghan Glynn <eo...@gmail.com>.
Hi David,
> This exception happens when the remote service doesn't appear within
> the timeout... Any chance of running it again and see if it still
> fails?
OK, I ran the build a few more times and didn't see the same failure, so
lets put that one down to a once-off aberration.
However, when cutting the release I'm seeing an apparent hang in
org.apache.cxf.dosgi.systests2.single.TestImportService. I've attached the
tail of the console output so you can see if anything rings a bell there.
For the moment the release is in limbo, i.e. the poms are updated, the tag
is laid down and the artifacts partially uploaded to the staging area in
Nexus. The upload doesn't look like its going to complete, seeing as the
test has been hung for the last half hour, so either way I'll be killing
that. However if you need to get any further fixes in, let me know and I'll
also roll back the changes in SVN and start from scratch next time.
If on the other hand you're confident about the integrity of the tests, I
could potentially re-run the release with -Darguments=-Dmaven.test.skip=true
but I'm leery about doing so unless we're fairly happy that I'm seeing a
phantom issue here.
Cheers,
Eoghan
On 19 July 2010 10:30, <da...@apache.org> wrote:
> Hi Eoghan,
>
> On 17 July 2010 12:59, Eoghan Glynn <eo...@gmail.com> wrote:
> >> Eoghan would you have some cycles?
> >
> > Yeah.
>
> Excellent!
>
> > A couple of things before I go ahead and cut the release:
> >
> > - can you update the release notes[1] with a summary of what's new in
> this
> > release?
>
> Done.
>
> > - does this TimeoutException[2] in TestExportService.testAccessEndpoint()
> > ring any bells?
>
> Not really, to be honest... It always passes for me :) It also passed
> on the last hudson run:
>
> http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/org.apache.cxf.dosgi.systests$cxf-dosgi-ri-systests2-singlebundle/180/testReport/org.apache.cxf.dosgi.systests2.single/TestExportService/
>
> This exception happens when the remote service doesn't appear within
> the timeout... Any chance of running it again and see if it still
> fails?
>
> Best regards,
>
> David
>
Re: DOSGI: Update to CXF 2.2.9
Posted by da...@apache.org.
Hi Eoghan,
On 17 July 2010 12:59, Eoghan Glynn <eo...@gmail.com> wrote:
>> Eoghan would you have some cycles?
>
> Yeah.
Excellent!
> A couple of things before I go ahead and cut the release:
>
> - can you update the release notes[1] with a summary of what's new in this
> release?
Done.
> - does this TimeoutException[2] in TestExportService.testAccessEndpoint()
> ring any bells?
Not really, to be honest... It always passes for me :) It also passed
on the last hudson run:
http://hudson.zones.apache.org/hudson/view/CXF/job/CXF-DOSGi/org.apache.cxf.dosgi.systests$cxf-dosgi-ri-systests2-singlebundle/180/testReport/org.apache.cxf.dosgi.systests2.single/TestExportService/
This exception happens when the remote service doesn't appear within
the timeout... Any chance of running it again and see if it still
fails?
Best regards,
David
Re: DOSGI: Update to CXF 2.2.9
Posted by Eoghan Glynn <eo...@gmail.com>.
> I think we're ready for a release!
Great!
> Eoghan would you have some cycles?
Yeah.
A couple of things before I go ahead and cut the release:
- can you update the release notes[1] with a summary of what's new in this
release?
- does this TimeoutException[2] in TestExportService.testAccessEndpoint()
ring any bells?
Cheers,
Eoghan
[1] distribution/sources/src/main/release/release_notes.txt
[2]
-------------------------------------------------------------------------------
Test set: org.apache.cxf.dosgi.systests2.single.TestExportService
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 123.83
sec <<< FAILURE!
testAccessEndpoint
[felix](org.apache.cxf.dosgi.systests2.single.TestExportService) Time
elapsed: 123.427 sec <<< ERROR!
java.util.concurrent.TimeoutException
at org.apache.cxf.dosgi.systests2.common.AbstractTestExportService.waitPort(AbstractTestExportService.java:129)
at org.apache.cxf.dosgi.systests2.common.AbstractTestExportService.baseTestAccessEndpoint(AbstractTestExportService.java:45)
at org.apache.cxf.dosgi.systests2.single.TestExportService.testAccessEndpoint(TestExportService.java:58)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.injectContextAndInvoke(CallableTestMethodImpl.java:134)
at org.ops4j.pax.exam.junit.extender.impl.internal.CallableTestMethodImpl.call(CallableTestMethodImpl.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.ops4j.pax.exam.rbc.internal.RemoteBundleContextImpl.remoteCall(RemoteBundleContextImpl.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:305)
at sun.rmi.transport.Transport$1.run(Transport.java:159)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:155)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:790)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:649)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
On 16 July 2010 13:53, David Bosschaert <da...@gmail.com> wrote:
> I spent a little while debugging this today and found that the issue
> was that the bundles internally used by the system tests didn't have
> the proper startlevel set which meant that they would get assigned
> level 5 and be started way before any of the other bundles, nailing
> the jaxws package to the one from the JRE again (0.0.0).
> I've changed the start level of these bundles and now everything is
> working correctly.
>
> I've committed this in r964787.
>
> I think we're ready for a release! Eoghan would you have some cycles?
>
> Cheers,
>
> David
>
> On 30 June 2010 18:16, Daniel Kulp <dk...@apache.org> wrote:
> > On Tuesday 29 June 2010 3:24:55 am David Bosschaert wrote:
> >> It troubles me that if people want to use CXF-DOSGi they would have to
> >> fiddle with the org.osgi.framework.system.packages. This is a major
> >> usability drawback from where we were before.
> >>
> >> > A more long-term option might to ship an entire distro of karaf with
> >> > dOSGi,
> >>
> >> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
> >> distro as OSGi is all about reusable components that can be used in
> >> any compliant OSGi Framework. We shouldn't have to ship a tweaked
> >> runtime for people to be able to use it.
> >>
> >> >> I'm just curious, why was the CXF import updated to include 0.0.0 ?
> >> >
> >> > So it works with an "out of the box" setup of Equinox without
> requiring
> >> > the user to update funky setup things like the system.packages thing.
> >>
> >> Depending on version 0.0.0 is potentially dangerous because you have
> >> no idea what version you will get. In OSGi this dependency means: take
> >> any version available!
> >
> > Depending on ANY version range it dangerous. The same problem could pop
> up
> > with the old version range "[2.1,3.0)". For example, lets say the
> system was
> > properly configured to export the system packages as 2.1 (assuming Java 6
> > update 4 or later). However, the user wants to use JAX-WS 2.2.
> (also
> > assume the 2.3 version of CXF that will support both 2.1 and 2.2).
> With the
> > current ordering, CXF would start, get version 2.1, then spec/api bundle
> would
> > start, then the client bundle would start and get 2.2, but then not be
> able
> > to use CXF due to the JAX-WS API version mismatch things. JAXB apis
> would be
> > the same way. Really, anything in the JDK could be an issue.
> >
> > JAXB is really a "could be an issue now" type thing. 2.2.9 supports the
> new
> > placements of @XmlElement on the method parameters to control the
> required and
> > nillable and such. This was added in JAXB 2.2 and required for JAX-WS
> 2.1,
> > but easily ported back to CXF 2.2.9, but only active if using JAXB 2.2.
> Thus,
> > there is a case where someone would WANT to use JAXB 2.2 with CXF today.
> In
> > the above scenario, CXF could pick up 2.1 from the system, but the user
> bundle
> > could want 2.2. Mismatch failure.
> >
> >>
> >> For CXF-DOSGi, as a temporary workaround, we *could* is *fix* the CXF
> >> jar that's part of our multibundle distro (during the build) and
> >> change the starting version back to what it was before.
> >>
> >> We could also reorder the bundles in the multibundle distro definition
> >> file (distro_bundles.xml).
> >
> >
> > I think this is the best option. I would think all the "spec"/"api"
> jars
> > should be pretty much the first things started up.
> >
> >
> >> I managed to get things working in the
> >> standalone case by putting the cxf bundle below the jaxws/jaxrs
> >> bundles, however for some reason it still hangs in the system tests...
> >
> > Not sure on that.
> >
> > Dan
> >
> >
> >>
> >> Cheers,
> >>
> >> David
> >
> > --
> > Daniel Kulp
> > dkulp@apache.org
> > http://dankulp.com/blog
> >
>
Re: DOSGI: Update to CXF 2.2.9
Posted by David Bosschaert <da...@gmail.com>.
I spent a little while debugging this today and found that the issue
was that the bundles internally used by the system tests didn't have
the proper startlevel set which meant that they would get assigned
level 5 and be started way before any of the other bundles, nailing
the jaxws package to the one from the JRE again (0.0.0).
I've changed the start level of these bundles and now everything is
working correctly.
I've committed this in r964787.
I think we're ready for a release! Eoghan would you have some cycles?
Cheers,
David
On 30 June 2010 18:16, Daniel Kulp <dk...@apache.org> wrote:
> On Tuesday 29 June 2010 3:24:55 am David Bosschaert wrote:
>> It troubles me that if people want to use CXF-DOSGi they would have to
>> fiddle with the org.osgi.framework.system.packages. This is a major
>> usability drawback from where we were before.
>>
>> > A more long-term option might to ship an entire distro of karaf with
>> > dOSGi,
>>
>> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
>> distro as OSGi is all about reusable components that can be used in
>> any compliant OSGi Framework. We shouldn't have to ship a tweaked
>> runtime for people to be able to use it.
>>
>> >> I'm just curious, why was the CXF import updated to include 0.0.0 ?
>> >
>> > So it works with an "out of the box" setup of Equinox without requiring
>> > the user to update funky setup things like the system.packages thing.
>>
>> Depending on version 0.0.0 is potentially dangerous because you have
>> no idea what version you will get. In OSGi this dependency means: take
>> any version available!
>
> Depending on ANY version range it dangerous. The same problem could pop up
> with the old version range "[2.1,3.0)". For example, lets say the system was
> properly configured to export the system packages as 2.1 (assuming Java 6
> update 4 or later). However, the user wants to use JAX-WS 2.2. (also
> assume the 2.3 version of CXF that will support both 2.1 and 2.2). With the
> current ordering, CXF would start, get version 2.1, then spec/api bundle would
> start, then the client bundle would start and get 2.2, but then not be able
> to use CXF due to the JAX-WS API version mismatch things. JAXB apis would be
> the same way. Really, anything in the JDK could be an issue.
>
> JAXB is really a "could be an issue now" type thing. 2.2.9 supports the new
> placements of @XmlElement on the method parameters to control the required and
> nillable and such. This was added in JAXB 2.2 and required for JAX-WS 2.1,
> but easily ported back to CXF 2.2.9, but only active if using JAXB 2.2. Thus,
> there is a case where someone would WANT to use JAXB 2.2 with CXF today. In
> the above scenario, CXF could pick up 2.1 from the system, but the user bundle
> could want 2.2. Mismatch failure.
>
>>
>> For CXF-DOSGi, as a temporary workaround, we *could* is *fix* the CXF
>> jar that's part of our multibundle distro (during the build) and
>> change the starting version back to what it was before.
>>
>> We could also reorder the bundles in the multibundle distro definition
>> file (distro_bundles.xml).
>
>
> I think this is the best option. I would think all the "spec"/"api" jars
> should be pretty much the first things started up.
>
>
>> I managed to get things working in the
>> standalone case by putting the cxf bundle below the jaxws/jaxrs
>> bundles, however for some reason it still hangs in the system tests...
>
> Not sure on that.
>
> Dan
>
>
>>
>> Cheers,
>>
>> David
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://dankulp.com/blog
>
Re: DOSGI: Update to CXF 2.2.9
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday 29 June 2010 3:24:55 am David Bosschaert wrote:
> It troubles me that if people want to use CXF-DOSGi they would have to
> fiddle with the org.osgi.framework.system.packages. This is a major
> usability drawback from where we were before.
>
> > A more long-term option might to ship an entire distro of karaf with
> > dOSGi,
>
> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
> distro as OSGi is all about reusable components that can be used in
> any compliant OSGi Framework. We shouldn't have to ship a tweaked
> runtime for people to be able to use it.
>
> >> I'm just curious, why was the CXF import updated to include 0.0.0 ?
> >
> > So it works with an "out of the box" setup of Equinox without requiring
> > the user to update funky setup things like the system.packages thing.
>
> Depending on version 0.0.0 is potentially dangerous because you have
> no idea what version you will get. In OSGi this dependency means: take
> any version available!
Depending on ANY version range it dangerous. The same problem could pop up
with the old version range "[2.1,3.0)". For example, lets say the system was
properly configured to export the system packages as 2.1 (assuming Java 6
update 4 or later). However, the user wants to use JAX-WS 2.2. (also
assume the 2.3 version of CXF that will support both 2.1 and 2.2). With the
current ordering, CXF would start, get version 2.1, then spec/api bundle would
start, then the client bundle would start and get 2.2, but then not be able
to use CXF due to the JAX-WS API version mismatch things. JAXB apis would be
the same way. Really, anything in the JDK could be an issue.
JAXB is really a "could be an issue now" type thing. 2.2.9 supports the new
placements of @XmlElement on the method parameters to control the required and
nillable and such. This was added in JAXB 2.2 and required for JAX-WS 2.1,
but easily ported back to CXF 2.2.9, but only active if using JAXB 2.2. Thus,
there is a case where someone would WANT to use JAXB 2.2 with CXF today. In
the above scenario, CXF could pick up 2.1 from the system, but the user bundle
could want 2.2. Mismatch failure.
>
> For CXF-DOSGi, as a temporary workaround, we *could* is *fix* the CXF
> jar that's part of our multibundle distro (during the build) and
> change the starting version back to what it was before.
>
> We could also reorder the bundles in the multibundle distro definition
> file (distro_bundles.xml).
I think this is the best option. I would think all the "spec"/"api" jars
should be pretty much the first things started up.
> I managed to get things working in the
> standalone case by putting the cxf bundle below the jaxws/jaxrs
> bundles, however for some reason it still hangs in the system tests...
Not sure on that.
Dan
>
> Cheers,
>
> David
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Re: DOSGI: Update to CXF 2.2.9
Posted by Eoghan Glynn <eo...@gmail.com>.
> A more long-term option might to ship an entire distro of karaf with
dOSGi,
> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
> distro as OSGi is all about reusable components that can be used in
> any compliant OSGi Framework. We shouldn't have to ship a tweaked
> runtime for people to be able to use it.
Well it could be a convenience *option*, just to get folks started out of
the box.
Agreed we would have to continue with the multi-bundle style option that
could be plonked into an existing runtime and be expected to work (without
too much bother).
> Depending on version 0.0.0 is potentially dangerous because you have
> no idea what version you will get. In OSGi this dependency means: take
> any version available!
Yeah.
But the way I'd see it is that CXF has kinda been backed into a corner by
what is fundamentally a framework bug. Exposing all the system packages as
0.0.0.0 makes absolutely no sense IMO, when many of these packages have a
clearly versioned provenance and it's likely that dependent bundles will
pull them in via version-constrained imports. The framework's 0.0.0.0 might
have been workable back in the day when only java.lang.String etc. were
being pulled in from the system package, but as more and more javax.* stuff
is being piled into the JRE, this isn't really feasible any more.
That said however, if there's a smarter fix/workaround that could be applied
to CXF instead, then great!
> We could also reorder the bundles in the multibundle distro definition
> file (distro_bundles.xml).
Just a ceveat, re-ordering bundles can be very fragile. SMX hit some nasty
issues whereby the ordering was subtly changed when the bundles were being
pulled in from a slowish NAS.
Cheers,
Eoghan
On 29 June 2010 08:24, David Bosschaert <da...@gmail.com> wrote:
> It troubles me that if people want to use CXF-DOSGi they would have to
> fiddle with the org.osgi.framework.system.packages. This is a major
> usability drawback from where we were before.
>
> > A more long-term option might to ship an entire distro of karaf with
> dOSGi,
> I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
> distro as OSGi is all about reusable components that can be used in
> any compliant OSGi Framework. We shouldn't have to ship a tweaked
> runtime for people to be able to use it.
>
> >> I'm just curious, why was the CXF import updated to include 0.0.0 ?
> > So it works with an "out of the box" setup of Equinox without requiring
> the
> > user to update funky setup things like the system.packages thing.
>
> Depending on version 0.0.0 is potentially dangerous because you have
> no idea what version you will get. In OSGi this dependency means: take
> any version available!
>
> For CXF-DOSGi, as a temporary workaround, we *could* is *fix* the CXF
> jar that's part of our multibundle distro (during the build) and
> change the starting version back to what it was before.
>
> We could also reorder the bundles in the multibundle distro definition
> file (distro_bundles.xml). I managed to get things working in the
> standalone case by putting the cxf bundle below the jaxws/jaxrs
> bundles, however for some reason it still hangs in the system tests...
>
> Cheers,
>
> David
>
Re: DOSGI: Update to CXF 2.2.9
Posted by David Bosschaert <da...@gmail.com>.
It troubles me that if people want to use CXF-DOSGi they would have to
fiddle with the org.osgi.framework.system.packages. This is a major
usability drawback from where we were before.
> A more long-term option might to ship an entire distro of karaf with dOSGi,
I'm also opposed to turning the CXF-DOSGi distribution into a Karaf
distro as OSGi is all about reusable components that can be used in
any compliant OSGi Framework. We shouldn't have to ship a tweaked
runtime for people to be able to use it.
>> I'm just curious, why was the CXF import updated to include 0.0.0 ?
> So it works with an "out of the box" setup of Equinox without requiring the
> user to update funky setup things like the system.packages thing.
Depending on version 0.0.0 is potentially dangerous because you have
no idea what version you will get. In OSGi this dependency means: take
any version available!
For CXF-DOSGi, as a temporary workaround, we *could* is *fix* the CXF
jar that's part of our multibundle distro (during the build) and
change the starting version back to what it was before.
We could also reorder the bundles in the multibundle distro definition
file (distro_bundles.xml). I managed to get things working in the
standalone case by putting the cxf bundle below the jaxws/jaxrs
bundles, however for some reason it still hangs in the system tests...
Cheers,
David
Re: DOSGI: Update to CXF 2.2.9
Posted by Eoghan Glynn <eo...@gmail.com>.
Dunno about older versions of felix, but 3.0.1 doesn't have the
org.osgi.framework.system.packages already listed out in the
config.properties. So it wouldn't just be a case of commenting out a few
pre-existing lines of config. Instead the user would have to copy a valid
org.osgi.framework.system.packages setting from somewhere else (e.g. the SMX
version).
Cheers,
Eoghan
On 28 June 2010 20:25, Sergey Beryozkin <sb...@gmail.com> wrote:
> I'd probably prefer updating the documentation and asking users to remove
> the jaxws related entry in their own 1.6-related part of the config. They
> will be appending the DOSGI fragment anyway and asking them to replace the
> 1.6 related part (which already exists in their config) with what DOSGI RI
> ships might be an extra hassle IMHO...
>
> cheers, Sergey
>
>
> >
> > A more long-term option might to ship an entire distro of karaf with
> dOSGi,
> > customized with some extra features in the internal system repo (that's
> the
> > approach I'm taking on another project that builds a CLI atop karaf,
> works
> > quite neatly with the features-maven-plugin to populate the internal
> repo).
> > The nice thing is that this is guaranteed to work out of the box, with
> all
> > external dependencies already resolved and all the versions lined up.
> Makes
> > the distro just a tad bigger tho' ;)
> >
> > Cheers,
> > Eoghan
> >
> > On 28 June 2010 18:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> >
> > > Hi Eoghan
> > >
> > > ServiceMix is shipping the config.properties and they may be specific
> to
> > a
> > > specific Felix version ? Similarly for Equinox (even though most of the
> > > config.properties are probably reusable across diff versions)
> > > DOSGI RI does only ship the fragments of config properties which are
> > built
> > > during the multi-bundle build...
> > >
> > > I'm just curious, why was the CXF import updated to include 0.0.0 ?
> > >
> > > cheers, Sergey
> > >
> > >
> > > On Mon, Jun 28, 2010 at 5:55 PM, Eoghan Glynn <eo...@gmail.com>
> wrote:
> > >
> > > > Have you tried overriding the org.osgi.framework.system.packages
> > property
> > > > in
> > > > felix/conf/config.properties, with a list of packages specifically
> > > > excluding
> > > > javax.xml.ws.*?
> > > >
> > > > This is the approach taken by SMX to get around these sort of issues.
> > See
> > > > for ex:
> > > >
> > > > wget
> > > >
> > > >
> > >
> >
> https://www.apache.org/dist/servicemix/servicemix-4/4.2.0/apache-servicemix-4.2.0.tar.gz
> > > > tar -xvzf apache-servicemix-4.2.0.tar.gz
> > > > less apache-servicemix-4.2.0/etc/config.properties
> > > >
> > > > Note the packages in the jre-1.6 list that are specifically commented
> > to
> > > > avoid a 0.0.0.0 version dragged in from the system bundle upsetting
> > > > version-constrained imports.
> > > >
> > > > Cheers,
> > > > Eoghan
> > > >
> > > > On 28 June 2010 10:34, David Bosschaert <da...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Sergey,
> > > > >
> > > > > I tried your patch on my machine and can confirm that it seems to
> > > > > consistently hang in the multibundle system test. This wasn't the
> > case
> > > > > before.
> > > > >
> > > > > The good news is that it's hanging because the multi-bundle distro
> is
> > > > > actually broken - it's so good to have tests :)
> > > > >
> > > > > I just tried it manually with Felix 3.0.1 and it tells me this
> > > > > org.apache.felix.framework.resolver.ResolveException: Constraint
> > > > > violation for package 'javax.xml.ws' when resolving module 7.0
> > between
> > > > > existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > > (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> > > > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > > (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> > > > > package; (&(package=javax.xml.ws
> > )(version>=0.0.0)(!(version>=3.0.0)))]
> > > > >
> > > > > Cheers,
> > > > >
> > > > > David
> > > > >
> > > > > g! lb
> > > > > START LEVEL 85
> > > > > ID|State |Level|Name
> > > > > 0|Active | 0|System Bundle (3.0.1)
> > > > > 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
> > > > > 2|Active | 1|Apache Felix Gogo Command (0.6.0)
> > > > > 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> > > > > 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
> > > > > 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> > > > > 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
> > > > > 7|Installed | 84|CXF dOSGi Remote Service Admin
> Implementation
> > > > > (1.2.0.SNA
> > > > > PSHOT)
> > > > > 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
> > > > > 9|Active | 83|CXF Local Discovery Service Bundle
> > > > (1.2.0.SNAPSHOT)
> > > > > 10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
> > > > > 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0
> > > (1.3.0)
> > > > > 12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
> > > > > 13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1
> > (1.3.0)
> > > > > 14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1
> > (1.3.0)
> > > > > 15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0
> > (1.3.0)
> > > > > 16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3
> > (1.3.0)
> > > > > 17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
> > > > > 18|Active | 76|Apache ServiceMix Bundles:
> commons-pool-1.5.4
> > > > > (1.5.4.1)
> > > > > 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7
> > > > (3.2.7.1)
> > > > > 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4
> > > (2.0.4.1)
> > > > > 21|Active | 73|Apache ServiceMix Bundles: xmlresolver-1.2
> > > > (1.2.0.1)
> > > > > 22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3
> (2.2.3.1)
> > > > > 23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3
> > > > (1.4.3.1)
> > > > > 24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0
> > > (1.3.0.1)
> > > > > 25|Active | 69|Apache ServiceMix Bundles: wsdl4j-1.6.1
> > > (1.6.1.1)
> > > > > 26|Active | 68|Apache ServiceMix Bundles: jaxb-impl-2.1.6
> > > > (2.1.6.1)
> > > > > 27|Active | 67|OPS4J Pax Web - Service (0.5.1)
> > > > > 28|Active | 66|spring-osgi-extender (1.2.0)
> > > > > 29|Active | 65|spring-osgi-core (1.2.0)
> > > > > 30|Active | 64|spring-osgi-io (1.2.0)
> > > > > 31|Active | 63|Spring AOP (2.5.6)
> > > > > 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding
> (1.5.10)
> > > > > 33|Active | 61|SLF4J API (1.5.10)
> > > > > 34|Active | 60|AOP Alliance API (1.0.0)
> > > > > 35|Active | 59|Spring Context (2.5.6)
> > > > > 36|Active | 58|Spring Beans (2.5.6)
> > > > > 37|Active | 57|Spring Core (2.5.6)
> > > > > 38|Active | 56|JDOM DOM Processor (1.0.0)
> > > > > 39|Active | 55|Apache Commons Logging (1.1.1)
> > > > > 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
> > > > > g! start 7
> > > > > RE: org.apache.felix.framework.resolver.ResolveException:
> Constraint
> > > > > violation f
> > > > > or package 'javax.xml.ws' when resolving module 7.0 between
> existing
> > > > > import 13.0
> > > > > .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> > > > > )(version>=2.1.0)
> > > > > )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > > (&(package=org.a
> > > > > pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> > > > > (&(package=javax.xml
> > > > > .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> > > > > org.osgi.framework.BundleException: Constraint violation for
> package
> > > > > 'javax.xml.
> > > > > ws' when resolving module 7.0 between existing import
> > > > 13.0.javax.xml.wsBLAMED O
> > > > > N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and
> > uses
> > > > > constraint
> > > > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > > (&(package=org.apache.cxf.jaxrs.provid
> > > > > er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
> > > > > )(version>=0.0.0)(!
> > > > > (version>=3.0.0)))]
> > > > >
> > > > > On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com>
> > wrote:
> > > > > > Hi
> > > > > >
> > > > > > I've attached a patch to [1] which I've tried locally, things
> looks
> > > ok
> > > > > after
> > > > > > updating to 2.2.9, i.e, I run two demos manually, greeter &
> > > > greeter_rest,
> > > > > >
> > > > > > but the build itself is hanging in systests2/multi bundle tests.
> > > > > >
> > > > > > Can someone please try the patch as well and confirm it's
> building
> > ok
> > > > or
> > > > > > hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done
> > IMHO
> > > > > >
> > > > > > cheers, Sergey
> > > > > >
> > > > > > [1] https://issues.apache.org/jira/browse/DOSGI-74
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: DOSGI: Update to CXF 2.2.9
Posted by Sergey Beryozkin <sb...@gmail.com>.
On Mon, Jun 28, 2010 at 7:20 PM, Eoghan Glynn <eo...@gmail.com> wrote:
> On 28 June 2010 18:19, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> > ServiceMix is shipping the config.properties and they may be specific to
> a
> > specific Felix version
>
> Well part of the config.props is version-specific (i.e. the exact version
> of
> equinox/felix framework to use), but not so much the bit defining the
> jre-1.5 and jre-1.6 specific packages.
>
> So you could conceivably just ship a fragment to append to the user's
> conf/config.properties (seeing as we already ship a
> felix.config.properties.append file with a big long list of bundles to load
> on startup).
>
I'd probably prefer updating the documentation and asking users to remove
the jaxws related entry in their own 1.6-related part of the config. They
will be appending the DOSGI fragment anyway and asking them to replace the
1.6 related part (which already exists in their config) with what DOSGI RI
ships might be an extra hassle IMHO...
cheers, Sergey
>
> A more long-term option might to ship an entire distro of karaf with dOSGi,
> customized with some extra features in the internal system repo (that's the
> approach I'm taking on another project that builds a CLI atop karaf, works
> quite neatly with the features-maven-plugin to populate the internal repo).
> The nice thing is that this is guaranteed to work out of the box, with all
> external dependencies already resolved and all the versions lined up. Makes
> the distro just a tad bigger tho' ;)
>
> Cheers,
> Eoghan
>
> On 28 June 2010 18:19, Sergey Beryozkin <sb...@gmail.com> wrote:
>
> > Hi Eoghan
> >
> > ServiceMix is shipping the config.properties and they may be specific to
> a
> > specific Felix version ? Similarly for Equinox (even though most of the
> > config.properties are probably reusable across diff versions)
> > DOSGI RI does only ship the fragments of config properties which are
> built
> > during the multi-bundle build...
> >
> > I'm just curious, why was the CXF import updated to include 0.0.0 ?
> >
> > cheers, Sergey
> >
> >
> > On Mon, Jun 28, 2010 at 5:55 PM, Eoghan Glynn <eo...@gmail.com> wrote:
> >
> > > Have you tried overriding the org.osgi.framework.system.packages
> property
> > > in
> > > felix/conf/config.properties, with a list of packages specifically
> > > excluding
> > > javax.xml.ws.*?
> > >
> > > This is the approach taken by SMX to get around these sort of issues.
> See
> > > for ex:
> > >
> > > wget
> > >
> > >
> >
> https://www.apache.org/dist/servicemix/servicemix-4/4.2.0/apache-servicemix-4.2.0.tar.gz
> > > tar -xvzf apache-servicemix-4.2.0.tar.gz
> > > less apache-servicemix-4.2.0/etc/config.properties
> > >
> > > Note the packages in the jre-1.6 list that are specifically commented
> to
> > > avoid a 0.0.0.0 version dragged in from the system bundle upsetting
> > > version-constrained imports.
> > >
> > > Cheers,
> > > Eoghan
> > >
> > > On 28 June 2010 10:34, David Bosschaert <da...@gmail.com>
> > > wrote:
> > >
> > > > Hi Sergey,
> > > >
> > > > I tried your patch on my machine and can confirm that it seems to
> > > > consistently hang in the multibundle system test. This wasn't the
> case
> > > > before.
> > > >
> > > > The good news is that it's hanging because the multi-bundle distro is
> > > > actually broken - it's so good to have tests :)
> > > >
> > > > I just tried it manually with Felix 3.0.1 and it tells me this
> > > > org.apache.felix.framework.resolver.ResolveException: Constraint
> > > > violation for package 'javax.xml.ws' when resolving module 7.0
> between
> > > > existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> > > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> > > > package; (&(package=javax.xml.ws
> )(version>=0.0.0)(!(version>=3.0.0)))]
> > > >
> > > > Cheers,
> > > >
> > > > David
> > > >
> > > > g! lb
> > > > START LEVEL 85
> > > > ID|State |Level|Name
> > > > 0|Active | 0|System Bundle (3.0.1)
> > > > 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
> > > > 2|Active | 1|Apache Felix Gogo Command (0.6.0)
> > > > 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> > > > 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
> > > > 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> > > > 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
> > > > 7|Installed | 84|CXF dOSGi Remote Service Admin Implementation
> > > > (1.2.0.SNA
> > > > PSHOT)
> > > > 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
> > > > 9|Active | 83|CXF Local Discovery Service Bundle
> > > (1.2.0.SNAPSHOT)
> > > > 10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
> > > > 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0
> > (1.3.0)
> > > > 12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
> > > > 13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1
> (1.3.0)
> > > > 14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1
> (1.3.0)
> > > > 15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0
> (1.3.0)
> > > > 16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3
> (1.3.0)
> > > > 17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
> > > > 18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4
> > > > (1.5.4.1)
> > > > 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7
> > > (3.2.7.1)
> > > > 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4
> > (2.0.4.1)
> > > > 21|Active | 73|Apache ServiceMix Bundles: xmlresolver-1.2
> > > (1.2.0.1)
> > > > 22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
> > > > 23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3
> > > (1.4.3.1)
> > > > 24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0
> > (1.3.0.1)
> > > > 25|Active | 69|Apache ServiceMix Bundles: wsdl4j-1.6.1
> > (1.6.1.1)
> > > > 26|Active | 68|Apache ServiceMix Bundles: jaxb-impl-2.1.6
> > > (2.1.6.1)
> > > > 27|Active | 67|OPS4J Pax Web - Service (0.5.1)
> > > > 28|Active | 66|spring-osgi-extender (1.2.0)
> > > > 29|Active | 65|spring-osgi-core (1.2.0)
> > > > 30|Active | 64|spring-osgi-io (1.2.0)
> > > > 31|Active | 63|Spring AOP (2.5.6)
> > > > 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
> > > > 33|Active | 61|SLF4J API (1.5.10)
> > > > 34|Active | 60|AOP Alliance API (1.0.0)
> > > > 35|Active | 59|Spring Context (2.5.6)
> > > > 36|Active | 58|Spring Beans (2.5.6)
> > > > 37|Active | 57|Spring Core (2.5.6)
> > > > 38|Active | 56|JDOM DOM Processor (1.0.0)
> > > > 39|Active | 55|Apache Commons Logging (1.1.1)
> > > > 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
> > > > g! start 7
> > > > RE: org.apache.felix.framework.resolver.ResolveException: Constraint
> > > > violation f
> > > > or package 'javax.xml.ws' when resolving module 7.0 between existing
> > > > import 13.0
> > > > .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> > > > )(version>=2.1.0)
> > > > )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > (&(package=org.a
> > > > pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> > > > (&(package=javax.xml
> > > > .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> > > > org.osgi.framework.BundleException: Constraint violation for package
> > > > 'javax.xml.
> > > > ws' when resolving module 7.0 between existing import
> > > 13.0.javax.xml.wsBLAMED O
> > > > N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and
> uses
> > > > constraint
> > > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > > (&(package=org.apache.cxf.jaxrs.provid
> > > > er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
> > > > )(version>=0.0.0)(!
> > > > (version>=3.0.0)))]
> > > >
> > > > On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com>
> wrote:
> > > > > Hi
> > > > >
> > > > > I've attached a patch to [1] which I've tried locally, things looks
> > ok
> > > > after
> > > > > updating to 2.2.9, i.e, I run two demos manually, greeter &
> > > greeter_rest,
> > > > >
> > > > > but the build itself is hanging in systests2/multi bundle tests.
> > > > >
> > > > > Can someone please try the patch as well and confirm it's building
> ok
> > > or
> > > > > hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done
> IMHO
> > > > >
> > > > > cheers, Sergey
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/DOSGI-74
> > > > >
> > > >
> > >
> >
>
Re: DOSGI: Update to CXF 2.2.9
Posted by Eoghan Glynn <eo...@gmail.com>.
On 28 June 2010 18:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> ServiceMix is shipping the config.properties and they may be specific to a
> specific Felix version
Well part of the config.props is version-specific (i.e. the exact version of
equinox/felix framework to use), but not so much the bit defining the
jre-1.5 and jre-1.6 specific packages.
So you could conceivably just ship a fragment to append to the user's
conf/config.properties (seeing as we already ship a
felix.config.properties.append file with a big long list of bundles to load
on startup).
A more long-term option might to ship an entire distro of karaf with dOSGi,
customized with some extra features in the internal system repo (that's the
approach I'm taking on another project that builds a CLI atop karaf, works
quite neatly with the features-maven-plugin to populate the internal repo).
The nice thing is that this is guaranteed to work out of the box, with all
external dependencies already resolved and all the versions lined up. Makes
the distro just a tad bigger tho' ;)
Cheers,
Eoghan
On 28 June 2010 18:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi Eoghan
>
> ServiceMix is shipping the config.properties and they may be specific to a
> specific Felix version ? Similarly for Equinox (even though most of the
> config.properties are probably reusable across diff versions)
> DOSGI RI does only ship the fragments of config properties which are built
> during the multi-bundle build...
>
> I'm just curious, why was the CXF import updated to include 0.0.0 ?
>
> cheers, Sergey
>
>
> On Mon, Jun 28, 2010 at 5:55 PM, Eoghan Glynn <eo...@gmail.com> wrote:
>
> > Have you tried overriding the org.osgi.framework.system.packages property
> > in
> > felix/conf/config.properties, with a list of packages specifically
> > excluding
> > javax.xml.ws.*?
> >
> > This is the approach taken by SMX to get around these sort of issues. See
> > for ex:
> >
> > wget
> >
> >
> https://www.apache.org/dist/servicemix/servicemix-4/4.2.0/apache-servicemix-4.2.0.tar.gz
> > tar -xvzf apache-servicemix-4.2.0.tar.gz
> > less apache-servicemix-4.2.0/etc/config.properties
> >
> > Note the packages in the jre-1.6 list that are specifically commented to
> > avoid a 0.0.0.0 version dragged in from the system bundle upsetting
> > version-constrained imports.
> >
> > Cheers,
> > Eoghan
> >
> > On 28 June 2010 10:34, David Bosschaert <da...@gmail.com>
> > wrote:
> >
> > > Hi Sergey,
> > >
> > > I tried your patch on my machine and can confirm that it seems to
> > > consistently hang in the multibundle system test. This wasn't the case
> > > before.
> > >
> > > The good news is that it's hanging because the multi-bundle distro is
> > > actually broken - it's so good to have tests :)
> > >
> > > I just tried it manually with Felix 3.0.1 and it tells me this
> > > org.apache.felix.framework.resolver.ResolveException: Constraint
> > > violation for package 'javax.xml.ws' when resolving module 7.0 between
> > > existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> > > (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> > > package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
> > >
> > > Cheers,
> > >
> > > David
> > >
> > > g! lb
> > > START LEVEL 85
> > > ID|State |Level|Name
> > > 0|Active | 0|System Bundle (3.0.1)
> > > 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
> > > 2|Active | 1|Apache Felix Gogo Command (0.6.0)
> > > 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> > > 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
> > > 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> > > 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
> > > 7|Installed | 84|CXF dOSGi Remote Service Admin Implementation
> > > (1.2.0.SNA
> > > PSHOT)
> > > 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
> > > 9|Active | 83|CXF Local Discovery Service Bundle
> > (1.2.0.SNAPSHOT)
> > > 10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
> > > 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0
> (1.3.0)
> > > 12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
> > > 13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0)
> > > 14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0)
> > > 15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0 (1.3.0)
> > > 16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0)
> > > 17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
> > > 18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4
> > > (1.5.4.1)
> > > 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7
> > (3.2.7.1)
> > > 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4
> (2.0.4.1)
> > > 21|Active | 73|Apache ServiceMix Bundles: xmlresolver-1.2
> > (1.2.0.1)
> > > 22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
> > > 23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3
> > (1.4.3.1)
> > > 24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0
> (1.3.0.1)
> > > 25|Active | 69|Apache ServiceMix Bundles: wsdl4j-1.6.1
> (1.6.1.1)
> > > 26|Active | 68|Apache ServiceMix Bundles: jaxb-impl-2.1.6
> > (2.1.6.1)
> > > 27|Active | 67|OPS4J Pax Web - Service (0.5.1)
> > > 28|Active | 66|spring-osgi-extender (1.2.0)
> > > 29|Active | 65|spring-osgi-core (1.2.0)
> > > 30|Active | 64|spring-osgi-io (1.2.0)
> > > 31|Active | 63|Spring AOP (2.5.6)
> > > 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
> > > 33|Active | 61|SLF4J API (1.5.10)
> > > 34|Active | 60|AOP Alliance API (1.0.0)
> > > 35|Active | 59|Spring Context (2.5.6)
> > > 36|Active | 58|Spring Beans (2.5.6)
> > > 37|Active | 57|Spring Core (2.5.6)
> > > 38|Active | 56|JDOM DOM Processor (1.0.0)
> > > 39|Active | 55|Apache Commons Logging (1.1.1)
> > > 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
> > > g! start 7
> > > RE: org.apache.felix.framework.resolver.ResolveException: Constraint
> > > violation f
> > > or package 'javax.xml.ws' when resolving module 7.0 between existing
> > > import 13.0
> > > .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> > > )(version>=2.1.0)
> > > )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > (&(package=org.a
> > > pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> > > (&(package=javax.xml
> > > .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> > > org.osgi.framework.BundleException: Constraint violation for package
> > > 'javax.xml.
> > > ws' when resolving module 7.0 between existing import
> > 13.0.javax.xml.wsBLAMED O
> > > N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and uses
> > > constraint
> > > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > > (&(package=org.apache.cxf.jaxrs.provid
> > > er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
> > > )(version>=0.0.0)(!
> > > (version>=3.0.0)))]
> > >
> > > On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> > > > Hi
> > > >
> > > > I've attached a patch to [1] which I've tried locally, things looks
> ok
> > > after
> > > > updating to 2.2.9, i.e, I run two demos manually, greeter &
> > greeter_rest,
> > > >
> > > > but the build itself is hanging in systests2/multi bundle tests.
> > > >
> > > > Can someone please try the patch as well and confirm it's building ok
> > or
> > > > hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
> > > >
> > > > cheers, Sergey
> > > >
> > > > [1] https://issues.apache.org/jira/browse/DOSGI-74
> > > >
> > >
> >
>
Re: DOSGI: Update to CXF 2.2.9
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi Eoghan
ServiceMix is shipping the config.properties and they may be specific to a
specific Felix version ? Similarly for Equinox (even though most of the
config.properties are probably reusable across diff versions)
DOSGI RI does only ship the fragments of config properties which are built
during the multi-bundle build...
I'm just curious, why was the CXF import updated to include 0.0.0 ?
cheers, Sergey
On Mon, Jun 28, 2010 at 5:55 PM, Eoghan Glynn <eo...@gmail.com> wrote:
> Have you tried overriding the org.osgi.framework.system.packages property
> in
> felix/conf/config.properties, with a list of packages specifically
> excluding
> javax.xml.ws.*?
>
> This is the approach taken by SMX to get around these sort of issues. See
> for ex:
>
> wget
>
> https://www.apache.org/dist/servicemix/servicemix-4/4.2.0/apache-servicemix-4.2.0.tar.gz
> tar -xvzf apache-servicemix-4.2.0.tar.gz
> less apache-servicemix-4.2.0/etc/config.properties
>
> Note the packages in the jre-1.6 list that are specifically commented to
> avoid a 0.0.0.0 version dragged in from the system bundle upsetting
> version-constrained imports.
>
> Cheers,
> Eoghan
>
> On 28 June 2010 10:34, David Bosschaert <da...@gmail.com>
> wrote:
>
> > Hi Sergey,
> >
> > I tried your patch on my machine and can confirm that it seems to
> > consistently hang in the multibundle system test. This wasn't the case
> > before.
> >
> > The good news is that it's hanging because the multi-bundle distro is
> > actually broken - it's so good to have tests :)
> >
> > I just tried it manually with Felix 3.0.1 and it tells me this
> > org.apache.felix.framework.resolver.ResolveException: Constraint
> > violation for package 'javax.xml.ws' when resolving module 7.0 between
> > existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> > (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> > package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
> >
> > Cheers,
> >
> > David
> >
> > g! lb
> > START LEVEL 85
> > ID|State |Level|Name
> > 0|Active | 0|System Bundle (3.0.1)
> > 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
> > 2|Active | 1|Apache Felix Gogo Command (0.6.0)
> > 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> > 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
> > 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> > 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
> > 7|Installed | 84|CXF dOSGi Remote Service Admin Implementation
> > (1.2.0.SNA
> > PSHOT)
> > 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
> > 9|Active | 83|CXF Local Discovery Service Bundle
> (1.2.0.SNAPSHOT)
> > 10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
> > 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0)
> > 12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
> > 13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0)
> > 14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0)
> > 15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0 (1.3.0)
> > 16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0)
> > 17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
> > 18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4
> > (1.5.4.1)
> > 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7
> (3.2.7.1)
> > 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4 (2.0.4.1)
> > 21|Active | 73|Apache ServiceMix Bundles: xmlresolver-1.2
> (1.2.0.1)
> > 22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
> > 23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3
> (1.4.3.1)
> > 24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0 (1.3.0.1)
> > 25|Active | 69|Apache ServiceMix Bundles: wsdl4j-1.6.1 (1.6.1.1)
> > 26|Active | 68|Apache ServiceMix Bundles: jaxb-impl-2.1.6
> (2.1.6.1)
> > 27|Active | 67|OPS4J Pax Web - Service (0.5.1)
> > 28|Active | 66|spring-osgi-extender (1.2.0)
> > 29|Active | 65|spring-osgi-core (1.2.0)
> > 30|Active | 64|spring-osgi-io (1.2.0)
> > 31|Active | 63|Spring AOP (2.5.6)
> > 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
> > 33|Active | 61|SLF4J API (1.5.10)
> > 34|Active | 60|AOP Alliance API (1.0.0)
> > 35|Active | 59|Spring Context (2.5.6)
> > 36|Active | 58|Spring Beans (2.5.6)
> > 37|Active | 57|Spring Core (2.5.6)
> > 38|Active | 56|JDOM DOM Processor (1.0.0)
> > 39|Active | 55|Apache Commons Logging (1.1.1)
> > 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
> > g! start 7
> > RE: org.apache.felix.framework.resolver.ResolveException: Constraint
> > violation f
> > or package 'javax.xml.ws' when resolving module 7.0 between existing
> > import 13.0
> > .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> > )(version>=2.1.0)
> > )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> > (&(package=org.a
> > pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> > (&(package=javax.xml
> > .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> > org.osgi.framework.BundleException: Constraint violation for package
> > 'javax.xml.
> > ws' when resolving module 7.0 between existing import
> 13.0.javax.xml.wsBLAMED O
> > N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and uses
> > constraint
> > 0.javax.xml.ws BLAMED ON [[7.0] package;
> > (&(package=org.apache.cxf.jaxrs.provid
> > er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
> > )(version>=0.0.0)(!
> > (version>=3.0.0)))]
> >
> > On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> > > Hi
> > >
> > > I've attached a patch to [1] which I've tried locally, things looks ok
> > after
> > > updating to 2.2.9, i.e, I run two demos manually, greeter &
> greeter_rest,
> > >
> > > but the build itself is hanging in systests2/multi bundle tests.
> > >
> > > Can someone please try the patch as well and confirm it's building ok
> or
> > > hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
> > >
> > > cheers, Sergey
> > >
> > > [1] https://issues.apache.org/jira/browse/DOSGI-74
> > >
> >
>
Re: DOSGI: Update to CXF 2.2.9
Posted by Eoghan Glynn <eo...@gmail.com>.
Have you tried overriding the org.osgi.framework.system.packages property in
felix/conf/config.properties, with a list of packages specifically excluding
javax.xml.ws.*?
This is the approach taken by SMX to get around these sort of issues. See
for ex:
wget
https://www.apache.org/dist/servicemix/servicemix-4/4.2.0/apache-servicemix-4.2.0.tar.gz
tar -xvzf apache-servicemix-4.2.0.tar.gz
less apache-servicemix-4.2.0/etc/config.properties
Note the packages in the jre-1.6 list that are specifically commented to
avoid a 0.0.0.0 version dragged in from the system bundle upsetting
version-constrained imports.
Cheers,
Eoghan
On 28 June 2010 10:34, David Bosschaert <da...@gmail.com> wrote:
> Hi Sergey,
>
> I tried your patch on my machine and can confirm that it seems to
> consistently hang in the multibundle system test. This wasn't the case
> before.
>
> The good news is that it's hanging because the multi-bundle distro is
> actually broken - it's so good to have tests :)
>
> I just tried it manually with Felix 3.0.1 and it tells me this
> org.apache.felix.framework.resolver.ResolveException: Constraint
> violation for package 'javax.xml.ws' when resolving module 7.0 between
> existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
> 0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
> package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
>
> Cheers,
>
> David
>
> g! lb
> START LEVEL 85
> ID|State |Level|Name
> 0|Active | 0|System Bundle (3.0.1)
> 1|Active | 1|Apache Felix Bundle Repository (1.6.2)
> 2|Active | 1|Apache Felix Gogo Command (0.6.0)
> 3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
> 4|Active | 1|Apache Felix Gogo Shell (0.6.0)
> 5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
> 6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
> 7|Installed | 84|CXF dOSGi Remote Service Admin Implementation
> (1.2.0.SNA
> PSHOT)
> 8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
> 9|Active | 83|CXF Local Discovery Service Bundle (1.2.0.SNAPSHOT)
> 10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
> 11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0)
> 12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
> 13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0)
> 14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0)
> 15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0 (1.3.0)
> 16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0)
> 17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
> 18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4
> (1.5.4.1)
> 19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7 (3.2.7.1)
> 20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4 (2.0.4.1)
> 21|Active | 73|Apache ServiceMix Bundles: xmlresolver-1.2 (1.2.0.1)
> 22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
> 23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3 (1.4.3.1)
> 24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0 (1.3.0.1)
> 25|Active | 69|Apache ServiceMix Bundles: wsdl4j-1.6.1 (1.6.1.1)
> 26|Active | 68|Apache ServiceMix Bundles: jaxb-impl-2.1.6 (2.1.6.1)
> 27|Active | 67|OPS4J Pax Web - Service (0.5.1)
> 28|Active | 66|spring-osgi-extender (1.2.0)
> 29|Active | 65|spring-osgi-core (1.2.0)
> 30|Active | 64|spring-osgi-io (1.2.0)
> 31|Active | 63|Spring AOP (2.5.6)
> 32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
> 33|Active | 61|SLF4J API (1.5.10)
> 34|Active | 60|AOP Alliance API (1.0.0)
> 35|Active | 59|Spring Context (2.5.6)
> 36|Active | 58|Spring Beans (2.5.6)
> 37|Active | 57|Spring Core (2.5.6)
> 38|Active | 56|JDOM DOM Processor (1.0.0)
> 39|Active | 55|Apache Commons Logging (1.1.1)
> 40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
> g! start 7
> RE: org.apache.felix.framework.resolver.ResolveException: Constraint
> violation f
> or package 'javax.xml.ws' when resolving module 7.0 between existing
> import 13.0
> .javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws
> )(version>=2.1.0)
> )] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=org.a
> pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package;
> (&(package=javax.xml
> .ws)(version>=0.0.0)(!(version>=3.0.0)))]
> org.osgi.framework.BundleException: Constraint violation for package
> 'javax.xml.
> ws' when resolving module 7.0 between existing import 13.0.javax.xml.wsBLAMED O
> N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and uses
> constraint
> 0.javax.xml.ws BLAMED ON [[7.0] package;
> (&(package=org.apache.cxf.jaxrs.provid
> er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws
> )(version>=0.0.0)(!
> (version>=3.0.0)))]
>
> On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> > Hi
> >
> > I've attached a patch to [1] which I've tried locally, things looks ok
> after
> > updating to 2.2.9, i.e, I run two demos manually, greeter & greeter_rest,
> >
> > but the build itself is hanging in systests2/multi bundle tests.
> >
> > Can someone please try the patch as well and confirm it's building ok or
> > hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
> >
> > cheers, Sergey
> >
> > [1] https://issues.apache.org/jira/browse/DOSGI-74
> >
>
Re: DOSGI: Update to CXF 2.2.9
Posted by David Bosschaert <da...@gmail.com>.
Hi Sergey,
I tried your patch on my machine and can confirm that it seems to
consistently hang in the multibundle system test. This wasn't the case
before.
The good news is that it's hanging because the multi-bundle distro is
actually broken - it's so good to have tests :)
I just tried it manually with Felix 3.0.1 and it tells me this
org.apache.felix.framework.resolver.ResolveException: Constraint
violation for package 'javax.xml.ws' when resolving module 7.0 between
existing import 13.0.javax.xml.ws BLAMED ON [[7.0] package;
(&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
0.javax.xml.ws BLAMED ON [[7.0] package;
(&(package=org.apache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0]
package; (&(package=javax.xml.ws)(version>=0.0.0)(!(version>=3.0.0)))]
Cheers,
David
g! lb
START LEVEL 85
ID|State |Level|Name
0|Active | 0|System Bundle (3.0.1)
1|Active | 1|Apache Felix Bundle Repository (1.6.2)
2|Active | 1|Apache Felix Gogo Command (0.6.0)
3|Active | 1|Apache Felix Gogo Runtime (0.6.0)
4|Active | 1|Apache Felix Gogo Shell (0.6.0)
5|Active | 85|CXF dOSGi Topology Manager (1.2.0.SNAPSHOT)
6|Active | 53|geronimo-javamail_1.4_spec (1.2.0)
7|Installed | 84|CXF dOSGi Remote Service Admin Implementation (1.2.0.SNA
PSHOT)
8|Active | 52|geronimo-activation_1.1_spec (1.0.2)
9|Active | 83|CXF Local Discovery Service Bundle (1.2.0.SNAPSHOT)
10|Active | 51|geronimo-annotation_1.0_spec (1.1.1)
11|Active | 82|Apache ServiceMix Specs :: JSR311 API 1.0 (1.3.0)
12|Active | 50|osgi.compendium (4.1.0.build-200702212030)
13|Active | 81|Apache ServiceMix Specs :: JAXWS API 2.1 (1.3.0)
14|Active | 80|Apache ServiceMix Specs :: JAXB API 2.1 (1.3.0)
15|Active | 79|Apache ServiceMix Specs :: STAX API 1.0 (1.3.0)
16|Active | 78|Apache ServiceMix Specs :: SAAJ API 1.3 (1.3.0)
17|Active | 77|Apache CXF Minimal Bundle Jar (2.2.9)
18|Active | 76|Apache ServiceMix Bundles: commons-pool-1.5.4 (1.5.4.1)
19|Active | 75|Apache ServiceMix Bundles: woodstox-3.2.7 (3.2.7.1)
20|Active | 74|Apache ServiceMix Bundles: neethi-2.0.4 (2.0.4.1)
21|Active | 73|Apache ServiceMix Bundles: xmlresolver-1.2 (1.2.0.1)
22|Active | 72|Apache ServiceMix Bundles: asm-2.2.3 (2.2.3.1)
23|Active | 71|Apache ServiceMix Bundles: xmlschema-1.4.3 (1.4.3.1)
24|Active | 70|Apache ServiceMix Bundles: xmlsec-1.3.0 (1.3.0.1)
25|Active | 69|Apache ServiceMix Bundles: wsdl4j-1.6.1 (1.6.1.1)
26|Active | 68|Apache ServiceMix Bundles: jaxb-impl-2.1.6 (2.1.6.1)
27|Active | 67|OPS4J Pax Web - Service (0.5.1)
28|Active | 66|spring-osgi-extender (1.2.0)
29|Active | 65|spring-osgi-core (1.2.0)
30|Active | 64|spring-osgi-io (1.2.0)
31|Active | 63|Spring AOP (2.5.6)
32|Resolved | 62|SLF4J Jakarta Commons Logging Binding (1.5.10)
33|Active | 61|SLF4J API (1.5.10)
34|Active | 60|AOP Alliance API (1.0.0)
35|Active | 59|Spring Context (2.5.6)
36|Active | 58|Spring Beans (2.5.6)
37|Active | 57|Spring Core (2.5.6)
38|Active | 56|JDOM DOM Processor (1.0.0)
39|Active | 55|Apache Commons Logging (1.1.1)
40|Active | 54|geronimo-ws-metadata_2.0_spec (1.1.2)
g! start 7
RE: org.apache.felix.framework.resolver.ResolveException: Constraint violation f
or package 'javax.xml.ws' when resolving module 7.0 between existing import 13.0
.javax.xml.ws BLAMED ON [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0)
)] and uses constraint 0.javax.xml.ws BLAMED ON [[7.0] package; (&(package=org.a
pache.cxf.jaxrs.provider)(version>=2.2.0)), [17.0] package; (&(package=javax.xml
.ws)(version>=0.0.0)(!(version>=3.0.0)))]
org.osgi.framework.BundleException: Constraint violation for package 'javax.xml.
ws' when resolving module 7.0 between existing import 13.0.javax.xml.ws BLAMED O
N [[7.0] package; (&(package=javax.xml.ws)(version>=2.1.0))] and uses constraint
0.javax.xml.ws BLAMED ON [[7.0] package; (&(package=org.apache.cxf.jaxrs.provid
er)(version>=2.2.0)), [17.0] package; (&(package=javax.xml.ws)(version>=0.0.0)(!
(version>=3.0.0)))]
On 26 June 2010 17:19, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi
>
> I've attached a patch to [1] which I've tried locally, things looks ok after
> updating to 2.2.9, i.e, I run two demos manually, greeter & greeter_rest,
>
> but the build itself is hanging in systests2/multi bundle tests.
>
> Can someone please try the patch as well and confirm it's building ok or
> hanging ? DOSGI 1.1 uses 2.5 and moving to 2.2.9 need to be done IMHO
>
> cheers, Sergey
>
> [1] https://issues.apache.org/jira/browse/DOSGI-74
>