Okay, maybe I'm completely crazy, but I thought I would be able to debug end to end with EDT. So I went in and set a breakpoint in my client, then right-clicked on it and said Debug As... EGL Rich UI Application. I hit the breakpoint in my client and so I set a breakpoint in my library (which is called by my service). I hit the Resume button and... the application ran to completion (calling my service and retrieving the data) and updated my browser page without stopping at my breakpoint.
Darn! I tried stepping into the call to the service as well, but no love there. Is there some magic I need to do to enable breakpoints in the server-side EGL?
Are you running the service on the test server or a server like Tomcat? If using the test server, it is always running in debug mode, so you can debug your server side by setting breakpoints in the EGL source (the RUI client does not need to be in debug mode since they are separate processes).
If you're running on Tomcat then you'll be running the 'deployed' service and not a debug-enabled version.
Note that to use the test server your resource binding must be the workspace:// format.
I'm not consciously running the service at all. I assume it's running on the test server, but all I'm doing is right-clicking on the client EGL source code and selecting Debug As... EGL Rich UI Application. I have breakpoints set in my server, but I didn't set anything that tells it where to run. I use a dedicated service, and it works - I get all my data from the host (this is the SQL code from the other thread). So how do I invoke my client in such a way that breakpoints in the server code are enabled and honored?
P.S. Which resource binding are you referring to? As I said, I call my service from the RUI by using a dedicated service. Within my server code I invoke my SQL using the following:
Okay, yes, dedicated services in the preview pane and debug mode are always run on the test server, so no bindings come into play here (REST services require the workspace:// URI to have the service run on the test service during development, and then you'd use http:// to invoke the deployed version).
I tried out a couple applications on my machine and my breakpoints are being hit. Can you try putting breakpoints in more locations? The breakpoints are driven by "SMAP" files that map EGL lines to Java lines, and it's possible the mapping for a statement is not correct.
Also, which build are you using? Nightly? Milestone?
Okay, I've got it working here. I'll try again on the other workstation tomorrow. It does take a little getting used to; you have to think about the breakpoints in the client and in the server and remember to resume each side appropriately. But I can indeed look at a variable on the host and see that it gets returned to the client. This is rockingly good stuff.