Bye bye wordpress.com, Hello RBlog!

EDIT: since OpenShift v2 closed with no real migration to its v3 my blog is now hosted at Metawerx: https://rmannibucau.metawerx.net/

For the impatients: go to my new blog on  https://blog-rmannibucau.rhcloud.com/ .

Blogging is probably the easiest way to share some tips and experiences. But – not to offend anyone – it needs a technical solution adapted to the writer(s).

I started blogging in 2012 on this wordpress.com blog which is an awesome platform ! Everything is already set up : hosting and installation are managed for you.

However, since few months, I felt quite limited relying on the free wordpress platform.

The main issue on wordpress.com is that you can not freely customize/design your blog (theme, plugins, …). Part of that, I often share codes and the provided themes didn’t support snippets very well. And that was embarrassing.

Second, I’m mainly writing about Java but I’m doing it on a PHP platform ! So I felt like promoting something I don’t use myself. It doesn’t respect “eat your own dogfood” principle and I started to feel inconsistent about that.

So I decided to move away from the wordpress.com platform to a more appropriate one.

Then the question was: where to move and what solution to choose ?

Studied options were:

• custom wordpress or CMS hosting
• custom application

Custom CMS

Most of the CMS I evaluated (wordpress, drupal, joomla…) were based on PHP technology. This is not an issue by itself but now I want to be consistent with what I’m writing and therefore I decided not to go with a non-Java solution.

To go even further I desired a EE (or at least JAX-RS) based solution but I didn’t find any major open sourced one.

Custom Application

After all, a blog is not that complicated:

• users
• category or tag
• and of course…. content !

So writing it can make sense.

Wait ! No comments ? Yes, after few years of blogging, I realized that it is great to leave a comment directly. But it also prevents the discussion (and often the issue) from being solved in the project list. That’s why I decided to not implement comments. However, it doesn’t mean you can not discuss about a post ! You can of course contact me through my twitter account, or through the project’s mailing-list related to the post, if accurate.

In current blogging sphere, the generated sites have good vibes but I didn’t want to go that way because it requires re-deployment for content updates, and I want to be able to share the content management with non-technical people.

To simplify, it means being able to edit, refresh and get the updates. This means I need a more classical HTTP application.

As mentioned above, the backend decision was to be JAX-RS based solution. Goal is to be able to extend the views in the future and easily write clients (including a CLI).

We have the “backend front” choice, but what about the persistence?

Using JavaEE, I have JPA built-in and it is often used for blogs so it can be a good candidate. But in 2016,there are other options:

• NoSQL : OrientDB, MongoDB, Cassandra are good candidates for instance
• Git(hub) : yeah, flat files and a java git client to handle CRUD operations

Here, I decided to use JPA (a relational database more than JPA actually) because it is easier to work with and integrate a RDBMS than other databases today:

• A default datasource is provided by JavaEE (or TomEE for pre JavaEE 7 versions) and therefore allows you to run without any addition
• Most of hosting providers (cloud or not) will support it, but maybe not other solutions
• Git (or Github) was either a custom git repository I didn’t want to maintain (backup etc…) but private hosting was not free. Side note: not using private hosting means your blog (and even your sources) will likely be read on github itself. That means you have no way to view statistics, etc…

I will not detail more the backend implementation, even if some parts are interesting. But I will probably do in other posts. The goal of this post is just to share the other all decision.

So now we have the backend. The frontend choice was the last missing step. Choices were either to use a server framework (like JSF, Tapestry, Wicket…) or a client framework/library (yes I mean javascript). Since JAX-RS choice was there, and that most of the time web server frameworks just wrap what the browser sees, ie javascript, then I decided to go with javascript. It may sound like a geek choice to go lower level, but actually, it is not. In fact, java libraries often try to hide frontend behind Java API. It is rarely up to date and often hard/costly to upgrade a javascript component. I just didn’t want that constraint.

Thus, I decided to fully implement the blog with Vue.JS. It is a great modern javascript framework inspired by AngularJS and not owned by a big major.

The only drawback I got with it was its little community, and it is something I’d like to avoid from now on.

The alternative at that time (yeah it was few months ago ;)) were AngularJS and ReactJS. Angular was not chosen because version 2 was close to be out but not yet usable. So you understand now why I chose ReactJS? Well not exactly… I tested Angular2 even if it was not ready to be used at that time. I identified that their API + Typescript usage makes backend/frontend writing at the same time smoother than usual.

As this coding was done during my spare time, while I didn’t have major constraints, I decided to wait a bit for Angular2 to choose it as a final solution.

So my fullstack blog is: JPA/JAX-RS/Angular2.

We are done right? Well… not really ! Angular2 promotes typescript usage instead of directly relying on javascript to simplify your code. However, this encourages you to split your application in even more files than a standard javascript one. Thereby, the application would make lots of requests to load. Since we don’t have HTTP/2 yet to make it soft, I needed a way to avoid this side effect. In other words : to avoid loading the application in 30 seconds. So I need a build tool able to transpile typescripts sources and then concatenate and uglify javascript sources.

You can make researches : all java solutions have drawbacks/limitation and *by nature* all good solutions are based on NodeJS. They are the first users so that’s natural 😉

Concerning java, maven was a natural solution, especially because of the quality of tomee-embedded maven plugin which makes the development very easy. More, there is a nice NodeJS maven plugin, so I just needed a NodeJS build solution. Gulp (http://gulpjs.com/) was evaluated but was too task-oriented (do it yourself) for a simple project like a blog. Thus, I decided to work with webpack (https://webpack.github.io/docs/) which has an insanely easy angular2 starting sample and a very easy built-in API.

Was it the right choice?

In terms of code, I’m quite happy about that stack : I can use TomEE goodness for backend writing and testing (more to come in future posts ;)) Furthermore, Angular2 is simple even for a Java developer. On the build side, the only trick was to ensure to be able to test Java part without building the full frontend task, and the opposite as well. But it is actually easy. Finally, development workflow is quite efficient.

However “all is not rosy”! Angular2 uses RxJs which is insanely great in terms of API and even patterns. However, it makes the frontend quite bigger than the original VueJS solution for instance. They are working on it, and it will likely be improved in the future. It is

not a real blocker, but can have an impact on mobile devices when network is not good enough.

To sum up, I am quite happy with that stack even if some optimizations can still be done and hope this new blog will enable sharing more content in a better manner.

To follow next content you can follow me on https://twitter.com/rmannibucau or check https://blog-rmannibucau.rhcloud.com/ .

Stay tuned!

Enhance OpenJPA entities with Gradle

OpenJPA has a Maven plugin but doesn’t provide a gradle plugin (yet?) but build-time enhancing is still a nice solution to ensure your entities will behave correctly whatever deployment you choose (in a plain TomEE the built-in javaagent does the work well but in embedded tests it is not guaranteed).

Is that a reason to abandon Gradle? Maybe not yet ;).

Oh My js! Server side javascript for java developers?

Javascript tooling set was enriched a lot these last years: npm, bower, gulp, grunt, … but most of them work on nodejs and need a certain amount of knowledge before being able to get anything from it.

For a Java developer it can be complicated and tempting to do a plain JSP instead of embrassing javascript.

Making javascript development easy can only be done in the case of a framework with a lot of defaults cause by nature you need to develop in an exploded fashion (by module) fr the maintenance and aggregate them at the end for performances reasons (HTTP 2.x will maybe make it smoother but will likely not replace it completely).

If your project is before all a frontend project you need to go on js side but if your project is simple and more centered on the data or the server side we can probably find a compromise.

This was the origin of “Oh My js!” which is a small library I created to integrate the pipeline I often use for frontend development with Maven and the Java stack I use (TomEE if you doubt of it ;)).

First of all what needs do I want to cover and which ones I’ll ignore:

• dependency management: ignored. I only want to handle runtime js dependencies and they are not that numerous in general so it can be done manually or worse case using webjars and a small groovy script for the optimization – will not be part of this post but can be another one if needed
• build: yes and no. There are multiple parts of a build in javascript: the “big final aggregation” which aims to put all resources we can in a single file to make client loading faster and (optional) each module transpilation/rendering/compilation/… This is this last part we will target
• test: java has a good tooling to do it but see next note for a more nuanced answer
• packaging: not sure javascript has a real packaging model yet but java has so all is fine and secured
• deployment: I build a war so maven/gradle are perfect

Of course I listed far more that what this post will cover but it was to show that the “blocking” part for a java developer is finally small enough to get some work to fill the gap.

Side note: frontend-maven-plugin is a great tool bringing to maven nodejs tooling (npm, bower, gulp, karma…). This however still needs to know these tools and just provide a “main-build” friendly solution so the initial cost can be important but it can worth it if you will need a lot of javascript.

@Throttled: the CDI extension

In JavaEE the throttling is often done using a stateless bean cause they are by designed pooled and the pool provide a contention point. This is however IMO a workaround more than a solution for the throttling need and a small CDI extension can be worth it.

CDI: replace the configuration by a register pattern

CDI doesn’t really have a configuration file. Of course the beans.xml is used to activate few features like interceptors but you can’t register a bean in it, can’t add a qualifier on a bean etc…

When it comes to writing a CDI library the question of the configuration hits you pretty quickly. Let see how to solve it with a not very complicated pattern making users life really nicer.

The Promise of CompletableFuture? JAX-RS2 example!

CompletableFuture API introduced in Java 8 is different from previous Future in the way it is composable and usable as a promise. Let’s see how to integrate it with JAX-RS 2.

Add missing functions to HtmlUnit: Vue.js case

Depending the application you work on HtmlUnit can miss few functions. If you open the javascript engine you will quickly see it is quite complex to extend from your code and can be annoying when sometimes it just misses few methods!

Let see with the case of Vue.js how to fix it very easily.

JSF/Primefaces and session timeout login redirection

If you use JSF and Primefaces you can encouter the case where your session expired and the next action your user does is an Ajax request. If you configured a form login then the ajax request will get the form redirection as expected but…it is an ajax call so your user will see nothing basically excepted an irresponsive GUI.

To work around it you can implement a custom PhaseListener checking if the request is an ajax request redirected to the login page and if so enforce the redirection through JSF API.

Chunking and global report using JTA

If you have a batch processing records in chunks you probably want to keep track of what succeeds and fails. The issue is the commit is often done after your business code is executed which means you kind of loose track of what happens.

To solve it you can use TransactionSynchronizationRegistry and Synchronizations.

Java 8 streams and JTA chunking?

Java 8 streams are very expressive – even if RxJava is even more 😉 – but sometimes EE integration is not that advanced. In case of a batch import of data it would be handy to use Stream API since we iterate over data to persist them but how to ensure we can use chunking – ie get a commit interval to not commit for each record?