Skip to content

[Bundle] Enqueue\Symfony\Client\ContainerAwareProcessorRegistry expects processors to be public #410

New issue

Have a question about this project? No Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “No Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? No Sign in to your account

Closed
dkarlovi opened this issue Mar 22, 2018 · 2 comments

Comments

@dkarlovi
Copy link
Contributor

With Symfony 4, all services are private by default. But Enqueue\Symfony\Client\ContainerAwareProcessorRegistry keeps them as a set of names which it tries to get() from the container.

A better approach might be to inject tagged services or alternatively use a service locator.

@makasim
Copy link
Member

makasim commented Mar 22, 2018

A PR that fixes it would be great

@dkarlovi
Copy link
Contributor Author

dkarlovi commented Apr 4, 2018

We should probably fix this first, then #409 since that one will make services private by default.

mnavarrocarter pushed a commit to mnavarrocarter/enqueue-dev that referenced this issue Jun 7, 2018
…or TopicSubscriberInterface

This will allow to symfony users that have autowiring/autoconfigure enabled to be able to rapidly
create their processors without worrying registering them as a service and adding the tag.

This closes php-enqueue#409 and php-enqueue#405. Also, keeps in mind php-enqueue#410. That's why services are public until a better solution
is implemented.
mnavarrocarter pushed a commit to mnavarrocarter/enqueue-dev that referenced this issue Jun 7, 2018
…or TopicSubscriberInterface

This will allow to symfony users that have autowiring/autoconfigure enabled to be able to rapidly
create their processors without worrying registering them as a service and adding the tag.

This closes php-enqueue#409 and php-enqueue#405. Also, keeps in mind php-enqueue#410. That's why services are public until a better solution
is implemented.
mnavarrocarter pushed a commit to mnavarrocarter/enqueue-dev that referenced this issue Jun 7, 2018
…or TopicSubscriberInterface

This will allow to symfony users that have autowiring/autoconfigure enabled to be able to rapidly
create their processors without worrying registering them as a service and adding the tag.

This closes php-enqueue#409 and php-enqueue#405. Also, keeps in mind php-enqueue#410. That's why services are public until a better solution
is implemented.
mnavarrocarter pushed a commit to mnavarrocarter/enqueue-dev that referenced this issue Jun 7, 2018
…or TopicSubscriberInterface

This will allow to symfony users that have autowiring/autoconfigure enabled to be able to rapidly
create their processors without worrying registering them as a service and adding the tag.

This closes php-enqueue#409 and php-enqueue#405. Also, keeps in mind php-enqueue#410. That's why services are public until a better solution
is implemented.
@makasim makasim closed this as completed Jun 8, 2018
ASKozienko pushed a commit that referenced this issue Nov 2, 2018
…or TopicSubscriberInterface

This will allow to symfony users that have autowiring/autoconfigure enabled to be able to rapidly
create their processors without worrying registering them as a service and adding the tag.

This closes #409 and #405. Also, keeps in mind #410. That's why services are public until a better solution
is implemented.
@makasim makasim added this to the 0.9 milestone Nov 27, 2018
No Sign up for free to join this conversation on GitHub. Already have an account? No Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants