ECF / JaxRSProviders

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

Replace service id in URL with a value of my choice? #16

Closed airaketa closed 5 years ago

airaketa commented 5 years ago

Hello, I wonder if it is possible to replace service id with something else in service URL for Jersey provider? Or make it possible? Let's say with ecf.jaxrs.jersey.server.pathPrefix value, for example. In other words, if service URL is http://localhost:8080/1 is it possible to replace the "1" with another value?

scottslewis commented 5 years ago

Hi,

Yes it is possible to replace the /1 with some other string. The reason it is 1 is because it needs to be unique for each service instance, and the remote service id (1 in typical case) does that.

It's not enough to use the pathPrefix only, however to do so...as typically this will result in /pathprefix/1.

This can be easily addressed as well, but before refreshing my own memory about how to do this let me leave it at that and see if this is necessary.

Thanks,

Scott

airaketa commented 5 years ago

Thanks for the quick response.

Well, I've been trying to figure it out for a while. I've tried to configure the service context path through DS Component annotation and ended up with something like this:

@Component(property = { "service.exported.interfaces=*", "service.intents=jaxrs",
    "service.exported.configs=ecf.jaxrs.jersey.server", "ecf.jaxrs.jersey.server.uri=/test",
    "ecf.jaxrs.jersey.server.exported.interfaces=MyInterface" })

But it stil gives me http://localhost:8080/1/test (or http://localhost:8080/test/1 if I go with ecf.jaxrs.jersey.server.pathPrefix instead of ecf.jaxrs.jersey.server.uri as you mentioned).

So help would be very helpful if it's not too much trouble for you.

scottslewis commented 5 years ago

Hi Airaketa

I will respond more fully later this evening. It currently requires extending a class and I'll explain that later but I'm considering adding properties based customization in next release version.

scottslewis commented 5 years ago

Hi Airaketa. I haven't forgotten about this, I just had something come up. I've decided to do two things:

1) I have an example that I'm completing of how to create a new remote service provider...based upon the jersey provider, that shows how to override the use of the remote service id (i.e. /1) in the path. This will work with the current version of JaxRSProvider release.

2) Add to the JaxRSProvider to allow folks like yourself to customize the use/or not of remote service id via service or system properties (e.g. like the pathPrefix). I want to think about this a little bit though, so that it has to be done only once with sufficient generality.

scottslewis commented 5 years ago

Hi Airakea. WRT 1 in my message above:

I've added a new example project here:

https://github.com/ECF/JaxRSProviders/tree/master/examples/org.eclipse.ecf.provider.jersey.ext.example

This project is an extension of the jersey server remote services provider allows you or others to customize the URL creation at runtime. There are two classes: Activator and ExtJerseyServerContainer. The activator has code that allows a new provider to be made available with config id: ecf.jaxrs.jersey.server.ext. You can use this provider in the student service example (StudentServiceImpl class) by adding a service property: service.exported.configs=ecf.jaxrs.jersey.server.ext

The ExtJerseyServerContainer class is where the url path prefix can be customized. This is by implementing this method (overrides superclass method that is responsible for the '/{serviceId}' ...e.g. '/1' in the url path:

https://github.com/ECF/JaxRSProviders/blob/c2d869b747869f3d7c3346bc387c72fe7793afbd/examples/org.eclipse.ecf.provider.jersey.ext.example/src/org/eclipse/ecf/provider/internal/jersey/ext/example/ExtJerseyServerContainer.java#L27

As you can see, to get an empty string (rather than /1) just return "". Or you can specify any prefix you want via the pathPrefix service property, which will be then available at runtime in the ExtJerseyServerContainer.servletPathPrefix variable.

I intend to create my own example usage of this extended jersey provider, but first I want to complete 2. With 2 in place, it won't be necessary to create an extended provider as per 1 at all, but rather it will be possible to set a servletPathPrefix and have that be used instead of /1. I wanted to create the 1 example anyway, however, because it does allow other more-specialized customization of the provider behavior, which some may wish to do as well.

airaketa commented 5 years ago

Hi Scott,

Thank you so much for your help in solving this issue. I will try to implement this for my own service.

Adding the new service property would also be very useful. So I will definitely be watching and waiting for a new version to come out.

scottslewis commented 5 years ago

Hi Airaketa.

I've just released version 1.10.0 of the JaxRSProviders.

I made a number of subtle changes to assist in implementing your use case.

First, I added a new system/service property for both/all JaxRSProviders called includeRemoteServiceId which defaults to 'false'...meaning that the /1 will be default not be added to the remote service URL as it was in the past. If the includeRemoteServiceId is set to true, howeveer, the /1 will be added as suffix as it was previously. See the page describing the includeRemoteServiceId as well as other system/service properties:

https://github.com/ECF/JaxRSProviders/wiki/JaxRS-Distribution-Provider-Configuration-Properties

As before, the pathPrefix system/service property allows an explicit path prefix to be set for the remote service servlet. This Karaf tutorial shows how this works:

https://wiki.eclipse.org/Tutorial:_JaxRS_Remote_Services_on_Karaf

I think this will be more understandable, but it does have the consequence that if the same pathPrefix is used for two service instances the second will fail. In that case it might be helpful to set includeRemoteServiceId to true.

I'm going to close this issue. Please reopen if these changes and the example distribution provider described above are not sufficient for dealing with your use cases.