Thank you, Gaetan, for sharing your valuable feedback. In the next few days, I will prepare a document on the OFBiz project wiki and share the feature/plugin details.
If someone wants to use it, then they would get the reference from the project wiki. -- Kind Regards, Ashish Vijaywargiya Vice President of Operations *HotWax Systems* *Enterprise open source experts* http://www.hotwaxsystems.com On Thu, Jul 2, 2026 at 6:22β―PM gaetan.chaboussie < [email protected]> wrote: > Hi Ashish, > > Inline -> > > On 7/2/26 14:24, Ashish Vijaywargiya wrote: > > Hello Jacques and Geatan, > > > > Thank you for sharing your thoughts. They were very helpful. π > You're most welcome :D > > 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'm much more confortable with this approach. > > I can also move it to the ofbiz-plugins folder if the community members > > agree to put the "devreload" component codebase there. > > I'm still not confortable with this. Any code in the plugins repository > means it become the community's responsability to maintain, and we > already have a lot of work going on. > > > 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. > > I'm not sure if it is a good practice to leave some code for a plugins > in the framework, even more so if the plugin isn't commited in the > plugins repo. > > The framework (IMO) shouldn't hold code that serves ONLY for a plugin. > I think a patch in the relevant plugin repo or readme might be enough. > > > 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. > Again I'm sorry, I don't want to be a bad guy here, but your own :-), Thank you for sharing your thoughts. > > external plugin (that might be referenced on the tools page of the > projects wiki) is the way to go IMO. > Best regards, > Gaetan > > 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 > >>>> >
