Re: [PATCH] Bug 3118: ecap_enable on forces icap_enable on

From: Tsantilas Christos <chtsanti_at_users.sourceforge.net>
Date: Wed, 03 Aug 2011 11:45:28 +0300

On 08/02/2011 12:24 PM, Amos Jeffries wrote:
> On 01/08/11 22:08, Tsantilas Christos wrote:
>> On 07/30/2011 02:36 AM, Amos Jeffries wrote:
>>> On 30/07/11 02:10, Tsantilas Christos wrote:
>>>> This is a patch which solves the bug 3118. Because it is not so small I
>>>> am posting it here for comments.
>>>>
>>>> Here is the patch description:
>>>>
>>>> Currently we were updating [Icap|Ecap]::TheConfig even when
>>>> [icap|ecap]_enable was false, which may lead to service activation for
>>>> Icap or Ecap services that should be disabled. The patch removes such
>>>> services from service groups before they are activated.
>>>>
>>>> The patch also warns the user when an adaptation group loses some but
>>>> not all of its services due to the new group cleanup code.
>>>>
>>>>
>>>> Regards,
>>>> Christos
>>>
>>> Can you thread some debugs statements through
>>> removeService(),removeRules() please, somewhere level 4-6.
>>
>> OK, done
>>
>>>
>>> What happens when a group is emptied of services and pruned after its
>>> been linked to or used by AccessRule? or any other config?
>>
>> The AccessRule removed too.
>>
>>>
>>> Amos
>>
>
> Okay. +1 from me, seems right.

committed to trunk

>
> Amos
Received on Wed Aug 03 2011 - 08:45:48 MDT

This archive was generated by hypermail 2.2.0 : Wed Aug 03 2011 - 12:00:03 MDT