[PATCH] 326 Fixed problem running GroupMemberProcessor on non-CA.
Previously the GroupMemberProcessor could only run on CA because the base Processor class depends on CA. To fix the problem all CA-specific code in Processor has been moved into a new CAProcessor. All existing subclasses of Processor will inherit from CAProcessor, but the GroupMemberProcessor will continue to inherit from Processor. -- Endi S. Dewata
On 10/10/2013 10:00 AM, Endi Sukma Dewata wrote:
Previously the GroupMemberProcessor could only run on CA because the base Processor class depends on CA. To fix the problem all CA-specific code in Processor has been moved into a new CAProcessor. All existing subclasses of Processor will inherit from CAProcessor, but the GroupMemberProcessor will continue to inherit from Processor.
Reposted as separated patches. The first one renames Processor to CAProcessor to reflect the current CA dependency issue. The second one creates a new generic Processor super class to fix GroupMemberProcessor issue. Please apply in this order: 331, 326-1. As Ade noted, there are additional works to be done: 1. Some other non-CA-specific fields/methods should be moved to the super class as well including stats, getSSLClientCertificat(), maybe the authenticate(). 2. SecurityDomainProcessor will need to run on a standalone KRA, so it should not inherit from CAProcessor either. -- Endi S. Dewata
On 10/28/2013 11:41 AM, Endi Sukma Dewata wrote:
On 10/10/2013 10:00 AM, Endi Sukma Dewata wrote:
Previously the GroupMemberProcessor could only run on CA because the base Processor class depends on CA. To fix the problem all CA-specific code in Processor has been moved into a new CAProcessor. All existing subclasses of Processor will inherit from CAProcessor, but the GroupMemberProcessor will continue to inherit from Processor.
Reposted as separated patches. The first one renames Processor to CAProcessor to reflect the current CA dependency issue. The second one creates a new generic Processor super class to fix GroupMemberProcessor issue. Please apply in this order: 331, 326-1.
As Ade noted, there are additional works to be done: 1. Some other non-CA-specific fields/methods should be moved to the super class as well including stats, getSSLClientCertificat(), maybe the authenticate(). 2. SecurityDomainProcessor will need to run on a standalone KRA, so it should not inherit from CAProcessor either.
New patch #326-2 attached. Fixed GroupMemberProcessor to extend from Processor. -- Endi S. Dewata
ACK. Please make sure to complete the remaining work as indicated. Ade On Thu, 2013-10-31 at 19:21 -0500, Endi Sukma Dewata wrote:
On 10/28/2013 11:41 AM, Endi Sukma Dewata wrote:
On 10/10/2013 10:00 AM, Endi Sukma Dewata wrote:
Previously the GroupMemberProcessor could only run on CA because the base Processor class depends on CA. To fix the problem all CA-specific code in Processor has been moved into a new CAProcessor. All existing subclasses of Processor will inherit from CAProcessor, but the GroupMemberProcessor will continue to inherit from Processor.
Reposted as separated patches. The first one renames Processor to CAProcessor to reflect the current CA dependency issue. The second one creates a new generic Processor super class to fix GroupMemberProcessor issue. Please apply in this order: 331, 326-1.
As Ade noted, there are additional works to be done: 1. Some other non-CA-specific fields/methods should be moved to the super class as well including stats, getSSLClientCertificat(), maybe the authenticate(). 2. SecurityDomainProcessor will need to run on a standalone KRA, so it should not inherit from CAProcessor either.
New patch #326-2 attached. Fixed GroupMemberProcessor to extend from Processor.
_______________________________________________ Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
participants (2)
-
Ade Lee -
Endi Sukma Dewata