renaming a spring bean class leads to 2 beans in the application context
February 29, 2016 at 2:22 pm #55914
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).
JorgFebruary 29, 2016 at 8:07 pm #55917
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)?
ColtonMarch 1, 2016 at 8:52 am #55927
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 mattersMarch 7, 2016 at 2:09 pm #56205
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?
TanelMarch 13, 2016 at 7:47 am #56433
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.
JorgMarch 16, 2016 at 7:34 pm #56550
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.December 7, 2017 at 12:16 pm #66765
Is there any news regarding this issue ?
Thanks in advance,
YassineDecember 8, 2017 at 2:39 pm #66774
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.
You must be logged in to reply to this topic.