Re: [osgi-dev] what is way to use a Resolver and Repository together ?

[Thomas Watson via osgi-dev]

The difference between what BND is doing and what I understand you are trying to do is that BND always starts with a fresh slate and does a full resolve to pull in the required resources to run.  But you want to start from a persistent state which is the set of things already provisioned to a framework and possibly resolved.
 
The key concept to understand is that the Resolver service is stateless.  All state must be kept by the implementation of the ResolveContext used to do the resolve operation.  The Resolver gets the current state by calling org.osgi.service.resolver.ResolveContext.getWirings().  This is the starting "context" the resolver must apply new resolution wires to.  If you have a running framework then you can gather all the Wiring objects for each bundle revision (BundleRevision implements Resource) by calling org.osgi.framework.wiring.BundleRevision.getWiring().
 
With that you can produce the Map wirings to hand the Resolver.  What I recommend is that you back your ResolveContext with at least two Respository implementations (or concepts).
 
1) to represent the resource/capabilities installed in the framework.  This can trivially be implemented by using the method org.osgi.framework.wiring.FrameworkWiring.findProviders(Requirement)
2) to represent one or more repositories you want to use to install more resources to the framework in order to satisfy additional requirements.
 
Then in org.osgi.service.resolver.ResolveContext.findProviders(Requirement) you can implement a policy where you can prefer capabilities from resources already installed over ones available from repository #2.
 
When the Resolver.resolve method hands back a Map> it has not actually been applied to the state maintained by the ResolveContext.  That is something that still needs to be applied by the code calling the Resolver.resolve method.  For you that may simply mean installing each Resource key in the map as a bundle.  Then you should likely do a framework resolution operation to ensure what you provisioned does really resolve at runtime.  Then next provisioning operation you will start over with a wiring state that includes again all the current BundleWiring objects.
 
HTH
Tom 
 
 
- Original message -From: Cristiano via osgi-dev Sent by: osgi-dev-boun...@mail.osgi.orgTo: Raymond Auge , OSGi Developer Mail List Cc:Subject: Re: [osgi-dev] what is way to use a Resolver and Repository together ?Date: Mon, Dec 3, 2018 1:26 PM 
On 01/12/2018 19:32, Raymond Auge wrote:> The basic idea is that you want to represent the capabilities of the> existing system as already being provided, used to support the> requirements you're searching for, but ultimately excluded from the> result, such that only missing capabilities are included in the result.>> You might want to look at> https://github.com/bndtools/bnd/blob/master/biz.aQute.resolve/src/biz/aQute/resolve/BndrunResolveContext.java > and note how when using a "distro" (a predefined set of provided> capabilities) it performs exactly this logic.>> Hth,> - RayHi Raymond,Thanks again for your support. ;)I was thinking that I had understood the concept you exposed, butlooking at the example wow, it is more complex than I was expecting.My understanding until now was that I would somehow mount a "snapshot"of the node using a ResolveContext object and then call theResolver.resolve(). After that, to call the repository's findProvider()using somehow the built snapshot...but BndrunResolveContext receives a Repository instance on itconstructor. Why would I need a repository inside the context?best regards,Cristiano___OSGi Developer Mail Listosgi-dev@mail.osgi.orghttps://mail.osgi.org/mailman/listinfo/osgi-dev 
 

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] what is way to use a Resolver and Repository together ?

[Cristiano via osgi-dev]

On 01/12/2018 19:32, Raymond Auge wrote:
The basic idea is that you want to represent the capabilities of the 
existing system as already being provided, used to support the 
requirements you're searching for, but ultimately excluded from the 
result, such that only missing capabilities are included in the result.


You might want to look at 
https://github.com/bndtools/bnd/blob/master/biz.aQute.resolve/src/biz/aQute/resolve/BndrunResolveContext.java 
and note how when using a "distro" (a predefined set of provided 
capabilities) it performs exactly this logic.


Hth,
- Ray



Hi Raymond,

Thanks again for your support. ;)

I was thinking that I had understood the concept you exposed, but 
looking at the example wow, it is more complex than I was expecting.


My understanding until now was that I would somehow mount a "snapshot" 
of the node using a ResolveContext object and then call the 
Resolver.resolve(). After that, to call the repository's findProvider() 
using somehow the built snapshot...


but BndrunResolveContext receives a Repository instance on it 
constructor. Why would I need a repository inside the context?


best regards,

Cristiano

___
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Re: [osgi-dev] Problem starting Aries JAX-RS Whiteboard

[Alain Picard via osgi-dev]

Tim,

As always, thanks for a very informative reply. I will surely open a bug
with PAX Web regarding this issue.

Cheers,
Alain


On Mon, Dec 3, 2018 at 4:30 AM Tim Ward  wrote:

> Hi Alain,
>
> Sorry this took you so long to work out - Sunday isn’t the best time to
> get a response I’m afraid!
>
> **
> In summary - this should have “just worked” for you. I’m sorry that it
> didn’t, but unfortunately in this case the web container implementation
> that you are using has some packaging bugs that make it break in certain
> scenarios.
>
> I would suggest raising bugs agains PAX-Web to see if you can get them to
> fix these issues.
> **
>
> Explanation follows:
>
> By debugging the Aries Whiteboard activator, it is looking for a service
> matching;
> "(&(objectClass=org.osgi.service.http.runtime.HttpServiceRuntime)(osgi.http.endpoint=*))”
>
>
> Part of the JAX-RS Whiteboard specification requires the
> JaxrsServiceRuntime service to advertise its root URI as a service property
> so that other services can work out where the resources will be hosted. The
> Aries JAX-RS Whiteboard implementation does not provide its own web
> container and instead makes use of the Http Whiteboard. This means that it
> has to query the HttpServiceRuntime service to work out what the base URI
> is. Note that this is an implementation decision - Aries JAX-RS Whiteboard
> could have provided its own embedded web container, but the consensus was
> that it should focus on JAX-RS and allow people to combine it into their
> existing web applications.
>
> This was colliding between org.ops4j.pax.web.pax-web-api (which I see as
> being used by the working copy) and in my case "org.eclipse.osgi.services"
> and "org.osgi.service.http.whiteboard 1.1" as well. I got rid of
> "org.eclipse.osgi.services"and instead locally use the org.osgi.* bundles
> and for the http.whiteboard, I lowered my import package to 1.0 to match
> paxweb export package version and the issue is gone. I honestly think that
> "org.eclipse.osgi.services" is evil.
>
>
> Much like the osgi.cmpn bundle, bundles which aggregate a bunch of
> otherwise unrelated APIs into an uber bundle are a bad thing. This is why
> the osgi.cmpn bundle has been made unresolvable (i.e. not possible to
> deploy) and the org.eclipse.osgi.services bundle should do the same.
>
> That being said - the main issue isn’t related to the
> org.eclipse.osgi.services bundle, but actually as a result of bad metadata
> in the pax web Http Whiteboard implementation. The Aries JAX-RS Whiteboard
> contains the following requirement:
>
> Require-Capability:
> osgi.implementation;filter:="(&(osgi.implementation=osgi.http)(version>=1)(!(version>=2)))"
>
> This requirement is there to ensure two things:
>
>
>1. To make sure that an Http Whiteboard implementation is resolved and
>deployed
>2. To make sure that the OSGi framework wires up the package space in
>the correct way
>
>
> Item 2 is the problem that you are seeing, and it’s because the PAX-Web
> implementation is failing to properly provide the implementation
> capability. This is how it is supposed to be provided (
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121954
> )
>
>
> osgi.implementation;osgi.implementation="osgi.http";version:Version="1.0";uses:="javax.servlet,javax.servlet.http,org.osgi.service.http.context,org.osgi.service.http.whiteboard"
>
> The bundle org.ops4j.pax.web.pax-web-runtime does do *exactly* this, but
> the person who did it failed to understand what a uses constraint actually
> meant. Specifically it’s an instruction to the resolver to say that *“A
> bundle wired to this capability must use the same package instances as the
> provider of the capability for these packages”.* The problem is that the
> org.ops4j.pax.web.pax-web-runtime *doesn’t use* these packages! A uses
> constraint is only valuable if the bundle either imports or exports the
> package that it refers to, otherwise the resolver is free to make any
> choice it likes when resolving your bundles. This is what you were seeing
> happen, and is why the JAX-RS Whiteboard was wired to an incompatible
> version of the Http Whiteboard packages.
>
> To fix this PAX Web needs to be updated to put the http whiteboard
> capability on the correct bundle (in this
> case org.ops4j.pax.web.pax-web-extender-whiteboard) which is the bundle
> that appears to actually implement the Http Whiteboard, and is wired to all
> the packages. I would also note that Pax Web puts the osgi.service
> capability for the HttpServiceRuntime service on the
> org.ops4j.pax.web.pax-web-runtime bundle, even though this bundle is not
> the one that provides the service! This could lead to yet more nonsense
> when provisioning.
>
> Best Regards,
>
> Tim
>
>
> On 2 Dec 2018, at 16:21, Alain Picard via osgi-dev 
> wrote:
>
> Ok,
>
> After another 10 hours of frustration, I finally solved the issue. By
> debugging the Aries Whiteboard activator, it is 

Re: [osgi-dev] Problem starting Aries JAX-RS Whiteboard

[Tim Ward via osgi-dev]

Hi Alain,

Sorry this took you so long to work out - Sunday isn’t the best time to get a 
response I’m afraid! 


In summary - this should have “just worked” for you. I’m sorry that it didn’t, 
but unfortunately in this case the web container implementation that you are 
using has some packaging bugs that make it break in certain scenarios.

I would suggest raising bugs agains PAX-Web to see if you can get them to fix 
these issues.


Explanation follows:

> By debugging the Aries Whiteboard activator, it is looking for a service 
> matching; 
> "(&(objectClass=org.osgi.service.http.runtime.HttpServiceRuntime)(osgi.http.endpoint=*))”

Part of the JAX-RS Whiteboard specification requires the JaxrsServiceRuntime 
service to advertise its root URI as a service property so that other services 
can work out where the resources will be hosted. The Aries JAX-RS Whiteboard 
implementation does not provide its own web container and instead makes use of 
the Http Whiteboard. This means that it has to query the HttpServiceRuntime 
service to work out what the base URI is. Note that this is an implementation 
decision - Aries JAX-RS Whiteboard could have provided its own embedded web 
container, but the consensus was that it should focus on JAX-RS and allow 
people to combine it into their existing web applications.

> This was colliding between org.ops4j.pax.web.pax-web-api (which I see as 
> being used by the working copy) and in my case "org.eclipse.osgi.services" 
> and "org.osgi.service.http.whiteboard 1.1" as well. I got rid of 
> "org.eclipse.osgi.services"and instead locally use the org.osgi.* bundles and 
> for the http.whiteboard, I lowered my import package to 1.0 to match paxweb 
> export package version and the issue is gone. I honestly think that 
> "org.eclipse.osgi.services" is evil.

Much like the osgi.cmpn bundle, bundles which aggregate a bunch of otherwise 
unrelated APIs into an uber bundle are a bad thing. This is why the osgi.cmpn 
bundle has been made unresolvable (i.e. not possible to deploy) and the 
org.eclipse.osgi.services bundle should do the same.

That being said - the main issue isn’t related to the org.eclipse.osgi.services 
bundle, but actually as a result of bad metadata in the pax web Http Whiteboard 
implementation. The Aries JAX-RS Whiteboard contains the following requirement:

Require-Capability: 
osgi.implementation;filter:="(&(osgi.implementation=osgi.http)(version>=1)(!(version>=2)))"

This requirement is there to ensure two things:

To make sure that an Http Whiteboard implementation is resolved and deployed
To make sure that the OSGi framework wires up the package space in the correct 
way

Item 2 is the problem that you are seeing, and it’s because the PAX-Web 
implementation is failing to properly provide the implementation capability. 
This is how it is supposed to be provided 
(https://osgi.org/specification/osgi.cmpn/7.0.0/service.http.whiteboard.html#d0e121954
 
)

osgi.implementation;osgi.implementation="osgi.http";version:Version="1.0";uses:="javax.servlet,javax.servlet.http,org.osgi.service.http.context,org.osgi.service.http.whiteboard"

The bundle org.ops4j.pax.web.pax-web-runtime does do exactly this, but the 
person who did it failed to understand what a uses constraint actually meant. 
Specifically it’s an instruction to the resolver to say that “A bundle wired to 
this capability must use the same package instances as the provider of the 
capability for these packages”. The problem is that the 
org.ops4j.pax.web.pax-web-runtime doesn’t use these packages! A uses constraint 
is only valuable if the bundle either imports or exports the package that it 
refers to, otherwise the resolver is free to make any choice it likes when 
resolving your bundles. This is what you were seeing happen, and is why the 
JAX-RS Whiteboard was wired to an incompatible version of the Http Whiteboard 
packages.

To fix this PAX Web needs to be updated to put the http whiteboard capability 
on the correct bundle (in this case 
org.ops4j.pax.web.pax-web-extender-whiteboard) which is the bundle that appears 
to actually implement the Http Whiteboard, and is wired to all the packages. I 
would also note that Pax Web puts the osgi.service capability for the 
HttpServiceRuntime service on the org.ops4j.pax.web.pax-web-runtime bundle, 
even though this bundle is not the one that provides the service! This could 
lead to yet more nonsense when provisioning.

Best Regards,

Tim
  
> On 2 Dec 2018, at 16:21, Alain Picard via osgi-dev  
> wrote:
> 
> Ok,
> 
> After another 10 hours of frustration, I finally solved the issue. By 
> debugging the Aries Whiteboard activator, it is looking for a service 
> matching; 
> "(&(objectClass=org.osgi.service.http.runtime.HttpServiceRuntime)(osgi.http.endpoint=*))".
>  Happens that I am having resolver chain issues with this specifically (and 
> my colleague is not,