[SM-2213] Service reference updating fails with <process>

• Type: Bug
• Status: Open
• Priority: Critical
• Resolution: Unresolved
• Affects Version/s: 3.4.2
• Component/s: servicemix-camel

Environment

Windows XP
Java(TM) SE Runtime Environment (build 1.7.0_21-b11)

• Assignee: Unassigned
• Reporter: Ephemeris Lappis
• Created: 13/Aug/13 09:59
• Updated: 13/Aug/13 09:59

Description

Hello.

I have two dependent modules :
1) an OSQi bundle with its BundleActivator that registers two service factories
2) a blueprint with service references to the first bundle's interfaces.

The blueprint references the service :

	<reference
		id="myFifiRead"
		interface="my.fifi.eight.camel.FifiReadService" />

And then a route uses the references :

		<route>
			<from uri="jetty:http://0.0.0.0:1111/fifi-8/read" />
			<to uri="bean:myFifiRead" />

This works as expected. When such a route processes an exchange, the service is called. When I update my bundle, the services seem to be "relinked" and the blueprint goes on working as if nothing had changed...

As my interfaces extends the Camel processor interface, I've changed the routes to use the DSL instruction instead of the bean "to" :

		<route>
			<from uri="jetty:http://0.0.0.0:1111/fifi-8/read" />
			<process ref="myFifiRead" />

This new code works as the first one, and seems to have rather better performances (about 75% on my test case and on my machine) that the "to"...
But now when I redeploy a new version of my bundle, the blueprint fails while stopping : after the OSGi bundle activator is stopped, and the "ungetService" callbacks are called, the routes update process blocks (status 'stopping' in the console) until a rather long timeout and ends with an error (first lines of log) :

org.osgi.service.blueprint.container.ServiceUnavailableException: Timeout expired when waiting for mandatory OSGi service reference: (objectClass=my.fifi.eight.camel.FifiReadService)
	at org.apache.aries.blueprint.container.ReferenceRecipe.getService(ReferenceRecipe.java:175)
	at org.apache.aries.blueprint.container.ReferenceRecipe.access$000(ReferenceRecipe.java:49)
	at org.apache.aries.blueprint.container.ReferenceRecipe$ServiceDispatcher.call(ReferenceRecipe.java:206)
	at org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.java:50)
	at org.apache.aries.proxy.impl.DefaultWrapper.invoke(DefaultWrapper.java:31)
	at org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java:78)

So, what is the main difference between the two ways of calling the service reference that make the second one fails when updating dependencies ? Is this a bug or a normal behavior ?

Is there a way using some parameters to make the dependency update works in both cases ?
Thanks for your help.

NB : I've tested this on versions : 4.4.2, 4.5.1 and 4.5.2 with the same behavior...

Regards.