ping@bamarni@lsmith77

👍

Yeah it would be awesome! 👍

Will services tagged as "cache warmer" replaced with listeners for cache:clear command?

best way to introduce this feature by a longshot without changing existing code, +1 from me.

@Koc that doesn't make sense imho, Cache Warming should work independent of console listeners.

@fabpot can we get all output as a string in terminate event?

👍

👍 I've been working with a few Symfony Console apps lately and this functionality would be awesome!

@Koc: you can wrap/change the output instance in the command event, so that you can then get what was displayed in the terminate event. This PR gives you the flexibility, it's then up to you to use it the way you want.

(I repost my comment, github hide it for now)

It could be useful to be able to not throw the exception inApplication::doRunCommand ; like in theHttpKernel.

Use case : you have a long running process like a rabbitmq consumer. With this feature, we could delegate the exception process into a dedicated event listener and make the "raw" command cleaner.

good to see this moving forward 👍

@stof had previously spotted a bug with this feature and the cache:clear command, see (#3889 (comment) for the beginning of the discussion), basically we came out to the conclusion that the cache:clear command shouldn't have this event dispatching capability, otherwise it would require some dirty hacks, do you think it will be easily doable when integrating this to the framework (as I can see this PR is only about the component part)?

I'd also have a remark about the ability to change the command to be executed through the pre-event, do you have any use case in mind? Imo this doesn't make so much sense.

I can see it'd use the same input object, It means that the changed command should have the same arguments / options than the first one, or basically that it should be able to work with the same input, it looks like a pretty restricting condition.

It is also not always so easy to instantiate a command object, for example when using this feature with the framework, one would always need to have the container so that it can passes it to the command (as usually they are container aware), it looks like all this would be kind of a "sub-application".

@fabpot Would you use the same listener than for the kernel when integrating it in a Sf2 project ? Because in this case, we would face the bug I reported in the previous PR: if you deleted a subscriber class and the kernel is in non-debug mode, creating the event dispatcher object will break (in debug mode, the container would be refreshed without the subscriber). But thecache:clear command should be able to be used even when you have an outdated cache as its goal is to clear it.

otherwise, 👍 for this implementation.

Should the listener flushing the swiftmailer memory spool be added in the bridge in this PR or in a subsequent one ?

@bamarni You're right. I've removed the possibility to change the command in a console.command listener.

@lyrixx not sure how to implement that. Let's do that in another PR.

@stof@bamarni I'm aware of the possible problems withcache:clear. But we already have such issues today. When upgrading Symfony where a new parameter in the DIC is required without default value, you have the same problem. So, I propose to deal with that in another PR.

see#6519 for instance

@stof The Swiftmailer listener should be done in another PR, especially because it is not that easy (the best would be do be able to move the listener from the bundle to the bridge).