Some notes from looking into the jetty upgrade.
Our present structure is:
**bin/**shutdown.sh
**bin/**shutdown.bat
**bin/**startup.sh
**bin/**startup.bat
data_dir/
etc/ - mostly jetty configuration details like jetty-http.xml
lib/ - jetty jars
license/
logs/
modules/
**resources/**log4j.properties
webapps/geoserver/
start.ini
star.jar
Jetty out of the box structure is:
**bin/**jetty.sh
**bin/**jetty.service
demo-base/etc/
demo-base/lib/etc/
demo-base/resoruces/
demo-base/start.d/
demo-base/webapps/
etc/ - mostly jetty configuration details like jetty-http.xml
**jetty/**jetty.pid
lib/ - jetty jars, and a lot more optional things we do not use (like different ways to manage sessions in a clustered environment)
logs/
modules/
resources/
webapps/
start.ini
start.jar
jetty.state
Do we have any notes on when this was setup initially?
Notes:
- as I understand it you can define a “base” (like demo-base) to isolate your customizations from the jetty distribution used
- our startup.sh script is much more simple than jetty.sh, and contains some logic for GEOSERVER_DATA_DIR
- Checking the jetty.sh and jetty.bat scripts they adjust to be renamed, so the script will work if renamed to geoserver.sh
- Jetty manual recommends apache procrun daemon for windows (good to know)
Discussion:
- Should we use a default jetty structure to make it easier to update?
- Should we use jetty.base? I think this would be good to be really clear about isolating our customizations
- Can we use jetty.sh? probably we still need to figure out our own startup because of windows
···
–
Jody Garnett