Fix Symfony 6.2 deprecation

[franmomu]

When using the bundle with Symfony 6.2 there is this deprecation warning:

The "Presta\SitemapBundle\Messenger\DumpSitemapMessageHandler" class implements "Symfony\Component\Messenger\Handler\MessageHandlerInterface" that is deprecated since Symfony 6.2, use the {@see AsMessageHandler} attribute instead.

AFAIK the MessageHandlerInterface is just a marker to tell Symfony to autoconfigure the class, but since it's already defined and configured in

PrestaSitemapBundle/config/messenger.xml

Lines 7 to 12 in 61e6c07

	<service id="presta_sitemap.messenger.message_handler" class="Presta\SitemapBundle\Messenger\DumpSitemapMessageHandler">
	<argument type="service" id="router" />
	<argument type="service" id="presta_sitemap.dumper" />
	<argument>%presta_sitemap.dump_directory%</argument>
	<tag name="messenger.message_handler" />
	</service>

I think the interface is not necessary.

Technically this is a BC break, but I guess this class is not meant to be extended by the user.

Update: Following #303 (comment), it is resolved by adding handles="Presta\SitemapBundle\Messenger\DumpSitemapMessage", there is no need to remove the interface for now.

[norkunas]

Maybe we should add handles="Presta\SitemapBundle\Messenger\DumpSitemapMessage" as Symfony does in it's core configurations?

[norkunas]

Edit: oh because ecd355f was not released yet..

Also I saw another two deprecation logs but they says the same:

The "Symfony\Component\Console\Command\Command::$defaultName" property is considered final. You should not override it in "Presta\SitemapBundle\Command\DumpSitemapsCommand".

Since symfony/console 6.1: Relying on the static property "$defaultName" for setting a command name is deprecated. Add the "Symfony\Component\Console\Attribute\AsCommand" attribute to the "Presta\SitemapBundle\Command\DumpSitemapsCommand" class instead.

[franmomu]

Maybe we should add handles="Presta\SitemapBundle\Messenger\DumpSitemapMessage" as Symfony does in it's core configurations?

Apparently it's not necessary: https://symfony.com/doc/current/messenger.html#manually-configuring-handlers

<service id="App\MessageHandler\SmsNotificationHandler">
     <!-- handles is only needed if it can't be guessed by type-hint -->
     <tag name="messenger.message_handler"
          handles="App\Message\SmsNotification"/>
</service>

but if they have it I don't know why 🤷‍♂️

[norkunas]

When it is declared Symfony does not need to guess what this handler handles, so imho from perf side it would be better even it's unnoticeable

[franmomu]

When it is declared Symfony does not need to guess what this handler handles, so imho from perf side it would be better even it's unnoticeable

There is no need then to remove the interface 👍

[norkunas]

Could this get merged? 😊

[yann-eugone]

Will fix #307

[yann-eugone]

I will take some time to see if something more is required for us to release it, but trying to do it ASAP

[yann-eugone]

Released as of https://github.com/prestaconcept/PrestaSitemapBundle/releases/tag/v3.3.1

[norkunas]

The deprecation about MessageHandlerInterface is still triggered. I guess we should conditionally create the class based on symfony version something like:

if (Kernel::VERSION_ID >= 60200) {
    class DumpSitemapMessageHandler {}
} else {
    class DumpSitemapMessageHandler implements MessageHandlerInterface {}
}

to avoid triggering it. or check if we need to implement it at all.

[yann-eugone]

Here we go again with these ugly solutions ^^
I'm wondering whether it is actually BC ?
If we remove the interface, but it is still working on EVERY symfony version we support, it should be OK right ?
This code was never intended to be used directly, or extended, or...
I believe that if someone has some static analysis tools plugged on, relying on this interface, he should be pissed we removed the interface, but does that exists anyway ?
Do we have examples on how the community has handled these changes ?

[norkunas]

I leaning to think that handles part in config is enough and should work