cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Valeri (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CXF-2664) STSClient overloaded setPolicy causes issues with Spring based STS client configuration
Date Tue, 27 Jul 2010 19:36:16 GMT

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

David Valeri updated CXF-2664:
------------------------------

    Summary: STSClient overloaded setPolicy causes issues with Spring based STS client configuration
 (was: STSClient overloaded setPolicy causes issues with Spring based configuration STS client
configuration)

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


Mime
View raw message