Circular dependency between Entitler and *Pool classes

Devan Goodwin dgoodwin at rm-rf.ca
Tue Jul 6 14:48:14 UTC 2010


We were just chatting about this in IRC, I think it should help the
problem quite a bit, and if the business logic layer objects
eventually end up with another circular dep, it's cleaner to break
that functionality out (not directly related to a particular entity
type) into a new object even though we may not have the best of
reasons for doing so.

On Tue, Jul 6, 2010 at 8:30 AM, Bryan Kearney <bkearney at redhat.com> wrote:
> Would a third tier help this out?
>
> -- bk
>
> On 07/02/2010 03:23 PM, Ajay Kumar wrote:
>> Hello everyone,
>> Bryan wanted me to move the revocation code fragment present in
>> OwnerResource#refreshEntitlementPools
>>          if (log.isInfoEnabled()) {
>>              log.info("No of entitlements to revoke: #" + toRevoke.size());
>>          }
>>          for (Entitlement e : toRevoke) {
>>              this.entitler.revokeEntitlement(e);
>>          }
>>
>> into the PoolCurator#refreshPools so that it can be re-used by other classes.
>> However, moving this into PoolCurator requires that Entitler be
>> injected into the PoolCurator class.
>>
>> But, Entitler has the following constructor:
>>   protected Entitler(PoolCurator epCurator,
>>          EntitlementCurator entitlementCurator, ConsumerCurator consumerCurator,
>>          Enforcer enforcer, EntitlementCertServiceAdapter entCertAdapter,
>>          SubscriptionServiceAdapter subAdapter,
>>          EventFactory eventFactory,
>>          EventSink sink,
>>          PostEntHelper postEntHelper){
>> ....
>> }
>>
>> As you can see, Entitler requires almost all the Curators and this
>> prevents the Entitler to be re-used within
>> various Curator classes.(the vicious circle)
>>
>> What are your views on this issue? How do you think it can be resolved?
>
> _______________________________________________
> candlepin mailing list
> candlepin at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/candlepin
>



-- 
Devan Goodwin <dgoodwin at rm-rf.ca>
http://rm-rf.ca



More information about the candlepin mailing list