I am targeting this branch, because it contains BC breaks.

Closes https://github.com/sonata-project/SonataNotificationBundle/issues/275

Changelog

### Changed
- The [php-amqplib](https://github.com/php-amqplib/php-amqplib) is replaced with [enqueue/amqp-lib](https://github.com/php-enqueue/enqueue-dev/blob/master/docs/transport/amqp_lib.md). This is BC change cuz it still uses php-amqplib internally. The change adopts [amqp interop](https://github.com/queue-interop/queue-interop#amqp-interop) standard which allows decouple the bundle from php-amqplib and use other its implementations in future. 

To do

• [x] Changelog
• [x] Update the tests
• [x] Update the documentation
• [x] Add an upgrade note

Subject

The PR replaces php-amqplib usage with the solution based on AMQP interop. There are several reasons for that:

• The code does not rely on an implementation but interoperable interfaces.
• The biggest advantage among others is that it would work with not only php-amqplib but amqp-ext, and bunny, or any amqp interop compatible libraries.
• cleaner OO API.
• less code, fewer bugs.
• no need for dealing with low-level details ( the right type for queue argument).
• supports delaying out of the box
• supports secure connections.

I am targetting this branch, because this is a BC change.

Changelog

### Changed
- dependency from `guzzle/guzzle` to `guzzlehttp/guzzle`, because it is deprecated

Subject

Package guzzle/guzzle is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead.

Old one: https://packagist.org/packages/guzzle/guzzle New one: https://packagist.org/packages/guzzlehttp/guzzle

Add ability to set the returnPath for mail messages sent via the notificationBundle

Subject

I am targeting this branch, because the change is backward compatible and adds another email parameter setting option but does not affect if it is not submitted.

Closes #363

Changelog

### Changed

sendEmail function to allow for there setting of a return path 

This PR adds support for multiple rabbitMQ backend queues. The rabbitMQ configuration has been changed to make the definition of multiple queue/route_key combinations possible, e.g.:

sonata_notification: 
    backend: sonata.notification.backend.rabbitmq

    backends: 
      rabbitmq:
          connection:
              host:     %rabbitmq_host%
              user:     %rabbitmq_user%
              pass:     %rabbitmq_pass%
              port:     %rabbitmq_port%
              vhost:    %rabbitmq_vhost%
          exchange: main
          default_queue: mailnotification
          queues: 
            transcoding: 
              queue: transcoding
              routing_key:  transcoder
            mailnotification: 
              queue: notification
              routing_key:  mail
            facebooknotification: 
              queue: notification
              routing_key:  facebook

To start a consumerHandler for a specific queue, simply pass the --queue argument to the command:

php app/console sonata:notification:start --env=prod --iteration=250 --queue=transcoding

A specific queue backend can be retrieved with the service id sonata.notification.backend.queue_<QUEUE_NAME>, e.g. sonata.notification.backend.queue_transcoding

Environment

AWS EC2 small instances, running amazon linux and php 7.1. RabbitMQ installed locally. RabbitMQ as well as sonata notifications are set up to auto restart should they go down via supervisor.

Sonata packages

$ composer show --latest 'sonata-project/*'
`sonata-project/admin-bundle              3.31.0             The missing Symfony Admin Generator
sonata-project/block-bundle              3.11.0             Symfony SonataBlockBundle
sonata-project/cache                     2.0.1              Cache library
sonata-project/classification-bundle     3.x-dev 0f3f55f    Symfony SonataClassificationBundle
sonata-project/core-bundle               3.9.0              Symfony SonataCoreBundle
sonata-project/datagrid-bundle           2.3.1              Symfony SonataDatagridBundle
sonata-project/doctrine-extensions       1.0.2              Doctrine2 behavioral extensions
sonata-project/doctrine-orm-admin-bundle 3.4.1              Symfony Sonata / Integrate Doctrine ORM into the SonataAdminBundle
sonata-project/easy-extends-bundle       2.4.0              Symfony SonataEasyExtendsBundle
sonata-project/exporter                  1.8.0              Lightweight Exporter library
sonata-project/notification-bundle       3.3.0              Symfony SonataNotificationBundle
sonata-project/user-bundle               dev-master 7a210f8 Symfony SonataUserBundle
`

Symfony packages

$ composer show --latest 'symfony/*'
`symfony/monolog-bundle                   v3.1.2             Symfony MonologBundle
symfony/phpunit-bridge                   v3.4.3             Symfony PHPUnit Bridge
symfony/polyfill-apcu                    v1.6.0             Symfony polyfill backporting apcu_* functions to lower PHP versions
symfony/polyfill-intl-icu                v1.6.0             Symfony polyfill for intl's ICU-related data and classes
symfony/polyfill-mbstring                v1.6.0             Symfony polyfill for the Mbstring extension
symfony/polyfill-php56                   v1.6.0             Symfony polyfill backporting some PHP 5.6+ features to lower PHP versions
symfony/polyfill-php70                   v1.6.0             Symfony polyfill backporting some PHP 7.0+ features to lower PHP versions
symfony/polyfill-util                    v1.6.0             Symfony utilities for portability of PHP codes
symfony/security-acl                     v3.0.1             Symfony Security Component - ACL (Access Control List)
symfony/swiftmailer-bundle               v2.6.7             Symfony SwiftmailerBundle
symfony/symfony                          v3.4.3             The Symfony PHP framework
`

PHP version

$ php -v
`PHP 7.1.7 (cli) (built: Sep 14 2017 15:47:38) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.1.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.1.7, Copyright (c) 1999-2017, by Zend Technologies`

Subject

So since updating to version 3.3.0 of the message bundle I have that problem that it maxes out my CPU at 100% randomly. Apparently something at the startup of a new iteration cycle goes bad causing it to cap at 100% and stay there. Sadly it will not generate logs when it does this so I'm having a hard time pinpointing the issue. (The log below is the only thing that was in my rotated log)

Steps to reproduce

Unknown, maybe the connection refusal causes it somehow?

Expected results

That it starts normally each time without causing the CPU to go to 100% and stay there till you kill the php process running sonata:notification:start

Actual results

[Mon, 05 Feb 2018 22:48:30 +0000] Retrieving backend ...22:48:30 ERROR     [console] Error thrown while running command "sonata:notification:start --env=prod --iteration=250". Message: "stream_socket_client(): unable to connect to tcp://localhost:5672 (Connection refused)" ["error" => ErrorException { …},"command" => "sonata:notification:start --env=prod --iteration=250","message" => "stream_socket_client(): unable to connect to tcp://localhost:5672 (Connection refused)"] []

In StreamIO.php line 138:

  stream_socket_client(): unable to connect to tcp://localhost:5672 (Connecti
  on refused)


sonata:notification:start [-i|--iteration [ITERATION]] [--type [TYPE]] [-d|--show-details [SHOW-DETAILS]] [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--no-debug] [--] <command>

I've also got a new relic transaction case of such a long running action:

Custom	Enqueue\AmqpLib\AmqpConsumer::receiveBasicGet	230	989,000 ms	77%
Custom	Enqueue\AmqpLib\AmqpConsumer::receive	230	283,000 ms	22%
Custom	Sonata\NotificationBundle\Iterator\AMQPMessageIterator::next	230	6,350 ms	0%
Custom	PhpAmqpLib\Wire\IO\StreamIO::select	125	5,380 ms	0%
Custom	Sonata\NotificationBundle\Command\ConsumerHandlerCommand::execute	1	1,330 ms	0%
Custom	PhpAmqpLib\Channel\AbstractChannel::wait	132	181 ms	0%
Total time			1,280,000 ms	100%

I am targeting this branch, because I removed the deprecated ContainerAwareEventDispatcher and according to your contributing guide that goes here .

Closes #247

Changelog

### Fixed
- Use `EventDispatcher` instead of deprecated `ContainerAwareEventDispatcher`

Subject

As of Symfony 3.3 the ContainerAwareEventDispatcher is deprecated and throws deprecation notices during Unit tests. This PR fixes the deprecation by using the proposed EventDispatcher

This bundle now depends on Admin Bundle to be installed.

PHP Fatal error: Class 'Sonata\AdminBundle\Admin\Admin' not found in /Users/gabriel/Zend/workspaces/PM2/PMAppMIBundle/vendor/sonata-project/notification-bundle/Sonata/NotificationBundle/Admin/MessageAdmin.php on line 21

@rande, Can this dependency be removed as it breaks the usefulness of the notification bundle.

Feature Request

Would be nice to have ability to run tasks all together and not one by one, when sonata:notification:start is called... but maybe I'm a dreamer?

This reverts commit 1d9462fcec356c5a3773d4a06100487af6313dbd.

Fatal error: Call to undefined method JMS\DiExtraBundle\DependencyInjection\JMSDiExtraExtension::blacklistControllerFile()

this commit broke with JMSDiExtraBundle dev-master because blacklist is in a different branch (https://github.com/lsmith77/JMSDiExtraBundle/blob/controller_blacklist/DependencyInjection/JMSDiExtraExtension.php)

Subject

Remove deprecated SonataCoreBundle

I am targeting 3.x, because there's no BC break.

Closes #423

Changelog

### Fixed
- Fix SonataCoreBundle deprecations

I am targeting this branch, because this is BC break

Changelog

### Changed
- Disable admin configuration by default

Subject

I believe, that disabling admin in configuration is more correct, because it can be enabled only when sonata.notification.backend.doctrine was enabled.

A default configuration, i.e. recipe for sonata-project/notification-bundle could be like this:

sonata_notification:
    consumers:
        register_default: false
    admin:
        enabled: false

Also, default configuration could contain commented configuration for backend: sonata.notification.backend.rabbitmq. Anyway, i have already created PR with recipe for this bundle in febuary https://github.com/symfony/recipes-contrib/pull/302

Additional configuration, i.e. a recipe for a new package sonata-project/notification-orm-pack could be like this (i created a gist with entity class):

sonata_notification:
    backend: sonata.notification.backend.doctrine
    backends:
        doctrine: ~
    class:
        message: App\Entity\SonataNotificationMessage
    admin:
        enabled: true

So, additional configuration will override default.