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
