Jürgenization | noun | jərgenajzeʃən
The process of turning code to solve a problem at hand that might look sufficient at the first glance into rock solid, quality assured, perfectly documented and extensible code. This process might consist of a complete rewrite of the code that originally made it into the process (Karma level 0) to only minor modifications (Karma level 10), usually depending on how often the author of the code to be jürgenized has made it through the process yet.
The term originates from Jürgen Höller, Spring framework lead developer, coining this kind process to deal with code contributions about to make it into the Spring framework. To get your code into the core codebase, you and the code get jürgenized.
Nowadays the term usually relates to the process of code quality assurance, in particular around Spring eco-system projects.
I’ve been recently pulled into some Twitter conversations about the quality of the new open data portal “launched” by the German government available at govdata.de. I put launched in quotation marks as the launch has been a rather rocky one critized through out the web.
I in particular made fun of the very verbose api resource the portal exposes. If you do a GET on it all you get returned is a:
{ "version" : 1 }
What I was trying to point at - and I think most of my Twitter followers are aware that I am into the field of REST web services a bit - is that it’s absolutely sad that it’s 2013 and we still see “APIs” published to the web that lack any kind of hypermedia elements. My initial tweet caused a bit of response and started some interesting conversation.
I am currently travelling conferences and Java User Groups with a talk called “Whoops! Where did my architecture go?”. It discusses approaches to create and maintain logical architectues in Java code bases, challenges, tools and tries to outline some ideas how one can accomplish this. A core part of the argumentation is the discussion about the importance of Java packages. Jens Schauder has written a blog post about that topic recently and I felt I had some things to add. The more I though about it I got the conclusion that a comment I envision would exceed the length of a reasonable reply I thought I’ll write up a blog post. I will point to the slides of the presentation in places where it comes in handy. The talk is also based on a lot of sample code which we will get to a bit later. The code can be found on GitHub.
When my former Wordpress-based blog crashed quite a while ago, I didn’t really bother to set it up again as I was to busy with other things. But as I felt the urge to go beyond Twitter posts to elaborate on certain topics in the recent time I thought I’d give it yet another spin.
Pretty much every application out in the wild is using logging to some extend. As applications tend to have bugs (yes, yours as well) it’s a common requirement to alter log levels at runtime. As JMX (Java Management Extensions) is a standard to monitor and manage applications it seems to be a reasonable approach to expose the loggers used in an application via JMX to allow tuning of log levels via a JMX client like jconsole. So let’s take a look on how you enable JMX with Spring.