This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 228318

Summary: Netbinox caches should not crash product if findInstallationArea() changes
Product: platform Reporter: stoto79
Component: NetigsoAssignee: Jaroslav Tulach <jtulach>
Status: RESOLVED FIXED    
Severity: normal CC: apireviews, jrechtacek
Priority: P2 Keywords: API_REVIEW_FAST
Version: 7.4   
Hardware: PC   
OS: Linux   
Issue Type: DEFECT Exception Reporter:
Attachments: The tests that seem to demonstrate the failures
Tests, implementation and note in arch.xml

Description stoto79 2013-04-05 23:30:43 UTC
See Oracle bug 16450627: INVALIDEXCEPTION :CANNOT START ORG.ECLIPSE.EQUINOX.COMMON  .

In the above bug JDev, a product running the Netbinox platform, crashes if its NB caches are corrupted. In the above case, it crashed because the value of 'netbeans.dirs' was different at the time the cache was built and the time the product was ran. The system property 'osgi.install.area', which is equal to the root that every cache entry will be made relative to, is computed by NB as the most common prefix of all entries of 'netbeans.dirs', the caches gave us back the wrong jar locations, and JDev crashed. 

The resolution for that bug was to invalidate the caches from the JDev side. But since finding all cases where the cache should be invalidated is a such a ad-hoc, error-prone process, the caching mechanism should be forgiving enough and not crash the entire product. NB caching is an optimization, so--ideally anyway--failure in it should never crash our product, but possibly only run slower.
Comment 1 Jaroslav Tulach 2013-04-12 10:46:08 UTC
The puzzler that keeps me busy is: Should the system detect when just the top most directory changes or any change to the list of clusters?

For the JDev case, this is probably the same as addition of new clusters caused the common installation prefix to change. However for NetBeans, this would not be the case. All clusters are usually placed under directory "netbeans" and adding new ones won't change the common installation prefix at all.

The first approach could invalidate just the cache from core.netigso module (however that is unlikely correct, other files, for example containing list of modules have probably changed as well).

The latter approach requires us to store a checksum file (recording information about cache at the time of creation). There currently is such checksum file, but only in user directory and moreover it contains a bit too much information which might now be after installation (like time stamps of .lastModified files in each cluster).
Comment 2 Jaroslav Tulach 2013-04-15 10:15:11 UTC
Created attachment 133499 [details]
The tests that seem to demonstrate the failures
Comment 3 Jaroslav Tulach 2013-04-15 14:50:29 UTC
Requesting API change review, as I am about to add new file into the cache which may affect installer.
Comment 4 Jaroslav Tulach 2013-04-15 14:51:19 UTC
Created attachment 133505 [details]
Tests, implementation and note in arch.xml
Comment 5 Jaroslav Tulach 2013-04-22 06:36:41 UTC
Unless there are objections, I'll integrate the change tomorrow.
Comment 6 Jaroslav Tulach 2013-04-23 11:04:41 UTC
ergonomics#997ae78bd4b6
Comment 7 Quality Engineering 2013-04-28 02:18:12 UTC
Integrated into 'main-golden', will be available in build *201304272301* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/997ae78bd4b6
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #228318: Store relative paths of clusters with respect to common shared prefix