I can see why the spec behaviour is defined that way. An optional service can still be temporarily unavailable either because the providing bundle starts after the consumer or because the providing bundle was temporarily removed. If we don't work this way, then it sounds like a bug to me.
Regards, Graham. On 15 November 2010 07:48, Valentin Mahrwald <[email protected]> wrote: > Hi, > > I have recently played around with optional reference elements (to get around > Blueprint automatically deregistering dependent services). One oddity I have > encountered is the behaviour when unsatisfied. My initial assumption as well > as that of people I have talked to was that a ServiceUnavailableException > would be thrown straight away. However, section 121.10.1 of the Blueprint > spec mandates that references with optional availability should wait in the > same way that mandatory references do: > > "When an operation is invoked on an unsatisfied proxy from a reference > manager (either optional or mandatory), the invocation must block until > either the reference becomes satisfied or a time-out expires (whichever comes > first). [...]" > > However, this behaviour does not work with our Blueprint implementation and > as far as the code below in ReferenceRecipe#getService is concerned can never > work: > > if (isStarted() && trackedServiceReference == null && > metadata.getTimeout() > 0 > && metadata.getAvailability() == > ServiceReferenceMetadata.AVAILABILITY_MANDATORY) { > blueprintContainer.getEventDispatcher().blueprintEvent(new > BlueprintEvent(BlueprintEvent.WAITING, > blueprintContainer.getBundleContext().getBundle(), > blueprintContainer.getExtenderBundle(), new String[] { getOsgiFilter() })); > monitor.wait(metadata.getTimeout()); > } > > Which to me suggests we are not implementing the spec but I am sure I have > missed something :-) Any thoughts? > > > Regards, > > Valentin
