On 10/5/2015 5:46 AM, Marin Orlić
wrote:
Hi,
what would be the
preferred method of dynamically changing the endpoint URL
registered for a remote REST service?
I can register
the service with an EDEF initially, but the requirement is
that the endpoint must be changeable via workspace
preferences. My guess is that a listener on preference
change could trigger service registration using dynamically
generated EDEF properties? How to start with that and what
properties need to be changed along with endpoint URI (endpoint.service.id?).
I think what you've outlined above is basically right. Before
discussing this in detail though I need to check an assumption: I
assume that when you say 'dynamically changing the endpoint URL' you
essentially mean:
1) Unregistering the existing remote service (i.e. at the old
endpoint URL)
2) Registering the remote service at the new endpoint URL
If this isn't a correct interpretation of what you've described as
'changing the endpoint URL' then please correct and detail.
Assuming this is what you want to do then I can think of two ways to
do it:
1) Calling ServiceRegistration.unregister() on first remote service
registered
2) Registering the remote service with the new endpoint URL
The above assumes that you are using the (default)
BasicTopologyManager (in the
org.eclipse.ecf.osgi.services.distribution bundle). The other way
it so *bypass* the BasicTopologyManager and do the same thing by
calling the RemoteServiceAdmin API direct...e.g.
1) Call
org.osgi.service.remoteserviceadmin.ExportRegistration.unregister()
2) Call
org.osgi.service.remoteserviceadmin.RemoteServiceAdmin.exportService()
The difference between these two methods is that in the first case
the *local* service will be unregistered and then reregistered
(because the BasicTopologyManager has a service hook that calls the
underlying RSA methods), while in the second case the local service
will remain active during the possibly short period between
unregister() and the registration of the new service. Another
difference is that the service discovery (i.e. unpublish, publish)
will be done automatically by the BasicTopologyManager in the first
case, but will not be done automatically in the second case.
As you can see the first approach uses just the BTM and the OSGi
service registry, the second uses the OSGi RSA api. Neither use any
ECF-specific API and I don't see any reasons why these couldn't be
called in response to a workspace preference change (although if
that's called by the UI thread you might need to do in some other
thread).
>How to start with that
and what properties need to be changed along with endpoint URI (endpoint.service.id?).
I would suggest that rather than trying to create the new EDEF
by hand, that you get the new EndpointDescription from the
ExportRegistration (returned from
RemoteServiceAdmin.exportService() via
getExportReference().getExportedEndpoint()) and use that. If
you ultimately decide that you would like to manipulate the EDEF
by hand then we can discuss further the properties that
need/should be changed (there are only ~3), but no reason to go
to that trouble unless necessary.
Scott
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|