Damnit. I just changed the Pax-Runner configuration to only use Equinox and now the tests pass, everything seems fine. Are you interested in a tiny Maven-based project demonstrating the issue?
Am 22.01.2010 um 16:58 schrieb Sergey Beryozkin: > Hi, > > please see more comments inline > > <snip/> > >> just one more question. I converted a plain (non-OSGi) JAX-RS project to >> DOSGi-based CXF. Now, for some of my JAXB annotated classes I get the error >> message: >> >> com.sun.istack.internal.SAXException2: unable to marshal type "a.b.c.X" as >> an element because it is missing an @XmlRootElement annotation >> >> S.B : Do those objects actually have @XmlRootElement ? > > Yes, they do. > >> >> I use Pax Exam to set up a test case that marshalls the object to a byte[] >> and unmarshalls it afterwards from it. >> >> Do you know that error? >> >> S.B : yes, usually it is to do with @XmlRootElement being not present or, in >> OSGI case, being 'lost' at runtime, due to a missing import package >> value...You can condigure DOSGI RI to not require @XmlRootElement for JAXRS >> services... > > I checked the packaged bundle. It definitely has the JAXB annotation packages > imported (which is no wonder as I'm using maven-bundle-plugin with bnd to > generate the Manifest). > >> S.B : for some reasons there're still invisible to the JAXB runtime. One of >> users reported a similar issue the other day, JAXB classes have been moved >> to a bundle separate from the application one. I don't recall what the fix >> was, it is just a visibility issue which can be solved at the OSGI level. >> Please attach a sample bundle if it won't work... > > How can I configure it for use without annotations? > >> S.B : You'll need to register a custom JAXBElementProvider as a >> MessageBodyReader and MessageBodyWriter OSGI service and set a property on >> it (marshalAsJaxbElement). One will be able to do the same from Spring DM >> context once we fix the issue of discovering well-known spring beans... > >> >> Why is CXF behaving different than "plain" JAXB? >> >> S.B : what exactly is different ? > > Just that plain works, and OSGi-based fails because of the errors mentioned > above. But I guess that's "misconfiguration". > >> S.B : yes, it's an OSGI configuration issue. DOSGI can't help on its >> own...At the last resort try DynamicImport... > > cheers, Sergey > >> >> Is it using a different JAXB implementation at all? And if yes, is it >> possible to switch to the implementation included in the JVM? >> >> Kind regards, >> Daniel >> >> Am 21.01.2010 um 13:01 schrieb Sergey Beryozkin: >> >>> Hi >>> >>> Please see a comment with S.B >>> >>> ----- Original Message ----- From: "Daniel Bimschas" >>> <[email protected]> >>> To: <[email protected]> >>> Sent: Wednesday, January 20, 2010 6:07 PM >>> Subject: Re: JAXB and JAX-RS under CXF >>> >>> >>> Oh great thing Sergey, >>> >>> thanks for that answer. I just tried and it works just fine. In fact, >>> documentation was either misleading or I misread. The documentation says >>> >>> "This property has a limited value for JAXRS services as JAXB is supported >>> by default, the only supported value is 'aegis' and it is a shortcut for >>> registering an Aegis provider [...]" >>> >>> which is a little hard to understand. One the one hand it says JAXB is >>> supported, but on the other hand 'aegis' is the only value you're allowed >>> to use. So this confused me. >>> >>>> S.B : it kind of does not makse sense, now that I read it again. (CXF) >>>> JAXRS do not use (CXF)databindings as often as they use 'providers', >>>> technically both terms are probably identical, but I wanted to not require >>>> users to set this property given that they will probably want to register >>>> say a DataBindingProvider provider delegating to CXF Aegis as OSGI >>>> service, with some custom configuration, etc...That said, for simple >>>> cases, letting users just to do "org.apache.cxf.rs.databinding=atom" would >>>> also make sense... >>> >>> JAXB will be supported with or without "org.apache.cxf.rs.databinding=jaxb" >>> but I'll look into simplifying the documentation and enhancing a bit the >>> way this org.apache.cxf.rs.databinding property is handled... >>> >>> thanks, Sergey >>> >>> >>> Thanks for the clarification and the impressively fast response! >>> >>> Regards, >>> Daniel >>> >>> Am 20.01.2010 um 18:20 schrieb Sergey Beryozkin: >>> >>>> Hi >>>> >>>> It is possible. It has to work, you do not even has to enable it for >>>> JAXRS; for DOSGI-RI/JAX-RS it is a default databinding given that the >>>> JAXRS spec requires the JAXB support OTB so I thought asking users to >>>> explictly add org.apache.cxf.rs.databinding=jaxb just to enable JAXB would >>>> be too much... >>>> Are you seeing any issues ? I'm thinking may be I've just done another >>>> piece of the documentation which is confusing ? One thing I'm saying there >>>> is that if you do not want to have your bundle modified for JAXB be >>>> supported at runtime as well as to explicitly annotate beans with >>>> @XmlRootElement and friends (that is, to import JAXB packages) then if it >>>> is JAX-RS only you can register a custom (CXF JAXRS) JAXBElementProvider >>>> and tell it to use JAXBElement internally and that is it... >>>> >>>> cheers, Sergey >>>> >>>> ----- Original Message ----- From: "Daniel Bimschas" >>>> <[email protected]> >>>> To: <[email protected]> >>>> Sent: Wednesday, January 20, 2010 5:07 PM >>>> Subject: JAXB and JAX-RS under CXF >>>> >>>> >>>> Hi list, >>>> >>>> following the DOSGi reference [1] I see that it's not possible to use JAXB >>>> under JAX-RS but with JAX-WS. Is that correct? And what is the reason for >>>> it? >>>> >>>> Kind regards, >>>> Daniel >>>> >>>> [1] http://cxf.apache.org/distributed-osgi-reference.html >>> >>> -- >>> M.Sc. Daniel Bimschas >>> Institute of Telematics, University of Lübeck >>> http://www.itm.uni-luebeck.de/users/bimschas >>> Ratzeburger Allee 160, 23538 Lübeck, Germany >>> Phone: +49 451 500 5389 >>> >>> >> >> -- >> M.Sc. Daniel Bimschas >> Institute of Telematics, University of Lübeck >> http://www.itm.uni-luebeck.de/users/bimschas >> Ratzeburger Allee 160, 23538 Lübeck, Germany >> Phone: +49 451 500 5389 >> >> > > -- > M.Sc. Daniel Bimschas > Institute of Telematics, University of Lübeck > http://www.itm.uni-luebeck.de/users/bimschas > Ratzeburger Allee 160, 23538 Lübeck, Germany > Phone: +49 451 500 5389 > > -- M.Sc. Daniel Bimschas Institute of Telematics, University of Lübeck http://www.itm.uni-luebeck.de/users/bimschas Ratzeburger Allee 160, 23538 Lübeck, Germany Phone: +49 451 500 5389
smime.p7s
Description: S/MIME cryptographic signature
