I’m glad the examples helped.
The asService() helper is correct as written IMO.
The test framework isn’t responsible for figuring out what you want to use as
your test implementations. I don’t think I’d want to have to deal with
tracking down when the framework picked the wrong stub or whatever for a test.
You may be in a situation where everyone will use the real implementation of
the service in a test - then the “embedded” route in the sample will work just
fine. I’d prefer the “external” version where the interface and implementation
are in separate bundles. That gives you the opportunity to use different
services for testing - maybe to create situations that are difficult to make
happen without stubs. If you want to use the real implementation, add the
bundle with the service implementation and registration as a
<scope>test</scope> dependency and you should be fine. You can also write
you’re own “test” bundle that provides implementations of the interface, and
then you just use those in you’re tests - and you can decide which
implementation is correct for each test. Lots and lots of options.
The Route as written requires all three services. If you want to run the test
without one of them, you’ll need to change the blueprint - remove the
<reference …> for the service you want to get rid of, and also remove the call
to that service from the route. If you don’t remove the <reference ..> and the
service isn’t there, you Camel context will timeout starting - waiting for
dependencies. If you get rid of the reference and forget to remove the call
from the route, you’ll get a NPE.
Hopefully all that makes sense - it’s getting late on a Friday and it’s time to
quit for the weekend :-)
> On Feb 5, 2016, at 3:23 PM, enigma <send2she...@gmail.com> wrote:
>
> Ranx, Quinn - Thank you so much for helping me in finding resolution to this
> problem.
>
> @Ranx - Yes, the META-INF of B1 has export-package and export-service for
> the Hello service. Similary, the META-INF of B2 has the corresponding
> import-package and import-service of Hello service of B1.
>
> @Quinn - I followed the instruction as suggested by you for the new sample
> project that you sent me. The "blueprint-Consumer" project was of particular
> interest to me. I did see that there is following method override with Stub
> service implementation.
>
> @Override
> protected void addServicesOnStartup(Map<String,
> KeyValueHolder<Object, Dictionary>> services) {
> services.put( MyServiceInterface.class.getName(), asService(new
> StubServiceImplementation(), "implementation", "stub"));
> }
>
> If I follow similar way of having the Stub implementation then the
> CamelBlueprintTestSupport does work.
>
> Please help me understand or correct me if I am going wrong here. According
> to my humble opinion, the asService() method should ideally have Interface
> instead of Implementation argument. This way, the Test framework should
> ideally figure out the implementation because of dependency and OSGI
> reference provided in the blueprint. This will free up the Junit test class
> from having to replicate the entire implementation class as stub classes.
>
> Question - Does BlueprintServiceConsumerRouteTest work if do not have Stub
> implementation ?
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777315.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
