Changes for zend-servicemanager v3

[kynx]

Re #15: against develop this time!

According to https://github.com/zendframework/maintainers/wiki/ZF3-ServiceManager-component-refactors,-phase-2 I'd be throwing an InvalidServiceException from validate() but that breaks tests. Is this the intention for v2?

[svycka]

@kynx this is because of bug in hydrator module. validatePlugin() should throw Zend\ServiceManager\Exception\RuntimeException as said in https://github.com/zendframework/zend-servicemanager/blob/release-2.7/src/AbstractPluginManager.php#L126 but instead throws Zend\Hydrator\Exception\RuntimeException.

If not then this will be BC break.

[kynx]

Thanks @svychka. I've got some changes ready to push that ensure the tests pass in both v2 and v3, but am waiting for zendframework/zend-servicemanager#87 so I can use my shiny new CommonPluginManagerTrait for testing :)

[svycka]

I don't think it is good idea to throw different exceptions with differrent SM versions. But lets see what ZF team will say

[kynx]

@weierophinney Hopefully this one's good to go.

[weierophinney]

There's a subtle issue here: with current v2, the container passed to the factory will be the HydratorPluginManager instance, while with v3, it will be the parent container. In the latter case, DelegatingHydrator usage breaks, as it will be attempting to fetch hydrators from the container, but the container will be the application-level container!

Which poses a quandary: how do we get access to the HydratorPluginManager? My suggestion is:

• Check to see if $container is a HydratorPluginManager instance; if so, done.
• Check to see if $container->has(HydratorPluginManager::class); if so, pull that, and done.
• Check to see if $container->has('HydratorManager') (the name used by zend-mvc); if so, pull that, and done.
• Finally, if all the above fail, create a new instance of HydratorPluginManager and use that.

I'll make that change on merge.