By injecting the request class, you're basically creating many many factories. If someone wants to replace some parameters of the create call, then that is not so nice. Why not create a factory and inject that?

yes, a factory would be the best option.

@schmittjoh I was thinking about this option while using call_user_func but found it overkill.
That said, your parameters argument is pretty convincing! Let's do that.

Why do you need to extend the request class? That really should not be necessary, the request should be treated like a value (i.e. data).

@igorw I totally agree with you... but sometimes, mostly to ease the migration from an old code base to Symfony, this is needed. In fact, I was about to reject the changes we made recently about this, but then I realized that it would help a lot with some of our customers. Moreover, the possibility to override the Request class is documented. So, you should not extend the Request class, but we (unfortunately) should cover this use case.

@fabpot should I add something to a changelog? If yes, which one?

Why use call_user_func_array here and not implement a Reuqest factory for the default Request and then hvae people extend the factory if they need something else? Doesn't make so much eense to make it so generic here or?

@beberlei the idea is to permit to extend the Request class and simply set its name to the factory (I added a config entry under framework section). It's still possible to implement your own factory and replace the existing service.

@jfsimon i think the config variable is not needed, because overriding the request is only necessary in <1% of all use-cases probably much less and in that case registering your own factory is just a one liner again using the .class% parameter, plus a 10 line factory. That is what the DIC is about and what you try to solve again by building a super generic factory class.

@fabpot while I agree this PR and GH-7707 are related, they don't touch the same code at all. I would see them as separate.

@beberlei okay, I understand your point. You're right, this is too much. I will remove the $class property and the request_class parameter today (to have a chance to see this PR merged in 2.3).

@jfsimon its just my opinion, it doesn't count for mergeability :-)

@beberlei I know, but I use to over engineer everything. Simpler is better, isn't it?

Rebased & simplified (with a huge delay).
@fabpot is something missing to be merged?

As overriding the Request class is quite an edge case, I propose something that is less intrusive and still flexible enough: see #8957

IMO this patch is the lesser evil than introducing yet another global var on the request, which could lead to strange side-effects. But I believe it can be vastly simplified by removing RequestFactoryInterface and replacing it with a callable that defaults to Request::create.

Just my $0.02.

@igorw thanks for mentioning theses awful static properties... the solution you propose is the one I used in the first place, then came some convincing comments in favor of a factory. Now I really think this factory is a good point as it may permit to remove the static propoerties from the request.

@fabpot what's your mind on this factory + static properties removal thing?

My idea with the other PR was to reduce the impact of supporting this feature as it is really just an edge case and I'm not comfortable with changing so many things just for that.

Also, with my hacks, all current bundles creating Requests will be "fixed" automatically. That's not the case with this PR

As this is really just to fix some edge cases for people moving to Symfony2, I really don't like this PR. So, we can either merge mine or close it as a won't fix.