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é (@rotty3000)
> Senior Software Architect
> Liferay, Inc. (@Liferay)
>
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
