[bug] IHandler.OnHandlerStateChanged event is never raised

[Konstantin]

Here is test demonstrating the issue

[Test]
public void Test()
{
var c = new WindsorContainer();
var myFacilty = new MyFacilty();
c.AddFacility("my", myFacilty);
c.Register(Component.For<A>());
Assert.AreEqual(HandlerState.WaitingDependency,
myFacilty.Handlers["Tests.A"].CurrentState);
c.Register(Component.For<B>().Instance(new B()));
Assert.AreEqual(HandlerState.Valid,
myFacilty.Handlers["Tests.A"].CurrentState);
var a = c.Resolve<A>();
Assert.IsTrue(myFacilty.OnHandlerStateChangedWasCalled,
"OnHandlerStateChanged was not raised");
}

//Classes used in test

namespace Tests
{

public class MyFacilty : AbstractFacility
{
public MyFacilty()
{
Handlers = new Dictionary<string, IHandler>();
}

protected override void Init()
{
Kernel.ComponentRegistered += KernelOnComponentRegistered;
}

private void KernelOnComponentRegistered(string key, IHandler
handler)
{
Handlers.Add(key, handler);
if (handler.CurrentState ==
HandlerState.WaitingDependency)
{
handler.OnHandlerStateChanged +=
onHandlerStateChanged;
}
}

private void onHandlerStateChanged(object source, EventArgs
args)
{
Console.WriteLine("onHandlerStateChanged");
}

public bool OnHandlerStateChangedWasCalled { get; set; }

public Dictionary<string, IHandler> Handlers { get; set; }
}

public struct B
{
}

public class A
{
public A(B b)
{
}
}
}

[Konstantin]

the code of onHandlerStateChanged method should be the following

private void onHandlerStateChanged(object source, EventArgs args)
{

OnHandlerStateChangedWasCalled = true;

[Michael Davis]

I suspect that this may be the same problem I posted about on March 4 ("Strange behavior with StartableFacility"), IOC-ISSUE-195.  If everything works as expected if you use c.AddComponent() to register your components instead of the c.Register() fluent interface, then it's definitely the same problem (and that can be a workaround you can use until it's fixed).

I suggested a potential fix for the issue and offered to submit a patch, but I never heard back from anyone about what the preferred method for doing that would be since the code was moved to github.

Michael Davis

--
You received this message because you are subscribed to the Google Groups "Castle Project Users" group.
To post to this group, send email to castle-pro...@googlegroups.com.
To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.

[Konstantin]

It does not depend on method used to register, but it definitely
affects StartableFacility - if A in from my sample implements
IStartable, it would be started in scope of c.Resolve<A>() while it
should be started after B is registered.

On Mar 29, 4:29 pm, Michael Davis <nerei...@gmail.com> wrote:
> I suspect that this may be the same problem I posted about on March 4
> ("Strange behavior with StartableFacility"), IOC-ISSUE-195.  If everything
> works as expected if you use c.AddComponent() to register your components
> instead of the c.Register() fluent interface, then it's definitely the same
> problem (and that can be a workaround you can use until it's fixed).
>
> I suggested a potential fix for the issue and offered to submit a patch, but
> I never heard back from anyone about what the preferred method for doing
> that would be since the code was moved to github.
>
> Michael Davis
>

> > castle-project-u...@googlegroups.com<castle-project-users%2Bun subs...@googlegroups.com>

[Krzysztof Koźmic (2)]

Michael,
what is the issue with code from Github? Just fork it, implement your
patch and send pull request.

Konstantin,
I will take a look at it this week. Thanks for the test case.

[Michael Davis]

I was just trying to find out if that was now the preferred method of submitting patches instead of attaching them to the case in Donjon.  Thank you for clarifying that.

2010/3/29 Krzysztof Koźmic (2) <krzy...@kozmic.pl>

To unsubscribe from this group, send email to castle-project-u...@googlegroups.com.

[Krzysztof Koźmic (2)]

No problem,

We're still working on updating the website for Git usage:
http://groups.google.com/group/castle-project-devel/browse_thread/thread/b952d0d87bef02ba#

If there's anything you feel would be beneficial to add or clarify,
speak up ;)

Krzysztof

On 29 Mar, 15:55, Michael Davis <nerei...@gmail.com> wrote:
> I was just trying to find out if that was now the preferred method of
> submitting patches instead of attaching them to the case in Donjon.  Thank
> you for clarifying that.
>

> 2010/3/29 Krzysztof Koźmic (2) <krzysz...@kozmic.pl>

> > > > > castle-project-u...@googlegroups.com<castle-project-users%2Bunsu...@googlegroups.com><castle-project-users%2Bun

> > subs...@googlegroups.com>
> > > > > .
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/castle-project-users?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Castle Project Users" group.
> > To post to this group, send email to castle-pro...@googlegroups.com
> > .
> > To unsubscribe from this group, send email to

> > castle-project-u...@googlegroups.com<castle-project-users%2Bunsu...@googlegroups.com>

[Tim S]

Thanks Michael! I actually just ran into this exact same problem. I
was totally baffled as to why my IStartable stopped starting up. I
thought it was something I did until I realized the problem started
happening when I upgraded to the latest Windsor distro. Like you
said, I changed my component from fluent registration to an explicit
AddComponent and, sure enough, it works like a charm!

tim

On Mar 29, 7:29 am, Michael Davis <nerei...@gmail.com> wrote:
> I suspect that this may be the same problem I posted about on March 4
> ("Strange behavior with StartableFacility"), IOC-ISSUE-195.  If everything
> works as expected if you use c.AddComponent() to register your components
> instead of the c.Register() fluent interface, then it's definitely the same
> problem (and that can be a workaround you can use until it's fixed).
>
> I suggested a potential fix for the issue and offered to submit a patch, but
> I never heard back from anyone about what the preferred method for doing
> that would be since the code was moved to github.
>
> Michael Davis
>

> > castle-project-u...@googlegroups.com<castle-project-users%2Bun subs...@googlegroups.com>