Monday, May 16, 2016

IBM Bluemix - Eclipse Developer Exprience


I'm an IDE guy, which means that I like to fill a dialog with some information and then some magic, that I understand, is done to achieve the desired results.

Recently, I wanted to deploy a demo app to IBM Bluemix. Of course, I quickly equipped my latest Eclipse environment with the Bluemix plugin and I have been able to get my app run on the cloud in a matter of minutes (https://marketplace.eclipse.org/content/ibm-eclipse-tools-bluemix). I like the clean Eclipse Server integration. It basically works like your local Tomcat, but with a remote cloud server. Pretty cool!

But wait, this first attempt was really basic. Now I need to add features, connect to a directory, configure a set of things, add shared libraries that are not in the WARs.. Unfortunately, the Eclipse plugin does not let me act on the files that are not directly part of my web application. In particular, I cannot edit the server.xml file (the one carrying the configuration), nor I can add my own config files/libraries in the server directory. From the web UI, I can look at these deployed files, but cannot create/update/delete them. Gasp, not even an open FTP port for this.

Does that mean that I should fall back to the command line tools and leave my beloved Eclipse environment? Well, no. There is actually a good IDE experience once you discover it.

1- The deployment options

There are basically 3 options to deploy your code, see: https://console.ng.bluemix.net/docs/runtimes/liberty/optionsForPushing.html.
  1. The one that I initially used from Eclipse is the one picking up a set of default configuration properties, that you can barely change. Good for a first try, but not sufficient going forward.
  2. The second one is about publishing a server directory to Bluemix. In Liberty's vocabulary, a server directory contains both your applications and the related config files (server.xml), but not the core Liberty's code. Moreover the same Liberty's installtion can have multiple server directories, thus launching multiple environments at the same time. Deploying such a directory to Bluemix is pretty easy, as you have to create a dir on your local file system, add your application(s), config files, and push id. Well, several manual steps to do, with potential error s (ex: server.xml content). See: https://console.ng.bluemix.net/docs/runtimes/liberty/optionsForPushing.html#server_directory.
  3. The last option pushes the whole server to Bluemix, meaning the server code, the applications, and tutti quanti. This is called a packaged server, explained here: https://console.ng.bluemix.net/docs/runtimes/liberty/optionsForPushing.html#packaged_server
Options 2. and 3. will certainly achieve what I'm looking for, but the doc implies using the command line tools.

2- Doing the job from Eclipse

The Liberty runtime on Bluemix is actually just a regular WebSphere Liberty server. So the first thing to do is to install the WebSphere Developer Tools (https://marketplace.eclipse.org/content/ibm-websphere-application-server-traditional-v85x-developer-tools). Once done, create a server in the "Servers" view. Some of the steps are explained here: https://developer.ibm.com/wasdev/docs/developing-applications-wdt-liberty-profile/. It will seamlessly download the runtime and get your server ready to go. Finally, add your j2ee application to the server and it is ready to run, locally.
Because it is a local server, you can access and modify the server.xml file, add your own config files... In my case, I named my Liberty server 'dwodemo' and I can access the local files in the following directory:

BTW, I get  this directory location at runtime by calling System.getProperty("server.config.dir")

Now comes the magic part. Once you have your application(s) deployed to that server, you can right click the server and package it for Bluemix (assuming you already created a Bluemix server entry):


After answering a few basic questions, a server package will be created for you and deployed to Bluemix. I got my app running pretty quickly without having to deal with the command line. Yes! Moreover, I can now change any of these files, and run this action again to update Bluemix.

Such a configuration, with a local Liberty server makes actually a lot of sense. First, because deploying an app to Bluemix (even just an update) takes time, while it is almost done instantly with a local server. The code/test developer experience is definitively a lot better with a local server. Then, if remote debugging works with Bluemix, this can also be a area of performance frustration... Keep it for when you have a problem on Bluemix that you cannot reproduce locally.

With this configuration in place, I'm getting a good developer experience, with quick code/deploy/test cycles. IBM did a good job with the tools. I simply wish they made this information more prominent in the documentation. I had to read many articles and stack overflow Q&A to understand what I actually need to do. I would have loved a Bluemix tutorial "Bluemix and Liberty for Tomcat developers", that goes beyond a simple WAR deployment, but talks about configuration, users, security, ...

Friday, May 13, 2016

WebSphere servlet resources in your Connections 5.5 extension

If you're deploying an application that executes in the Connections 5.5 WebSphere server, then you may face this issue. Starting from version 3.0, a servlet container allows you to package resources (html, js, jsp...) within the application classpath, under META-INF/resources. Per the servlet spec, these resources can be located in jar files, deployed in WEB-INF/lib. We now heavily use this capability as our components are packaged as self-contained jar files, including both the java code and the web resources.

If this worked well in C4.5+, it stopped working with C5.5. Actually, the java classes from the custom jar files are properly loaded, but none of the embedded resources are served by the web server. After some investigation, we found out that the way the jar file is created makes it work or not. Precisely, if you create the jar from Eclipse (export...) then it does *not* work. Same if you package it using the Windows internal zip capability. If you recreate it using 7-zip, then it starts work... There must be some subtle internal differences between these compressors, and the new WebSphere seems to be very sensitive. If you have the issue, you now have a workaround :-).

The problem has been reported to IBM, with all the pieces to easily reproduce it. A PMR was created several weeks ago. But so far, no solution/fix has been provided. This is one of these cross organization problems where ICS argues that it is a WebSphere problem, while the WebSphere team doesn't show a lot of interests.