Issue on tracker http://issues.castleproject.org/issue/IOC-253
On 30 ноя, 04:57, Krzysztof Koźmic <[email protected]> wrote: > Konstantin > > That's odd. > > While the console app you provided exposes faulty behavior, when I > copied the code, verbatim, to a test, the test passes, in other words > the behavior is correct. > > I don't know what to make of that. > > Can anyone try this out? > > Krzysztof > > On 29/11/2010 11:02 PM, Konstantin wrote: > > > > > > > > > Just tested with latest castle , the same > > > ctor: Dependency > > Expected values: > > Dependency is disposed: true > > container.Kernel.GraphNodes.Length: 0 > > > Actual values: > > Dependency is disposed: False > > container.Kernel.GraphNodes.Length: 1 > > > Ppress enter... > > > On 29 ноя, 14:26, Konstantin<[email protected]> wrote: > >> It constantly reproduces on my box and all boxes i've tried... > > >> here is vs2008 solution with the same code and exact ver of > >> castlehttp://dl.dropbox.com/u/1055156/CastleIssueDemo.zip > >> please try it... > > >> On 29 ноя, 12:12, Krzysztof Koźmic<[email protected]> wrote: > > >>> Can you create a failing test to reproduce that? > >>> As mentioned earlier, I don't see the faulty behavior you're describing > >>> in the test you provided earlier > >>> K > >>> On 29/11/2010 6:57 PM, Konstantin wrote: > >>>> I have not migrated on latest ver yet. > >>>> Some environment details: > >>>> Castle.Core, Version=1.2.0.0, Culture=neutral, > >>>> PublicKeyToken=407dd0808d44fbdc > >>>> WinXP 32 > >>>> .NET 3.5sp1 > >>>> I've noticed the issue after added the component that starts > >>>> foreground thread and stops it in dispose, as result application > >>>> process hangs afer exit. > >>>> As work around i've got rid of generic class registration and > >>>> implemented 4 ancectors with no changes. Using sample form the test > >>>> instead of registering Depender<T> , i register > >>>> public class IntDepender: Depender<int> { } > >>>> public class StringDepender: Depender<string> { } > >>>> etc. > >>>> I can agree that recolving implementation of generic class with > >>>> factory is not a straight forward usage of Factory facility: > >>>> public interface IDependerFactory > >>>> { > >>>> Depender<T> CreateDepender<T>(); > >>>> } > >>>> but if it manages to create component it should be able to release > >>>> it... > >>>> Looks like when being disposed castle releases the instance of > >>>> component registered as generic type and resolved with factory, it > >>>> fails and does not even try to release anything else. To be precise it > >>>> does not call any decomission concern. > >>>> On 27 ноя, 01:35, Krzysztof Koźmic<[email protected]> wrote: > >>>>> I'm confused, > >>>>> you said your problem is component is not being disposed, however your > >>>>> tests shows everrything works the way it's supposed to. > >>>>> Krzysztof > >>>>> On 27/11/2010 1:42 AM, Konstantin wrote: > >>>>>> Sorry undefined lyfestyleType is set at registration time and never > >>>>>> changes (guess castle uses default typa which is singleton for such > >>>>>> components) > >>>>>> Here is the issue reproducing test > >>>>>> namespace Castle.Tests > >>>>>> { > >>>>>> [TestFixture] > >>>>>> public class CastleTests{ > >>>>>> public class Dependency : IDisposable > >>>>>> { > >>>>>> public Dependency() > >>>>>> { > >>>>>> Console.WriteLine("ctor: " + GetType().Name); > >>>>>> } > >>>>>> public void Dispose() > >>>>>> { > >>>>>> IsDisposed = true; > >>>>>> Console.WriteLine("dispose: " + GetType().Name); > >>>>>> } > >>>>>> public bool IsDisposed { get; private set; } > >>>>>> } > >>>>>> public class Depender<T> > >>>>>> { > >>>>>> public T DependencyInstance { get; set; } > >>>>>> public Depender(T d) > >>>>>> { > >>>>>> DependencyInstance = d; > >>>>>> } > >>>>>> } > >>>>>> public interface IDependerFactory > >>>>>> { > >>>>>> Depender<T> CreateDepender<T>(); > >>>>>> } > >>>>>> [Test] > >>>>>> public void Test() > >>>>>> { > >>>>>> WindsorContainer container = new WindsorContainer(); > >>>>>> container.AddFacility<TypedFactoryFacility>(); > >>>>>> var assembly = Assembly.GetExecutingAssembly(); > >>>>>> container.Register( > >>>>>> //Registering generic type > >>>>>> AllTypes.FromAssembly(assembly).Where(o => > >>>>>> o.Name.Contains("Depender")). > >>>>>> Configure(c => c.LifeStyle.Transient), > >>>>>> Component.For<Dependency>().LifeStyle.Singleton, > >>>>>> Component.For<IDependerFactory>().AsFactory() > >>>>>> ); > >>>>>> var factory = container.Resolve<IDependerFactory>(); > >>>>>> Depender<Dependency> depender = > >>>>>> factory.CreateDepender<Dependency>(); > >>>>>> container.Dispose(); > >>>>>> Assert.IsTrue(depender.DependencyInstance.IsDisposed); > >>>>>> Assert.AreEqual(0, container.Kernel.GraphNodes.Length); > >>>>>> } > >>>>>> } > >>>>>> } > >>>>>> On 26 ноя, 15:09, Konstantin<[email protected]> wrote: > >>>>>>> Unfortunately i failed to create a test reproducing the issue. > >>>>>>> Another strage thing: LifestyleType of not cleaned up components in > >>>>>>> GraphNodes is changed from singleton to Undefined after container > >>>>>>> dispose. > >>>>>>> On 26 ноя, 01:31, Mauricio Scheffer<[email protected]> > >>>>>>> wrote: > >>>>>>>> Can you submit a failing test reproducing the issue? > >>>>>>>> On Nov 25, 12:51 pm, Konstantin<[email protected]> > >>>>>>>> wrote: > >>>>>>>>> I've noticed that not all components implementing IDisposbale and > >>>>>>>>> having singleton lifycycle are disposed on container.Dispose() call. > >>>>>>>>> the _container.Kernel.GraphNodes property is also not empty after > >>>>>>>>> it. > >>>>>>>>> Some componentModels that are left in GraphNodes (looks like none of > >>>>>>>>> them is disposed) have Dependers that are not present on root > >>>>>>>>> level > >>>>>>>>> of GraphNodes. > >>>>>>>>> I"ve spent plenty of time investigating the problem and has no idea > >>>>>>>>> of > >>>>>>>>> what else can i check. Please help! -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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-users?hl=en.
