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,
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 th
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 cu
Hi Eoghan,
On 17 July 2010 12:59, Eoghan Glynn 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 TimeoutExc
> 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.testAccessE
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 o
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 e
> 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
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
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.p
On Mon, Jun 28, 2010 at 7:20 PM, Eoghan Glynn wrote:
> On 28 June 2010 18:19, Sergey Beryozkin 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
>
On 28 June 2010 18:19, Sergey Beryozkin 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
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
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
duri
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/s
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 Dav
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.bosscha...@gmail.com> wrote:
> Hi Sergey,
>
> I think you need to dive a little deeper to see what the actual
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 wrote:
> Hi David
>
> So
> (version>=2.1.0)
>
> does not intersect with
>
> (version>=0.0.0)(!(version>=3.0.0)
>
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.bosscha...@gmail.com> wrote:
> Hi Sergey,
>
> I tried your patch on my machine and can confirm that it seems to
> consistently h
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 manual
20 matches
Mail list logo
