Yes, it's an impressive accomplishment, I hope I didn't come off the wrong way with my questions. I wanted to figure out how the JAX-RS whiteboard stuff might play together with the CXF REST services I already have. I'll make sure to ask any further questions in the Aries list.
Ryan On Wed, Jun 19, 2019 at 9:47 AM Tim Ward <tim.w...@paremus.com> wrote: > 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> > 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 >> >> >> >
