[jira] [Created] (TRINIDAD-2328) ChildPropertyTreeModel throws a NoRowAvailableException when calling isContainer() for an illegal rowKey

["Vikram Jit SIngh (JIRA)" <de...@myfaces.apache.org>]

Vikram Jit SIngh created TRINIDAD-2328:
------------------------------------------

             Summary: ChildPropertyTreeModel throws a NoRowAvailableException when calling isContainer() for an illegal rowKey
                 Key: TRINIDAD-2328
                 URL: https://issues.apache.org/jira/browse/TRINIDAD-2328
             Project: MyFaces Trinidad
          Issue Type: Bug
          Components: Components
    Affects Versions: 2.0.2-core, 2.1.0-core
         Environment: All
            Reporter: Vikram Jit SIngh


As per the contract of TreeModel/CollectionModel backed by DataModel and implemented by SortableModel (used for Lists in ChildPropertyTreeModel)

1) setRowKey() accepts illegal rowKeys and fails silently, although if the rowKey is illegal in the middle of the node path it assigns -1. Currently, it can accept/assign an illegal rowKey if and only if it has only one node.

2) getRowData() states that it should be called only after validating through isRowAvailable() otherwise it may throw a NoRowAvailableException if the rowKey/rowIndex is illegal.

3) isContainer() does not specify any usage contract and hence "should return FALSE even for illegal rowKeys (since illegal row keys are actually legal to be entered)".

Problem:
Instantiate ChildPropertyTreeModel with a dummy instance and set an illegal rowKey. Call isContainer().
OR
Instantiate ChildPropertyTreeModel with NULL and set any rowKey. Call isContainer().

Seen:
NoRowAvailableException is thrown.

Expected:
It should silently return false

Cause & Solution:
isContainer() calls getRowData() without checking for isRowAvailable(), which is mandated by the contract, and hence throws the exception. Solution is to check isRowAvailable() and then proceed accordingly.

Extra Notes:
Although an illegal rowKey is acceptable, IMHO it can serve as a cause for problems and hence should be changed to revert to -1 whenever an illegal rowKey is detected, since the contract states that the function can take illegal rowKeys but does not mandate the usage of illegal rowKeys. We can very well revert those to -1. This can be opened as a new Issue/Enhancement.

Patch:
Will attach the patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira