You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "David Valeri (JIRA)" <ji...@apache.org> on 2010/07/30 15:53:16 UTC

[jira] Resolved: (CXF-2664) STSClient overloaded setPolicy causes issues with Spring based STS client configuration

     [ https://issues.apache.org/jira/browse/CXF-2664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Valeri resolved CXF-2664.
-------------------------------

    Resolution: Fixed

> STSClient overloaded setPolicy causes issues with Spring based 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, 2.2.10
>            Reporter: David Valeri
>            Assignee: David Valeri
>             Fix For: 2.3, 2.2.10
>
>
> 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.