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…
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 undocumented in unirest, getting this done has proven to be mostly straightforward. Yet I decided to do a quick write-up, maybe it will help others get started faster.
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 writing a bit more about…
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 set of features and mostly the same API available for a bunch of different languages, maybe so far only missing Perl. Things-that-don’t-bind-you-too-much-to-a-particular-runtime for the win.
- At least in the Java implementation, it wraps proven libraries such as the Apache Commons HttpComponents packages and provides a more “accessible”, more straightforward API for doing the things you need in REST. Especially plain HttpClient or some of the JAX-RS client implementations tend to make you get lost in implementing loads of boilerplate code for the 80% of things you need just because all the API is built around the idea of supporting 100% in a “generic” way. At least I surely don’t want to implement a bunch of subclasses, filters, authenticators and the like just to send HTTP BASIC authentication headers. Though, at least, this seems to have grown a bit easier in recent versions of Jersey, by then it still is pretty much implementation-specific and sucks if you use JAX-RS API as this is not part of the API and so ties you to a particular JAX-RS client implementation – not what you want when explicitely using the API. Anyhow, Unirest does provide 100% of features here, but it does rather well at making the 60..80% (guessed numbers, maybe they are even smaller) of commonly used features available in a very readable, very straightforward and sane API. That’s how it possibly should be.
- Fortunately, unlike some (many?) other Java REST client frameworks, unirest doesn’t stumble the pitfall of providing yet another static (as in compile-time) xxxx-to-Java-classes mapping that tightly binds particular (JSON) properties to Java class members and makes at least parts of your code fail the very moment the wire format changes. I mean, seriously: Even each and every JSON representation will be likely to contain fields that are mandatory to your application (and, consequently, cause trouble when absent). In most of these situations, you will have to find some way how to deal with these fields being absent, so maybe it doesn’t matter whether your application will throw a custom exception or just handle an exception thrown by the JSON-to-Java mapper at the core of things; and, in case your application provider quietly and without any announcement makes substantial changes to a published API, you will need to do some talking anyway. Yet, looking at a representation such as JSON where formal validation usually doesn’t happen and most of the structures are convention rather than enforcable interface contract, maybe once again going with Postel’s Law is a good thing, so maybe there are better approaches for translating JSON representations to data structures usable in Java than compile-time mappers.
As for now, moving forth seeing where unirest takes me. So far the trip has been pretty pleasant.
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:
Caused by: java.lang.ClassNotFoundException: org.netbeans.lib.profiler.server.ProfilerRuntimeCPUFullInstr not found by org.apache.felix.http.jetty 
... 2 more
There’s a blog post out there explaining how to set up various profilers to work with OSGi, which also includes VisualVM. A bit of playing makes this work with Eclipse and bndtools, too. Not much to add, except for that it’s important to, in Eclipse / bndtools, put the “right” things in the right place:
- Download an up-to-date version of visualvm, see here. Unpack this to a meaningful folder.
- In your
bndrunconfiguration file, add
-runvmsection. This should make your Java VM include the
jfluid-server.jar(the part of the profiler that includes the required classes) on startup.
- In the same file, add
-runpropertiessection to make OSGi find the classes included in this package.
By then, you should be able to connect VisualVM to an OSGi framework running from within Eclipse / bndtools and enable CPU and memory profiling just the way you’re eventually used to.