[jira] [Updated] (TAP5-2636) Non-unique advice IDs silently override each other in random order on application startup

["Dmitry Gusev (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitry Gusev updated TAP5-2636:
-------------------------------
    Description: 
Looks like Tapestry5 has had this behaviour for a long time if not always, not sure what were the reasons behind it, but it doesn't sound right and may lead to undefined behaviour.

Maybe this is simply a misuse of the `new Orderer` constructor:

 

 
{code:java}
@Override
public List<ServiceAdvisor> findAdvisorsForService(ServiceDef3 serviceDef)
{
    lock.check();

    assert serviceDef != null;

    Logger logger = getServiceLogger(serviceDef.getServiceId());

    Orderer<ServiceAdvisor> orderer = new Orderer<ServiceAdvisor>(logger); // <<<<<<<<<<<< Here

    for (Module module : moduleToServiceDefs.keySet())
{code}
This is not the case with decorators, their IDs are forced to be unique, the implementation passes `true` as the second argument here.

I believe it needs fixing, but because we've had it working like this for a long time, maybe with a symbol that preserves original behaviour that should not allow duplicate IDs by default?

 

  was:
Looks like Tapestry5 has had this behaviour for a long time if not always, not sure what were the reasons behind it, but it doesn't sound right and may lead to undefined behaviour.

Maybe this is simply a misuse of the `new Orderer` constructor.

!image-2020-08-17-11-57-54-832.png|width=568,height=211!

This is not the case with decorators, their IDs are forced to be unique, the implementation passes `true` as the second argument here.

I believe it needs fixing, but because we've had it working like this for a long time, maybe with a symbol that preserves original behaviour that should not allow duplicate IDs by default?

 


> Non-unique advice IDs silently override each other in random order on application startup
> -----------------------------------------------------------------------------------------
>
>                 Key: TAP5-2636
>                 URL: https://issues.apache.org/jira/browse/TAP5-2636
>             Project: Tapestry 5
>          Issue Type: Bug
>    Affects Versions: 5.5.0
>            Reporter: Dmitry Gusev
>            Priority: Major
>
> Looks like Tapestry5 has had this behaviour for a long time if not always, not sure what were the reasons behind it, but it doesn't sound right and may lead to undefined behaviour.
> Maybe this is simply a misuse of the `new Orderer` constructor:
>  
>  
> {code:java}
> @Override
> public List<ServiceAdvisor> findAdvisorsForService(ServiceDef3 serviceDef)
> {
>     lock.check();
>     assert serviceDef != null;
>     Logger logger = getServiceLogger(serviceDef.getServiceId());
>     Orderer<ServiceAdvisor> orderer = new Orderer<ServiceAdvisor>(logger); // <<<<<<<<<<<< Here
>     for (Module module : moduleToServiceDefs.keySet())
> {code}
> This is not the case with decorators, their IDs are forced to be unique, the implementation passes `true` as the second argument here.
> I believe it needs fixing, but because we've had it working like this for a long time, maybe with a symbol that preserves original behaviour that should not allow duplicate IDs by default?
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)