You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Ephemeris Lappis <ep...@gmail.com> on 2016/02/18 12:30:57 UTC
cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Hello.
I've a unit test class based on CamelBlueprintTestSupport that works as
expected except if I let a "cxf:bean" route with a configuration property.
The properties are loaded from a CFG file on the
"loadConfigAdminConfigurationFile" call. They are all resolved as expected
on any of all the routes components, exept with cxf:bean.
The route endpoint is :
**
And the following exception is thrown :
**
In fact, the CXF route is not actually tested at this time (just the
transformation, services call and processing routes are), and the class
fails because of it.
Any idea ?
Thanks for your help.
Regards.
--
View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with
CamelBlueprintTestSupport
Posted by Ephemeris Lappis <ep...@gmail.com>.
Hello.
I've done more tests, and I have two comments.
1) The error also occurs on other endpoint type. for example, if I use the
same property on a direct option, the route construction fails with the same
exception. This means that this is not a CXF specific problem...
2) I've seen a message in the console after the exception occurs that lets
think that the CamelBlueprintTestSupport has not completed the
initializations when the Camel context construction begins. Here is the
message :
**
That shows that the properties values are loaded from the configuration file
by the overridden "loadConfigAdminConfigurationFile".
The method "useOverridePropertiesWithConfigAdmin" is not overridden in my
tests, since the configuration is already set.
I don't understand why this method is called after the Camel context
construction starts...
Thanks for your help.
Regards.
--
View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777897.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Sorry - my mistake. I normally use the Java DSL and then wire it up with blueprint - then I can use the Blueprint property placeholders.
You could use a Java RouteBuilder something like this
public class MyRouteBuilder extends RouteBuilder {
boolean loggingFeatureEnabled = false;
@Override
public void configure() throws Exception {
fromF( "cxf//:bean:my.ws?dataFormat=PAYLOAD&loggingFeatureEnabled=%b", loggingFeatureEnabled)
.to( "mock://result");
}
public void setLoggingFeatureEnabled(boolean loggingFeatureEnabled) {
this.loggingFeatureEnabled = loggingFeatureEnabled;
}
}
and then create the bean in your blueprint and set the property with the Blueprint property placeholder
<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:cm="http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0"
xsi:schemaLocation="
http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://camel.apache.org/schema/blueprint http://camel.apache.org/schema/blueprint/camel-blueprint.xsd">
<cm:property-placeholder persistent-id="cxf-props" update-strategy="reload" >
<cm:default-properties>
<cm:property name="loggingFeatureEnabled" value="true" />
</cm:default-properties>
</cm:property-placeholder>
<bean id="java-route" class="com.pronoia.camel.builder.MyRouteBuilder" >
<property name="loggingFeatureEnabled" value="${loggingFeatureEnabled}" />
</bean>
<camelContext id="blueprint-context" xmlns="http://camel.apache.org/schema/blueprint">
<routeBuilder ref="java-route" />
</camelContext>
</blueprint>
> On Feb 18, 2016, at 10:59 AM, Ephemeris Lappis <ep...@gmail.com> wrote:
>
> Hello.
>
> Thanks for this last answer : I was just about to try the proposed solution,
> despite my doubts about Camel/Blueprint properties resolution...
>
> But I'm still with my problem...
>
> Another idea ?
>
> Tanks again.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777871.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with
CamelBlueprintTestSupport
Posted by Ephemeris Lappis <ep...@gmail.com>.
I don't understand why the OSGi configuration properties are resolved as
expected in this CXF route when deploying the bundle on ServiceMix, and are
not when testing it with the CamelBlueprintTestSupport.
In the same blueprint, I've other properties used in other Camel components
that are resolved in both cases. In the following example, the logger name
doesn't produce an error :
**
If I have understood well, when the CamelContext is set inside a blueprint
that comes with an OSGi property place holder, which is my case, no explicit
Camel place holder is needed. This is the way we've built many bundles for
many years with Camel and ServiceMix.
The OSGi configuration is declared with the associated persistence ID like
that :
**
And, this way, Camel properties are resolved whatever way we call them :
{{name}} in the blueprint, or in Simple or Groovy scripts too, using the
respective syntax.
So, I don't understand why the property in the CXF:BEAN endpoint's URI leads
to an exception, and only in the unit test.
Maybe something fails in the endpoint construction, perhaps because of some
missing package in the unit test path that is not logged in the console, and
produces a side effect ?
--
View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777886.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Brad Johnson <br...@mediadriver.com>.
I don't know if you use features files for deployment but that's a good way
to deploy the cfg files.
On Mon, Feb 22, 2016 at 12:52 PM, Ephemeris Lappis <
ephemeris.lappis@gmail.com> wrote:
> Hello.
>
> As the default properties in the Blueprint placeholder seems to be a good
> workaround, waiting the 2.16.2 fixed version on ServiceMix, we will set
> them
> for our bundles. In fact, it's also a good way to document the properties
> that the bundle expects, and an easy way to test it without strange CBTS
> overridden operation. This is specially useful for automated tests during
> the CI build where all parameters must be set.
>
> Thanks for this advice.
>
> For deployment, configuration files remain the best way to handle
> differences between environments, specially when using devops style
> continuous deployment, and configuration version management. In this case,
> as you say, CFG files may just override the needed properties...
>
> Thanks for your help.
>
> Regards.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5778076.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: cxf:bean doesn't resolve properties with
CamelBlueprintTestSupport
Posted by Ephemeris Lappis <ep...@gmail.com>.
Hello.
As the default properties in the Blueprint placeholder seems to be a good
workaround, waiting the 2.16.2 fixed version on ServiceMix, we will set them
for our bundles. In fact, it's also a good way to document the properties
that the bundle expects, and an easy way to test it without strange CBTS
overridden operation. This is specially useful for automated tests during
the CI build where all parameters must be set.
Thanks for this advice.
For deployment, configuration files remain the best way to handle
differences between environments, specially when using devops style
continuous deployment, and configuration version management. In this case,
as you say, CFG files may just override the needed properties...
Thanks for your help.
Regards.
--
View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5778076.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Brad Johnson <br...@mediadriver.com>.
I have stopped using the config admin files with the CBTS altogether as I
found them problematic and the reloads can cause their own problems.
That's unfortunate because I use cfg files at deployment time.
Brad
On Sat, Feb 20, 2016 at 2:37 PM, Quinn Stevenson <
quinn@pronoia-solutions.com> wrote:
> I think it’s the startup order. I think the
> loadConfigAdminConfigurationFile() method was intended to override existing
> properties - not provide the initial values. When there aren’t any
> property keys at all in the context, the initial creation fails before the
> overrides can take effect (by a bundle reload).
>
> I’m guessing a little here because I’ve always provided defaults for
> these, and then I override them (either in a test or in a real environment)
> only when I need to. Providing sensible defaults for my production stuff
> in there greatly reduces the number of PID/cfg files I need to maintain - I
> only have to drop them in production when something changes and I need to
> react quickly (i.e. before I can repackage the bundle with the new default
> values). Eventually, I will replace the defaults and get rid of the
> PID/cfg in production.
>
> BTW - I normally use the useOverridePropertiesWithConfigAdmin() instead of
> the loadConfigAdminConfigurationFile() method because I like to keep the
> property values I’m changing for the test in the test class itself rather
> than in a file somewhere. Personal preference - just another option.
>
> Hopefully someone with a greater knowledge of the inner workings of
> CamelBlueprintTestSupport will correct me if I’m off-base on this one.
>
> > On Feb 20, 2016, at 11:02 AM, Ephemeris Lappis <
> ephemeris.lappis@gmail.com> wrote:
> >
> > Hello.
> > I've done the test with default values, and, surprising, it works !
> > Somebody could explain why ?
> > Whatever reason, good news : this lets us test our blueprints with Camel
> > 2.16.1 which is the version that comes with our ServiceMix.
> > Thanks a lot !
> > Regards.
> >
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777989.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I think it’s the startup order. I think the loadConfigAdminConfigurationFile() method was intended to override existing properties - not provide the initial values. When there aren’t any property keys at all in the context, the initial creation fails before the overrides can take effect (by a bundle reload).
I’m guessing a little here because I’ve always provided defaults for these, and then I override them (either in a test or in a real environment) only when I need to. Providing sensible defaults for my production stuff in there greatly reduces the number of PID/cfg files I need to maintain - I only have to drop them in production when something changes and I need to react quickly (i.e. before I can repackage the bundle with the new default values). Eventually, I will replace the defaults and get rid of the PID/cfg in production.
BTW - I normally use the useOverridePropertiesWithConfigAdmin() instead of the loadConfigAdminConfigurationFile() method because I like to keep the property values I’m changing for the test in the test class itself rather than in a file somewhere. Personal preference - just another option.
Hopefully someone with a greater knowledge of the inner workings of CamelBlueprintTestSupport will correct me if I’m off-base on this one.
> On Feb 20, 2016, at 11:02 AM, Ephemeris Lappis <ep...@gmail.com> wrote:
>
> Hello.
> I've done the test with default values, and, surprising, it works !
> Somebody could explain why ?
> Whatever reason, good news : this lets us test our blueprints with Camel
> 2.16.1 which is the version that comes with our ServiceMix.
> Thanks a lot !
> Regards.
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777989.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with
CamelBlueprintTestSupport
Posted by Ephemeris Lappis <ep...@gmail.com>.
Hello.
I've done the test with default values, and, surprising, it works !
Somebody could explain why ?
Whatever reason, good news : this lets us test our blueprints with Camel
2.16.1 which is the version that comes with our ServiceMix.
Thanks a lot !
Regards.
--
View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777989.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
OK - One other thing on this.
If you add some default properties elements in your blueprint, you’re test works as written as well
<cm:property-placeholder
persistent-id="my.camel.bp"
update-strategy="reload">
<cm:default-properties>
<cm:property name="my.label" value="" />
<cm:property name="my.logger" value="" />
<cm:property name="my.flag" value="" />
<cm:property name="my.path" value="" />
</cm:default-properties>
</cm:property-placeholder>
> On Feb 19, 2016, at 3:57 PM, Ephemeris Lappis <ep...@gmail.com> wrote:
>
> Hello.
> Indeed, it seems to work with Camel 2.16.2. As I've explained in my previous
> reply, I've refactored the blueprints to extract in separated files the
> roots that have unresolved properties. This will allow us to test all the
> important blueprints with the targeted version of Camel.
> An explanation of what has been fixed about Camel life cycle with the 2.16.2
> should be welcome...
> Thanks to all.
> Regards.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777956.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with
CamelBlueprintTestSupport
Posted by Ephemeris Lappis <ep...@gmail.com>.
Hello.
Indeed, it seems to work with Camel 2.16.2. As I've explained in my previous
reply, I've refactored the blueprints to extract in separated files the
roots that have unresolved properties. This will allow us to test all the
important blueprints with the targeted version of Camel.
An explanation of what has been fixed about Camel life cycle with the 2.16.2
should be welcome...
Thanks to all.
Regards.
--
View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777956.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
Looks like something was fixed in 2.16.2 - I tried your sample and if I change the Camel version to 2.16.2, your test passes.
> On Feb 19, 2016, at 4:28 AM, Ephemeris Lappis <ep...@gmail.com> wrote:
>
> Hello again.
>
> I've build a simple project with simple routes to test the property
> restitution (the ZIP is attached). The blueprint and its configuration file
> work as expected deployed on my ServiceMix 6.1.0 that comes with Camel
> 2.16.1 as my unit tests.
>
> The file "error-2_16_1.txt" is a copy of the console when the unit test is
> running with Camel 2.16.1.
>
> The file "error-2_14_0.txt" is the exception that is thrown by JUnit with
> Camel 2.14.0, that seems to work worst for property resolution : properties
> that are found inside Camel routes like te logger name with 2.16.1 are not
> with the 2.14.0.
>
> I hope this can help you to find an idea...
>
> Thanks again.
>
> Regards.
>
> error-2_16_1.txt
> <http://camel.465427.n5.nabble.com/file/n5777913/error-2_16_1.txt>
> error-2_14_0.txt
> <http://camel.465427.n5.nabble.com/file/n5777913/error-2_14_0.txt>
> camel-bp-test.zip
> <http://camel.465427.n5.nabble.com/file/n5777913/camel-bp-test.zip>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777913.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Brad Johnson <br...@mediadriver.com>.
I just use one full copy of properties for tests and another that I include
in the bundle. If you don't put a camel context in the porperties then you
don't end up with multiple contexts and OSGi/karaf automatically pick up
all the blueprint files it finds in your OSGI-INF blueprint folders. So I
usually have a blueprint.xml that has the camel context and another one
with blueprint-properties.xml that only defines properties values but
doesn't have a camel context. The third test-blueprint-propertie.xml I
keep in src/test/resources and when I run CBTS I just do this:
private static final String TEST_BLUEPRINT_XML =
"test-blueprint-properties.xml,OSGI-INF/blueprint/blueprint.xml";
@Override
protected String getBlueprintDescriptor() {
return TEST_BLUEPRINT_XML;
}
On Fri, Feb 19, 2016 at 4:48 PM, Ephemeris Lappis <
ephemeris.lappis@gmail.com> wrote:
> Hello.
>
> Happy to see I'm not the only one getting such a problem !
>
> I've also modified the blueprints to put the entry routes that are
> configured with these problematical properties in a separted file that
> needs
> no real unit tests, and all the routes that are to be actually tested in
> other blueprints. As this leads to create multiple Camel contexts, routing
> is done with "vm" instead of "direct" from the head blueprint to others...
>
> Thanks for your feedback.
>
> Regards.
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777955.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: cxf:bean doesn't resolve properties with
CamelBlueprintTestSupport
Posted by Ephemeris Lappis <ep...@gmail.com>.
Hello.
Happy to see I'm not the only one getting such a problem !
I've also modified the blueprints to put the entry routes that are
configured with these problematical properties in a separted file that needs
no real unit tests, and all the routes that are to be actually tested in
other blueprints. As this leads to create multiple Camel contexts, routing
is done with "vm" instead of "direct" from the head blueprint to others...
Thanks for your feedback.
Regards.
--
View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777955.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Brad Johnson <br...@mediadriver.com>.
I've always had problems with using cfg files in CBTS and don't know
exactly why. I think it may be a loading life cycle issue. For example,
in using CXF I'll commonly specify the service class in the configuration
file. What I'v resorted to doing is using multiple blueprint files.
Blueprint for blueprint-properties.xml that has nothing but the property
definition block with PID and defaults, the camel-blueprint.xml that shows
sets up the camel context, etc. At test time I'll point to the
src/test/resources/test-blueprint-properties.xml instead of the
blueprint.xml and it works fine.
On Fri, Feb 19, 2016 at 5:28 AM, Ephemeris Lappis <
ephemeris.lappis@gmail.com> wrote:
> Hello again.
>
> I've build a simple project with simple routes to test the property
> restitution (the ZIP is attached). The blueprint and its configuration file
> work as expected deployed on my ServiceMix 6.1.0 that comes with Camel
> 2.16.1 as my unit tests.
>
> The file "error-2_16_1.txt" is a copy of the console when the unit test is
> running with Camel 2.16.1.
>
> The file "error-2_14_0.txt" is the exception that is thrown by JUnit with
> Camel 2.14.0, that seems to work worst for property resolution : properties
> that are found inside Camel routes like te logger name with 2.16.1 are not
> with the 2.14.0.
>
> I hope this can help you to find an idea...
>
> Thanks again.
>
> Regards.
>
> error-2_16_1.txt
> <http://camel.465427.n5.nabble.com/file/n5777913/error-2_16_1.txt>
> error-2_14_0.txt
> <http://camel.465427.n5.nabble.com/file/n5777913/error-2_14_0.txt>
> camel-bp-test.zip
> <http://camel.465427.n5.nabble.com/file/n5777913/camel-bp-test.zip>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777913.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: cxf:bean doesn't resolve properties with
CamelBlueprintTestSupport
Posted by Ephemeris Lappis <ep...@gmail.com>.
Hello again.
I've build a simple project with simple routes to test the property
restitution (the ZIP is attached). The blueprint and its configuration file
work as expected deployed on my ServiceMix 6.1.0 that comes with Camel
2.16.1 as my unit tests.
The file "error-2_16_1.txt" is a copy of the console when the unit test is
running with Camel 2.16.1.
The file "error-2_14_0.txt" is the exception that is thrown by JUnit with
Camel 2.14.0, that seems to work worst for property resolution : properties
that are found inside Camel routes like te logger name with 2.16.1 are not
with the 2.14.0.
I hope this can help you to find an idea...
Thanks again.
Regards.
error-2_16_1.txt
<http://camel.465427.n5.nabble.com/file/n5777913/error-2_16_1.txt>
error-2_14_0.txt
<http://camel.465427.n5.nabble.com/file/n5777913/error-2_14_0.txt>
camel-bp-test.zip
<http://camel.465427.n5.nabble.com/file/n5777913/camel-bp-test.zip>
--
View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777913.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Claus Ibsen <cl...@gmail.com>.
You need to use CAmel's property placeholder, not some CXF stuff if
you mean they are loaded by CXF.
http://camel.apache.org/using-propertyplaceholder.html
On Thu, Feb 18, 2016 at 6:59 PM, Ephemeris Lappis
<ep...@gmail.com> wrote:
> Hello.
>
> Thanks for this last answer : I was just about to try the proposed solution,
> despite my doubts about Camel/Blueprint properties resolution...
>
> But I'm still with my problem...
>
> Another idea ?
>
> Tanks again.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777871.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: cxf:bean doesn't resolve properties with
CamelBlueprintTestSupport
Posted by Ephemeris Lappis <ep...@gmail.com>.
Hello.
Thanks for this last answer : I was just about to try the proposed solution,
despite my doubts about Camel/Blueprint properties resolution...
But I'm still with my problem...
Another idea ?
Tanks again.
--
View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834p5777871.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Claus Ibsen <cl...@gmail.com>.
On Thu, Feb 18, 2016 at 4:41 PM, Quinn Stevenson
<qu...@pronoia-solutions.com> wrote:
> I don’t know if this fits your use case, but you could let Blueprint do the substitution instead of camel.
>
> <from uri=“cxf://bean:my.ws?…...loggingFeatureEnabled=${fv.soap.tracing}” />
>
That shouldn't be possible as blueprint ${ } placeholders only work in
<bean> and whatnot. What's inside the <camelContext> is controlled by
the Camel namespace parser, and it uses Camel's property placeholder
which uses {{ }} style by default.
>
>> On Feb 18, 2016, at 4:30 AM, Ephemeris Lappis <ep...@gmail.com> wrote:
>>
>> Hello.
>>
>> I've a unit test class based on CamelBlueprintTestSupport that works as
>> expected except if I let a "cxf:bean" route with a configuration property.
>>
>> The properties are loaded from a CFG file on the
>> "loadConfigAdminConfigurationFile" call. They are all resolved as expected
>> on any of all the routes components, exept with cxf:bean.
>>
>> The route endpoint is :
>> **
>>
>> And the following exception is thrown :
>> **
>>
>> In fact, the CXF route is not actually tested at this time (just the
>> transformation, services call and processing routes are), and the class
>> fails because of it.
>>
>> Any idea ?
>>
>> Thanks for your help.
>>
>> Regards.
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: cxf:bean doesn't resolve properties with CamelBlueprintTestSupport
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
I don’t know if this fits your use case, but you could let Blueprint do the substitution instead of camel.
<from uri=“cxf://bean:my.ws?…...loggingFeatureEnabled=${fv.soap.tracing}” />
> On Feb 18, 2016, at 4:30 AM, Ephemeris Lappis <ep...@gmail.com> wrote:
>
> Hello.
>
> I've a unit test class based on CamelBlueprintTestSupport that works as
> expected except if I let a "cxf:bean" route with a configuration property.
>
> The properties are loaded from a CFG file on the
> "loadConfigAdminConfigurationFile" call. They are all resolved as expected
> on any of all the routes components, exept with cxf:bean.
>
> The route endpoint is :
> **
>
> And the following exception is thrown :
> **
>
> In fact, the CXF route is not actually tested at this time (just the
> transformation, services call and processing routes are), and the class
> fails because of it.
>
> Any idea ?
>
> Thanks for your help.
>
> Regards.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/cxf-bean-doesn-t-resolve-properties-with-CamelBlueprintTestSupport-tp5777834.html
> Sent from the Camel - Users mailing list archive at Nabble.com.