After using the same font for everything, I recently fell in love with this absolutely beautiful and extremely readable font.

For years and years I've been using a terminal font that I modified to add support for ASCII-art and some Menlo Powerline glyphs. I was quite satisfied with the font, but over the last few years I've noticed that my eyesight isn't what it once was, and I've had more trouble reading the font and having to zoom things in more often. Also, the ASCII-art got screwed up at a few font sizes. Finally I simply have had a feeling lately that the font didn't "pop" as much as it once did. (I cannot for the life of me remember what font I based it on, and I guess it really doesn't matter).

The other day while watching an Emacs tutorial on YouTube, my jaw dropped. The font used by the author of the video looked, in my honest opinion, stunning. And, at least for me, was extremely readable compared to anything I've used before, even when very small.

I trawled github to find out what font it was. And finally, I found it: Iosevka. (And just in case the web site disappears sometime in the future, the font is available on github.

Not only is this font good looking and readable, but it's also very impressive. The font is actively developed. It has an insane amount of glyphs available, and more are being added. It comes in many different varieties, and each variety has a full range of variants. Everything is available as TTC, TTF and webfonts. It even has an online customization tool that allows you to generate fonts with only the exact variants, glyphs and varieties you need. To see every glyph available in every variety and variant, there is a specimen tool.

This is now my default font for more or less everything I do, and I highly recommend checking it out, and testing it your self.

A long time ago, and as soon as it was commercially available, I purchased an automationbridge. I was so stoked about this product, and it's been a central but silent part om my smart home ever since.

The reason I was so stoked was because at the time my main smart home controller was a Fibaro Home Center 2. Which is a great device, and I highly recommend it if you want a perfect balance of things that just work, but still be able to do things your self (using LUA, which off course isn't optimal, but hey it's better than nothing). But let's face it. Fibaros Google Home integration sucks big time.

Which leads me to the automationbridge. This fancy little device (it's a raspberry pi with custom software on an SD-card glued stuck), bridges your smart home controller with Google Home or Alexa, and lets you easily do anything you can do in your smart home through voice commands (and much much more). It gives you Google Home and Alexa integration the way things should have been done.

Currently the supported smart home controllers are Fibaro Home Center HC2 & HC3, Fibaro Home Center Lite, Vera Edge/Plus/Secure, HomeSeer, Home Assistant, RTI XP Controllers.

But it can do a lot more. It also has modules for a bunch of third party integrations such as Logitech Harmony Hub, Netamo, Belkin Wemo, Bose SoundTouch, Sonos, LIFX, etc. The list is way to long to show everything here. Just be aware that these additional plugins cost extra, and you purchase them individually. I haven't used any of these, but one of these days I'm going to pull out my Harmony Hub and connect it, and find something smart to use it for.

The automation bridge is super easy to use. You simply plug it in, connect it to your network, and run through a very easy to follow setup. This is a true plug and forget device. The only problem with that is I log on to it about once a year, realize it has a bunch of firmware updates to be installed. I install them, and realize that they have added a bunch of new features that I probably should investigate, but never get around to.

A different, really great feature is the notification feature. This allows you to send audio notifications to one, or all of your google home devices directly from a script on your home automation controller. You can also set up default notifications that trigger based on events from your controller, with a custom message, and custom set of Google Home device targets, directly on your automation bridge. Only your imagination limits this. I've among other things used it to have a voice inform the burglar that the alarm has been triggered, and warn me if the balcony temperature is too high and my plants are going to be unhappy.

But notifications allow you to do more. Based on events you can also trigger sending a message to Pushover, or call any number of custom webhooks. I haven't used these additional notification features, as they were a later addition, and I already have my own custom Pushover and webhook integration I wrote myself running on the Fibaro Home Center 2.

Finally it also has a feature for building panels for use on wall mounted Android tablets or iPads. I haven't tested this feature as I prefer to make my own wall panels running on raspberry pi with my own custom software.

So yeah. If you use Google Home, and have one of the listed smart home controllers I highly recommend investing in one of these devices, as they make life easier and makes your smart home just that much more smarter.

By the way, the Fibaro Home Center 2 is still my main smart home controller, but it now runs in tandem with a Futurehome Hub.

So ever since google tricked me into heavily going into their home automation ecosystem, by asking if I wanted to help them test something cool which I would have to sign an NDA for, which turned out to be a google home mini that supported Norwegian before they launched in Norway, I've used google assistant a lot. (So one of my google home minis has a sticker on it saying it is a preview and is illegal to sell, trade or give away).

Google home is everywhere on in my life. I've got lots of google home, google home minis and google home hubs all throughout the apartment. I use google assistant on my phone. I've integrated tasker heavily with google home, and plan on setting up multiple old phones with tasker for various other integrations. I use a automationbridge (I'm writing a post about this product soon) to integrate my Fibaro Home Center 2. I've got lots of custom stuff running on raspberry pi's. And lot's of other google home integrations going on.

Oh, and did I mention that "ok Google, remind me to ...." basically organizes my whole life?

Anyhow. I've always felt that one thing was missing from the ecosystem. A good desktop client. When working from my laptop, or my stationary computer, talking to a google appliance across the room, or grabbing my phone is just a pain. It takes extra time, and it disrupts my work flow. I've always wanted to be able to with a keyboard shortcut send a few lines of text to google assistant. But this hasn't been possible, until now. (It's also possible to use your voice, but keyboard is so much faster)

I happened to stumble across this project randomly, and it's everything I was looking for. The Google Assistant Unofficial Desktop client. And even better, it is cross platform, so it works on Windows (yuck), it works on Mac (a little less yuck), and it works on GNU/Linux (yay).

There isn't that much more to say about the functionality. It is what it says it is. Google assistant on the desktop. However, there are a few things you should be aware of. First of all don't expect all of the features you find on your phone, or on your google home device for that matter. The app is unofficial, but uses Googles official public API. That means that you only have access to the features Google has chosen to provide through their API. Some features they reserve for their own internal implementations, and such features naturally aren't available.

In addition the project is young. Hence there are bugs, and the feature list isn't huge. But it is under continuous and active development. So more features are continuously added.  

Finally a note on installation is needed. Since this is unofficial, the activation process needed isn't trivial. You need to register to get access to the API, and register the app as a trial application. That means this isn't for the people who simply can't handle anything more advanced that plugging something in to the wall (of people who feel they are to fancy for anything other than plugging something in to the wall and will gladly pay through their nose and use sub par products and services to prove their point - I'm looking at you Apple users). Fortunately, the main developer has made a very clear and concise illustrated guide to installing and activating the app, so anybody who can read and see pictures should be able to install it.

So if you use Google Assistant, I highly recommend you try out this app.

https is easy, simple, free, and soon to be "mandatory". All of my sites and services use https, always. This was done as a project over time quite a few years ago, combined with converting all of my sites and services to run on docker which I touched on in my previous post, and will be covering in the future.

Originally, everything ran on a couple of payed, catch-all wildcard certificates from startssl. After let's encrypt launched, I decided to move everything over to them. Not really to save money, but rather because I had a feeling that let's encrypt would be huge, and something that I really should learn more about as soon as possible. And boy was I glad I did when the whole startcom drama occurred.

In this post I will describe the technology I used to create a zero maintenance let's encrypt based system for all of my sites and services, including automatic http->http redirects, that is future proof (meaning that adding new services or sites require zero effort regarding https, as long as they run in docker). But first a few thoughts on https in general.

Why https is important, and something you need to know

Back in the days, https was something you needed if you were an online bank, doing e-commerce, running a secure corporate network, or something else "important". Some years ago, this started to change. It started as a trickle, but recently the faucet has been opened, and now everybody online needs to relate to it. If you publish stuff online or run any kind of online service, there is no way around it. If you are "only a consumer" you still need to relate to it, and if you don't you will be in trouble at some point. Hint: Do you always ensure any site you enter any personal information on is encrypted?

The main deal here is that you need to ensure that all of your personal information is secure online, including your browsing habits. These days, anything you do online without https (or when talking about non-web stuff, without encryption) is up for grabs by anybody between you and whatever end point you are accessing. This isn't anything new, but awareness of it is much greater, and it's no longer only the "nerds in the closets" who have access. It could be anybody. And if you are on a non-private wireless network (which is more and more common, wifi is everywhere), you can almost guarantee that the baddies have all of your unencrypted information.

In other words, doing anything unencrypted online today is a bad idea, period. But wait, you might say, I don't have anything to hide. Hint: Everybody has something to hide, you might just not think about it all the time. Would you post your VISA number and PIN-code online? Would you post your social security number online? Would you post all of your web history online? Even if you somehow exist in a parallel reality where you would post all of these things online, by not using encryption you are harming those whose lives depend on encryption being available. There are lots of people out there whose lives depend on being able to use encryption freely, such as dissidents in suppressive states and dictatorships, whistle blowers, people fleeing from persecution, abusive relationships or even the mafia. If you use encryption when you strictly don't feel the need to, you help create plausible deniability for those who do need it, and you help ensure encryption options exist. If you don't you indirectly harm them. Off course, this is an even broader area than just https. Encrypted email, chat, voice, etc. is just as important.

By always using encryption you are also protecting your self from spoofs, traps and tricks. There are lots of ways to attempt to fool you into believing you are visiting a different site than you actually are. The reasons can be many, including stealing your information, tricking you into clicking on ads to generate revenue for somebody, or installing viruses or malware on your computer. By always using https, some of, but of course not all of these tricks are foiled.

Finally, because of all of the issues mentioned above, browser vendors are starting to enforce the use of https. This includes showing a big red warning to all users that your site is not safe if you don't use https, blocking any new web functionality, so no https, no new web features will work on your site, and down right blocking you completely. The vendors started slowly, but are getting more and more aggressive, and we are most likely not far from a situation where https basically is mandatory for all presence on the web. The unencrypted web is soon to be broken. If you haven't already, now is the time to prepare.

Pros and cons?

There are two options. Embrace the change and be happy, or complain and make a fuss. But in the end, complaining will get you nowhere. This is happening, it's happening now, and it's happening fast. It (should) impact everybody, and nobody can change it. So embrace it instead. Hence I'm not going to say much about pros and cons. But one of each are worth mentioning.

The main pro is of course that this is needed. And it has been needed for a long time. So that this is finally happening is great.

The main con has to do with access to technology. Web publishing of simple content is easy, very easy. All you need is a server, or a computer that always is on, and a public IP-address or a forwarding service. In addition you need to acquire some simple knowledge of HTML and how to install a web server. That's it. But once https is defacto required for everything, since your published content will be banned by the browsers, much more technical knowledge is needed, and it is no longer a trivial task to learn. This is a shame since it hinders access to knowledge, and can kill the joy of learning by making the initial threshold higher.

Let's encrypt

To make the mentioned shift possible,the Mozilla foundation started working on a free, easy to use system called Let's encrypt. Today, a lot of major players sponsor the Let's encrypt. Https used to be expensive, and fairly unavailable. Let's encrypts goal was to change this.

Let's encrypt is free to use, and you can create as many certificates as you want for free. You can do it manually, but the certificates are only valid for three months at a time. Fortunately Let's encrypt provides a very good API that allows easy automation of certificate creation and renewal. Furthermore, basically the whole world of service providers and application developers have embraced Let's encrypt. Most applications or services either provide a plug-in TODO TAG PLUG-IN? or already have Let's encrypt built in. You'll also find multiple API-implementations for basically any programming language out there, even lisp.

Let's encrypt makes basic https free and available for everybody, which is great. Advanced use, the kind of use required by banks, e-commerce, etc. isn't covered, but that's ok. This service is for the broad public, not for the huge corporations.

Technical awesomeness

I promised you some technical goodies, and here they are. As mentioned in my previous post, I have converted all of my sites and services to run on docker over the last few years. I'm more or less in love with docker, and basically have my whole life in docker these days. As part of this process I converted everything to use https. Initially I used a master certificate I payed for, but as soon as Let's encrypt was mature, I decided to switch, a choice I'm very happy with. Fortunately, I decided to try to make a system that was automatic, and future proof. In other words, no maintenance needed, and adding new sites or services should be trivial.

While converting all of my sites and services to docker, I also set up https for all of them. This was done using a single nginx instance running in docker using the fabulous docker image jwilder/nginx-proxy. This runs as a single nginx container instance, and listens to docker waiting for new containers to be started. By adding a few environment variables when spinning up a new container, you can instruct nginx-proxy that you want to be proxied with the given url. Nginx-proxy automatically detects this, automatically creates a proxy configuration, and reloads itself. Hence you can automatically add new services to your proxy by simply adding a few environment variables to the command when starting the service. No need for any manual configurations or restarting containers. Nginx-proxy handles everything.

Nginx-proxy has a single configuration copied and used for all existing and new proxied containers. In addition, you can specify individual configurations for individual containers (based on hostname) if needed, but naturally this process does require a reboot. If you already have existing purchased https certificates, you can add them to nginx-proxy, again identified by host name. This is how I originally did things. Finally, the proxy will, when you use https, ensure that any unsecure requests automatically are re-directed to secure requests. This can be disabled if you want to, though I cannot fathom why you would. Not only is this important to ensure the security of your users, but google will index your secure and non-secure sites as separate sites, so serving content (the same or different) on both can cause issues with your search rankings.

I plan to give a much more detailed description of the setup I've used for docker in a later post.

Adding Let's encrypt to the mix

Since I already had this system when I wanted to convert to Let's encrypt, I decided to investigate if I could find something that worked well with the system I already had. And fortunately I did.

The component I found was JrCs/docker-letsencrypt-nginx-proxy-companion. This nice little component runs as it's own container and hooks into the system described above. It allows using Let's encrypt as a part of the system, again by adding a few environment variables when creating a container, in the same way as with nginx-proxy. These environment variables instruct the companion to retrieve a certificate from let's encrypt if an existing valid certificate doesn't exist. The companion then handles the certificate generation, and instructs the proxy to use that certificate for the new container it has been instructed to proxy.

This makes adding certificates to the system easy as can be. All you need to do is add a couple more environment variables to the command you use to create your instance, and bobs your uncle.

The companion also ensures the certificates stay up to date—remember they are only valid for three months—without any manual interaction. In addition to the daemon listening for new containers, the companion runs a "cron job" that periodically checks the validity of the certificates in use. By default, any certificate that will expire in less than a month, will automatically be renewed.

Shortcomings of the setup

The only shortcoming I've found with the system, is an issue that most likely not many people will encounter. The shortcoming only applies to the Let's encrypt companion. Basically, the companion doesn't handle multiple instances very well. If you run multiple instances of it on the same system, they will all trigger on all actions, and try to create or renew certificates that they themselves don't "own", resulting in error messages, and unneeded communications with the Let's encrypt API. The system is still fully usable, but the added error messages in the log, and added traffic to Let's encrypt are annoying.

And in case you wonder why I would have two instances, the reason is I have individual nginx proxies listening to two different IP-addresses on the same machine. I initially had to do this to allow incoming webhooks from a system that couldn't handle wildcard certificates. This prompted me to set up a different IP-address on the same system, not only for webhooks from the mentioned system, but all incoming webhooks. Feels nice to be able to keep incoming webhooks separate from the rest of the system.

Should I do the same?

You might be planning on doing something similar yourself, and wondering if you should create a setup similar to the one I created. The answer to this is: probably not.

I learned a great deal and had a lot of fun while implementing the system, and I'm very happy with the result. I now have a stable, reliable and extendable system that requires little to no maintenance. However, getting there was not trivial. It required a lot of trial and error, reading documentation, reading code when documentation wasn't available (more often than not), and a couple of restarts from scratch.

Unless you actually want to do all of this tinkering (for fun, or for profit) or you want to learn more about docker, let's encrypt and nginx, you probably shouldn't go down the same route I did.

If you simply want something robust that works, you probably are better of going with a more "out of the box" system, such as Træfik. Granted, learning Træfik is probably just as much work as setting up the system I described above, but you'll get a whole lot more for free (such as a nice UI, clustering support, metrics, an API, etc.) You will also be learning something you much more likely will encounter in "the real world". Documentation is also a lot better, and I'm guessing that the technology most likely will exist longer into the future as well.

At some point I want to convert my system to use Træfik, and potentially also Kubernetes, but that is a task and a blog post for another day, and not something I highly prioritize at the moment.

If you only take one thing away from this blog post, I hope it's that you have to be conscious of https and encryption and actively relate to it, no matter who you are.

You might have noticed recently, that gsmblog suddenly got a new fresh modern design. But this isn't a simple re-design. This is a complete revamp, and a total re-write from scratch. And it didn't happen over night. The future of the blog is bright.

Before I continue, I want to make one, rather bold, statement. The blog has basically been dead for a long time now. That was due to a couple of things. First of all, life happened. I've been busy with a new job, a new apartment, lots of personal projects, and generally lots of stuff going on. Secondly, even though the blog was in its fourth third iteration, I was far from happy with the tech. It started on Joomla, moved on to Drupal, and finally Wordpress. But none of them were good. They were large, heavy, slow (hence needed varnish to function properly), and based on php (so based on a nasty language with fairly sloppy code, and full of security issues). Now, in its fourth iteration, I think I finally have found the ultimate permanent solution. More on this soon.

Currently the whole blog has been converted. The only thing missing is comments. I've moved to using an external comment system to make life easier, and it seems that importing the old comments will require some manual work, but I will move the few relevant comments over at some point.

Introducing Ghost

Without further ado, let me present Ghost. I came across Ghost when looking for a simple blog software for work. We needed something simple. Something that a bunch of nerdy tech heads could use without annoyance, without lots of bells an whistles. And, since we also wanted to use it as a first steppingstone to start moving services to the cloud, we wanted it to be docker friendly. After testing and evaluating a bunch of different alternatives, I came across Ghost. And I was really impressed, even if it wasn't even a full release version yet. So, why so great?

Modern technology. API

First off, Ghost is based on modern Javascript technology. Now, I'm not always a huge fan of modern Javascript "hipster" technology, but when done right, I like it. And Ghost did it right. Not only is it modern, but their choice of technology makes it lightning fast out of the box. No need for varnish any more. And their markup (HTML and CSS) is modern as well.

Ghost is also fully API based, with both a public and a private API. So no vendor lock in, data is available, and simple to export or use within other applications. My personal opinion is that any data that isn't available through an API is useless, and nobody should publish such data. Also, all of the data is stored in a very simple, available format, easy to extract even without the API.

KISS, markdown and anti-WYSIWYG

Possibly even more important is the wonderful editor, their KISS (Keep it stupid simple) philosophy and anti-WYSIWYG stance. The editor is based on markdown, and as a nerdy guy who writes code, any software that allows me to use some sort of markup language, like markdown is great. It's easy, flexible, simple and available, and doesn't require me to use that pesky mouse. Finally, they have done something, that I really wish more products did, and made the markup first citizen and downplayed WYSIWYG. I loathe WYSIWYG editors, and avoid them at all costs, and Ghost has provided a few buttons for those who absolutely have to have some sort of GUI, and preview mode. In other words, a perfect balance. Finally full HTML can be inserted anywhere, which is great.

Fast and flexible

Ghost is also very simple and easy to deploy and configure. A few simple commands are needed, and a couple of settings in a config file are needed, and you are set to go. Or, if you use docker all you have to do is to pull and run the docker container, no configuration needed. Once you are done testing or creating your installation, preparing for production is even simpler. All you need to do is change a single parameter in the configuration file, or if you use docker, add an environment variable to your docker command.

Creating a theme for your blog (if you don't want to purchase a theme in the marketplace, or stick with the default theme) is simple, understandable and, for a developer, trivial. The easiest way is to start with the default theme and adapt it to your needs. This couldn't be easier. You simply clone the git repository containing the default theme. Run npm install and away you go. Naturally you have automatic compilation on changes. Once you are done, you run a single build command, and upload the resulting zip to your blog. The css and templates are clean, easily understood, and the documentation is good.

I don't have any experience (yet) extending or adapting Ghost, but from the looks of it, this should also be fairly easy as long as you know a bit about modern Javascript development.

Are there any downsides?

Not many. But note that if you are the kind of person who wants writing your blog to be similar to writing a document in Microsoft word, or you feel the need for tons of glorious bloating extensions, Ghost is not for you.

There are a couple of things I really would like though. I would appreciate a way to change and add keyboard shortcuts in the editor. The fact that I try to avoid the mouse as much as possible, and use a browser, and browser plug-ins geared to always using the keyboard, the editor comes up short when it comes to keyboard interaction.

Also, the editor doesn't play nice with browser plug-ins that allow you to use external editors to edit in-browser text, and has issues with in-browser spell-checking. Somehow the editor seems to not be identified as an input, which causes issues.

The tag-editor unfortunately lacks a couple of important features. The tags need to be ordered in alphabetical order, and allow ordering by frequency and order of creation. As of now, the only way to find tags is by searching, which is a pain.

Finally, a feature for custom snippets would be highly appreciated. Nothing fancy is needed, but a simple key->html addition would make life a lot easier. Optionally, one could allow the user to create markdown extensions.

The future of the blog

Hopefully this means that posts on this blog will be much more frequent in the future. There no longer is any kind of technical or WYSIWYG-annoyance hindering frequent posting. In addition, my new job provides me more spare time, and a much better possibility of investigating and learning new technology pro-actively on the job, rather than always just last minute learning based on whatever is needed for the next project. The list of posts I want to write has been steadily growing, so I'll most definitely never run out of topics to cover.

A small tech update

About a year and a half ago, I spent some time upgrading all of my sites, and all of my services to run on docker and got rid of my host running on tilaa and moved everything back to my original linode server. I might use tilaa for some things yet in the future, if nothing else for prototyping, but when linode dropped their prices tilaa no longer offered any big benefits compared to linode, and after experiencing some random kernel panics on their custom debian without them being able to determine why, I opted out for now.

Anyhow, the migration was a long ongoing process as I not only moved everything over to docker, but changed a bunch of technology stacks. One of the major changes was re-creating all of my static sites using spring boot. But a lot of other technology was modernized and replaced as well. I had planned a long series of posts about the process, but as mentioned, life happened. Some of the planned posts should appear in the near future though.

As mentioned, everything now runs on docker (basically my whole life is in docker now) which is a huge time saver, and makes life much easier and much more fun. I cannot recommend docker enough.

Future plans

Over time I'm hoping to continue to modernize my technology stack, and also complete some of the many side projects I've been planning for ages. At some point I would like to move things from bare bone hosting into kubernetes, however, at the moment google cloud (which I've been starting to investigate at work) is way to expensive compared to linode, and even self hosting kubernetes would be much more expensive than the bare bone hosting I currently do.

Photo by Thought Catalog / Unsplash

Maven is a great tool. I could spend a lot of time and effort telling you why, but if you use maven or have moved on to gradle or something similar, you already know why. That is not the point of this post. The point of this post is to get you, the open source software developer, to embrace maven the way it should be embraced.

One of the really great things about maven is that it, combined with a good version control system, such as git, allows you to work on your projects most anywhere with little to no effort. This gets even better when you combine it with something like docker, which allows you to create developer environments anywhere with little to no effort. Have a few hours to kill at a friends house or the library? Check out your project and work on it. Need to stay home from work to take care of your sick kids? Check out your project and work on it. Attending a dull meeting or conference? Check out your project and work on it.

Now in theory this works great. Unfortunately it's only mostly in theory. We live in a great time to be an open source dev. 99% of the time you can find libraries for anything you need thanks to github and friends. Unfortunately most of those libraries aren't available in a maven repository. You have to clone the project, and install it locally. Which sucks. It makes things hard. And it makes the scenario I described above a pipe dream. Any time you use one of the many great libraries out there, you end up with a project that cannot simply be checked out and worked on. You have to install all sorts of dependencies locally. The result is either a long check list of things that need to be cloned and installed before starting work, or the need to spend a lot of time creating scripts for bootstrapping your environment. This is unnecessary.

Why not simply run your own maven repository you might ask? I do, and I tend to share anything a put in there to the general public as well, but I shouldn't have to. And neither should anybody else. A private maven repository is a viable work around (because that is really what it is in my mind) for big companies and geeks like me. If you have the means and knowledge to do it. You need the dev-ops knowledge to do it, and you need the means to pay for virtual hosting to run it, since running a local maven repository doesn't add any benefits over simply using your local maven cache, you still have to install everything on each and every machine, and the whole point is to avoid that.

There is a very simple solution to this, but it involves all of the small time open source devs out there spending a tiny effort to make things easier for everybody. All you have to do is publish your libraries to a publicly available maven repository. Most of the big guys do it already. But even a lot of the big guys don't, which is a huge shame. The big guys aren't the people I want to reach here though, they can rest assured that their laziness makes me annoyed and I will voice my protests whenever I can. The guys I want to reach are you and I. The small guys. Publishing your tiny library on github. You rock. But you could rock even harder.

I get why you don't do it. You just want to get your software out there, and really don't care who uses it. I really get that. I'm the same. You might even think providing a maven repository is a lot of effort or will cost you something. It isn't, and it won't. You might think you need to be a dev-op and run your own nexus server. You don't. You can publish your project to the Sonatype Central Repository with very little effort and no cost.

By spending a tiny once off effort, you will be saving all of us lot's of time and effort, and we will thank you for it. And if we all do it, we will all benefit as well. And don't think your library is to small or not important enough to do it. If you put it on github, somebody will use it and in my honest opinion, that all it takes. If your project is on github it is important enough that it should be in a repository.

So please, spend the extra hour of time to help save hours and hours of time for us all.

As I previously mentioned I really really loathe having to install publicly available packages to my local maven repository. While working on my personal API project, which I will return to in a later post once I've worked on it some more, I came across the need to use quartz within dropwizard with guice for dependency injection. I came across this nifty little library called dropwizard-jobs. Unfortunately as so many great projects I stumble across on github, the project isn't available in a public maven repository. So once again I decided to fork the project and publish it in my public maven repository.

This time around the project seems to be actively maintained, so I've reached out to the dev offering him access to the repository I created in case he wants to push to it himself. If I don't hear back from the dev I will not be actively adding anything to the project, but I will maintain the fork and repository with any updates that hit the original repository. If I forget, feel free to reach out by creating a ticket on github. If the original dev decides to use my repository, I will abandon the fork after the initial pull.

The forked project is available at https://github.com/deadcyclo/dropwizard-jobs

The public maven repository is available at https://nexus.vanntett.net/content/repositories/dropwizard-jobs/

Photo by Tom Kulczycki / Unsplash

fitbit4j is a fully working java API client library for the fitbit-API. I currently started working on a project that I intent to integrate with fitbit through their API, and quickly discovered a problem. The official fitbit4j api library is not available in maven. However, fitbit pushed their maven releases to github, which sort of works but is quite nasty. Unfortunately the latest version that they published in such a way was 1.0.25 which is broken.

Some time after fitbit published this version they changed their API to enforce SSL, which is a good thing. However, this broke version 1.0.25 of fitbit4j. They pushed code for version 1.0.26-SNAPSHOT to their public github repository, but did not release it in their "maven repository" on github. So the only solution, until now, if you wanted to use fitbit4j in your projects was to build it yourself and install it to your local maven cache. This is not a good solution. I loathe having artifacts installed to a local maven repository as this makes distributed work a pain and involves a manual checkout process, or potentially a scripted checkout process.

Since I loathe using local maven I naturally have my own maven repository running. I therefore decided to fork fitbit4j on github, change the publication setup and publish 1.0.26 as a release to my own fitbit maven repository. Now, since I have this repository online, I'll also share it to the world, so you too can avoid installing fitbit4j in your local maven cache, and rather use a proper repository.

The forked project is available at https://github.com/deadcyclo/fitbit4j

The maven repository is available at https://nexus.vanntett.net/content/repositories/fitbit/

Feel free to use this repository as much as you like. fitbit4j seems to have been abandoned after version 1.0.26, or possibly their API simply is very mature. If fitbit pushes updates to fitbit4j, I will sync them to the fork and publish new versions to the maven repository. This is not a true fork, hence I am not intending to maintain the project myself, other than syncing anything fitbit does, and naturally since I rely on the API-client myself, I will fix the client myself if it in the future breaks without a fix from fitbit themselves. I am not planning on adding any new features to the project. However, if you want to contribute any changes of fixes you might have implemented, feel free to submit a pull request and I'll include them after a code review (If this does happen, I will maintain a set of maven repositories, one for the official version and one for the version containing 3rd party contributions.

I also have a heads up if you plan on using fitbit4j to investigate the fitbit API: don't. fitbit4j is fairly large and messy, written in your typical enterprise bloated way, and not very well commented. If you want to use an API library to investigate their API, you are probably much better off having a look at this third party python api library. It is fairly small, tidy and well commented.

Photo by Andres Urena / Unsplash

Have you ever tried to manipulate one of the web content meta data dates as an actual date in a Liferay Freemarker web content template? Unfortunately these dates are handled very poorly by Liferay.

They are returned as a formatted string, based on the default locale of the portal, unless you have manually changed the default locale of the structure the template uses. This means that the only way of obtaining the article create date, article publish date and last updated as actual date objects requires parsing strings, which in itself is a pain. Furthermore, since the date is formatted based on the used locale, you can't simply just parse the date either. Now in velocity you have access to a nice date utility that can parse a date string based on a provided locale. Unfortunately no such feature exists in Freemarker, so you have to change the actual locale of the template back and forth. Finally, not that this will only work if the default language of the structure the template is based on is the same as the default language of the portal. If they differ, your are simply out of luck as far as I have found out. If anybody knows how to solve this if these default locales differ, please, please let me know.

<#-- Retrieve the published date meta data field of the web content -->
<#assign displaydate = .vars['reserved-article-display-date'].data>

<#-- Save the original page locale for later -->
<#assign originalLocale = .locale>

<#-- Set the page locale to the portals default locale -->
<#setting locale = localeUtil.getDefault()>

<#-- Parse the date to a date object -->
<#assign displaydate = displaydate?datetime("EEE, d MMM yyyy HH:mm:ss Z")>

<#-- Set the page locale back to the original page locale -->
<#assign locale = originalLocale>

Now you can use the date as a normal date object in freemarker:

${displaydate?string["yyyy-MM-dd"]}

Other meta data dates

The following three meta data dates are available on web content in Liferay:

reserved-article-display-date
reserved-article-create-date
reserved-article-modified-date

So to use all three of theme, you could use the following code:

<#-- Retrieve the published date meta data field of the web content -->
<#assign displaydate = .vars['reserved-article-display-date'].data>
<#assign createdate = .vars['reserved-article-create-date'].data>
<#assign modifieddate = .vars['reserved-article-modified-date'].data>

<#-- Save the original page locale for later -->
<#assign originalLocale = .locale>

<#-- Set the page locale to the portals default locale -->
<#setting locale = localeUtil.getDefault()>

<#-- Parse the date to a date object -->
<#assign displaydate = displaydate?datetime("EEE, d MMM yyyy HH:mm:ss Z")>
<#assign createdate = createdate?datetime("EEE, d MMM yyyy HH:mm:ss Z")>
<#assign modifieddate = modifieddate?datetime("EEE, d MMM yyyy HH:mm:ss Z")>

<#-- Set the page locale back to the original page locale -->
<#assign locale = originalLocale>

And you would use them all as normal, for example:

${displaydate?date}
${createdate?time}
${modifieddate?iso_utc}

Photo by Sonja Langford / Unsplash

I've just published a Liferay Spring MVC Freemarker Portlet Maven Archetype on github. It is a maven archetype for creating Liferay Spring MVC Freemarker portlets. Since this type of portlet is not officially supported by Liferay, no archetype currently exists. This archetype amends that. Furthermore this is a much more complete archetype than the archetypes currently supplied by Liferay. This archetype generates a runnable portlet including a lot of examples of best practices and the best way of creating a Liferay Spring MVC Freemarker portlet. These best practices are influenced by both Liferays best practices, but also the best practices of several projects I am currently working on.

Note that the setup allows one to use either JSP or Freemarker as views or a combination thereof. When looking for a view, first the system looks for a Freemarker template with the given name. If no Freemarker template is found, it goes on to look for a JSP template with the given name. If neither is found, the system fails. Hence it is possible to create portlets with a mixture of both Freemarker and JSP templates.

This is the initial version of the archetype. Improvements will be added whenever possible. If you have suggestions, ideas, or better practices I would be very happy to hear them, or even better receive a pull request.

The archetype is free (all I ask is that you contribute any improvements you make back) to use and located at github.

Requirements for using the Maven Archetype

To be able to use this archetype you need to download and install Liferay Portal EE Maven, if you are using the enterprise edition. If you are using the community edition, maven should be able to find this itself. Note currently I've been using SP5 version, since when I started working on this project, no artifacs were published for later service packs.

Installation

1. Clone the repository
2. Run the command mvn install

Usage

1. In your Liferay maven project run mvn archetype:generate -DarchetypeCatalog=Local -Dfilter=com.liferay.maven.archetypes:
2. Select the number beside liferay-portlet-spring-mvc-freemarker-archetype
3. Continue as if you are using any of the archetypes provided by Liferay

Photo by Mohamed Nohassi / Unsplash

It seems that Samsung has broken Bluetooth tethering on their latest Galaxy Gear update for the Galaxy Note III, even when using the null_ ROM. But I have a solution. Are you having issues with extremely slow downloads and multiple time outs. Does it take ages to download from the Play store, or can't you download from the Play store at all? Read on.

The problem

I installed the latest update a few days ago, and today I needed to install some additional software on the Galaxy Gear. I simply could not get the Play store to work. It loaded and loaded, but never got anywhere. One single time I got it to start downloading, but after a half an hour the download of 2 MB was still at 3%. I tried absolutely everything, but could not get it working. I tried disconnecting my Bluetooth keyboard and mouse, thinking that they somehow were saturating the Bluetooth link. I tried connecting to multiple other phones and computers. I tried rebooting everything, multiple times. I tried clearing settings. I tried disconnecting and re-pairing devices. I even tried updating to the latest version of the null_ ROM. But no matter what I did, the issue prevailed. I googled for hours, with no solution found. However, I saw a lot of people complaining about this exact problem. I also so a lot of people answering that "Well, Bluetooth tethering is slow. This is ordinary." which, pardon my French, is complete BS. Yes Bluetooth tethering is slower than WIFI, but it is not that slow. You aren't exactly able do to HD-streaming, but downloading from the Play store, and surfing the web works quite fine (like it used to do before the last Galaxy Gear software update from Samsung. This kind of bad performance is quite obviously due to something being broken, and anybody who says different is not telling you the truth.

The solution

I was about to give up, when I finally stumbled upon a solution. First I paired my Galaxy Gear with my Samsung Galaxy S4 which does not have Samsung Galaxy Gear software installed on it. Next I turned off Bluetooth on my Galaxy Note III to ensure that the Galaxy Gear disconnected from it. Finally I activated Bluetooth tethering on my S4 and on the Galaxy Gear. Suddenly, working Bluetooth tethering with even better speeds than I was experiencing on the Note III prior to the latest Samsung Galaxy Gear software update. So there you have it. To get Bluetooth tethering working on the Galaxy Gear running the null_ ROM, you have to disconnect it from all devices running Samsung Galaxy Gear software, pair it with a device not running said software, and activate Bluetooth tethering.

Intentional?

I'm really hoping this wasn't intentionally done by Samsung, but I find it very strange that this feature, that worked fine when using previous versions of their software suddenly stopped working. Specially considering how much effort they have put down in only allowing authorized applications to use the Bluetooth link when running their stock firmware.

Photo by Allef Vinicius / Unsplash

As part of my complete makeover of all my websites I spent the last few weeks creating an application in sparkframework, a non-enterprise Java micro web framework. However, I never actually launched it. I came very close, and I'll get back to why not in a moment.

The spark framework

The spark framework is a tiny non-enterprise Java framework that gives you the bare minimum needed to create a web application, with just a few lines of code, and not much more. It provides embedded Jetty out of the box, so you can use it without rolling out your own app server, which is nice. It also supports Freemarker-, and JSP-templates. In other words you can assume it's great if you either like building everything from scratch yourself (and actually have time), or you are creating something very simple.

Just to give an impression of how minimalistic it actually is, and what it provides, here are the features:

• Routes
• Request
• Query maps
• Response
• Cookies
• Session management
• Halting
• Filters
• Browser Redirect
• Static files (in package and/or external)
• Freemarker and JSP templates with views

My application

And this sounded to me to be exactly what I needed. What I wanted to do was replace a whole bunch of sites with a single tiny small Java application. The sites in question are currently based on static html, Server Side Includes and a lot of HTTP redirects in Apache, so a micro framework should have been exactly what I needed. I spent a couple of weekends creating a very minimalistic application to handle this. The main class is only about 30 lines of Java code, supported by a few POJOs. In addition, the application included a whole bunch of Freemarker templates, three JSON files, and a few bootstrap 3 themes. Each page are rendered through a master template for the given site, and the page template included through it. I also included a fall back for unknown sites letting me render a "oops" site for any incoming requests to the sever that doesn't map to a known site. This allows the application to act as a "catch all" backend for Varnish.

The three JSON files define the structure of the sites. One file contains entries for each page of each site including sub-template to be used, title, path and any other site specific settings or content that are used across multiple pages. The second file contains redirects and the third JSON file simply contains a lists of all of my sites, since I want to include that list on multiple sites but maintain in from a single location.

Adding a new page to a site simply involves adding a new Freemarker template, and giving the page an entry in the first JSON file. Easy as can be. Adding a new redirect simply involves adding an entry to a JSON file. Finally, adding a new site involves adding new entries to the first JSON file and adding a couple of lines of Java code. The extra couple of lines of Java code should really not be necessary, and I was planning on changing this soon, until the problem arose.

The problem

Right before launch I discovered a problem, that ended up thwarted my whole effort. While testing the sites before switching DNS entries, I discovered that some 404 errors where rendered by a boring generic jetty 404 page. This was not my intention. My initial thought was to create a top level "splat" route at the lowest priority level, to trap any incoming non-recognized requests and spit out a custom 404 based on the site. But that broke static files, since routes have higher priority that static files no matter what in the spark framework. How about a filter? Include a top level end filter that checks for 404s and redirects based on that? Nope. The exit filter obviously also is applied before the static route. What about adding a custom 404 page to jetty? Not possible. The spark framework doesn't provide any customization of the built in Jetty server.

Leaving the only option to not use the embedded jetty but rather deploy the application on an external app server, which completely screws up the whole idea of the application. If that is the only option, why not go for Spring and get all of the Spring magic? Or simply make the whole thing from scratch based on an embedded Jetty? The whole idea of the project was a simple drop and run jar without any external dependencies, configuration or effort. Naturally, what I really should do is fork the project and add the option myself, but with my current TODO-list that probably will not happen for a good 10 years or so.

So there you have it. Custom 404 pages combined with static content and embedded Jetty in simply not possible in the spark framework which is a shame. So now I'm going to spend time redoing the project in Spring Boot instead.

Conclusion

The spark framework is a really cool concept. I really like the idea of being able to create non-enterprise applications with minimal a minimal footprint in Java. However, the lack of possibility to configure the embedded Jetty server is a big show stopper as far as I am concerned. Until that is fixed, I'll probably not be using the spark framework and rather making do with the "enterprizy" Spring Boot framework instead.

However, if you really like making everything from scratch yourself (I really do, but I've discovered that I never finish anything I try to make from scratch, so I've more or less given up on not using frameworks), and like non-enterprise Java (yeah, it really does exist), you most definitely want to look into the spark framework. And hopefully you like tinkering, and decide that you should contribute configuration of the embedded Jetty server to the project (I really wish I had the time).

Finally, spark is probably really great for prototyping and creating proofs of concept, and I'll probably be using it for that in the future.

Photo by Bhushan Sadani / Unsplash

Here I will guide you step by step through the process of creating Liferay Spring MVC portlets. I've already showed you how to create Liferay Spring MVC Freemarker portlets and how to create Liferay Spring MVC Freemarker and JSP portlets. However, both of those posts require the prior knowledge of how to create Liferay Spring MVC portlets. There are already several resources online that describe how to do this, but I find them either too verbose, or faulty, so I'm writing my own hoping to fix this.

Personally I find Spring MVC portlets highly superior to Liferay MVC portlets in many different ways. You can easily take advantage of spring injections. You use spring annotations for render requests, action requests and resource requests which, if you do it right, results in much more structured controllers with much less boiler plate code that are much more readable to human beings. Still doing things right, your whole project is more structured, organized and logical. You can also use Freemarker instead of JSP preferable. If you don't know why you should read 10 reasons to replace your JSPs with Freemarker templates on the Stack Hunter blog. Finally, your portlets end up much more maintainable simply because there are a whole lot more programmers out there that know Spring compared to the amount of programmers who know Liferay MVC.

Now, Spring MVC portlets might be great, and I highly recommend them if you are creating traditional portlets. However, if you need to create webapp portlets, you probably shouldn't be using Spring MVC. For webapp portlets, I recommend using Vaadin if you are creating a business application. If you are creating a non-business application, my preference is AngularJS, possibly combined with Spring MVC. I'll be writing more about both Vaadin and AngularJS in future posts.

Unfortunately Liferay doesn't provide us a means of creating Spring MVC portlets out of the box in their IDE or Developer Studio. I'm still hoping that they soon add this feature, and also fix the issue with Spring MVC Freemarker portlets that I show a work around for in one of my previous posts mentioned above. However, their new Maven support is a great feature though still a bit rough around the edges and Liferay 6.2 is a huge step forward. If anybody else created Liferay 6.2 it would be given the name Liferay Next Gen or something like that.

Step 1: Creating the portlet

To be able to create a Spring MVC portlet in Liferay, you first need to create a regular Liferay MVC portlet using the Liferay SDK, and then manually modifying it to become a Spring MVC portlet. Do this however you like, either by using the command line tool in the SDK or in your favourite IDE.

Step 2: Turn your portlet class into Spring DispatcherPortlet

Open the portlet.xml file in your docroot/WEB-INF folder and replace

<portlet-class>com.liferay.util.bridges.mvc.MVCPortlet</portlet-class>

with

<portlet-class>org.springframework.web.portlet.DispatcherPortlet</portlet-class>

Step 3: Create a Spring application context file

Now you need to create a spring application context file. Personally I prefer calling this file nameofyourportlet-portlet.xml in lower case rather than applicationContext.xml, since this makes it easier to add multiple portlets to a single portlet project without collisions. The file should be created in docroot/WEB-INF (the same place as your portlet.xml file) and should contain the following:

<?xml version="1.0" encoding="UTF-8"?>  
<beans xmlns="http://www.springframework.org/schema/beans"  
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p"  
     xmlns:context="http://www.springframework.org/schema/context"  
     xmlns:aop="http://www.springframework.org/schema/aop"  
     xsi:schemaLocation="  
            http://www.springframework.org/schema/beans  
            http://www.springframework.org/schema/beans/spring-beans-3.1.xsd  
            http://www.springframework.org/schema/context  
            http://www.springframework.org/schema/context/spring-context-3.1.xsd  
            http://www.springframework.org/schema/aop  
      http://www.springframework.org/schema/aop/spring-aop-2.5.xsd">  
  <context:annotation-config />  
  <bean class="org.springframework.web.portlet.mvc.annotation.DefaultAnnotationHandlerMapping" />  
</beans>

Step 4: Telling the portlet class where to find the spring application contex

Back in your portlet.xml file located in docroot/WEB-INF replace

<init-param>  
  <name>view-jsp</name>  
  <value>/view.jsp</value>  
</init-param>

with

<init-param>  
  <name>contextConfigLocation</name>  
  <value>/WEB-INF/nameofyourportlet-portlet.xml</value> 
</init-param>

ensuring that you use the file name of the file you created in step 3.

Step 5: Adding Spring jars to project

Find and open the liferay-plugin-package.properties file in docroot/WEB-INF and add the following to the end of the file:

portal-dependency-jars=\
    spring-web-servlet.jar,\
    spring-web-portlet.jar,\
    spring-web.jar,\
    spring-transaction.jar,\
    spring-jdbc.jar,\
    spring-expression.jar,\
    spring-core.jar,\
    spring-context.jar,\
    spring-beans.jar,\
    spring-asm.jar,\
    spring-aop.jar,\
    commons-beanutils.jar,\
    commons-collections.jar,\
    commons-fileupload.jar,\
    commons-io.jar,\
    commons-lang.jar,\
    jstl-api.jar,\
    spring-context-support.jar,\
    jstl-impl.jar,\

The jstl files are optional, but I highly recommend using jstl when you are forced to use JSP, so I included them here. Also note that if you are going to be using Freemarker, you need to include the freemarker.jar file here as well.

At this point you should build your project. Depending upon what IDE you are using, you might need to manually add the jar files to the projects classpath as well.

Step 6: Add ViewRenderServlet entry in the web.xml file

In the web.xml file located in docroot/WEB-INF add the following entry:

<servlet>  
  <servlet-name>view-servlet</servlet-name>  
  <servlet-class>org.springframework.web.servlet.ViewRendererServlet</servlet-class>  
  <load-on-startup>1</load-on-startup>  
</servlet>  
<servlet-mapping>  
  <servlet-name>view-servlet</servlet-name>  
  <url-pattern>/WEB-INF/servlet/view</url-pattern>  
</servlet-mapping>

Step 7: Add Spring view resolver

Spring supports many different types of view resolvers. Personally I prefer the Freemarker resolver when creating Liferay MVC portlets. If you want to use Freemarker, you should read the post I linked to at the beginning of this post. Also note that with Spring 3.0 or higher you can use multiple prioritized view resolvers, again see the links at the beginning of this post.

In the application context file you created in step 3 add the following entry:

<bean id="jspViewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">  
  <property name="viewClass" value="org.springframework.web.servlet.view.InternalResourceView" />  
  <property name="prefix" value="/WEB-INF/jsp/" />  
  <property name="suffix" value=".jsp" />  
  <property name="order" value="1" />  
</bean>

This ensures that what ever you return form a Spring @RenderMapping annotated controller function will be resolved to a JSP file in docroot/WEB-INF/jsp/. So you if for example return "myview" from your controller render function, Spring will use the file docroot/WEB-INF/jsp/myview.jsp to render your portlet.

Step 7: Create a controller with a render request handler

Here we create a very simple Spring controller that adds a simple request handler to render the jsp file mentioned above. This is not an exhaustive Spring tutorial, and if you don't know Spring MVC, you should find a good tutorial explaining controllers, render requests, action requests, resource requests, etc, and read it after completing this tutorial.

package is.brendan.liferay.portlet.testportlet.controller;  
import javax.portlet.RenderRequest;  
import javax.portlet.RenderResponse;  
import org.springframework.stereotype.Controller;  
import org.springframework.ui.Model;  
import org.springframework.web.bind.annotation.RequestMapping;  
import org.springframework.web.portlet.bind.annotation.RenderMapping;  

@Controller(value = "MyController")  
@RequestMapping("VIEW")  
public class MyController {

  @RenderMapping  
  public String handleRenderRequest(RenderRequest request,RenderResponse response,Model model){  

    return "myview";  
  }  
}

Step 8: Define the controller in the application context

In your application context file created in step 3 add the following:

<bean class="is.brendan.liferay.portlet.controller.MyController" />

Congratulations. If you did everything right, you have now created a fully functioning Liferay Spring MVC portlet.

Photo by Carli Jeen / Unsplash

I previously showed how to create a Liferay Spring MVC Freemarker portlets. But what if you want to use both Freemarker and JSP in the same portlet? Is it possible? If you are using Spring 3.0 or higher, it certainly is. And it's actually very simple and easy to do. I'm going to show you how to create Liferay Spring MVC Freemarker and JSP portlets in a moment.

But first. When would you need to do this? I really haven't found any use for this when creating a brand new portlet on my own. However, I have found this useful in multiple cases. If somebody delivers JSP-files for a project you are working on, and you really want to do your own work in Freemarker, since Freemarker is superior to JSP, this gives you a solution without very much added effort. This method is also great when upgrading your portlets from JSP to Freemarker. It allows you to gradually upgrade rather than do everything in a single big bang. And if you aren't really sure if you should be upgrading your portlets or not, I highly recommend reading 10 reasons to replace your JSPs with Freemarker templates on the Stack Hunter blog. Finally, if you are extending a legacy portlet that uses JSP, and you really don't feel like mucking about with JSP any more, this method comes to the rescue.

Now, before you continue, Liferay has an issue with Spring MVC Freemarker portlets resulting in a nullpointer exception in FreeMarkerView.getTemplate(). If you don't already know how to handle this, please read my post I linked to in the first paragraph before continuing.

Spring 3.0 added support for multiple view resolvers by giving them priorities. Using multiple ordered view resolvers is as simple as adding both resolvers, just as you would if you were adding theme as singletons in addition to giving them a priority. View resolvers with a lower priority number resolve before resolvers with a higher priority number.

Contemplate this code:

<bean id="freemarkerConfig" class="org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer">
  <property name="templateLoaderPath" value="/WEB-INF/freemarker/"/>
</bean>

<bean id="viewResolver" class="is.brendan.liferay.web.freemarker.ExtendedFreemarkerViewResolver">
  <property name="cache" value="true"/>
  <property name="prefix" value=""/>
  <property name="suffix" value=".ftl"/>
  <property name="exposeSpringMacroHelpers" value="true"/>
  <property name="freemarkerConfigurer" ref="freemarkerConfig"/>
  <property name="order" value="0" />
</bean>

<bean id="jspViewResolver"  
  class="org.springframework.web.servlet.view.InternalResourceViewResolver">  
  <property name="viewClass"  
   value="org.springframework.web.servlet.view.InternalResourceView" />  
  <property name="prefix" value="/WEB-INF/jsp/" />  
  <property name="suffix" value=".jsp" />  
  <property name="order" value="1" />  
 </bean>

Now, if you return the "myview" in your Spring MVC @RenderMapping mapped method, Spring will first investigate the /WEB-INF/freemarker/ folder looking for a file named myview.ftl. If that file does not exist, Spring will move on and investigate the /WEB-INF/jsp/ folder looking for a file named myview.jsp. Naturally, if neither of the files exists, your portlet will crash and burn.

Photo by Glen Carrie / Unsplash

Liferay Freemarker Spring MVC portlets are great, and certainly are my favourite way of developing portlets in Liferay at the moment, when creating non-webapp portlets. For business applications created as webapps Vaadin is most certainly the way to go, and for non-business applications created as webapps, my personal favourite at the moment is AngularJS which plays very nicely with Liferay. I'll get back to Vaadin and AngularJS in later posts.

Now creating Spring MVC portlets in Liferay is common, and fairly well documented all over the place on the net. It does involve a manual process where you start out with a Liferay MVC portlet, and change it to a Spring MVC portlet. I'm hoping Liferay soon will realize the value of adding Spring MVC portlets to their SDK, so we avoid having to do this manually. Intellij support would be nice as well, but their new Maven support in 6.2 goes a long way towards mitigating the problem, though it still is a bit flaky in the current version of the new Liferay IDE I'm using.

Spring MVC portlets are great, but you still have to deal with JSP. For the real killer combination, you need to add Freemarker to the mix. Unfortunately, though using Freemarker in Spring MVC is very straight forward, using it in a Liferay portlet is not. The issue manifests itself as a nullpointer exception in FreeMarkerView.getTemplate(FreeMarkerView.java) This "bug" has existed in all versions of Liferay I have worked with, and has yet to be fixed in Liferay 6.2. Hopefully as Freemarker becomes more and more popular, Liferay will finally decide to fix this issue. Luckily there is a workaround which I will describe here. This works in Liferay 6.1.1+ and Liferay 6.2. For earlier versions a different workaround exists, but I will not describe it here, as you really should have moved on from Liferay 6.0 and 6.1.0 by now.

The first step of the workaround is to create the following Java class:

package is.brendan.liferay.web.freemarker;
import java.lang.reflect.Method;
import javax.portlet.PortletContext;
import javax.servlet.ServletContext;
import org.springframework.web.portlet.context.PortletContextAware;
import org.springframework.web.servlet.view.AbstractUrlBasedView;
import org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer;
import org.springframework.web.servlet.view.freemarker.FreeMarkerView;
import org.springframework.web.servlet.view.freemarker.FreeMarkerViewResolver;

public class ExtendedFreemarkerViewResolver extends FreeMarkerViewResolver implements PortletContextAware {
        private FreeMarkerConfigurer freemarkerConfigurer;

        @Override
        protected AbstractUrlBasedView buildView(String viewName) throws Exception {
                FreeMarkerView freemarkerView = (FreeMarkerView)super.buildView(viewName);

                freemarkerView.setConfiguration(freemarkerConfigurer.getConfiguration());
                freemarkerView.setServletContext(getServletContext());

                return freemarkerView;
        }

        public void setFreemarkerConfigurer(FreeMarkerConfigurer freemarkerConfigurer) {
                this.freemarkerConfigurer = freemarkerConfigurer;
        }

        @Override
        public void setPortletContext(PortletContext context) {
                try {
                        Method meth = context.getClass().getDeclaredMethod("getServletContext");
                        setServletContext((ServletContext)meth.invoke(context));
                } catch (Exception e) {
                        throw new UnsupportedOperationException("Could not get servletcontext", e);
                }
        }

}

Next, in your applicationcontext do the following:

<bean id="freemarkerConfig" class="org.springframework.web.servlet.view.freemarker.FreeMarkerConfigurer">
  <property name="templateLoaderPath" value="/WEB-INF/freemarker/"/>
</bean>

<bean id="viewResolver" class="is.brendan.liferay.web.freemarker.ExtendedFreemarkerViewResolver">
  <property name="cache" value="true"/>
  <property name="prefix" value=""/>
  <property name="suffix" value=".ftl"/>
  <property name="exposeSpringMacroHelpers" value="true"/>
  <property name="freemarkerConfigurer" ref="freemarkerConfig"/>
</bean>

Now you are good to go. Drop your Freemarker templates in /WEB-INF/freemarker/ and use them just like you would in a regular Spring MVC portlet.

And if you want to get really fancy, you can add the ability to load Freemarker templates from outside of your portlet project for added power. This allows you to allow your portlet to use Freemarker templates uploaded through the Liferay Sync application. Check out this proof of concept. Though this is a rather neat feature, if you already have moved to Liferay 6.2 you are probably going to want to use the new Liferay Application Display Template feature since it's fully supported by Liferay, and not a hack like the proof of concept mentioned above.

Photo by frankie / Unsplash