Middleware Callable Resolver Support Bug

[kwhat]

In the Slim 4 feedback I had some criticism for the slim 4 middleware process. As promised, I have some more details about the issues I was having. The support added back in #2780 was a good idea, however, it appears to have some flawed logic related to middleware construction if added as a string that is defined in the container. Ex: $app->add(ExceptionHandler::class);

What I expect: The class should be resolved in the container and use the $defaultMethod specified to CallableResolver::resolveByPredicate() by the AdvancedCallableResolverInterface::resolveMiddleware() method.

What is actually happening: The middleware is resolved as a string, constructed with the container and assumed to use the '__invoke' method.

The solution: The source of the issue appears to be a general over engineering of the CallableResolver. The resolveByPredicate() method is unneeded, and I generally wonder if the AdvancedCallableResolverInterface is needed at all. I have included a proposed fix in PR form to remove the resolveByPredicate() method and refactor the resolveSlimNotation() method to be a little more ergonomic.

After reviewing the new Slim 4 code base, this feels like a common trend when compared to Slim 2/3. Things are not particularly gratuitous, there were just a lot of features added, and the simplicity got lost in the implementation details.

[kwhat]

There is still one failing test, but I didn't see this one until I pulled the most recent 4.x and appears to be unrelated to this change. I did look at the MiddlewareDispatcher in terms of callable resolution... woof. For all the effort that went into decoupling stuff for 4.x, I wonder why this class is also a CallableResolver. I am also wondering if the fixes I put in place will actually fix the issue I am experiencing.

[l0gicgate]

I don't actually understand the issue you're experiencing.

Can you show your ExceptionHandler class? Does it implement MiddlewareInterface?

[kwhat]

I finally tracked it back to a freaking container issue, ie the class exists but its not in the container (when I thought it was) so it was getting constructed with ContainerInterface which is the intended behavior. I am not super stoked that this took 2 days to sort though, the old and new code are functioning identical, do with this issue/pr whatever you want.