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