[CONTROLLER-1216] Hot reloading MD-SAL application in karaf container Created: 16/Mar/15 Updated: 25/Jul/23 Resolved: 04/Jul/17 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | config |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Abhishek Kumar | Assignee: | Michael Vorburger |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 2855 |
| Description |
|
An UnsupportedOperationException is thrown when you try to deploy an MD-SAL application. Caused by: java.lang.UnsupportedOperationException: Class reloading is not supported The new code does not take effect. I see that “handleChangedClass” referred to in above exception is not implemented and throws UnsupportedOperationException. |
| Comments |
| Comment by Tony Tkacik [ 17/Mar/15 ] |
|
I believed this was for hot reloading of MD-SAL, but that is for your application, |
| Comment by Abhishek Kumar [ 19/Mar/15 ] |
|
We could create another defect for hot reloading of MD-SAL itself. This defect is intended to be for hot reloading applications based on MD-SAL (like the one I have). It uses config subsystem for dependency injection and osgi registration. In the handleChangedClass, I would like to create a new module instance (based on new classes). The new instance creation for module requires "DependencyResolver" that is not passed to this method. Any pointers on how to get a reference to DependencyResolver? Also, since this method handleChangedClass will always need to be implemented by the module, does it make sense to move it out of abstract factory and place inside module factory during code gen? |
| Comment by Tony Tkacik [ 23/Mar/15 ] |
|
As your explained this is for your application, so this could not be fixed in Controller, but in your app. Closing this as Resolved - Wontfix, since fix is needed in your app. |
| Comment by Abhishek Kumar [ 03/Apr/15 ] |
|
This issue is in the yangtools generated class. Hence, reopening the defect but changing the product to yangtools. If you notice the stacktrace in the description above, the failing method is This source code for this class is auto-generated by yangtools and can not be modified by application. |
| Comment by Tony Tkacik [ 07/Apr/15 ] |
|
Closing - handleChangedClass needs to be customized by user, we can not autogenerate different implementation, since that means bundle got reloaded and may contains incompatible class changes, which effectivelly means yangtools and contoller compontents do not know how it changed, if this change was compatible So we should update description for handleChangedClass which describes in general |
| Comment by Tony Tkacik [ 07/Apr/15 ] |
|
Moving back to controller, since JMX generator is config subsystem generator and is not present in yangtools (never was). |
| Comment by Michael Vorburger [ 13/Jun/16 ] |
|
https://lists.opendaylight.org/pipermail/mdsal-dev/2016-June/000360.html |
| Comment by Michael Vorburger [ 18/Jun/16 ] |
| Comment by Michael Vorburger [ 28/Jun/16 ] |