Hello Jim Klimov, No, I havent.
Thank you very much for your informations and tips. On Juli, 25 2014, 10:47 <Jim Klimov> wrote in [1]: > Did you previously use and manage Java, on solaris, ilkumos or other oses? > There is a JAVA_HOME environment variable (set in shell, profile, > initscript, smf attribs, etc.) that points your Java program such as > tomcat, or a cli tool, or some gui installer or whatever to the > installation location of the jvm you want to use in this case. Of > course, the "java" program for this jvm instance should be from the > corresponding "$JAVA_HOME/bin" path. > So you can have multiple installations and many JVMs running with > different versions (there are programs where backwards compatibility > does not cut it and you do need an older version of Java for example). > It is customary to install Solaris java's into > /usr/jdk/instances/<versioncode>/ and symlink /usr/jdk/latest and > /usr/java to the directory with the version you need most likely, > and a dozen programs in the standard PATH like /usr/bin/java are in > fact symlinks to /usr/java/bin/java and such. > For hosts where /usr is system-managed and should not be touched by > users according to some policy, /opt/jdk, /opt/java or plain > /opt/<versioncode> are commonly used as containers for jre/jdk > installations (typically as unzipped archives, unpackaged). It still > makes sense to maintain /opt/java or even /usr/java (if changeable) > to point to the installation this zone needs. > Note that for some java versions the x86_64 package or archive only > includes the 64-bit files and should overlay a 32-bit jvm of the > same version installed/unpacked into the same location. For other > oses or major java versions the releases are fully sufficient. An > indicator may be the file size (i.e. 80mb 32-bit + 10mb 64-bit vs. both > similarly-sized). > As a hint, if you use many local zones to host farms of java > appservers,etc., you'll find that updating java's consistently > (especially un-packaged) has a large footprint in storage and > management, more so if you customize the jdk installations (local > CA's, most recent timezones and so on). Instead, I > install/unpack/customize once in the GZ (one best-compressed dataset > per jdk in a structure resembling the standard solaris jdk > installation), and lofs-mount the whole lot into the local zones. If > certain zones need more customization, you can clone off their copy > of jdk dataset and delegate into the zone, but we've never needed > that beyond some testing of the approach (cumbersome but works and > saves space). Also, once you've completed this update on one host, > it is easy to 'zfs-send' to your other GZ's hosting LZs with javas. > HTH, > //Jim > Ps: OTN = Oracle TechNet > -- > Typos courtesy of K-9 Mail on my Samsung Android -- Best Regards Alexander Juli, 25 2014 ........ [1] mid:[email protected] ........ _______________________________________________ OmniOS-discuss mailing list [email protected] http://lists.omniti.com/mailman/listinfo/omnios-discuss
