Sorry, if I'm not being clear... I don't know what specifics you'd like about my scenario.We have a web app with MVP setup where presenter has a reference to view & view has reference to presenter. These presenters may have "child" ones in UI sense. Child presenters are not constructor- nor property- injected. We do calls like GetXXXChildPresenter which eventually end up resolving child presenters through Windsor with correct view supplied through ctor params.
AFAIR, transient & disposable types are not combined in our dependency chains. But to be foolproof, I have to call release on all root components (presenters) per web request. To do so, I need to track all presenters myselves. This is not a problem now, when I know it. In this particular case I've "solved" it in a matter of minutes. The problem is I was totally unaware that container expects me to do so. It seems there more people like me. Which misuse the container. It would be nice if possible for container to be more explicit about the thing, i.e. throw meaningfull exceptions. On Thu, Mar 5, 2009 at 12:08 AM, hammett <[email protected]> wrote: > > I read four of your past emails and couldnt find the scenario. Again: > why transients is combined with disposable types? Also, who is the > bootstrapper (the first that has a reference to the container)? > > > On Wed, Mar 4, 2009 at 12:50 PM, Victor Kornov <[email protected]> wrote: > > I've described my scenario a couple e-mail back. As I said, to have > things > > "right" & not be surprised by sudden memory leaks if some rouge > disposable > > components manages it's way into a dependency chain, I have to manually > > release all my root components (presenters in composite MVP with > webforms). > > Wouldn't it be nice to not support disposable components by default, then > > when such thing is encountered, throw descriptive exception, like "set > > release policy to all tracking & do not forget to release all your root > > components"? > > > > On Wed, Mar 4, 2009 at 11:45 PM, hammett <[email protected]> wrote: > >> > >> What's your scenario? Why transient is combined with IDisposable? > >> > >> > >> On Wed, Mar 4, 2009 at 12:42 PM, Victor Kornov <[email protected]> > wrote: > >> > People (like me) seem to have problems in simple, straightforward > >> > scenarions. It's surprising to have container manifest such behaviour, > >> > i.e. > >> > track all components which leeds to memory leaks. > >> > If we look at disposable components in container as "advanced" stuff, > >> > requiring all tracking release policy & mandatory "manual" release of > >> > each > >> > component makes sense (i.e. instead of dispose you call > >> > container.Release) > >> > > >> > On Wed, Mar 4, 2009 at 11:30 PM, hammett <[email protected]> wrote: > >> >> > >> >> I fail to see how to implications and side effects of not disposing > an > >> >> object graph can be considered success. > >> >> > >> >> > >> >> On Wed, Mar 4, 2009 at 12:21 PM, Victor Kornov <[email protected]> > >> >> wrote: > >> >> > I believe Ayende's point is to make users to fall into the pit of > >> >> > success. > >> >> > > >> >> > On Wed, Mar 4, 2009 at 11:19 PM, hammett <[email protected]> > wrote: > >> >> >> > >> >> >> I'm not sure misuse is a good argument to change this behavior. > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en -~----------~----~----~----~------~----~------~--~---
