1

I am using Install4J 6.1.5 and I am trying to modify the classpath using a manually constructed vmoptions file and the slightly documented -classpath/a vmoptions file instruction.

It appears that the -classpath/a and -classpath/p options do not support paths with environment variables in them, at least in linux launchers. When I include:

-classpath/a ${HOME}/.ssheena-server/resources

To a vmoptions file, the ${HOME} appears in its' unaltered form in the launchers' -classpath parameter when I look at the java process using ps -ef:

-classpath /opt/bids/ssheena-server/.install4j/i4jruntime.jar:${HOME}/.ssheena-server/resources

Is there a way to use -classpath/a that will support using environment variables?

Jay Guidos
  • 151
  • 9

1 Answers1

0

As of install4j 6.1.5, environment variable substitution in classpath modifications in .vmoptions files is not supported.

You could modify the .vmoptions file with an action in the installer. For example, you could use the installer variable syntax

${installer:sys.userHome}

in .vmoptions file and use a "Replace installer variables in text files" action to replace it at runtime.

Ingo Kegel
  • 46,523
  • 10
  • 71
  • 102
  • Hi Ingo! Thanks for your prompt reply. In this case I am using a vmoptions file that is manually constructed during the deployment of an RPM, which has only limited access to installer runtime actions. Also, for the example listed I really do want the classpath to reflect the **invoker's** $HOME directory, which will vary with the user invoking the launcher. – Jay Guidos Mar 07 '17 at 21:40
  • OK, I understand. Unfortunately, replacing environment variable definitions in strings that are read from files is quite difficult to do with a POSIX Bourne shell. In the RPM media file wizard, you could use the "Installer options->Post-install script" step to write or modify the .vmoptions file with the absolute path. – Ingo Kegel Mar 08 '17 at 07:54
  • That will not work - the $HOME variable is per-user - somehow the RPM file would have to create or modify a vmoptions file for every user on the machine it is installing on. There is clearly a use case for adding per-user resources to the classpath assembled by the launcher that is not handled by any work around you have suggested so far. In the POSIX launcher code you could just do an echo of the generated launch path: `echo -classpath $local_classpath` to achieve the desired effect, right? – Jay Guidos Mar 08 '17 at 21:15
  • like in this example: $INSTALL4J_JAVA_PREFIX exec "$app_java_home/bin/java" -Dinstall4j.jvmDir="$app_java_home" -Dexe4j.moduleName="$prg_dir/$progname" "-Dinstall4j.launcherId=105" "-Dinstall4j.swt=false" "$vmov_1" "$vmov_2" "$vmov_3" "$vmov_4" "$vmov_5" $INSTALL4J_ADD_VM_PARAMS -classpath "**\`echo $local_classpath\`**" com.install4j.runtime.launcher.UnixLauncher run-redirect 36df8614 "" "" com.bids.ssheena.server.Main – Jay Guidos Mar 08 '17 at 21:18
  • I see the use case, but these kinds of features are difficult to implement because they span multiple platform-specific launchers. I think you will have to use a classloader in your application for that. "just do an echo" unfortunately not, see http://stackoverflow.com/questions/10683349/forcing-bash-to-expand-variables-in-a-string-loaded-from-a-file – Ingo Kegel Mar 08 '17 at 21:21
  • I see your point. How about forgetting about environment variables, and pushing the problem into the launcher (**com.install4j.runtime.launcher.UnixLauncher**)? What if your launcher scanned the classpath for some token, say like this: **${i4j:java.home}/lib** and and then launched my main after doing property translation and a scrubbed classpath? – Jay Guidos Mar 09 '17 at 22:06
  • Sure, that would be possible to implement, although you can do that in the just the same way with your own wrapper main class that constructs a URLClassLoader and loads your real main class with that class loader. – Ingo Kegel Mar 10 '17 at 06:57