Removed lowercase console alias from default service config

[mattroylloyd]

An alias was added in the ServiceListenerFactory to add the lowercase aliases for console and config. This caused a Zend\ServiceManager\Exception\InvalidServiceNameException exception to be throw within the Zend\ServiceManager package when using the default configuration prior to v3.x.

Within Zend\ServiceManager v3.x, the service manager has become case sensitive, meaning that this issue would be resolved.

However, as v2.x normalises the aliases, it classifies console and Console as a duplicate key, and throws the aforementioned exception.

This is a fix is only required as of v2.x of zend-mvc

Added data provider tests for expected aliases for default config

[weierophinney]

I'm going at this from the opposite direction, because we want to standardize on console and config for these service names with v3. As such, I've created a test case to try and reproduce the issue, and succeeded in doing so. I'll try and get an alternate patch in place shortly.

[weierophinney]

Interestingly, under zend-servicemanager v2, I'm getting a ServiceNotFoundException, not an InvalidServiceNameException.

[weierophinney]

Okay, discovered a few things:

• I needed to call $listener->addServiceManager() before triggering it's onLoadModulesPost() event.
• I needed to provide a mock ModuleManager so that the ConfigFactory would work.

Interestingly, once I did that, I no longer received any exceptions at all.

So, I tried to reproduce this in a skeleton application. I did the following:

• composer create-project -s dev zendframework/skeleton-application
• I then descended into the new application, and edited the zendframework item constraint to read ^2.5, and ran a composer update. This gave me zend-servicemanager v2.7 and zend-mvc v2.7 versions.

From there, I tried each of the following:

• I went to the home page. This worked fine.
• I created a console route, mapping to a new action in the Application's IndexController, and invoked the new end point. This also worked fin.

As such, I'm unable to reproduce the issue. Because we want to standardize on the lowercase versions of those two services for v3, I can't accept the PR as-is, as it breaks existing assumptions and integrations. If you can provide a way to reproduce the issue reliably, please create a new pull request with the test case.

Thanks!

[mattroylloyd]

Sounds good, thanks

[jg-development]

Hi,

we are currently having this issue, too. An application is using the servicemanager 2.7.6 and the mvc 2.7. This combination should normally work, but with mvc 2.7.x the two new aliases results in the InvalidServiceNameException.
The only solution for us is now a force to a version lower 2.7 in mvc like "~2.3 <2.7".
But with depending libs, this does not work.

Either the compatibility from 2.7 to servicemanager 2.7 should be removed or the aliases. Both cannot work together.
Greetings Jan

[weierophinney]

@jg-development As noted, I cannot reproduce the issue. If you can provide me with specific details on how to reproduce it, I will re-open.

At this point, I am not willing to make a change, as I know from the above tests that it works for both zend-servicemanager v2 and v3, but with the change suggested, will stop working for v3. Unless I have a way to reliably reproduce the issue, allowing me to debug, I have nothing more to work with.

[jg-development]

Hi,

you can reproduce it with these steps:
Create an skeleton application as you done it before.
Edit the composer.json to this:

{
  "name": "zendframework/skeleton-application",
  "description": "Skeleton Application for ZF2",
  "license": "BSD-3-Clause",
  "keywords": [
    "framework",
    "zf2"
  ],
  "homepage": "http://framework.zend.com/",
  "require": {
    "php": ">=5.3.3",
    "zendframework/zendframework": "~2.3",
    "zendframework/zend-mvc": "2.7.10",
    "zendframework/zend-servicemanager": "2.7.6"
  }
}

composer update etc.
Now add an "allow_override" with "false" to the application module and the exception is coming.

Greetings Jan