Skip to content

2009 01 21 we have a facility

Fabian Schmied edited this page Jan 21, 2009 · 1 revision

Published on January 21st, 2009 at 13:26

We have a Facility!"

Lee Henson has implemented a Castle Windsor facility for re-motion's ObjectFactory class. With it, it is possible to have the container resolve components that are mixed by re-motion. Lee's original intention was to have a mixed MonoRail controller, which should now be perfectly possible.

Quoting from Lee's announcement on the Castle developers list:

Sample usage is the specs in the project, but sample (notepad) code
would be:

<wherever you are creating your container>

var remotionFacility = new RemotionFacility  
(assemblyContainingMyMixins);  
container.AddFacility("remotion.facility", remotionFacility);

<register components>

...

<later on>

var component = container.Resolve<ComponentWithAvailableMixins>();  
((MyMixin) component).SomeMethod();

Here's the link: http://github.com/leemhenson/re-motion/tree/c98d2439d8e78a31cc866ecc47a772b5a74ec34f/RemotionFacility.

UPDATE: We now have a Remotion-Contrib repository, find the facility here: https://github.com/re-motion/Contrib-Mixins-WindsorFacility.

Thanks a lot for making this work, man!

How it works

Lee and I mailed around a little to see how to do this, and while Lee did all the implementation work, it's quite easy to explain what it does. The RemotionFacility is a simple Windsor facility that hooks up a special RemotionActivator class for components that have mixins configured. That activator uses re-motion's ObjectFactory to instantiate the component (after all of its constructor dependencies have been resolved) - and voilà, there is your mixed component.

What can go wrong

The RemotionFacility has constructors allowing you to use an auto-generated configuration, specify the assemblies to scan, or specify a dedicated MixinConfiguration instance. However, even when you specify the configuration by hand, re-motion will still want to do an assembly scan of those assemblies in your bin folder at runtime. This is the default policy and cannot be easily disabled in the current re-motion trunk revisions, so you might get exceptions when you have assemblies with dangling references in your project's bin folder. Such an exception is nearly always a deployment bug, so you should really clean up your folder, but if you can't (or don't want to), the only way around it currently is to set a custom ITypeDiscoveryService via ContextAwareTypeDiscoveryUtility.SetDefaultInstance(...) before doing anything mixin-related. (Or, better, before doing anything re-motion-related, since a lot in re-motion is mixin-related.)

(This will be fixed to make it easier in the future.)

- Fabian

EDIT (2009-02-10): Updated link to facility.
EDIT (2009-03-23, 2011-04-22): Updated link to facility. Again.