XFire 1.2.6 not compatible with Spring 3.0's CustomEditorConfigurer [SPR-6157]

[spring-projects-issues]

Manuel Jordan opened SPR-6157 and commented

A code for XFire working with Spring 2.5.6 works fine, with the follow jars

activation-1.1.jar
commons-logging-1.0.4.jar
jdom-1.0.jar
spring.jar <---
spring-webmvc.jar <---
stax-api-1.0.1.jar
wsdl4j-1.6.1.jar
wstx-asl-3.2.0.jar
xfire-all-1.2.6.jar

With the follows jars

com.springsource.org.antlr-3.0.1.jar
org.springframework.asm-3.0.0.M3.jar
org.springframework.beans-3.0.0.M3.jar
org.springframework.context-3.0.0.M3.jar
org.springframework.core-3.0.0.M3.jar
org.springframework.expression-3.0.0.M3.jar
org.springframework.web-3.0.0.M3.jar
org.springframework.web.servlet-3.0.0.M3.jar
xfire-all-1.2.6.jar

Even If I include the missing jars from the first list in this configuration
When tomcat 6.0.20 is started, I receive instead this error

21/09/2009 12:30:10 PM org.springframework.web.context.ContextLoader initWebApplicationContext
GRAVE: Context initialization failed
org.springframework.beans.factory.BeanCreationExce ption: Error creating bean with name
'xfire.customEditorConfigurer' defined in class path resource
[org/codehaus/xfire/spring/customEditors.xml]: Initialization of bean failed;
nested exception is org.springframework.beans.TypeMismatchException:
Failed to convert property value of type
[java.util.LinkedHashMap] to required type [java.util.Map] forproperty 'customEditors';
nested exception is java.lang.IllegalArgumentException:
Cannot convert value of type [org.codehaus.xfire.spring.editors.ServiceFactoryEd itor]
to required type [java.lang.String] for property 'customEditors[org.codehaus.xfire.service.ServiceFactory]':
no matching editors or conversion strategyfound
at org.springframework.beans.factory.support.Abstract AutowireCapableBeanFactory.doCreateBean(AbstractAu towireCapableBeanFactory.java:483)
.....
Caused by: org.springframework.beans.TypeMismatchException:
Failed to convert property value of type [java.util.LinkedHashMap] to required type [java.util.Map]
for property 'customEditors'; nested exception is java.lang.IllegalArgumentException:
Cannot convert value of type [org.codehaus.xfire.spring.editors.ServiceFactoryEd itor]
to required type [java.lang.String] for property 'customEditors[org.codehaus.xfire.service.ServiceFactory]':
no matching editors or conversion strategy found
at org.springframework.beans.BeanWrapperImpl.convertF orProperty(BeanWrapperImpl.java:383)
.....

Caused by: java.lang.IllegalArgumentException:
Cannot convert value of type [org.codehaus.xfire.spring.editors.ServiceFactoryEd itor] to required type
[java.lang.String] for property 'customEditors[org.codehaus.xfire.service.ServiceFactory]'
: no matching editors or conversion strategy found
at org.springframework.beans.TypeConverterDelegate.co nvertIfNecessary(TypeConverterDelegate.java:226)

---

Affects: 3.0 M3

Reference URL: http://forum.springsource.org/showthread.php?t=77998

Issue Links:

• XFire 1.2.6 not compatible with Spring 4.0's CustomEditorConfigurer [SPR-14262] #18834 XFire 1.2.6 not compatible with Spring 4.0's CustomEditorConfigurer
• CustomEditorConfigurer functionality regression in 3.0 [SPR-5971] #10639 CustomEditorConfigurer functionality regression in 3.0
• CustomEditorConfigurer needs way to register Property Editor instances [SPR-5860] #10529 CustomEditorConfigurer needs way to register Property Editor instances
• CustomEditorConfigurer compatibility breakage in 3.0 [SPR-5773] #10443 CustomEditorConfigurer compatibility breakage in 3.0

Referenced from: commits b152ac3

[spring-projects-issues]

Juergen Hoeller commented

This is caused by the removal of a deprecated feature - passing in shared PropertyEditor instances into a BeanFactory - from Spring's CustomEditorConfigurer component, which XFire seems to be using under the hood there. We do understand the need for backwards compatibility with third-party libraries, so we reintroduced support for this deprecated feature in Spring 3.0 RC2. However, a deprecation warning will be written to the log; XFire should stop using this deprecated feature at some point. This has been deprecated since Spring 2.0.7, after all.

Juergen