Discussion on deprecated APIs for removal in future versions

[jonorossi]

The community needs to discuss what obsolete public public API's can be removed for Windsor V5, including anything that might no longer be useful or could be replaced with something from the framework.

Anything that is identified as "generally agreed" will be dealt with in a PR which should be linked here.

Below are a list of obsolescent items found and their current status.

• Logging Facility: LoggerImplementation enum and the loggingApi XML property

• XML config in general (Not a thing for v5, @Fir3pho3nixx)

• Parent/Child containers (Still in flight, @Fir3pho3nixx)

• Burden Tracking (Still in flight, @hconceicao)

• IEnvironmentInfo (Still in flight, @jonnii)

• Deprecating Resolve(Type, IDictionary) in favor of IReadOnlyDictionary<string, object> (Still in flight, @jnm2)

• Obsolescense in general (Generally agreed)

• ActAs

• Parameters

• ServiceOverrides

• Properties

• BasedOn'T

• Where

• CustomLifestyleAttribute

• NoTrackingReleasePolicy

• AllTypes && AllTypesOf

• DefaultKernel_ObsoleteAPI

• WindsorContainer_ObsoleteAPI

I do believe most of the XML configuration can be removed. I think XML removes the compiler from type safety resolution and promotes these problems to the runtime environment. So I would think any XML based config needs to hit the road and go to that XML heaven in the sky.

It also seems like we should get rid of parent/child containers.

#324
#338
#115
#66

I think what you need to do is read @hammett's original post about this:

http://hammett.castleproject.org/?p=296

@kkozmic tried to reason with this implementation but I do believe it creates more problems than what the micokernel already solves:

• http://kozmic.net/2010/06/01/castle-windsor-and-child-containers/
• http://kozmic.net/2010/06/02/castle-windsor-and-child-containers-reloaded/
• http://kozmic.net/2010/06/03/castle-windsor-and-child-containers-empire-strikes-back/

We should really be using:

• https://github.com/castleproject/Windsor/blob/master/docs/handler-selectors.md
• https://github.com/castleproject/Windsor/blob/master/docs/resolvers.md

I hope that we can treat this as an opportunity to discuss things that should not be here apart from mere obsolescence, parent/child containers appears to be a big after trawling through all the old issues tonight. This is steering users down the wrong path with the wrong expectations. A major version increment is hopefully where we get to discuss things like this and make things easier for people. It is my hope that there is more that people would like see more come out of this that makes Windsor easier to use.

[jonorossi]

parent/child containers appears to be a big after trawling through all the old issues tonight

Yes as you've discovered they are a source of many problems because the rules around them still aren't defined. Reading the comments on @kkozmic blog posts does make me realise that today child containers are really the only solution for some people's requirements. A handler selector doesn't let you register different components without having them always registered, a sub dependency resolver would be a painful way to perform this task, it means if you were doing WinForms (or any long lived app) your root container has common stuff and as you enter a specific module (doesn't even need to be a plugin) of the application its child container gets created for use and destroyed on closing, you couldn't really do that without child containers.

Having a look at Autofac they don't appear to have child containers but creating an Autofac lifetime scope does provide an inner container builder where you can register more types that don't infect the parent scope.

I think we could probably do the same and allow the scoped lifestyle to support registrations, singletons would survive in the container, scoped lifestyle components would be released on scope disposal as they are now, transient is obvious, and all other lifestyles would behave like they were resolved outside the scope. Thinking through many of the requirements in those blog comments this would handle most cases.

Windsor has been used in long lived programs (GUI and server) for a long time and will continue to be, web apps are only one use case. What we really need is for users to get involved so we can learn about people's use cases.

[reijerh]

From that list, we use BasedOn<T> and Where, e.g:
Classes.FromAssembly(assembly).BasedOn<IPlugin>().WithServiceBase()
and
Classes.FromAssemblyNamed("foo").Where(t => t.Name.EndsWith("Repository")).WithServiceAllInterfaces()

I'm a little confused by the deprecation messages on those to be honest, perhaps we've been using them wrong? Are there alternatives?

Now regarding child containers: we're using them in an application that has a plugin style architecture, where each plugin can create and attach its own child container to the main container. A plugin represents a module, and whenever a module is opened, the child container is created and the plugin registers its own components (possibly overriding some main container's defaults). When the module is closed by the user, the child container is disposed and there should be no trace left of any of the module's components.

This works quite nicely as the plugins can re-use defaults from the main container for e.g. UI stuff, but they can modify behavior at the same time.

Regarding #324: this 'bug' is only important to me because we currently have to manually Resolve() some components to accommodate the use of WPF ViewModels in old and new code, and it's not always known when these components should be Released() again. So relying on the module container to dispose stuff was very convenient. This is just the way things go with a huge codebase where 75% is legacy and you have to combine different paradigms. As an alternative I tried to use the scoped lifestyle, but it didn't seem to work correctly when I tried to create a module-lifetime scope using it, probably caused by async/await. I looked into it, and it seems the mechanism it uses (some sort of calling context thingy) doesn't work correctly for async/await scenarios. I rolled my own module-scoped-lifestyle for now.

One other thing that caused some confusion: resolving transients using Resolve() inside a singleton's constructor will stick the resolved transients to the singleton forever, meaning calling Release() for these manually resolved transients later on doesn't actually release them from memory. This can result in memory leaks that are insanely hard to figure out, there's just a couple of posts on the internet that document this, if you know what to look for.

@reijerh

The members you mention are not deprecated and look like they will live on in the FromDescriptor. The BasedOn methods here are in the BasedOnDescriptor to stop the fluent interface from being re-entrant and resetting. I think you might be OK.

@reijerh & @jonorossi

Parent/Child containers look like they need proper rules hashed out. Coming up with a language that could concisely define this would not be an easy task. We should try lead up to it by discussing it more. I have some additional thoughts around singletons. For example, if it is registered in the parent container and already resolved then it should stand to reason they would survive the disposal of the child container however if they are registered in the child container then surely it would make sense that it is not resolvable via the parent and would not survive the child containers disposal. This fundamentally alters how a singleton would behave. Furthermore disposables that are transient's and then consumed by singleton's should probably be disallowed altogether in parent containers, in child containers the singleton would be tracked and are assumed to be shorter lived so this would potentially be viable as the child container would eventually get disposed. Our rules need to factor in where the component was registered, what the intended lifestyle was and how it behaves or is tracked in a child container and then what happens to it when the container is disposed. No easy task! :)

The divergent side of my brain is thinking do we even need this? What we are really after is a way creating shorter lived containers that serve as plugins with re-usable setups. I am a massive fan of using installers. These allow you to create and share common container setups and common installers can be consumed by specialised installers for child scenarios. Simply creating a new container with distinctions between how it is used and how installers are composed together might actually be a simpler solution to the problem. This also avoids sending us down the path of trying to support mutated lifestyles. Much easier!

I still believe we should get rid of this feature, I can solve it by using composition at the installer level.

[jonorossi]

What we are really after is a way creating shorter lived containers that serve as plugins with re-usable setups.

Usage of child containers It rarely about reusing container set up but having access to parent container instances.

Usage of child containers It rarely about reusing container set up but having access to parent container instances.

Still struggling to understand why this is a "must have" feature.

Parent/Child Scenario

ParentForm <- Registered in parent container, instantiated. Click resolves through N possible ChildForm's.

ChildForm <- Registered in child container, to be instantiated but requires a reference to ParentForm.

ParentIWindsorInstaller -> Holds reference to parent container. Preferably protected static named ParentContainer.

ChildIWindsorInstaller -> Inherits ParentIWindsorInstaller and then will have access to both ParentContainer/ChildContainer.

Then add a custom SubDependencyResolver to the child that checks resolution between the parent and child containers because you already have a reference to both.

Might be missing something obvious here but this is potentially how I would do it.