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?
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?
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@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@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/candlepin
candlepin@lists.fedorahosted.org