This OTN thread reminded me of some unsuccessful work I did a while back trying to ensure that the appropriate version of Java was invoked when launching EAS from the web.  After reviewing my notes and doing more digging I came up with a (hack-y, admittedly) workaround, so I decided to write it up.  If you want to see my ‘solution’ without the preamble, skip ahead to here.  And if you know of a simpler or more efficient solution, please, tell me in the comments!

Edited – April 30th

Thanks to Jason and John for their very helpful comments.

John has a solution – blogged in comprehensive detail here – that involves using an edited copy of the easconsole.jnlp file saved on the user’s local machine.  The technique that I (and, I think, Olivier Schaller according to this post on OTN) had tried previously involved modifying the server-side .jnlp file within the EAS application.

While I still don’t understand why that approach failed, John’s technique definitely works for me. So I may have unfairly libeled the authors of the JNLP documentation in the section Deeper into the JNLP, below!  John graciously says that both techniques are valid, but I’d recommend his option over modifying a properties file that is not intended to be edited manually.

I’ll continue to watch the OTN thread, and update this post again if Olivier reports any success with the server-side JNLP – that would be the best possible solution, in my opinion, since it would apply automatically for new users without any client-side shenanigans.

The Problem

Using the Essbase Administration Services (EAS) Console with an unsupported¹ version of Java is a frequent cause of apparently mysterious misbehavior.  Typically, the Administration Console will start up and connect to a server successfully, but then ignore specific commands or hang part-way through a process.  Problems using the Outline Editor are particularly common.

Manual Fixes

One ‘obvious’ solution is to install only the supported version of Java, but ensuring the presence of a single, specific version is more easily said than done, since:

• Multiple versions can coexist happily
• Different versions may be required by other applications
• Java is often configured to update automatically
• Corporate IT may push out a ‘helpful’ update

A more practical answer is to use the Java Control Panel to disable (temporarily) incompatible versions:

But this method is a nuisance for users who, like me, often switch between different EPM versions (with different compatibility requirements), or frequently run other applications that use a version of Java not also supported by their version of EAS.

It would be really convenient to have a one-click method of launching a particular instance of the EAS console in a way that guarantees that the appropriate version of Java is invoked.

What Web-Launching Does

As a preliminary step, I investigated exactly what happens when EAS is launched from a browser.  The ‘Launch’ button on the ‘Web Launcher for Administration Services Console’ page serves up a file named ‘easconsole.jnlp’.  The suffix stands for ‘Java Net Launcher Protocol’, and the JNLP file is an XML document which details (amongst other things) the .jar file containing the target application.  When clicked, the content of the JNLP file is passed to the Java Web Start application – javaws.exe – on the client.  Java Web Start downloads the target .jar file and other required resources, then launches it outside the browser².

With multiple versions of Java installed, there are corresponding multiple versions of javaws.exe available and no obvious way to force the browser to select a particular one.  However, it is possible to remove the browser from the equation by launching from a shortcut configured to point at a specific version of Java Web Start.

I set up a shortcut as follows:

• Found the path to the JRE bin directory of the appropriate version of Java – for example, ‘C:\Program Files\Java\jre6\bin\’
• Created a shortcut
• Set the shortcut ‘Target’ property (note that the double-quotes, URL and single space before the URL are all part of the value) to:  “jrebindirectory\javaws.exe” http://server:port/easconsole/easconsole.jnlp
• Set the shortcut ‘Start In’ property (again, the double-quotes are part of the value) to: “jrebindirectory“

Problem Solved, Right?

Double-clicking this shortcut will launch EAS from the web, but do so with the version of Java Web Start specified.  I was pretty pleased with myself at this point.

Unfortunately, and surprisingly, it doesn’t actually help at all!

Java Web Start is invoked in the version specified, but it turns out that one version of Java Web Start will happily fire another version of Java.  On my system, if Java 7 is enabled in the Java Control Panel, forcing the .jnlp to be processed by Java Web Start 6 still results in Java 7 being invoked to run the console.  Even more confusingly, the Java splash screen shows the version of Java Web Start, not the version of Java that is ultimately running EAS, giving the impression that the appropriate version is in use.  Checking the properties of the launched process via Task Manager tells a different story.

Deeper into the JNLP

At this point, I turned to investigating whether control could be applied from the ‘server end’ of the process.  Promisingly, the JNLP syntax does state that application developers can specify a required Java version via the ‘version’ attribute.  While this feature had been used in the easconsole.jnlp file installed in my 11.1.2.2 test system, the version is specified as “1.6+”.  According to the documentation, “1.6+” permits any version of 1.6 or greater – which of course, includes the unsupported version 1.7.  However, this proved to be another dead end.  Despite modifying the JNLP file on the EAS server to “1.6” (no “+”) Java Web Start would still invoke Java 7.  I experimented with different values in the JNLP file for some time, without success.  A Java developer may know better, but it seems that the JNLP syntax documentation is either wrong or incomplete on this topic.

Back to the Drawing Board

With my clever ideas exhausted, I returned to the ‘manual’ option described earlier – using the Java Control Panel.  Would it at least be possible to automate the process of disabling the incompatible versions?  A Google search reveals that the Java Control Panel is actually modifying a configuration file named “deployment.properties”, stored under the user’s “AppData” directory.  In my Windows 8 system, deployment.properties sits at “C:\Users\Tim\AppData\LocalLow\Sun\Java\Deployment”, and the file looks (in part) like this:

deployment.javaws.jre.2.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.1.registered=true
deployment.javaws.jre.0.product=1.7.0_25
deployment.javaws.jre.4.platform=1.5
deployment.javaws.jre.3.registered=true
deployment.javaws.jre.0.path=C\:\\Program Files (x86)\\Java\\jre7\\bin\\javaw.exe
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.2.path=C\:\\Program Files\\Java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.3.location=http\://java.sun.com/products/autodl/j2se

I don’t know why order is scrambled, rather than having all the “jre.0” properties together, followed by all the “jre.1” properties and so on – sorting the file doesn’t seem to make any functional difference.  In any case, each version of Java installed has a number of properties – “product” (e.g. “1.7.0_25”), “platform” (e.g. “1.7”) and, crucially, “enabled” (“true” or “false”).  Enabling or disabling a version in the Java Control Panel has the effect of toggling this property in the deployment.properties file.

So the problem could be resolved by a script to:

• Modify deployment.properties to disable all but the desired version
• Launch the console
• Return the deployment.properties file to its original state

A shortcut to this script would then provide a one-click means of launching a particular console instance with the correct Java version.

I am not a PowerShell Developer

Although the web-launched console will run in non-Microsoft operating systems, the vast majority of users have Windows clients.  That means that the logical choice of scripting language is PowerShell.

At this point I need to add a disclaimer that I know only enough PowerShell to be dangerous, so the following should definitely not be taken as a ‘best-practice’ example or tutorial for PowerShell.  For the same reason, I’m not going to give a line-by-line walkthrough of the code.  I’d be very happy to receive any suggestions for improvements or fixes.

All that said, I wrote the following script:

########################################################################
#       Name: LaunchEAS.ps1                                            #
#     Author: TimG                                                     #
#   Platform: PowerShell 3.0                                           #
#       Date: 4/23/2014                                                #
#    Purpose: Launch EAS from .jnlp, forcing use of a specific Java    #
#             Java version by manipulating deployment.properties       #
# Parameters: $1 = $version, the version of Java to be used            #
#             $2 = $easjnlp, the URL of the console .jnlp              #
#             $3 = $properties, the full path to deployment.properties #
#             $4 = $javaws, full path to the javaws used to process    #
#             the .jnlp                                                #
#   Modified: 4/23/2014 Initial version                                #
########################################################################

########################################################################
#                                                                      #
#       ***                   WARNING                       ***        #
#       *** Use of this script is entirely at your own risk ***        #
#       *** Ensure deployment.properties is backed up first ***        #
#                                                                      #
########################################################################

$version = $args[0]
$easjnlp = $args[1]
$properties = $args[2]
$javaws = $args[3]

#Check that $properties is a valid path / existing file.
#Back it up with .bak suffix if so, exit if not
If (Test-Path $properties) {
    Copy-Item -Path $properties -Destination "$properties.bak" -Force
}    
Else {
    Return
}

#Find the version 'id' used in deployment.properties for the specified Java version
Select-String -Pattern "^deployment.javaws.jre.(\d+).product=$version$" -Path $properties | Foreach-object {
    $count = $_.matches.count
    $versionid = $_.matches[0].groups[1].value
}

#If the specified version not found in deployment.properties exactly once, exit
If ($count -ne 1) {
    return
}

#Modify deployment.properties to set all versions of Java except the specified one to enabled=false
(Get-Content $properties) | 
Foreach-Object {
    $_ -Replace "^deployment.javaws.jre.([\d+-[$versionid]]).enabled=true$", 'deployment.javaws.jre.$1.enabled=false'
} |
Set-Content $properties

#Launch the console (asynchronously)
Start $javaws $easjnlp
#Sleep before switching the property file back, because launch sometimes takes a while, especially if the .jar
#needs to be downloaded.
Start-Sleep 30

# restore the .bak version of the properties file
Copy-Item -Path "$properties.bak" -Destination $properties -Force

Putting it Together

Using the above script requires saving it (as LaunchEAS.ps1) to an accessible location – for example, C:\Users\Tim\Scripts.

The script takes four parameters:

• The version of Java to be used, in the same format as shown in the Java Control Panel – e.g. “1.6.0_43”
• The URL of the JNLP file, e.g. “http://servername:port/easconsole/easconsole.jnlp”
• The location of the deployment.properties file, e.g. “C:\Users\Tim\AppData\LocalLow\Sun\Java\Deployment\deployment.properties”
• The path to Java Web Start, e.g. “C:\Program Files\Java\jre6\bin\javaws.exe”

The resulting shortcut target would therefore be:

Powershell "C:\Users\Tim\Scripts\LaunchEAS.ps1" '1.6.0_43' 'http://servername:port/easconsole/easconsole.jnlp' 'C:\Users\Tim\AppData\LocalLow\Sun\Java\Deployment\deployment.properties' 'C:\Program Files\Java\jre6\bin\javaws.exe'

However (with these paths, at least) this exceeds the maximum length (255 characters) that the target field of the shortcut dialog will accept.  So it’s necessary to create a one-line .bat file containing the above command, place that in the “Scripts” directory, and then point the desktop shortcut at the .bat file instead.

Using this script is not an ideal solution, since it involves directly modifying a configuration file that should really only be edited via the Control Panel. Additionally, the fixed delay between disabling other versions and returning the file to its original state creates a risk that a different application could be launched while the version of Java it requires is temporarily disabled (or, conversely, that the console won’t have been launched before the file is restored and incompatible Java versions are re-enabled).  I’m willing to accept the limitations for my own personal use.