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.
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.
Scott
On 5/24/2016 7:39 AM, Raymond Auge wrote:
Oh! One thing we REALLY missed with this "bridge" API however was DS.
So that was knock against it.
OTOH
What it did was make developers understand the intent of DS when it
was being used suddenly by others from within the framework, and they
felt envy. So this lack of goodies at that bridge layer was actually a
driver toward adopting real modules.
Sincerely,
- Ray
On Tue, May 24, 2016 at 10:35 AM, Raymond Auge
<raymond.a...@liferay.com <mailto:raymond.a...@liferay.com>> wrote:
Peter we also have a similar separate API.
Our reason however is because we deliberately needed to segregate
ourselves from the OSGi API that might be in our host environment
(which might be an osgi runtime itself).
So having a separate API which is a wrapper for, but distinct
from, OSGi service layer has other values. For one it's easier to
map legacy code onto services without actually brining in OSGi,
which goes directly at what the OSGi Alliance refers to "services
first" migration to OSGi.
Sincerely,
- Ray
On Tue, May 24, 2016 at 10:20 AM, Scott Lewis
<sle...@composent.com <mailto:sle...@composent.com>> wrote:
On 5/23/2016 11:25 PM, Peter Kriens wrote:
Interesting! Another service fan :-)
Indeed.
One thing, why create a special API for this?
Because I believe it's clearer and therefore easier for
non-OSGi (java) programmers to consume...relative to either
the embedded framework or Connect.
Scott
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay, Inc.*
<http://www.liferay.com> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay, Inc.*
<http://www.liferay.com> (@Liferay)
Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org>
(@OSGiAlliance)
_______________________________________________
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
