@fabpot Indeed, fixed + tests added.

So, I would deprecate getContainerExtensionClass in 2.7 and remove it in 3.0 as your new extension point does more than the old one.

@fabpot IMO, the two methods have different topics and so, the one which resolves the DI extension class name (getContainerExtensionClass) should not be deprecated otherwise, I will still need to resolve the DI extension class by myself because it will become part of the instantiation.

I can obviously bring the two lines of code which resolves the DI extension class but if I can avoid it, I would follow this method.

My point is I build a generic bundle implementation on top of the Symfony one, so, the DI extension class resolution is a feature I need but having it decouplated from the DI extension instanciation would be even better for passing dependencies :)

An other way to do it would be to move the DI extension class resolution in the getContainerExtension method and then pass the resolved class as parameter to the new createContainerExtension. Then, developers can choose to use it or not. What do you think?

👍

Thank you @egeloen.

I'm now getting LogicException: Extension Symfony\Component\HttpKernel\Bundle\Bundle must implement Symfony\Component\DependencyInjection\Extension\ExtensionInterface when running tests. Might be just a merging issue since the code merged differs from the PR.

Indeed, merge issue. Fixed now.