There are a number of advantages to this:
- caching of objects is shared between the backend and the web interface
- Tomcat no longer needs to be configured
- a single JVM
- considerably less memory usage
Note: There is a bug which exists in several of the OpenNMS v.1.12.x and v.1.13.x versions where making the modifications strictly in the opennms.properties file is insufficient. The work around to correct this is detailed in the instructions in the bug report (http://issues.opennms.org/browse/NMS-6629).
Jetty is enabled by default in opennms.properties, on port 8980:
org.opennms.netmgt.jetty.port = 8980 opennms.rtc-client.http-post.base-url = http://localhost:8980/opennms/rtc/post opennms.map-client.http-post.url = http://localhost:8980/opennms/map/post
If you wish to use an alternate port, edit
$OPENNMS_HOME/etc/opennms.properties and change or add the org.opennms.netmgt.jetty.port property, as well as the rtc-client and map-client URLs:
org.opennms.netmgt.jetty.port = 8080 opennms.rtc-client.http-post.base-url = http://localhost:8080/opennms/rtc/post opennms.map-client.http-post.url = http://localhost:8080/opennms/map/post
If you wish to disable Jetty altogether, edit the
$OPENNMS_HOME/etc/service-configuration.xml file and comment out the Jetty portion:
<!-- <service> <name>OpenNMS:Name=JettyServer</name> <class-name>org.opennms.netmgt.jetty.jmx.JettyServer</class-name> <invoke at="start" pass="0" method="init"/> <invoke at="start" pass="1" method="start"/> <invoke at="status" pass="0" method="status"/> <invoke at="stop" pass="0" method="stop"/> </service> -->
The webapp is still available for use by Tomcat (or any other servlet container) in
Advanced Configuration (1.3.7+ only)
If you currently run OpenNMS in a distributed configuration with the WebUI running under Tomcat on a say host "B" separated from the OpenNMS service daemons on say host "A", you can now do this without having to install Tomcat (can we say framework now? ;-)
1) Install OpenNMS on the host "B" and disable all the daemons in service-configuration.xml except the following: (Tomcat not required, ya!)
2) Disable the JettyServer service daemon on host "A" if desired (recommended). Also, change pg_hba.conf to allow remote connections from host "B".
3) Next, you'll need to adjust
$OPENNMS_HOME/etc/opennms.properties on host "B"
set this to the hostname or IP address of host "A"
set this URL to include the hostname or IP address and port host "B"
4) Next, you'll need to change
$OPENNMS_HOME/jetty-webapps/opennms/WEB-INF/configuration.properties and change the database connection properties to connect to the same PostgreSQL instance that host "A" uses.
5) Next, edit the
$OPENNMS_HOME/etc/c3p0.properties file and reduce the number of initial, min, and max connections from the default of 50 (required for the daemons) to 5.
6) Additionally, you'll need to NFS/SMB mount RRD repository from host "A" on to host "B" as well as a few of the
$OPENNMS_HOME/etc files (notifications.xml, notifd-configuration.xml, destinationPaths.xml, users.xml, groups.xml, magic-users.properties, javamail-configuration.properties, a few more... this will change SOON!). Make those mount points available to your $OPENNMS_HOME/etc and $OPENNMS_HOME/share/rrd directories (or wherever you have them configured) on host "B" (don't forget the NFS mount option "norootsquash" for the etc/ mount).
Now, RTCd on running on host "A" will post availability calculations to your Jetty instance on host "B" and your WebUI instance will be able to send events to the service daemons on host "A" via the TCP proxy. You'll also be able to view/edit configuration in the NFS mounted /etc and graph data from the NFS mounted RRD repository. Soon, NFS mounting will not be necessary.
Configuring the embedded JettyServer for HTTPS
Since release 1.3.11, the embedded Jetty server can be configured to provide an HTTPS listener with no external dependencies. For details, see Standalone HTTPS with Jetty.
Using Apache as an SSL front-end
Jetty startup problems
If jetty fails to show the expected pages when you try to login, and gives a 404 or 503 error, this can be caused by an error in one of the configuration files, especially etc/snmp-graph.properties (although as of version 1.11, that file should be less of a problem). The place to look is logs/daemon/output.log. Find the section where OpenNMS is starting, and that is where you will see any errors that jetty has encountered when it starts up. You don't see the name of the configuration file that has the problem, but you do see the contents that need correcting and that should help you determine what needs correcting.
Alternatively OpenNMS may not like the version of Java on your machine. Look in /var/log/opennms/webapp/jetty.log and you may see an error 'System property 'java.vm.name' does not contain a suitable JVM signature'. As it says in the error log, 'OpenNMS recommends the official Sun JVM. You can edit /usr/share/opennms/jetty-webapps/opennms/WEB-INF/web.xml and change the value for the 'dontBlameOpenNMS' context parameter from 'false' to 'true', but don't blame OpenNMS for any errors that occur without switching back to a supported JVM and setting the property back to 'false', first.'
java.lang.IllegalStateException: Form too large
If you hit this error in the webUI, you need to configure something like
in $OPENNMS_ROOT/etc/opennms.properties. Make sure the new value is larger than what the WebUI reported.
NOTE: In older versions of jetty (e.g. 5.1.11) this property was named org.mortbay.http.HttpRequest.maxFormContentSize and defaulted to 200000.