Bug #7340
Cannot change certificate location after calling D1Client.getCN()
100%
Description
In Metacat, I noticed that CertificateManager.setCertificateLocation() would only work sporadically. Traced it down to D1Client (and related classes) caching CNode instances when they are requested. It works fine if the very first thing you do is set the desired CertificateLocation but not if your order is:
- D1Client.getCN()
- CertificateManager.setCertificatgeLocation(loc)
- D1Client.getCN() // uses old or default certificate location
Associated revisions
fixes #7340. Created a DefaultHttpMultipartRestClient that observes the CertificateManager and updates it's HttpClient when the default certificate location changes. This should side-step issues where existing cached CNodes and MNodes in D1Client are out of date with the default client certificate.
fixes #7340. Created a DefaultHttpMultipartRestClient that observes the CertificateManager and updates it's HttpClient when the default certificate location changes. This should side-step issues where existing cached CNodes and MNodes in D1Client are out of date with the default client certificate.
History
#1 Updated by Rob Nahf over 8 years ago
The root of the problem is the default certificate changing in CertificateManager without notice. Will extend the CertificateManager instance from java.util.Observable, so that it can be observed by D1Client or other classes that need to know.
Looking a bit more closely at the HttpMultipartRestClient, notice that it might be the ideal class to be the Observer - it has access to the HttpClient, so can change it via the Observer.update method.
#2 Updated by Rob Nahf over 8 years ago
- Status changed from In Progress to Testing
- % Done changed from 30 to 50
created a DefaultHttpMultipartRestClient that updates its HttpClient using the Observer pattern, and have D1Client classes using it so that the cached CNode and MNodes held in the SettingsContextNodeLocator are still valid, and use the new HttpClient, when CertMan.. setCertificateLocation is called.
#3 Updated by Ben Leinfelder over 8 years ago
I redeployed Metacat (built by Jenkins from trunk that included latest libclient build) and was able to update my node capabilities as expected so I believe this can be closed as far as Metacat is concerned.
#4 Updated by Rob Nahf over 8 years ago
- Status changed from Testing to Closed
- % Done changed from 50 to 100
Applied in changeset d1-python:d1_python|r16280.
