search

ECF / JaxRSProviders

Remote Services distribution provider based upon JaxRS. Includes imples based upon Jersey and CXF.
Apache License 2.0
13 stars 18 forks source link

Each registered jax-rs service is bound to its own jersey container? #4

Closed erdalkaraca closed 7 years ago

erdalkaraca commented 7 years ago

It seems that each JAX-RS service is started in its own jersey container. This means, that if we have two OSGi bundles that both deploy their services using the alias "/", then not both services are available. Am I right, or what do I miss?

When I do this, only one of my services work (can be accessed via GET, for example).

erdalkaraca commented 7 years ago

It seems that only one jersey container is instantiated and bound to the first encountered jax-rs service. Should registering multiple jax-rs services in the same OSGi instance work?

scottslewis commented 7 years ago

Hi Erdal,

I've been away from my desk much of the day...sorry about the slowness. I need to let you know that I'll be traveling over the next four days, and so will be slow to continue this dialog, but continue it we will :).

It seems that each JAX-RS service is started in its own jersey container. This means, that if we have two OSGi bundles that both deploy their services using the alias "/", then not both services are available. Am I right, or what do I miss?

As currently implemented, yes this is true. If the services are both deployed with path "/" then the second servlet creation and registration will fail. Actually it won't e

It seems that only one jersey container is instantiated and bound to the first encountered jax-rs service. Should registering multiple jax-rs services in the same OSGi instance work?

Yes, this is a bug. Would you please open one? I know how to fix this, and will do so when I can (probably over weekend), but can't right away.

scottslewis commented 7 years ago

Opps...sorry...this is already an issue/bug. Forget about opening a new one, this one will do fine.

scottslewis commented 7 years ago

Hi Erdal,

Just now I've committed a fix for this:

https://github.com/ECF/JaxRSProviders/commit/7fd0dbf57ebbd1ddc6f6113c22cf77dec51ae790

What this does is introduce an extension to ECF's RSA impl (called a HostContainerSelector) that overrides the default container selector and forces the creation of a new container instance for every Jersey remote service. The thing that this depends upon to work, however, is that the alias provided for each service be unique.

e.g. For the first service (this from https://github.com/ECF/JaxRSProviders/tree/master/examples/com.mycorp.examples.student.remoteservice.host/rsexport.jersey.properties

Distribution-provider property defining the alias prefix for the Jersey server

ecf.jaxrs.jersey.server.alias=/jersey/is/good

Other Jersey properties that could be defined

ecf.jaxrs.jersey.server.urlContext=http://localhost:8282

and the following from rsexport.jersey2.properties ...

Distribution-provider property defining the alias prefix for the Jersey server

ecf.jaxrs.jersey.server.alias=/jersey/is/good2

Other Jersey properties that could be defined

ecf.jaxrs.jersey.server.urlContext=http://localhost:8282

Note that the urlContext is the same: http://localhost:8282 and the alias is different...i.e. /jersey/is/good vs /jersey/is/good2.

These two paths have to be different as otherwise there is no way to distinguish the endpoints (which are also bound to the Jersey servlets).

scottslewis commented 7 years ago

Closing this issue, as it is dealt with as discussed on issue 5

https://github.com/ECF/JaxRSProviders/issues/5