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.
