1:45 a.m.
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
7:47 p.m.
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(a)redhat.com>
To: "pki-devel" <pki-devel(a)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(a)redhat.com
https://www.redhat.com/mailman/listinfo/pki-devel
9:49 a.m.
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
3902
days inactive
3945
days old
2 comments
2 participants
participants (2)
-
Endi Sukma Dewata -
John Magne