This was just a quick fix, a solution looks different :) Kind regards, Johannes
On Wed, Feb 16, 2011 at 10:01 PM, Jeremy Mikola <[email protected]> wrote: > I believe Johannes was talking about this exact issue in IRC today. The > solution seems to be adding: > > if (!array_filter($configs)) { return; } > > To the load() methods. Alternatively, perhaps we can just use that same > logic one step above and avoid invoking load() methods for this case. > > On Wed, Feb 16, 2011 at 3:40 PM, Fabien Potencier < > [email protected]> wrote: > >> >> On 2/16/11 8:24 PM, Stefan Paschke wrote: >> >>> Dear all >>> >>> I just studied the MergeExtensionConfigurationPass->process() config >>> merging process, and noticed that it adds as many empty config arrays to >>> every extension config as there are extensions. This seems odd and I wonder >>> what the reason to do so is. >>> Basically, process() contains a foreach loop over >>> $container->getExtensions(), inside which a temporary ContainerBuilder >>> instance is created; this is used to generate an object resource for the >>> extension. The temporary ContainerBuilder instance is then merged into the >>> main ContainerBuilder. In the merging process, the main ContainerBuilder >>> checks if configurations for its extensions exist in the temporary >>> ContainerBuilder. Because they don't, temporary ContainerBuilder returns an >>> empty array, which results in empty arrays being added to the main >>> ContainerBuilders configs. These are then passed to the Extension->load() >>> methods, where they need to be filtered from the function arguments. >>> Is this intended behaviour, and if so, what is the purpose? Wouldn't it >>> be easier to avoid adding empty config arrays in case where there already is >>> a config? >>> >> >> It is not intended and it is just a side-effect of the recent refactoring. >> Can you fix this and send a pull request? >> >> Thanks, >> Fabien >> >> >> regards >>> >>> Stefan Paschke >>> >>> >> -- >> 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 >> > > > > -- > jeremy mikola > > -- > 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 > -- 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
