You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@tiles.apache.org by "Lukasz Racon (JIRA)" <ji...@apache.org> on 2009/05/19 22:50:42 UTC
[jira] Created: (TILES-416) wildcard order of tile definitions is
not preserved
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
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.
[jira] Updated: (TILES-416) wildcard order of tile definitions is
not preserved
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/TILES-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Petrelli updated TILES-416:
-----------------------------------
Applied patch by Lukasz Racon.
Thanks Lukasz!
> 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
> Assignee: Antonio Petrelli
> 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.
[jira] Updated: (TILES-416) wildcard order of tile definitions is
not preserved
Posted by "Lukasz Racon (JIRA)" <ji...@apache.org>.
[ 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.patch
Map implementation, that stores tile definitions, was changed from HashMap to LinkedHashMap. We could use Map interface for API and instantiate LinkedHashMap, but this way at least intentions are visible and code compilation enforces an ordered Map.
> 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.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.
[jira] Closed: (TILES-416) wildcard order of tile definitions is
not preserved
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/TILES-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Petrelli closed TILES-416.
----------------------------------
Resolution: Fixed
> 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
> Assignee: Antonio Petrelli
> 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.
[jira] Updated: (TILES-416) wildcard order of tile definitions is
not preserved
Posted by "Lukasz Racon (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (TILES-416) wildcard order of tile definitions is
not preserved
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/TILES-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Petrelli updated TILES-416:
-----------------------------------
Assignee: Antonio Petrelli
> 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
> Assignee: Antonio Petrelli
> 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.
[jira] Updated: (TILES-416) wildcard order of tile definitions is
not preserved
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/TILES-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Petrelli updated TILES-416:
-----------------------------------
Fix Version/s: 2.1.3
> 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
> Assignee: Antonio Petrelli
> Fix For: 2.1.3
>
> 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.
[jira] Updated: (TILES-416) wildcard order of tile definitions is
not preserved
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/TILES-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Antonio Petrelli updated TILES-416:
-----------------------------------
Ok to use LinkedHashMap, but can you prepare a patch in which you don't change the API (using Map as a return value as it was) and in which variable types are always Map?
You need to use the LinkedHashMap only at instantiation.
> 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.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.
[jira] Commented: (TILES-416) wildcard order of tile definitions is
not preserved
Posted by "Antonio Petrelli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/struts/browse/TILES-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=46376#action_46376 ]
Antonio Petrelli commented on TILES-416:
----------------------------------------
About using the interface and not the implementation to be exposed by the API, this is simply a best practice.
But you are right, there should be some way to say that should enforce the order.
For example, the API should return a collection, and not a Map: building the map should be a consequence.
Can you open a JIRA issue about it?
P.S. I like the new patch, I will apply it ASAP.
> 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.