Quick 2-tuples in Java

For cases one does not want or need (because it would never find reuse!) to create wrapper class for pairing two values of any types (a 2-tuple) in Java, Map.Entry public inner interface in java.util.Map container can be acceptable alternative. Code relying on java.util.Collections.singletonMap (constant additional space use!) to return a pair from Java method can be written as such:

// returns pair (2-tuple)
private Map.Entry<Integer, Record> bar() {
  // ... recordCount and record created
  return Collections.singletonMap(recordCount, record).entrySet().iterator().next();
}

// 2-tuple extraction with getKey()/getValue()
public void foo() {
  Map.Entry<Integer, Record> pair = bar();
  Integer recordCount = pair.getKey();
  Record record = pair.getValue();
  // use paired values ...
}

Locales in Liferay

I wanted to configure the languages available in Liferay 6.2 runtime interface site settings (Site Administration → Configuration → Site Settings → Display Settings → Language) to include Russian and Azerbaijani — but these were not even listed among available languages. From portal source I verified that language pack for Russian indeed exists (not for Azerbaijani though!).

Having had a look at portal.properties gives a hint that interface languages in Liferay runtime depend on locales.enabled setting, which can be overriden in one of the Liferay configuration files (reading order: portal.properties, portal-bundle.properties, portal-ext.properties & portal-setup-wizard.properties). So e.g. locales.enabled=en_US,ru_RU in portal-ext.properties will do the trick for making Russian locale available, for Azerbaijani, one would need to start translating.

And later I found that available locales can also be set from Control Panel → Configuration → Portal Settings → Display Settings → Available Languages :)

Liferay 6.2 archetypes

Maven (build tool and a Trickster) provides several Liferay specific archetypes with com.liferay.maven.archetypes archetypeGroupId. Some of these are tied to MVC frameworks to be used in Liferay portlet (e.g liferay-portlet-jsf-archetype), others assembled for more generic functionality. Sample command line to generate Liferay portlet project structure without any MVC specifics added:

mvn archetype:generate \
     -DarchetypeGroupId=com.liferay.maven.archetypes \
     -DarchetypeArtifactId=liferay-portlet-archetype \
     -DarchetypeVersion=6.2.10.6 \
     -DgroupId=thecompany.com \
     -DartifactId=company-portlet-one \
     -Dversion=0.1-SNAPSHOT \
     -DinteractiveMode=false

The list of all available Maven archetypes can be seen with: mvn archetype:generate command. Following MVC agnostic archetypes are available in com.liferay.maven.archetypes group.

1. liferay-ext-archetype — for creating customizations as Liferay extension, also called ext plugin. With ext plugins Liferay core functionality can be replaced with modifications separate from Liferay's code. Jamie L Sammons writes: Liferay Ext Plugins are often considered a last resort in the Liferay Plugin world due to the complexity and the lack of hot deploy as well as the inability to remove them once they are deployed.

2. liferay-hook-archetype — for Liferay customization, a hook has advantage of hot deploy. Web resources, JSPs, portal services, etc can be overridden with hooks. Hooks can also be defined in portlets.

3. liferay-layouttpl-archetype — layout templates allow definition of new page layouts, embedding commonly used portlets in layouts, specifying CSS, etc.

4. liferay-portlet-archetype — minimalistic Liferay portlet to be deployed in portal.

5. liferay-servicebuilder-archetype — to generate a basic service layer. It comes with promise of CRUD and SOAP all in place for the entities.

6. liferay-theme-archetype — Liferay theme plugin archetype for user interface customization of sites in Liferay.

7. liferay-web-archetype — creates a minimal web application skeleton, Liferay specific addition being WEB-INF/liferay-plugin-package.properties file, allowing to manage that application from Liferay Control Panel.

Liferay Editions

Ambitiously named Liferay provides open-source "enterprise" Java portal environment for JSR-286 portlets.

Current Liferay version is 6.2, distributed in two editions:

• Community Edition (CE)
• Enterprise Edition (EE)

Birdview comparison of Liferay editions is presented at: http://www.liferay.com/downloads/liferay-portal/overview. EE is built on LGPL code of CE edition and additions include "Emergency Hot Fixes", "Consolidated Service Packs", wider selection of ready-made components (web-forms, workflows, systems integration) and various support options depending on service levels. Source code of EE is available with subscription. In the EE FAQ, there is a promise that each EE version will be supported for minimum of 4 years.

Liferay has partner programs for redistribution, support and service. Componence is one of the partners that has provided more detailed list of EE features.

Pricing of Liferay EE is opaque, their get pricing link opens up a form requesting all kinds of information about the potential client, including short description of project use case, including an estimated scale (total users, concurrent users, integrations and redundancy planned) plus any current infrastructure estimations for OS, DB, IdM, integration.

Privileged ports, Linux capabilities and Java

Under Unices (including Linux), running a listening service on low numbered privileged TCP ports (< 1024) can usually only be done by root (superuser). This does not necessarily mean that service needs to run with effective user id of root, but at service port binding time, user running the program needs to have sufficient privileges. As lot of low numbered ports are commonly used for many standard services (HTTP is usually over port 80 and HTTPS port 443, etc), the notion of privileged ports can be considered "security through convention" approach, preventing random user with UNIX shell account popping up some apparently "official" service. On the other hand, requirement for privileged account can become a security issue, if the program that needs to be run on privileged port is in some aspects untrusted.

privbind/authbind

Debian packages include privbind utility that allows to execute application as an unprivileged user with extra privilege of binding to reserved ports. Its manual is contradictory, specifying both that:

• privbind has no SUID parts, and runs within the confines of a single process
• privbind works by starting two processes. One drops privileges and runs (exec(2)) the command, the other remains as root.

Contradictions aside, privbind is unable to work with many current Java Virtual Machines (JVMs), as it is "using LD_PRELOAD to intercept every call to bind(2) made by the program"¹, while JVM implementations can and do binding calls directly to kernel. If it works, usage can be as easy as: "privbind path_to_binary".

Similar package available on Debian is authbind, also using LD_PRELOAD mechanism and thus suffering from the same limitations.

setcap + chrpath

However, on Linux kernels with capabilities support (2.2+), using per-thread NET_BIND_SERVICE capability can be used to run service on privileged port without runtime superuser privileges. This capability can be enabled with setcap "eip" flags (effective, inheritable and permitted, execute as root), e.g. on Java binaries:

setcap cap_net_bind_service=+eip $JAVA_HOME/bin/java
setcap cap_net_bind_service=+eip $JAVA_HOME/jre/bin/java

While necessary, setcap might not be sufficient (as unprivileged user):

java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory

Examining the java binary with readelf shows:

xyz@sdk$ readelf -d java
Dynamic section at offset 0x71c contains 28 entries:
  Tag        Type                         Name/Value
 ... skipped ...
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [lib.so]
 0x0000000f (RPATH)                      Library rpath: [$ORIGIN/../lib/amd64/jli]

According to thread in openjdk distro-pkg-dev list, glibc disallows relative paths and $ORIGIN expansion when running binary with capabilities as ordinary user (for security reasons). One solution to that is to change the RPATH encoded in ELF binary to absolute path. From Debian packages chrpath can be used for this:

chrpath -r $JAVA_HOME/lib/amd64/jli/ $JAVA_HOME/bin/java
chrpath -r $JAVA_HOME/jre/lib/amd64/jli/ $JAVA_HOME/jre/bin/java

setcap + patchelf

Changing RPATH can also be done with patchelf, not currently included in Debian packages. Sylvain Duloutre's blog post describes granting identical port binding capabilities to JVM binaries with setcap and patchelf, with RPATH change performed like this:

patchelf --set-rpath $JAVA_HOME/lib/amd64/jli $JAVA_HOME/bin/java
patchelf --set-rpath $JAVA_HOME/jre/lib/amd64/jli $JAVA_HOME/jre/bin/java

NB!

Granting capabilities to (JVM) binaries can introduce security concerns and should only be done where access to such binaries is suitably restricted.

---

¹ privbind-devel: privbind not working with Java

Coincidental Eagerness

I had web application crashing on me with org.hibernate.LazyInitializationException on certain web application page.

org.hibernate.LazyInitializationException: could not initialize proxy - no Session

Everyone who has ever used Hibernate instantly recognizes the problem. Smart proxy that Hibernate uses to load child entities of an entity on-demand could not perform its duty as the entity instance had already escaped the data layer and session had been closed. Child objects could be loaded eagerly in the data layer to make problem go away.

I examined the code and clearly child objects whose attempted retrieval resulted in the exception were never loaded. Weirdly, no-one else received exception on that page. The web layer code where exception occurred was roughly as this:

// Q, QLabel & Language are Hibernate entities
private String getQTitleInLang(Q q, String langCode) {
  for (QLabel ql: q.getLabels()) {
    // QLabel's Language is uninitialized, getCode() fails
    if(langCode != null && ql.getLanguage().getCode().equals(langCode)){
      return ql.getDescription();
    }
  }
  return null;
}

The data layer code that loaded the main entity was bad Hibernate usage, manually forcing the n+1 selects. Actually it was worse. It had 2 nested for loops, each calling Hibernate.initialize() on many child entities. But that is besides the point, I cleaned it up a bit for the sake of example.

private void initQ(Set<q> qs) throws HibernateException {
  for (Q q: qs) {
    Hibernate.initialize(q.getLanguages());
    Hibernate.initialize(q.getLabels());
  }
}

Correct but bad fix is to add the nasty loop that initializes QLabels:

private void initQ(Set<q> qs) throws HibernateException {
  for (Q q: qs)  {
    Hibernate.initialize(q.getLanguages());
    Hibernate.initialize(q.getLabels());
    // The ugly fix. In real code that brings 3rd nested for loop.
    for (QLabel ql: q.getLabels()) {
      Hibernate.initialize(ql.getLanguage());
    }
  }
}

So why did the code work for everyone else? It was just that they happened to work with different database. In their databases all the Language entities that QLabels' owned coincided with those that Q itself had as its child Languages.

As Hibernate Session holds a mandatory first-level cache of persistent objects that are used when navigating the object graph or looking up objects by identifier, that made the "unloaded" entities accessible under certain conditions.

Session-level caching just happens to work so well that code coincidentally works sometimes :)