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