JRebel Reference Manual

©ZeroTurnaround OÜ, Estonia, Tartu


Prev  Home  Next
2. IDE Configuration 4. Server Configuration

3. Application Configuration

3.1 rebel.xml Basics
3.2 Eclipse
3.3 MyEclipse 9.1 or later
3.4 IntelliJ IDEA 8.x/9.x
3.5 IntelliJ IDEA X or later
3.6 NetBeans 7.x
3.7 Maven
3.8 rebel.xml Reference
3.8.1 <application>
3.8.2 <classpath>
3.8.3 <dir>
3.8.4 <dirset>
3.8.5 <jar>
3.8.6 <jarset>
3.8.7 <war>
3.8.8 <web>
3.8.9 <link>
3.8.10 <include>
3.8.11 <exclude>

3.1 rebel.xml Basics

JRebel maps your project workspace directly to a running application, watches for the changes you make to classes and resources, and intelligently reflects them in your application. In order for it to do that, JRebel needs to know where your classes and resources are. We use the rebel.xml configuration file to map your deployed project back to your workspace. This is mandatory when you deploy your app as a WAR/EAR. You'll need to have one rebel.xml file per each module. This includes both web and EJB modules.

The rebel.xml configuration file should end up in your WEB-INF/classes directory in the case of a web module and in the jar root in the case of an ejb module or a jar library. Put it in the root of a source or resource folder in your project (the same place where the .properties files are) and make sure it's copied to the target directory.

Configuring JARs

JARs are usually not deployed on their own, but as a part of application (e.g. WEB-INF/lib in WARs or EJB modules in EARs). However, often you still want to update their code on-the-fly. Let's assume that we have a module 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="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath> <dir name="c:\myWorkspace\myBusinessModule\target\classes"/>
<dir name="c:\myWorkspace\myBusinessModule\src\main\resources"/>
</classpath> </application>

This will mount classes and resources in directories c:\myWorkspace\myBusinessModule\target\classes and c:\myWorkspace\myBusinessModule\src\main\resources before the classes and resources in the JAR file. Changes to those classes and resources will propagate to the application.

Configuring WARs

In case of a web application you have web application resources, like JSPs, HTML files, graphic files and so on in addition to the classpath. To configure a web application deployed as a WAR file we create a rebel.xml file in the WEB-INF/classes directory:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.zeroturnaround.com" xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath> <dir name="c:\myWorkspace\myWar\target\classes"/>
<dir name="c:\myWorkspace\myWar\src\main\resources"/>
</classpath> <web> <link target="/">
<dir name="c:\myWorkspace\myWar\src\main\webapp"/>
</link> <link target="/jsps/">
<dir name="c:\myWorkspace\myWar\src\main\jsps"/>
</link> </web> </application>

This will mount classes and resources in directories c:\myWorkspace\myWar\target\classes and c:\myWorkspace\myWar\src\main\resources to the application classpath before the deployed classes and resources. This means that those classes and resources will override the ones in WEB-INF/classes and WEB-INF/lib/*.jar. Changes to those classes and resources will propagate to the application.

This will also map the web resources in the 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 may map several directories to one context target if necessary.

Configuring EARs

To configure a EAR you need to create a separate rebel.xml file for each EAR module. Web modules should be configured 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 and mount classes and resources that belong to the EAR as a whole.

Using Relative Paths

Putting absolute paths in the rebel.xml might be a bad idea as you'd like to share it with other team members. Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml to a property that you provide. You can set this property as a Java System property (-Dmyproject.root=c:/projects/) or in the JRebel Agent Configuration:


Tips and Tricks

3.2 Eclipse

Click on your project and pick Generate rebel.xml.



You need to generate one rebel.xml file per Eclipse project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and Eclipse will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.


(*) Put rebel.xml in the root of the src/main/resources folder for Maven projects.

The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to share it with other team members. Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml to a property that you provide. You can set this property as a Java System property (-Dmyproject.root=c:/projects/) or in the JRebel Agent Configuration:


If everyone on your team uses Eclipse and a similar workspace layout, you can even skip using a custom property as every application or server launched with JRebel for Eclipse will have the property rebel.workspace.path set to the Eclipse workspace location and you can use it as “${rebel.workspace.path}” in rebel.xml.

3.3 MyEclipse 9.1 or later

Click on your project and pick Generate rebel.xml.



You need to generate one rebel.xml file per Eclipse project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and Eclipse will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.


(*) Put rebel.xml in the root of the src/main/resources folder for Maven projects.

The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to share it with other team members. Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml to a property that you provide. You can set this property as a Java System property (-Dmyproject.root=c:/projects/) or in the JRebel Agent Configuration:


If everyone on your team uses Eclipse and a similar workspace layout, you can even skip using a custom property as every application or server launched with JRebel for Eclipse will have the property rebel.workspace.path set to the Eclipse workspace location and you can use it as “${rebel.workspace.path}” in rebel.xml.

3.4 IntelliJ IDEA 8.x/9.x

To generate the rebel.xml file right click on your project and pick Generate rebel.xml:

Generate rebel.xml

You need to generate one rebel.xml file per project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and your IDE will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.

(*) Put rebel.xml in the root of the src/main/resources folder for Maven projects.

The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to share it with other team members. Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml to a property that you provide. You can set this property as a Java System property (-Dmyproject.root=c:/projects/) or in the JRebel Agent Configuration:


3.5 IntelliJ IDEA X or later

To generate the rebel.xml file right click on your project and pick Generate rebel.xml:

Generate rebel.xml

You need to generate one rebel.xml file per project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and your IDE will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.

(*) Put rebel.xml in the root of the src/main/resources folder for Maven projects.

The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to share it with other team members. Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml to a property that you provide. You can set this property as a Java System property (-Dmyproject.root=c:/projects/) or in the JRebel Agent Configuration:


3.6 NetBeans 7.x



To generate the rebel.xml file right click on your project and pick Generate rebel.xml:

Generate rebel.xml

You need to generate one rebel.xml file per project in your workspace; this includes all Java projects, including Web and EJB projects. Put a rebel.xml in the root of a source folder(*) in each project, and your IDE will copy the rebel.xml file to the expected target folder when the project builds. For Web projects, JRebel expects to find the rebel.xml configuration file in the WEB-INF/classes directory in the target .war file. For EJB and Java projects, JRebel expects the rebel.xml file to be in the jar root.

The plugin generates the rebel.xml with absolute paths to your workspace. This might be a bad idea as you'd like to share it with other team members. Luckily JRebel will expand expressions like "${myproject.root}" in rebel.xml to a property that you provide. You can set this property as a Java System property (-Dmyproject.root=c:/projects/) or in the JRebel Agent Configuration:


3.7 Maven

Add the following snippet to your parent pom.xml. The rebel.xml configuration file will be generated for each individual sub-module of your maven project.

<plugin>
  <groupId>org.zeroturnaround</groupId>
  <artifactId>jrebel-maven-plugin</artifactId>
  <version>1.1.1</version>
  <executions>
    <execution>
      <id>generate-rebel-xml</id>
      <phase>process-resources</phase>
      <goals>
        <goal>generate</goal>
      </goals>
    </execution>
  </executions>
</plugin>

This will generate JRebel configuration file rebel.xml automatically on every build. If you want to generate the rebel.xml manually run mvn jrebel:generate -Drebel.xml.dir=OUTPUT_DIRECTORY (by default OUTPUT_DIRECTORY is target/classes). Adding -Drebel.generate.show=true will print out generated rebel.xml at info level, so you can immediately see what was generated.

By default, the generated rebel.xml contains absolute paths to your workspace. However if you want to deploy the artifacts for your team to use, you will need to make sure that the paths are relative using a configurable custom property.

Assuming that you have the following project structure in directory c:\projects\:

my-maven-project1
  my-jar1
  my-war1

You should add the following configuration to the plugin:

<configuration>
  <!--
    root is 2 directories up from the jar/war modules
  -->
  <relativePath>../../</relativePath>
  <!--
    use a custom property for specifying root directory (note the double $)
    set the property in JRebel configuration or as -Dmyproject.root=c:/projects/
  -->
  <rootPath>$${myproject.root}</rootPath>
</configuration>

Now you will have c:/projects/my-maven-project1/my-jar1/target/classes as ${myproject.root}/my-maven-project1/my-jar1/target/classes in the rebel.xml. You can set this property as a Java System property (-Dmyproject.root=c:/projects/) or in the JRebel Agent Configuration:

A sample maven plugin configuration with comments follows:

<plugin>
  <groupId>org.zeroturnaround</groupId>
  <artifactId>jrebel-maven-plugin</artifactId>
  <version>1.1.1</version>
  <configuration>
    <!--
     If your project uses custom packaging that is not recognized
     set this to jar or war.
     -->
    <packaging>war</packaging>
    <classpath>
      <fallback>default</fallback>
      <resources>
        <resource>
          <!--
            A relative path.
          -->
          <directory>target/special-classes
          </directory>
          <!--
            You may use includes and excludes as with any other
            resource.
          -->
          <includes>
            <include>com/yourapp/include/package1/**
            </include>
            <include>com/yourapp/include/package2/**
            </include>
          </includes>
          <excludes>
            <exclude>com/yourapp/exclude/package1/**
            </exclude>
            <exclude>com/yourapp/exclude/package2/**
            </exclude>
          </excludes>
        </resource>
        <resource>
          <!--
            Empty resource element marks default configuration. By
            default it is placed first in generated configuration.
          -->
        </resource>
        <resource>
          <!--
            An absoulte path is used here.
           -->
          <jar>c:\projects\myProject\3rdpartyLibs\myLibrary.jar
          </jar>
        </resource>
        <resource>
          <jarset>app/3rd-party-lib</jarset>
          <excludes>
            <exclude>apache*.jar</exclude>
          </excludes>
        </resource>
        <resource>
          <dirset>c:\projects\project1Root\
          </dirset>
          <excludes>
            <exclude>**\build\classes</exclude>
          </excludes>
        </resource>
      </resources>
    </classpath>

    <war>
      <path>c:\projects\myProject\dist\myProject.war
      </path>
    </war>

    <web>
      <resources>
        <resource>
          <target>gfx/</target>
          <directory>c:\projects\myProject\static\gfx
          </directory>
        </resource>
        <resource>
          <!--
            Empty resource element marks default configuration. By
            default it is placed first in generated configuration.
          -->
        </resource>
      </resources>
    </web>


    <!--
      addResourcesDirToRebelXml - default is false
      Required if the resource directories are to be added to rebel.xml
    -->
    <addResourcesDirToRebelXml>true</addResourcesDirToRebelXml>


    <!--
      alwaysGenerate - default is false
      If 'false' - rebel.xml is generated if timestamps of pom.xml and the current rebel.xml file are not equal.
      If 'true' - rebel.xml will always be generated
    -->
    <alwaysGenerate>true</alwaysGenerate>

  </configuration>
</plugin>

Also, maven has a notion of build profiles defined in your application's POM that you can leverage.

    <profiles>                                                     
      <profile>                                                    
        <id>jrebel</id>                               
        <activation>                                               
          <property>                                               
            <name>env</name>                          
            <value>jrebel</value>                     
          </property>                                              
        </activation>                                              
        <build>                                                    
          <plugins>                                                
            <plugin>                                               
              <groupId>org.zeroturnaround</groupId>        
              <artifactId>jrebel-maven-plugin</artifactId> 
              <executions>                                       
                <execution>                                      
                  <id>generate-rebel-xml</id>       
                  <phase>process-resources</phase>  
                  <goals>                                        
                    <goal>generate</goal>           
                  </goals>                                       
                </execution>                                     
              </executions>                                      
            </plugin>                                            
          </plugins>                                             
        </build>                                                 
      </profile>                                                 
    </profiles>                                                  

Executing the example above with mvn -Denv=jrebel clean installcommand will trigger JRebel plugin to generate rebel.xml.

3.8 rebel.xml Reference

Starting with JRebel 2.0 rebel.xml file must be used for web applications that use packaged deployment (i.e. WARs, JARs and EARs). Instead of the WAR/JAR/EAR file deployed all resources will be picked up from the locations provided in the rebel.xml. Also these directories and archives will be monitored for changes.

The rebel.xml must be placed in the WEB-INF/classes directory of the deployed WAR file, in a root directory of a JAR file or in the root of EJB JAR modules. A rebel.xml file should be provided per each module in the application that you want to change on-the-fly.

The contents of the rebel.xml is defined by the schema at http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd . There is a full example at the end of this file.

JRebel will expand expressions like "${myProject.root}" in rebel.xml to a system property that you can pass to the application container as -DmyProject.root=c:/myWorkspace/myProject. This allows to use a single configuration for everyone and then customize it when starting the server.

Tags reference

3.8.1 <application>

Top level tag that defines the configuration with classpath, web and war tags.
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
...
</application>

3.8.2 <classpath>

Defines the mounted classpath of the application with nested dir, dirset, jar and jarset elements. The fallback attribute controls if classes and resources are also found from the original application classpath (e.g. WEB-INF/classes, WEB-INF/lib/*.jar, JAR root, etc).

Attribute Description Required
fallback Values: all, none and default (default).
  • If set to all classes and resources will always be found from both the original and mounted classpath. This mode may cause some resources to appear double in the application.
  • If set to none classes and resources will only be found from the mounted classpath. This mode requires all classes and resources (including e.g. those in WEB-INF/lib/*.jar) to be fully mounted
  • If set to default then classes and resources will be found from both original and mounted classpath, but resources present in both will be filtered out. This mode implies that classes and resources in the path that rebel.xml is in are fully present in the mounted classpath (e.g. all classes and resources in WEB-INF/classes should be mounted if rebel.xml is there).
No
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
...
</classpath>
</application>

3.8.3 <dir>

Directory on the filesystem that is added to classpath or link. Nested include / exclude tags can be used to limit the files included from the specified directory.

Attribute Description  Required
name A full path to a directory on the filesystem.
Yes
includes Specifies a pattern that directs which resources will be included from the parent. No
excludes Specifies a pattern that directs which resources will be excluded from the parent. No
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
<!--
Add a directory with class files to the classpath. The classes
can also be excluded or included based on patterns.
-->
<dir name="c:\projects\myProject\classes\">
<!-- Including everything from com/yourapp/package1-->
<include name="com/yourapp/package1/**"/>
<!-- Exclude the unimportant subpackage of package1-->
<exclude name="com/yourapp/package1/unimportant/**"/>
</dir>
</classpath>
</application>

3.8.4 <dirset>

Defines multiple subdirectories of a directory that can be added to classpath. Nested include / exclude tags can be used to limit the subdirectories included from the specified directory.

Attribute Description Required
dir The parent directory from which subdirectories are found. By default all will be added.  Yes
includes Specifies a pattern that directs which resources will be included from the parent. No
excludes Specifies a pattern that directs which resources will be excluded from the parent. No
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
<!--
DIRSET enables you to add multiple directories to the classpath
without specifying them one-by-one. For example if there are multiple
MAVEN modules with a similar folder structure. The following configuration
will include all modules from the directory of "c:\projects\project1Root\
that adhere to the pattern "**\build\classes".
-->
<dirset dir="c:\projects\project1Root\">
<include name="**\build\classes"/>
</dirset>
</classpath>
</application>

3.8.5 <jar>

Defines a JAR file that is added to classpath or link. Nested include / exclude tags can be used to limit the resources included from the specified JAR.

Attribute Description Required
name Full path to a JAR file that is added to the CLASSPATH. Yes
includes Specifies a pattern that directs which resources will be included from the parent. No
excludes Specifies a pattern that directs which resources will be excluded from the parent. No
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
<!--
Adds a JAR file to the classpath. The classes from the
JAR archive can also be excluded or included based on patterns.
-->
<jar name="c:\projects\myProject\3rdpartyLibs\myLibrary.jar">
<!-- Including everything from com/yourapp/package1-->
<include name="com/yourapp/package1/**"/>
<!-- Exclude the unimportant subpackage of package1-->
<exclude name="com/yourapp/package1/unimportant/**"/>
</jar>
</classpath>
</application>

3.8.6 <jarset>

Defines multiple JAR files to be added to classpath. Nested include / exclude tags can be used to limit the JARS included from the specified directory.

Attribute Description Required
dir JAR files from this directory on the filesystem are added to the CLASSPATH Yes
includes Specifies a pattern that directs which resources will be included from the parent. No
excludes Specifies a pattern that directs which resources will be excluded from the parent. No
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<classpath>
<!--
JARSET enables you to add multiple JAR files to the classpath without
specifying them one-by-one. The following example includes JAR files
from the app/3rd-party-lib directory that don't match the pattern apache*.jar.
-->
<jarset dir="app/3rd-party-lib">
<exclude name="apache*.jar"/>
</jarset>
</classpath>
</application>

3.8.7 <war>

Overrides the WAR file deployed to the container with a exploded directory or a WAR file on the filesystem. Needs to have either dir or file attribute.

Attribute Description Required
dir Path to an exploded WAR directory on the filesystem. Resources and class files will be loaded from this directory.
Yes/No
file Path to a WAR archive on the filesystem. Resources and class files will be loaded from this file. Yes/No
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<!--
WAR tag with FILE attribute specifies the location of the WAR file.
The contents of this WAR file will have higher priority as compared
to the web application deployed. All resources in this file will be
available in the web application just as they would be in the
deployed WAR file.
-->
<war file="c:\projects\myProject\dist\myProject.war" />
</application>
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<!--
WAR tag with DIR attribute specifies the location of the exploded
directory. The contents of this directory will have higher priority
as compared to the web application deployed to the container. All
resources in this folder will be available in the web application
just as they would be in the deployed web application.
-->
<war dir="c:\projects\myProject\dist\war" />
</application>

3.8.8 <web>

Defines separate locations for static resources that can be referenced from the web application. With nested link tags it is possible to map different resources from the filesystem to the web context.

<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<!--
WEB tag defines separate locations for static resources that can be referenced from
the web application. Directories containing jsp, css, html, gif etc. files. These
directories can be mapped to arbitrary locations for the web application.
-->
<web>
...
</web>
</application>

3.8.9 <link>

Can be added to web to link a nested dir or jar to the target URI. The mapped resource is made available from servlet context and also via HTTP.

Attribute Description Required
target Mapping target. For example "gfx/" or "js/". Yes
<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">
<!--
WEB tag defines separate locations for static resources that can be referenced from
the web application. Directories containing jsp, css, html, gif etc. files. These
directories can be mapped to arbitrary locations for the web application.
-->
<web>
<!--
The location c:\projects\myProject\static\gfx will be accessible to the WEB
application as http://yourhost/webapp/gfx folder. Adding static resources to
that location will let you use them from your web application.
-->
<link target="gfx/">
<dir name="c:\projects\myProject\static\gfx"/>
</link>
</web>
</classpath>
</application>

3.8.10 <include>

This element is used to filter resources in dir, dirset, jar and jarset elements. Resources named by this element will be included in the result.

Attribute Description Required
name Name that will be filtered, can contain wildcards. See example for more information. Yes
<dirset dir="c:\projects\project1Root\">
<exclude name="**\build\classes"/>
</dirset>
...
<jarset dir="app/3rd-party-lib">
<exclude name="apache*.jar"/>
</jarset>
...
<jar name="c:\projects\myProject\3rdpartyLibs\myLibrary.jar">
<!-- Include all of package1-->
<include name="com/yourapp/package1/**"/>
<!-- Except for internal subpackage-->
<exclude name="com/yourapp/package1/internal/**"/>
</jar>

3.8.11 <exclude>

This element is used to filter resources in dir, dirset, jar and jarset elements. Resources named by this element will be excluded from the result.

Attribute Description Required
name Name that will be filtered, can contain wildcards. See example from include tag for more information. Yes

Example configuration

The following file can be copied to your project and appropriate sections deleted or customized.

<?xml version="1.0" encoding="ISO-8859-1"?>
<application
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://www.zeroturnaround.com"
xsi:schemaLocation="http://www.zeroturnaround.com http://www.zeroturnaround.com/alderaan/rebel-2_0.xsd">

<!--
Classpath allows you to add DIRECTORIES and JAR files to your classpath. Your
webapp will see these resources as resources inside the WAR archive or your
exploded directory.
The default value of fallback is true. When set to 'false' then if a resources
is NOT found from the defined directories, it won't be looked for from the
deployed resources.
Example. Fallback is set to FALSE and you remove a styles.css file. Even though
a styles.css file is deployed to the container, it will give a 404 on HTTP request
or null on ServletContext lookup even though it exists in the deployed archive.
If set to true, all resources will fallback to the deployed application, this is
the default behavior.
-->
<classpath fallback="default">
<!--
Add a directory with class files to the classpath. The classes
can also be excluded or included based on patterns.
-->
<dir name="c:\projects\myProject\classes\">
<!-- Only include package1 and its subpackages -->
<include name="com/yourapp/package1/**"/>
<!-- Except com/yourapp/package1/package2 and its subpackages -->
<exclude name="com/yourapp/package1/package2/**"/>
</dir>
<!--
Adds a JAR file to the classpath. The classes from the
JAR archive can also be excluded or included based on patterns.
-->
<jar name="c:\projects\myProject\3rdpartyLibs\myLibrary.jar">
<!-- Only include package1 and its subpackages -->
<include name="com/yourapp/package1/**"/>
<!-- Except com/yourapp/package1/package2 and its subpackages -->
<exclude name="com/yourapp/package1/package2/**"/>
</jar>
<!--
JARSET enables you to add multiple JAR files to the classpath without
specifying them one-by-one. The following example includes JAR files
from the c:\projects\3rd-party-lib directory that don't match the pattern apache*.jar.
-->
<jarset dir="c:\projects\3rd-party-lib">
<exclude name="apache*.jar"/>
</jarset>
<!--
DIRSET enables you to add multiple directories to the classpath
without specifying them one-by-one. For example if there are multiple
MAVEN modules with a similar folder structure. The following configuration
will include all modules from the directory of "c:\projects\project1Root\
that adhere to the pattern "**\build\classes".
-->
<dirset dir="c:\projects\project1Root\">
<exclude name="**\build\classes"/>
</dirset>
</classpath>
<!--
WAR tag with FILE attribute specifies the location of the WAR file. The contents
of this WAR file will have higher priority as compared to the web application deployed.
All resources in this file will be available in the web application just as they
would be in the deployed WAR file.
-->
<war file="c:\projects\myProject\dist\myProject.war" />

<!--
WAR tag with DIR attribute specifies the location of the exploded directory. The
contents of this directory will have higher priority as compared to the web application
deployed to the container. All resources in this folder will be available in the
web application just as they would be in the deployed web application.
-->
<war dir="c:\projects\myProject\dist\war"/>


<!--
WEB tag defines separate locations for static resources that can be referenced from
the web application. Directories containing jsp, css, html, gif etc. files. These
directories can be mapped to arbitrary locations for the web application.
-->
<web>
<!--
The location c:\projects\myProject\static\gfx will be accessible to the WEB
application as http://yourhost/webapp/gfx folder. Adding static resources to
that location will let you use them from your web application.
-->
<link target="gfx/">
<dir name="c:\projects\myProject\static\gfx"/>
</link>
<!--
The location c:\projects\jsProject\dist\js will be accessible to the WEB
application as http://yourhost/webapp/js folder. Adding static resources to
that location will let you use them from your web application.
-->
<link target="js/">
<dir name="c:\projects\jsProject\dist\js"/>
</link>
</web>
</application>

Prev  Home  Next
2. IDE Configuration 4. Server Configuration

JRebel Reference Manual, ©ZeroTurnaround OÜ, Estonia, Tartu