Yes, we’re really proud of the JAX-RS whiteboard - particularly when you can use it with the DS 1.4 Component Property annotations. It’s brilliantly simple to use.
All the best, Tim > On 19 Jun 2019, at 14:32, Ryan Moquin <fragility...@gmail.com> wrote: > > Yes, you are correct Tim. I forgot there is an Aries list, my bad! > > Thank you for the explanation Tim, that makes perfect sense to me :) It's > pretty cool to be able to whip up some jaxrs classes without the extra boiler > plate. > > Ryan > > On Mon, Jun 17, 2019 at 5:30 AM Timothy Ward <timothyjw...@apache.org > <mailto:timothyjw...@apache.org>> wrote: > Hi, > > I feel that the best place to ask this question would be the Apache Aries > mail list (given that it’s an Aries project). I’m therefore cross posting > this back to the Aries list. > > In general repackaging a library is intended to shield users from the > underlying implementation details. In the case of the JAX-RS whiteboard it > shouldn’t matter whether it’s CXF, Jersey, Restlet, or whatever else under > the covers. In the specific case of Aries JAX-RS it proved necessary to put > in some custom extensions to: > > Get CXF to correctly apply lifecycle to the services that it uses > Get CXF to natively handle OSGi promises (this involves putting extra code in > CXF client packages) > Avoid some lifecycle issues when CXF was incompletely installed > > The overall Aries JAX-RS whiteboard project is first and foremost an > implementation of the OSGi JAX-RS whiteboard specification (it’s the > reference implementation) so item 2 was already a pretty hard requirement for > repackaging CXF. Ease of use was a further concern, CXF is big, and does a > lot more than just JAX-RS which pushed us into building “one bundle that > works” rather than “a bundle with lots of CXF dependencies that are hard to > manage and partially redundant”. > >> Could that be a hinderance around CXF version upgrades when used in a >> project? Such as if there was a security vulnerability in the version of CXF >> that was repackaged? > > Aries JAX-RS is updated and released regularly. If there’s a security fix > then rolling it out in a point release would be trivial (update a pom > property and re-build). I therefore don’t see this as a significant problem. > >> CXF works fine in OSGi, why wouldn't is just be pulled as is? > > CXF *mostly* works fine in OSGi. We needed to add this support > https://github.com/apache/aries-jax-rs-whiteboard/tree/master/jax-rs.whiteboard/src/main/java/org/apache/cxf/jaxrs/client > > <https://github.com/apache/aries-jax-rs-whiteboard/tree/master/jax-rs.whiteboard/src/main/java/org/apache/cxf/jaxrs/client> > and also to customise the way in which the CXF invocations occur (including > the resource lifecycle) > https://github.com/apache/aries-jax-rs-whiteboard/tree/master/jax-rs.whiteboard/src/main/java/org/apache/aries/jax/rs/whiteboard/internal/cxf > > <https://github.com/apache/aries-jax-rs-whiteboard/tree/master/jax-rs.whiteboard/src/main/java/org/apache/aries/jax/rs/whiteboard/internal/cxf> > > The end result is that embedding CXF gives better control over what’s used > and tested (we have fixed a bunch of CXF bugs as part of building the > whiteboard!) and is more reliable for our users. > >> Is this mainly meant for people who really don't care what is used under the >> covers and the version of it, but just want to quickly get a rest server up >> and going? > > No, this is intended to be a production quality implementation of the OSGi > JAX-RS Whiteboard specification. The fact that CXF is used is technically an > implementation detail, but there is a fragment that you can attach to export > the CXF packages from the Aries whiteboard if you have a desire to go CXF > native. Using the plain JAX-RS API is the preferred option. > > I hope this helps, > > Tim > >> On 16 Jun 2019, at 16:00, Ryan Moquin <fragility...@gmail.com >> <mailto:fragility...@gmail.com>> wrote: >> >> I was looking at the Aries JAXRS whiteboard example to see how it differs >> from just using CXF directly. It looks interesting. My one main concern >> would be around the Aries whiteboard bundle needing to repackage cxf >> dependencies. Could that be a hinderance around CXF version upgrades when >> used in a project? Such as if there was a security vulnerability in the >> version of CXF that was repackaged? CXF works fine in OSGi, why wouldn't is >> just be pulled as is? Is this mainly meant for people who really don't care >> what is used under the covers and the version of it, but just want to >> quickly get a rest server up and going? >> >> Thanks! >> Ryan >
