avoid trying to load nonexistent DoctrineTransportFactory class

[craue]

This fixes symfony/symfony#41727.

[craue]

This instead would also do:

- if (! class_exists(\Symfony\Component\Messenger\Transport\Doctrine\DoctrineTransportFactory::class)) {
+ if (! class_exists(\Symfony\Component\Messenger\Transport\Doctrine\DoctrineTransportFactory::class, false)) {

[ostrolucky]

Build needs to be green. Please test if your second solution works in both scenarios, it's SA friendly

[nicolas-grekas]

• if (! class_exists(\Symfony\Component\Messenger\Transport\Doctrine\DoctrineTransportFactory::class, false)) {

I'm not sure this would, as it would not try to actually load the class and would rely on class loading order.

[craue]

I could only test if it's working in my scenario (to avoid the error), it does.

[nicolas-grekas]

OK, then I confirm this 2nd patch would break the logic when the package is found in vendor.

[craue]

Too bad. What about the failing SA then?

[ostrolucky]

Closing here, as this is a broken BC on Symfony side. Doctrine-bundle shouldn't have to update the code just so it keeps working with next minor symfony version. Please fix BC layer on Symfony side.

[ostrolucky]

Actually, just noticed code on symfony side didn't change since symfony 5.1, which is probably when we added class_exists, so it's our BC layer that was broken whole time

[ostrolucky]

One solution which should be better is reversing the conditions. Default to new transport factory. If it doesn't exist, use legacy one.

[craue]

Like this?

- if (! class_exists(DoctrineTransportFactory::class)) {
-     // If symfony/messenger < 5.1
-     if (! class_exists(\Symfony\Component\Messenger\Transport\Doctrine\DoctrineTransportFactory::class)) {
-         // Dont add the tag
-         return;
-     }
- 
-     $transportFactoryDefinition->setClass(\Symfony\Component\Messenger\Transport\Doctrine\DoctrineTransportFactory::class);
- }
- 
- $transportFactoryDefinition->addTag('messenger.transport_factory');
+ if (class_exists(DoctrineTransportFactory::class)) {
+     $transportFactoryDefinition->addTag('messenger.transport_factory');
+ } elseif (class_exists(\Symfony\Component\Messenger\Transport\Doctrine\DoctrineTransportFactory::class, false)) {
+     // symfony/messenger >= 5.1
+     $transportFactoryDefinition->setClass(\Symfony\Component\Messenger\Transport\Doctrine\DoctrineTransportFactory::class);
+     $transportFactoryDefinition->addTag('messenger.transport_factory');
+ }

[craue]

/ping

[ostrolucky]

yes, but without false flag

[craue]

yes, but without false flag

Without it, I'd get the initial error again.

[ostrolucky]

I'm back to my first response: It's an issue on Symfony side. I've created symfony/symfony#42303. As for what you can do, you can call DebugClassLoader::disable() in your test case, or stop using symfony/phpunit-bridge, which enables it

[craue]

Calling DebugClassLoader::disable() in my test case makes it pass but complain about

Remaining indirect deprecation notices (1)

  1x: Since symfony/messenger 5.1: The "Symfony\Component\Messenger\Transport\Doctrine\DoctrineTransportFactory"
class is deprecated, use "Symfony\Component\Messenger\Bridge\Doctrine\Transport\DoctrineTransportFactory" instead.
The Doctrine transport has been moved to package "symfony/doctrine-messenger" and will not be included by default
in 6.0. Run "composer require symfony/doctrine-messenger".

although I'm not actively using the messenger and cannot see a way to get rid of that deprecation notice.

[ostrolucky]

see referenced issue. stop using symfony/symfony