Why can't be bundled luceedebug.jar in VS Code extension?

[rodriciru]

I suppose there's no way to run this extension without the jar file. So my question is, why can't be bundled luceedebug.jar in VS Code extension? It's something OS specific. In that case we can include some major OS versions no?

[jamiejackson]

That actually seems awkward to me, even if the extension could download the Jar. The client side (VS code extension) is really solidly a client-side thing and the agent side (the Jar) is a solidly server-side thing. I think the current separation is desirable.

It also begs the question that the Lucee server that's being debugged is on the developer's host OS, which isn't necessarily true. For instance, my Lucee runs in a docker container, in which the agent/Jar is baked in. Others might be debugging Lucee on a truly remote server.

If it's a convenience thing, maybe it would be helpful to add a jar download link to the extension details page... wait, we don't have a jar download page yet, do we? I guess this has a dependency on that. We'd need a GitHub action to publish Jars.

[softwareCobbler]

We could probably auto download the jar, but we can't auto-spawn or auto-configure your server. I think this just reiterates @jamiejackson's comments above.

@jamiejackson also mentions github actions, which @zspitzer actually put work into a while ago. Artifacts are built, but I'm not sure if it's possible to get a stable link to "the most recent" result.

If we could get such a stable link then it could be placed in the extension details page. This would at least save people from having to look at Gradle.

Here's a (probably non stable) link to the current build: https://github.com/softwareCobbler/luceedebug/suites/16530704252/artifacts/944188478

[rodriciru]

OK. There's a step forward not to clone, gradle....... to get a jar, which can be simply downloaded.

But why in the readme say this: If you are an end-user who just wants to start debugging your CFML, install the luceedebug extension from the Marketplace.

For me, this line translates to OK. I don't need the jar file, just the VS Code extension. The JAR is for advanced users who want to customize the JAR or developers of the JAR, but not for me, because I am an end user.

[carehart]

If I may dare to wade into these waters (please don't bite me--and forgive me using lots of words, but I hope they're helpful and necessary)...

Rodriciru, I think you're misconstruing what that sentence is getting at. In saying "an end-user who just wants to start debugging", that's referring to the the first of the two options in that section labelled, "VS Code luceedebug Debugger Extension". The second option is for those who want to "hack" at the extension.

More important, that discussion of the extension is itself the second of two broader steps on the page, with the first being "Install and Configure Agent". And it's THAT which discusses adding the -javaagent jvm arg, which would POINT to the jar in question. I think the page makes it pretty clear that those are two separate broad and required steps.

So your question here has been focused on "why can't be bundled luceedebug.jar in VS Code extension?" Even if that was done somehow, there is STILL the need to do the step of configuring that jvm arg in your lucee config to add the javaagent to point to the jar. And trust me, getting the jar is the easy part (even if it does require "a step you'd hoped to avoid").

That "pointing" to the jar is going to be by FAR the more challenging step for most, because there are MANY different ways people implement Lucee (whether the installer, express, jar, or war approaches--and whether implemented on Tomcat--not to mention the container image). Each has different ways that jvm args like the javaagent should be specified, and more importantly WHERE that should be done. (This problem plagues also those who simply want to increase the java heap size or other JVM args for Lucee.)

And this page understandably offers only a brief discussion of that jvm configuration step, saying "Tomcat users can use the setenv.sh file for this purpose"...which itself is not true if you installed Lucee with the Windows installer. (In that case, you instead change such jvm args with the luceew.exe tool).

This javaagent config step can be maddening--for users as well as for the tool makers/project creators. And different ones (for tools implemented as javaagents) have over the years offered a widely varying level of coverage about all these options (of how to configure a java agent): some with far more detail, some with barely more. There are just SO many permutations (even for a jvm app deployed "on Tomcat", let alone in other app servers).

My main point here is that this concern over "bundling the jar" is just one of two steps. Even if a Lucee extension might "bundle the jar for you", such an extension would really need to also do this next vital step of "finding where to place the javaagent in the right place" and doing that. Otherwise that will be the next real pain point for you and others who may raise such a concern. (Or do you understand all this already, and feel differently still?)

Bottom line: for now, the steps in that first section can't "just be done for folks". It is going to require potentially "advanced" knowledge (at least more "complete" knowledge) of configuring a javaagent--however Lucee is implemented, That's not really "advanced" knowledge, but it's not trivial--whether as a tool or being documented more completely.

But mine is an observer's perspective (being familiar with other tools that require handling java agents, with Lucee or CF or otherwise). Others here may have different thoughts, of course. As always, I'm just trying to help, and to move the conversation forward.

[carehart]

I'm surprised this has been closed without discussion from either side. I was standing in the middle, hoping to broker an agreement. :-)

[rodriciru]

I'm not in the position of nothing. I'm not a CF or a java experienced dev, so my contribution here will be nothing.

Reading your statement,it was clear that the jar has to exist,and it's impossible to auto-atach.

I also think an link in the extension or somewhere else it's a very good idea.

So I no see reasons to keep this issue open.

That's why I closed this, but if is good to keep open I will open again if I could

El mié, 8 nov 2023 15:19, Charlie Arehart @.***> escribió:

I'm surprised this has been closed without discussion from either side. I was standing in the middle, hoping to broker an agreement. :-)

— Reply to this email directly, view it on GitHub https://github.com/softwareCobbler/luceedebug/issues/49#issuecomment-1801984595, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACR6MY3WO2BPFGOTZPP44LLYDOII3AVCNFSM6AAAAAA6PSE6S6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBRHE4DINJZGU . You are receiving this because you modified the open/close state.Message ID: @.***>

[carehart]

Understood. I just couldn't know how you regarded the help or the situation.

Next I'd hope we might hear from any committers here about what, if anything, might be considered based on the situation--whether something they may want to do, or something they'd at least be open to someone else offering as an pr. They may well feel it's sufficient as-is, in which case one need not bother to propose anything.

Again, just hoped to hear from both sides before the issue was closed, as surely someone else could experience it...and I suspect most people don't go trawling through closed issues to find answers--though that can be valuable, as in this case. :-)

[softwareCobbler]

most recent build is now available at https://github.com/softwareCobbler/luceedebug/releases/latest