Niclas Hedhman wrote:
Stephen and I have discussed this further on ICQ, and the issue basically grows into something more sinister... ;o)
I wish my ascii art was good enough to draw a little monster with a wicked grin!
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 }
How is this different from dispose? As far as I can see what you are really saying is that you want a contract that forces commissioning, action and decommissioning within a particular controlled scope.
E.g.
MyService service = (MyService) manager.lookup( "my-service" ); service.executeTransactions( m_actions );
The component MyComponent implemeting MyService can then aquire the actual service that does the work, apply a series of actions, then release the service before returning from the call. This way your in control of the aquisition/release cycle. Alternatively you could declare the entire thign as a lifecycle extension and do something like:
public void assign( ActionHandler handler )
{
handler.handle( m_actions );
}Does your scenario does let you isolate the aquisition/release cycle to this level of granularity?
Stephen.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED]
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/ | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
