Receiving a "Bidirectional Dependency Problem detected" exception
770 views
Skip to first unread message
Gary Brunton
May 23, 2012, 5:53:46 PM5/23/12
to fubumv...@googlegroups.com
I created a IPropertyBinder implementation and registered it like so:
Models.BindPropertiesWith<MyPropertyBinder>();
I then created a new LookupSettings type and added the scanning convention of "SettingsScanner" and set the default ISettingsProvider to AppSettingsProvider.
Now on app start up I'm receiving the exception below. If I remove the settings configuration the binding works great. If I instead remove the binding configuration the settings logic works great. I just can't seem to have both of these working at the same time.
Any thoughts?
StructureMap Exception Code: 295
Bidirectional Dependency Problem detected with RequestedType: FubuCore.Configuration.ISettingsProvider, Name: 225d8b78-58ee-4965-a2fe-e12b527ad7ae, ConcreteType: FubuCore.Configuration.AppSettingsProvider. The BuildStack is:
1.) RequestedType: FubuCore.Configuration.ISettingsProvider, Name: 225d8b78-58ee-4965-a2fe-e12b527ad7ae, ConcreteType: FubuCore.Configuration.AppSettingsProvider
2.) RequestedType: FubuCore.Binding.IObjectResolver, Name: fa83e2cc-1e6f-4fe2-a99b-84404b2d39b4, ConcreteType: FubuCore.Binding.ObjectResolver
3.) RequestedType: FubuCore.Binding.BindingRegistry, Name: f87d34cb-53c8-4500-b67e-b9469b1be648, ConcreteType: FubuCore.Binding.BindingRegistry
4.) RequestedType: System.Collections.Generic.IEnumerable`1[FubuCore.Binding.IPropertyBinder], Name: acec573d-b7b6-4112-8617-72b3a3b46826, ConcreteType: System.Collections.Generic.IEnumerable`1[FubuCore.Binding.IPropertyBinder]
5.) RequestedType: FubuCore.Binding.IPropertyBinder, Name: 749f3566-268a-4e12-aaed-58634e60e795, ConcreteType: myapp.web.Core.Lookup.MyPropertyBinder
6.) RequestedType: myapp.web.Configuration.Settings.LookupSettings, Name: b9e77571-fdf9-4548-9afa-2e2e0cc989a1, ConcreteType: mayapp.web.Configuration.Settings.LookupSettings
Jaime Jhon
May 23, 2012, 5:56:46 PM5/23/12
to fubumv...@googlegroups.com
Could you post the ctor of each one of those?
On the other hand, you don't need ctor args (dependencies) in your property binder, you have access to the IoC in the Bind method by way of the BindingContext arg, e.g.: context.Services<T>.
Regards,
Jaime.
--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/XxunhaAnY54J.
To post to this group, send email to fubumv...@googlegroups.com.
To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.
Chad Myers
May 23, 2012, 6:04:54 PM5/23/12
to fubumv...@googlegroups.com
This is almost always because you have a propertybinder (or some other class involved in model binding) that takes in one of your settings classes or something related to settings.
Settings depends on model binding, so if your model binding requires settings, you have a circular reference.
-Chad
On Wed, May 23, 2012 at 4:53 PM, Gary Brunton <gbru...@gmail.com> wrote:
--
Jeremy D. Miller
May 23, 2012, 6:14:51 PM5/23/12
to fubumv...@googlegroups.com
Hadn't hit exactly this one before, but try having your
MyPropertyBinder class use IBindingContext.Service<LookupSettings>() instead of injecting it in. By making the resolution of LookupSettings lazy, you should be able to get around the cyclical dependency problem.
Model binding (and html conventions) are both a touch odd as far as IoC integration because the IModelBinder/IPropertyBinder objects are only created once and then reused for all subsequent requests. Most dependencies, and anything that is sensitive to the current request, needs to be resolved by calling Service<T>() on IBindingContext/IPropertyContext to make sure you're getting the dependency that's scoped to the current request.
Jeremy D. MillerThe Shade Tree Developer
jeremy...@yahoo.com
From: Chad Myers <chad....@gmail.com>
To: fubumv...@googlegroups.com
Sent: Wed, May 23, 2012 5:04:58 PM
Subject: Re: [fubumvc] Receiving a "Bidirectional Dependency Problem detected" exception
Jaime Jhon
May 23, 2012, 6:32:10 PM5/23/12
to fubumv...@googlegroups.com
Jeremy, on a related topic, how do you address the resolving of services from IFieldValidationRule implementors when using the FubuValidation bits?
What I did was to create a custom IValidationSource that takes in customs IValidationRule (using a marker interface) which respect the nested container so the services could be disposed at the end of the request.
I think adding something like the BindingContext.Services method to ValidationContext would solve this problem.
I would be able to keep using the built-in stuffs without branching my code into custom infrastructure.
On the other hand, am I doing it wrong? Is there some built-in infrastructure that solves this issue already ?
Regards,
Jaime.
Gary Brunton
May 23, 2012, 7:20:24 PM5/23/12
to fubumv...@googlegroups.com
Thanks guys. The binder was injecting the settings type.
Injecting the IBindingContext type and using the Service method solves my problem.
Thanks!
Gary
-Chad
To unsubscribe from this group, send email to fubumvc-devel+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fubumvc-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups "FubuMVC Development Group" group.
To post to this group, send email to fubumv...@googlegroups.com.
To unsubscribe from this group, send email to fubumvc-devel+unsubscribe@googlegroups.com.
Brandon Behrens
Jun 27, 2012, 12:02:36 PM6/27/12
to fubumv...@googlegroups.com
We've run into this at Dovetail as well. For us, if we initialize singletons in the container before we activate all the activators we don't get the bidirectional dependency issue. There's a bit of history on this --
Ryan made a hack back in November in the GetAllActivators method of StructureMapContainerFacility.
That's not intuitive and a little difficult to test but it worked. (at least for us)
A couple of weeks later, it looks like Ryan's change was more or less reverted with this commit:
When looking at this initially, we thought it might just be a merge conflict that was resolved with "use mine" instead of Ryan's change causing a problem.
Then we saw this commit:
This commit looks a lot more intentional to me than the previous one.
I think we need to initialize singletons in the container before we go and pull all of the activators out of the container. That's what Ryan's initial change effectively did. As mentioned above, it's not very intuitive and a little difficult to test.
The GetAllActivators method is only called in one place, the Bootstrap method of FubuApplication.
What would everyone think of adding a method to IContainerFacility called InitializeSingletons and we called that method right before we called GetAllActivators?
factory = containerFacility.BuildFactory();
containerFacility.InitializeSingletons();
return containerFacility.GetAllActivators();
--Brandon
To view this discussion on the web visit https://groups.google.com/d/msg/fubumvc-devel/-/P2d1OgTRlD4J.
To unsubscribe from this group, send email to fubumvc-deve...@googlegroups.com.
Jeremy D. Miller
Jun 27, 2012, 2:00:11 PM6/27/12
to fubumv...@googlegroups.com
I'm not buying that Brandon. Why would it matter in this case? Spinning up the singletons as an activator was done because of SM's nested container bugs, but the activators don't run from a nested container.
Are *you* guys using a nested container inside one of your Activators? Like say the old localization stuff? Can you add more context?
I really don't want this changed in fubu because it's been so problematic in the past. We tried to move the singleton activator up first before and *that* caused trouble.
You guys already use a custom IContainerFacility I believe. You might try addressing that there.
From: Brandon Behrens <brandon...@gmail.com>
To: fubumv...@googlegroups.com
Sent: Wed, June 27, 2012 11:03:01 AM
Ryan Rauh
Jun 27, 2012, 3:16:40 PM6/27/12
to fubumv...@googlegroups.com
@Jeremy
We tried to move the singleton activator up first before and *that* caused trouble.
What problems did it cause?
The problem is here
foreach (var activator in _container.GetAllInstances<IActivator>())
All of the IActivator's are resolved from the container before the singletons are
initialized. This means that if you try and inject a singleton in an IActivator, you're gonna have a bad time.
If we take a ride on the way back when machine, singleton spin up used to be the last thing executed before GetAllActivators was called.
Why don't we move this code back into the BuildFactory method like it used to be?
-Ryan
Jeremy D. Miller
Jun 27, 2012, 3:23:30 PM6/27/12
to fubumv...@googlegroups.com
I don't remember, TBH.
What exactly are you hitting? Can you be more specific?
From: Ryan Rauh <rauh...@gmail.com>
To: fubumv...@googlegroups.com
Sent: Wed, June 27, 2012 2:16:43 PM
Chad Myers
Jun 27, 2012, 3:28:17 PM6/27/12
to fubumv...@googlegroups.com
We have several activators. Two of them are blowing up with the bi-di problem.
One takes a Settings object in the c'tor, one takes an ITransactionProcessor (which ultimately blows up on our DatabaseSettings object).
What should we be doing instead?
-Chad
On Wed, Jun 27, 2012 at 1:00 PM, Jeremy D. Miller <jeremy...@yahoo.com> wrote:
Jeremy D. Miller
Jun 27, 2012, 3:32:31 PM6/27/12
to fubumv...@googlegroups.com
Ok, so it's a singleton in a nested container that blows everything up then, right? (that's what TransactionProcessor does).
You can just force the singleton spin up business to happen as your first Activator (all happens in the order you register them). I'm frankly scared to make any kind of global change, and you guys are a lot more vulnerable than everyone else because of the way your use NH/SessionBoundary/nested container.
Aren't you using a custom IContainerFacility from fast pack anyway? If you are, you can force it to happen there. We moved the singleton activator to the back for a reason, and I'm inclined to believe that it was an issue with Blue.
The permanent fix is to finally
do SM3 some day -- which'll solve you're issue in about 6 months or so at my current rate
Sent: Wed, June 27, 2012 2:28:19 PM
Chad Myers
Jun 27, 2012, 5:06:32 PM6/27/12
to fubumv...@googlegroups.com
Looks like the problem was that we used to have to register StandardModelBinder in the container.
Latest fubu doesn't require us to register that any more. Once I removed the registration of StandardModelBinder, the bi-di problem went away.
-Chad
Jeremy D. Miller
Jun 27, 2012, 5:07:13 PM6/27/12
to fubumv...@googlegroups.com
Sweet.
Sent: Wed, June 27, 2012 4:06:36 PM
Reply all
Reply to author
Forward
0 new messages