[
https://issues.apache.org/jira/browse/CXF-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Valeri reassigned CXF-2664:
---------------------------------
Assignee: David Valeri
> STSClient overloaded setPolicy causes issues with Spring based configuration
> STS client configuration
> -----------------------------------------------------------------------------------------------------
>
> Key: CXF-2664
> URL: https://issues.apache.org/jira/browse/CXF-2664
> Project: CXF
> Issue Type: Improvement
> Components: WS-* Components
> Affects Versions: 2.3
> Reporter: David Valeri
> Assignee: David Valeri
>
> When attempting to configure an STSClient using an abstract Spring bean and
> the CXF Configurable framework, one cannot set the policy field of the
> STSClient reliably. Spring uses built-in Java capabilities to resolve the
> fields of a bean and the setters/getters for that field. If a setter is
> overloaded, there is no guarantee that Spring will resolve the same setter
> across multiple JVMs or even in the same JVM with slightly different
> environments. This issue was observed when running from a JUnit test case in
> Eclipse and running in a JUnit test case from a command line Maven build.
> As it is trivial for an end user to create a Neethi Policy object graph from
> a DOM structure both in Spring and in code, the setter that takes a DOM
> element is less useful to the end user.
> The Spring config for performing the transformation manually is as follows:
> [code]
> ...
> <bean name="policyBuilder" factory-bean="cxf" factory-method="getExtension">
> <constructor-arg value="org.apache.cxf.ws.policy.PolicyBuilder"/>
> </bean>
> <bean factory-bean="policyBuilder" factory-method="getPolicy">
> <constructor-arg>
> <!-- Use a PropertyPathFactoryBean to extract the DOM from the
> PolicyBean
> that the embedded WS-P XML is turned into. -->
> <bean
> class="org.springframework.beans.factory.config.PropertyPathFactoryBean">
> <property name="targetObject">
> <wsp:Policy
> xmlns:wsp="http://www.w3.org/2006/07/ws-policy";>
> ...
> </wsp:Policy>
> </property>
> <property name="propertyPath" value="element"/>
> </bean>
> </constructor-arg>
> </bean>
> ...
> [code]
> As this is a minimal amount of configuration, it does not heavily impact
> users.
> The setter taking a DOM element could be removed or ease of use could be
> maintained by expanding the scope of a single setter to take an Object and
> then invoke any number of internal setters based on the object type.
> Alternatively, a number of setPolicyAsXXX methods could be used to accomplish
> the same ends. Obviously, binary compatibility with previous versions should
> be considered when making these changes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
