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
