[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] Support for RFC 119
- From: Scott Lewis <slewis@xxxxxxxxxxxxxxxxx>
- Date: Wed, 14 Jan 2009 14:16:38 -0800
- Delivered-to: email@example.com
- User-agent: Thunderbird 22.214.171.124 (Windows/20081209)
Thanks for the responses. Follow up inline below.
Thomas Watson wrote:
Comments in line below.
Scott Lewis wrote
> ECF is looking to implement OSGi 4.2 RFC 119 in the Galileo/ECF 3.0
This is great news.
> After reading the RFC 119 spec, it seems that there are only a very few
> implications for equinox itself:
> 1) RFC 119 depends upon RFC 126 (which is the Service Registry Hooks
> rfc), which after inspecting the org.eclipse.osgi bundle has apparently
> been implemented in HEAD/3.5. Thanks to whoever did that! I'm
> testing/using it now and will immediately report any issues found.
Thanks goes to BJ Hargrave for this. We look forward to you using this
feature. This feature is also being used by OSGi members to implement
the RI for RFC 119.
> 2) In the RFC 119 draft that I have, their is an addition of a new type
> for org.osgi.framework.ServiceException. From RFC 119:
> 126.96.36.199 Exception Handling
> There will be a new type of exception for the ServiceException: REMOTE.
> This type of exception is thrown when
> there is an issue with the distribution software used to covert between
> the protocol-specific and OSGi invocations.
> After looking at ServiceException, I see that that REMOTE type value is
> not currently defined in org.osgi.framework.ServiceException (on
> org.eclipse.osgi HEAD). How should this addition be properly affected?
> Should I open an enhancement request to add a REMOTE type and
> patch to contribute an addition/change? (e.g.):
Hmmm it looks like there is a gap here in the companion code provided by
OSGi (org.osgi.* packages). I opened a bug against the enterprise
expert group to sort this out. I suspect they should be defining a
new exception (RemoteServiceException) which uses the SUBCLASSED
For now you can just throw a ServiceException of UNKNOWN or if you
want you could just use your own value for the type until we sort this
Ok, is this something I/we can track or is it OSGi members only?
All new api defined by RFC 119 is being added to the following packages
I have an open CQ to use the OSGi companion code from the R4.2
specification (see https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2795)
The osgi-cmpn jar contains these two packages for R4.2. I think
an ECF implementation would want to include these APIs and export it
themselves instead of having some unrelated 'util' bundle export them
from equinox. You can open another CQ for ECF and piggy back the
one from above.
OK done. The ECF CQ is:
> 4) There are several new service property name constants. How/where
> should these be added? (on Constants? or some other/new interface for
> remote service properties?).
The API contained in the packages above define several new constants.
Are these the ones you are referring to?
I'll take a look. I haven't seen the cmpn code before so if they are
*not* there I'll bring it up again here.
If there are others that belong in org.osgi.framework.Constants then
please let me know and I will raise issues with OSGi.
> By my reading, with the addition of 2, and answers to 3 and 4 that
> will be no more required additions/changes to Equinox in order to
> support RFC 119. Please let me know if I should open enhancement
> requests and create attachments...or do something else...to effect the
> necessary changes and additions.
I look forward to working with you from an Equinox perspective to
get this work started.
Thanks much. One question: If we/ECF is going to have or create the
bundle that exports the distribution provider and discovery interfaces
from the r4.2 cmpn...should this bundle be in the equinox namespace (and
if so what?) or should it be in the ecf namespace (i.e. in
org.eclipse.ecf core bundle or some such)?
We can work this out 1-1 if you prefer Tom...let me know if you would
rather I contact you or equinox dev team directly to settle these questions.