Well it's been over 24 hours and not a single bite in regard to this post, except for Tom :). So what was wrong with that code? There's actually nothing wrong per say, it's completeley valid code and it would work if I were using the correct calls to the container, instead of my own invented interfaces.
However, there is a conceptual issue. I am using Dependency Injection, and thus injecting my dependencies into the classes that require it. Instead of having to deal with creating all the necessary dependencies before calling the class, I am making use of an IoC Container that helps me accomplish Inversion of Control. This means that my classes are no longer responsible for creating any dependencies themselves, and rely on them being created and passed in., i.e. inverting the control from the class to that of the caller.
The problem arises when I pass in the container as a dependency. Here I am allowing my CustomerController to use the container to create an instance of ISomeService it uses (Service Locator pattern). This contradicts the objectives I'm trying to accomplish by using an IoC container.
Is it bad? Well depends on what you're trying to do. If you want to remain true to IoC and not have a dependency on a particular container, then yes, it's bad.
[Note: This code is similar to an example application that ships with CAL (Composite Application Library - WPF). CAL doesn't actually do this, ONLY the sample application. CAL is in fact a pretty decent framework (so far) and doesn't depend on a specific container, although it ships with Unity. So don't dismiss CAL because of this sample]