Formerly the location of the Docker official image for Jetty
Home Page: https://registry.hub.docker.com/_/jetty/
This was the Git repo of the official Docker image for jetty.
This project was started and maintained by Appropriate Computing but has now been moved to co-reside with the Jetty project at Eclipse. The new respoitory can now be found at eclipse/jetty.docker.
Hi, I'm looking to enable docker containers for packages like jetty for multiple architectures on dockerhub, starting off with a focus on ppc64le. Wanted to check on the work that will be involved to do that
I have locally been able to successfully test ppc64le changes to the dockerfiles in this repo - changes for enabling additional arch would be minimum.
Would like to know how a multi-arch image for this can be initiated? The official images have this method for enabling multi-arch : https://github.com/docker-library/official-images#multiple-architectures, however this repo isnt an official image yet. Would the first step be to make this an official image or are there any other ways the dockerhub jetty image can be enabled for ppc64le?
The java image is being deprecated in favor of openjdk. We should switch the base image for jetty to be FROM openjdk. The java image will no longer receive updates after December 2016. See docker-library/official-images#2046 and docker-library/docs#660
When a webapp tries to render text (for example, while generating a chart with JFreeChart, PDFs etc.), a NPE is thrown:
java.lang.NullPointerException
at sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
at sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:219)
at sun.awt.FontConfiguration.init(FontConfiguration.java:107)
at sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:776)
at sun.font.SunFontManager$2.run(SunFontManager.java:431)
at java.security.AccessController.doPrivileged(Native Method)
at sun.font.SunFontManager.<init>(SunFontManager.java:376)
at sun.awt.X11FontManager.<init>(X11FontManager.java:57)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at java.lang.Class.newInstance(Class.java:442)
at sun.font.FontManagerFactory$1.run(FontManagerFactory.java:83)
at java.security.AccessController.doPrivileged(Native Method)
at sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
at sun.font.SunFontManager.getInstance(SunFontManager.java:250)
at sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:264)
at sun.java2d.SunGraphics2D.getFontMetrics(SunGraphics2D.java:855)
at org.jfree.text.G2TextMeasurer.getStringWidth(G2TextMeasurer.java:79)
at org.jfree.text.TextUtilities.nextLineBreak(TextUtilities.java:306)
at org.jfree.text.TextUtilities.createTextBlock(TextUtilities.java:247)
at org.jfree.chart.title.TextTitle.arrangeRR(TextTitle.java:628)
at org.jfree.chart.title.TextTitle.arrange(TextTitle.java:496)
at org.jfree.chart.JFreeChart.drawTitle(JFreeChart.java:1311)
at org.jfree.chart.JFreeChart.draw(JFreeChart.java:1203)
at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1399)
at org.jfree.chart.JFreeChart.createBufferedImage(JFreeChart.java:1379)
at org.jfree.chart.ChartUtilities.writeChartAsPNG(ChartUtilities.java:184)
at org.jfree.chart.ChartUtilities.writeChartAsPNG(ChartUtilities.java:138)
at my.awttest.AwtTestServlet.renderChart(AwtTestServlet.java:49)
at my.awttest.AwtTestServlet.doGet(AwtTestServlet.java:28)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:816)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:583)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:548)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:226)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1114)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:511)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1048)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:213)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:119)
at org.eclipse.jetty.server.Server.handle(Server.java:517)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:302)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:242)
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:245)
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95)
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:75)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceAndRun(ExecuteProduceConsume.java:213)
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:147)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:654)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:572)
at java.lang.Thread.run(Thread.java:745)
This happens because the underlying JRE is the openjdk-8-jre-headless Debian package. The exception goes away when I add the fontconfig package to the image. [1]
I'd also suggest to set the default JAVA_OPTIONS to -Djava.awt.headless=true instead of leaving it blank. While that's not strictly necessary, it probably makes sense to tell any running app not to create dialogs etc. [2]
Current jetty images leaves the default home for the jetty user (i.e. /home/jetty) which might lead to various errors when building a custom image from it.
The error is easy to reproduce :
[urli@vivat ~]$ docker run -it jetty:latest /bin/bash
jetty@c48a79115c75:/var/lib/jetty$ cd
bash: cd: /home/jetty: No such file or directory
Now that @gregw is helping maintain this image, we should update the LICENSE to correctly reflect the copyright situation (I'm sure that would make some lawyers at the Eclipse Project happy). I also noticed we don't have MAINTAINER in the Dockerfile, so that should be added as well.
See docker-library/official-images#1420 for an example of the current best-practice for GPG verification.
This should mostly just point at the main Jetty documentation on the subject, but it would probably be good to add some information about how to set up the keystore for the Docker image/container.
Hi, I have a problem getting access logs using logback. I was able to correctly get application logs by adding my logback.xml to $JETTY_BASE/resources.
Added logback-access.xml to $JETTY_BASE/resources and also added logback-access to "--modules"
Any help is appreciated.
The start module documentation needs to be updated to describe:
The usage.txt file has been updated, but not the main documentation.
Is there a way to configure Java heap, or how to pass custom flags to the java VM?
As of docker-library/openjdk#121, the openjdk base image supports additional architectures where the JRE is available on the given base OS. In practice, this means amd64, arm32v7, arm64v8, i386, ppc64le, and s390x for JRE 7 and 8, as well as amd64 for JRE 8 on Windows.
To the extent possible, I think we should have variants of the jetty image for these additional platforms and architectures.
How to access Jetty running in Docker from LAN? I run jetty in ubuntu 14.04 and tried all sorts of things but no luck , my jetty server runs locally but not accessible from my machine.
I am experiencing a intemitent problem when a start a jetty container: Instead of keep server running the container exits with code 0.
Docker logs shows this message:
2018-06-29 22:42:57.000:INFO:docker-entrypoint:jetty start from /var/lib/jetty/jetty.start
Investigating the docker-entrypoint.sh I've discovery that the only point where this message is displayed is inside a if block that checks the existence of the jetty.start file, and in that case, execute the contents of it. But the problem is that there is no coding creating this file.
I'am using a Ubuntu 16.04 virtualbox machine, the problem only occours in the fist time docker is called in that VM. The container that is created with this error condition will never start again, but if I try "docker run" again the new container created works perfectly.
If I destroy the VM and recreate it (I am using Vagrant and Puppet to recreate the machine and install docker every time) the problem may occour again. I've destroyed the VM 10 times, in 6 times the container did not start, because of this problem: A empty jetty.start file and the message above in the docker logs.
I've encounter this problem with a Docker file I've build from the "jetty:9.4-jre8" and with the "jetty:9.4-jre8" image itself.
I've found the empty jetty.start file because I've copied the /var/lib/jetty folder from the container that did not started to a folder, and check it's contents.
Anyone has any idea of how this could happen? I've checked the docker-entrypoint,sh several times, and does not make any sense, this is the part when it checks the existance of the file and log the message thai is appearing to me in docker logs:
if [ -f $JETTY_START ] ; then
if [ $JETTY_BASE/start.d -nt $JETTY_START ] ; then
cat >&2 <<- EOWARN
********************************************************************
WARNING: The $JETTY_BASE/start.d directory has been modified since
the $JETTY_START files was generated. Either delete
the $JETTY_START file or re-run
/generate-jetty.start.sh
from a Dockerfile
********************************************************************
EOWARN
fi
echo $(date +'%Y-%m-%d %H:%M:%S.000'):INFO:docker-entrypoint:jetty start from $JETTY_START
set -- $(cat $JETTY_START)
else
Any help would be appreciated. Thanks!
Output of "docker logs" after trying "docker start" 3 times:
2018-06-29 15:54:02.000:INFO:docker-entrypoint:jetty start from /var/lib/jetty/jetty.start
2018-06-29 17:47:01.000:INFO:docker-entrypoint:jetty start from /var/lib/jetty/jetty.start
2018-06-29 22:42:57.000:INFO:docker-entrypoint:jetty start from /var/lib/jetty/jetty.start
Checking the "/var/lib/docker/aufs/diff" I could find the layer where the empty file was introcuced with the command:
root@puppet-PC57-120:/var/lib/docker/aufs/diff# find -name jetty.start`
Output:
./8df891c9347e500e9c48a7228dc538633210e759746a5f22eb8172921652111d/var/lib/jetty/jetty.start
Listing the contents of this layer:
root@puppet-PC57-120:/var/lib/docker/aufs/diff/8df891c9347e500e9c48a7228dc538633210e759746a5f22eb8172921652111d# tree
.
├── tmp
│ └── hsperfdata_jetty
│ └── 9
└── var
└── lib
└── jetty
├── jetty.start
└── logs
6 directories, 2 files
Docker history of the image:
IMAGE CREATED CREATED BY SIZE COMMENT
d0a341de0d9e 8 weeks ago /bin/sh -c #(nop) CMD ["java" "-jar" "/us... 0B
<missing> 8 weeks ago /bin/sh -c #(nop) EXPOSE 8080/tcp 0B
<missing> 8 weeks ago /bin/sh -c #(nop) USER [jetty] 0B
<missing> 8 weeks ago /bin/sh -c #(nop) COPY file:d462f1618b7d60... 82.6MB
<missing> 8 weeks ago rm -r /var/lib/jetty/webapps 0B
<missing> 2 months ago /bin/sh -c #(nop) HEALTHCHECK &{["CMD-SHE... 0B
<missing> 2 months ago /bin/sh -c #(nop) MAINTAINER TI Quantum <... 0B
<missing> 3 months ago /bin/sh -c #(nop) CMD ["java" "-jar" "/us... 0B
<missing> 3 months ago /bin/sh -c #(nop) ENTRYPOINT ["/docker-en... 0B
<missing> 3 months ago /bin/sh -c #(nop) EXPOSE 8080/tcp 0B
<missing> 3 months ago /bin/sh -c #(nop) USER [jetty] 0B
<missing> 3 months ago /bin/sh -c #(nop) COPY multi:4510ce2f7fb95... 3.26kB
<missing> 3 months ago /bin/sh -c set -xe && mkdir -p "$TMPDIR" ... 0B
<missing> 3 months ago /bin/sh -c #(nop) ENV TMPDIR=/tmp/jetty 0B
<missing> 3 months ago /bin/sh -c set -xe && java -jar "$JETTY_H... 4.75kB
<missing> 3 months ago /bin/sh -c #(nop) WORKDIR /var/lib/jetty 0B
<missing> 3 months ago /bin/sh -c mkdir -p "$JETTY_BASE" 0B
<missing> 3 months ago /bin/sh -c #(nop) ENV JETTY_BASE=/var/lib... 0B
<missing> 3 months ago /bin/sh -c set -xe && curl -SL "$JETTY_TG... 9.69MB
<missing> 3 months ago /bin/sh -c #(nop) ENV JETTY_GPG_KEYS=AED5... 0B
<missing> 3 months ago /bin/sh -c #(nop) ENV JETTY_TGZ_URL=https... 0B
<missing> 3 months ago /bin/sh -c #(nop) ENV JETTY_VERSION=9.4.9... 0B
<missing> 3 months ago /bin/sh -c #(nop) WORKDIR /usr/local/jetty 0B
<missing> 3 months ago /bin/sh -c mkdir -p "$JETTY_HOME" 0B
<missing> 3 months ago /bin/sh -c #(nop) ENV PATH=/usr/local/jet... 0B
<missing> 3 months ago /bin/sh -c #(nop) ENV JETTY_HOME=/usr/loc... 0B
<missing> 3 months ago /bin/sh -c groupadd -r jetty && useradd -r... 329kB
<missing> 3 months ago /bin/sh -c /var/lib/dpkg/info/ca-certifica... 394kB
<missing> 3 months ago /bin/sh -c set -ex; if [ ! -d /usr/share... 393MB
<missing> 3 months ago /bin/sh -c #(nop) ENV CA_CERTIFICATES_JAV... 0B
<missing> 3 months ago /bin/sh -c #(nop) ENV JAVA_DEBIAN_VERSION... 0B
<missing> 3 months ago /bin/sh -c #(nop) ENV JAVA_VERSION=8u162 0B
<missing> 3 months ago /bin/sh -c #(nop) ENV JAVA_HOME=/docker-j... 0B
<missing> 3 months ago /bin/sh -c ln -svT "/usr/lib/jvm/java-8-op... 33B
<missing> 3 months ago /bin/sh -c { echo '#!/bin/sh'; echo 's... 87B
<missing> 3 months ago /bin/sh -c #(nop) ENV LANG=C.UTF-8 0B
<missing> 3 months ago /bin/sh -c apt-get update && apt-get insta... 2.05MB
<missing> 3 months ago /bin/sh -c set -ex; if ! command -v gpg >... 7.8MB
<missing> 3 months ago /bin/sh -c apt-get update && apt-get insta... 23.8MB
<missing> 3 months ago /bin/sh -c #(nop) CMD ["bash"] 0B
<missing> 3 months ago /bin/sh -c #(nop) ADD file:b380df301ccb5ca... 100MB
Dockerfile beeing used:
FROM jetty:9.4-jre8
HEALTHCHECK --interval=30s --timeout=3s --start-period=10m \
CMD curl -f http://localhost:8080/health
RUN ["rm","-r","/var/lib/jetty/webapps"]
COPY target/servico.calculo.war /var/lib/jetty/webapps/ROOT.war
USER jetty
EXPOSE 8080
CMD ["java","-jar","/usr/local/jetty/start.jar"]
Hi,
Jetty's start-time can be decreased by bypassing start.jar.
Please add this improvement to the docker-jetty images.
setuid usage requires native libraries that reduces the architectures that can be supported out of the box. We should avoid setuid and document how it can be used if desired. (see discussion in #68)
i success install the jetty docker
docker run -d -p 8888:8080 jetty:9
but when try to access to ip:8080, it wont work
any idea?
I'm trying to configure mongo (running on the docker host) as a session manager for jetty, but if fails because it cannot connect. Does anybody have a working example of how this can be achieved?
I'm getting this exception:
java.io.IOException: couldn't connect to [/127.0.0.1:27017] bc:java.net.ConnectException: Connection refused (Connection refused)
at com.mongodb.DBPort._open(DBPort.java:206)
at com.mongodb.DBPort.go(DBPort.java:94)
at com.mongodb.DBPort.go(DBPort.java:75)
at com.mongodb.DBPort.findOne(DBPort.java:129)
at com.mongodb.DBPort.runCommand(DBPort.java:138)
at com.mongodb.DBTCPConnector.fetchMaxBsonObjectSize(DBTCPConnector.java:414)
at com.mongodb.Mongo.getMaxBsonObjectSize(Mongo.java:537)
at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:237)
at com.mongodb.DBApiLayer$MyCollection.createIndex(DBApiLayer.java:347)
at org.eclipse.jetty.nosql.mongodb.MongoSessionIdManager.<init>(MongoSessionIdManager.java:187)
at org.eclipse.jetty.nosql.mongodb.MongoSessionIdManager.<init>(MongoSessionIdManager.java:175)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.eclipse.jetty.util.TypeUtil.construct(TypeUtil.java:580)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:793)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1239)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1144)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.set(XmlConfiguration.java:466)
at org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:411)
I actually try to overwrite the config like that in my Dockerfile:
FROM jetty:9.3-jre8-alpine
EXPOSE 8080
ADD /target/myapplication.war /var/lib/jetty/webapps/ROOT.war
RUN mkdir -p /var/lib/jetty/config/
ADD /jetty.xml /var/lib/jetty/jetty.xml
RUN java -jar "$JETTY_HOME/start.jar" --add-to-startd=nosql --approve-all-licenses
CMD ["java","-Djava.io.tmpdir=/tmp/jetty","-jar","/usr/local/jetty/start.jar", "--debug", "/var/lib/jetty/jetty.xml"]
It seems that the config done in /var/lib/jetty/jetty.xml is ignored, where I set the ServerAddress to a different host. Any pointers?
jetty:alpine latest version (JETTY_VERSION=9.4.18.v20190429) is including sqlite (used in sqlite-libs) as a dependency, and this version has 2 security vulnerabilities causing docker images that use jetty:alpine as base image to be flagged by container registry vulnerability scans.
Both vulnerabilities have been fixed in sqlite 3.28.0-r0.
Can sqlite 3.28.0-r0 be included to avoid these 2 vulnerabilities ?
thanks
Seeing below error:
java.lang.IllegalStateException: Cannot read file: modules/alpn-impl/alpn-1.8.0_191.mod
at org.eclipse.jetty.start.Modules.registerModule(Modules.java:202)
at org.eclipse.jetty.start.Modules.enable(Modules.java:355)
at org.eclipse.jetty.start.Modules.enable(Modules.java:360)
at org.eclipse.jetty.start.Modules.enable(Modules.java:377)
at org.eclipse.jetty.start.Modules.enable(Modules.java:377)
at org.eclipse.jetty.start.Modules.enable(Modules.java:286)
at org.eclipse.jetty.start.BaseBuilder.build(BaseBuilder.java:129)
at org.eclipse.jetty.start.Main.start(Main.java:435)
at org.eclipse.jetty.start.Main.main(Main.java:77)
When are we expecting 9.4.13 to be released
As the title. Are there plans for docker-jetty on jre 11 ?
I'm trying to use jetty to deploy a 1.7 war file. My Dockerfile has only this:
FROM jetty:jre7
ADD target/match-rules.war /var/lib/jetty/webapps/
The docker container starts
95fcb5134f70 matchbox/nci-match-rules "/docker-entrypoint.s" 15 seconds ago Up 14 seconds 0.0.0.0:8080->8080/tcp, 0.0.0.0:10250->10250/tcp Rules
Is this correct or should I copy the CMD line from the jetty Dockerfile as well? I'm having a problem with the war extraction, but it might be unrelated to the Docker usage.
2016-06-20 15:02:21.631:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/var/lib/jetty/webapps/] at interval 1
2016-06-20 15:02:29.313:WARN:oejw.StandardDescriptorProcessor:main: Could not instantiate listener org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap
java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
...
2016-06-20 15:02:29.687:INFO:nci-match-rules:main: No Spring WebApplicationInitializer types detected on classpath
15:02:29,773 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
15:02:29,773 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
I just noticed that there are 9.4.0.M0 and 9.3.10.M0 versions of Jetty after seeing a comment from @joakime on #30. I also recall @jmcc0nn3ll commenting that Jetty 9.2 is considered EOL (see here).
I wanted to open this issue in anticipation of the update to Jetty 9.4 to see which versions we should actually support.
When the command includes JDWT session, I get exit 0 when running docker-compose up, if the JDWT settings are removed then everything works fine. Any ideas?
Jetty version:
2018-01-10 23:35:09.811:INFO:oejs.Server:main: jetty-9.4.7.v20170914
This is the error message
$ docker-compose logs -f
Attaching to retail-processor
retail-processor | Listening for transport dt_socket at address: 9999
retail-processor exited with code 0
my docker-compose.yml file looks like this:
version: "3" services: retail-processor: build : . container_name: retail-processor command: "java -Xms125m -Xmx375m -Djava.io.tmpdir=/tmp/jetty -Xdebug -agentlib:jdwp=transport=dt_socket,address=9999,server=y,suspend=n -jar /usr/local/jetty/start.jar -Djetty.http.port=8080" ports: - "8080:8080" - "9999:9999" volumes: - ./build/libs/:/var/lib/jetty/webapps environment: - USE_IN_MEMORY_DB=false - CONNECTION_POOL_MAX_SIZE=10 - CONNECTION_POOL_IDLE_TIMEOUT=30000 - SPAN_SECONDS_DELAY=1 - TERM=xterm
Currently there's no tag for version 9.4 of Jetty.
Specific image ID: 1dc9280cc083
Jetty starts, and the contexts appear to come up. However, all attempts to access them via SSL fail as follows. Yes, the port is exposed and not firewalled etc - this happens even via localhost.
EDIT: confirmed. 8u181-b13-1~deb9u1 works, 8u181-b13-2~deb9u1 BREAKS, 8u212-b01-1~deb9u1 works again (caveat: have to add an alpn-impl pointing at alpn-boot-8.1.13.v20181017)
draeath@ginnungagap:~/scratch$ curl --insecure --ciphers ALL -I -v https://REDACTED:44420/cas
* Trying REDACTED...
* TCP_NODELAY set
* Connected to REDACTED (REDACTED) port 44420 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to REDACTED:44420
* Curl_http_done: called premature == 1
* stopped the pause stream!
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to REDACTED:44420
Note if I leave the ciphers parameter off, the defaults fail in the same way.
Packet capture shows:
-> SYN
<- SYN,ACK
-> ACK
-> TLSv1 Client Hello
<- ACK
<- FIN, ACK
-> FIN, ACK
<- ACK
There is no log, STDOUT, or STDERR emissions from Jetty when this occurs.
Digging around, I discovered the following. I have an older build of this software that's working fine. I performed a docker container export of both the old build and the new one (which fails), and did a recursive diff between. Ignoring binary differences, I found the following differences, and only the following differences, presumably from upstream openjdk:8-jre
7.52.1-5+deb9u6 to 7.52.1-5+deb9u78u181-b13-1~deb9u1 to 8u181-b13-2~deb9u1Debian package changelogs for these show the curl change seems unrelated:
curl (7.52.1-5+deb9u7) stretch-security; urgency=high
* Fix NTLM password overflow via integer overflow as per CVE-2018-14618
https://curl.haxx.se/docs/CVE-2018-14618.html
-- Alessandro Ghedini <[email protected]> Mon, 03 Sep 2018 23:50:29 +0100
However the java changelog seems particularly relevant:
openjdk-8 (8u181-b13-2) unstable; urgency=high
[ Tiago Stürmer Daitx ]
* Apply patches from 8u191-b12 security update.
- CVE-2018-3136, S8194534: Manifest better support.
- CVE-2018-3139, S8196902: Better HTTP Redirection.
- CVE-2018-3149, S8199177: Enhance JNDI lookups.
- CVE-2018-3169, S8199226: Improve field accesses.
- CVE-2018-3180, S8202613: Improve TLS connections stability.
- CVE-2018-3183, S8202936: Improve script engine support.
- CVE-2018-3214, S8205361: Better RIFF reading support.
- CVE-2018-3211: Unspecified vulnerability in the Serviceability component.
- S8195868: Address Internet Addresses.
- S8195874: Improve jar specification adherence.
- S8201756: Improve cipher inputs.
- S8203654: Improve cypher state updates.
- S8204497: Better formatting of decimals.
* debian/patches/jdk-freetypeScaler-crash.diff: removed as this patch causes
a memory leak; upstream fixed it in openjdk-7, albeit in a different way.
Closes: #910672.
[ Matthias Klose ]
* Bump standards version.
-- Matthias Klose <[email protected]> Sun, 21 Oct 2018 12:23:32 +0200
Specifically this update touches several areas around TLS/SSL.
Now, for some of my local info for context.
Dockerfile:
# ---- runtime ---- #
FROM jetty:9-jre8 AS runtime
USER root
# mountpoint for runtime volume - easy persistent logs
RUN mkdir -pv /mnt/jetty-logs && chown -v jetty:jetty /mnt/jetty-logs
USER jetty
ENV JAVA_OPTIONS "-Xmx512m -Xms512m"
RUN java -jar ${JETTY_HOME}/start.jar --add-to-start=https,http2 --approve-all-licenses
RUN rm -v ${JETTY_BASE}/start.d/http.ini
ADD --chown=jetty:jetty cas-redirect.war /var/lib/jetty/webapps/ROOT.war
COPY --chown=jetty:jetty cas.war /var/lib/jetty/webapps/cas.war
ADD --chown=jetty:jetty etc/cas /etc/cas
ADD --chown=jetty:jetty keystore /var/lib/jetty/etc/keystore
ADD --chown=jetty:jetty ssl.ini /var/lib/jetty/start.d/ssl.ini
Referenced ssl.ini content:
jetty.sslContext.keyStorePassword=REDACTED
jetty.sslContext.keyManagerPassword=REDACTED
https://apereo.github.io/cas/5.3.x/index.html but this issue happens even if this context is omittedkeystore is valid with one private key and public cert pair:
draeath@ginnungagap:~/scratch$ keytool -list -keystore ./keystore
Enter keystore password: REDACTED
Keystore type: PKCS12
Keystore provider: SUN
Your keystore contains 1 entry
REDACTED, Aug 10, 2018, PrivateKeyEntry,
Certificate fingerprint (SHA-256): REDACTED
/generate-jetty-start.sh: 3: /generate-jetty-start.sh: cannot create /jetty-start: Permission denied
Particularly HTTP/2 support
Using the command
RUN java -jar /usr/local/jetty/start.jar --add-to-startd=http2 --approve-all-licenses
in a Dockerfile based on the latest image complains with the following error:
org.eclipse.jetty.start.graph.GraphException: Missing referenced dependency: alpn-impl/alpn-1.8.0_66
at org.eclipse.jetty.start.graph.Graph.selectNodes(Graph.java:470)
at org.eclipse.jetty.start.graph.Graph.selectNode(Graph.java:447)
at org.eclipse.jetty.start.graph.Graph.selectNode(Graph.java:415)
at org.eclipse.jetty.start.graph.Graph.selectNodes(Graph.java:473)
at org.eclipse.jetty.start.graph.Graph.selectNode(Graph.java:447)
at org.eclipse.jetty.start.graph.Graph.selectNode(Graph.java:415)
at org.eclipse.jetty.start.graph.Graph.selectNodes(Graph.java:473)
at org.eclipse.jetty.start.BaseBuilder.build(BaseBuilder.java:151)
at org.eclipse.jetty.start.Main.start(Main.java:407)
at org.eclipse.jetty.start.Main.main(Main.java:75)
Usage: java -jar start.jar [options] [properties] [configs]
java -jar start.jar --help # for more information
Which I believe is because there is no alpn-1.8.0_66 file in the /usr/local/jetty/modules/alpn-impl/ folder. I was able to get further by symlinking alpn-1.8.0_60 to alpn-1.8.0_66, but this does not seem ideal.
I see the current jre-11 based Jetty image is based off openjdk:11-jre.
To reduce image size, it would be valuable if Jetty images existed that were based off the openjdk:11-jre-slim image.
Thank you for your consideration.
The HTTP/2 Support instructions are currently failing with images based on 9.4.9.v20180320 based images (jetty:latest, jetty:alpine):
$ docker build .
Sending build context to Docker daemon 186.7MB
Step 1/3 : FROM jetty:alpine
---> 6c074c65bd67
Step 2/3 : RUN java -jar "$JETTY_HOME/start.jar" --create-startd --add-to-start="http2" --approve-all-licenses
---> Running in 8e7a9a2ef816
java.lang.IllegalStateException: Cannot read file: modules/alpn-impl/alpn-1.8.0_171.mod
at org.eclipse.jetty.start.Modules.registerModule(Modules.java:202)
at org.eclipse.jetty.start.Modules.enable(Modules.java:355)
at org.eclipse.jetty.start.Modules.enable(Modules.java:360)
at org.eclipse.jetty.start.Modules.enable(Modules.java:377)
at org.eclipse.jetty.start.Modules.enable(Modules.java:377)
at org.eclipse.jetty.start.Modules.enable(Modules.java:286)
at org.eclipse.jetty.start.BaseBuilder.build(BaseBuilder.java:127)
at org.eclipse.jetty.start.Main.start(Main.java:435)
at org.eclipse.jetty.start.Main.main(Main.java:77)
Usage: java -jar $JETTY_HOME/start.jar [options] [properties] [configs]
java -jar $JETTY_HOME/start.jar --help # for more information
The command '/bin/sh -c java -jar "$JETTY_HOME/start.jar" --create-startd --add-to-start="http2" --approve-all-licenses' returned a non-zero code: 247
Should these instructions be updated, or is there a larger failure occurring?
New to docker, so may be missing something obvious but i can't get this image to serve pages on my mac. Any help is appreciated.
I run the following from my mac:
docker run -d jetty
And then the following to get the container-ip:
docker-machine ip
And then put the following on my macs chrome browser:
http://container-ip:8080/
I get the following message in the browser: This site can’t be reached
A user left a comment on the Docker Hub that the docs at https://wiki.eclipse.org/Jetty/Howto/Deploy_Web_Applications contradict what we have in the README.md. It looks like that wiki page hasn't been updated since 2013, so that link should either be removed or replaced with a link that points to officially maintained documentation.
I use the docker-jetty/9.4-jre8/Dockerfile to build image on arm64 architecture and successed,so I think we can add it to support arm64 architecture.
All the latest Jetty 9.3-jre8 use Java 10. Alpine seems to work
If ALPN is enabled, the correct module is not selected because the docker jvm has -internal in the version name. A PR has been raised on Jetty to make our parsing more lenient, but we have also raised an issue on docker-java because GA releases should not have - in their version numbers.
This issue is opened here just to note the ALPN problem and can be closed once jetty version is upgraded or docker-jetty changes.
Like most of the Docker official images, this image is currently configured to run as root. I'm opening this issue as a place to discuss what change should be made, if any. See this discussion in the context of the tomcat image for the sort of issues that can be anticipated for jetty.
I can see a few changes/enhancements being made to this image:
Dockerfile to create a consistent jetty user to allow users to easily do USER jetty in a derived Dockerfile or -u jetty in their docker run command.JETTY_BASE for the jetty:9 image and give an example that uses --module setuid to drop privileges to the jetty user after starting as root.Hi,
thanks for providing docker-Jetty-images.
In my use case, I do not only want to use Jetty, I have to use JDK (instead of JRE), too¹.
It would be great, if you could provide additional docker-Jetty-images, which contain JDK instead of JRE.
¹
In special: Within my docker-image, I want to be able to use v8. And I want to have Alpine as base image. Because of Alpine, I have to compile v8 on my own, needing JDK at this point, for details see https://github.com/tarent/openjdk-alpine-j2v8. So I want Jetty, Alpine, and am needing JDK for compiling v8.
I want to adapt the approach of tarent/openjdk-alpine-j2v8 (which extends openjdk:8-jdk-alpine) to the Jetty docker image. For this, I am "missing" jetty:jdk8-alpine.
I'm new to jetty and looking to use it for some testing.
I'm able to run the container and access the jetty server:
docker run -d -p 8080:8080 jetty:9
Is it correct that the raw container will return a 404 and No contexts by default? All I need for my testing is 200 and so I've resorted to try to build/deploy a helloworld app to achieve this.
I used the Eclipse wiki site to build the HelloWorld webapp. It works on 8080 with mvn jetty:run and, after tweaking the pom.xml (jar-->war) my target directory includes the exploded hello-world-* directory (index.html, META-INF, WEB-INF) and the war file.
Assuming that is correct, I'm trying -v /path/to/target:/var/lib/jetty/webapps and it doesn't work.
I continue to receive the 404.
docker run -d -p 8080:8080 -v /...../target:/var/lib/jetty/webapps jetty:9
https://store.docker.com/images/jetty
now is 9.4.6.v20170531
hope docker jetty version update to 9.4.7.v20170914
Thanks！
When I initially created this image, I included Jetty 7 and 8 images because "stable-7" and "stable-8" versions are listed at http://download.eclipse.org/jetty/
However, I later discovered that Jetty 7 and 8 were EOL'd as of the end of 2014. Here's what Webtide's blog post has to say about it:
This year will mark the end of our open source support for Jetty 7 and Jetty 8. Earlier this week we pushed out a maintenance release that only had a handful of issues resolved over the last five months so releases have obviously slowed to a trickle. Barring any significant security related issue it is unlikely we will see more then a release or two remaining on Jetty 7 and Jetty 8. We recommend users update their Jetty versions to Jetty 9 as soon as they are able to work it into their schedule. For most people we work with, the migration has been trivial, certainly nothing on the scale of the migration between foundations.
Removing Jetty 7 and 8 images will have the benefit of allowing the jetty image as a whole to start using a simple JETTY_BASE owned by user jetty by default, thereby fixing #1. Instructions or a variant image can then be provided that starts as root and uses the built-in setuid module to drop privileges to user jetty.
Would it be possible to upgrade to the latest jetty 9.3.7.v20160115?
Some of the updated features include a fix for the SLOTH vulnerability: jetty/jetty.project@0a1b0b2
As suggested in #41 I derived an image from jetty with the following Dockerfile:
FROM jetty:alpine
RUN set -xe \
&& apk add --no-cache --virtual .build-deps attr \
&& setfattr -n user.pax.flags -v "em" /usr/lib/jvm/java-1.8-openjdk/jre/bin/java \
&& apk del .build-deps \
&& rm -rf .build-deps \
&& rm -rf /tmp/hsperfdata_root
Once build is completed, java binary has no extended attributes. If I start an interactive session and set them manually they do work though.
I'm using docker with devicemapper loop sparse files and XFS as backing filesystem (as reported by docker info).
Any hint would be appreciated ;).
The chown of JETTY_BASE is missing -R, so it's contents are still own by root
I'm receiving this from the jetty:9-jre8 tag, which I just pulled a few minutes ago. Image ID in 'docker image ls' is 07b6d9a3f5d2
12:28:20.805 Step 14/19 : RUN java -jar ${JETTY_HOME}/start.jar --add-to-start=https,http2 --approve-all-licenses
12:28:20.805 ---> Running in 665b7b212c45
12:28:20.805 java.lang.IllegalStateException: Cannot read file: modules/alpn-impl/alpn-1.8.0_181.mod
12:28:20.805 at org.eclipse.jetty.start.Modules.registerModule(Modules.java:202)
12:28:20.805 at org.eclipse.jetty.start.Modules.enable(Modules.java:355)
12:28:20.805 at org.eclipse.jetty.start.Modules.enable(Modules.java:360)
12:28:20.805 at org.eclipse.jetty.start.Modules.enable(Modules.java:377)
12:28:20.805 at org.eclipse.jetty.start.Modules.enable(Modules.java:377)
12:28:20.805 at org.eclipse.jetty.start.Modules.enable(Modules.java:286)
12:28:20.805 at org.eclipse.jetty.start.BaseBuilder.build(BaseBuilder.java:129)
12:28:20.805 at org.eclipse.jetty.start.Main.start(Main.java:435)
12:28:20.805 at org.eclipse.jetty.start.Main.main(Main.java:77)
12:28:20.805
12:28:20.805 Usage: java -jar $JETTY_HOME/start.jar [options] [properties] [configs]
12:28:20.805 java -jar $JETTY_HOME/start.jar --help # for more information
The current CMD has -jar start.jar before -Djava.io.tmpdir=.... This forces start.jar to always fork a new JVM.
We should consider putting the -D first, so a new JVM is only required if a module is enabled that needs additional JVM args (eg ALPN).
With Docker version 17.09.0-ce, build afdb6d4 I have started getting the following warnings when building:
[WARNING]: Empty continuation line found in:
ENV JETTY_GPG_KEYS AED5EE6C45D0FE8D5D1B164F27DED4BF6216DB8F 2A684B57436A81FA8706B53C61C3351A438A3B7D 5989BAF76217B843D66BE55B2D0E1FB8FE4B68B4 B59B67FD7904984367F931800818D9D68FB67BAC BFBB21C246D7776836287A48A04E0C74ABB35FEA 8B096546B1A8F02656B15D3B1677D141BCF3584D FBA2B18D238AB852DF95745C76157BDF03D0DCD6 5C9579B3DB2E506429319AAEF33B071B29559E1E
[WARNING]: Empty continuation lines will become errors in a future release.
The source for that line is
# GPG Keys are personal keys of Jetty committers (see https://github.com/eclipse/jetty.project/blob/0607c0e66e44b9c12a62b85551da3a0edce0281e/KEYS.txt)
ENV JETTY_GPG_KEYS \
# Jan Bartel <[email protected]>
AED5EE6C45D0FE8D5D1B164F27DED4BF6216DB8F \
# Jesse McConnell <[email protected]>
2A684B57436A81FA8706B53C61C3351A438A3B7D \
# Joakim Erdfelt <[email protected]>
5989BAF76217B843D66BE55B2D0E1FB8FE4B68B4 \
# Joakim Erdfelt <[email protected]>
B59B67FD7904984367F931800818D9D68FB67BAC \
# Joakim Erdfelt <[email protected]>
BFBB21C246D7776836287A48A04E0C74ABB35FEA \
# Simone Bordet <[email protected]>
8B096546B1A8F02656B15D3B1677D141BCF3584D \
# Greg Wilkins <[email protected]>
FBA2B18D238AB852DF95745C76157BDF03D0DCD6 \
# Greg Wilkins <[email protected]>
5C9579B3DB2E506429319AAEF33B071B29559E1E
So I think the comment style is confusing the warning. We could either fix this in docker-jetty by reformatting and avoiding the problem... or perhaps it is an issue that should be escalated to docker itself?
Hi all
The use case is to have the docker stop when when the default webapp cannot talk to say mysql.
It is my understanding that the following xml is what I need:
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_0.dtd">
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<!-- don't use the following two lines in the jetty-web.xml -->
<Set name="war"><SystemProperty name="jetty.home" default="."/>/apollobit-web-0.3.war</Set>
<Set name="contextPath">/</Set>
<Set name="throwUnavailableOnStartupException">true</Set>
</Configure>
Here is what I have tried:
ideas?
Not sure why, but the below bit fails for me with exit code 2. I am building using Ubunut 14.04 and Oracle JDK 8, not sure if the below doesn't execute on Ubuntu?
ENV JETTY_GPG_KEYS 5DE533CB43DAF8BC3E372283E7AE839CD7C58886
RUN set -xe
&& for key in $JETTY_GPG_KEYS; do
gpg --keyserver ha.pool.sks-keyservers.net --recv-keys "$key";
done
It would seem with the latest release of jetty:9-alpine and jetty:latest JAVA_OPTIONS set via environment variable is not working.
Simple test case:
docker run --rm --name jettymem -ti -e JAVA_OPTIONS=-Xmx1G jetty:latest
Check command run with docker top jettymem, the -Xmx1G is not present even though you can see it is set with docker exec -ti jettymem sh -c ' echo "$JAVA_OPTIONS" '
I'm using jetty:latest as Baseimage in my Dockerfile (FROM jetty:latest)
I used to modify some parts within the Container with statements in my Dockerfile like:
RUN rm -f /etc/localtime && ln -snf /usr/share/zoneinfo/$TIMEZONE /etc/localtime && echo $TIMEZONE > /etc/timezone
RUN apt-get update && \
apt-get -y upgrade && \
apt-get -y install foo bla && \
apt-get clean
RUN mkdir /somedir
Since the latest version of the Image I get an "permission denied" error when trying to run any of this commands.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.