You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Antonin Stefanutti (JIRA)" <ji...@apache.org> on 2016/01/28 19:08:39 UTC
[jira] [Assigned] (CAMEL-5986) Property placeholders do not work
for CDI injection
[ https://issues.apache.org/jira/browse/CAMEL-5986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonin Stefanutti reassigned CAMEL-5986:
-----------------------------------------
Assignee: Antonin Stefanutti
> Property placeholders do not work for CDI injection
> ---------------------------------------------------
>
> Key: CAMEL-5986
> URL: https://issues.apache.org/jira/browse/CAMEL-5986
> Project: Camel
> Issue Type: Improvement
> Components: camel-cdi
> Affects Versions: 2.11.1
> Reporter: Karim de Fombelle
> Assignee: Antonin Stefanutti
> Fix For: 2.17.0
>
> Attachments: apache-deltaspike.properties, stacktrace.txt
>
>
> Camel-CDI offers a mechanism to resolve property placeholders like {{{{property1}}}} in an endpoint URI as described in camel [documentation|http://camel.apache.org/using-propertyplaceholder.html]
> These placeholders could come from ConfigSource loaded via the deltaspike configuration CDI extension and its ConfigResolver class according comments on class _org.apache.camel.cdi.component.properties.CdiPropertiesParser_
> Anyway this choice is surprising because the documentation of the _org.apache.deltaspike.core.api.config.PropertyFileConfig_ specifies the following:
> {code}
> * <p>Please note that the configuration will only be available
> * after the boot is finished. This means that you cannot use
> * this configuration inside a CDI Extension before the boot
> * is finished!</p>
> {code}
> camel-cdi maven module contains a test class _org.apache.camel.cdi.component.properties.PropertiesComponentTest_ which IMHO does not illustrate the real use we would need in a CDI container.
> It shows placeholders replaced after the boot of the CDI container, which is inline with the javadoc above but probably not really useful.
> {code}
> context.resolvePropertyPlaceholders("{{directEndpoint}}_{{directEndpoint}}");
> {code}
> But from my standpoint the real benefit would be to use such a feature as follows:
> {code}
> @RunWith(Arquillian.class)
> @ApplicationScoped
> public class CamelCdiCamel5986Test {
> @Inject
> @Mock("mock:{{property1}}")
> private MockEndpoint mockEndpoint;
> @Deployment
> public static Archive<?> createDeployment() {
> JavaArchive jar = ShrinkWrap.create(JavaArchive.class)
> .addClass(TestRouteBuilder.class)
> .addClass(CdiConfigFile.class)
> .addAsResource("META-INF/camel.properties")//according CdiConfigFile
> .addPackages(true, ConfigurationExtension.class.getPackage())
> .addPackages(true, CdiCamelContext.class.getPackage())
> .addAsManifestResource(EmptyAsset.INSTANCE, "beans.xml");
> return jar;
> }
> //test crashes with a org.jboss.weld.exceptions.DeploymentException (...) Could not add Routes: [Route[[From[direct:begin]] -> [To[mock:{{property1}}]]]]
> @Test
> public void testConfiguration() {
> assertNotNull("mockEndpoint is null", mockEndpoint);
> }
> @ContextName
> public static class TestRouteBuilder extends RouteBuilder {
> @Override
> public void configure() throws Exception {
> from("direct:begin").to("mock:{{property1}}");
> }
> }
> /**
> * Copy of class from camel-cdi test class org.apache.camel.cdi.support.CdiConfigFile
> */
> public static class CdiConfigFile implements PropertyFileConfig {
> private static final long serialVersionUID = 1L;
> @Override
> public String getPropertyFileName() {
> return "META-INF/camel.properties";
> }
> }
> }
> {code}
> But the test crashes failing to resolve the placeholder {{{{property1}}}} with the complete stack stack attached.
> Obviously I have a camel.properties file in my classpath, but it is ignored.
> Just adding the attached META-INF/apache-deltaspike.properties file in the classpath makes the test green.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)