Added a test case to demonstrate the fatal error occuring when a Bundle implementing BundleInterface only is registered in the kernel.
Only call registerCommand on bundles that is an instance of Bundle

Fixes GH-5133
[DoctrineBridge] Fix log of non utf8 data
MD format fix
merged branch gajdaw/md_format_fix (PR #5160)

Commits
-------

6b0dcbb MD format fix

Discussion
----------

Md format fix

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -

Small format fixes in CHANGELOG-2.0.md.

---------------------------------------------------------------------------

by travisbot at 2012-08-03T06:23:27Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2025980) (merged 6b0dcbb7 into 1da896dc).
merged branch web-dev/bundle-interface-command-fatal-error (PR #5133)

Commits
-------

30bcb57 Added a test case to demonstrate the fatal error occuring when a Bundle implementing BundleInterface only is registered in the kernel.

Discussion
----------

Fatal error in FrameworkBundle console application

A fatal error is generated in the `FrameworkBundle` console application when a bundle is added implementing [`BundleInterface`](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Bundle/BundleInterface.php)

This is because the method `registerCommands` does not exist on this interface and is instead only defined on the concrete [`Bundle`](https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpKernel/Bundle/Bundle.php#L173) implementation.

The workaround for this issue is simple - implement an empty method for `registerCommands` in the bundle implementation so that the fatal error is not triggered.

However this issue should probably be fixed by either restricting bundles to the Bundle class or expanding the `BundleInterface` to include the `registerCommands` method signature. Both of these fixes will introduce a BC break into the API so I would suggest creating a fix for 2.0 which includes method detection in the `registerCommands` method of the [`Console\Application`](https://github.com/symfony/symfony/blob/master/src/Symfony/Bundle/FrameworkBundle/Console/Application.php#L80) class.

I'm happy to submit the fix for this - however I would like some direction from the SF2 dev team as to which way they would like to resolve this.

The PR currently only contains a unit test that proves this behaviour.

---------------------------------------------------------------------------

by travisbot at 2012-08-01T02:42:55Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2006350) (merged 30bcb572 into 1da896dc).

---------------------------------------------------------------------------

by henrikbjorn at 2012-08-01T05:50:16Z

I am thinking a instanceof check might be the most reasonable in this case. But in master it should proberly be fixed by adding the method to the interface.

/cc @stof any comments if that is to be done?

---------------------------------------------------------------------------

by stof at 2012-08-01T08:53:02Z

yeah, for 2.0, we cannot change the interface.
merged branch henrikbjorn/2.0 (PR #5137)

Commits
-------

0b78fdf Only call registerCommand on bundles that is an instance of Bundle

Discussion
----------

Only call registerCommand on bundles that is an instance of Bundle

Fixes GH-5133

---------------------------------------------------------------------------

by travisbot at 2012-08-01T09:41:05Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2008252) (merged 0b78fdff into 1da896dc).

---------------------------------------------------------------------------

by henrikbjorn at 2012-08-01T10:05:00Z

Build failed because of HTTP request error.

---------------------------------------------------------------------------

by lsmith77 at 2012-08-01T11:31:08Z

wondering if it would be good if you could include the commit from #5133 in this PR .. then we get the test and the fix at once.
fix phpdoc statement of getAlias()
removed unused private property
merged branch lsmith77/container_builder_cosmetics (PR #5163)

Commits
-------

3605c54 removed unused private property
d4a78a2 fix phpdoc statement of getAlias()

Discussion
----------

Container builder cosmetics

---------------------------------------------------------------------------

by travisbot at 2012-08-03T08:39:00Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2026569) (merged 3605c54f into 13c60bde).
merged branch vicb/doctrine_logger (PR #5139)

Commits
-------

a0709fc [DoctrineBridge] Fix log of non utf8 data

Discussion
----------

Doctrine logger - fix logging of binary data

fix #5115

---------------------------------------------------------------------------

by travisbot at 2012-08-01T11:21:07Z

This pull request [fails](http://travis-ci.org/symfony/symfony/builds/2008862) (merged a0709fc3 into 1da896dc).

---------------------------------------------------------------------------

by stof at 2012-08-01T11:54:45Z

I see a way to fix it in a far better way: instead of json_encoding the parameters and appending them to the SQL, we could pass them as context to the logger (the optional second argument) as Monolog already handles normalizing the context (and in a better way silencing the error).
Btw, this would also make the log message better for rich logger as they would receive the array (for instance, the FirephpHandler is able to send the context as an array instead of a string as firebug is able to dump arrays)

---------------------------------------------------------------------------

by vicb at 2012-08-01T12:19:06Z

@stof you're right that would be much better. What about keeping this fix for 2.0 and use your suggestion for 2.1 (as the public `log` method prototype would change (to take the context as argument) ?

---------------------------------------------------------------------------

by stof at 2012-08-01T12:21:09Z

@vicb as the method is public, it need to be done in 2.1 only indeed. The next question being "why is it public ?" :)

---------------------------------------------------------------------------

by fabpot at 2012-08-03T07:47:39Z

So, what's the next step?

---------------------------------------------------------------------------

by vicb at 2012-08-03T07:48:38Z

I think this should be merged in 2.0 and then 2.1 should be updated with the suggestion from @stof

---------------------------------------------------------------------------

by fabpot at 2012-08-03T07:54:16Z

Can you provide a PR for 2.1 so that I merge both at the same time?
corrected phpdoc
[FrameworkBundle] added test for fix broken command registration
Fixes incorrect class used in src/Symfony/Bundle/FrameworkBundle/Console/Application.php

Issue must be related to commit 7a5f6142405c599cf0eb54e80c98e54e41ab4fdf (merged 2.0), specifically this file src/Symfony/Bundle/FrameworkBundle/Console/Application.php, lines 86-88. 

Presumably to do "instanceof Bundle" correct class has to be imported at the top of the file:

instead of 
use Symfony\Component\HttpKernel\Bundle;

this should be
use Symfony\Component\HttpKernel\Bundle\Bundle;
Conflicts:

	src/Symfony/Bundle/FrameworkBundle/Console/Application.php
merged branch lsmith77/container_builder_cosmetics (PR #5165)

Commits
-------

4563397 corrected phpdoc

Discussion
----------

corrected phpdoc

---------------------------------------------------------------------------

by travisbot at 2012-08-03T09:37:07Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2026993) (merged 4563397c into fee3f4e1).
merged branch SamsonIT/fix_broken_command_registration (PR #5169)

Commits
-------

55a0b34 Fixes incorrect class used in src/Symfony/Bundle/FrameworkBundle/Console/Application.php
79c547f [FrameworkBundle] added test for fix broken command registration

Discussion
----------

[FrameworkBundle] fix broken command registration

fixed #5168, #5166

---------------------------------------------------------------------------

by travisbot at 2012-08-03T11:35:29Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2027699) (merged 39e964b8 into fee3f4e1).

---------------------------------------------------------------------------

by travisbot at 2012-08-03T11:45:14Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2027761) (merged 55a0b347 into fee3f4e1).

---------------------------------------------------------------------------

by xeross at 2012-08-03T11:45:45Z

Duplicate of #5166

---------------------------------------------------------------------------

by Burgov at 2012-08-03T11:47:54Z

@xeross that PR was opened on master instead of 2.0

---------------------------------------------------------------------------

by xeross at 2012-08-03T11:48:49Z

@Burgov Ah sorry, I got confused and thought this was another dupe
[Config] Missing type argument passed to loader.

In FileLoader the $type is not passed to the child loader.
merged branch beberlei/ConfigFileLoaderTypeMissing (PR #5193)

Commits
-------

b3cf36a [Config] Missing type argument passed to loader.

Discussion
----------

[Config] Missing type argument passed to loader.

In FileLoader the $type is not passed to the child loader.

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
License of the code: MIT

---------------------------------------------------------------------------

by travisbot at 2012-08-06T14:22:30Z

This pull request [passes](http://travis-ci.org/symfony/symfony/builds/2047982) (merged b3cf36af into 89dce2df).
[DependencyInjection] Added a test for a frozen constructor of a container with no parameters
[DependencyInjection] Fixed a frozen constructor of a container with no parameters