Discussion: make duplicate contributions to services with ordered configurations an error

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Discussion: make duplicate contributions to services with ordered configurations an error

Thiago H de Paula Figueiredo
Hello!

I've just stumbled again at https://issues.apache.org/jira/browse/TAP5-1305,
which boiled down to Tapestry-IoC dropping a contribution to an ordered
configuration if there's another contribution with the same id. I fixed it
specifically for service decorators. For service configurations, it
remained the same: the contribution is dropped with a warning in the log,
but I think this is easy to overlook and can cause errors which are
difficult to spot since you consider that all contributions.

What do you think of making contributing two different values to an ordered
configuration with the same id a show-stopping error?

--
Thiago
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: make duplicate contributions to services with ordered configurations an error

Dmitry Gusev
Hi Thiago,

I would expect this to throw an exception on application start.

I would also expected that `configuration.override` would fix this,
although it's not that clear what should happen if you're overriding a
contribution twice, say, in different modules.

Can we order the overrides somehow?

If so I'd expected the last override would win if ordered, if override
isn't ordered anyhow -- should fail with an error due to ambiguity. Not
sure if that's doable at the moment, so just theorising.

On Fri, Oct 27, 2017 at 4:40 PM, Thiago H. de Paula Figueiredo <
[hidden email]> wrote:

> Hello!
>
> I've just stumbled again at https://issues.apache.org/
> jira/browse/TAP5-1305,
> which boiled down to Tapestry-IoC dropping a contribution to an ordered
> configuration if there's another contribution with the same id. I fixed it
> specifically for service decorators. For service configurations, it
> remained the same: the contribution is dropped with a warning in the log,
> but I think this is easy to overlook and can cause errors which are
> difficult to spot since you consider that all contributions.
>
> What do you think of making contributing two different values to an ordered
> configuration with the same id a show-stopping error?
>
> --
> Thiago
>



--
Dmitry Gusev

AnjLab Team
http://anjlab.com
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: make duplicate contributions to services with ordered configurations an error

Thiago H de Paula Figueiredo
On Fri, Oct 27, 2017 at 11:57 AM, Dmitry Gusev <[hidden email]>
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.
Reply | Threaded
Open this post in threaded view
|

Re: Discussion: make duplicate contributions to services with ordered configurations an error

chiefsucker
In reply to this post by Dmitry Gusev
In both cases I would expect a hard exception instead of a soft warning.
There’s already enough magic going on in the background.

Best,
Rafael




On October 27, 2017 3:57:59 PM Dmitry Gusev <[hidden email]> wrote:

> Hi Thiago,
>
> I would expect this to throw an exception on application start.
>
> I would also expected that `configuration.override` would fix this,
> although it's not that clear what should happen if you're overriding a
> contribution twice, say, in different modules.
>
> Can we order the overrides somehow?
>
> If so I'd expected the last override would win if ordered, if override
> isn't ordered anyhow -- should fail with an error due to ambiguity. Not
> sure if that's doable at the moment, so just theorising.
>
> On Fri, Oct 27, 2017 at 4:40 PM, Thiago H. de Paula Figueiredo <
> [hidden email]> wrote:
>
>> Hello!
>>
>> I've just stumbled again at https://issues.apache.org/
>> jira/browse/TAP5-1305,
>> which boiled down to Tapestry-IoC dropping a contribution to an ordered
>> configuration if there's another contribution with the same id. I fixed it
>> specifically for service decorators. For service configurations, it
>> remained the same: the contribution is dropped with a warning in the log,
>> but I think this is easy to overlook and can cause errors which are
>> difficult to spot since you consider that all contributions.
>>
>> What do you think of making contributing two different values to an ordered
>> configuration with the same id a show-stopping error?
>>
>> --
>> Thiago
>>
>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]