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

Issue 29 simplify endpoint configuration #30

Closed modular-mind closed 3 years ago

modular-mind commented 3 years ago

Here's a sketched out implementation that provides JAX-RS and Jersey defaults and also allows for user-specified profile values. I tried to keep things simple and also avoid changing anything in the base ECF logic.

What I came up with is allowing profile-specific settings to be specified in the EDEF file itself. Inside the reader I only had an InputStream and couldn't work my way back to the EDEF file location, so I chose not to use separate properties files. An example for the launch service would be:

`

`

Currently the developer would need to indicate the profile on the command line with the argument:

-Dorg.eclipse.ecf.provider.jaxrs.client.profile=test

This is the simplest thing I could think to implement (again, without modifying the base ECF code). Let me know what you think. I'd be happy to take an alternate approach or change any of the details.

modular-mind commented 3 years ago

Hi Scott, just wanted to ping you about this. If you think there's a better approach, I'm up for working on that.

scottslewis commented 3 years ago

Hi Patrick. I'm very sorry to be so slow about responding to this contribution. Lots of personal stuff over last 1.5 months have kept me away. I very much appreciate your willingness to contribute.

The only objection to what you've done is that I would like to try to generalize it somehow...so that a single mechanism could be used for simplifying the construction of client-side edef...for any distribution provider (rather than jaxrs)...e.g. something that allows default property values (for spec-required edef properties), and allows template references to System property values, and arbitrary other properties/values.

Do you have a pressing need to have this introduced immediately for your/your client's usage?

modular-mind commented 3 years ago

No problem, just thought I'd see if I could make some progress on this. I don't have a pressing need at the moment, just trying to make the Jersey Client more useful. Configuration is one of the main issues at present.

So would your suggestion mean modifying the core ECF Remote Services functionality? If we could come up with a general approach, I'd be happy to sketch out an implementation.

scottslewis commented 3 years ago

So would your suggestion mean modifying the core ECF Remote Services functionality?

Yes, but only by adding something. Most of the edef discovery and import handling is essentially specified by the OSGi RSA specification (chap 122) so can't really modify that.

But I do think it would be possible to add an 'edef templating' mechanism/service, which would (e.g.) do variable substitution for edef properties...certainly with system properties, maybe with some optional properties files, etc.

If we could come up with a general approach, I'd be happy to sketch out an implementation.

I would like to do that. From your work it sounds like what you want/need is to have edef templates with string/variable substitution. Where system properties can be referenced in the template, other properties/files could be referenced, etc. Is that right?

And another question for you: Is this for the use case where no network discovery is available, and remote service import can only be done with file-based (static) edef...and that static edef has to be customized for a given service import? Or are there other use cases that you need/want (modification of a discovered edef before import?