Consider providing a non-headless JRE version of tomcat

[weltan]

The Tomcat 9 image is based on tomcat:9-jre8-alpine which uses a headless JRE.

I’ve run into a problem with, for example, generating PDFs and SVGs, that use java.awt.Font, which does not work well in headless mode. Root issue can be seen here: docker-library/openjdk#73.

This type of functionality (generating PDFs) would seem quite common for App Service enterprise Java apps.

Would it be possible to provide a non-headless tomcat image like tomcat:9-jre8 without alpine, similar to what you have for 8.5? I've already asked upstream Alpine OpenJDK to add the few packages needed for java.awt.Font to work, and was rejected (makes sense).

Another option if you want to keep only Alpine because it's a lightweight container option, is to allow the user to select from a pre-defined set of custom tomcat container versions in Azure.

Of course, we can always use our own custom containers, but I think users might prefer to use these Azure-managed containers rather than having to resort to a custom Docker container.

[jvano]

The tomcat built-in images for App Service Linux are still in preview and we will make changes but your input is very valuable. Thanks @weltan for the suggestion.

[weltan]

Great, thanks for your consideration.

Just so you know, we ended up using your tomcat9 alpine built-in, and installed fontconfig and ttf-dejavu at run-time using a code-invoked shell command. It ain’t pretty, but it allowed us to stay on the built-in tomcat image.

[ernani]

Perhaps this change in the Dockerfile would do it, right?

ENV JAVA_OPTS -Djava.awt.headless=true $JAVA_OPTS

[weltan]

@ernani: I think you might be misunderstanding? We're trying to avoid headless mode, not enable it.

[ernani]

@weltan I thought it was the opposite case, in that sense you are right, perhaps you may want to go building a custom docker image and deploy it using Web Apps for containers instead?

Perhaps that workaround is not optimal for you, so, in that way having a custom image would address that situation in an optimal way, right?

[weltan]

@ernani Yes - creating a custom image would solve this problem. However, as I pointed out in my original post above, it's a huge boon to be able to use the azure-managed containers. Furthermore, it seems like the particular issue my team ran into is a relatively common subclass of "cases where using headless JRE isn't possible" and therefore might be suitable for a more general solution provided by Azure.

That's why I asked about whether they'd consider adding a non-headless managed container.

[ernani]

I am a CSA @ Microsoft. I will try to point it out internally your situation to the Product Group. I will get back to you with an answer ASAP. Best Regards Em Sex, 6 de jul de 2018 4:37 PM, Ken Kantzer <notifications@github.com> escreveu:

…

Yes - creating a custom image would solve this problem. However, as I pointed out in my original post above, it's a huge boon to be able to use the azure-managed containers. Furthermore, it seems like the particular issue my team ran into is a relatively common subclass of "cases where using headless JRE isn't possible" and therefore might be suitable for a more general solution provided by Azure. That's why I asked about whether they'd consider adding a non-headless managed container. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG_WxLN09pxJSvhtpq9AzdRDvBRdNO1ks5uD7xkgaJpZM4UdyOb> .

[weltan]

curious, @ernani, if you've heard anything?

[ernani]

I have had the chance to talk to some of the guys internally and some new content are coming in but still with no ETA.

Perhaps @jvano you could also help reinforce this requirement as well.

Best Regards!

[jvano]

Hi

The Java built-in images for App Service Linux are still in preview and we are making changes to them and bringing new ones as the Java SE.

We still don't have an ETA to share at this point but we want to have the images ready for production workloads sometime this year.

Thanks,

Joaquín

[weltan]

@jvano @ernani sounds good, totally understand that this is in preview - that’s actually why I reached out, I figured this is the time where changes are still happening regularly!

[shrishrirang]

@weltan: #8 contains changes for building Tomcat 8.5 and 9.0 images using the Ubuntu 18.04 image as the base. The PR is merged and we will be updating the official Azure App Service images (for Tomcat 8.5 and 9.0 both) in Docker Hub this week.

[shrishrirang]

@weltan : We recently changed the base image of the Dockerfiles. However, we aren't using headless jre anymore, so I believe your issue is addressed. But to be sure I would like to test it once. Do you have a simple repro app or set of steps I can use to confirm?

[weltan]

@shrishrirang hi thanks for this fix. We can confirm that using the new Ubuntu base image in our App service allowed us to remove the workaround, and everything seems to be working.

As for a minimal repro for you to test, I believe any use of java.awt.Font should produce an exception in Alpine-headless, but not in Ubuntu, so this gist, provided by someone on this thread, should work? https://gist.github.com/md5/7fb07efafee3802da457

[shrishrirang]

Currently, the docker image being used is an alpine image. We had moved to Ubuntu briefly, but we are again back to using an alpine image. However, the difference this time is that we are not using a headless jre anymore.

I'll take a look at the repro instructions you shared. Thanks!

[shrishrirang]

9de23e2 addresses the font issue. The updated Tomcat images are live now. If you see any issues, feel free to report them.