We’re starting to plan Lucee 9 and want your feedback early.
Today Lucee comes in two parts: the loader, lucee.jar, and the core, lucee.lco. For Lucee 9 we plan to merge them into one simple jar. Lucee itself would no longer run on OSGi, and the jar would no longer bundle third-party jars; those would come from Maven when needed.
Upsides
Faster startup.
Much simpler to run, embed, build and maintain. It’s just one jar, like any other Java library.
Downside
No more hot deployment of new Lucee versions, so updating Lucee means replacing the jar and restarting. In our view that’s a small price, since most setups restart for updates anyway.
This continues what we’re doing for Lucee 8 (LDEV-6589), where Maven only gets the plain Lucee jar and the full build for Express and WAR goes to GitHub Releases. The Lucee 9 ticket is LDEV-6590.
What we’d like to hear from you
Do you use hot deployment of Lucee versions (updating the core through the admin or by dropping in an .lco) without a restart? How important is it to you?
Do you rely on the loader/core split in any other way?
Anything else we should keep in mind?
Please reply here or comment on the ticket. Nothing is final yet, so now is the best time to shape it.
what i see in my daily business that people no longer relay on lucee core deployment (lco), this was fine couple years back, but today deployment looks completely different, but that maybe just me
Will this affect usage of multiple versions of the same package? I install a version of Bouncy Castle for my codebase. My code has been tested and verified with that version. Lucee already has a version of Bouncy Castle. Currently OSGi make these multiple versions possible. How will that be affected?
Every deployment I’m doing is containerized at this point, so it makes no difference to me. Even going back a few years ago, deployments were based on .WAR packages, so hot reloading wasn’t really a concern.
Thanks @Leftbower, @illequipped and @micstriit, that matches what we’re hearing. @apenhorwood good question: dropping OSGi applies to Lucee itself only. Classloader separation stays. Already today, Lucee extensions can load different versions of the same Maven-based library without conflicts, and that won’t change in Lucee 9. On top of that, Lucee 9 won’t ship third-party jars inside the Lucee jar anymore, so your own tested Bouncy Castle version won’t collide with a copy bundled by Lucee. We’ll make sure that case keeps working and note it on LDEV-6590.
neither. I create a new container with the new Lucee version and keep the old one in a separate container in parallel or a backup, until I can confirm that all of my code works with the new Lucee version.
For local stuff, I use commandbox and update server.json, so it wouldn’t matter for that.
On my non-local stuff though, I generally don’t have server access that allows me to control things outside the webroot. so, I’ve regularly relied on the admin update for updgrade and downgrade (I generally expect a restart here also). I’m not saying don’t do it. And overall, i’m less concerned about the upgrade, because those are easier to schedule than an unexpected need to rollback is.
Thanks @emjay2 for sharing how you handle updates. The point about rolling back through the admin when you have no access outside the webroot is really helpful input for the Lucee 9 plan, and we’ll keep it in mind.