Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Problem using multiple services from single server

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



Back to the top