java

„Building microservices“ re-visited and reflected…

It seems that „Building microservices“ finally made it to general availability. Actually, I’ve been following the book quite a while now, signed up (and bought the ebook version) pretty early during its early-access phase, and, finally, am pretty pleased with what the result looks like…

HTTP caching and unirest-java

In one of our modules we make use of unirest client library for Java in order to access remote REST endpoints. As, right now, this involves quite some communication, we were looking into response caching which seems both an obvious idea and yet something that is defined pretty well in HTTP and, too, implemented pretty well in apache httpclient which lives at the core of unirest. And actually, even though

Jetty, Micro Services and re-shaping things.

Last week, the Java part of our system went productive after a major runtime update – and it did so not on top of the Glassfish application server we’ve been using so far but rather re-structured into multiple modules embedding a current version of Eclipse Jetty. This is a fairly large change and quite a step, still sort of a work in progress and, after all, once again something worth

unirest: cross-platform REST client.

Stumbled across unirest last nite while ultimately feeling a bit unhappy with Java EE / JAX-RS frameworks. These folks in some way got my mind re-sorted a bit. I am still playing with this, yet there are a few things I already like about that one: It’s available. Same as some things I saw on Spark, Sinatra, Mojolicious earlier, it helps to see a REST client framework making an equal

Profiling OSGi applications using VisualVM

Recently been into working with OSGi modules built on top of Apache Felix using the Eclipse bndtools. This ain’t fun all the time, but it works. However, I am then and now using visualvm for profiling and monitoring issues. With OSGi, at least the VisualVM profiler doesn’t work out of the box but instead causes a lot of fun just like this: java.lang.NoClassDefFoundError: org/netbeans/lib/profiler/server/ProfilerRuntimeCPUFullInstr at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582) Caused by:

Prototyping think project! SOAP clients with Jython

Though I mostly use (server-sided) Java technology in my day-to-day work, I am then and now intrigued by Python as a straightforward, accessible scripting language which is easy to learn, easy to teach and immensely powerful in many situations. However, there are situations in which I just wished to have frameworks from the Java world available in Python… SOAP, to start with. Fortunately, Jython has been around for quite a

Refactoring and removing.

Deleted code doesn’t contain bugs, they say. I always felt kind of unsafe with the idea of actually and straightforward removing code while into refactoring smaller or larger parts of the systems – after all, same as it doesn’t contain bugs, deleted code also doesn’t contain business logic anymore which might not be what you want at times. Yet, trying to clean up parts of (the Java / Java EE

a clueless start to node.js

node.js is a technology that has been on my „to-try“ stack of technologies for quite a while now. There has been quite some fuzz out there recently regarding this framework, and as so far I wanted to have a closer look on what’s possible in JavaScript outside the browser, anyway, it seemed a good reason for dealing with something „new“ just for the sake of it, even without immediately having

hitting the golden hammer.

More than once, the last couple of weeks I repeatedly stumbled across situations in which I had to remember the infamous Law Of The Instrument in order to explain some peoples attitude towards technology and overall technological decisions. I am not sure if this „law“ holds completely true all the time, but I am sure there are some valid points to it.