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
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.
