The plot thickens. Changing to RFE. Ironically, even if we wanted to modify the
GF cfg_cache to exclude the uuid = settings, it will not work. Until we make
some enhancements to how the Java API and bootstrap work, excluding uuid = in
the GF bundles installerless zip bundles is not feasible. Once the UC project
files an RFE to address some gaps on the UC side, we'll update this RFE with a
pointer to that issue.
Excluding uuid = in product bundles that don't make use of the pkg(5) Java API
apart from perhaps the initial bootstrap (e.g. Web Space, MQ, Web Stack, etc)
continues to be a recommended best practice because the pkg(5) Python API will
always automatically add the uuid settings.
Here's why excluding uuid = in the cfg_cache won't work with GF zip bundles today:
1) The bootstrap doesn't currently automatically add uuids when no uuid =
entries exist. It only resets uuid = entries when they exist. In the GF case,
this gap wouldn't matter that much because of the next aspect.
2) When start-domain is executed, the GF code uses the pkg(5) Java API to set
the uuids to the same value so as to align with the uuid used to identify and
potentially register the installation of GF. However, due to the behavior of
the Java API, it appears this setting only takes effect when the uuid = entries
(I have not tested the installer-wrapped GF bundles to see how they would behave
with uuid = not present).
As a result of this investigation, the UC team is looking into enhancing the
bootstrap and pkg(5) Java API to better handle cases where uuid = is not present
1) Double uuids for same installation:
Given the behavior today where start-domain effectively resets the uuids a
second time for the same installation, our backend usage reporting is probably
counting more unique installations than actually exist. Perhaps this issue is
limited to the use of GF zip bundles. The UC team will look into the reporting
2) Running bootstrap after start-domain overwrites sync'd uuids:
This is actually a very likely scenario:
- User downloads zip and expands it.
- User knows nothing about bin/updatetool and starts the domain.
- During start-domain, uuids are set and sync'd.
- Later on, user executes bin/updatetool which in turn executes the bootstrap.
At this point the bootstrap overwrites the sync'd up uuids as set via
start-domain. Another start-domain will sync the uuids again, but in the
meantime, a series of updates or installs may have occurred via the Update Tool
with the unsync'd uuids.