Open scottlittlewood opened 10 years ago
Hi @scottlittlewood
It seems we hit the same problem, with the newer versions of windsor and how session scope works
Could you try adding this code and seeing if it helps you
_container.Register(
Component.For<HttpContext>().UsingFactoryMethod(() => (HttpContext)null),
Component.For<AspNetRequest>().UsingFactoryMethod(() => (AspNetRequest)null),
Component.For<AspNetResponse>().UsingFactoryMethod(() => (AspNetResponse)null)
);
If it works for you, I'll have to see how we can fix the issue or document the work around. Toby
This stuff is nasty. we need to make this much much much better me thinks.
Hi @holytshirt
I tried the code you provided but that looks like AspNetHost, I'm specifically looking at HttpListenerHost.
After some trial and error and looking at the status "Potential Misconfigured Components" in the container.
The following code seems to resolve the Http Hosting / Windsor Container issue for now. I tested adding the HttpResponse but that doesn;t seem to be needed to make the above test pass.
Thanks for the suggestion. Not sure what the correct solution would be for this integration to be less painful.
_container.Register(
Component.For<System.Net.HttpListenerContext>().UsingFactoryMethod(() => (System.Net.HttpListenerContext)null),
Component.For<OpenRasta.Hosting.HttpListener.HttpListenerCommunicationContext>().UsingFactoryMethod(() => (OpenRasta.Hosting.HttpListener.HttpListenerCommunicationContext)null),
Component.For<System.Net.HttpListenerRequest>().UsingFactoryMethod(() => (System.Net.HttpListenerRequest)null),
);
We need a plan to can the iOC integration out of OR. I'll give it a go this weekend if time allows.
Sebastian Lambla - http://serialseb.com
On 31 Oct 2014, at 11:16, Scott Littlewood notifications@github.com<mailto:notifications@github.com> wrote:
Hi @holytshirthttps://github.com/holytshirt
I tried the code you provided but that looks like AspNetHost, I'm specifically looking at HttpListenerHost.
After some trial and error and looking at the status "Potential Misconfigured Components" in the container.
The following code seems to resolve the Http Hosting / Windsor Container issue for now. I tested adding the HttpResponse but that doesn;t seem to be needed to make the above test pass.
Thanks for the suggestion. Not sure what the correct solution would be for this integration to be less painful.
_container.Register(
Component.For
Reply to this email directly or view it on GitHubhttps://github.com/openrasta/openrasta-castle-windsor/issues/6#issuecomment-61246908.
@scottlittlewood I have had a stab at doing the integration with the new way of doing custom scopes in castle windsor. Just need to find the time to finish it, as I ran into some issues.
I'll document mine and your workarounds in the readme for the moment.
Toby
I added @scottlittlewood 's test and one of my own, which currently fails. See this pull request
https://github.com/openrasta/openrasta-castle-windsor/pull/7
I've been attempting to host an OpenRasta based project using a HttpListenerHost while also using Castle Windsor as the container.
Unfortunately I've come across an issue where Windsor is not able to resolve the IOperationFilters registered with the container as the Handler.Current State in AvailableHandlers() are seen as WaitingDependency
This is causing a (405) MethodNotAllowed response being returned to any and all requests coming in to the system.
Debugging the Windsor Container seems to indicate that it is unable to resolve IRequest because it can't resolve ICommunicationContext which in turn can't resolve System.Net.HttpListenerContext (nativeContext). I'm not too familiar with the registration of components in Windsor / OpenRasta and wondered if anyone with more insight could help.
This only happens when attempting to use Castle Windsor as the InternalDependencyResolver in OpenRasta works fine.
I've confirmed this with the test below.
Here is the debug log:
The error originates from the following call OpenRasta.Pipeline.Contributors.AbstractOperationProcessing.GetMethods() This calls in to the WindosrDependencyResolver.ResolveAllCore where T : IOperationFilter
The (3) default handlers are returned from the Windsor Kernel but as stated previously the Windsor IHandler instances are WaitingDependency
The container itself seems to indicate there are a few potential misconfigured components (13) I can see that the ICommunicationContext, IRequest and IResponse instances are registered PerRequest in HostManager.SetupCommunicationContext(context).
While debugging in WindsorDependencyResolver.AvailableHandlers() and executing the following in the immediate window the following error is shown