http://coldfusion.com logo
Join Slack
Powered by
anyone have a good way to uninstall lucee extensio...
# lucee
f
anyone have a good way to uninstall lucee extensions from the command line?
z
rm -rf
f
yeah, I was thinking I could delete certain lex files in 
lucee-server/context/extensions/installed
but, they are named things like 
18buz1m6kzx2m.lex
which is the same as in 
available/D46D49C3-EB85-8D97-30BEC2F38561E985-1.0.0.2.lex
but with the UUID in the file name I can know what extension it is, not sure how 
18buz1m6kzx2m.lex
is generated
normally I would just use lucee light and then add extensions as needed, maybe a better approach but in this case I am wanting to do it the other way around
z
pre install?
you can just delete the files for the unwanted extensions from the fat jar
f
in this case I’m using the lucee installer (which also I normally don’t use)
yep, so in this case I’m using the lucee installer with the unattended flag via a script, so I want to remove a few extensions that are unneeded
z
if you don't start lucee via the installer, you can still just replace the fat jar
f
ok a little tricky to script, but possible
z
wouldn't mind allow passing in a custom fat jar via installer param
f
what about passing a custom extensions uuid list, maybe more useful?
b
@foundeo I'm pretty sure there is an env var to uninstall extensions on first start
👍 1
Let me look
z
advantage of the above approach, you could use the latest installer to instal 5.3.8 but with latest java / tomcat
b
It is ironic though how • Adobe gave us a command line, but no env vars or file system conventions • Lucee gave us env vars and file system conventions, but not command line 🙂
Dang, maybe I dreamt that uninstall one 🤔 https://docs.lucee.org/guides/Various/system-properties.html
z
yep, it's only additive
f
yeah there is an extensions env var, but I think it tells it to install them, not uninstall them
I think it is 
LUCEE_EXTENSIONS
z
light and dump the desired extensions in /deploy
b
No, that's the one to install. I thought for sure I had seen one for uninstalling, but I guess I imagined it
z
b
z
hehe
b
It's uninstalling extensions all right but I guess it's not something we can tap into
f
yeah, bummer
b
Funny Zac and I were looking at the same code 🙂
themoreyouknow 1
f
getting back to my question, I just searched my commandbox folder locally and I find I have a bunch of 
18buz1m6kzx2m.lex
files in various installs
so that name is not randomly generated apparently
b
It's predicable but I forget where it comes from
f
I think that solves my problem if I can predict the names
b
FWIW, I don't think you can just delete them if they are already installed-- installing extensions adds stuff to the Lucee XML files
🤔 1
z
HashUtil.create64BitHashAsString(id + version, Character.MAX_RADIX) + ".lex";
👍 2
another why are we using guids etc here question
b
Yeah, I already hate several things about extensions which seems to have been designed in a manner to piss of developers as much as possible 😆
f
yeah, has these entries in lucee-server.xml:
Copy code
<rhextension file-name="18buz1m6kzx2m.lex" id="D46D49C3-EB85-8D97-30BEC2F38561E985" lucee-core-version="5.0.0.050-" mapping="[{'virtual':'/lucee/doc','physical':'','archive':'{lucee-config}/context/lucee-doc.lar','primary':'archive ','inspect':'once ','toplevel':'true','readonly':'true','listenermode':'modern','listenertype':'curr2root '}]" name="Lucee Documentation" release-type="all" start-bundles="false" trial="false" version="1.0.0.2"/>
z
i did convince @micha that package names and versions are just as unique and we might change that (alas, like all IT projects we have a huge backlog)
f
my conclusion: this will be a pain in the rear to script uninstall of extensions
Brad - there is no way to do this with cfconfig right?
b
No, CFConfig edits XML files on disk which may or may not even exist in the context of a server. Extension install/uninstall requires an actual running Lucee server with all of its baked in logic
👍 1
z
lucee.extensions.blocked or something
f
would be nice Zac
z
whatdoyareckon @micha?
does the lucee 6 mix of extensions come closer to your desires? i.e. no form, ajax, search, axis, chart?
🚀 1
something like this?
blocked ain't quite right language wise, where's @Adam Cameron when i need him?
b
Is your goal to • prevent the default installation of extensions bundled with a lucee jar (more specifically, declared in the manifest) on first boot? • actually uninstall a possibly previously-installed extension from the server on any boot
z
the first, this is initial deploy
preventInstall
b
The trick here IMO is that the env var to install extensions "just works", whether it's the first start or the 1000th start. I think an env var that told Lucee "_I don't wish for you to have ESAPI installed_" should also work regardless of whether it's the first start or the 1000th.
💯 1
I can already imagine scenarios (such as building an an Ortus pre-warmed Docker container) where you don't have the liberty of being the "first start" but you still may want Lucee, from that point forward, to no longer have an extension installed.
z
yeah that makes sense
so i'd guess that would hook into the checking deploy folder logic on startup more or less
Thinking about this on the train, we could just support prefixing the guids defined in lucee.extensions with ! Indicating they should be removed / not installed? Makes everything simpler and means no rules to handle conflicts between lucee.extensions and the blocked env var i was suggesting
b
That's an interesting idea. Curious what Micha's take is on it
z
visually - might be a bit clearer depending on the font used. @micha what do you think about the overall idea?
2 Views
Open in Slack
PreviousNext
Powered by