Hi Peter,
I think that the problem might be this:
On 3/10/2015 8:27 AM, Peter Hermsdorf wrote:
Hi folks,
<stuff deleted>
<property name="endpoint.service.id" value-type="Long"
value="0"/>
The endpoint.service.id *must be unique* for each endpoint
description, and if all of them have '0' as the value then only one
of them will actually be discovered. The technical reason for this
is that the discovery mechanism uses this value to decide whether
one/multiple endpoint descriptions are equal, and if they are it
doesn't need to pay attention to duplicates.
I suspect that the solution for you might be to have some unique
value set for each of these separate endpoint descriptions. It
could be just sequence...i.e. 0, 1, 2, 3 etc., or it could be a
random number, they just have to be unique.
Interesting/surprising coincidence on timing of this problem...I
just helped another ECF consumer with what might be the exact same
problem of importing (using edef files with a non-unique
endpoint.service.id).
<stuff deleted>
On client side only one of the remote services gets registered (i
think the last one/2nd ....)
Should this setup work this way or is there another approach
needed to provide/consume multiple services?
I also tried using different values for
ecf.generic.server.path (in the above
axample "/server") for the two different services on
client and server but also with no luck ...
My environment:
- ECF version 3.7 (i'm currently bound to eclipse indigo 3.7 RCP)
This is now a pretty old version of ECF...particularly wrt to the
RSA impl. There was a bug recently discovered, fixed and deployed
in 3.9.3 WRT the processing of multiple edef files
https://bugs.eclipse.org/bugs/show_bug.cgi?id=461348
Note that a workaround for the above is to not have any spaces in
the Remote-Service header values...e.g.
Remote-Service: OSGI-INF/file1.xml,OSGI-INF/file2.xml,etc.
Realistically, it might become difficult/impossible to support ECF
3.7 on Indigo for much longer...and I *believe* that ECF 3.9.3 will
run on everything back to Kepler (although I admit I haven't tested
on Kepler yet...I will do so/help do so, however, if that is
necessary. Please let me know). The dependency here is on the use
of the OSGI Wiring API (required for compliance with modern versions
of OSGi RSA spec), which I *think* only appeared in Kepler version
of Equinox (can't remember what number version of Equinox that was
right now).
Anyway, please let all know what can be done to help here.
Scott
|