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

2018-12-03 Thread 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

2018-12-03 Thread 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, 

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

2018-12-02 Thread Alain Picard via osgi-dev
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, which I can't explain).

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.

Cheers,
Alain

On Sat, Dec 1, 2018 at 5:43 PM Alain Picard  wrote:

> Banging my head trying to figure out why my jaxrs is not starting properly.
>
> One of my colleague is running what should be the same environment and it
> works in his, but he has seen issues at time.
>
> In my log I see:
> 17:28:09.870 [Start Level: Equinox Container:
> 8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG o.o.p.w.e.w.i.Activator - Pax
> Web Whiteboard Extender started
> 17:28:10.863 [Start Level: Equinox Container:
> 8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Starting the whiteboard factory
> 17:28:10.901 [Start Level: Equinox Container:
> 8adb54b2-c97b-4651-9844-16e93c4d8f80] INFO
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Registered ClientBuilder
> 17:28:10.905 [Start Level: Equinox Container:
> 8adb54b2-c97b-4651-9844-16e93c4d8f80] INFO
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Registered SseEventSourceFactory
> 17:28:10.914 [Start Level: Equinox Container:
> 8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - adding new whiteboard
> configuration: {service.pid=org.apache.aries.jax.rs.whiteboard.default}
> 17:28:10.948 [Start Level: Equinox Container:
> 8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Whiteboard factory started
> 17:28:11.021 [Start Level: Equinox Container:
> 8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG o.o.p.w.s.i.Activator -
> Starting Pax Web
>
> And there is no reference to AriesJaxrsServiceRuntim.
>
> Looking for JaxrsServiceRuntime returns that it is registered:
> se org.osgi.service.jaxrs.runtime.JaxrsServiceRuntime
> {org.osgi.service.jaxrs.runtime.JaxrsServiceRuntime}={service.id=55,
> service.bundleid=11, service.scope=singleton, service.ranking=-2147483648,
> service.pid=org.apache.aries.jax.rs.whiteboard.default}
>   "Registered by bundle:" org.apache.aries.jax.rs.whiteboard_1.0.0 [11]
>   "No bundles using service."
>
> But the runtime DTO returns:
> {"serviceDTO":null, "defaultApplication":null, "applicationDTOs":[],
> "failedResourceDTOs":[], "failedExtensionDTOs":[],
> "failedApplicationDTOs":[]}
>
>
> The log from my colleague has a lot more starting with
> AriesJaxrsServiceRuntim:
> 15:42:52.941 [Start Level: Equinox Container:
> cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Starting the whiteboard factory
> 15:42:53.020 [Start Level: Equinox Container:
> cfe72d7c-4e6a-4892-94ae-9333da37a0ba] INFO
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Registered ClientBuilder
> 15:42:53.023 [Start Level: Equinox Container:
> cfe72d7c-4e6a-4892-94ae-9333da37a0ba] INFO
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Registered SseEventSourceFactory
> 15:42:53.034 [Start Level: Equinox Container:
> cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - adding new whiteboard
> configuration: {service.pid=org.apache.aries.jax.rs.whiteboard.default}
> 15:42:53.092 [Start Level: Equinox Container:
> cfe72d7c-4e6a-4892-94ae-9333da37a0ba] INFO
> o.a.a.j.r.w.a.CxfJaxrsBundleActivator - created whiteboard from
> configuration: {service.pid=org.apache.aries.jax.rs.whiteboard.default}
> 15:42:53.142 [Start Level: Equinox Container:
> cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG
> o.a.a.j.r.w.i.AriesJaxrsServiceRuntime - Registered service
> CachingServiceReference {
> cachedProperties={osgi.jaxrs.name=.default,
> osgi.jaxrs.whiteboard.target=(service.pid=org.apache.aries.jax.rs.whiteboard.default)}
> serviceReference={javax.ws.rs.core.Application}={osgi.jaxrs.application.base=/,
> service.id=79, service.bundleid=152, service.scope=singleton,
> service.ranking=-2147483648, osgi.jaxrs.name=.default,
> osgi.jaxrs.whiteboard.target=(service.pid=org.apache.aries.jax.rs.whiteboard.default),
> service.pid=org.apache.aries.jax.rs.whiteboard.default}
> } for name .default
> 15:42:53.159 [Start Level: Equinox Container:
> cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG o.a.a.j.r.w.i.Whiteboard -
> Obtained instance from CachingServiceReference {
> cachedProperties={osgi.jaxrs.application.select=null (cached),
> 

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

2018-12-01 Thread Alain Picard via osgi-dev
Banging my head trying to figure out why my jaxrs is not starting properly.

One of my colleague is running what should be the same environment and it
works in his, but he has seen issues at time.

In my log I see:
17:28:09.870 [Start Level: Equinox Container:
8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG o.o.p.w.e.w.i.Activator - Pax
Web Whiteboard Extender started
17:28:10.863 [Start Level: Equinox Container:
8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Starting the whiteboard factory
17:28:10.901 [Start Level: Equinox Container:
8adb54b2-c97b-4651-9844-16e93c4d8f80] INFO
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Registered ClientBuilder
17:28:10.905 [Start Level: Equinox Container:
8adb54b2-c97b-4651-9844-16e93c4d8f80] INFO
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Registered SseEventSourceFactory
17:28:10.914 [Start Level: Equinox Container:
8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - adding new whiteboard
configuration: {service.pid=org.apache.aries.jax.rs.whiteboard.default}
17:28:10.948 [Start Level: Equinox Container:
8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Whiteboard factory started
17:28:11.021 [Start Level: Equinox Container:
8adb54b2-c97b-4651-9844-16e93c4d8f80] DEBUG o.o.p.w.s.i.Activator -
Starting Pax Web

And there is no reference to AriesJaxrsServiceRuntim.

Looking for JaxrsServiceRuntime returns that it is registered:
se org.osgi.service.jaxrs.runtime.JaxrsServiceRuntime
{org.osgi.service.jaxrs.runtime.JaxrsServiceRuntime}={service.id=55,
service.bundleid=11, service.scope=singleton, service.ranking=-2147483648,
service.pid=org.apache.aries.jax.rs.whiteboard.default}
  "Registered by bundle:" org.apache.aries.jax.rs.whiteboard_1.0.0 [11]
  "No bundles using service."

But the runtime DTO returns:
{"serviceDTO":null, "defaultApplication":null, "applicationDTOs":[],
"failedResourceDTOs":[], "failedExtensionDTOs":[],
"failedApplicationDTOs":[]}


The log from my colleague has a lot more starting with
AriesJaxrsServiceRuntim:
15:42:52.941 [Start Level: Equinox Container:
cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Starting the whiteboard factory
15:42:53.020 [Start Level: Equinox Container:
cfe72d7c-4e6a-4892-94ae-9333da37a0ba] INFO
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Registered ClientBuilder
15:42:53.023 [Start Level: Equinox Container:
cfe72d7c-4e6a-4892-94ae-9333da37a0ba] INFO
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - Registered SseEventSourceFactory
15:42:53.034 [Start Level: Equinox Container:
cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - adding new whiteboard
configuration: {service.pid=org.apache.aries.jax.rs.whiteboard.default}
15:42:53.092 [Start Level: Equinox Container:
cfe72d7c-4e6a-4892-94ae-9333da37a0ba] INFO
o.a.a.j.r.w.a.CxfJaxrsBundleActivator - created whiteboard from
configuration: {service.pid=org.apache.aries.jax.rs.whiteboard.default}
15:42:53.142 [Start Level: Equinox Container:
cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG
o.a.a.j.r.w.i.AriesJaxrsServiceRuntime - Registered service
CachingServiceReference {
cachedProperties={osgi.jaxrs.name=.default,
osgi.jaxrs.whiteboard.target=(service.pid=org.apache.aries.jax.rs.whiteboard.default)}
serviceReference={javax.ws.rs.core.Application}={osgi.jaxrs.application.base=/,
service.id=79, service.bundleid=152, service.scope=singleton,
service.ranking=-2147483648, osgi.jaxrs.name=.default,
osgi.jaxrs.whiteboard.target=(service.pid=org.apache.aries.jax.rs.whiteboard.default),
service.pid=org.apache.aries.jax.rs.whiteboard.default}
} for name .default
15:42:53.159 [Start Level: Equinox Container:
cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG o.a.a.j.r.w.i.Whiteboard -
Obtained instance from CachingServiceReference {
cachedProperties={osgi.jaxrs.application.select=null (cached),
osgi.jaxrs.application.base=/, osgi.jaxrs.name=.default,
osgi.jaxrs.extension.select=null (cached),
osgi.http.whiteboard.context.select=null (cached),
osgi.jaxrs.whiteboard.target=(service.pid=org.apache.aries.jax.rs.whiteboard.default)}
serviceReference={javax.ws.rs.core.Application}={osgi.jaxrs.application.base=/,
service.id=79, service.bundleid=152, service.scope=singleton,
service.ranking=-2147483648, osgi.jaxrs.name=.default,
osgi.jaxrs.whiteboard.target=(service.pid=org.apache.aries.jax.rs.whiteboard.default),
service.pid=org.apache.aries.jax.rs.whiteboard.default}
}
15:42:53.182 [Start Level: Equinox Container:
cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG o.a.a.j.r.w.i.Whiteboard -
Creating CXF Bus with extensions {} and properties
{service.pid=org.apache.aries.jax.rs.whiteboard.default}
15:42:53.275 [Start Level: Equinox Container:
cfe72d7c-4e6a-4892-94ae-9333da37a0ba] DEBUG o.a.a.j.r.w.i.Whiteboard -
Created CXF Bus with extensions {} and properties
{service.pid=org.apache.aries.jax.rs.whiteboard.default}

Aries referenced bundles
11|Active |