Renewal of Let’s Encrypt Certificates Using Plesk

Note to self: If the Let’s Encrypt extension for Plesk fails to renew a certificate (when triggered manually), disable the automatic forwarding to an SSL connection in the Apache settings. This forced secure connection seems to disturb the renewal script.

The error I got was something like this:

Let's Encrypt SSL certificate installation failed: Failed letsencrypt execution: 2016-01-19 13:56:07,885:WARNING:letsencrypt.cli:Root (sudo) is required to run most of letsencrypt functionality. Failed authorization procedure. (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from [REMOVED IP]: 401 IMPORTANT NOTES: - The following errors were reported by the server: Domain: Type: urn:acme:error:unauthorized Detail: Invalid response from /.well-known/acme- challenge/REMOVED-ID [REMOVED IP]: 401

See also this bug report on Github.

Let’s hope the extension is going to renew all certificates automatically every month from now on, as it should.

Testing Delegate Methods

We had an interesting discussion the other day: should we write unit tests for delegate methods, that is, methods that only delegate the call to a delegate object? Here’s an example of such a method:

I said I did not see much value in a unit test for this method as all the test could do is verify whether the do()  method of the mocked delegate object was called. Instead of testing behaviour, we would test the wiring which is close to trivial in this case and should be tested implicitly as part of an integration test involving the delegate object and the main object.

Some of my colleagues disagreed with me. Their argument was that a unit test would detect changes in the delegate call and indicate the intended usage of the delegate object. They were concerned an incorrect wiring could be introduced without a unit test. And this unit test would be cheap to write.

I did not find any of these arguments very convincing – and I’m in good company: the JUnit team’s FAQ webpage has a section on Best Practices which comments on testing delegate methods. You can read it here. Thank you, J. B. Rainsberger!

Headless Testing with TestFX

Jérome Cambon wrote a nice introduction to TestFX and how to enable the headless mode using Monocle.

I tried to reproduce the steps he described for running my TestFX GUI tests in headless mode from Eclipse so I can keep using my mouse while they are running. The crux is setting the VM arguments in Eclipse. First, I tried to set

in the VM arguments section of the JRE tab in my Maven run configuration:

Maven run configuration in Eclipse

This did not work. I could still see the TextFX robot move the mouse cursor on my screen.

I had to specify the VM arguments using Maven’s ‘argLine’ parameter:

Maven argLine parameter

If anyone knows why setting the VM arguments in the run configuration did not work, please let know.

A Potential Pitfall with the TextFormatter Class in JavaFX

A common use case for the TextFormatter class in JavaFX is a text field that should convert any lower-case character input into an upper-case character. This can be achieved easily by defining a filter for the text formatter as described here. A straightforward implementation could look like this:

This implementation comes with one pitfall, though. When the (German) user types the character “ß” into the text field, it will be converted into “SS” because that’s how Germans roll. So the resulting string is one character longer than the input string. Why is this a problem? Well, the cursor position will be between the two “S” characters after the conversion:


When the user types in the next character, it will be inserted between the two “S” characters, not behind them. Bummer.

Luckily, the masterminds behind JavaFX give us the tools to correct this unfortunate behaviour since the change object that the filter works on allows for setting the anchor and caret position in the text field. We need to correct them by the difference between the string lengths before and after the conversion:

This puts the cursor at the end of the string no matter how many “ß” characters the user types in or pastes into the text field.

The TextFormatter Class in JavaFX: How to Restrict User Input in a Text Field

There are a lot of code examples for restricting or modifying user input into a JavaFX text field. Most examples I have seen suggest adding a change listener to the text field’s text property. Here’s how you would allow only lower-case characters in your text field using the change listener approach:

This approach comes with one drawback: you’ll have two events being triggered by two changes of the text property. The first change is caused by the direct user input, the second change is caused by the manipulation of the user input by the change listener. The user won’t notice these two events, but somewhere in your code you have another listener for the text property, that listener will receive two events, one with the “invalid” change and a second one with the “valid” change.

Another approach was suggested by Richard Bair a long time ago. His suggestion resulted in the TextFormatter  class being added to JavaFX with version 8u40. It’s a clean way to format, filter, or restrict user input. Here’s how it works:

What’s still missing is support for the backspace key to delete a character in the text field, but that’s just my silly example implementation. [Update 2016-12-28: The implementation was improved to support the deletion and selection of characters.]

This approach intercepts the user input before it’s written into the text property and thus fires only one event. Before that happens, you can examine and modify the Change  object in the UnaryOperator  defined in getFilter()  method.

In addition to filtering, a TextFormatter  object can convert a value to a string representation and vice versa. From the Javadoc:

A value converter and value  can be used to provide a special format that represents a value of type V. If the control is editable and the text is changed by the user, the value is then updated to correspond to the text.

Sounds pretty handy.

Owncloud with Apache 2.4, PHP FPM, and Plesk

After about two weeks of fiddling around, I finally managed to get my own instance of owncloud up and running with Apache behind Plesk. Here’s how I did it:

  1. Set up a sub-domain in Plesk, e.g.
  2. Set up a database for owncloud using Plesk.
  3. Make sure to use HTTP strict transport security by adding the following Apache HTTPS directive:
  4. Create a directory for your owncloud data, e.g. /var/oc_data
  5. Give sufficient permissions to your HTTP user on the data directory:

    In my case, user1 is the the name of the Plesk user with which I had created the sub-domain. psacln is the group assigned to this user by Plesk.
  6. Update PHP to version 5.6.x. There is this bug in version 5.5.x which makes owncloud unusable if you don’t want to use mod_php (which is discouraged).
  7. Configure PHP in Plesk and Apache as follows:
    • Run PHP as an FPM application
    • Set open_basedir to {WEBSPACEROOT}{/}{:}{TMP}{/}{:}/dev/urandom{:}/var/oc_data{/}
    • Set memory_limit to 256M (or something like that)
    • Set max_execution_time to 120 (or something like that)
    • Set max_input_time to 120 (or something like that)
    • Set post_max_size to 128M (or something like that)
    • Set upload_max_filesize to 64M (or something like that)
  8. Check this owncloud documentation page for potential additional PHP settings when running in FPM mode.
  9. Download the setup-owncloud.php web installer as described here and run it from your browser.
  10. Have fun.

How to Make Unit Tests more Likeable

What are these unit tests good for? Are we testing Mockito?

This is what a colleague asked another colleague a couple of days ago. He was referring to some rather complicated and long unit tests that used a lot of mocks and verify statements. I knew what he was talking about since I had seen quite a few tests like that myself.

Whenever a JUnit test method has more than ten lines or so, I get suspicious (and sometimes start crying). Add a few ArgumentCaptors and I’m done with that test. If I’m supposed to fix a test like that, I tend to give up quickly and rather delete the test method than try to understand what is being tested and why it fails.

A good test, however, makes me smile. It’s short, concise and readable because it follows the arrange, act, assert principle. It uses Mockito’s fluent API if it uses Mockito at all. That’s anyString()  instead of Mockito.anyString()  and times(2)  instead of VerificationModeFactory.times(2) (which is Mockito’s internal API btw). And mocks, stubs, spies, and dummy objects are set up in the @Before  method instead of every test method. This saves a lot of boilerplate code and makes me want to fix the test if it breaks.

Adding JavaFX Properties to a DTO

Now that I have understood what a DTO is good for, I’m thinking about ways to improve it. As they are right now, our DTOs are POJOs extended by JSR 303 annotations for defining constraints on their fields/methods. The annotations are duplicates of the annotations defined on the corresponding entities.

Since I have worked with the UI code most of my time so far, I have felt the drawback of not having JavaFX properties in our DTOs: they cannot be observed easily by the GUI controls. There is a wrapping mechanism to add this observability, but it is rather complicated to use and requires a lot of extra code.

So why not make the DTOs full JavaFX beans? After all, we would not be the first project to do this. Two common objections were raised when I brought this up:

  1. DTOs are created on the server which should not have dependencies to a GUI/client technology.
  2. We would need to mix JavaFX beans with JSR 303 annotations.

Let’s address the first point. Yes, having a GUI dependency in your server code is not a good idea. But are JavaFX properties a GUI technology? Or even a client technology? It’s a bit unfortunate that they were introduced as part of JavaFX in a javafx.* package such that everyone identifies them as a GUI technology at first sight. It’s an image problem. I would argue they are a self-contained technology which is independent of any GUI parts of JavaFX and could therefore be used for any data model, no matter if it’s on the client, on the server, or shared between both. Even if one does not use JavaFX for the frontend, depending on JavaFX properties would do almost no harm in practice since JavaFX is part of the JDK and your server code certainly depends on the JDK. So the no client dependencies on the server argument is merely a formal one in my opinion.

What about the second point, mixing JavaFX properties with bean validation annotations? I have never tried it myself, but I have the feeling it cannot be that big of a problem. If it works in the FXForm2 demo, why should there be a fundamental incompatibility between these two technologies? But I admit that a good prototype is needed to make a final judgment.

We will have a meeting on this tomorrow. Let’s see what the others think.


What’s up with DTOs?

Having worked a lot with EMF and Eclipse RCP applications based on EMF as the framework of choice for transferring domain models into code, I never got in touch with real-life examples of Data Transfer Objects (DTOs). I was familiar with the pattern in theory, but I never saw a DTO in practice since EMF works fine without them, even in a client-server architecture.

This changed recently. My new project is a client-server system which does not use EMF for implementing its domain objects. DTOs are used heavily to transfer data from the server to the client and vice versa. During my first journeys through the unknown code base, I stumbled upon a lot of DTOs and wondered what they were needed for at all since they seemed to introduce a lot of redundancy and required a mapping to and from the entities managed by the server. Wouldn’t it be more efficient and practical to simply use the entities as the shared domain objects on the server and the client? What is right in the EMF world cannot be wrong in the JavaEE world, I thought.

So I did some research and found this blog post by Adam Bien who seemed to confirm my doubts. “JavaEE 7 retired the DTO” was all I needed to hear in order to start a discussion with one of my new colleagues about the whole purpose of DTOs in our project. He was nice enough to take a long break from his current task and give me an extended explanation of why and how DTOs are necessary in our project. He answered all of my questions patiently, even if some of them were perhaps a bit naive and showed my lack of experience with some aspects of JavaEE. Needless to say it was a fruitful discussion.

I did some more research the next day based on his explanation. When I was finished, I had changed my mind. I am now convinced DTOs add value to our project despite the code duplication and the extra efforts for the domain mapping because they embody more than a simple transfer mechanism . Here are the pros and cons of DTOs based on my current understanding:


  • Duplicate code (duplicate data models, duplicate constraints,…)
  • A mapping to and from the domain objects is required


  • DTO exposes the domain model in a form that is tailored for the client’s needs
  • Entity should be managed by the server all the time, never deattached from it
  • Can save bandwidth by carrying only a selected subset of the entity’s attributes/dependencies
  • No client dependency on JPA if entity uses JPA annotations (e.g. for constraints)
  • More pros here on Adam Bien’s blog

Resources I found helpful