Running Web-Launched EAS with the Right Java Version

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 unsupported1 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:

The Java Runtime Environment Settings dialog in the Java Control Panel
 

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 browser2.

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.

Show 2 footnotes

  1. The supported version(s) of Java for a given EPM release can be found in the relevant Certification Matrix, available from Oracle here.  Note that if the Certification Matrix states that (for example) Java “1.6_22+” is supported, this does not mean that 1.7 is supported.  See the explanatory note on Oracle’s Proactive Support blog.
  2. The Wikipedia article on Java Web Start gives a much more comprehensive explanation

12 thoughts on “Running Web-Launched EAS with the Right Java Version

  1. Hi Tim,

    Another great article. Just a thought since I run into this too: You can create a batch file that specifies the full path to an instance of javaws.exe on the system, followed by the JNLP URL, and then it’ll run the JNLP file with that particular JRE. So on my case since I have several JDKs/JREs installed but want to force EAS to launch with a 1.6 JRE, I specific the full path, so the contents of the local batch file are something like “C:\Java\jre1.6\bin\javaws.exe http://example.com/easconsole/easconsole.jnlp“.

    Also, the reason the numbered properties are out of order is presumably because it’s a Java Properties object, which is backed by a HashMap (but frequently just thought of as a Map) and the key/value pairs are not guaranteed to be serialized lexicographically with respect to the key. Which is just a fancy way of saying that for intents and purposes, the order of the properties can be seemingly random.

    • Hi Jason,

      Thank you for the comment, and the for the insight in to the ordering question – that further reinforces the point that you’re not really supposed to be messing with the file manually!

      On the first point, I really hope that you’re right and that I’m just doing something wrong, but my system didn’t seem to behave that way. I am running Windows 8 and have 1.7.0_21, 1.6.0_43 and 1.6.0_22.

      If I use a shortcut to explicitly launch javaws.exe from /jre6/bin, I get the Java 6 splash screen as javaws.exe launches but if v7 is not disabled the v6 javaws.exe actually invokes the process with the v7 javaw.exe (I can tell from looking at the properties of the process in Task Manager, and from the misbehavior of the console that I know I only see in 7).

      Like I said, I would love to be wrong about this, because processing the deployment.properties files is such as hack! Any thoughts?

      Thanks again,

      Tim

      • Hi Tim,

        I emailed you this too but I’m cross-posting in case it comes in handy for any future visitors/Googlers.

        I think the answer (for me at least) is to be even a bit more “low tech” about it. In other words, don’t use a shortcut to java/javaws itself, but rather a shortcut to a batch file that calls one of those. For example, here’s a copy and paste from a small batch file I have on my desktop right now:

        C:\Java\jdk1.6.0_37\jre\bin\javaws https://essbasservername.clientdomain.com:4443/easconsole/easconsole.jnlp

        In this case I am not relying on Windows to set the start directory or anything: I’m quite literally just forcing a very particular javaws.exe to run, then feeding it the exact URL for the JNLP file. Note that in this case it’s over SSL (https) rather than the probably more common http, but that doesn’t really change the semantics.

        I resort to this method because the VM this runs on has Java 1.7 as the default and will soon have 1.8 installed, so any this just saves me from having to mess around with trying to set which is the default. It’s not “elegant” I suppose but it’s quick and dirty.

        Hope that helps,

  2. Thanks again, Jason. Nice to have some input from a genuine Java developer. But, unfortunately, I’m still baffled.

    I created a .bat file containing this:

    “C:\Program Files\Java\jre6\bin\javaws.exe” http://servername:port/easconsole/easconsole.jnlp

    When I double-click it, I see the Java 6 splash screen, and EAS launches. But when I open up Task Manager and look at the properties of the “Java(TM) Platform SE Binary” process (i.e. the EAS console) it says it’s “javaw.exe” from location “C:\Program Files\Java\jre7\bin”. The version 6 Web Start is invoking Java 7.

    I also tried pointing it at the copy of javaws.exe in jre1.6.0_22, with the same results. There must be an environmental difference that explains why this works for you and not me, but I have no idea what it is…

    I don’t think that it’s an inelegant solution, by the way (or at least, still an awful lot more elegant than hacking the properties file!).

  3. Hi Tim,

    I see the same issue of the splash screen using 1.6 and then 1.7 being invoked using that method on Windows 7.

    The way I do it to invoke using 1.6 or 1.7 is first to download the jnlp, I do this by changing the property of a jnlp to open with a text editor instead of java web start.
    I then go to the http easconsole page and download the jnlp to the client machine, once the file has downloaded the property for jnlp can be set back to open with java web start.

    The downloaded jnlp I don’t update and use the following command to open using 1.7
    “C:\Program Files\Java\jre7\bin\javaws.exe” “C:\EAS\eas17.jnlp”
    or you could just access easconsole in the usual way as it should invoke 1.7

    I make a copy of the jnlp and edit it, update

    to

    so basically just remove the + from 1.6+

    Then start with
    “C:\Program Files\Java\jre6\bin\javaws.exe” “C:\EAS\eas16.jnlp”

    Seems to work for me and once done does not require any changes to files or the java control panel.

    Cheers

    John

  4. Hi,
    I am having the same problem, one of my app. uses 1.5.0_14 and other one need 1.7. I tried couple of things but never succeded. Any ideas?

  5. I made something similar once.
    Inside the JNLP, I changed the version from “1.6+” to “1.6*” and then some calls start to work fine.
    Another thing about the JNLP, there is in the last lines of the file a tag
    I include this lines:
    -uMYUSER
    -pMYPASS
    This way, the EAS connect without prompt.
    Even though, save your password without encription may be a security flaw.

      • Thanks for your comment Wesley – perhaps I missed trying “*” instead of “+”? I’m definitely going to try the -u and -p switches, at least in my sandbox environments.

  6. i have you a smarter solution ex. for a Batch set the Classpath Environemen..

    like..
    SET java_home=C:\LocalData\jre
    SET PATH=%java_home%\bin\;%PATH%
    :: This will help solve your Problem…
    Set CLASSPATH=”%java_home%\lib\javaws.jar;%java_home%\lib\deploy.jar”
    “%java_home%\bin\javaws.exe” -Xnosplsah “http://server/start.jnlp”

    hope this help, and your apps run as before…
    Environement is also nice for Application Virtualisation with the same Problem…

  7. My company’s Desktop Management group used App-V and packaged EAS with the correct version of Java (1.6). The users now have a single shortcut on the desktop to launch the application. Works like a champ!

    As I am not in the Desktop group, I don’t have a lot of specifics. I can share some of the properties in the shortcut to provide a little insight:

    TARGET
    %ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\A1DF7320-4A60-4BEA-916C-51A275A961BF\Root\VFS\ProgramFilesX86\Java\jre6\bin\javaws.exe %ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\A1DF7320-4A60-4BEA-916C-51A275A961BF\Root\easconsole.jnlp

    START IN
    %ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\A1DF7320-4A60-4BEA-916C-51A275A961BF\Root\VFS\ProgramFilesX86\Java\jre6\bin

    As new users require the application (or new machines are rolled out), the package can be pushed out via MS Software Center.

  8. Pingback: Launching a Java JNLP file with an Old version of JRE – Sys Admin Jam

Leave a Reply to Shawn Kogan Cancel reply

Your email address will not be published. Required fields are marked *