The reason why the context-properties does not work, is I am relying on direct access to the Environment class available in spring 3.1 which has the resolvePlaceholders method. I am not relying on the normal bean post processor stuff that replaces properties.
The original bug was for 2.4, but I never tested this in 2.4, I only ever tried my solution using 2.7.x Sorry I could not be of more help as I agree it would have been nicer to be able to use the context:properties-placeholder stuff defined in the context, unfortunately I don't know a way to do this. On Tue, Mar 26, 2013 at 10:42 PM, Jason Pell <[email protected]> wrote: > I had a look at this and the context:property-placeholder results in > the registration of a PropertySourcesPlaceholderConfigurer bean, but > there is no straightforward resolvePlaceholders method here, so I > don't see a simple way out of pre-defining your properties in the > context initializer. > > > > On Tue, Mar 26, 2013 at 10:02 PM, Jason Pell <[email protected]> wrote: >> Hi, >> >> I see you are using a webapp so you can also use the Spring 3.1 >> context initialiser interface to add properties to the Environment. >> Registering them in the environment directly allows such things as >> imports to register values from properties files. I will still keep >> looking to see if I can update the http conduit configurer to use >> context:property-placeholder configuration, but it would at least >> clean up your code: >> >> http://blog.springsource.org/2011/02/15/spring-3-1-m1-unified-property-management/ >> >> <context-param> >> <param-name>contextInitializerClasses</param-name> >> <param-value>com.bank.MyInitializer</param-value> >> </context-param> >> >> public class MyInitializer implements >> ApplicationContextInitializer<ConfigurableWebApplicationContext> { >> public void initialize(ConfigurableWebApplicationContext ctx) { >> PropertySource ps = new MyPropertySource(); >> ctx.getEnvironment().getPropertySources().addFirst(ps); >> // perform any other initialization of the context ... >> } >> } >> >> >> On Tue, Mar 26, 2013 at 9:26 PM, Jason Pell <[email protected]> wrote: >>> Hi, >>> >>> When I get a chance I was planning to work out how to get this working >>> without using the environment stuff and using properties placeholder >>> configurer >>> >>> Sent from my Galaxy S2 >>> >>> On Mar 14, 2013 4:56 AM, "Oliver Moser" <[email protected]> wrote: >>>> >>>> Hi Dan >>>> >>>> On 2013-03-13 18:42, Daniel Kulp wrote: >>>>> >>>>> On Mar 13, 2013, at 10:07 AM, Oliver Moser <[email protected]> wrote: >>>>> >>>>>> Hi Glen >>>>>> >>>>>> On 2013-03-13 14:38, Glen Mazza wrote: >>>>>>> >>>>>>> I don't have an answer to your question, but to clarify, are you >>>>>>> saying that if you upgraded to the latest CXF 2.7.3 Jason's approach >>>>>>> would work for you? (Is doing such an upgrade an option for you if it >>>>>>> would?) >>>>>> >>>>>> I don't know if upgrading would make Jason's approach work for me, but >>>>>> somehow I assumed that his approach was intended for CXF 2.4 (jira says >>>>>> affected version 2.4.3) >>>>>> >>>>>> Anyways, I can give it a try an upgrade to CXF 2.7, but I'm not sure if >>>>>> that will help. >>>>>> >>>>>> Question for me that still remains is how to replace the default >>>>>> configurer, so that I can handle the property placeholders in my own >>>>>> implementation. >>>>> >>>>> >>>>> You can always do a: >>>>> >>>>> Configurer cfg = bus.getExtension(Configurer.class); >>>>> cfg = new MyCustomConfigurer(cfg); >>>>> bus.setExtension(cfg, Configurer.class); >>>>> >>>>> where MyCustomConfigurer wrappers the original and delegates to it >>>>> for anything you don't handle yourself (conduits). >>>> >>>> Thanks. >>>> >>>> On the other hand, I just finished upgrading to 2.7.3, and with this >>>> version, Jason's approach (the >>>> "PropertyPlaceholderResolvingConduitConfigurer") seems to work. Looks like >>>> some things changed in this regard from 2.6 to 2.7. >>>> >>>> However, I still have to explicitly add the Properties that holds the >>>> endpoints urls (${client1.url} in my sample below) using >>>> >>>> ((ConfigurableApplicationContext)context).getEnvironment(). >>>> getPropertySources().addFirst(new >>>> ResourcePropertySource(additionalProperties)); // <-- additionalProperties >>>> points to "/WEB-INF/backends-local.properties" >>>> >>>> in setApplicationContext() of the HTTPConduitConfigurer implementation. >>>> I'm not sure why the properties that I have configured using >>>> >>>> <context:property-placeholder >>>> location="/WEB-INF/backends-local.properties"/> >>>> >>>> are not available at the time the HTTPConduitConfigurer is initialized. >>>> Also played with depends-on, but that didn't do the trick. >>>> >>>> cheers >>>> >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> cheers >>>>>> >>>>>> Oliver >>>>>> >>>>>> >>>>>>> >>>>>>> Glen >>>>>>> >>>>>>> On 03/13/2013 06:32 AM, Oliver Moser wrote: >>>>>>>> >>>>>>>> Hi Glen >>>>>>>> >>>>>>>> On 2013-03-12 22:03, Glen Mazza wrote: >>>>>>>>> >>>>>>>>> Hmm. http-conf configuration is for a specific port, and it's >>>>>>>>> presently assumed that the properties for that port would be the same >>>>>>>>> regardless of the client connecting to it. Dan Kulp informed me on >>>>>>>>> IRC there's already a JIRA request to provide something quite similar >>>>>>>>> to what you're requesting >>>>>>>>> (https://issues.apache.org/jira/browse/CXF-4811). >>>>>>>> >>>>>>>> I had a look at the jira. However, the approach Jason posted does not >>>>>>>> work for me. >>>>>>>> >>>>>>>> I'm using cxf 2.6.1, and the PatternSyntaxException happens during >>>>>>>> initialization of the spring bus. >>>>>>>> >>>>>>>> setApplicationContext() in SpringBus.java also sets the various >>>>>>>> extensions, amongst them >>>>>>>> >>>>>>>> ... >>>>>>>> setExtension(new ConfigurerImpl(applicationContext), >>>>>>>> Configurer.class); >>>>>>>> ... >>>>>>>> >>>>>>>> ConfigurerImpl parses the bean definitions for wildcards (via >>>>>>>> initWildcardDefinitionMap()), and this is where the PatternException >>>>>>>> occurs. >>>>>>>> >>>>>>>> So, is there a way to replace the default configurer with a custom >>>>>>>> configurer that basically does what Jasons custom conduit configurer >>>>>>>> does? >>>>>>>> I.e. first replace property placeholders and run the pattern matcher >>>>>>>> on the >>>>>>>> resulting string? >>>>>>>> >>>>>>>> cheers >>>>>>>> >>>>>>>> Oliver >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> It would be messy, but if you configure two configuration files, one >>>>>>>>> for each client, each having a different http-conf configuration, and >>>>>>>>> reference them from the same Java class, that *might* work (unsure - >>>>>>>>> haven't tested it.) >>>>>>>>> >>>>>>>>> Glen >>>>>>>>> >>>>>>>>> On 03/12/2013 11:27 AM, Oliver Moser wrote: >>>>>>>>>> >>>>>>>>>> Hi >>>>>>>>>> >>>>>>>>>> I recently stumbled over a configuration issue with http conduits >>>>>>>>>> that i'm still not able to resolve. >>>>>>>>>> >>>>>>>>>> I have two jaxws:clients configured that have the same service class >>>>>>>>>> associated: >>>>>>>>>> >>>>>>>>>> <jaxws:client id="client1" >>>>>>>>>> serviceClass="a.b.c.PortType" >>>>>>>>>> address="${client1.url}" >>>>>>>>>> username="${client1.username}" >>>>>>>>>> password="${client1.password}"> >>>>>>>>>> </jaxws:client> >>>>>>>>>> >>>>>>>>>> <jaxws:client id="client2" >>>>>>>>>> serviceClass="a.b.c.PortType" >>>>>>>>>> address="${client2.url}" >>>>>>>>>> username="${client2.sysid}" >>>>>>>>>> password="${client2.password}"> >>>>>>>>>> </jaxws:client> >>>>>>>>>> >>>>>>>>>> How can I configure two seperate http-conf:conduits that have >>>>>>>>>> different settings for proxy, timeout etc.? I cannot reference it via >>>>>>>>>> "{http://acme.com/}PortType"; since they are the same for both >>>>>>>>>> clients, nor >>>>>>>>>> can I use wildcards. What would work is if I could use the property >>>>>>>>>> placeholders for the URLs, since the endpoints are different: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> <http-conf:conduit name="${client1.url}"> >>>>>>>>>> <http-conf:client ConnectionTimeout="10000" >>>>>>>>>> ReceiveTimeout="20000" >>>>>>>>>> ProxyServer="${proxy.host}" >>>>>>>>>> ProxyServerPort="${proxy.port}"/> >>>>>>>>>> </http-conf:conduit> >>>>>>>>>> >>>>>>>>>> <http-conf:conduit name="${client2.url}"> >>>>>>>>>> <http-conf:client ConnectionTimeout="30000" >>>>>>>>>> ReceiveTimeout="40000"/> >>>>>>>>>> </http-conf:conduit> >>>>>>>>>> >>>>>>>>>> However, a regex is expected in this case, and hence this try fails >>>>>>>>>> with a PatternSyntaxException. >>>>>>>>>> >>>>>>>>>> anyone got an idea on how to solve this? Maybe I miss something. >>>>>>>>>> >>>>>>>>>> cheers >>>>>>>>>> >>>>>>>> >>>>>> >>>>>> -- >>>>>> Oliver Moser >>>> >>>> >>>> -- >>>> Oliver Moser
