In the last installment, we talked about Payara Micro. In this, we’re going to look at Thorntail. Thorntail, née Wildfly Swarm, is based on Wildfly from Red Hat and is said to be "just enough app-server". Much like Payara Micro, Thorntail exposes a battle-tested application server platform, stripped down for microservices usage. Let’s a take a look at what it takes to deploy our application on Thorntail.
Payara Micro is a MicroProfile implementation from the good folks at Payara, based on Payara Server, which is itself based on GlassFish. Whew! If you’re familiar with either GlassFish or Payara, you should feel right at home with Payara Micro.
To start our investigation, we need an application to work with. Part of the problem with getting started applications is making sure that your example is complicated enough to be interesting, but not so complicated that the greater message is lost in the details of the app. MicroProfile 2.0 is made up of a number of components:
MicroProfile Config 1.3
MicroProfile Fault Tolerance 1.1
MicroProfile Health Check 1.0
MicroProfile JWT Authentication 1.1
MicroProfile Metrics 1.1
MicroProfile OpenAPI 1.0
MicroProfile OpenTracing 1.1
MicroProfile Rest Client 1.1
Common Annotations 1.3
To include all of those in this would probably be a bit too much technical weight for a getting started effort, so, for this example, I’ve leaned (probably too far) toward simple. Our application will have a single JAX-RS resource, into which is injected a single CDI bean. The point is to have a working REST endpoint, with an inject "service layer", to show a MicroProfile in action, allowing us to verify that our basic environment is configured and working correctly. From there you are free to load on all the complexity you find you need. That’s exactly what I’ll be doing in a separate project. :)
The Eclipse MicroProfile is a community-driven profile initially developed by Red Hat, IBM, TomiTribe, Payara and the London Java Community (LJC). Launched in 2016, it was intended to sit alongside Java EE’s Web and Full profiles, offering Java EE developers a smaller, lighter set of standards with which they could build microservices. Today, MicroProfile lives as an Eclipse project, and is being supported and actively developed by its creators as well as many more, including both corporations and individuals, giving us an embarassment of riches, if you will, when it comes to implementations.
By my count, there are at least 6 implementations from which to choose, leading to the question: Which one do I choose? While there are many aspects that factor in to such a decision, it is not my intent here to answer those questions. Rather, what I’d like to do is provided some small "getting started" projects to help you kick off your own investigation. With that in mind, here are the implementations (in no particular order) that we’re going to look at:
In Part 1, we’ll cover the (admittedly absurdly basic) application, and in subsequent parts, we’ll see what it takes to deploy that application using each of these MicroProfile implementations.
Copying files in Java is, I think, header than it seems it should be. Typically, I see that done with, say, a
ByteArrayInputStream and a
ByteArrayOutputStream . Thanks to Kotlin’s extension function capabilities, this operation is a one-liner:
That could even be an extension function itself:
fun File.copyFile(dest: File): Unit = dest.writeBytes(this.readBytes())
My work machine runs Windows (go ahead and laugh. I’ll wait). While I’ve been able to tweak the machine and get a moderately acceptable setup, there are times when I’d really like to use Linux for something, so I spin up a virtual machine with VirtualBox. While that works, I don’t really like having source code — especially with changes in flight — on the VM, as it makes it a bit more dangerous/difficlt to destroy the VM should I need the disk space (which happens more often than I’d like). I set out, then to get shared folders working so I can keep the source on my host machine, and just do the work in the VM. Unfortunately, it doesn’t seem to be as simple as adding a shared folder to the VirtualBox config. This post, then, will detail the steps I took to make things work for me.
If you wrote software on a DOS system in the 80s or 90s, you probably used one of the Borland products, Turbo Pascal or Turbo C, with that beautiful, beautiful blue, mouse-enabled text-based user interface (TUI, if you will). Those IDEs were powered by a library called Turbo Vision (TV), which Borland documented and published for others to use. I loved it. While we all live in a GUI world and there are lots of libraries for building GUIS, I have for years now been dying to be able to use TV again, if for no other reason than hard core nostalgia. The problem being that I have used C in about 2 decades, and, to be honest, I’m not sure I’m too excited about writing even toy apps in the language. Dead end, right? Not so fast.
Enter, stage left: SWIG. SWIG, the Simplified Wrapper and Interface Generator, is a tool for building wrappers for libraries written in, say, C or C, for languages such as Python, PHP, and... Java. While it may not be the best option, it's an option, and I've been tinkering with it off and on for many, many moons now with the C version of the library open source by Borland long ago, before they were sold off and the Borland brand quietly disappeared. Tonight, I made great progress on it.
I’m currently working on a DSLs-in-Kotlin presentation for my local JUG, so I need a good domain in which to work. HTML is a great sample domain, but it’s been done to death. After a bit of head scratching, I’ve come up with what is, I think, a somewhat novel domain: REST application building. Sure, there are libraries like Ktor, but suffers from some very serious NIH. I’m totally kidding, but the dearth of discussions regarding REST applications and DSL construction was good enough for me, so let’s see what we have so far.
If you’ve been working with Java for very long, you’ve probably had occasion to use
String.format() . And, if you’re like me, you may very well have been doing it "wrong". Let’s take a look at what was, for me, common usage, and how, maybe, you should be doing it.
Wise or not, I recently made the move to Linux on my work machine. For the most part, it works wonderfully. For reasons that aren’t too terribly relevant here, I found myself needing (or wanting) to run the Windows version of Firefox. While I could run it successfully, it wouldn’t connect to the internet. After a whole lot of digging, I finally found the answer, which I thought I should document here with the hope that it will be easier for others to find (including me when I go through this again in a few years ;).
The culprit, it seems, is a couple of Firefox settings: browser.tabs.remote.autostart and browser.tabs.remote.autostart2
Once you have Firefox running under Wine, go to about:config in the browser, and enter remote.autostart in the Search box, and change the value of both settings to false:
Restart Firefox, and you should be golden.
For what it’s worth, credit where credit is due: this is the post that finally got me over the hump.
- Tips for Writing Pluggable Java EE Applications
- JSFTemplating and Woodstock: Component Authoring Made Easy
- Jason Lee in depth: Mojarra and Scales
- Jason Lee: Postmortem for JavaOne 2008
- International Environmental: A Cooling Company Which Prefers Hot Software
- IEC donates custom JSF component to Mojarra Scales