Configuring the rebel.xml configuration file is considered an advanced procedure. Our support engineers are standing by to help you with this at

Application configuration using rebel.xml

JRebel maps your project workspace directly to a running application. JRebel then monitors the changes you make to classes and resources – and intelligently reflects them in your application.

In order for this to happen, JRebel needs to know where your classes and resources are. For this purpose, JRebel uses the rebel.xml configuration file. This XML file maps your deployed project back to your workspace. This is obligatory when deploying your application as a WAR or EAR package. One rebel.xml configuration file needs to be present per module. This includes both web and EJB modules.

When using a JRebel IDE plugin, it is recommended to generate rebel.xml using the IDE plugin. We provide dedicated plugins for Maven and Gradle. Generating rebel.xml using the dedicated Maven and Gradle plugins is intended for situations when generation using the IDE plugin is not available.


The rebel.xml configuration file should end up in your WEB-INF/classes directory in case of a web module. In case of an EJB module or a JAR library, it should be in the root of the archive. Place it in the root of a source or resource folder in your project (the same place where .properties files are located) and make sure it is copied to the target directory.


JAR configuration

JARs are usually not deployed on their own, rather as a part of an application (e.g. WEB-INF/lib in WARs or EJB modules in EARs). You might still want to update their code on the fly. Let us assume that we have a module titled my-business-module.jar deployed in WEB-INF/lib. You can propagate the changes from your workspace by adding the following rebel.xml to the root of the JAR file:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="" xmlns="" xsi:schemaLocation="">

    <dir name="C:\myWorkspace\myBusinessModule\target\classes"/>


This will mount classes and resources in C:\myWorkspace\myBusinessModule\target\classes before the classes and resources in the JAR file. Changes to those classes and resources will then correctly propagate to the application.

WAR configuration

When working with web applications, resources like JSPs, HTML files, graphic files and so on need to be specified in addition to the classpath. To configure a web application deployed as a WAR file, let us create a rebel.xml file in the WEB-INF/classes directory:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="" xmlns="" xsi:schemaLocation="">

    <dir name="C:\myWorkspace\myWar\target\classes"/>

    <link target="/">
      <dir name="C:\myWorkspace\myWar\src\main\webapp"/>
    <link target="/jsps/">
      <dir name="C:\myWorkspace\myWar\src\main\jsps"/>


This XML will mount classes and resources in C:\myWorkspace\myWar\target\classes to the application classpath before the deployed classes and resources. These classes and resources override the ones in WEB-INF/classes and WEB-INF/lib/\*.jar. Changes to those classes and resources will propagate to the application.

Doing this will also map the web resources in C:\myWorkspace\myWar\src\main\webapp directory to the root (“/”) of the web application context and the web resources in C:\myWorkspace\myWar\src\main\jsps directory under the /jsps/ URI of the web application context. You can map multiple directories to a singular context target when necessary.

EAR configuration

To configure an EAR, you need to create a separate rebel.xml file for each EAR internal module (WARs and JARs). Web modules should be configured the same as individually deployed WARs, EJB modules should be configured same as JARs. If your container supports APP-INF/classes you may also add a rebel.xml to that folder. Then mount classes and resources that belong to the EAR as a whole.

Using relative paths

The configuration file rebel.xml supports using relative paths. This is useful for when you want to share your rebel.xml with the rest of your team. JRebel can expand rebel.xml expressions like ${myproject.root} to a property that you define yourself. This can be set as a Java system property: -Dmyproject.root=C:/projects/ or defined separately within {user.home}/.jrebel/

There are also special variables that can be used:

  • ${rebel.workspace.path} – Refers to the workspace root folder. Only applicable when using an IDE. In Eclipse, refers to true workspace root. In IntelliJ IDEA, refers to the project root folder. In NetBeans, refers to the parent folder of the current project.

  • ${rebel.project.path} – Refers to the project’s root folder. Only applicable when using remote server support and an IDE. Should not be used when running JRebel locally.


    This variable is not recommended for teams where multiple IDEs are used side by side.


  • You are not limited to mounting directories to classpath. You can also mount JARs with <jar>.
  • If you need to mount a lot of directories or JARs at once you can use <dirset> or <jarset> that accepts Ant-style patterns to specify the specific directories.
  • You can use Ant FileSet-style include and exclude directives in the <dir> and <jar> entries.

Per-project automatic path variables are also available when running your server from the IDE, if you are using Eclipse or IntelliJ IDEA. For a more in-depth overview of the rebel.xml configuration options, please refer to the configuration file reference chapter.