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> 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: > > > 1. Get CXF to correctly apply lifecycle to the services that it uses > 2. Get CXF to natively handle OSGi promises (this involves putting > extra code in CXF client packages) > 3. 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 > 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 > > 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> 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 > > >
