Re: DOSGI: Update to CXF 2.2.9
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
> 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 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: [JiBX DataBinding] An issue when feeding the XMLStreamReader to JiBX framework
Nilupa Bandara wrote: On Sat, Jun 26, 2010 at 1:00 AM, Dennis Sosnoski wrote: ... Nilupa, I've updated JiBX CVS with this change and posted new 1.2.3-SNAPSHOT jars to the maven1 repository at http://jibx.sourceforge.net/maven/jibx/jars/ Try adding the call to startTag() after constructing the StAXReaderWrapper, it should get you past the problem. Hi, Still it gives an error even if I call the startTag() after instantiating the StAXReaderWrapper object[1]. However if I call same method twice startTag(), it works[2] It sounds like the code is somehow reading beyond the end of the element you're having JiBX unmarshal, to the enclosing element end tag. I don't know why this would be occurring. Can you send me the stack traces you get when (1) you don't call wrapper.startTag() at all, and when (2) you just call it once? That may help me determine what's going wrong. Thanks, - Dennis
Re: [JiBX DataBinding] An issue when feeding the XMLStreamReader to JiBX framework
Never mind, I think I found the issue. I've changed the StAXReaderWrapper code so that you should no longer need to call startTag() at all and have changed that back to a private method. Please try the latest 1.2.3-SNAPSHOT jars and verify that this now works. Thanks again, - Dennis Dennis Sosnoski wrote: Nilupa Bandara wrote: On Sat, Jun 26, 2010 at 1:00 AM, Dennis Sosnoski wrote: ... Nilupa, I've updated JiBX CVS with this change and posted new 1.2.3-SNAPSHOT jars to the maven1 repository at http://jibx.sourceforge.net/maven/jibx/jars/ Try adding the call to startTag() after constructing the StAXReaderWrapper, it should get you past the problem. Hi, Still it gives an error even if I call the startTag() after instantiating the StAXReaderWrapper object[1]. However if I call same method twice startTag(), it works[2] It sounds like the code is somehow reading beyond the end of the element you're having JiBX unmarshal, to the enclosing element end tag. I don't know why this would be occurring. Can you send me the stack traces you get when (1) you don't call wrapper.startTag() at all, and when (2) you just call it once? That may help me determine what's going wrong. Thanks, - Dennis
