You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Thiago Henrique De Paula Figueiredo (Jira)" <ji...@apache.org> on 2020/12/02 02:48:00 UTC
[jira] [Commented] (TAP5-2636) Non-unique advice IDs silently
override each other in random order on application startup
[ https://issues.apache.org/jira/browse/TAP5-2636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17242003#comment-17242003 ]
Thiago Henrique De Paula Figueiredo commented on TAP5-2636:
-----------------------------------------------------------
Hello, [~dmitrygusev]!
Good catch! I believe you're right that this is a bug, and one existing since the beginning of Tapestry and I seriously dislike this kind of override being done without an error. I don't think the configuration symbol is needed here. I'm fixing it now.
> 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
> Assignee: Thiago Henrique De Paula Figueiredo
> 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 in the `RegistryImpl.java`:
> {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)