JRebel with remote servers: new features and migration

With the release of JRebel 6.2.4, we are introducing a significantly improved remote servers support. This is currently available only in JRebel for Eclipse.

What’s new?

Centralized remote server management in your IDE

Until now, you had to separately configure the remote server URL and other settings for each project. The new JRebel plugin introduces central remote server management. This means adding the remote servers once and reusing the configuration for the projects deployed to that server. This becomes increasingly useful as the number of your remote projects grows.

Security, simplified

We provide optional security for the communication protocol between the IDE and the remote server. Do keep in mind that a remote server running in your internal network (or otherwise protected by the network layer) does not really need this extra security.

For users that do wish to use additional security, we have good news. We have re-implemented this feature, replacing the complicated public/private key configuration with a simple password.

Previously, the public key was defined in rebel-remote.xml within the deployed .war file. This meant that it would be spread around on multiple remote servers, and that it would get updated with every project redeployment. The new password-based implementation is scoped per server and does not depend on projects that are deployed to that server. It does need to be initialized on the server. Please refer to the the migration instructions below to learn how to set up the new security.

Dropping context paths from remote server URLs

To simplify the configuration, providing the full context path in the remote server URLs (within the IDE configuration) is now optional. You can configure just by entering the root URL of your remote Java application server. Using URLs with full context paths is also still supported.

About compatibility

The new IDE plugin requires the new server-side JRebel agent. The remote server support in JRebel for Eclipse 6.2.4 expects the JRebel agent on the server to be upgraded to JRebel 6.2.4 or newer.

The updated server-side JRebel agent works with all JRebel IDE plugin versions. The new JRebel agent on the server-side supports both the new IDE implementations (JRebel for Eclipse 6.2.4 or newer) and the old IDE implementations (JRebel for Eclipse 6.2.3 or older, any currently available version of JRebel for IntelliJ or JRebel for NetBeans).

Migration guide

Using the central remote server configuration

This part of migration is optional -- although recommended. If you decide to skip it, your remote server configuration will remain valid.

Let us assume that you are working on three separate projects, all deployed to the same remote server. In essence, a setup like this:

Project 1 -- deployed to http://myserver:9000/project1
Project 2 -- deployed to http://myserver:9000/project2
Project 3 -- deployed to http://myserver:9000/project3

In the previous JRebel remote server implementation, this required turning on remote server support for each of these projects, and then entering the three deployment URLs, one-by-one for each project. When switching over to the new JRebel remote servers implementation, this configuration is still supported (selecting the option Use project specific settings). The new implementation provides a "do not repeat yourself" method of configuring the common remote server for the whole workspace. This is especially useful when you manage a large number of remote projects.

To switch over to the centralized configuration, open JRebel Configuration > Remote servers and add a remote server using the URL without the context path (http://myserver:9000 in our example). Following that, open the JRebel settings for each of your projects and switch from project-specific settings to Use workspace server.

Were you using multiple deployment URLs in a previous version of JRebel for Eclipse to synchronize your changes to multiple remote servers at the same time? This option will no longer be available. With the upgrade to the new JRebel IDE plugin, all URLs for projects that had multiple URLs are removed. Please review and validate your project settings respectively.

Changes to security

This section only applies to you if you were using the extra security on the remote protocol in the previous version of JRebel for Eclipse (or intend to start using it in the new version).

The previous keypair-based security is being replaced with a more straightforward, password based security measure. The new server-side JRebel agent is able to support both new and old security implementations.

The keypair-based security is switched on by having the public key in the deployed .war archive. Password-based security is switched on by executing the -set-remote-password command on the remote server. If either of the security methods is detected, the server is not accessible without security enabled by the other version of the protocol. For example, enabling the password on the server means that your colleagues with the old IDE plugin versions need to start connecting to the server with public-private key security enabled.

Please note that the transition from the old security implementation to the new one requires your explicit interaction. By default, security is just disabled on the IDE during the migration to JRebel for Eclipse 6.2.4 (the public key is removed from rebel-remote.xml).

In order to continue without the security (if you used it before), redeploy your .war so that the public key is removed on the server. Doing this will disable security for this project. If you didn't have public-private key security enabled before, skip the redeploy.

In order to switch over to the new security method, log on to the remote server and execute the following command:

$ java -jar jrebel.jar -set-remote-password

Make sure to use the same password in the IDE JRebel remote settings.