thanks a lot jason for looking into this. If I find some time I will see
if something else can be done to make this easier to work with.
cheers
On 03/26/2013 01:08 PM, Jason Pell wrote:
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
--
Oliver Moser
