locked
Sun Java Co-Existence Problems RRS feed

  • Question

  • I've read various articles on how to get virtual Java applications co-existing with locally installed versions of Java without conflicting, but I'm not quite sure of the implications of each as they each have flaws.

    #1 - http://blogs.technet.com/b/virtualworld/archive/2007/08/14/troubleshooting-softgrid-with-process-monitor.aspx
    In this article, he tells you to simply delete the HKCU\Software\Classes\CLSID key in its entirety. This does indeed fix the problem of having a virtualized version of java and a locally installed version of java on the same machine, but wouldn't it potentially cause problems for any other applications that may have keys under CLSID? It seems like it could break a lot of stuff. Somehow the locally installed Java keys seem to recreate themselves automatically. I also tried to get this option to work by adding the scripting to my Java OSD, but I couldn't get the script to run (maybe because I'm dynamically suiting this to my main Java app). I am able to get it to run if I add the scripting to the main app I call.

    #2 - http://blog.stealthpuppy.com/virtualisation/juggling-sun-java-runtimes-in-app-v/
    In this article the user is saying he didn't want to do option #1 above so he simply added the keys and deleted them during sequencing so that it wouldn't see those problematic keys in the virtual bubble. The problem with this is that you'd have to update all of your virtualized java packages each time a new version of java came out so that it wouldn't conflict with it. I thought that potentially I could follow this article and just add the entire CLSID key and then delete it so that it wouldn't see anything in that area, but I'm not quite sure I fully understand how the virtual bubble sees the local file system and registry.

    Are there better ways to handle this or is my thinking incorrect? I've also thought about creating the key HKCU\Software\Classes\CLSID and having it be empty in my virtualized Java package and then set it to "Override Local" so that it wouldn't see anything, but I've got more testing to do with that.

    I thought I'd poll everyone here to see what the consensus is. I'm running App-V 4.6 using SCCM R2.

    Friday, March 4, 2011 3:17 PM

Answers

  • If you delete keys that are part of the local machine within the virtual registry then those keys will be hidden from the virtual application. they will still exist outside of the virtual environment. E.g You have Office installed locally so the key HKLM\Software\Microsoft\Office is there in local registry. Run a regedit within your virtual java application and you can see this office reg key. Try deleting it. Its no longer visible in the virtual registry. Close regedit and launch regedit outside the virtual app, you'll still see HKLM\Software\Microsoft\Office. This is the principle behind the approach to java applications. The sequencer monitors and captures the actions performed on the registry, thus deleting a key during sequencing will result in it being hidden in the virtual registry.  
    Friday, March 4, 2011 4:09 PM

All replies

  • I use method #2 as method #1 could potentially create a lot more problems than it fixes. Method #2 is perfect for a managed environment (which i'm used to) as you're only going to have 1-2 java versions as part of your build so you only have to accommodate them. As for new java versions, i'd imagine you could launch an externally managed script within the virtual environment that deletes the necessary java keys. That way you only have to update the one script instead of constantly updating the sequence.
    Friday, March 4, 2011 3:54 PM
  • Maybe I'm unsure of how the virtual/non-virtual environments interact, but whenever I call a script to delete registry keys from within the virtual environment, it appears to delete the actual registry keys. Is there a way to script it so that the virtual environment can't "see" those keys?
    Friday, March 4, 2011 3:57 PM
  • If you delete keys that are part of the local machine within the virtual registry then those keys will be hidden from the virtual application. they will still exist outside of the virtual environment. E.g You have Office installed locally so the key HKLM\Software\Microsoft\Office is there in local registry. Run a regedit within your virtual java application and you can see this office reg key. Try deleting it. Its no longer visible in the virtual registry. Close regedit and launch regedit outside the virtual app, you'll still see HKLM\Software\Microsoft\Office. This is the principle behind the approach to java applications. The sequencer monitors and captures the actions performed on the registry, thus deleting a key during sequencing will result in it being hidden in the virtual registry.  
    Friday, March 4, 2011 4:09 PM
  • That is exactly how I thought it should work, but I'm definitely not seeing that in my testing. I am essentially having one of my virtual apps run the script to delete some registry keys, which I THOUGHT was inside the virtual environment only. However, I launch regedit locally and the registry keys are indeed deleted locally (not solely from the virtual environment). I also seem to see the entire registry which I didn't think the virtual environment would see. Is it something with the way I'm starting regedit? I am essentially having my virtual application launch cmd.exe and then I am launching regedit from there.
    Friday, March 4, 2011 9:21 PM
  • How are you launching command prompt? if you're using a pre-script you could be launching it pre-load...
    Friday, March 4, 2011 10:29 PM