Mailing-List: contact dev-help@avalon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <dev@avalon.apache.org>
From: Niclas Hedhman <niclas@hedhman.org>
Organization: Private
To: "Avalon framework users" <users@avalon.apache.org>
Subject: Re: When use ServiceManager.release(obj)?
Date: Sat, 13 Dec 2003 19:01:25 +0800
User-Agent: KMail/1.5
References: <18146989312.20031211162031@freemail.hu>
 <200312131209.26590.niclas@hedhman.org> <3FDAB1B6.50809@apache.org>
In-Reply-To: <3FDAB1B6.50809@apache.org>
Cc: dev@avalon.apache.org
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200312131901.25249.niclas@hedhman.org>


Stephen and I have discussed this further on ICQ, and the issue basically 
grows into something more sinister... ;o)

My argument is based on;
* External resources can in some instances not be held onto as long as it 
takes for the GC to come around and release them.
* Therefor, an explicit release() should in these case be required from the 
user code.
* If that release() is not called, the user code developer must get notified 
(fail early), otherwise it will go undetected until deployment.


Stephen's argument is;
* User code developers are "lazy" and never play by rules.
* Automatic reclamation is therefor desireable, as it can solve a lot of this 
behaviour.
* Code looks nicer without the release(). It is sometimes troublesome to 
manage the release() call, just as it is troublesome to manage the 
destructors in C++.
* The container should help as much as possible.
* The behaviour (automatic reclamation) is not default, and must be declared 
explicitly.


I then raised the issue that there is currently no way for the User code to 
know that a release() is required for some troublesome services, as 
Disposable is declared at the implementation, which may not be known when the 
user code is written.

My conclusion, therefor, is either the release() is enforced or it should be 
deprecated altogether.

Since I DO realize that my use-cases are somewhat exceptional, there are 
possible solutions to them.
public interface ReleaseRequirement
{
    /** Releases external resource that may be held by the service.
     *  Failure to call this method may cause fatal errors later in code
     *  execution.
    */
    void release():
}

public interface MyService extends ReleaseRequirement
{
    // whatever
}


And the implementation can create Reports on failure to do release() by 
implementing Disposable and declaring the auto reclamation policy.

This is a solution without container involvement, and I can do with that.


Bottom-line Q;
Either release() is a requirement or it shouldn't exist. Which?

Niclas


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org