<context-param>
<param-name>repose-config-directory</param-name>
<param-value>/etc/repose/</param-value>
</context-param>
<context-param>
<param-name>repose-cluster-id</param-name>
<param-value>cluster</param-value>
</context-param>
<context-param>
<param-name>repose-node-id</param-name>
<param-value>node</param-value>
</context-param>
Glassfish Setup
|
This version of the docs is a work in progress. If you don’t see what you are looking for check the legacy wiki. |
This page describes how to run the Repose WAR in a Glassfish container.
Make sure to install the Repose WAR first!
Configuration
Glassfish
Repose needs two parameters set in order to start with an optional third parameter to set the location of the config directory.
IN PROGRESS
Alternatively, the web.xml file within the war itself can be modified to include the following:
Repose
System Model
Repose can use internal dispatch (within the Glassfish container) to access your deployed WARs.
For example, if you had sample.war deployed, you could set the configured root-path to /sample and then access it as if it was on the root path (e.g., curl localhost:8080 would point to localhost:8080/sample/).
system-model.cfg.xml (partial)
<?xml version="1.0" encoding="UTF-8"?>
<system-model xmlns="http://docs.openrepose.org/repose/system-model/v2.0">
<repose-cluster id="repose">
...
<endpoint id="internal"
root-path="/sample"
default="true"/>
...
</repose-cluster>
</system-model>Testing
You can use curl or HTTPie to send a request to Glassfish.
Known Issues
JSON Bodies
If you are using any of the filters that can impact the body of your request or response, and that body is JSON, you may see unexpected behavior. This behavior stems from the fact that Glassfish ships with a different version of certain Jackson libraries than Repose, and the differing versions collide. Due to the way Java handles class loading, this can lead to weird cases where some of the classes are loaded from our newer version and some from Glassfish’s older version. This will cause `NoClassDefFoundException`s as it’s looking in the wrong spot for some classes. Glassfish does has a configuration to resolve this problem; this configuration tells Glassfish to not do the normal parent delegation of class loading, but to instead check the applications classpath first and then go up the parent classloader chain if it fails to find the needed classes. This requires the addition of the following glassfish-web.xml:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app>
<class-loader delegate="false"/>
</glassfish-web-app>For more information, see: here.