Skip to content

JeffersonLab/epics2web

Repository files navigation

epics2web Java CI with Gradle Docker

A gateway server and accompanying JavaScript client API to monitor EPICS Channel Access over the web.

MonitorTest



Overview

The epics2web application allows users to monitor EPICS PVs from the web using Web Sockets and a REST web service endpoint. The application leverages the Java JCA library and is designed to run on Apache Tomcat.

Quick Start with Compose

  1. Grab project
git clone https://github.com/JeffersonLab/epics2web
cd epics2web
  1. Launch Compose
docker compose up
  1. Monitor test PV via web browser

http://localhost:8080/epics2web/test-camonitor

PV name: HELLO

See: Docker Compose Strategy

Install

  1. Download Java 8+
  2. Download Apache Tomcat 7, 8, or 9
  3. Download epics2web.war and drop it into the Tomcat webapps directory
  4. Start Tomcat and navigate your web browser to localhost:8080/epics2web

Note: epics2web also works and was tested with GlassFish, and presumably works with WildFly or any other Java web application server that supports Web Sockets.

Note: The dependency jars are included in the war file that is generated by the build. You can copy the jar files from project lib directory to the Tomcat lib directory and change the build.gradle script to use providedCompile instead of implementation if you'd prefer to include the dependencies that way.

API

API Reference

Configure

This application uses the Java Channel Access library. It requires a working EPICS channel access environment with the environment variable EPICS_CA_ADDR_LIST set. See Also: Advanced Configuration.

Logging

This app is designed to run on Tomcat so Tomcat logging configuration applies. We use the built-in JVM logging library, which Tomcat uses with some slight modifications to support separate classloaders. In the past we bundled an application logging.properites inside the epics2web.war file. We no longer do that because it then appears to require repackaging/rebuilding a new version of the app to modify the logging config as the app bundled config overrides the global Tomcat config at conf/logging.properties. The recommend logging strategy is to now make configuration in the global Tomcat config so as to make it easy to modify logging levels. An app specific handler can be created. The global configuration location is generally set by the Tomcat default start script via JVM system properties. The system properties should look something like:

  • -Djava.util.logging.config.file=/usr/share/tomcat/conf/logging.properties
  • -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager

The contents of the logging.properties should be modfied to look something like:

handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 4host-manager.org.apache.juli.FileHandler, 5epics2web.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler

5epics2web.org.apache.juli.FileHandler.level = FINEST
5epics2web.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
5epics2web.org.apache.juli.FileHandler.prefix = epics2web.

org.jlab.epics2web.handlers = 5epics2web.org.apache.juli.FileHandler
org.jlab.epics2web.level = ALL

Note: This example is for older versions of Tomcat as newer version use an AsyncFileHandler. Refer to your logging configuration guide for your version of Tomcat.

Build

This project is built with Java 17 (compiled to Java 8 bytecode), and uses the Gradle 7 build tool to automatically download dependencies and build the project from source:

git clone https://github.com/JeffersonLab/epics2web
cd epics2web
gradlew build

Note: If you do not already have Gradle installed, it will be installed automatically by the wrapper script included in the source

Note for JLab On-Site Users: Jefferson Lab has an intercepting proxy

See: Docker Development Quick Reference

Test

docker compose -f build.yaml up

Wait for containers to start then:

gradlew integrationTest

Release

  1. Bump the version number in the VERSION file and commit and push to GitHub (using Semantic Versioning).
  2. The CD GitHub Action should run automatically invoking:
    • The Create release GitHub Action to tag the source and create release notes summarizing any pull requests. Edit the release notes to add any missing details. A war file artifact is attached to the release.
    • The Publish docker image GitHub Action to create a new demo Docker image.

See Also