Declarative Services are definitely useful for that, particularly the bind/unbind lifecycle methods. If you're using Java 1.8, you can tie that together with the Optional class (or Guice, or just some custom thing). I think there are different levels of dynamism possible depending on how tightly coupled you are to service references. Blueprint also helps a bit, but I like DS better in that it makes it more explicit and allows you to keep on running when optional services come and go.
On 13 August 2014 13:52, Matt Sicker <[email protected]> wrote: > Declarative Services are definitely useful for that, particularly the > bind/unbind lifecycle methods. If you're using Java 1.8, you can tie that > together with the Optional class (or Guice, or just some custom thing). I > think there are different levels of dynamism possible depending on how > tightly coupled you are to service references. Blueprint also helps a bit, > but I like DS better in that it makes it more explicit and allows you to > keep on running when optional services come and go. > > > On 13 August 2014 10:03, Raymond Auge <[email protected]> wrote: > >> Haha, this is great Peter, thanks! >> >> - Ray >> >> >> On Wed, Aug 13, 2014 at 2:14 AM, Peter Kriens <[email protected]> >> wrote: >> >>> Don't have a doc but I can give you some ammunition: >>> >>> 1) If they promise never, ever, ever, to throw an NPE, then you're >>> willing to discuss this case with them. >>> 2) It is a bit like SHAs, yes, theoretically they could clash, but life >>> is all about chances and I'll take the odds with SHAs any day. >>> 3) Assuming parts are perfect makes for -extremely- brittle systems. The >>> most reliable systems are made of unreliable parts. >>> 4) Tell them to shut up and use DS. This makes virtually use cases work >>> very well and the remaining are diagnosed. >>> 5) It is like fear of flying, after experience it will disappear. >>> 6) The dynamics in OSGi (should) reflect real change in the real world. >>> Would you handle that change better in a non-OSGi environment that OSGi >>> with its extremely well tested primitives for this? >>> 7) Could you make me a test case that shows the problem? (Dangerous, but >>> in general the test cases become really contrived, and if it isn't asked >>> them how they would solve it. They will either use OSGi's primitives or >>> make something awful). >>> 8) What are the consequences of a failure in that place? (You can >>> counteract then that an NPE/VM failure has the same effect, any system that >>> cannot handle failure is fundamentally flawed or of low interest). >>> >>> Or the final one: >>> >>> 8) What, is that true??? Oh my God! Stay there, I have to immediately >>> call IBM to tell them this so they scrap Websphere! They will be so >>> thankful for pointing this out to them! >>> >>> Or just let them read anti-fragile from Taleb. >>> >>> Kind regards, >>> >>> Peter Kriens >>> >>> >>> >>> >>> On 13 aug. 2014, at 07:59, Raymond Auge <[email protected]> >>> wrote: >>> >>> Hey All, >>> >>> Every other week a new developer comes around and starts asking those >>> smarty pants questions: >>> >>> Q: .. what about holding references, and bundles/services coming and >>> going during this time?? >>> >>> It makes me violent! >>> >>> Does anyone know of a document that discusses this topic so as I can >>> simply point them at it without having to enter into another often heated >>> debate about it? >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect >>> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) >>> >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>> >>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> 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) >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> > > > > -- > Matt Sicker <[email protected]> >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
