> 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? > > 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. This would ensure that DS still works, along with all the other frameworks such as iPOJO, Blueprint etc, 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” ;-) Regards, Neil > > 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 < >> <mailto:sle...@composent.com>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 >> <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 <mailto:osgi-dev@mail.osgi.org> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <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
