@lsmith77 any news about this ?

havent had time for this. but should be something for someone who wants to dip their toes in core dev. will try to find a helping hand via twitter.

@lsmith sounds interesting taking a look

@lsmith77 can you please elaborate on

my personal example use case is wanting to set a dynamic HTTP header in all commands calling a backend through a load balancer that picks the server based on said HTTP header.

I am also confused because in the other ticket you said tags, @fabpot reopened it because of it otherwise he would have kept it closed and now this is events again.

here is an example of a kernel listener, that i would also like to run on the CLI before any command is executed:

    api.jackalopeheader.listener:
        class: Foo\BarBundle\EventListener\JackalopeHeaderListener
        arguments:
            - @doctrine_phpcr.odm.document_manager
            - %phpcr_loadbalancer_session_header%
            - %phpcr_loadbalancer_session_max_value%
        tags:
            -  { name: kernel.event_listener, event: kernel.request, method: onKernelRequest }

so the idea would be that I could also modify the tag section to something like the following

        tags:
            -  { name: kernel.event_listener, event: kernel.request, method: onKernelRequest }
            -  { name: cli.event_listener, event: cli.init, method: onCliInit }

@lsmith77 if you implement it using the EventDispatcher, there is no reason to have a different tag name.

Any progress on this? May I give it a try using the tag approach?

@flevour i have not worked on it .. and i have not seen anyone else post any progress on this ticket

@lsmith77 if the tag approach is still the way to go, I'll give it a shot.

yes it is.

Sorry, but I need to discuss this a little further. Where would the fix go?

I read #1884 a 3 or 4 times to make sure I am understanding the issue.
In that case the point for not using EventDispatcher was to avoid making the Console component depend on it. So the solution was to implement some code inside the CacheClearCommand and using the tag system to call all tagged services at the right moment. Anyway depending on the EventDispatcher wouldn't be a problem because the CacheClearCommand is implemented inside FrameworkBundle which depends on the ED (is this statement correct at all?).

If I understand correctly, the scope of this issue is a bit larger. It's not aiming to solve a specific use case, as in the cache:clear scenario. Instead it's aiming to create a way to solve all possible cases when you want to call a set of services before or after the execution of a command. This would mean calling all properly tagged services at the right moment. That is, modifying ContainerAwareCommand in order to wrap the call to execute() with calls to the tagged services.

As this sounds very EventDispatcher-y to me (and your example makes the parallelism even more likely), could you please help me understand why going with tagged services is the way to go and how would you implement it?

The final code would be in the FrameworkBundle as a new compiler pass. There we would look for the tagged services and connect them to events. The events should themselves be triggered inside Symfony\Bundle\FrameworkBundle\Console\Application

I published the PR just to gather feedback about the direction I am taking.
I tried to avoid using EventDispatcher but eventually I would end up rewriting a worse implementation of it for this use case.

Hi Lukas, when you have 2 mins, please give a look at #3889, I need some pointers to move on.