You are viewing a plain text version of this content. The canonical link for it is here.

Posted to user@karaf.apache.org by Ryan Moquin <fr...@gmail.com> on 2019/06/16 15:00:10 UTC

Aries JAXRS whiteboard question

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

Re: Aries JAXRS whiteboard question

Posted by Scott Lewis <sl...@composent.com>.

Just FYI:  ECF's impl of OSGi R7 Remote Services has a CXF [1] as Karaf 
features.

This uses only Jax-RS 2  annotations rather than the OSGI annotations, 
and since OSGi spec'd works seamlessly with DS.

There's a tutorial here [2] that uses either Jersey or CXF.   Of course 
any existing service built on CXF wil run as usual.

Scott

[1] https://github.com/ECF/JaxRSProviders

[2] https://wiki.eclipse.org/Tutorial:_JaxRS_Remote_Services_on_Karaf

On 6/21/2019 5:48 AM, Ryan Moquin wrote:
> 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.ward@paremus.com 
> <ma...@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 <fragility2.0@gmail.com
>>     <ma...@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
>>     <timothyjward@apache.org <ma...@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
>>>         <fragility2.0@gmail.com <ma...@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
>>
>

Re: Aries JAXRS whiteboard question

Posted by Ryan Moquin <fr...@gmail.com>.

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 <ti...@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 <fr...@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 <ti...@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 <fr...@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
>>
>>
>>
>

Re: Aries JAXRS whiteboard question

Posted by Tim Ward <ti...@paremus.com>.

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 <fr...@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 <timothyjward@apache.org <ma...@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 <fragility2.0@gmail.com <ma...@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
>

Re: Aries JAXRS whiteboard question

Posted by Ryan Moquin <fr...@gmail.com>.

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 <ti...@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 <fr...@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
>
>
>

Re: Aries JAXRS whiteboard question

Posted by Timothy Ward <ti...@apache.org>.

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 <fr...@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

Re: Aries JAXRS whiteboard question

Posted by Timothy Ward <ti...@apache.org>.

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.

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?

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?

I hope this helps,

Tim

On 16 Jun 2019, at 16:00, Ryan Moquin <fr...@gmail.com>> wrote:

Thanks!
Ryan