renaming a spring bean class leads to 2 beans in the application context

ZeroTurnaround Homepage Forums JRebel Support renaming a spring bean class leads to 2 beans in the application context

This topic contains 7 replies, has 5 voices, and was last updated by  Meelis 1 week, 2 days ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #55914

    Jorg Heymans
    Participant

    Hi,

    After renaming a spring bean and jrebel reload, i can discovered through ApplicationContext.getBeansOfType that teh application context now contains both the old and the new bean. Is this normal / supported ? I am using 6.4.1-SNAPSHOT (201602240111).

    Thanks,
    Jorg

    #55917

    Colton Sablinsky
    Moderator

    Hi Jorg,

    Is there a reason that you are currently using the nightly build? Do you see the same problem if you use the latest stable release (JRebel 6.3.3)?

    Regards,
    Colton

    #55927

    Jorg Heymans
    Participant

    Was using snapshot because of other bug. Tested using 6.3.3 same behaviour. It is really easy to test. Just create a bean, start the app, check with getBeansOfType that there is only one such bean. Then rename the bean, jrebel reload, and verify again with getBeansOfType that there are now two instances of this bean in the app context.

    using Spring 3.2.16 in case it matters

    #56205

    Hi Jorg,

    Thanks for reporting this.
    This is indeed how JRebel integration with Spring currently works, but you are correct that the preferred behavior would be to return only the new bean after renaming the bean.

    We would like to look into what we can do about it, but could you please provide us some insights first? How often are you renaming beans and what is the side effect for you of ApplicationContext.getBeansOfType returning old beans after you renamed the bean?

    Best,
    Tanel

    #56433

    Jorg Heymans
    Participant

    Well renaming a bean most of the time is the same as renaming the class if there was no explicit bean name set. Choosing a different name for a class happens regularly during initial code development when concepts are still settling. The side effect in this particular case was that one of our application management screens was showing a duplicate entry in a dropdown where we list all beans implementing a specific interface. Nothing terrible really. But for example imagine one would rename a class implementing <ApplicationListener>, then business logic in that handler would execute twice because of there being two such beans now, probably causing quite a bit of confusion.

    Jorg

    #56550

    Meelis
    Moderator

    Hi Jorg,

    Thank you for the input.

    The use-case with ApplicationListener class rename causing event to be processed multiple times is indeed valid. I have created a test that describes this use-case.
    We will look into it and see what the best way to resolve the issue is, however we can’t give any deadlines as of now.

    #66765

    khayassine
    Member

    Hi,

    Is there any news regarding this issue ?

    Thanks in advance,
    Yassine

    #66774

    Meelis
    Moderator

    Hi,

    Unfortunately the issue is on hold as currently JRebel doesn’t support removing beans in general. Renaming is essentially a remove + add with new name.
    We do have some specific integrations targeting bean renames, such as the recently added support for renaming Controller-s without it causing duplicate mapping errors, however the case with for example ApplicationListener-s is slightly trickier.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.