How to handle java home in module?

[Gavin Williams]

Morning all

I'm currently working on a module[1] to support installation and configuration of Apache Karaf[2], a Java OSGi container...

I've got most of the installation piece sorted, and am starting to work on the configuration side of things.
Unfortunately I've hit a bit of a blocker which I'm not sure of the best way to work-around.

As part of the service installation process, a Java wrapper config file is created.
This config file needs to be modified to specify the 'JAVA_HOME' value. However I'm not sure of the best way to calculate this JAVA_HOME value, due to the variable nature of both Java variants (Java 6 vs 7, Oracle vs OpenJDK, release version) and the fact that Java might not be installed at the start of the Puppet run.
The intention is to use a template for the config file, so it's modifiable by Puppet.

Options I can think of:

1. Use a fact to provide JAVA_HOME. This fails if Java isn't installed at the start of the agent run, which is a valid scenario if this module is also installing Java...
   
2. Hard code the value based on a pre-determined file path based on chosen Java distro and version. Not very clean/configurable...
   
3. Update wrapper config file to pull in system env for JAVA_HOME. However this fails if the system version isn't the one that the app should use...
   

Am I missing a trick somewhere along the lines, or is hoping to achieve all this - Install Java, Install Karaf, configure Karaf service - in one run asking too much?

Thoughts/ideas welcome.

Cheers
Gavin

[1] https://github.com/fatmcgav/fatmcgav-karaf/tree/develop
[2] http://karaf.apache.org/index.html

[jcbollinger]

Your criticisms of those options present an inconsistent view of your requirements.  If the app needs to use a specific Java version that may be different from the system's default (per remarks about #3) then it's going to be pretty tricky to get the correct value from a fact, too (alternative #1).  That seems to say that knowing the requisite Java version in advance (#2) is one of your requirements, so whether that's clean or configurable is irrelevant.
 

Thoughts/ideas welcome.

Since you are managing the Java package, in principle you can know what JAVA_HOME you will need based on which package you are ensuring installed.  That is, you can know what the appropriate JAVA_HOME will be once Puppet is done because it is (or can be) part of what you are managing, albeit indirectly.

If you want to be a little less prescriptive and a little more adaptive, at the risk of possibly needing two runs to reach a stable configuration, then you could try a combination of your alternatives 1 and 2: use a custom fact to try to choose JAVA_HOME from among those of the runtimes available before the run, and if there isn't any (or if none is suitable) then use a prediction based on knowledge of what you are about to install.  Honestly, though, this seems harder and messier than my previous alternative.

John

[Gavin Williams]

John

Cheers for the response...

It's quite possibly i'm over-thinking the possible permeations on the Java side, and probably need to strip it back to as simple as possible.
In that vein, I've gone with your suggestion of asserting what the JAVA_HOME will be once the relevant package has been installed by this module.

Will get the latest changes pushed shortly for comment.

Cheers
Gavin

[Corey Osman]

Basically you should be creating an init script for each java application that you start.  It should be the responsibility of that init script to set the JAVA_HOME/JAVA_BIN variables.  With this in mind you shouldn't need to worry about facts or different JAVA_HOME variables since the init script will set this explicitly for each java application you run.  You would want to have a java_home or java_bin puppet parameter in your class/define so that you can change java versions in hiera for a specific node/environment/datacenter.   If you want a "default" version that is the only reason I would see for setting JAVA_HOME in your bash_profile.

Have a look at java service wrappers to help automate that init script creation.  (This is what jenkins, puppetdb, and many others use).

Corey