| Re: [equinox-dev] Support for RFC 119 |
Comments in line below.
Tom
Scott Lewis wrote
>
> ECF is looking to implement OSGi 4.2 RFC 119 in the Galileo/ECF 3.0 release:
This is great news.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=249240
>
> 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:
>
> 5.2.2.2 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 attach a
> 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
ServiceException type.
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
out.
>
>
> /**
> * As specified by RFC 119 Distributed OSGi section 5.2.2.2.
> * Remote type of ServiceException.
> */
> public static final int REMOTE = 5;
>
>
> One question: does this framework change appear somewhere else in the
> r4.2 spec? (i.e. other than 119)? As it seems to imply that RFC 119
> isn't stand-alone (that is, it requires this small addition to framework).
See comments above.
>
> 3) There are several optional but recommended interfaces defined in RFC
> 119 (e.g. DistributionProvider, Discovery, ServicePublication,
> ServiceDescription). But it does not say in the RFC 119 spec (that I
> can find) where/what package these interfaces should/will be placed in.
> Are there conventions about this (placement) that dictate what
> package(s) these interfaces should be in? If so, where is that? If
> not, how is it decided where these will/should be? Should I open an
> equinox enhancement request for these interface additions as well?
>
All new api defined by RFC 119 is being added to the following packages
org.osgi.service.discovery
org.osgi.service.distribution
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.
> 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?
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 there
> 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.
>
> Thanks,
>
> Scott
>
>
I look forward to working with you from an Equinox perspective to
get this work started.
Thanks Tom.