Re: [Pki-devel] [PATCH] refactor installation code to use python client instead of jython

On 3/19/2013 3:54 PM, Ade Lee wrote: > This is a pretty big change, but we want to get it into 10.0.2 so that > we can eliminate our dependency on jython. > > So far, its been tested against a straight CA install. I plan to > continue testing against other configurations, but as the code change is > quite large, I want to start the review early. > > Please review, > Ade Some comments: 1. Right now the encoder.py has to import other PKI modules in order to construct the TYPES and NOTYPES lists, so if new modules are added we'd need to update the encoder.py. This is not ideal since encoder.py is a common module. It might be better to let the modules register themselves into those lists, for example in encoder.py we can do something like this: import pki.encoder class ConfigurationRequest: ... encoder.TYPES['ConfigurationRequest'] = ConfigurationRequest

2. The SystemCertData is now in NOTYPES list. What if we want to send a SystemCertData object in a future API? It will need to be in TYPES. Maybe instead of using NOTYPES we should check if the object is an array and the elements are in TYPES then we return an array of encoded objects.

3. JSON responses should be converted back into Python object: http://stackoverflow.com/questions/6578986/how-to-convert-json-data-into-...

4. The ConfigurationResponse.getSystemCerts() should return a List instead of a Collection.

5. File access can be written with the 'with' keyword: with open(...) as f: data = f.read()

6. Sometimes OCSP or TKS installation failed: pkispawn : INFO ....... constructing PKI configuration data. pkispawn : INFO ....... configuring PKI configuration data. pkispawn : ERROR ....... Exception from Java Configuration Servlet: [Errno 111] Connection refused Maybe Tomcat is too slow to start? Sometimes it works just fine.