The Web Extensible Display Manager leverages epics2web to view EDM screens on the web.
- Grab project
git clone https://github.com/JeffersonLab/wedm
cd wedm
- Launch Compose
docker compose up
- Navigate to example displays via web browser
- Install epics2web
- Download wedm.war and drop it into the Tomcat webapps directory
- Start Tomcat and navigate your web browser to localhost:8080/wedm
Use the environment varaible EPICS_2_WEB_HOST to specify the hostname (and optionally :port) of the epics2web server. If undefined, the same host as WEDM is assumed.
The environment variable EDL_DIR must be set to the canonical path to the directory containing your EDL files. This directory (and subdirectories) will be browsable in WEDM. If you want the demo EDL files on the overview page to work you need to download the demo files and place them inside your EDL_DIR directory at the subdirectory wedm. Demo files which require an EPICS monitor will need those PVs to exist (LOC PVs are used as much as possible to limit this). The demo files are intended to be used with the JLab colors.list.
The color palette file is located by searching the following locations in order:
- EDMCOLORFILE environment variable with an absolute path to a file
- EDMFILES environment variable with an absolute path to a directory containing the file "colors.list"
- Finally the default location of /etc/edm/colors.list
Similar to EDM, the environment variable EDMDATAFILES may be set to a colon-separated list of search paths.
For example, setting EDMDATAFILES=/main/sub1:/main/sub2 will result in searches for display files in the two
provided folders. When relative paths are encountered in an EDL file, the EDL_DIR path is searched first, then any additional paths specified in EDMDATAFILES are searched.
Some EDM installations share files across a site via a web server.
That way, clients running EDM do not need local or NFS-based file access,
but can access all *.edl files from a web server. WEDM will fetch edl files specified with an absolute HTTP or HTTPS URL, and alternatively can search for files specified with a relative path to a remote server.
Similar to EDM, the environment variable EDMHTTPDOCROOT allows WEDM to locate relatively-specified remote files via a web address. It has to be used in combination with an EDMDATAFILES search path, which might have only one / entry.
For example, assume EDMHTTPDOCROOT=http://www.webserver.com/edlfiles and
EDMDATAFILES=/main/sub1:/main/sub2.
Whenever WEDM is now trying to open a file x.edl, it will attempt to open
http://www.webserver.com/edlfiles/main/sub1/x.edl
followed by
http://www.webserver.com/edlfiles/main/sub2/x.edl,
using the order provided in the search path,
until it succeeds to find the file.
When EDMHTTPDOCROOT is defined, all complete URLs passed to WEDM via ...?edl=http:/...
must in fact start with the EDMHTTPDOCROOT. Other URLs will be rejected to prevent
network attacks which try to use the WEDM host to probe URL access.
Often it is convenient to ignore self-signed certificates. This can be done by defining the environment variable WEDM_DISABLE_CERTIFICATE_CHECK to any value.
EDM versions from 1-12-105J on (ca. June 2021) use this environment variable to enable support for relative path names:
EDMRELATIVEPATHS=yes
When relative paths are enabled, the names of embedded displays, images and links to related displays can be resolved relative to the display which contains them.
By default, WEDM will test access to each relative path and otherwise fall back to the search path. These access checks take considerable time. If a site uses relative path names and no longer relies on a search path, these checks can be disabled via
WEDM_DISABLE_RELATIVEPATHS_CHECK=yes
When both EDMRELATIVEPATHS and WEDM_DISABLE_RELATIVEPATHS_CHECK are set to yes,
all file references are assumed to be relative without checking access.
When proxying WEDM it is sometimes useful to have multiple instances accessible via the same host via separate context paths. In order to return correct links to resources an instance proxied with a namespacing prefix needs to be aware of the prefix. The environment variable CONTEXT_PREFIX does this. For example at Jefferson Lab we use a single proxy server for multiple departments each with their own instance of WEDM, and each configured with a prefix such as "/fel", "/chl", "/itf", and "/srf" ("/ops" uses default/empty prefix).
If the optional environment variable OTF_DIR is defined, then ShellCommand widgets with OTFLauncher commands will be honored if possible via a pregenerated screen cache found at the path indicated by the variable. The cache directory is expected to contain a file named edl.json which maps OTF shell commands to .edl files. The JLab On-The-Fly (OTF) EDM screens are used to automatically keep screens in sync with the accelerator configuration database and are usually generated dynamically at the time of invocation. A cache reduces latency when opening screens and a separate app invokes the generation commands such that WEDM continues to interface solely with EDM files on a filesystem.
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/wedm
cd wedm
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
- Bump the version number in the VERSION file and commit and push to GitHub (using Semantic Versioning).
- 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.
At JLab this app is found at epicsweb.jlab.org/wedm, plus other fiefdom specific subpaths, and internally at epicswebtest.acc.jlab.org/wedm. However, the epicsweb server is a proxy for epicswebops.acc.jlab.org, epicswebops2.acc.jlab.org, epicswebchl.acc.jlab.org, epicswebfel.acc.jlab.org, epicswebsrf.acc.jlab.org and epicswebitf.acc.jlab.org. Additionally, the context root for each is adjusted with a prefix such that all servers can be reached from a single namespace. The context root prefixes are /, /ops2, /chl, /fel, /srf, and /itf respectively. Tomcat interprets context roots from war file name unless overridden elsewhere. Therefore each war must be prefixed with <prefix>#. Use wget or the like to grab the release war file. Don't download directly into webapps dir as file scanner may attempt to deploy before fully downloaded. Be careful of previous war file as by default wget won't overrwite. The war file should be attached to each release, so right click it and copy location (or just update version in path provided in the example below). Example for chl fiefdom:
cd /tmp
rm wedm.war
wget https://github.com/JeffersonLab/wmenu/releases/download/v1.2.3/wedm.war
mv wedm.war chl#wedm.war
mv chl#wedm.war /usr/share/tomcat/webapps