[DOSGi] Reworking the system tests
Hi all, One of the things to-do for the DOSGi refactoring work that's currently happening on trunk is to re-enable the system tests. Now both Sergey and I have been fighting with the spring-osgi based testing system that's there before and I can tell you it's generally no fun at all. The biggest problem that I've encountered with it is the interference of the test framework with the CXF-DOSGi code as they both use Spring-DM but sometimes have conflicting requirements. So I'd like to spend a little bit of time refactoring the system tests to use Pax-Exam. I haven't used it in anger yet but I've heard good things about it and it should not suffer from the interference problem. Thoughts anyone? David
Re: [DOSGi] Reworking the system tests
David, One thing to note about pax-exam is that its doesn't AFAIK have a feature analogous to the spring-osgi-test support for accessing and adding to the manifest for the on-the-fly bundle. Now I don't know whether we could possibly live without this manifest-mangling as currently done by the dOSGi systests, specifically setting the DynamicImport-Package header to *. If we can live without this setting, no worries. If not, its something to consider about adopting pax-exam. Cheers, Eoghan 2010/1/22 dav...@apache.org Hi all, One of the things to-do for the DOSGi refactoring work that's currently happening on trunk is to re-enable the system tests. Now both Sergey and I have been fighting with the spring-osgi based testing system that's there before and I can tell you it's generally no fun at all. The biggest problem that I've encountered with it is the interference of the test framework with the CXF-DOSGi code as they both use Spring-DM but sometimes have conflicting requirements. So I'd like to spend a little bit of time refactoring the system tests to use Pax-Exam. I haven't used it in anger yet but I've heard good things about it and it should not suffer from the interference problem. Thoughts anyone? David
Re: [DOSGi] Reworking the system tests
Yep, now that you mention it, tiny bundles were what Toni Menzel of the PAX team suggested using when we tripped over a similar issue with the SMX integration tests during the Karaf switch-over. Cheers, Eoghan 2010/1/22 dav...@apache.org Thanks for the heads up Eoghan. I understood that the recent tiny bundles integration could take care of this. Have a look at the bottom example in http://wiki.ops4j.org/display/paxexam/ExamAndTinybundles. Do you think that will do it? Cheers, David 2010/1/22 Eoghan Glynn eogl...@gmail.com: David, One thing to note about pax-exam is that its doesn't AFAIK have a feature analogous to the spring-osgi-test support for accessing and adding to the manifest for the on-the-fly bundle. Now I don't know whether we could possibly live without this manifest-mangling as currently done by the dOSGi systests, specifically setting the DynamicImport-Package header to *. If we can live without this setting, no worries. If not, its something to consider about adopting pax-exam. Cheers, Eoghan 2010/1/22 dav...@apache.org Hi all, One of the things to-do for the DOSGi refactoring work that's currently happening on trunk is to re-enable the system tests. Now both Sergey and I have been fighting with the spring-osgi based testing system that's there before and I can tell you it's generally no fun at all. The biggest problem that I've encountered with it is the interference of the test framework with the CXF-DOSGi code as they both use Spring-DM but sometimes have conflicting requirements. So I'd like to spend a little bit of time refactoring the system tests to use Pax-Exam. I haven't used it in anger yet but I've heard good things about it and it should not suffer from the interference problem. Thoughts anyone? David
Re: JAXB and JAX-RS under CXF
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 bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org 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 bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org 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
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 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 bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org 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
Re: JAXB and JAX-RS under CXF
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 bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org 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 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 bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org 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
Re: JAXB and JAX-RS under CXF
Excellent, thanks. Please ping the Felix team, and I'll play with this project too... cheers, Sergey - Original Message - From: Daniel Bimschas bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org 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 bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org 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 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 bimsc...@itm.uni-luebeck.de To: dev@cxf.apache.org 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
Re: [VOTE] Release CXF 2.2.6
+1 - Original Message - From: Daniel Kulp dk...@apache.org To: dev@cxf.apache.org Sent: Wednesday, January 20, 2010 2:44:41 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: [VOTE] Release CXF 2.2.6 This is a vote to release CXF 2.2.6 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.2.5 release. Over 78 JIRA issues are resolved for 2.2.6. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314381styleName=HtmlprojectId=12310511Create=Create The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-057/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-057/org/apache/cxf/apache-cxf/2.2.6 This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.6 The vote will be open for 72 hours. Here is my +1. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
[RESULT] [VOTE] Release CXF 2.1.9
With 11 +1 votes and no other votes, this vote passes. I'll get the artifacts syncing to central and onto the mirrors. Dan On Tue January 19 2010 8:41:00 pm Daniel Kulp wrote: This is a vote to release CXF 2.1.9 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.1.8 release. Over 43 JIRA issues are resolved for 2.1.9 *Note:* as announced earlier this will be the last 2.1.x release of Apache CXF. Users are encouraged to start migrating to 2.2.x. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314380sty leName=HtmlprojectId=12310511Create=Create The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-056/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-056/org/apa che/cxf/apache-cxf/2.1.9 This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.1.9 The vote will be open for 72 hours. Here is my +1. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog signature.asc Description: This is a digitally signed message part.
[RESULT][VOTE] Release CXF 2.2.6
With 12 +1 votes and no other votes, this vote passes. I'll get it syncing to central and onto the mirrors. Dan On Tue January 19 2010 8:44:41 pm Daniel Kulp wrote: This is a vote to release CXF 2.2.6 Once again, there have been a bunch of bug fixes and enhancements that have been done compared to the 2.2.5 release. Over 78 JIRA issues are resolved for 2.2.6. List of issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12314381sty leName=HtmlprojectId=12310511Create=Create The Maven staging area is at: https://repository.apache.org/content/repositories/orgapachecxf-057/ The distributions are in: https://repository.apache.org/content/repositories/orgapachecxf-057/org/apa che/cxf/apache-cxf/2.2.6 This release is tagged at: http://svn.apache.org/repos/asf/cxf/tags/cxf-2.2.6 The vote will be open for 72 hours. Here is my +1. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog
