You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Martin Ford <Ma...@monitise.com> on 2013/02/05 15:18:24 UTC
Mocking an endpoint in a blueprint that contains a property
placeholder
Hi,
I have a simple blueprint route that uses camel-mail to send an email. The protocol (i.e. component), host and port are set up as property
placeholders:
<route id="myRoute">
<from uri="direct:sendEmail"/>
<to uri="{{email.protocol}}://{{email.host}}:{{email.port}}" />
</route>
When deployed to Fuse ESB the blueprint containing this route works fine. My problem comes when trying to mock the to endpoint in a unit test (which extends CamelBlueprintTestSupport).
When I run my test I find that it's looking for a ComponentResolver for component={{email.protocol}}, which makes sense. Unfortunately this seems to be happening during the creation of the CamelContext so I can't mock it or replace it with a stub.
I believe I could create a ComponentResolver to handle such a component, but I'd rather not. Is there a simpler solution?
If you're wondering, I've got the component part of the endpoint as a property placeholder so we can easily configure smpt vs. smtps.
Thanks
________________________________
This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying, disclosure or taking of any action in reliance upon it by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. Monitise accepts no liability if this email harms any systems or data of the recipient (including as a result of software virus infection or where this e-mail is modified or amended in any way during or following transmission) or if this email is accessed by anyone other than the person(s) to whom it is addressed.
The Monitise group includes Monitise plc (Reg. No. 6011822), Monitise Group Limited (Reg. No. 5590897), Monitise International Limited (Reg. No. 5556711), Monitise Europe Limited (Reg. No. 4831976) and Mobile Money Network Limited (Reg. No. 7153130). These companies are registered in England and Wales and their registered office address is 95 Gresham Street, London, EC2V 7NA United Kingdom.
Re: Mocking an endpoint in a blueprint that contains a property
placeholder
Posted by fordm <fo...@gmail.com>.
Claus Ibsen-2 wrote
> I think there is a method on CamelTestSupport =
> useOverridePropertiesWithPropertiesComponent you can override and
> return the properties to use for testing.
> I guess we should document that on:
> http://camel.apache.org/camel-test.html.
There is indeed a useOverridePropertiesWithPropertiesComponent method and
I've tried overriding it but it has no effect.
The issue appears to be in the CamelBlueprintTestSupport setUp method (a
call to CamelBlueprintHelper.createBundleContext), where the blueprint being
loaded / parsed. Any components (e.g. direct, file, smtp, etc.) seem to be
identified and their resolvers (eagerly?) loaded. It's at this point that
it's trying to find a component resolver for {{email.protocol}}.
This occurs directly before the useOverridePropertiesWithPropertiesComponent
method call.
--
View this message in context: http://camel.465427.n5.nabble.com/Mocking-an-endpoint-in-a-blueprint-that-contains-a-property-placeholder-tp5726972p5727049.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Mocking an endpoint in a blueprint that contains a property placeholder
Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Feb 6, 2013 at 6:15 PM, fordm <fo...@gmail.com> wrote:
> Claus Ibsen-2 wrote
>> I think there is a method on CamelTestSupport =
>> useOverridePropertiesWithPropertiesComponent you can override and
>> return the properties to use for testing.
>> I guess we should document that on:
>> http://camel.apache.org/camel-test.html.
>
> There is indeed a useOverridePropertiesWithPropertiesComponent method and
> I've tried overriding it but it has no effect.
>
> The issue appears to be in the CamelBlueprintTestSupport setUp method (a
> call to CamelBlueprintHelper.createBundleContext), where the blueprint being
> loaded / parsed. Any components (e.g. direct, file, smtp, etc.) seem to be
> identified and their resolvers (eagerly?) loaded. It's at this point that
> it's trying to find a component resolver for {{email.protocol}}.
>
> This occurs directly before the useOverridePropertiesWithPropertiesComponent
> method call.
>
Hi
Thanks for sharing your observation. I have logged a ticket
https://issues.apache.org/jira/browse/CAMEL-6044
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Mocking-an-endpoint-in-a-blueprint-that-contains-a-property-placeholder-tp5726972p5727046.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen
Re: Mocking an endpoint in a blueprint that contains a property
placeholder
Posted by fordm <fo...@gmail.com>.
Claus Ibsen-2 wrote
> I think there is a method on CamelTestSupport =
> useOverridePropertiesWithPropertiesComponent you can override and
> return the properties to use for testing.
> I guess we should document that on:
> http://camel.apache.org/camel-test.html.
There is indeed a useOverridePropertiesWithPropertiesComponent method and
I've tried overriding it but it has no effect.
The issue appears to be in the CamelBlueprintTestSupport setUp method (a
call to CamelBlueprintHelper.createBundleContext), where the blueprint being
loaded / parsed. Any components (e.g. direct, file, smtp, etc.) seem to be
identified and their resolvers (eagerly?) loaded. It's at this point that
it's trying to find a component resolver for {{email.protocol}}.
This occurs directly before the useOverridePropertiesWithPropertiesComponent
method call.
--
View this message in context: http://camel.465427.n5.nabble.com/Mocking-an-endpoint-in-a-blueprint-that-contains-a-property-placeholder-tp5726972p5727046.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Mocking an endpoint in a blueprint that contains a property placeholder
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Feb 5, 2013 at 3:18 PM, Martin Ford <Ma...@monitise.com> wrote:
> Hi,
>
>
>
> I have a simple blueprint route that uses camel-mail to send an email. The protocol (i.e. component), host and port are set up as property
>
> placeholders:
>
>
>
> <route id="myRoute">
>
> <from uri="direct:sendEmail"/>
>
> <to uri="{{email.protocol}}://{{email.host}}:{{email.port}}" />
>
> </route>
>
>
>
> When deployed to Fuse ESB the blueprint containing this route works fine. My problem comes when trying to mock the to endpoint in a unit test (which extends CamelBlueprintTestSupport).
>
>
>
> When I run my test I find that it's looking for a ComponentResolver for component={{email.protocol}}, which makes sense. Unfortunately this seems to be happening during the creation of the CamelContext so I can't mock it or replace it with a stub.
>
>
>
> I believe I could create a ComponentResolver to handle such a component, but I'd rather not. Is there a simpler solution?
>
>
>
> If you're wondering, I've got the component part of the endpoint as a property placeholder so we can easily configure smpt vs. smtps.
>
I think there is a method on CamelTestSupport =
useOverridePropertiesWithPropertiesComponent you can override and
return the properties to use for testing.
I guess we should document that on: http://camel.apache.org/camel-test.html.
>
> Thanks
>
> ________________________________
>
> This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying, disclosure or taking of any action in reliance upon it by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. Monitise accepts no liability if this email harms any systems or data of the recipient (including as a result of software virus infection or where this e-mail is modified or amended in any way during or following transmission) or if this email is accessed by anyone other than the person(s) to whom it is addressed.
>
> The Monitise group includes Monitise plc (Reg. No. 6011822), Monitise Group Limited (Reg. No. 5590897), Monitise International Limited (Reg. No. 5556711), Monitise Europe Limited (Reg. No. 4831976) and Mobile Money Network Limited (Reg. No. 7153130). These companies are registered in England and Wales and their registered office address is 95 Gresham Street, London, EC2V 7NA United Kingdom.
--
Claus Ibsen
-----------------
Red Hat, Inc.
FuseSource is now part of Red Hat
Email: cibsen@redhat.com
Web: http://fusesource.com
Twitter: davsclaus
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen