[
https://issues.apache.org/struts/browse/TILES-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Racon updated TILES-416:
-------------------------------
Attachment: wildcard-order-map.patch
Here is a patch that preserves the API.
I am still on the side that enforcing the ordered map at the API level is
better then the risk of exposing the implementation details of the Map. It
prevents issues in the future - when someone decides to provide his own
implementation that conforms to a Map interface but does not preserve the
insertion order.
> wildcard order of tile definitions is not preserved
> ---------------------------------------------------
>
> Key: TILES-416
> URL: https://issues.apache.org/struts/browse/TILES-416
> Project: Tiles
> Issue Type: Bug
> Components: tiles-core
> Affects Versions: 2.1.2
> Reporter: Lukasz Racon
> Attachments: wildcard-order-map.patch, wildcard-order.patch
>
>
> Tile definitions are stored in HashMap which does not preserve the order from
> the tiles definition XML.
> If you define these two:
> <definition name="test.def*.sub*" template="/test{1}.jsp">
> <definition name="test.def*" template="/test{1}.jsp">
> and try to resolve definition name like "test.defName.subLayered" you may get
> either.
> Order that depends on tile name hashCode and hash table implementation does
> not sound like a good idea. When table reaches load threshold it may give you
> different result. For example adding 13th tile definition (Hash table has
> default capacity: 16 and .75 load factor) triggers resize function that may
> reorder tile definitions - tiles that worked before may suddenly stop working.
> Same issue was reported here:
> http://markmail.org/message/cgazkho4qndlgo6d
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
