You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by enigma <se...@gmail.com> on 2016/02/04 19:32:14 UTC
CamelBlueprintTestSupport No bean could be found in the registry
Hi,
I have a Junit test class extending CamelBlueprintTestSupport. The route has
reference to a POJO bean. When I execute the test method, I see the
following message -
Caused by: org.apache.camel.NoSuchBeanException: No bean could be found in
the registry for: requestBean
How do I add the POJO bean reference to the registery when using
CamelBlueprintTestSupport ?
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Normally the service interface and the service implementation are in separate bundles. This gives you a lot more flexibility in deployment and testing.
That said - here’s a set of projects that demonstrate all three ways - the service implementation embedded with the service interface, the service implementation in a separate bundle, and a stubbed service implementation. Hopefully the attachment comes through. If it doesn’t, I’ll have to figure out another way of getting it to you.
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
I do have interface and implementation in bundle 1 which is exposed as
service. Bundle 2 is where I am having reference to the interface only. I do
have dependency on the B1 captured in B2. If not for it then it'd result in
compilation problem. On the other hand, if I add a <scope>test</scope>
dependency then compilation of the project fails.
This is what I see in the logs -
:
:
org.apache.aries.blueprint.container.BlueprintContainerImpl Bundle
ExampleServiceTest is waiting for dependencies
[(objectClass=com.bundle1.example.api.ServiceInterface1),
(objectClass=com.bundle2.example.api.ServiceInterface2),
(objectClass=com.bundle2.example.api.ServiceInterface3)]
:
:
:
java.lang.RuntimeException: Gave up waiting for service
(objectClass=org.apache.camel.CamelContext)
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777246.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I would assume that MyServiceInterface is in one bundle, and you have another bundle with a private class implementing the interface and exposing that implementation as a service. If that is correct, then I normally create a stub for the service in my src/test/java/…../TestStubServiceImpl.java and register and instance of that class as a service for the MyServiceInterface interface.
If the implementation of the service is in the same bundle as MyServiceInterface, and that bundle exposes the implementation as a service, then having a dependency on that bundle should be sufficient.
If the implementation of the service is in a different bundle and you want to use that implementation, again, add a <scope>test</scope> dependency and the service should be available for you - you wouldn’t need addServicesOnStartup in either of these last two situations.
Generate a sample project using camel-archetype-blueprint v2.16.2 and see what it does - that should help.
> On Feb 4, 2016, at 2:27 PM, enigma <se...@gmail.com> wrote:
>
> I have to register OSGI reference present in the blueprint xml file. It is an
> interface class. So, in the following statement MySerivceInterface is the
> OSGI reference which is present in a different OSGI bundle. In the above
> reply it is metioned as TestStubServiceImpl need to be passed to asService()
> method. What is this TestStubServiceImpl ? How can we add the reference of
> MySerivceInterface OSGI bundle to the asService method call ?
> services.put(MySerivceInterface.class.getName(), asService(new
> TestStubServiceImpl(), null));
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777241.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
I have to register OSGI reference present in the blueprint xml file. It is an
interface class. So, in the following statement MySerivceInterface is the
OSGI reference which is present in a different OSGI bundle. In the above
reply it is metioned as TestStubServiceImpl need to be passed to asService()
method. What is this TestStubServiceImpl ? How can we add the reference of
MySerivceInterface OSGI bundle to the asService method call ?
services.put(MySerivceInterface.class.getName(), asService(new
TestStubServiceImpl(), null));
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777241.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
If the service in the second bundle is associated with or using the camel
context it won't work due to CBTS and PojoSR constraints. Does it work if
you deploy it to karaf?
On Tue, Feb 9, 2016 at 2:30 PM, enigma <se...@gmail.com> wrote:
> I cannot share the actual Project code that I am working on due to Client
> constraints. However, I used the same project (v2.16.2) that Quinn shared
> via Github. Created 2 different bundles B1 and B2. In my case, the 2
> bundles
> have 2 different camel contexts. In B1, there was service interface and
> implementation. The Test scenario, I wanted to test was Bundle B2 to invoke
> the actual service implementation in B1. I was able to invoke via Stub
> implementation using asService() method. I was looking for invoking the
> actual implementation of B1 service instead of creating the Stub
> implementation.
>
> Perhaps, you may want to use the same project that Quinn shared.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777491.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
I cannot share the actual Project code that I am working on due to Client
constraints. However, I used the same project (v2.16.2) that Quinn shared
via Github. Created 2 different bundles B1 and B2. In my case, the 2 bundles
have 2 different camel contexts. In B1, there was service interface and
implementation. The Test scenario, I wanted to test was Bundle B2 to invoke
the actual service implementation in B1. I was able to invoke via Stub
implementation using asService() method. I was looking for invoking the
actual implementation of B1 service instead of creating the Stub
implementation.
Perhaps, you may want to use the same project that Quinn shared.
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777491.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <br...@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 <br...@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 <se...@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.
>>>
>>
>>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
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 <br...@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 <se...@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.
>>
>
>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
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 <se...@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.
>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
Nifty. I hadn't considered the filter route before. I'm definitely going
to check that out. What I ended up doing is using a service factory which
reloads based on properties configuration changes. When the cfg file gets
changed to use the test or actual service impl it triggers a reload and the
factory instantiates the indicated class.
It works to a point. But it always feels like I'm hacking around the
limitations of CBTS and not really getting at the testing.
On Tue, Feb 9, 2016 at 1:02 PM, Quinn Stevenson <quinn@pronoia-solutions.com
> wrote:
> I haven’t had much success at attaching projects either - that’s why I
> went the GitHub route.
>
> You could put a small sample on GitHub ;-)
>
>
> > On Feb 9, 2016, at 11:49 AM, Brad Johnson <br...@mediadriver.com>
> wrote:
> >
> > I just had a "duh" moment when I re-read. My comments weren't referring
> to
> > the asService method specifically but the addServicesOnStartup method.
> > Apologies for any confusion there.
> >
> > If I had a good way to mock up a set of bundles to show the injection of
> a
> > second test stub bundle and attach it I'd do that but I don't think the
> > forum permits attachments.
> >
> > On Tue, Feb 9, 2016 at 12:44 PM, Brad Johnson <
> brad.johnson@mediadriver.com>
> > wrote:
> >
> >> I wish there was a way to see your code. But if you are exporting the
> >> service from the firs bundle AND it doesn't use a CamelContextRoute in
> that
> >> bundle, then you shouldn't need to invoke the asService method at all.
> The
> >> <test> scope will pick up your second bundle and register the service
> >> automatically.
> >>
> >> If you make a copy of your service provider bundle and just put a test
> >> stub inside it with a blueprint statement that exposes that interface
> and
> >> put a reference to that bundle in your consumer the test will
> automatically
> >> pick it up and register it. Unfortunately if that second bundle relies
> on
> >> CamelContexts and routes this will not work. So it is really only
> useful
> >> for creating test stubs.
> >>
> >> As Quinn pointed out if you create an API bundle and perhaps a models
> >> bundle that the other two projects depend on then they are decoupled. A
> >> test stub bundle would depend on the API, have a test implementation and
> >> then be exposed via its service interface.
> >>
> >> I could probably work this up as a project easier to demonstrate but i
> >> don't know if there's a way to do attachments.
> >>
> >>
> >> On Mon, Feb 8, 2016 at 1:37 PM, enigma <se...@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.
> >>>
> >>
> >>
>
>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I haven’t had much success at attaching projects either - that’s why I went the GitHub route.
You could put a small sample on GitHub ;-)
> On Feb 9, 2016, at 11:49 AM, Brad Johnson <br...@mediadriver.com> wrote:
>
> I just had a "duh" moment when I re-read. My comments weren't referring to
> the asService method specifically but the addServicesOnStartup method.
> Apologies for any confusion there.
>
> If I had a good way to mock up a set of bundles to show the injection of a
> second test stub bundle and attach it I'd do that but I don't think the
> forum permits attachments.
>
> On Tue, Feb 9, 2016 at 12:44 PM, Brad Johnson <br...@mediadriver.com>
> wrote:
>
>> I wish there was a way to see your code. But if you are exporting the
>> service from the firs bundle AND it doesn't use a CamelContextRoute in that
>> bundle, then you shouldn't need to invoke the asService method at all. The
>> <test> scope will pick up your second bundle and register the service
>> automatically.
>>
>> If you make a copy of your service provider bundle and just put a test
>> stub inside it with a blueprint statement that exposes that interface and
>> put a reference to that bundle in your consumer the test will automatically
>> pick it up and register it. Unfortunately if that second bundle relies on
>> CamelContexts and routes this will not work. So it is really only useful
>> for creating test stubs.
>>
>> As Quinn pointed out if you create an API bundle and perhaps a models
>> bundle that the other two projects depend on then they are decoupled. A
>> test stub bundle would depend on the API, have a test implementation and
>> then be exposed via its service interface.
>>
>> I could probably work this up as a project easier to demonstrate but i
>> don't know if there's a way to do attachments.
>>
>>
>> On Mon, Feb 8, 2016 at 1:37 PM, enigma <se...@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.
>>>
>>
>>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
I just had a "duh" moment when I re-read. My comments weren't referring to
the asService method specifically but the addServicesOnStartup method.
Apologies for any confusion there.
If I had a good way to mock up a set of bundles to show the injection of a
second test stub bundle and attach it I'd do that but I don't think the
forum permits attachments.
On Tue, Feb 9, 2016 at 12:44 PM, Brad Johnson <br...@mediadriver.com>
wrote:
> I wish there was a way to see your code. But if you are exporting the
> service from the firs bundle AND it doesn't use a CamelContextRoute in that
> bundle, then you shouldn't need to invoke the asService method at all. The
> <test> scope will pick up your second bundle and register the service
> automatically.
>
> If you make a copy of your service provider bundle and just put a test
> stub inside it with a blueprint statement that exposes that interface and
> put a reference to that bundle in your consumer the test will automatically
> pick it up and register it. Unfortunately if that second bundle relies on
> CamelContexts and routes this will not work. So it is really only useful
> for creating test stubs.
>
> As Quinn pointed out if you create an API bundle and perhaps a models
> bundle that the other two projects depend on then they are decoupled. A
> test stub bundle would depend on the API, have a test implementation and
> then be exposed via its service interface.
>
> I could probably work this up as a project easier to demonstrate but i
> don't know if there's a way to do attachments.
>
>
> On Mon, Feb 8, 2016 at 1:37 PM, enigma <se...@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.
>>
>
>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
I wish there was a way to see your code. But if you are exporting the
service from the firs bundle AND it doesn't use a CamelContextRoute in that
bundle, then you shouldn't need to invoke the asService method at all. The
<test> scope will pick up your second bundle and register the service
automatically.
If you make a copy of your service provider bundle and just put a test stub
inside it with a blueprint statement that exposes that interface and put a
reference to that bundle in your consumer the test will automatically pick
it up and register it. Unfortunately if that second bundle relies on
CamelContexts and routes this will not work. So it is really only useful
for creating test stubs.
As Quinn pointed out if you create an API bundle and perhaps a models
bundle that the other two projects depend on then they are decoupled. A
test stub bundle would depend on the API, have a test implementation and
then be exposed via its service interface.
I could probably work this up as a project easier to demonstrate but i
don't know if there's a way to do attachments.
On Mon, Feb 8, 2016 at 1:37 PM, enigma <se...@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.
>
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
@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.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
Perhaps I confused matters. The interface canonical name is the key to the
registry and the stub is the implementation. I'm not sure if PojoSR
proxies that as it would be in an actual OSGi environment but I'm guessing
that it does.
As you know the proxy class in OSGi dynamically implements the interface
and acts as the intermediary to calls to the actual implementation.
The OSGi/PojoSR are using the interface name as the key for look up. But he
was having a problem when he ran his two bundles of the second bundle not
finding the interface in the registry for a service that was being exported
by his first bundle. If the first bundle is in his POM with a scope of
test then it should be available during testing.
Sorry if I sewed confusion there.
Brad
On Mon, Feb 8, 2016 at 9:19 AM, Quinn Stevenson <quinn@pronoia-solutions.com
> wrote:
> I’m a little confused here - asService take the object implementing the
> interface and the service property key/values - I’m not sure how that could
> even work as an interface instead of the implementation object. The
> service interface is provided earlier in the call ( the key in services.put
> ), and I like having the string there as well so I don’t have to add
> dependencies to my project all the time (when I’m using OSGi classes that
> are provided by the framework).
>
> That said, I’m always looking for ways to simplify tests - do you have an
> idea on how this could work? Maybe you could do a prototype that we could
> see?
>
>
> > On Feb 7, 2016, at 6:43 PM, Brad Johnson <br...@mediadriver.com>
> wrote:
> >
> > According
> > to my humble opinion, the asService() method should ideally have
> Interface
> > instead of Implementation argument.
> >
> > The asService is there to create a proxy to the actual implementation
> class
> > I believe. What you are actually putting in the registry is a key of the
> > value of the full package and class name of the interface. That's what
> > blueprint is going to look up the service based upon. The value is what
> > you put in as the implementation.
> >
> > In a true blueprint environment that implementation will be hidden
> behind a
> > proxy object that exposes the interface. Any bundle wanting to use that
> > proxied implementation then just tells it what the package anc class name
> > of the interface are. In other words, when that interface is fetched
> from
> > the OSGi registry and handed to the requester, the requester doesn't know
> > what concrete implementation it is talking to. It may be a test stub, it
> > may be the actual implementation. In fact, if you try to then cast that
> to
> > the concrete implementation of the class it will fail because what it
> finds
> > is a proxy of the interface. This also makes it possible to hot swap
> > bundles at run time because the proxy stays the same but the
> implementation
> > changes.
> >
> > I'm still mystified why your test class wasn't picking up the service
> from
> > your first bundle though. If you have have it exported and referenced
> and
> > listed as a test dependency in your client bundle then it should be
> > automatically loaded up. One of those pieces sounds as if it is missing.
> >
> > @Override
> > protected void
> > addServicesOnStartup(Map<String,KeyValueHolder<Object, Dictionary>>
> > services) {
> > services.put( MyServiceInterface.class.getName(), asService(new
> > StubServiceImplementation(), "implementation", "stub"));
> > }
> >
> >
> > On Fri, Feb 5, 2016 at 4:53 PM, enigma <se...@gmail.com> wrote:
> >
> >> Thank you and Have a good weekend! :)
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777317.html
> >> Sent from the Camel - Users mailing list archive at Nabble.com.
> >>
>
>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I’m a little confused here - asService take the object implementing the interface and the service property key/values - I’m not sure how that could even work as an interface instead of the implementation object. The service interface is provided earlier in the call ( the key in services.put ), and I like having the string there as well so I don’t have to add dependencies to my project all the time (when I’m using OSGi classes that are provided by the framework).
That said, I’m always looking for ways to simplify tests - do you have an idea on how this could work? Maybe you could do a prototype that we could see?
> On Feb 7, 2016, at 6:43 PM, Brad Johnson <br...@mediadriver.com> wrote:
>
> According
> to my humble opinion, the asService() method should ideally have Interface
> instead of Implementation argument.
>
> The asService is there to create a proxy to the actual implementation class
> I believe. What you are actually putting in the registry is a key of the
> value of the full package and class name of the interface. That's what
> blueprint is going to look up the service based upon. The value is what
> you put in as the implementation.
>
> In a true blueprint environment that implementation will be hidden behind a
> proxy object that exposes the interface. Any bundle wanting to use that
> proxied implementation then just tells it what the package anc class name
> of the interface are. In other words, when that interface is fetched from
> the OSGi registry and handed to the requester, the requester doesn't know
> what concrete implementation it is talking to. It may be a test stub, it
> may be the actual implementation. In fact, if you try to then cast that to
> the concrete implementation of the class it will fail because what it finds
> is a proxy of the interface. This also makes it possible to hot swap
> bundles at run time because the proxy stays the same but the implementation
> changes.
>
> I'm still mystified why your test class wasn't picking up the service from
> your first bundle though. If you have have it exported and referenced and
> listed as a test dependency in your client bundle then it should be
> automatically loaded up. One of those pieces sounds as if it is missing.
>
> @Override
> protected void
> addServicesOnStartup(Map<String,KeyValueHolder<Object, Dictionary>>
> services) {
> services.put( MyServiceInterface.class.getName(), asService(new
> StubServiceImplementation(), "implementation", "stub"));
> }
>
>
> On Fri, Feb 5, 2016 at 4:53 PM, enigma <se...@gmail.com> wrote:
>
>> Thank you and Have a good weekend! :)
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777317.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
According
to my humble opinion, the asService() method should ideally have Interface
instead of Implementation argument.
The asService is there to create a proxy to the actual implementation class
I believe. What you are actually putting in the registry is a key of the
value of the full package and class name of the interface. That's what
blueprint is going to look up the service based upon. The value is what
you put in as the implementation.
In a true blueprint environment that implementation will be hidden behind a
proxy object that exposes the interface. Any bundle wanting to use that
proxied implementation then just tells it what the package anc class name
of the interface are. In other words, when that interface is fetched from
the OSGi registry and handed to the requester, the requester doesn't know
what concrete implementation it is talking to. It may be a test stub, it
may be the actual implementation. In fact, if you try to then cast that to
the concrete implementation of the class it will fail because what it finds
is a proxy of the interface. This also makes it possible to hot swap
bundles at run time because the proxy stays the same but the implementation
changes.
I'm still mystified why your test class wasn't picking up the service from
your first bundle though. If you have have it exported and referenced and
listed as a test dependency in your client bundle then it should be
automatically loaded up. One of those pieces sounds as if it is missing.
@Override
protected void
addServicesOnStartup(Map<String,KeyValueHolder<Object, Dictionary>>
services) {
services.put( MyServiceInterface.class.getName(), asService(new
StubServiceImplementation(), "implementation", "stub"));
}
On Fri, Feb 5, 2016 at 4:53 PM, enigma <se...@gmail.com> wrote:
> Thank you and Have a good weekend! :)
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777317.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
Thank you and Have a good weekend! :)
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777317.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <se...@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.
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
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.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
Check the META-INF that's created in the target directory or in the jar
file itself. Does the first bundle indicate the export of the interface
class and declaration of a service?
On Fri, Feb 5, 2016 at 12:42 PM, Quinn Stevenson <
quinn@pronoia-solutions.com> wrote:
> Yes - please do.
>
> Also - you may need to do a "mvn -DskipTests clean install” before the
> tests will work (I put this in one of the README.md’s as well). I’ve had
> to do that quite often when using services exposed from other bundles in
> tests.
>
>
> > On Feb 5, 2016, at 11:40 AM, enigma <se...@gmail.com> wrote:
> >
> > Thank you! . I will take a look and will let you know how it goes.
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777308.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Yes - please do.
Also - you may need to do a "mvn -DskipTests clean install” before the tests will work (I put this in one of the README.md’s as well). I’ve had to do that quite often when using services exposed from other bundles in tests.
> On Feb 5, 2016, at 11:40 AM, enigma <se...@gmail.com> wrote:
>
> Thank you! . I will take a look and will let you know how it goes.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777308.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
Thank you! . I will take a look and will let you know how it goes.
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777308.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I was afraid that might happen - I still haven’t figured out what you can and cannot attach to a message.
The sample is available on GitHub : https://github.com/hqstevenson/example-camel-osgi-service-testing.git
> On Feb 5, 2016, at 9:45 AM, enigma <se...@gmail.com> wrote:
>
> @Ranx - As you mentioned, I do have the OSGI service registry in Bundle B1
> and reference of the OSGI service in Bundle B2. The appropriate package
> structure is exported from B1 and it is imported in B2 pom xml files.
>
> @Quinn - I did not get the attachment files. Could you point me where I can
> download the files ?
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777297.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
@Quinn - I used the same camel-archetype-blueprint to have 2 projects and was
able to repro the above problem. One bundle B1 with interface and
implementation of Hello interface service. Another Bundle B2, with reference
to the Hello service. I must be making some fundamental mistake. If you
could please send me the attachment files that'd be of great help.
Steps followed -
* Create B1 with camel-archetype-blueprint v2.16.2
* Create B2 with camel-archetype-blueprint v2.16.2
* Declare osgi service registry for Hello Interface in B1
* Declare osgi reference for Hello Interface in B2
* Add dependency of B1 in B2 pom file.
* Export pkg structure from B1
* Import pkg structure in B2. The method addServicesOnStartup was commented
out in B2.
* Run the test method of BlueprintServiceRouteTest in B2 .
Error -
Bundle sample-blueprint-b1/0.0.1.SNAPSHOT is waiting for dependencies
[(objectClass=com.test.spring.sample.sample_blueprint_b1.Hello)]
Tests in error:
testRoute(com.test.spring.sample.sample_blueprint_b2.BlueprintServiceRouteTest):
Gave up waiting for service (objectClass=org.apache.camel.CamelContext)
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777307.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
@Ranx - As you mentioned, I do have the OSGI service registry in Bundle B1
and reference of the OSGI service in Bundle B2. The appropriate package
structure is exported from B1 and it is imported in B2 pom xml files.
@Quinn - I did not get the attachment files. Could you point me where I can
download the files ?
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777297.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by Ranx <br...@mediadriver.com>.
E. Nigma,
Did that solution resonate for you? Are you still stuck?
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777294.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by Ranx <br...@mediadriver.com>.
How are you setting up the service in the first bundle? How are you
referring to it in the second bundle?
If you are actually using the bundle during your test then as Quinn pointed
out you needn't use the override method. I suspect it is the service
declaration in the first bundle that is off or you aren't grabbing the
reference in the second bundle.
To declare your service and register it in the first bundle you add this to
the blueprint:
<service interface="com.foo.MyService" ref="myServiceImpl" />
<bean id="myServiceImpl" class="com.foo.internal.MySerivceImpl"/>
Then in the consuming bean you have to have the reference:
<reference id="mySerivceRef" interface="com.foo.MyService" />
The service is keyed in the OSGi registry by its interface name and not by
any reference name. So the reference here is telling the registry to look
for something proxied to that interface and set it to the id of
myServiceRef. Inside your consuming blueprint file you then use the
myServiceRef as if it were any other bean. If you actually examine it
though you'll see it is a proxy class that acts as a facade with that
interface.
If you still can't get it maybe post the blueprint snippets.
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777248.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
After debugging the Junit test, the object references were null and hence the
exception - "IllegalStateException: The service registration is no longer
valid." was thrown.
I did get the camel-archetype-blueprint v2.16.2. I see that the following
of adding service method call is invoked. The implementation class for the
Hello Interface is present in the same project and it is available.
services.put( Hello.class.getName(), asService(new HelloBean(), null,
null));
In my case, there are 2 OSGI Bundles (B1, B2). There is interface S1 and
implementation of it in B1. The OSGI Bundle B2 is referencing Bundle B1 for
Service1. The implementation class for Service1 is not exposed to B2. Only
Interface of S1 is available for B2. I am writing Junit Test method in B2
for testing a scenario which invokes Service1 from B2. How can I pass the
correct object reference from B2 in the aService method call?
Any suggestions?
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777244.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
The syntax of this looks correct. As Brad pointed out, the object references need to be valid when this method is called.
There is and example of registering test services in the sample generated by the camel-archetype-blueprint as well. My PR for this is in 2.17-SNAPSHOT version and 2.16.2. If you generate a small project using that archetype it may help.
> On Feb 4, 2016, at 2:15 PM, Brad Johnson <br...@mediadriver.com> wrote:
>
> What is your serviceObjectRef1?
>
> protected void addServicesOnStartup(Map<String, KeyValueHolder<Object,
> Dictionary>> services) {
> services.put(MySerivceInterface.class.getName(), asService(new
> TestStubServiceImpl(), null));
> }
>
> On Thu, Feb 4, 2016 at 3:11 PM, enigma <se...@gmail.com> wrote:
>
>> Thank you for the prompt response. I used the second option of using
>> blueprint xml and invoking getBlueprintDescriptor() method. The test method
>> is dependent on few OSGI services. I have few OSGI service references which
>> needs to be added during startup as follows-
>>
>> @Override
>> protected void addServicesOnStartup(
>> Map<String, KeyValueHolder<Object, Dictionary>>
>> services) {
>> services.put(Service1.class.getName(),
>> asService(serviceObjectRef1, null,
>> null));
>> services.put(Service2.class.getName(), asService(serviceObjectRef2,
>> null, null));
>> services.put(Service3.class.getName(), asService(serviceObjectRef3,
>> null, null));
>> }
>>
>> Looks like above syntax is incorrect and the following error is thrown -
>> java.lang.IllegalStateException: The service registration is no longer
>> valid.
>>
>> Could you please let me know the correct way of registering the service?
>>
>>
>>
>> --
>> View this message in context:
>> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777238.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Brad Johnson <br...@mediadriver.com>.
What is your serviceObjectRef1?
protected void addServicesOnStartup(Map<String, KeyValueHolder<Object,
Dictionary>> services) {
services.put(MySerivceInterface.class.getName(), asService(new
TestStubServiceImpl(), null));
}
On Thu, Feb 4, 2016 at 3:11 PM, enigma <se...@gmail.com> wrote:
> Thank you for the prompt response. I used the second option of using
> blueprint xml and invoking getBlueprintDescriptor() method. The test method
> is dependent on few OSGI services. I have few OSGI service references which
> needs to be added during startup as follows-
>
> @Override
> protected void addServicesOnStartup(
> Map<String, KeyValueHolder<Object, Dictionary>>
> services) {
> services.put(Service1.class.getName(),
> asService(serviceObjectRef1, null,
> null));
> services.put(Service2.class.getName(), asService(serviceObjectRef2,
> null, null));
> services.put(Service3.class.getName(), asService(serviceObjectRef3,
> null, null));
> }
>
> Looks like above syntax is incorrect and the following error is thrown -
> java.lang.IllegalStateException: The service registration is no longer
> valid.
>
> Could you please let me know the correct way of registering the service?
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777238.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: CamelBlueprintTestSupport No bean could be found in the
registry
Posted by enigma <se...@gmail.com>.
Thank you for the prompt response. I used the second option of using
blueprint xml and invoking getBlueprintDescriptor() method. The test method
is dependent on few OSGI services. I have few OSGI service references which
needs to be added during startup as follows-
@Override
protected void addServicesOnStartup(
Map<String, KeyValueHolder<Object, Dictionary>> services) {
services.put(Service1.class.getName(), asService(serviceObjectRef1, null,
null));
services.put(Service2.class.getName(), asService(serviceObjectRef2,
null, null));
services.put(Service3.class.getName(), asService(serviceObjectRef3,
null, null));
}
Looks like above syntax is incorrect and the following error is thrown -
java.lang.IllegalStateException: The service registration is no longer
valid.
Could you please let me know the correct way of registering the service?
--
View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228p5777238.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: CamelBlueprintTestSupport No bean could be found in the registry
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I usually use one of two ways.
The first is to override createRegistry and add your bean implementation there:
@Override
protected JndiRegistry createRegistry() throws Exception {
JndiRegistry registry = super.createRegistry();
registry.bind( "bean-id", new BeanClass() );
return registry;
}
The second is to create another blueprint.xml in src/test/resource/OSGI-INF/blueprint that creates your bean and then add it to the list of descriptors returned from getBlueprintDescriptor()
> On Feb 4, 2016, at 11:32 AM, enigma <se...@gmail.com> wrote:
>
> Hi,
> I have a Junit test class extending CamelBlueprintTestSupport. The route has
> reference to a POJO bean. When I execute the test method, I see the
> following message -
> Caused by: org.apache.camel.NoSuchBeanException: No bean could be found in
> the registry for: requestBean
>
> How do I add the POJO bean reference to the registery when using
> CamelBlueprintTestSupport ?
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/CamelBlueprintTestSupport-No-bean-could-be-found-in-the-registry-tp5777228.html
> Sent from the Camel - Users mailing list archive at Nabble.com.