[ https://issues.jboss.org/browse/JBTM-2593?page=com.atlassian.jira.plugin.... ] Mark Little commented on JBTM-2593: ----------------------------------- OK, so for full details of why this really shouldn't have been a warning in the first place here goes ... read_state takes a file type (ft in the parameters) ... protected InputObjectState read_state (Uid objUid, String tName, int ft) Within the method we get the current state of the instance ... int state = currentState(objUid, tName); Now that state could be one of OS_UNKNOWN, OS_COMMITTED, OS_UNCOMMITTED, OS_HIDDEN, OS_COMMITTED_HIDDEN or OS_UNCOMMITTED_HIDDEN. All of these are valid values for the state to have (OS_UNKNOWN typically means "it's not there"). Assuming it's OS_COMMITTED or OS_UNCOMMITTED we're going to see if that's the state we expected when read_state was called, i.e., if ft is one of these. Then we do other "stuff"/ If the state isn't OS_COMMITTED or OS_UNCOMMITTED then we're not going to bother reading the state. If it's hidden (committed hidden or even uncommitted hidden) then we're going to return a null state and the caller interprets this at the higher level. For example, if it expected to find a state and got null back then it can call currentState and base its next actions on that value, e.g., then calling reveal_state and read_state once again. But the important thing is that just because the state is neither committed nor uncommitted does not mean that it's an error or a warning. That's for the caller to determine and not the ObjectStore implementation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)