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,

After thinking about this a little bit, I believe I have more of an explanation for what's going on with you/your use case.  In short, I think it comes down to this:

On 3/11/2015 3:10 AM, Peter Hermsdorf wrote:
<stuff deleted>
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).
Of course thats a problem. I tried upgrading to the latest version, but as you already statet, there is a dependency to a core equinox.osgi package version 1.7 whereas eclipse indigo only has version 1.6 available.

An upgrade of our RCP app to Eclipse 4 is planned, but currently not in work. I case we would need a fix in ECF 3.7 I would consider patching/building it myself ....

i.e. the version of ECF RSA that you are using (ECF 3.7/Indigo) was done prior to two changes that are affecting you:

1) It was prior to the OSGi RSA 1.1 specification, which required reworking the use of the edef-given properties...for both discovery and distribution/lookup/import on the consumer.   The reason this was necessary was that RSA 1.1 added the notion of a remote service 'update' (i.e. updating the remote service's properties), and so to do this with EDEF meant adding additional properties, and more importantly, changing the semantics/handling of endpointdescription equality.  I now believe this is why my initial response of making the endpoint.service.id unique in your generated edef didn't for you, because you are using a version prior to when this property (only) was used to determine ed uniqueness.

2) Some changing (simplification, really) of use of ECF-specific remote service properties.  I can't immediately go into technical detail here, as I have to remind myself about the specifics (I've forgotten), but I'm pretty sure that that's this could be affecting you/your use case as well.

IMHO there are two ways to deal with this:

1) Help you transition to ECF 3.9.3 (or something more recent from ECF).   One thing to consider:   I'm pretty sure that ECF 3.9.3 will run properly on Equinox Kepler or later, and I believe that Kepler had/has support for RCP 3.8 (as opposed to requiring that you move to Eclipse 4.x immediately).   

2) As you say above, we could look to apply a 'fix' to ECF 3.7 (what you are experiencing may not actually be a bug in 3.7, but rather simply not yet applying the right set of remote service property values...I'm not sure at this point).  I will help with this if you so desire, but as you might expect I'm not anxious to do this...i.e. I would prefer 1.   Why?  Two reasons:  a) Moving forward it's simpler for ECF; b) When you move to something more recent in terms of ECF versions it would be better if you didn't have to rework your edef in addition to adjusting to the UI and other changes.

I'm willing to help with either 1 or 2 based upon what you decide, but I'm limited by resources (my time).

To help me figure out what would be involved with 2, would you let me know what the exact version of ECF you are using is?  (i.e. with qualifier)

Thanks,

Scott


Back to the top