On 19 Jun 2019, at 14:32, Ryan Moquin <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
