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

[Endi Sukma Dewata]

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-a-python-object

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