On Fri, Oct 27, 2017 at 11:57 AM, Dmitry Gusev <dmitry.gu...@gmail.com> wrote:
> Hi Thiago, > Hello, Dmitry! > I would expect this to throw an exception on application start. > Thanks for your opinion! Even more for agreeing with me! :D > I would also expected that `configuration.override` would fix this, > It would. This scenario isn't two different contributions with the same id, but a proper override. > although it's not that clear what should happen if you're overriding a > You raise a good question. What Tapestry does, and it has been this way at least since the 5.1 days, is to throw an exception when a contribution is overridden twice. > contribution twice, say, in different modules. > That's a problem we had at our day job, which has some extra configuration layers beyond factory defaults and application defaults. The solution was to create and contribute more SymbolProvider instances. Tapestry 5.4 improves the situation a little bit by processing modules are processed in alphabetical order instead of a non-deterministic one, as 5.3.x and previous ones did. This prevents some issues which only happened when the modules were processed in a certain order, so they wouldn't happen every time.
