Re: Re: [Webmacro-devel] More pruning

[<web...@st...>]

On Tue, 15 Jul 2003, Brian Goetz wrote:

|
| >So what's the best design for doing this sort of thing?  The listener
| >approach is appealing because then only tools that need this functionality
| >would register themselves, so very few listeners would actually be
| >managed.  Plus this is analogous to the model used by HttpSessions and
| >ServletContexts.
| >
| >Is the overhead really that great?
|
| The performance overhead is negligible.
|
| However, the issue you raise below, requiring the WM user to explicitly
| free the Context is not really negligible, as the lifecycle methods at all
| levels bubble up to the the level of the user's consciousness.
|
| So what if we add these:
|
| class Context {
|    ...
|    public void registerDestructor(Destructor dtor) { destructors.add(dtor); }
|    public void destroy() { /* iterate through destructors */ }
| }
|
| which don't affect anyone who's not going to use them.  To be polite, we
| can teach WMServlet about it.  And tools that hold things like connections
| should still probably use finalizers, just in case none of the explicit
| mechanisms do their job.  That seems OK to me.
|
| >I suppose an alternative is to put the onus on the Servlet developer to
| >handle the cleanup if they want to use these kinds of tools.  WMServlet
| >makes a call to a stub method called destroyContext() after each
| >request.  A developer could use a method like this to go into the context
| >and find resources that need to be released.  This is more work for the
| >developer, but since this isn't used much, it might make sense to do it
| >this way.

Ehh.. I don't get this. A developer -may- adhere to the contract, but he
is equally free to just -not- do the cleanup?

I feel that -either- one require the developer to do the cleanup (which I
don't like - I already -hate- DB Connection-getting and -closing), or
there aren't any such "suggestions" at all.

I develop a framework. If this "suggested destroy - contract" is in there,
I will have to always destroy the Contexts, as I don't know what others
will put into the configuration - even though I (as the framework
developer) don't use this at all.

Endre.