Hello Ashish, thank you for your work on this feature. I personally find the approach very interesting.
Although I can see the point of view and the concerns raised by Geatan, offering extensive hot-reload capabilities directly from the framework/tooling without relying on the IDE is for me a nice addition. After all, it is an extra option for developers that don't use eclipse or Intellij - although I imagine they are a very small minority. To the concern regarding "plugin" code residing inside the main project, I was wondering if there was an option for some "creative" refactoring where you bind your new classloader through properties or a similar mechanism. Of course if any additional configuration is absent, it should default to the current implementation. In that case even your DevReloadHook class could live in the plugin and be picked up through a more generalised Interface that just provides the appropriate classloader. This way no changes in the main project hint to the existence of the dev container plugin, but anyone can provide their own implementation of a "classloader provider" that modifies the standard classloading behaviour for java. This is only an idea I had after looking at the modifications in trunk. I hope I was able to get my point across and that it addresses the concerns in this thread. Best of luck with further development and the future adoption of this functionality. Konstantinos Marinos On 2026/07/02 12:24:07 Ashish Vijaywargiya wrote: > Hello Jacques and Geatan, > > Thank you for sharing your thoughts. They were very helpful. π > > I thought about my implementation again and updated it a bit. The > implementation (WatchService + in-process compiler + a child-first > classloader) lives entirely in a small plugin, published separately at > https://github.com/ashishvijaywargiya/devreload. This plugin is available > to anyone, and anyone can clone it if required. > > I can also move it to the ofbiz-plugins folder if the community members > agree to put the "devreload" component codebase there. > > To make the framework pick up hot-reloaded classes when that plugin is > present, I need a small footprint in ofbiz-framework itself: a reflective > bridge, a small file DevReloadHook.java, plus one gated classloader check > each in StandardJavaEngine and JavaEventHandler. > > Branch for reference: > https://github.com/apache/ofbiz-framework/compare/trunk...ashishvijaywargiya:ofbiz-framework:dev-reload-container-support > > Hopefully, now the changes in the "dev-reload-container-support" branch can > be merged into the OFBiz trunk code. > > To demonstrate the feature, I have added a new field "comments2" on the > form, and then made the changes in services.xml, and then made the changes > in OfbizDemoServices.java file. The changes in services.xml and java files > are reflected without restarting OFBiz. > > https://drive.google.com/drive/folders/1W5ILWVOSBD956GcDT50-GmZkV_seMNRv?usp=sharing > > I have made the changes in a demo component - > https://github.com/ashishvijaywargiya/ofbizDemo. > > Please let me know your thoughts on this. > > I will also explore the HotSwap plugin in IntelliJ IDEA and get back with > my thoughts. > > Thank you. > > -- > Kind Regards, > Ashish Vijaywargiya > Vice President of Operations > *HotWax Systems* > *Enterprise open source experts* > http://www.hotwaxsystems.com > > > > On Wed, Jul 1, 2026 at 9:49β―PM Jacques Le Roux via dev <[email protected]> > wrote: > > > Hi, > > > > I tend to agree with Gaetan. > > > > Jacques > > > > Le 01/07/2026 Γ 09:18, gaetan.chaboussie via dev a Γ©crit : > > > Hello Ashish, hello all. > > > First, thanks for the effort put into this. Seems like a lot of work > > (even if it looks like there has been some AI help on the code). > > > This being said, I'm not sure how i feel seeing a 'developer only' > > intended feature in the project code. > > > I think that it's the IDE's job to provide this kind of feature. In my > > experience, Eclipse handles it natively pretty well, and Intellij is making > > > great progress (and has a Hotsawp plugin that i personally use). > > > Also, i believe that it's precisely the point of GroovyScripts to allow > > editing without recompiling. > > > > > > Although I understand the idea, I would personnaly not advise this > > change, that creates low level code changes, and looks tricky to maintain. > > > > > > Gaetan. > > > > > > On 6/30/26 18:03, Ashish Vijaywargiya wrote: > > >> Hello OFBiz Dev Community, > > >> > > >> I would like to share a prototype that removes the need to restart OFBiz > > >> when developing Java services, events and service > > definitions(services.xml). > > >> > > >> Many years ago I came across Tomcat's reloadable="true" context > > attribute. > > >> When enabled, Tomcat's application deployer watches for class file > > changes > > >> and > > >> automatically reloads the web application β no server restart, no manual > > >> step. I always thought that was a great developer experience, and at the > > >> back of my mind I wondered whether something similar could be done in > > OFBiz. > > >> > > >> The standard Java change cycle in OFBiz today is: > > >> edit .java β ./gradlew classes β kill OFBiz β wait 30-60 s β restart β > > test > > >> > > >> Groovy scripts and Freemarker templates already pick up changes without > > a > > >> restart; Java does not. This prototype brings the same convenience to > > Java > > >> development, specifically targeting *Services.java and *Events.java > > files > > >> which are the ones developers touch most during active feature work. > > >> > > >> --- What it does --- > > >> > > >> A new class called DevReloadContainer is added to framework/base. It is > > >> activated by passing -Dofbiz.hotreload=true on startup and does three > > >> things: > > >> > > >> 1. Watches build/classes/java/main/ for changed .class files and > > >> hot-swaps them into a fresh class loader without restarting OFBiz. > > >> In practice this means saving a *Services.java or *Events.java > > file > > >> is enough β the change is live in under a second. > > >> > > >> 2. Watches all component servicedef/ directories and clears the service > > >> model cache when any *services.xml file changes, so new or > > modified > > >> service definitions are picked up immediately. > > >> > > >> 3. Watches all component src/main/java/ directories and compiles changed > > >> .java files in-process (using javax.tools.JavaCompiler), so you > > do not > > >> need a second terminal running ./gradlew -t classes. > > >> > > >> A 300 ms debounce window batches a burst of file-save events into a > > single > > >> reload, so rapid edits do not cause multiple reloads. > > >> > > >> --- The new dev workflow --- > > >> > > >> A new Gradle task wraps everything into one command: > > >> > > >> ./gradlew ofbizDev > > >> > > >> Start OFBiz with that command, then edit any *Services.java, > > *Events.java, > > >> or *services.xml file and save β changes are live without any restart. > > >> > > >> The working code is on branch dev-reload-container-support. > > >> > > >> > > https://github.com/ashishvijaywargiya/ofbiz-framework/tree/dev-reload-container-support > > >> > > >> > > https://github.com/apache/ofbiz-framework/compare/trunk...ashishvijaywargiya:ofbiz-framework:dev-reload-container-support > > >> > > >> The implementation went through several rounds of debugging and > > >> covers 32 test cases including child-first class loading, multi-cycle > > >> reload correctness, > > >> inner and anonymous class reloading, concurrent class loading, > > >> malformed-bytecode handling, shutdown races, and the macOS > > spurious-event > > >> suppression. > > >> > > >> Please review this feature and let me know your thoughts/feedback. > > >> And please report any issues you find. > > >> > > >> Very soon, I will be creating a pull request for this feature. > > >> > > >> I am hopeful that this feature will be helpful to all developers who are > > >> building enterprise applications using the Apache OFBiz project. π > > >> > > >> Thank you. > > >> > > >> -- > > >> Kind Regards, > > >> Ashish Vijaywargiya > > >> Vice President of Operations > > >> *HotWax Systems* > > >> *Enterprise open source experts* > > >> http://www.hotwaxsystems.com > > >> > > >
