Brad -
Yes - I think you are right-on.
The example I put on GitHub consisted of three bundles - service-interface,
service-one and blueprint-consumer.
The service-interface bundle exports the Java interface for the service I use
throughout the tests. It also contains an implementation of the Java interface
that is not exported. Finally, to mimic what enigma was doing, it registered
an implementation of that interface as a service using Blueprint - i.e.
<service interface="com.pronoia.osgi.service.MyServiceInterface" >
<service-properties>
<entry key="implementation" value="embedded" />
</service-properties>
<bean class="com.pronoia.osgi.service.impl.MyServiceImplementation" />
</service>
The service-one bundle registered another implementation of the interface as a
service using Blueprint as well - i.e.
<service interface="com.pronoia.osgi.service.MyServiceInterface" >
<service-properties>
<entry key="implementation" value="external" />
</service-properties>
<bean class="com.pronoia.osgi.service.impl.AnotherServiceImplementation" />
</service>
The blueprint-consumer bundle consists of a simple Camel route written using
the Blueprint DSL that references three services that implement the Java
interface exported by the service-interface bundle. The instances of the
references are distinguished by service-properties - the service registered by
the service-interface bundle has “implementation=embedded”; the service
registered by the service-one bundle has “implementation=external”; and there
is a third service reference with “implementation=stub”. This third service is
provided by a stub implementation in the bundle-consumer ( src/test/java/…. )
and it is registered as a service using addServicesOnStartup. The blueprint
looks like this
<reference id="embedded-service"
interface="com.pronoia.osgi.service.MyServiceInterface"
filter="implementation=embedded"/>
<reference id="external-service"
interface="com.pronoia.osgi.service.MyServiceInterface"
filter="implementation=external"/>
<reference id="stub-service"
interface="com.pronoia.osgi.service.MyServiceInterface"
filter="implementation=stub"/>
<camelContext id="blueprint-context"
xmlns="http://camel.apache.org/schema/blueprint";>
<route id="timerToLog">
<from uri="timer:blueprint-consumer"/>
<setBody>
<constant>Dummy Body</constant>
</setBody>
<bean ref="embedded-service" method="execute"/>
<bean ref="external-service" method="execute"/>
<bean ref="stub-service" method="execute"/>
<to uri="mock:result"/>
</route>
</camelContext>
So when the test is run, it calls all three services (which don’t do anything
besides log who they are). The service-reference for
filter=“implementation=embedded” is on the class path because of the Maven
dependency on the service-interface bundle. Also, the service-reference for
filter=“implementation=external” is on the class path because of the Maven
dependency on the service-one bundle. Note that I meant to have this
dependency scoped as a test dependency - that was my error. Finally, the
service-reference for filter=“implementation=stub” is provided in the test
class derived from CamelBlueprintTestSupport by overriding the
addServicesOnStartup.
My intent was to show three ways of accomplishing the testing, but I may have
overdone it a bit - sorry about that.
In order to test without the stub, the reference for
filter=“implementation=stub” would need to be removed as well as the call to
that service ( <bean ref=“stub-service” … />. Then, only the “real”
implementations would be used - which I think is what enigma was after.
Hopefully all of that makes sense (and doesn’t confuse matters further).
> On Feb 9, 2016, at 10:47 AM, Brad Johnson <brad.john...@mediadriver.com>
> wrote:
>
> Quinn,
>
> Did this finally make some sense. I think I must have inadvertently
> confused matters and that certainly wasn't my intention.
>
> On Mon, Feb 8, 2016 at 9:44 PM, Brad Johnson <brad.john...@mediadriver.com>
> wrote:
>
>> What I meant was if he is using the actual implementation or the test stub
>> is the second bundle then he can simply refer to in the test scope.
>> There's one huge caveat there though. It has to be a pure OSGi service
>> that does not rely on another CamelContext. PojoSR is not capable of
>> testing across multiple contexts. My guess is that he has something
>> associated with a second camel context in the service bundle. So if the
>> bundle declares a service like:
>>
>> <service interface="my.foo.DBConnector">
>> <bean class="my.foo.internal.DatabaseConnectorImpl" />
>> </service>
>>
>> or
>>
>>
>> <service interface="my.foo.DBConnector">
>> <bean class="my.foo.internal.TestStubDatabaseConnectorImpl" />
>> </service>
>>
>> Then that can be used during testing from one bundle to the other and
>> switched to and from the actual implementation to a test implementation by
>> changing what the bean class is.. It can use its own blueprint xml,
>> obviously, it just can't rely on a second camel context.
>>
>> Those can be switched. In some cases one can then use this:
>>
>>
>> <service interface="my.foo.DBConnector">
>> <bean class="${databaseImplClazz}" />
>> </service>
>>
>> And change it with configuration. As long as one doesn't get multiple
>> contexts involved. Hopefully in Camel 3 they will move to a karaf
>> environment for tests (whether through Pax Exam or something else.)
>>
>> When my clients ask what I find weakest in Camel/blueprint I automatically
>> reply "testing".
>>
>>
>>
>> On Mon, Feb 8, 2016 at 1:37 PM, enigma <send2she...@gmail.com> wrote:
>>
>>> @Ranx - With reference to your statement - " If the first bundle is in his
>>> POM with a scope of
>>> test then it should be available during testing. ".
>>>
>>> Are you saying that it is possible to invoke the asService method *without
>>> *the the Stub Implementation and the OSGI can invoke the actual
>>> implementation?
>>>
>>> If that is the case, then I have tried it that approach and was NOT
>>> successful. Not sure, if I am missing something here.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777405.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>
>>
