This post applies to:
- Jetty version 9.4.6.v20170531
- Spring Boot 1.5.6.RELEASE
- Ubuntu 16.04.3 LTS
The problem
Running Spring Boot applications in Jetty environment as WARs is not as simple as the documentation states due to:
- Lack of documentation about installing Jetty (specified version) on Ubuntu (specified version) (some samples I used):
- Completely outdated/wrong Jetty installation instructions (https://www.eclipse.org/jetty/documentation/9.4.x/startup-unix-service.html)
The main requirement was to run some simple Spring Boot application that performs a scheduled task. The main problem was that after installing Jetty and deploying the WAR nothing happened…Ups!
The Resolution
Step 1
The Spring Boot application was using the following entry point:
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.support.SpringBootServletInitializer;
import org.springframework.context.annotation.Bean;
import org.springframework.scheduling.TaskScheduler;
import org.springframework.scheduling.annotation.EnableScheduling;
import org.springframework.scheduling.concurrent.ConcurrentTaskScheduler;
@SpringBootApplication
@EnableScheduling
public class SalusptApplication extends SpringBootServletInitializer {
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(SalusptApplication.class);
}
public static void main(String[] args) {
SpringApplication.run(SalusptApplication.class, args);
}
@Bean
public TaskScheduler taskScheduler() {
return new ConcurrentTaskScheduler();
}
}
At this point application started to run properly from IDE (STS) so it was the time to deploy it on Jetty: run mvn package and you obtain the WAR under two flavours:
- target<application>.WAR
- target<application>-original.war
The first one contains also the jars for running with embeded application server but you can safely deploy it.
Remark: Jetty was running as root since no JETTY_USER environment variable was defined yet.
Deployment looked successfull (no errors in logs) but nothing happened.
After some trial/error attempts it was quite obvious that configure method was not called so no chance for Spring Boot initialization process to be triggered. Nothing in official Spring Boot reference was mentioning about enabling anotations module on Jetty, of course we have had to be more attentive in our kindergarten Java courses…(I am a newbie in Spring/Jetty world, why not to find out things the hard way!)
Step 2
After enabling the annotation module another surprise…application still not working: I’ve got (by analysing logs) an error similar to the one described here: https://stackoverflow.com/questions/41995029/jersey-spring3–2–25–1-produces-failed-startup-of-context-error-in-jetty–9–3. Removing Jersey dependency in Maven pom.xml solved the problem (somehow, at some point in future I plan to have some REST API exposed to the world, fingers cross!)
Step 3
Without really understanding what I was doing at the phase of generatig the project scheleton through https://start.spring.io/ I added devtools to the project. Well, trying to deploy to Jetty the WAR I’ve got another error, something with not finding an entry point for restarting the application. Till restarting I neede a first proper start so…good by devtools.
Step 4
Now added JETTY_USER=jetty to /env/defaults/jetty
Another surprise…Jetty would not start. After another late night hours of trial and error attempts I noticed that if I change ownership of \run\jetty to user jetty the server starts and I can deploy the WAR. The problem was that after restrating the server the permissions on /run directory were lost.
Ok, time to analyze /etc/init.d/jetty. The short story (also described here: https://stackoverflow.com/questions/17999729/jetty-bash-script-works-only-with-root-user):
The evil hides behind the following snippet:
if [ -z "$JETTY_RUN" ]
then
JETTY_RUN=$(findDirectory -w /var/run /usr/var/run $JETTY_BASE /tmp)/jetty
[ -d "$JETTY_RUN" ] || mkdir $JETTY_RUN
fi
If no JETTY_RUN environment variable is defined the script attempts to build a base one and appends jetty to it; so the directory is created (surprise) under root account and later attempt to start jetty (start-stop-daemon -S -p"$JETTY_PID" $CH_USER -d"$JETTY_BASE" -b -m -a "$JAVA" -- "${RUN_ARGS[@]}" start-log-file="$JETTY_START_LOG") with JETTY_START_LOG="$JETTY_RUN/$NAME-start.log" will fail since jetty user will not be able to create the log file.
The solution was to pre-define the JETTY_RUN environment variable pointing to a directory where jetty is owner.
Appendix
Full Jetty installation steps
Java 8
sudo -i
Run one by one the following commands;watch out for capitalized Y on answers.
apt install software-properties-common
add-apt-repository ppa:webupd8team/java
apt-get update
apt-get install oracle-java8-installer
#apt-get install oracle-java8-set-default
Download and install Jetty
sudo -i
mkdir -p /opt/jetty
mkdir -p /opt/web/jettybase
mkdir /opt/web/jettybase/run
mkdir -p /opt/jetty/temp
useradd --user-group --shell /bin/false --home-dir /opt/jetty/temp jetty
chown -R jetty:jetty /opt/jetty
chown -R jetty:jetty /opt/web/jettybase
chown -R jetty:jetty /opt/jetty/temp
cd /tmp
wget http://central.maven.org/maven2/org/eclipse/jetty/jetty-distribution/9.4.6.v20170531/jetty-distribution-9.4.6.v20170531.tar.gz
cd /opt/jetty
tar -zxf /tmp/jetty-distribution-9.4.6.v20170531.tar.gz
cd /opt/jetty/jetty-distribution-9.4.6.v20170531
cp bin/jetty.sh /etc/init.d/jetty
cd /opt/web/jettybase
java -jar /opt/jetty/jetty-distribution-9.4.6.v20170531/start.jar --add-to-start=deploy,http,console-capture,annotations
#configures Java for debug, must be removed from production environmemnts
echo "JETTY_HOME=/opt/jetty/jetty-distribution-9.4.6.v20170531" > /etc/default/jetty
echo "JETTY_BASE=/opt/web/jettybase" >> /etc/default/jetty
echo "JETTY_RUN=/opt/web/jettybase/run" >> /etc/default/jetty
echo "TMPDIR=/opt/jetty/temp" >> /etc/default/jetty
echo "JAVA_OPTIONS=\"-Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=n\"" >> /etc/default/jetty
echo "JETTY_USER=jetty" >> /etc/default/jetty
service jetty check
update-rc.d jetty defaults
service jetty start
service jetty status
# if service not starting check all involved directories that jetty user is owner
# just for development, in order to be able to copy files through WinSCP:
chmod o+w /opt/web/jettybase/webapps
How Spring Boot Bootsrap Should Work
See also http://piotrnowicki.com/2011/03/using-servlets–3–0-servletcontainerinitializer/
The >=3.0 Servlet Container (Jetty in our case) will try (if annotations module is activated!) to find in class path all implementations of javax.servlet.ServletContainerInitializer and will call its onStartup method with a Set of all implementations of the @HandlesTypes mentioned class:
package org.springframework.web;
...
@HandlesTypes(WebApplicationInitializer.class)
public class SpringServletContainerInitializer implements ServletContainerInitializer {
/**
* Delegate the {@code ServletContext} to any {@link WebApplicationInitializer}
* implementations present on the application classpath.
* <p>Because this class declares @{@code HandlesTypes(WebApplicationInitializer.class)},
* Servlet 3.0+ containers will automatically scan the classpath for implementations
* of Spring's {@code WebApplicationInitializer} interface and provide the set of all
* such types to the {@code webAppInitializerClasses} parameter of this method.
* <p>If no {@code WebApplicationInitializer} implementations are found on the classpath,
* this method is effectively a no-op. An INFO-level log message will be issued notifying
* the user that the {@code ServletContainerInitializer} has indeed been invoked but that
* no {@code WebApplicationInitializer} implementations were found.
* <p>Assuming that one or more {@code WebApplicationInitializer} types are detected,
* they will be instantiated (and <em>sorted</em> if the @{@link
* org.springframework.core.annotation.Order @Order} annotation is present or
* the {@link org.springframework.core.Ordered Ordered} interface has been
* implemented). Then the {@link WebApplicationInitializer#onStartup(ServletContext)}
* method will be invoked on each instance, delegating the {@code ServletContext} such
* that each instance may register and configure servlets such as Spring's
* {@code DispatcherServlet}, listeners such as Spring's {@code ContextLoaderListener},
* or any other Servlet API componentry such as filters.
* @param webAppInitializerClasses all implementations of
* {@link WebApplicationInitializer} found on the application classpath
* @param servletContext the servlet context to be initialized
* @see WebApplicationInitializer#onStartup(ServletContext)
* @see AnnotationAwareOrderComparator
*/
@Override
public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
throws ServletException {
List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
if (webAppInitializerClasses != null) {
for (Class<?> waiClass : webAppInitializerClasses) {
// Be defensive: Some servlet containers provide us with invalid classes,
// no matter what @HandlesTypes says...
...
