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.
--
Endi S. Dewata