On 5/24/2016 10:57 AM, Neil Bartlett wrote:
Sorry Scott I didn’t read your earlier email closely enough, it looks
like you may already be doing basically what I suggested.
I’m unclear about how you can support DS while running on a legacy
back-end API such as ServiceLoader. Do you fake the OSGi APIs that the
existing DS implementation calls into?
All I've done so far is to include previously-built bundles/jars on the
Connect classpath (using the classpath bundle finder) on startup, and
used DS to register and export a remote service [1], and discover and
then dynamically inject remote service proxy into consumer (in jar) [2].
I know this isn't 'real' DS (with @Component in plain 'ol java code..not
just in bundle/jars), but that's where it is atm.
As for standardising this wrapper API… I don’t know, it might make an
interesting enRoute project; I don’t know if there would be much
interest in writing an OSGi spec for it.
On behalf of the potential users I think it would be a good idea...since
from my chair a major rap on OSGi from the java world is still OSGi's
complexity...which seems to me is a criticism mostly not focused on OSGi
services/remote services. But I've stated that view before in other
forums and it hasn't gone anywhere (that I know of).
For me DS does 95% of what I need, and when I do drop down to the
low-level API it’s nearly always on the provider side (i.e.,
register/unregister service) rather than the consume side, because
sometimes you need your service to reflect the state of entities in
the real world.
Sure. But there are plenty of situations I can think of...particularly
for RS/RSA...that would involve java-only consumers with osgi-providers,
vice-versa, etc., etc...particularly for remote services for IoT [1].
My observation is that the service registry/ds/remote services...and all
its micro-services relevance is (unfortunately IMHO) not the first thing
people (other than you, me, Peter and a few others) typically think
about WRT adopting OSGi.
Scott
[1] https://dzone.com/articles/network-dynamics-and-micro-services
Regards,
Neil.
On 24 May 2016, at 18:48, Scott Lewis <sle...@composent.com
<mailto:sle...@composent.com>> wrote:
On 5/24/2016 10:33 AM, Neil Bartlett wrote:
On 24 May 2016, at 18:25, Scott Lewis <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 <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
