Using App-V DSC with Java
Hi folks,
At the client site I'm on they have a number of apps using JRE.
At the moment there is a physical install of the JRE using a deployment.config file in C:\Windows\Sun\Java\Deployment pointing to a deployment.properties in the C:\Program Files/Java/jre6/lib/ folder. The deployment.properties file contains things like disabling the autoupdate which you would want by default, but it also contains application specific entries.
Three applications share this physical install and each has it's own settings in this file. As it happens they are all happy to coexist with the options set at the moment but going forward there will undoubtedly be occasions where one will directily conflict with another.
Can DSC help me here? Create a secondary JRE package with a deployment.config in it, but then have the primary applications copy their own specific deployment.properties file into the correct location when they launch?
I'm new to DSC so bear with me, but if I launch two primary apps and they both call the same secondary app at the same time via DSC, there is only one instance of the secondary app mounted in a single Q:\<MNT folder>? In which case the primaries can't both copy their version into the same area, can they? Even if I have deployment.properties files in separate areas, there can only be one deployment.config file which can only point to one file at any one time.
Am I going to have to abandon the DSC approach in this case and just sequence using the old model i.e. a JRE install + application's URL in one bubble?
If so, presumably DSC is only of much help for middleware packages, if the middleware itself doesn't require config after install (XML Parser, VC++ 2008 redistributables, etc.)
Hope I've got some JRE/DSC gurus reading today! [;)]
Many thanks,
Dangle
At the client site I'm on they have a number of apps using JRE.
At the moment there is a physical install of the JRE using a deployment.config file in C:\Windows\Sun\Java\Deployment pointing to a deployment.properties in the C:\Program Files/Java/jre6/lib/ folder. The deployment.properties file contains things like disabling the autoupdate which you would want by default, but it also contains application specific entries.
Three applications share this physical install and each has it's own settings in this file. As it happens they are all happy to coexist with the options set at the moment but going forward there will undoubtedly be occasions where one will directily conflict with another.
Can DSC help me here? Create a secondary JRE package with a deployment.config in it, but then have the primary applications copy their own specific deployment.properties file into the correct location when they launch?
I'm new to DSC so bear with me, but if I launch two primary apps and they both call the same secondary app at the same time via DSC, there is only one instance of the secondary app mounted in a single Q:\<MNT folder>? In which case the primaries can't both copy their version into the same area, can they? Even if I have deployment.properties files in separate areas, there can only be one deployment.config file which can only point to one file at any one time.
Am I going to have to abandon the DSC approach in this case and just sequence using the old model i.e. a JRE install + application's URL in one bubble?
If so, presumably DSC is only of much help for middleware packages, if the middleware itself doesn't require config after install (XML Parser, VC++ 2008 redistributables, etc.)
Hope I've got some JRE/DSC gurus reading today! [;)]
Many thanks,
Dangle
0 Comments
[ + ] Show comments
Answers (8)
Please log in to answer
Posted by:
dangle
12 years ago
Thanks Pratik but I don't think that's going to help me much. I would still need to create a sequence for each of the 3 applications consisting of the "base JRE install + IE shortcut to server hosting the Java app + JRE config specific to each app". This is what I was trying to avoid in the case 3 apps becomes 10 apps.
I was hoping that DSC would allow a generic JRE install with no customisations, but the primary app consists of the IE shortcut and the Java settings each app needs. Not all Java settings are registry based otherwise I guess the primary app's reg keys could be configured to just replace any keys also present in the secondary's layer.
I was hoping that DSC would allow a generic JRE install with no customisations, but the primary app consists of the IE shortcut and the Java settings each app needs. Not all Java settings are registry based otherwise I guess the primary app's reg keys could be configured to just replace any keys also present in the secondary's layer.
Posted by:
pjgeutjens
12 years ago
It should be possible to create this solution. One thing you need to keep in mind is that environment variables (I think actually everything defined in the OSD, not sure though) for the prerequisite package (JRE) will NOT propagate into the bubble of the main application when they are linked through DSC. So you would need to add these to the OSD of the main applications as well. I'm thinking specifically of JAVA_HOME settings in this case. I guess you would put deployment.config file in the JRE sequence, and deployment.properties in each of the main applications.
PJ
PJ
Posted by:
dangle
12 years ago
Thanks PJ.
I must admit I've heard references to JAVA_HOME but following an install of JRE 1.6.29 (for instance) there's no sign of these. I'm sure they haven't appeared in other 1.6.x installs I've done either. There's JavaHome Registry keys within the HKLM\Software\JavaSoft\ structure. Is this environment var from older versions do you know?
The deployment.config must go in C:\Windows\Sun\Java\Deployment and it points to a single location. So unfortunately it can't point to each app's deployment.properties location. And if the each primary app included a deployment.config pointing to their own deployment.properties file, what would happen when the second primary app were run at the same time? Surely it would overwrite any C:\Windows\Sun\Java\Deployment\deployment.config it found with its own copy?
As asked above, is there only one instance of the secondary app? It can only mount in the Q:\<MNT folder> location once and it's a single copy shared by all dependant apps simultaneously?
Cheers.
I must admit I've heard references to JAVA_HOME but following an install of JRE 1.6.29 (for instance) there's no sign of these. I'm sure they haven't appeared in other 1.6.x installs I've done either. There's JavaHome Registry keys within the HKLM\Software\JavaSoft\ structure. Is this environment var from older versions do you know?
The deployment.config must go in C:\Windows\Sun\Java\Deployment and it points to a single location. So unfortunately it can't point to each app's deployment.properties location. And if the each primary app included a deployment.config pointing to their own deployment.properties file, what would happen when the second primary app were run at the same time? Surely it would overwrite any C:\Windows\Sun\Java\Deployment\deployment.config it found with its own copy?
As asked above, is there only one instance of the secondary app? It can only mount in the Q:\<MNT folder> location once and it's a single copy shared by all dependant apps simultaneously?
Cheers.
Posted by:
pjgeutjens
12 years ago
I wouldn't put the deployment.config file in the 2 apps. I would put deployment.config in the underlying JRE package that you are going to use in DSC, and then only put the deployment.properties file in the sequence for the different main applications (not the JRE), each in VFS, each on the same location that the deployment.config file from the JRE points to. Each bubble should have its own VFS folder under Q:\MyPackage\VFS and should be able to operate independently.
Since you would still need the components of the underlying JRE, the setting for the deployment.properties file in your sequence for the main apps should be 'Merge'. You'll noticed I started speaking more and more in the hypothetical, cause this is really something you should test. For some background info you might like to read the following:
http://blogs.technet.com/b/serverappv/archive/2011/04/14/isolation-and-state-separation.aspx
http://www.tmurgent.com/WhitePapers/AppV_DSC_Transparency.pdf
Hope you get there, keep me posted :)
PJ
Since you would still need the components of the underlying JRE, the setting for the deployment.properties file in your sequence for the main apps should be 'Merge'. You'll noticed I started speaking more and more in the hypothetical, cause this is really something you should test. For some background info you might like to read the following:
http://blogs.technet.com/b/serverappv/archive/2011/04/14/isolation-and-state-separation.aspx
http://www.tmurgent.com/WhitePapers/AppV_DSC_Transparency.pdf
Hope you get there, keep me posted :)
PJ
Posted by:
dangle
12 years ago
Thanks PJ. That's helped a lot.
So if I had 3 JRE apps, they would all be mounted like so: -
Q:\MyPackage1\
Q:\MyPackage2\
Q:\MyPackage3\
A non Appv deployment.config may have an entry something like: -
deployment.system.config=file\:C\:/Program Files/Java/jre6/lib/deployment.properties
So if we put deployment.config in the JRE secondary app as proposed, it would still have the entry but each app would be redirected to their copy in their own VFS like so?
Q:\MyPackage1\VFS\CSIDL_PROGRAM_FILES\MyApp\Java/jre6/lib/deployment.properties
Q:\MyPackage2\VFS\CSIDL_PROGRAM_FILES\MyApp\Java/jre6/lib/deployment.properties
Q:\MyPackage3\VFS\CSIDL_PROGRAM_FILES\MyApp\Java/jre6/lib/deployment.properties
Cheers.
So if I had 3 JRE apps, they would all be mounted like so: -
Q:\MyPackage1\
Q:\MyPackage2\
Q:\MyPackage3\
A non Appv deployment.config may have an entry something like: -
deployment.system.config=file\:C\:/Program Files/Java/jre6/lib/deployment.properties
So if we put deployment.config in the JRE secondary app as proposed, it would still have the entry but each app would be redirected to their copy in their own VFS like so?
Q:\MyPackage1\VFS\CSIDL_PROGRAM_FILES\MyApp\Java/jre6/lib/deployment.properties
Q:\MyPackage2\VFS\CSIDL_PROGRAM_FILES\MyApp\Java/jre6/lib/deployment.properties
Q:\MyPackage3\VFS\CSIDL_PROGRAM_FILES\MyApp\Java/jre6/lib/deployment.properties
Cheers.
Posted by:
pjgeutjens
12 years ago
Yes,
in each app-v bubble the deployment.properties file in the VFS should be merged into (i.e. layered above) the physical Program Files folder and should also 'see' everything in the DSC'd JRE. So each app should only see its own deployment.properties file.
Only thing I'm not 100% sure of is the behavior of the JRE in each instance. I wonder if the changes in the properties file will immediately be picked up by the JRE. Something to test ;-)
PJ
in each app-v bubble the deployment.properties file in the VFS should be merged into (i.e. layered above) the physical Program Files folder and should also 'see' everything in the DSC'd JRE. So each app should only see its own deployment.properties file.
Only thing I'm not 100% sure of is the behavior of the JRE in each instance. I wonder if the changes in the properties file will immediately be picked up by the JRE. Something to test ;-)
PJ
Posted by:
dangle
12 years ago
Cool. Very busy here at the moment so will not get a chance to test for a while but will report back when I do.
Thanks again.
Thanks again.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.