Re: Capabilities and requirements

[Jean-Baptiste Onofré]

Hi Ryan,

Do you mean you are using resources repository (define in
etc/org.apache.karaf.features.cfg) ?

A features repository can also contains capability and requirements.

To be able to find the req/cap, the resolver needs to know the cap/req.
If they are splitted in different repositories, then you have first to
"load" the repositories to be visible by the resolver. Else the resolver
won't know "where" the cap is provided.

Cave can help in two ways:
1. the features gateway is able to gather several features repositories
in a meta-global-one.
2. Cave can serve as resources repositories backend

Can you share your test case in order for me to take a look ?

Regards
JB

On 19/06/2019 23:18, Ryan Moquin wrote:
> Hi JB,
> 
> I decided to try the req/cap again.  The reason it didn't work for me
> before apparently is because a capability satisfying a requirement isn't
> detected by the resolver if they are in different feature repositories
> (which is the same as a feature XML I believe).  I tried to reference a
> feature as a dependency in a different repository but it wouldn't work
> unless I had it in the same repository.
> 
> I'm not sure if that's by design or if something like Cave would be
> needed for that scenario.  Otherwise I need to rethink how I handle the
> requirement and capabilities.  I am trying to keep separate feature
> repositories because if I aggregate, then it takes longer to create the
> updated aggregate feature xml.
> 
> Ryan
> 
> On Sat, Jun 15, 2019, 12:01 PM Jean-Baptiste Onofré  > wrote:
> 
> Hi Ryan,
> 
> I will provide a more complete answer (I don't have time right now), but
> you can take a look on the way we use cap/req in Pax Web (for the HTTP
> provider capability).
> 
> Basically, the cap/req are global in the feature resolver, considering
> the req/cap at feature level, but also at bundle level.
> 
> Regards
> JB
> 
> On 15/06/2019 16:28, Ryan Moquin wrote:
> > I apologize if this is a stupid question. I've been trying to
> understand
> > how to leverage capabilities and requirements in a way to allow
> defining
> > the provisioning of a system by specifying requirements in a feature.
> >
> > I've read through the posts on the mailing list about it, the docs and
> > the karaf features.xml but haven't found the information I am looking
> > for.  I also tried some experiments with a bundle providing a
> capability
> > and a feature requiring it but it didn't seem to work.  I am wondering
> > if I am just over thinking or over complicating it in my head. 
> Here are
> > the questions:
> >
> > 1.  When a feature specifies a requirement, what is the "scope" of
> > resolution used by the feature resolver?  Meaning, does it only pick
> > from features specified within that feature with dependency=true
> > specified?  Or from any feature defined in the features.xml and any
> > feature repository defined that provides a satisfying capability?
> >
> > 2.  Can you specify a requirement in a feature for a requirement
> > provided by a bundle?
> >
> > 3.  If a bundle or feature provides a capability, but you don't
> specify
> > you require it.  Does it always get considered for installation if
> it's
> > in a feature that doesn't have dependency=true?
> >
> > Part of this is because I still can't understand when to use
> > dependency=true for a feature.  I am primarily talking about custom
> > capabilities and requirements I make up myself for a system to pull
> > things in.
> >
> > Not sure if the above questions fully make sense, having a hard time
> > articulating exactly what I am trying to figure out.
> >
> > Thanks for any help!
> >
> > Ryan
> 
> -- 
> Jean-Baptiste Onofré
> jbono...@apache.org 
> http://blog.nanthrax.net
> Talend - http://www.talend.com
> 

-- 
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Capabilities and requirements

[Ryan Moquin]

Hi JB,

I decided to try the req/cap again.  The reason it didn't work for me
before apparently is because a capability satisfying a requirement isn't
detected by the resolver if they are in different feature repositories
(which is the same as a feature XML I believe).  I tried to reference a
feature as a dependency in a different repository but it wouldn't work
unless I had it in the same repository.

I'm not sure if that's by design or if something like Cave would be needed
for that scenario.  Otherwise I need to rethink how I handle the
requirement and capabilities.  I am trying to keep separate feature
repositories because if I aggregate, then it takes longer to create the
updated aggregate feature xml.

Ryan

On Sat, Jun 15, 2019, 12:01 PM Jean-Baptiste Onofré  wrote:

> Hi Ryan,
>
> I will provide a more complete answer (I don't have time right now), but
> you can take a look on the way we use cap/req in Pax Web (for the HTTP
> provider capability).
>
> Basically, the cap/req are global in the feature resolver, considering
> the req/cap at feature level, but also at bundle level.
>
> Regards
> JB
>
> On 15/06/2019 16:28, Ryan Moquin wrote:
> > I apologize if this is a stupid question. I've been trying to understand
> > how to leverage capabilities and requirements in a way to allow defining
> > the provisioning of a system by specifying requirements in a feature.
> >
> > I've read through the posts on the mailing list about it, the docs and
> > the karaf features.xml but haven't found the information I am looking
> > for.  I also tried some experiments with a bundle providing a capability
> > and a feature requiring it but it didn't seem to work.  I am wondering
> > if I am just over thinking or over complicating it in my head.  Here are
> > the questions:
> >
> > 1.  When a feature specifies a requirement, what is the "scope" of
> > resolution used by the feature resolver?  Meaning, does it only pick
> > from features specified within that feature with dependency=true
> > specified?  Or from any feature defined in the features.xml and any
> > feature repository defined that provides a satisfying capability?
> >
> > 2.  Can you specify a requirement in a feature for a requirement
> > provided by a bundle?
> >
> > 3.  If a bundle or feature provides a capability, but you don't specify
> > you require it.  Does it always get considered for installation if it's
> > in a feature that doesn't have dependency=true?
> >
> > Part of this is because I still can't understand when to use
> > dependency=true for a feature.  I am primarily talking about custom
> > capabilities and requirements I make up myself for a system to pull
> > things in.
> >
> > Not sure if the above questions fully make sense, having a hard time
> > articulating exactly what I am trying to figure out.
> >
> > Thanks for any help!
> >
> > Ryan
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: Aries JAXRS whiteboard question

[Tim Ward]

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

[Ryan Moquin]

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