Re: JAXB and JAX-RS under CXF

2010-01-27 Thread Sergey Beryozkin

Hi Daniel

It is probably JDK 1.6 that you're using ? I think I did manage to expose JAXB beans on Felix using a single bundle distribution 
with 1.5 (by moodifying one of the existing DOSGi demos)...


cheers, Sergey

- Original Message - 
From: "Daniel Bimschas" 

To: 
Sent: Tuesday, January 26, 2010 10:01 PM
Subject: Re: JAXB and JAX-RS under CXF


Hi Sergey,

thanks for your efforts. The only thing I had to do is to add javax.xml.bind.* packages to the boot delegation classpath of my OSGi 
environment. A point I simply didn't think about as most JRE-classes are usually present by default.


Kind regards,
Daniel

Am 22.01.2010 um 17:46 schrieb Sergey Beryozkin:


Excellent, thanks. Please ping the Felix team, and I'll play with this project 
too...

cheers, Sergey

- Original Message - From: "Daniel Bimschas" 

To: 
Sent: Friday, January 22, 2010 4:43 PM
Subject: Re: JAXB and JAX-RS under CXF


Sergey,

I'm unsure if that is something that can be fixed at DOSGi level. I just made a demo project and attached it to this mail. I will 
also send it to the Apache Felix guys who hopefully can inspect the issue (if they care) :D because felix's the framework that 
doesn't work.


Regards,
Daniel








Am 22.01.2010 um 17:21 schrieb Sergey Beryozkin:

Ok, great it started working for you... Do you reckon that something can actually be fixed at the DOSGI level ? If yes then 
indeed, please open a DOSGI issue and attach a project. But it looks like it is a container-specific issue ? Which one were you 
using originally, before switching to Equinox ?


thanks, Sergey


- Original Message - From: "Daniel Bimschas" 

To: 
Sent: Friday, January 22, 2010 4:13 PM
Subject: Re: JAXB and JAX-RS under CXF


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



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" 

To: 
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 [...]

Re: JAXB and JAX-RS under CXF

2010-01-26 Thread Daniel Bimschas
Hi Sergey,

thanks for your efforts. The only thing I had to do is to add javax.xml.bind.* 
packages to the boot delegation classpath of my OSGi environment. A point I 
simply didn't think about as most JRE-classes are usually present by default.

Kind regards,
Daniel

Am 22.01.2010 um 17:46 schrieb Sergey Beryozkin:

> Excellent, thanks. Please ping the Felix team, and I'll play with this 
> project too...
> 
> cheers, Sergey
> 
> - Original Message - From: "Daniel Bimschas" 
> 
> To: 
> Sent: Friday, January 22, 2010 4:43 PM
> Subject: Re: JAXB and JAX-RS under CXF
> 
> 
> Sergey,
> 
> I'm unsure if that is something that can be fixed at DOSGi level. I just made 
> a demo project and attached it to this mail. I will also send it to the 
> Apache Felix guys who hopefully can inspect the issue (if they care) :D 
> because felix's the framework that doesn't work.
> 
> Regards,
> Daniel
> 
> 
> 
> 
> 
> 
> 
> 
> Am 22.01.2010 um 17:21 schrieb Sergey Beryozkin:
> 
>> Ok, great it started working for you... Do you reckon that something can 
>> actually be fixed at the DOSGI level ? If yes then indeed, please open a 
>> DOSGI issue and attach a project. But it looks like it is a 
>> container-specific issue ? Which one were you using originally, before 
>> switching to Equinox ?
>> 
>> thanks, Sergey
>> 
>> 
>> - Original Message - From: "Daniel Bimschas" 
>> 
>> To: 
>> Sent: Friday, January 22, 2010 4:13 PM
>> Subject: Re: JAXB and JAX-RS under CXF
>> 
>> 
>> 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
>>> 
>>> 
>>> 
>>>> 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 l

Re: JAXB and JAX-RS under CXF

2010-01-22 Thread Sergey Beryozkin

Excellent, thanks. Please ping the Felix team, and I'll play with this project 
too...

cheers, Sergey

- Original Message - 
From: "Daniel Bimschas" 

To: 
Sent: Friday, January 22, 2010 4:43 PM
Subject: Re: JAXB and JAX-RS under CXF


Sergey,

I'm unsure if that is something that can be fixed at DOSGi level. I just made a demo project and attached it to this mail. I will 
also send it to the Apache Felix guys who hopefully can inspect the issue (if they care) :D because felix's the framework that 
doesn't work.


Regards,
Daniel








Am 22.01.2010 um 17:21 schrieb Sergey Beryozkin:

Ok, great it started working for you... Do you reckon that something can actually be fixed at the DOSGI level ? If yes then 
indeed, please open a DOSGI issue and attach a project. But it looks like it is a container-specific issue ? Which one were you 
using originally, before switching to Equinox ?


thanks, Sergey


- Original Message - From: "Daniel Bimschas" 

To: 
Sent: Friday, January 22, 2010 4:13 PM
Subject: Re: JAXB and JAX-RS under CXF


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



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" 

To: 
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.databin

Re: JAXB and JAX-RS under CXF

2010-01-22 Thread Daniel Bimschas
Sergey,

I'm unsure if that is something that can be fixed at DOSGi level. I just made a 
demo project and attached it to this mail. I will also send it to the Apache 
Felix guys who hopefully can inspect the issue (if they care) :D because 
felix's the framework that doesn't work.

Regards,
Daniel



jaxb-cxf-issue-project.tar.gz
Description: GNU Zip compressed data

Am 22.01.2010 um 17:21 schrieb Sergey Beryozkin:

> Ok, great it started working for you... Do you reckon that something can 
> actually be fixed at the DOSGI level ? If yes then indeed, please open a 
> DOSGI issue and attach a project. But it looks like it is a 
> container-specific issue ? Which one were you using originally, before 
> switching to Equinox ?
> 
> thanks, Sergey
> 
> 
> - Original Message - From: "Daniel Bimschas" 
> 
> To: 
> Sent: Friday, January 22, 2010 4:13 PM
> Subject: Re: JAXB and JAX-RS under CXF
> 
> 
> 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
>> 
>> 
>> 
>>> 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" 
>>>> 
>>>> To: 
>>>> 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
>>>> 
>>

Re: JAXB and JAX-RS under CXF

2010-01-22 Thread Sergey Beryozkin
Ok, great it started working for you... Do you reckon that something can actually be fixed at the DOSGI level ? If yes then indeed, 
please open a DOSGI issue and attach a project. But it looks like it is a container-specific issue ? Which one were you using 
originally, before switching to Equinox ?


thanks, Sergey


- Original Message - 
From: "Daniel Bimschas" 

To: 
Sent: Friday, January 22, 2010 4:13 PM
Subject: Re: JAXB and JAX-RS under CXF


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



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" 

To: 
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

Re: JAXB and JAX-RS under CXF

2010-01-22 Thread Daniel Bimschas
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
> 
> 
> 
>> 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" 
>>> 
>>> To: 
>>> 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 enhanci

Re: JAXB and JAX-RS under CXF

2010-01-22 Thread Sergey Beryozkin

Hi,

please see more comments inline



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" 

To: 
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" 

To: 
Sent: Wednesday, January 20, 2010 5:07 PM
Subject: JAXB and JAX-RS under CXF


Hi list,

following the DOSG

Re: JAXB and JAX-RS under CXF

2010-01-22 Thread Daniel Bimschas
Sergey,

I checked, please see my further questions below...

Am 22.01.2010 um 16:10 schrieb Sergey Beryozkin:

> Hi Daniel
> 
> please see comments with S.B
> 
> thanks, Sergey
> 
> - Original Message - From: "Daniel Bimschas" 
> 
> To: 
> Sent: Friday, January 22, 2010 3:00 PM
> Subject: Re: JAXB and JAX-RS under CXF
> 
> 
> Thanks Sergey,
> 
> 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).

How can I configure it for use without annotations?

> 
> 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".

> 
> 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" 
>> 
>> To: 
>> 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 JA

Re: JAXB and JAX-RS under CXF

2010-01-22 Thread Sergey Beryozkin

Hi Daniel

please see comments with S.B

thanks, Sergey

- Original Message - 
From: "Daniel Bimschas" 

To: 
Sent: Friday, January 22, 2010 3:00 PM
Subject: Re: JAXB and JAX-RS under CXF


Thanks Sergey,

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 ?

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...


Why is CXF behaving different than "plain" JAXB?

S.B : what exactly is different ?

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" 

To: 
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" 

To: 
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




Re: JAXB and JAX-RS under CXF

2010-01-22 Thread Daniel Bimschas
Thanks Sergey,

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

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? Why is CXF behaving different than "plain" JAXB? 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" 
> 
> To: 
> 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" 
>> 
>> To: 
>> 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



smime.p7s
Description: S/MIME cryptographic signature


Re: JAXB and JAX-RS under CXF

2010-01-21 Thread Sergey Beryozkin

Hi

Please see a comment with S.B

- Original Message - 
From: "Daniel Bimschas" 

To: 
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" 

To: 
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




Re: JAXB and JAX-RS under CXF

2010-01-20 Thread Daniel Bimschas
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.

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" 
> 
> To: 
> 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



smime.p7s
Description: S/MIME cryptographic signature


Re: JAXB and JAX-RS under CXF

2010-01-20 Thread 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" 

To: 
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