> 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 <[email protected]> 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 <[email protected]> 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
> > [email protected]
> > http://dankulp.com/blog
> >
>
