ng-admin + JAX-RS: 400 Bad Request on DELETE

I’m tried of building admin UIs and I’m trying out ng-admin. It’s pretty straightforward to setup given the guides and demos.

List, create, updates were fine until I got to the DELETE method. The server was throwing 400 Bad Requests and upon Chrome network inspection I discover that ng-admin was sending a JSON body in the request. I don’t really care who is “following the standard” as long they work together (think browsers and jquery), so I’m fine to fix either side to either the client not send the body, or the server accepting the non-empty body.

ng-admin uses Restangular under the hood to make REST requests. Restangular did have this FAQ about DELETEs with body(s).

A little refactoring and presto! DELETE now works.

app.config(['RestangularProvider', function(RestangularProvider) {
  RestangularProvider.setRequestInterceptor(function(elem, operation) {
    return (operation === "remove") ? undefined : elem;


multiple definition of `R_running_as_main_program`

I inherited a C++ application that was using rcpp to embed R. After R was upgraded to 3.2, the make was failing miserably with the error:

file1.o:(.bss+0x0): multiple definition of `R_running_as_main_program'
file2.o:(.bss+0x0): first defined here

This was found to be caused by

To overcome this, edit /usr/share/R/include/Rinterface.h and search for this line:

int R_running_as_main_program;

Add the “extern” keyword at the start and save it:

extern int R_running_as_main_program;

After that there should be no problem building the program.


Wrong encoding when JSP includes HTML

We had a standard JSP header with logo and menu, and we used it to include a few static HTML pages (e.g. privacy policy and about us). We had multiple versions of the static content in different languages, and the non-English ones shows up in gibberish, although the menu shows up fine.

We already specified the encoding in our enclosing JSP page.

<%@ page pageEncoding="UTF-8"%>

as well as specified the charset in the meta header

<meta http-equiv="content-type" content="text/html; charset=utf-8">

A common “workaround” is to convert the html to JSP to specify the encoding. However being lazy developers, we want a better solution. Eventually we found the hint to set the encoding in web.xml. We tweaked the extension from .jsp to .html and it works!



Lenovo T440p keyboard

I was just issued a Lenovo ThinkPad T440p, not that I get to choose the model. Immediately I got down to customizing the quirks (to me).

1. Fn/Ctrl key swap
Ctrl-C Ctrl-V Ctrl-Z Ctrl-W all don’t work. Because in the Ctrl’s position is a Fn. This link explains why (so we could find the Fn key for ThinkLight in the dark), but I didn’t really need the ThinkLight so I swapped it anyway.

Go to BIOS > Keyboard/Mouse > Fn/Ctrl Swap > Enabled.

2. F1-F12 lock
F1-F12 could only be accessed with the Fn key. so F2 to rename became Fn-F2, and F5 to refresh became Fn-F5.

Press Fn-Esc to lock the Function keys.

3. Trackpad Scroll
I use a MBA at home so the two-finger scroll was reversed.

To keep myself sane, go to Control Panel > Mouse > Change Mouse Settings > ThinkPad > Advanced > Scroll > Two-Finger Scrolling > Check Switch Direction.

4. Lenovo Message Center Plus
The big red icon on the taskbar was an eyesore to me.

Right click on the taskbar > Toolbars > Uncheck Lenovo Solution Center.


Glassfish timezone different from OS (Ubuntu)

We added a new Ubuntu server to deploy one of our new feature to isolate it from the core modules. The new module did not work, and we narrowed it to System.currentTimeMillis() returning a time in the future.

NTP was active; we ran the linux “date” command and it was showing the correct date. When we checked Glassfish’s JVM report, it showed that the user.timezone was different, and the timezone difference coincides with the time differences we observed. The straightforward answer: set -Duser.timezone in the JVM options and we are good to go.

But wait, why our original servers didn’t have this issue? We checked the original server, and there was no such JVM option setting. After some tracing it turns out that /etc/timezone of the new server was incorrect, and that influenced the timezone Glassfish used. Finally we matched the two server settings and reverted the user.timezone JVM option.