Hello

I found the origin of the issue.  
When warming up, base UrlMatcher / UrlGenerator are "cached" by the routing 
component. The CMF ChainRouter adds its routers in a compiler pass through its 
add() method. But calling this method triggers setContext() which triggers 
again UrlMatcher caching process, thus the collision and the fatal error.

A first global solution would be to adopt the same behavior than in the 
CacheClearCommand by generating a suffix for the class name. To be consistent, 
it would imply the command to expose the generated suffix (via uniqid()) so 
that WarmableInterface implementations could use it to generate their cache 
eventually, the CacheClearCommand already cleaning up the file and class names 
after the warmup process has finished.

Another approach for the CMF ChainRouter would be not to set the request 
context in add(), but rather in all() (after sorting). I'll create a PR for 
that :)

Hope that helps.  

--  
Jérôme Vieilledent


Le vendredi 21 septembre 2012 à 15:31, Jérôme Vieilledent a écrit :

> Hello
>  
> I found the origin of the issue.  
> When warming up, base UrlMatcher / UrlGenerator are "cached" by the routing 
> component. The CMF ChainRouter adds its routers in a compiler pass through 
> its add() method. But calling this method triggers setContext() which 
> triggers again UrlMatcher caching process, thus the collision and the fatal 
> error.
>  
> A first global solution would be to adopt the same behavior than in the 
> CacheClearCommand by generating a suffix for the class name. To be 
> consistent, it would imply the command to expose the generated suffix (via 
> uniqid()) so that WarmableInterface implementations could use it to generate 
> their cache eventually, the CacheClearCommand already cleaning up the file 
> and class names after the warmup process has finished.
>  
> Another approach for the CMF ChainRouter would be not to set the request 
> context in add(), but rather in all() (after sorting). I'll create a PR for 
> that :)
>  
> Hope that helps.  

-- 
If you want to report a vulnerability issue on symfony, please send it to 
security at symfony-project.com

You received this message because you are subscribed to the Google
Groups "symfony developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en

Reply via email to