| 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
 
 
 
 |