Hi all,
Upgrade tool has this "feature" that attempts to copy 3rd party jars from <gfv2>/lib to glassfish3/glassfish/lib if some user has decided to put jars there instead of in the domain. Ultimately, though, it's the user's responsibility to copy these jars if they exist. The tool, assuming it's used instead of just running asadmin, warns the user if it can't find <source_domain>/../../lib. In some installations of GF, it's just expected that it won't find that dir (e.g. package-based installs).
The copying is a deep copy that processes all files not in an exclude list. An example of one of these lists is here (I don't know how the contents were chosen):
v3/extras/upgrade/upgrade-jar/src/main/resources/com/sun/enterprise/tools/upgrade/common/unixV2LibExcludeList.properties
That all sounds nice, and the user is warned if the lib dir isn't found, but I've realized now that domainX/../../lib could be *anything* since the domainX directory can be anywhere. Even if it's in the default location, the jar contents aren't the same across all versions of GlassFish. For instance, I installed sges_ee-2_1_1-p08-solaris-sparc.bin to reproduce an issue there and saw that the upgrade tool copied these files over to the 3.1 installation:
Copied file: oam-integration.jar
Copied file: libutilforsyslog64.so
Copied file: modutil
Copied file: libjvminfoutil64.so
Copied file: libustdio.so
Copied file: libicudata.so
Copied file: libicuuc.so.2
Copied file: libicuuc.so
Copied file: libicuctestfw.so.2
Copied file: libustdio.so.2
Copied file: libicui18n.so.2
Copied file: libustdio.a
Copied file: libicutoolutil.so.2
Copied file: libicule.a
Copied file: libicuuc.a
Copied file: libicui18n.so
Copied file: libicudata.a
Copied file: libicutoolutil.a
Copied file: libicui18n.a
Copied file: libicuctestfw.a
Copied file: libicule.so
Copied file: libicutoolutil.so
Copied file: libicule.so.2
Copied file: libicuctestfw.so
Copied file: libicudata.so.2
Copied file: libsqlite3.so
Copied file: libsoftokn3.so
Copied file: libfreebl_32int_3.so
Copied file: libnss3.so
Copied file: libnssdbm3.so
Copied file: libfreebl_32int64_3.so
Copied file: libssl3.so
Copied file: libjss4.so
Copied file: libnssckbi.so
Copied file: libfreebl_32fpu_3.so
Copied file: libnssutil3.so
Copied file: libsmime3.so
Copied file: libnspr4.so
Copied dir: cpu
Copied file: libplds4.so
Copied file: libplc4.so
Copied dir: jdbcdrivers
Copied file: README.pkg
I don't think we want that.
So can I get rid of this "feature?" I can't think of any foolproof way to implement it other than to tell the user to handle it if s/he added any jars where they really shouldn't be anyway. Even if I can create an all-inclusive list of every jar file (and other file) that was ever shipped in GF v2.X or 3.X, there's no way to know that the user hasn't altered one of these jars in his/her installation unless we want to ship a copy of all of them to diff.
Thanks,
Bobby