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

[Rafael Bugajewski]

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  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 <
thiag...@gmail.com> 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: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

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 
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.

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 <
thiag...@gmail.com> 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

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