Spring jaxws:client no more resolves the ${property placeholder} references [SPR-15827]

Manish opened SPR-15827 and commented

This works with CXF 3.1.10 and Spring 4.1.6 but does not when I upgrade spring to 4.3.7 I also tried upgrading to Spring 4.3.10 but that does not help either.

I load the properties file as

above referenced file contains session.manager.service.uri=http://some.com/url

and I need to use that property in below jaxws:client section

BUT it never resolves the address and throws an error: Could not find conduit initiator for address: ${session.manager.service.uri:http://enter.valid.session.manager.service.uri/} and transport:

---

Affects: 4.3.7, 4.3.10

1 votes, 3 watchers

Comment From: spring-projects-issues

Juergen Hoeller commented

I'm not familiar with the jaxws namespace; that's an external extension. In any case, I'm surprised that there is a difference in placeholder resolution: Spring applies such resolution to any bean property value, so as long as the address attribute is being bound to a bean property underneath (which is very likely how the jaxws namespace handler is implemented), resolution should still work fine.

It'd be of great help if you could debug this a bit further. We can certainly fix this for 4.3.11 once we know the root cause of the regression.

Comment From: spring-projects-issues

Manish commented

The property resolution occurs at startup and its a soap client so the service class is actually an interface. Without knowing all the intricacies of spring bean factory and not knowing how to lazy load the "jaxws:client" so I can step through the debugger is making it hard for me to debug further. If you give me some pointers to follow I will try and help.

Comment From: spring-projects-issues

Juergen Hoeller commented

CXF's <jaxws:client> element seems to define a bean of type org.apache.cxf.jaxws.JaxWsProxyFactoryBean underneath. So you could set a breakpoint into JaxWsProxyFactoryBean.setAddress and see when that method is being invoked there: For some reason, it might be called too early, even before placeholder resolution has happened. It'd be great to see a stacktrace of that setAddress invocation...

Comment From: spring-projects-issues

Manish commented

Here you go. Interestingly in prior 4.1.6 version line 6 below used to be [6] org.springframework.beans.BeanWrapperImpl.setPropertyValue (BeanWrapperImp l.java:1,169)

[1] org.apache.cxf.frontend.ClientProxyFactoryBean.setAddress (ClientProxyFact oryBean.java:299) [2] sun.reflect.NativeMethodAccessorImpl.invoke0 (native method) [3] sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java :57) [4] sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorI mpl.java:43) [5] java.lang.reflect.Method.invoke (Method.java:606) [6] org.springframework.beans.BeanWrapperImpl$BeanPropertyHandler.setValue (Be anWrapperImpl.java:358) [7] org.springframework.beans.AbstractNestablePropertyAccessor.processLocalPro perty (AbstractNestablePropertyAccessor.java:469) [8] org.springframework.beans.AbstractNestablePropertyAccessor.setPropertyValu e (AbstractNestablePropertyAccessor.java:292) [9] org.springframework.beans.AbstractNestablePropertyAccessor.setPropertyValu e (AbstractNestablePropertyAccessor.java:280) [10] org.springframework.beans.AbstractPropertyAccessor.setPropertyValues (Abs tractPropertyAccessor.java:95) [11] org.springframework.beans.AbstractPropertyAccessor.setPropertyValues (Abs tractPropertyAccessor.java:75) [12] org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact ory.applyPropertyValues (AbstractAutowireCapableBeanFactory.java:1,564) [13] org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact ory.populateBean (AbstractAutowireCapableBeanFactory.java:1,276) [14] org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact ory.doCreateBean (AbstractAutowireCapableBeanFactory.java:553) [15] org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact ory.createBean (AbstractAutowireCapableBeanFactory.java:483) [16] org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject (AbstractBeanFactory.java:306) [17] org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.ge tSingleton (DefaultSingletonBeanRegistry.java:230) [18] org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean ( AbstractBeanFactory.java:302) [19] org.springframework.beans.factory.support.AbstractBeanFactory.getTypeForF actoryBean (AbstractBeanFactory.java:1,508) [20] org.springframework.beans.factory.support.AbstractAutowireCapableBeanFact ory.getTypeForFactoryBean (AbstractAutowireCapableBeanFactory.java:816) [21] org.springframework.beans.factory.support.AbstractBeanFactory.isTypeMatch (AbstractBeanFactory.java:558) [22] org.springframework.beans.factory.support.DefaultListableBeanFactory.doGe tBeanNamesForType (DefaultListableBeanFactory.java:432) [23] org.springframework.beans.factory.support.DefaultListableBeanFactory.getB eanNamesForType (DefaultListableBeanFactory.java:395) [24] org.springframework.beans.factory.support.DefaultListableBeanFactory.getB eansOfType (DefaultListableBeanFactory.java:515) [25] org.springframework.beans.factory.support.DefaultListableBeanFactory.getB eansOfType (DefaultListableBeanFactory.java:508) [26] voya.vcf.data.mybatis.MyBatisCustomConfiguration.postProcessBeanFactory ( MyBatisCustomConfiguration.java:27) [27] org.springframework.context.support.PostProcessorRegistrationDelegate.inv okeBeanFactoryPostProcessors (PostProcessorRegistrationDelegate.java:281) [28] org.springframework.context.support.PostProcessorRegistrationDelegate.inv okeBeanFactoryPostProcessors (PostProcessorRegistrationDelegate.java:176) [29] org.springframework.context.support.AbstractApplicationContext.invokeBean FactoryPostProcessors (AbstractApplicationContext.java:686) [30] org.springframework.context.support.AbstractApplicationContext.refresh (A bstractApplicationContext.java:524) [31] org.springframework.web.context.ContextLoader.configureAndRefreshWebAppli cationContext (ContextLoader.java:443) [32] org.springframework.web.context.ContextLoader.initWebApplicationContext ( ContextLoader.java:325) [33] org.springframework.web.context.ContextLoaderListener.contextInitialized (ContextLoaderListener.java:107) [34] org.apache.catalina.core.StandardContext.listenerStart (StandardContext.j ava:4,729) [35] org.apache.catalina.core.StandardContext.startInternal (StandardContext.j ava:5,167) [36] org.apache.catalina.util.LifecycleBase.start (LifecycleBase.java:150) [37] org.apache.catalina.core.ContainerBase.addChildInternal (ContainerBase.ja va:725) [38] org.apache.catalina.core.ContainerBase.addChild (ContainerBase.java:701) [39] org.apache.catalina.core.StandardHost.addChild (StandardHost.java:717) [40] org.apache.catalina.startup.HostConfig.deployDirectory (HostConfig.java:1 ,101) [41] org.apache.catalina.startup.HostConfig$DeployDirectory.run (HostConfig.ja va:1,786) [42] java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:471) [43] java.util.concurrent.FutureTask.run (FutureTask.java:262) [44] java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.jav a:1,145) [45] java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.ja va:615) [46] java.lang.Thread.run (Thread.java:745)

Comment From: spring-projects-issues

Juergen Hoeller commented

What does voya.vcf.data.mybatis.MyBatisCustomConfiguration do? This seems to be a BeanFactoryPostProcessor implementation calling getBeansOfType without early-init-avoiding false flags. Not sure why this would have worked before but this is certainly brittle; in a post-processor implementation, access to other beans and in particular type matching against other beans needs to be done very defensively...

Comment From: spring-projects-issues

Manish commented

first of all sorry for late response as I was away on vacation.

MyBatisCustomConfiguration class gets all myBatis SqlSessionFactory beans in an attempt to set a standard timeout on all of them. see below note from the javadoc that this method allows eager init.

This version of getBeansOfType matches all kinds of beans, be it singletons, prototypes, or FactoryBeans. In most implementations, the result will be the same as for getBeansOfType(type, true, true).

are you suggesting not allowing eager init would resolve this issue?

Comment From: spring-projects-issues

Juergen Hoeller commented

Indeed, I expect a defensive getBeansOfType call without eager-init allowance to resolve this issue. Such early calls in a BPP implementation are always brittle, and the only clean way out is to explicitly suppress eager initialization for type matching purposes there.

Comment From: spring-projects-issues

Roman commented

The same issue with @SpyBean/@MockBean annotations due to getBeanNamesForType() in MockitoPostProcessor.getExistingBeans

Comment From: akuma8

I have the same issue with Spring 4.3.18.RELEASE, where property defined here:

<jaxws:client id="ClientOne"
        serviceClass="com.app.soap.Service"
        address="${client.one.address}">   <!--This is not resolved --> 
       <jaxws:handlers>
           <ref bean="loggingSoapClientHandler"/>
       </jaxws:handlers>
 </jaxws:client>

My workaround was to define a bean containing all addresses and use it with SpEL.

<jaxws:client id="ClientOne"
        serviceClass="com.app.soap.Service"
        address="#{jaxWsAdresses.clientOneAddress}">   
       <jaxws:handlers>
           <ref bean="loggingSoapClientHandler"/>
       </jaxws:handlers>
 </jaxws:client>

Comment From: snicoll

I am going to close this as the resolution happens outside of the core framework and we've provided some pointers already. I'd suggest to report that against CXF if that's still applicable. Alternatively, if we get a small sample that we can run ourselves to reproduce the problem we can have another go at it.