jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: jackrabbit-jcr-tests questions
Date Thu, 27 Aug 2009 09:29:37 GMT

On Tue, Aug 25, 2009 at 12:05, Sergey Kabashnyuk<ksmmlist@gmail.com> 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(  nt:base  and nt:hierarchyNode)
>   this node types is an abstract node types. In section
> 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 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:

  // 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:


>   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 <aklimets@day.com>:
>> On Fri, Jun 19, 2009 at 2:49 PM, Sergey Kabashnyuk<ksmmlist@gmail.com> 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
>> alexander.klimetschek@day.com

View raw message