Recently, I was building a website with documentation for one of the projects I’m involved with. I wanted to protect access to that website to a specific set of people inside my company. Here’s how I did it.
When you want to transmit binary files over SOAP-based webservices, you have two choices: Base64 or Message Transmission Optimization Mechanism (MTOM). The latter is much more efficient, but also harder to troubleshoot if it doesn’t work at once. Both options have their own typical scenario Serialise the file content using Base64 and include the result right into the XML structure. This is relatevely easy to implement and troubleshoot. It usually works well for small binary files, but as files grow larger, you may run into performance issues.
Last month, I did a talk at GOTO Berlin where I explained the basics of Transport Layer Security. During the talk, the audience asked a few questions through the app. One of them was: “How does Beast work?” and I wasn’t able to answer that one on stage, unfortunately. Since it’s an interesting question, I’ll answer it here. Unfortunately, understanding BEAST is a bit harder than the talk itself… BEAST stands for Browser Exploit Against SSL/TLS.
Recently, Twitter brought the renaming of Ozark to Krazo to my attention. It pulled my attention: I had never heard of either projects, and I wondered what they would be about. Ozark (or Krazo) will be the Reference Implementation of the new Model-View-Controller Specification. This MVC specification, also known as JSR 371, was planned for inclusion in Java EE 8, but eventually dropped. Apparently, this didn’t kill the effort. I was curious to see where the specification (and it’s implementation) would be now.
There are many situations when you need to write a SOAP-based webservice. Maybe you are writing a test dummy, or maybe you got the interface from some kind of architect. (Yes, there are other reasons, too.) And chances are you’ll be using Spring-WS to do this. Recently I was doing that, and I found the following inside the interface definition (WSDL): <element name="faultMessage" type="common:FaultMessage"/> <message name="faultMessage"> <part name="faultMessage" element="tns:faultMessage"/> </message> <portType name="someName"> <operation name="searchOrder"> <input message="tns:searchOrderRequest"/> <output message="tns:searchOrderResponse"/> <fault name="faultMessage" message="tns:faultMessage"/> </operation> </portType> That was a rather challenging thing!
Recently, my co-worker Willem pulled my attention to the .NET Microservices. Architecture for Containerized .NET Applications e-book. Although I have a strong background in Java and the Java platform, I started reading it, and soon I felt like trying it out. But building software without having automated builds and tests is not the real thing, so that was the first thing I wanted to do. I usually use CircleCI for that, but unfortunately they don’t seem to have an official guide for that.
Every now and then, there’s this moment where you feel a certain urge to draw a diagram. Oftentimes, I feel a similar urge to make a digital version of it. But I don’t always have professional tooling around - and no, PowerPoint or its friends are not what I’m looking for. Recently, I found a tool that fits my idea of “good tooling” rather well. So, without further ado, let me introduce you to PlantUML!
Last Tuesday was the first edition of JVMCON. This conference has a special programme committee: its audience. When the Call for Papers closed, everyone who had a ticket could see the submitted papers. Only, they could not see who submitted the paper - which let them focus on the papers themselves. Out of almost 180 papers, they had to select 13… And guess what: one of them was mine! I presented my talk for the early birds, and there were quite a lot of them!
A few weeks ago, I wrote about migrating an existing Spring-application to Java 9. When I finished, two things remained to be investigated: Code coverage for unit tests. A bunch of warnings when running the application in Tomcat. Code coverage for unit tests As Alan Bateman pointed out, upgrading JaCoCo to its latest version should resolve the issue about the $jacocoData field. In fact, I thought I had done that, but somehow I kept on getting the same error every single time.
I recently participated in a Twitter conversation about upgrading to Java 9. Like most of the people, my current projects are all on Java 8. Of course the question came up, why don’t you upgrade? Good question! Since I hadn’t even tried, I decided to see how far I could come… The component I took for my experiment is a pretty simple Spring application. It doesn’t use Spring Boot. It exposes a few REST endpoints, and calls couple of webservices over SOAP.