scottslewis
commented
3 years ago Hi Patrick.
First let me explain why things are the way they are now (and a little about how they are now).
EDEF itself is specified by the OSGi remote services and rsa chapters (100 and 122). The edef format is simply an xml expresssion of an arbitrary set of properties (name->type:value pairs). The remote services spec, however, has a set of properties that must (or optionally) be present...under different service import/export circumstances. For the Jersey provider, as you say there are really only a couple properties that change and the others can be set to defaults or generated randomly.
ECF implements the spec and so the normal rsa mechanism generates edef on export, and then typically uses discovery to publish and discover those edefs. Just FYI: As per spec, there is a 'topology manager'...which can be replaced...that listens for discovered endpointdescriptions, and with default topology manager simply calls RemoteServiceAdmin.importEndpoint(EndpointDescription ed) to actually import the endpoint description.
For your use case, however, since you are constructing and 'discovering' client-side edef (and there is no server-side edef and no discovery needed) you need to either create edef manually OR create instances of EndpointDescriptions at runtime and import them via the RemoteServiceAdmin service instance via its importService method
ECF has a couple of utility classes in it's implementation of the RemoteServiceAdmin that are helpful in reading, writing, and constructing EndpointDescription instances...i.e.:
EndpointDescriptionReader EndpointDescriptionWriter EndpointDescription
This is all for your context...as I understand that all you want is a simpler way to create your client-side edef that your system can discover.
Particularly since others have described similar use cases (client-side only edef creation and use for service import), I do think it might make sense to have some sort of new ECF-specific service that (e.g.) 1) takes a set of default properties (as map), 2) Takes another properties map that specifies additional and/or overriding values. These two maps could then be merged, and it could return an ECF EndpointDescription...that can then be used either to pass to RemoteServiceAdmin.importService directly...or can be written to a stream/file via EndpointDescriptionWriter. e.g.:
public interface EndpointDescriptionTemplater {
EndpointDescription createUsingTemplate(Map<String,?> templateProperties, Map<String, ?> overridingProperties);}
The idea would be that your service could use such a service with a fixed-constant map for templateProperties (for rest remote services); and just read and provide props for overridingProps.
To me, this does appear well-suited to config admin, but I don't think that RCP apps have an impl of config admin present by default, do they?
I would prefer introducing a new service instead of extension point as then it would be usable in all OSGi environments (karaf, etc).
Another idea would be to use the Eclipse variable filtering/text substitution...i.e. have a text file with variable references (i.e. a template edef with variables), have eclipse do the variable substitution using org.eclipse.core.variables. If an RCP app, org.eclipse.core.variables may very well be in your target platform already.
LMK what you think. Let me know your thoughts.
modular-mind
I'm creating this issue really just to start a discussion. In my work with the JAX-RS client in the past I've found the EDEF xml files to be difficult to work with. There are two main issues:
When creating a simple REST client, I think there are really only two properties that are unique: the endpoint URI (ecf.endpoint.id) and the remote service interface (objectClass). The rest of the properties (I think) can be set to defaults or generated randomly.
The endpoint URI often needs to be configured for different environments (test/beta/prod).
My solution has been to create an extension point (these are RCP apps) called "endpointDescriptions" that has only these two attributes. When multiple environments are needed, I've had the extension reference a properties file listing all of the URIs. Finally, an OSGi service called an EndpointManager reads these from the extensions on startup and then generates and registers the actual EndpointDescriptions.
I was wondering what your opinion of a best practice is in this context. I've looked into Config Admin of course, but I want to keep this extremely simple to allow for easy integration into Eclipse RCP applications. I'm sure extension points are not ideal when looking at other non-Eclipse environments like Karaf. Is there an easier way to get this done?