Hi Josh >> Have you looked into jackson.codehaus.org's JSON provider? > > >Not yet. Should I? Is there a way to plug this into the DOSGi >implementation (which I use -- possibly inappropriately -- only as a means >to declarative publish my JAX-WS and JAX-RS endpoints)?
If you decide to try a 3rd part (JAXRS) provider like Jackson then you'd need to wrap it in a bundle and register an instance of it as MessageBodyReader/MessageBodyWriter from the Activator and DOSGI JAXRS will pick it up Alternatively, wrap it in your own provider (to be shipped with your application bundle) and then just refer to your provider class using org.apache.cxf.rs.provider property... cheers, Sergey Josh Holtzman wrote: > > On Mon, Sep 7, 2009 at 2:41 PM, Benson Margulies > <[email protected]>wrote: > >> There have been some email threads on this list about sharing >> configuration >> and code between conventional web services and JAX-RS. At the same time, >> we're having a bit of a debate over on the dev side. So I'm writing this >> message to solicit some thoughts from users. >> >> > I'm not sure whether this will help either side of the debate, but I > thought > I'd share my approach in case it's useful to you. I build my services > with > no JAX-WS or JAX-RS configuration or code at all. I then add separate > JAX-WS and JAX-RS endpoints, which do not implement the service API, but > implement something close to it. For instance "public void > updateEntity(Entity entity)" works just fine for a java service and in > JAX-WS, but in JAX-RS I want to return a Response object rather than void. > Asynchronous calls are also handled differently depending on the endpoint > "style". > > The JAX-WS and -RS endpoints delegate all of their logic to the central > pojo > service, so the endpoints become purely about publishing the remote > services > in a way that makes the most sense for the client. This is a fundamental > design decision that winds up requiring more code in the end, but it also > allows separation of business logic from all of the latest-and-greatest > endpoint technologies. > > >> Do you use JSON, XML, or both? If you use JSON, are you happy with it? >> >> > Both, but I'm just starting to play around with CXF's JSON support. I > need > pretty tight control over the JSON/P that my REST endpoints produce, so > I'll > likely wind up serializing entities myself in at least some cases. > > >> Have you looked into jackson.codehaus.org's JSON provider? >> >> > Not yet. Should I? Is there a way to plug this into the DOSGi > implementation (which I use -- possibly inappropriately -- only as a means > to declarative publish my JAX-WS and JAX-RS endpoints)? > > >> If you have an existing conventional service, and you are looking to add >> (or >> have added) JSON support, read on. >> >> How much investment do you have in data binding configuration? I'm >> particularly interested in Aegis. Are any of you using Aegis with an >> investment in .aegis.xml files or @nnotations? If so, what expectations >> do >> you have for JSON? >> > > I use JAXB, not Aegis, for databinding because it's "the standard". Sorry > I > can't be of any help here. > > Josh > > >> >> In 2.2.x, Aegis+JAX-RS+JSON only works for fairly simple data types. >> Problems with namespaces and generic types cripple more complex cases. >> These >> problems would require a whole lot of effort to solve. I'm wondering, >> really, if all of you could just plug in Jackson and get the results you >> want. You might have to add some Jackson-specific @nnotations. If you are >> dependent on .aegis.xml files to avoid @nnotations, this would be a >> problem. >> If you have a giant raft of .aegis.xml files, or you have custom type >> mappings, it might be a really big problem. In which case, I wonder, >> ahem, >> if you'd like to help me implement the changes to Aegis needed. >> >> Anyhow, please let us know. >> > > -- View this message in context: http://www.nabble.com/Questions-for-JAX-RS-Users-tp25329919p25391530.html Sent from the cxf-user mailing list archive at Nabble.com.
