On 5/24/2016 10:33 AM, Neil Bartlett wrote:
On 24 May 2016, at 18:25, Scott Lewis <sle...@composent.com
<mailto:sle...@composent.com>> wrote:
It was/is not my desire to define a new API, but as per my and Ray's
and other's needs, I believe it does make sense. I would like to
see a standardized API and am willing to contribute to such an effort
but that currently doesn't exist.
So you’d like to see a service API that is (a) standardised and (b)
exists. Seems to me that the OSGi API checks both those boxes. What am
I missing?
The full OSGi API brings with it a whole bunch of other functionality
that is unavailable/irrelevant to the java-only programmer...and
therefore provides unnecessary complexity. My assertion would be that
simplification does help those that are new to OSGi (much of the larger
java world).
FWIW, I used the 'org.eclipse.ecf' package namespace only because
it's one that I currently have access to.
I think Ray's point is a good one...I've got several impls of this
ServiceRegistry API...e.g. Connect, Concierge, Equinox, Felix..these
might make more sense in some deployment environments than others.
Ray's point about the 'envy' of DS is interesting...although seems
like a trivial addition to this API would/could eliminate much of the
envy :). The examples in my repo use DS (Felix SCR impl) for dynamic
remote services injection+service dependencies, and it works
beautifully. Adding on tooling and/or API to allow use of
@Component, etc in plain ol' java projects would be very cool.
So, wouldn’t it be a better approach to use the existing OSGi service
API and build your new API on top of it? You could take advantage of
modern Java idioms that were not available back when OSGi was
invented, such as lambdas, try-with-resource blocks, etc.
The ServiceRegistry API does essentially that (i.e. provide access to
the OSGi service API) [1]. I suppose I'm missing something about your
point.
This would ensure that DS still works, along with all the other
frameworks such as iPOJO, Blueprint etc,
DS does work just fine (along with every other OSGi-based service
framework that I've tried so far) . Obviously there are/will be
limitations.
and at the same time you could give people a direct programmatic
service API if they want one.
Also you would benefit from the battle-hardened, thread-safe code in
the existing service registry implementations. Incidentally I would
like to build a similar API for bundle and configuration control, so
that I don’t have to explain for the umpteenth time that you need to
refresh after updating/installing/uninstalling a set of bundles. This
is on my TO DO list, right underneath “learn Chinese” ;-)
I'm confused. Please feel free to present better alternative(s) to [1]
that meet and simplify these java-only service registry use cases (maybe
before Chinese?), but I don't really get the criticisms you seem to be
raising.
Scott
[1]
https://github.com/ECF/ServiceRegistry/blob/master/projects/org.eclipse.ecf.osgi.serviceregistry/src/org/eclipse/ecf/osgi/serviceregistry/ServiceRegistry.java
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
