Can you show the stack trace of the error that you receive? I do not really see why the current code should trigger it.

Can you show the stack trace of the error that you receive? I do not really see why the current code should trigger it.

Sure,https://travis-ci.org/github/Warxcell/files/jobs/773978302#L785

If I docomposer require symfony/amqp-messenger - it's working again. But I don't really need that package.

I think we should prevent the use ofReflectionClass instead if the given class does not exist:#41751

Why? To me it's looks like this middleware is tighly coupled to AMQP package, why not ship it inside it and load it only when installed, rather than ship it globally in Messenger, load it always, and check on every message if class exists?

We can think about adding a new middleware in another namespace and deprecate the other one. But such a change must not happen in a patch release and would have to target the5.4 branch.

Ok, so I will redirect this to 5.4 and your fix will be patched in 5.2 ?

Please fix commit+PR title
and add a line in the changelog of the component, and in UPGRADE files for 5.4 and 6.0.

I'm working on an alternative AMQP transport for messenger based onbunny library.

Moving this class will complicate dependency tree. Can we choose the way@xabbuh proposes to avoid that?

EDIT: This class is indeed so tightly coupled tosymfony/amqp-messenger it has no business staying at the component level. Please disregard what I said, I'll find a way to make it work for another transport.

@Warxcell Looks good to me. Can you rebase on 6.2 and update the code accordingly? Thank you.

On closer look, I think we should close this PR. The linked issue has been fixed, which means that in practice, this is change is just a nice to have. Yes, the implementation knows only about some amqp stamp at the moment, but we could also imagine a day where it manages other kind of stamps.

Thanks for having a look Nicolas. Let's close then.