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.

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(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel