'FROM scratch' is a bare image, empty. Creating a 'FROM scratch'
container means the only thing in the container is what you put in there
directly. Mostly, that's just your jlinked application. Maybe you would
include imagemagick for thumbnail processing or something, but
generally, just your app. If for some reason your app is hacked, and the
hacker were to get a chance to Runtime.exec() something, there's nothing
outside of your application to exec... not even a bash shell, unless you
include one.
So it not only makes your image lighter weight, but greatly reduces your
attack surface as well.
I did it using a multistage docker build, something like:
FROM adoptopenjdk:13-jdk-hotspot as MAVEN_BUILD
RUN apt-get update; \
apt-get install -y maven binutils;
COPY src /proj/src/
COPY pom.xml /proj/
COPY toolchains.xml /proj/
WORKDIR /proj/
RUN mvn verify --global-toolchains toolchains.xml -P jlink; \
cp -R target/jlink-image /app;
COPY strip.sh /proj/
RUN chmod +x strip.sh; \
./strip.sh
FROM scratch
COPY --from=MAVEN_BUILD /export /
EXPOSE 8080
WORKDIR /app/bin
ENTRYPOINT ["/app/bin/java", "-m", "${package}/${package}.App"]
But this was like six years ago. I did this before there was even a
maven-jlink-plugin. The build should be much easier now. The real magic
happens in the strip.sh. That determines the native libs you actually
need to make your binaries run and only copies over those to the scratch
image.
On 2/1/26 11:41 PM, Ricardo Parada wrote:
That is awesome. I will take a look.
Im curious. What is this FROM scratch? A base docker image? What would it have?
Regards,
Ricardo Parada
On Jan 31, 2026, at 6:04 AM, Ramsey Gurley <[email protected]> wrote:
Yep, that's removed in Wonder 8. That looked basically unused. You'd have to go out of
your way to use it. Coming soon :) I'm currently removing a dependency on an old json-lib
in ERRest now, but I'm almost there. I was hoping to finish up this month, but it didn't
quite happen. Glad to hear someone is interested in containers other than me. I already
have a bare-metal "FROM scratch" Java app archetype that I put together years
ago. I'll apply that to wonder-archetypes quite soon. Stay tuned.
On 1/30/26 11:32 PM, Ricardo Parada via Webobjects-dev wrote:
Good morning,
Has anybody updated Wonder’s ERXSignalHandler so that it doesn’t rely on
sun.misc.*?
It seems to be used by ERXEC’s registerOpenEditingContextLockSignalHandler()
which registers for “HUP”.
Also sun.misc.SignalHandler is extended by ERXGracefulShutdown.
In the cloud world environment, e.g. AWS/EKS/EC2, an app almost never needs
SIGHUP anymore.
Kubernetes EKS does not use HUP
It uses SIGTERM first to request a graceful shutdown. Then after a grace
period, SIGKILL if the process does not exit.
EC2 (systemd) also avoids HUP
Systemd service units use SIGTERM for graceful stop.
A WebObjects app on EKS or EC2 should not expect or need HUP.
JVM Shutdown Hooks
Java allows you to register clean up code that executes when JVM begins
shutdown.
Runtime.getRuntime().addShutdownHook(new Thread(() -> { … }));
They will execute when SIGTERM (graceful termination) is requested. SIGINT when
process receives ctrl+C.
They will not execute if SIGKILL is received (kill -9) or when JVM crashes due
to fatal signals (SIGSEGV, etc.)
Anyways, it seems it could be updated to used java’s shutdown hooks and play
better in modern Java and cloud world.
Has anybody updated wonder to migrate away from sun.misc?
Thank you
Ricardo Parada
