Hello Thanks Marcel for you help.
I found the source of the problem with nt:base and nt:hierarchyNode node types. It's outdated properties file. Sergey Kabashnyuk eXo Platform SAS 2009/8/27 Marcel Reutegger <[email protected]>: > Hi, > > On Tue, Aug 25, 2009 at 12:05, Sergey Kabashnyuk<[email protected]> wrote: >> Hello. >> I have more questions about tests. >> >> 1. In tests >> >> org.apache.jackrabbit.test.api.NodeTest#testAddNodeConstraintViolationExceptionUndefinedNodeType >> org.apache.jackrabbit.test.api.NodeTest#testRemoveMandatoryNode >> >> org.apache.jackrabbit.test.api.WorkspaceCloneTest#testCloneNodesConstraintViolationException >> >> org.apache.jackrabbit.test.api.WorkspaceCopyBetweenWorkspacesTest#testCopyNodesConstraintViolationException >> >> org.apache.jackrabbit.test.api.WorkspaceCopyTest#testCopyNodesConstraintViolationException >> >> org.apache.jackrabbit.test.api.WorkspaceMoveTest#testMoveNodesConstraintViolationException >> >> org.apache.jackrabbit.test.api.SerializationTest#testNodeTypeConstraintViolationWorkspaceWithHandler >> >> org.apache.jackrabbit.test.api.SerializationTest#testNodeTypeConstraintViolationSessionWithHandler >> >> org.apache.jackrabbit.test.api.SerializationTest#testNodeTypeConstraintViolationWorkspace >> >> org.apache.jackrabbit.test.api.SerializationTest#testNodeTypeConstraintViolationSession >> >> nt:base used as primary node type, and in test >> >> org.apache.jackrabbit.test.api.SessionTest#testMoveItemExistsException >> >> org.apache.jackrabbit.test.api.NodeOrderableChildNodesTest#testOrderBeforeUnsupportedRepositoryOperationException >> >> nt:hierarchyNode used as primary node type. >> >> By specification( 3.7.10.1 nt:base and 3.7.11.1 nt:hierarchyNode) >> this node types is an abstract node types. In section >> 3.7.1.3 written what abstract node types cannot be directly >> assigned to a node. >> >> Is the tests correct? > > no, they are not, but it should have been fixed some time ago. See > issue JCR-2159. > >> 2. Test NodeNameTest check correct comparation NAME() with a different >> type of values. In some cases it expect InvalidQueryException. But >> section 6.7.16 Comparison >> of specification is not clear about when should it be. Can you clarify >> what comparation a possible and what not? > > It says: > > "If operand1 and operand2 evaluate to values of different property types, > the value of operand2 is converted to the property type of the value of > operand1 as described in §3.6.4 Property Type Conversion. If the type > conversion fails, the query is invalid." > > an then it depends on the type of operand2. e.g. in > testStringLiteralInvalidName > operand2 is a STRING that needs to be converted to NAME. therefore > 3.6.4.1 applies with: > > "NAME: If the string is a syntactically valid qualified JCR name with > a registered > prefix, it is converted directly. If it is a syntactically valid > expanded JCR name > with a registered namespace URI, it is returned in qualified form. If it is a > syntactically valid expanded JCR name with an unregistered namespace > URI, a prefix is created automatically, the mapping added to the local > namespace mappings (see §3.5.2 Session-Local Mappings), and the name > is returned in qualified form. Otherwise a ValueFormatException is thrown." > >> 3. Tests >> org.apache.jackrabbit.test.api.query.qom.NodeNameTest#testLongLiteral >> org.apache.jackrabbit.test.api.query.qom.NodeNameTest#testBooleanLiteral >> compared with NAME() without CAST. Is the tests correct? > > After reading the relevant spec section, I think those are not > correct. In 6.7.34 it says: > > "An UncastLiteral is always interpreted as a Value of property type STRING. > A CastLiteral, on the other hand, is interpreted as the string form of a Value > of the PropertyType indicated." > > I created a jira issue: https://issues.apache.org/jira/browse/JCR-2282 > >> 4. Test >> org.apache.jackrabbit.test.api.query.qom.SelectorTest#testUnknownNodeType >> have constrain fail("Selector with unknown node type must throw >> InvalidQueryException") >> but by specefication if nodeType is a valid JCR name but not the >> name of a node type available in the >> repository, the query is valid but the selector selects no nodes. >> Is the test correct? > > This was discussed in the EG and consensus was that the query should be > invalid. the changes made it into the spec but were later accidentally > reverted. > > See: https://jsr-283.dev.java.net/issues/show_bug.cgi?id=764 > >> 5. What should return property.getDefaultValues() for mix:etag node >> type to satisfy >> org.apache.jackrabbit.test.api.nodetype.PredefinedNodeTypeTest#testMixETag >> test? > > hmm, I'm not sure about this one. But I guess the mix-etag.txt is wrong. > > jackrabbits built-in node types has a comment: > > [mix:etag] > mixin > // currently has a default value because auto-creation not handled > see JCR-2116 > - jcr:etag (STRING) = '' protected autocreated > > which is not in sync with the spec. there it says: > > [mix:etag] mixin > - jcr:etag (STRING) protected autocreated > > I've created a jira issue for that: > http://issues.apache.org/jira/browse/JCR-2283 > > regards > marcel > >> Question appeared because null value or empty array can't be >> matched as expected >> in mix-etag.txt file. >> >> Thanks. >> >> Sergey Kabashnyuk >> eXo Platform SAS >> >> 2009/6/19 Alexander Klimetschek <[email protected]>: >>> On Fri, Jun 19, 2009 at 2:49 PM, Sergey Kabashnyuk<[email protected]> >>> wrote: >>>> Can you give me the link to the issue? >>> >>> https://jsr-283.dev.java.net/issues/show_bug.cgi?id=787 >>> >>> Regards, >>> Alex >>> >>> -- >>> Alexander Klimetschek >>> [email protected] >>> >> >
