hello all. i spent a lot of my free time for 2 years working on a step debugger project called Coldbug for Lucee. i have abandoned the project a few months back, but i figured i could share the code to give some ideas or if someone wants to mess around with the code. it does work, for small websites that do not have many complexities, running on a PC. I have destructed the project some to remove the website and some other stuff, but everything should be there if you want to run it locally. I use VS code but I am sure it is feasible to use eclipse or another java IDE. I hope it works for you if interested, and I am willing to help you get it running, but I am no longer doing development on the project.
1 Like
thanks for sharing this, some of the test seem to be failing.
[ERROR] Failures:
[ERROR] clientsidehandlerTest.forgotpassword_test:169 expected: <true> but was: <false>
[ERROR] clientsidehandlerTest.login_false_test:80 expected: <false> but was: <true>
[ERROR] clientsidehandlerTest.register_test:148 expected: <true> but was: <false>
[ERROR] heartbeathandlerTest.callapiheartbeat_loggedin_test:31 expected: <true> but was: <false>
[INFO]
[ERROR] Tests run: 47, Failures: 4, Errors: 0, Skipped: 0
also, would you consider putting this up on github?
I’ve been playing with jpda and lucee a bit, this exposes the cfml code to the debugger right?
The red hat language server support in vs code could possibly pick up on this?
-
the tests were part of the production build and i made some modifications before making it a public repo. you can delete theses tests as they will not add value to the project now.
-
i dont use github, feel free to clone and upload it to github if you want to play with it on there.
-
yes it does. in the case of coldbug, the significant code you might want to look over would be inside of the src/main/java/com/riftwebdesign/coldbug/controllers/EventController.java line 325 createBreakPointRequests
-
ive not played with any debugger settings inside of vscode, it might be possible. i think one of the more challenging aspects will be to acquire the variables from lucee as the variables are stored in different scope objects and are not part of the variable set that jpda is going to find. because you will need to get the pagecontext object to have access to these scopes. In the same file listed in 3) the EventController.java file, look around line 458, which loops the frames in the stack to find the PageContext. Once you have this you can invoke some methods using jpda to get scopes or other things.
3 Likes
Thanks for sharing. I played with it two weeks ago. It looks promising. Although it indeed needs some work. It did not really let me connect reliably yet.
I managed to get it working on a Windows and Mac locally using the Lucee Express version. I did not have any real issues here with debugging a very basic cfm page. It shows the webinterface, stops at breakpoints and shows variable contents by using a cfdump.
However when I try to connect it to a remote Lucee instance, I seem to be able to connect (through a tunnel on localhost 7999) and I was able to see a connection in the dashboard, however when I hit a break point (or at least I assume that is it, because it does not turn orange), my lucee server. hangs.
I see this in de logs of coldbug:
java.util.ServiceConfigurationError: com.sun.jdi.connect.Connector: Provider com.sun.tools.jdi.SharedMemoryAttachingConnector not found
java.util.ServiceConfigurationError: com.sun.jdi.connect.Connector: Provider com.sun.tools.jdi.SharedMemoryListeningConnector not found
In my Lucee server I managed to make it expose the 7999 to the outside world, so I know it connects (also showing in the Coldbug dashboard). Another way to debug in your remote server is to run the client app jar on the server and tunnel the webinterface. It does seem to connect but looses it again.
It seems that debugging at breakpoints the parent of extended cfc’s never do get picked up unfortunately.
But it definitely is promising. And yes, integration with VS code would be awesome.
Based on the error, my first assumption is that the JDK is not installed. the “com.sun.tools” lib i believe is only inside of the JDK. the project itself I believe includes a folder with jars and the pom “clean” process will install these jars.
that use case you got working is probably going to be more reliable than anything else. i mostly developed it from a local standpoint on windows using lucee express. i did do some testing with linux. and i did some testing with a locally installed lucee version. however, these were not the main focal points of the project because there are alot of issues related around some qwerks i was trying to polish with bigger projects. its just too time consuming as a side project and like i mentioned, i have spent over 2 years in free time to get it too where it is now, which is still not fully functional. its just too big of a project to do alone.
from what i know now, IMO, the best approach will probably be developed from both sides. I think lucee needs to have an adapter interface that allows easier access to retrieving information or setting variables from the jdpa connector, and the connector will need to be able to access that adapter to get information to setup breaks, or get/set variables.
On the Lucee side of things, there is already some existing, built in support?
1 Like