[PATCH] 376 Fixed TPS resource statuses.
TPS resources that are stored in CS.cfg have been refactored to update their statuses properly. These resources include profiles, profile mappings, connections, and authenticators. Ticket #654 -- Endi S. Dewata
ACK: A few simple questions. 1. I notice we have resources for CS.cfg Connections. Does this clash with the so-called "Connectors" we already have in the Java subsystems? Or are they designed as a replacement? I'm speaking of the Connectors that allow us to talk from subsystem to subsystem. 2. I notice we have separate classes for the various types of CSCfgRecords, being ConnectionRecord, or ProfileRecord, etc. The entirety of those classes seem to be taken care of by the base class, CSCfgRecord. Further down the line we have XXXDatabase classes that have methods to add these records, such as CreateConnectionRecord, or CreateProfileRecord. The methods appear to be pretty similar to each other. Would it have been possible to put much of this down into the base class? ----- Original Message ----- From: "Endi Sukma Dewata" <edewata@redhat.com> To: "pki-devel" <pki-devel@redhat.com> Sent: Tuesday, December 17, 2013 11:45:50 PM Subject: [Pki-devel] [PATCH] 376 Fixed TPS resource statuses. TPS resources that are stored in CS.cfg have been refactored to update their statuses properly. These resources include profiles, profile mappings, connections, and authenticators. Ticket #654 -- Endi S. Dewata _______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
On 1/28/2014 7:47 PM, John Magne wrote:
ACK:
Thanks. Pushed to master.
A few simple questions.
1. I notice we have resources for CS.cfg Connections. Does this clash with the so-called "Connectors" we already have in the Java subsystems? Or are they designed as a replacement? I'm speaking of the Connectors that allow us to talk from subsystem to subsystem.
Do you mean the KRAConnector in CA and TPSConnector in TKS? It looks like they are designed for different purpose. They use specific parameters which don't match with the parameters used in TPS. The Connections in TPS are used to manage generic connection configurations in TPS. It doesn't actually establish a connection yet.
2. I notice we have separate classes for the various types of CSCfgRecords, being ConnectionRecord, or ProfileRecord, etc. The entirety of those classes seem to be taken care of by the base class, CSCfgRecord.
Yes. They are originally unrelated classes but now they inherit from the same base class.
Further down the line we have XXXDatabase classes that have methods to add these records, such as CreateConnectionRecord, or CreateProfileRecord. The methods appear to be pretty similar to each other. Would it have been possible to put much of this down into the base class?
These classes have been simplified quite a bit. I don't want to simplify too much in case there are resource-specific logic that has to be added while I'm still looking at the original TPS code, but we can certainly clean it up later. -- Endi S. Dewata
participants (2)
-
Endi Sukma Dewata -
John Magne