jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Kabashnyuk <ksmml...@gmail.com>
Subject Re: jackrabbit-jcr-tests questions
Date Thu, 27 Aug 2009 10:20:20 GMT
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 <marcel.reutegger@gmx.net>:
> Hi,
>
> 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( 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 <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
>>>
>>
>

Mime
View raw message