Announcement Announcement Module
No announcement yet.
How to deal with overloaded setters in an external API? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to deal with overloaded setters in an external API?

    class SomeoneElsesAPI {
       void setDirectory(File dir){...}
       void setDirectory(String dir){...}
    <bean id="someoneElsesAPI" class="com.someone.SomeoneElsesAPI">
       <property name="directory">
          <value type="java.lang.String">/etc</value>
    I have a case similar to the above example, Spring is throwing an IllegalStateException indicating that it can't convert String to File.

    How do I tell spring which of the overloaded methods to use? I thought spring would figure it out when I specified it in the <value type="..."> parameter which relieves any ambiguity.

  • #2
    Ok, from various other discussions and a whole lot of reading what I understand is that Spring just doesn't support overloaded setters (because, hey, the're not beans, right?).

    Anyway, maybe I just don't understand reflection, but it seems so easy to allow a separate option for defining the signature to eliminate ambiguity in these cases. I mean, it's done in constructors right?

    I would never write non bean conformant code myself, but there's plenty of useful stuff out there that just wasn't built for bean architectures.

    As is we have to write custom wrappers and nasty little workaround for stuff like that it seems, this all ties code to the spring framework which goes against spring principals of minimal-intrusiveness, and sure does just makes things hard (another non-spring like attribute).

    Anyone out there able to enlighten me as to why there isn't a method signature feature in properties like there is in constructors? Seems like the constructor signature functionality solves the same exact problem, why not re-use the same successful solution?