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.
