Overloaded setters break Spring XML usage

[RahulPrabha]

Setting the initVersion property for the xml bean definition of Flyway causes a org.springframework.beans.ConversionNotSupportedException on app start.

Here's what my config looks like:

This config used to work in v2.3 but now breaks after upgrading to 3.0

Everything works fine if I remove the setting of initVersion. Setting initVersion in java, using flyway.setInitVersion("1") for example, also works fine.

Here's the stack trace:

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flyway' defined in class path resource [spring/databaseMigrations.xml]: Initialization of bean failed; nested exception is org.springframework.beans.ConversionNotSupportedException: Failed to convert property value of type 'java.lang.String' to required type 'org.flywaydb.core.api.MigrationVersion' for property 'initVersion'; nested exception is java.lang.IllegalStateException: Cannot convert value of type [java.lang.String] to required type [org.flywaydb.core.api.MigrationVersion] for property 'initVersion': no matching editors or conversion strategy found
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:529)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:912)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.doResolveDependency(DefaultListableBeanFactory.java:855)
at org.springframework.beans.factory.support.DefaultListableBeanFactory.resolveDependency(DefaultListableBeanFactory.java:770)
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:486)

[ath0mas]

Faced same problem.
Indeed String based MigrationVersion constructor is used here when you declare your initVersion value as a String. This same constructor was deprecated in previous Flyway version, and now made "private".

I now use the advised factory method, like this:

<property name="initVersion" value="#{T(org.flywaydb.core.api.MigrationVersion).fromVersion('1.0')}" />

[axelfontaine]

Thanks for reporting and investigating this! I'm not currently sure what the best way to address this would be. I see a couple of options:

• changing the interface (would mean a breaking change for everyone using the API)
• add additional non-overloaded methods (polluting the interface)
• encourage people to use this workaround (not great, but does the job)
• lobby the Spring guys to add support for overloaded setters (so that you could lock in the string based one)

Thoughts?

[kayser]

might be the best to just document the workarround for now

[adrianchung]

Are there any updates on any decisions with this issue?

[everflux]

It would be awesome if you could manage to adhere to the JavaBeans convention. This would resolve this problem cluster.

See:
http://www.oracle.com/technetwork/articles/javaee/spec-136004.html

Juergen Hoeller said in https://jira.spring.io/browse/SPR-4931

The problem here is that the JavaBeans convention does not support overloaded setter methods to begin with. Each bean property must have exactly one (or none at all) setter method associated with.

[axelfontaine]

Special thanks to @dharrigan for sponsoring the fix of this issue!

[dharrigan]

Hi,

Confirmation. (See Screenshot)

I guess it'll be with you next week sometime.

-=david=-

On 5 December 2014 at 11:58, Axel Fontaine notifications@github.com wrote:

Special thanks to @dharrigan https://github.com/dharrigan for
sponsoring the fix of this issue!

—
Reply to this email directly or view it on GitHub
#752 (comment).

I prefer encrypted and signed messages. KeyID: B20A22F9
Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9

"It is not usually until you've built and used a version of the program
that you understand the issues well enough to get the design right." - Rob
Pike, Brian Kernighan.

No trees were harmed in the sending of this message, however, a number of
electrons were inconvenienced.