In that case it would mean that the Blueprint used in Karaf 3.0.2 was bugged… why not. But I don’t catch how the system determines that the service publishing/discovery has ended and then missing services are errors. I have the feeling that the starting phase ends too early for some reason.
Are there any Aries blueprint settings about parallelism or things like that? JP [@@ OPEN @@] De : Christian Schneider [mailto:[email protected]] De la part de Christian Schneider Envoyé : vendredi 18 septembre 2015 14:22 À : [email protected] Objet : Re: Karaf upgrade 3.0.2 -> 4.0.1 leads to ServiceUnavailableException I think you are getting the expected result. I was wrong with the assumption that you get null. Blueprint will always inject a service proxy. The reason is that it can inject the proxy only at the context start. So the ServiceUnavailableException when you use the service is the way blueprint tells you that no service is present. So if you access the service in the factory it will fail with this exception. If you do not refer to it blueprint will start normally but of course you could still get the exception whenever you access the service and it is not there. Christian On 18.09.2015 14:13, CLEMENT Jean-Philippe wrote: Christian, I did some further testing. If I don’t use the reference then I get no error which is strange as I still declare it (and the activation is eager). Maybe this is due to some optimization? If I give the reference to a simple test bean as argument or property then I get the same issue: 1. ServiceUnavailableException: No matching service for optional OSGi service reference 2. The bundle (A) is still NOT waiting for any “grace period” of any kind and directly fails to start If I use a reference-listener then no issue but the availability still has to be optional in order not to go in grace period. I did not succeed in getting a null object. Why isn’t the bundle (A) waiting before failing? JP -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
