IDE test server overview

One of the goals of EDT is to let you test your applications without having to configure and deploy to your target environment. However, we must also use care not to alter the behavior of the application when in test mode.

The IDE test server (based on Jetty) is a major player in this regard, allowing you to invoke services from a Rich UI client without deploying them. Not only will the test server run the service right out of the EGL source project, it'll also automatically manages itself by updating configurations when files such as your deployment descriptors change. You don't even start the server yourself - it's started up when needed, and runs in the background. By the way, the server runs in debug mode, so you can set breakpoints in the service and step through the code.

Now, there are some situations where the server needs to be restarted for changes to take effect. You'll be prompted if this happens, and given the choice to terminate the server now or let it keep running. The most typical case is when the Java debugger's hot code replace fails (e.g. you modified a part but the generated Java code contains a type of change that the Java debugger does not support "swapping in", such as a new global field).

I mentioned previously that the server is started automatically, and an important addendum is that the server instance has a "base project", which dictates the classpath, the list of available deployment descriptors, etc. When invoking a service, one of the following rules is used to determine the "base project":

• When invoking a dedicated service, the project of the main Rich UI handler is the base project.
• When invoking a REST service, the project containing the service is the base project.

This allows us to best match the deployed environment. If you open the Debug perspective, the Debug view will list all the test server processes. The process name will indicate the "base project" of that particular server, and there is only one server process per base project. You can use this information to terminate a specific project test server. (Once killed it'll get started back up automatically the next time it's needed.)

Before I go, a couple tips:

• When invoking a dedicated service, make sure the project containing the service is on the Java Build Path of the Rich UI project.
• To invoke a service in a RESTful way, the service must be listed as a REST service in the deployment descriptor, otherwise it will not be exposed as a REST service (this is to match the deployed application's behavior). Then to use the test server instead of trying to invoke the deployed service, use the following workspace URI format for your REST binding: workspace://myServiceProject/myPackage.myService. If you use the 'http://' URI format then the test server will not be used.
  
• If you're using JNDI database access in your services, you can benefit from connection pooling (which provides a significant performance boost) simply by defining an Apache Tomcat runtime at Window > Preferences > Server > Runtime Environments. Otherwise it'll still work, but will run slower.

And if you're a developer looking to extend EDT, the test server can also be extended to support new concepts (information on this can be found on the wiki).

-Justin