New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overloaded setters break Spring XML usage #752

Closed
RahulPrabha opened this Issue May 9, 2014 · 7 comments

Comments

Projects
None yet
7 participants
@RahulPrabha
Copy link

RahulPrabha commented May 9, 2014

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:

screen shot 2014-05-09 at 1 42 27 pm

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

This comment has been minimized.

Copy link

ath0mas commented May 13, 2014

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

This comment has been minimized.

Copy link
Contributor

axelfontaine commented May 13, 2014

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

This comment has been minimized.

Copy link

kayser commented Jun 11, 2014

might be the best to just document the workarround for now

@adrianchung

This comment has been minimized.

Copy link

adrianchung commented Aug 5, 2014

Are there any updates on any decisions with this issue?

@axelfontaine axelfontaine added this to the Flyway 4.0 milestone Nov 26, 2014

@axelfontaine axelfontaine changed the title initVersion org.springframework.beans.ConversionNotSupportedException Overloaded setters break Spring XML usage Nov 28, 2014

@axelfontaine axelfontaine modified the milestones: Flyway 3.2, Flyway 4.0 Nov 28, 2014

@everflux

This comment has been minimized.

Copy link

everflux commented Nov 28, 2014

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 added a commit to flyway/flywaydb.org that referenced this issue Dec 5, 2014

@axelfontaine

This comment has been minimized.

Copy link
Contributor

axelfontaine commented Dec 5, 2014

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

axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Dec 5, 2014

axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Dec 5, 2014

@dharrigan

This comment has been minimized.

Copy link

dharrigan commented Dec 5, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment