merged branch Seldaek/psr3 (PR #6628)

This PR was merged into the master branch.

Commits
-------

67d7423 Remove use of deprecated HttpKernel LoggerInterface
dca4528 [HttpKernel] Extend psr/log's NullLogger class
1e5a890 [Monolog] Mark old non-PSR3 methods as deprecated
91a86f8 [HttpKernel][Monolog] Add PSR-3 support to the LoggerInterface

Discussion
----------

[HttpKernel][MonologBridge] PSR-3 support

This enables PSR-3 support and monolog 1.3+. The first commit is the main part. The rest deals with deprecation of short-hand methods (warn/err/crit/emerg) that are fully expanded in PSR-3 (warning/error/critical/emergency).

The downside of deprecating them is that for bundles it's a bit harder to support older and newer versions. If that is too much of a hassle you can drop that for now and cherry pick the first commit.

The upside is that it forces people to move towards PSR-3 compatible stuff, which means eventually we could completely drop the LoggerInterface from the framework. In any case I think the documentation should only mention the `Psr\Log\LoggerInterface` and people should start hinting against that. The change should be done in core as well I suppose.

Anyway I wanted to throw this out there as it is to get feedback.

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

by stof at 2013-01-09T09:15:15Z

@Seldaek I also think you should change the typehint to use the PSR LoggerInterface in all classes using the logger

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

by Seldaek at 2013-01-09T09:54:55Z

OK updated according to all the feedback. I tested it in an app and it still seems to work so there shouldn't be any major issues.

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

by Seldaek at 2013-01-09T09:59:55Z

@fabpot if you merge please merge also the bundle PR, otherwise it won't be possible to update without conflict.

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

by frosas at 2013-01-10T14:59:20Z

I'm trying to understand why a `composer update` of a Symfony 2.1.* resulted in a fatal error. Shouldn't a stable version don't break like this?

As @olaurendeau points, why Symfony depends 1.* instead of 1.2.*? Or why Monolog 1.3 breaks its public interface (EDIT: I'm not sure about it)? Or why isn't this PR being merged (into branch 2.1) at the same time Monolog 1.3 is released?

Please, understand I'm not looking for who to blame, it's just I want to know if this situation is unexpected or if otherwise a `composer update` on a stable branch is not as innocent as it seems.

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

by stof at 2013-01-10T15:06:51Z

@frosas it cannot be merged into 2.1 as it is a BC break. The 2.1 branch has been updated to forbid Monolog 1.3 already

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

by Seldaek at 2013-01-10T15:11:58Z

@frosas you can blame me for releasing as 1.3.0 and not 2.0, but technically for monolog this isn't really a BC break, I just added an interface. The problem is due to the way it's used in symfony, it ended up as a fatal error. In any case the situation is now sorted out I think.

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

by frosas at 2013-01-10T15:26:43Z

@stof now I see this `>=1.0,<1.3-dev` change in the 2.1 branch. Now, shouldn't a new (2.1.7) version be released for all of us not in the dev minimum-stability?

@Seldaek then do you see feasible to rely only in X.Y.* versions to avoid this kind of errors?

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

by Seldaek at 2013-01-10T15:45:22Z

@frosas relying on X.Y.* is painful because you always need to wait until someone updates the constraint to get the new version. Of course using ~1.3 like in this PR means if I fuck up and break BC people will update to it, but that's a less likely occurrence than the alternative I think, so I would rather not use X.Y.*

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

by frosas at 2013-01-10T15:50:50Z

@Seldaek you are right about this, but I was thinking more in changing it only for the stable versions. EDIT: I mean, how often do you need a new feature in a branch you only apply fixes to?

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

by stof at 2013-01-10T15:57:32Z

@frosas Monolog and Symfony have separate release cycles. Foorcing Symfony users to use an old version of Monolog until they update to a new version of Symfony whereas the newer Monolog is compatible is a bad idea. Thus, as Monolog keeps BC, it does not maintain bugfix releases for all older versions (just like Twig does too). So it would also forbid you to get the fixes done in newer Monolog versions.

The incompatibility between Symfony 2.1 LoggerInterface and PSR-3 (whereas they expect exactly the same behavior and signature for methods with the same name) is unfortunate and is the reason why we get some issues here.

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

by frosas at 2013-01-10T16:21:06Z

@stof I appreciate you prefer to allow newer versions at the price of having to be constantly monitoring its changes to avoid breaks.

Another similar but safer strategy would be to stick to X.Y.* versions and upgrade to X.Y+1.* once the new version integration is tested, but I understand this is discutible in projects as close to Symfony as Monolog.

Returning to the issue, what do you say to release this 2.1.7 version? Or is it only me who is having issues here?

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

by stof at 2013-01-10T16:26:20Z

@frosas a minor release should not break BC when following smeantic versionning (Symfony warned about the fact it is not strictly followed for the first releases of 2.x). But as far as monolog is concerned, 1.3 is BC with 1.2.

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

by Seldaek at 2013-01-10T16:49:55Z

@frosas sorry I didn't get you still had the problem. I tagged a 2.1.7 of monologbundle which hopefully fixes your issue.

1 files changed, 2 insertions, 2 deletions

diff --git a/Http/RememberMe/AbstractRememberMeServices.php b/Http/RememberMe/AbstractRememberMeServices.php
index e49ce14..ae61dd7 100644
--- a/Http/RememberMe/AbstractRememberMeServices.php
+++ b/Http/RememberMe/AbstractRememberMeServices.php
@@ -22,7 +22,7 @@ use Symfony\Component\Security\Core\Exception\CookieTheftException;
 use Symfony\Component\HttpFoundation\Response;
 use Symfony\Component\HttpFoundation\Request;
 use Symfony\Component\HttpFoundation\Cookie;
-use Symfony\Component\HttpKernel\Log\LoggerInterface;
+use Psr\Log\LoggerInterface;
 
 /**
  * Base class implementing the RememberMeServicesInterface
@@ -129,7 +129,7 @@ abstract class AbstractRememberMeServices implements RememberMeServicesInterface
             }
         } catch (UnsupportedUserException $unSupported) {
             if (null !== $this->logger) {
-                $this->logger->warn('User class for remember-me cookie not supported.');
+                $this->logger->warning('User class for remember-me cookie not supported.');
             }
         } catch (AuthenticationException $invalid) {
             if (null !== $this->logger) {