From jira-events at lists.jboss.org  Mon Mar  2 04:22:58 2009
From: jira-events at lists.jboss.org (Serge Emmanuel Pagop (JIRA))
Date: Mon, 2 Mar 2009 04:22:58 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-240) code test case for
 SVNRepositoryConnection used  for connection
In-Reply-To: <31126753.1224577100902.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14190630.1235985778419.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12454898#action_12454898 ] 

Serge Emmanuel Pagop commented on DNA-240:
------------------------------------------

We need also to extend svn connector with workspace features just like in file system connector. Discussion is opened.

> code test case for SVNRepositoryConnection used  for connection
> ---------------------------------------------------------------
>
>                 Key: DNA-240
>                 URL: https://jira.jboss.org/jira/browse/DNA-240
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Serge Emmanuel Pagop
>            Assignee: Serge Emmanuel Pagop
>             Fix For: 0.4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar  2 04:22:58 2009
From: jira-events at lists.jboss.org (Serge Emmanuel Pagop (JIRA))
Date: Mon, 2 Mar 2009 04:22:58 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-239) code test case for
 SVNRepositorySource used to manage the repos. content
In-Reply-To: <1909384.1224576860902.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26289717.1235985778466.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12454899#action_12454899 ] 

Serge Emmanuel Pagop commented on DNA-239:
------------------------------------------

We need also to extend svn connector with workspace features just like in file system connector. Discussion is opened.

> code test case for SVNRepositorySource used to manage the repos. content
> ------------------------------------------------------------------------
>
>                 Key: DNA-239
>                 URL: https://jira.jboss.org/jira/browse/DNA-239
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Serge Emmanuel Pagop
>            Assignee: Serge Emmanuel Pagop
>             Fix For: 0.4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar  2 10:55:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 2 Mar 2009 10:55:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-240) code test case for
 SVNRepositoryConnection used  for connection
In-Reply-To: <31126753.1224577100902.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28513811.1236009322321.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12454979#action_12454979 ] 

Randall Hauch commented on DNA-240:
-----------------------------------

I'll add some thoughts, since I've written the workspace support for other connectors.

There are a couple of useful things around the concept of DNA workspaces (which follow JCR workspaces, btw).  The first is that a single RepositorySource can "contain" (or expose) one or more workspaces to the rest of the system; the available workspaces are returned in the GetWorkspacesRequest.  The second is that the workspaces in a source can either be fixed or variable; there is a connector capability that says whether the connector can create workspaces, and the source can support the CreateWorkspaceRequest, DestroyWorkspaceRequest, and CloneWorkspaceRequest commands.  The third is that sources typically have a "default" workspace that is used when the VerifyWorkspaceRequest contains null for the workspace name.  

Finally, there is the notion about how the content of workspaces are related to each other.  Basically, workspaces are independent, but it is possible that a node in one workspace has what JCR calls "corresponding nodes" in other workspaces.  You can think of these as a node in one workspace that has the same identity (e.g., UUID) as a node in another workspace.  All other aspects of these nodes (e.g., properties, children, etc.) are independent.

So, given these characteristics, it seems to make sense that a DNA workspace maps pretty well to an SVN branch/tag.  This is especially true given that a file in one branch may also "correspond to" a file in a different branch.  So, assuming the SVN repository uses the "convention" of a "trunk", "branches" and "tags" folder structure, then there would be one workspace for "trunk", and one workspace for each branch and each tag.  The default workspace would be "trunk" (meaning that processing a VerifyWorkspaceRequest would treat a null workspace name as if it were "trunk").  Although it'd be possible for the connector to allow creating workspaces, in the short term all I think we need/want is the ability for the connector to expose the existing trunk, branches and tags.  Therefore, the connector capabilities would say that no workspaces can be created, and the processing of the CreateWorkspaceRequest, DestroyWorkspaceRequest, and CloneWorkspaceRequest would throw exceptions.  (Note that if we would want to allow the connector to create new branches or tags, then these requests map pretty closely to the kinds of SVN operations to create a branch/tag.)  Finally, the GetWorkspacesRequest would simply return the names of the branches, tags and "trunk".  BTW, in order to make the workspace name more meaningful to the user, the connector could use a convention where the workspace names could follow a pattern; e.g., "branch/xyz" where "xyz" is the actual branch name, and "tag/abc" where "abc" is the actual name of the tag.

The SVNRepositorySource could also be configured to restrict the workspace names that should be exposed.  For example, this could be done as a single String[] property (see FileSystemSource.getPredefinedWorkspaceNames) of workspace names, or it could be done using more SVN terminology:  a String[] exposedBranches, a String[] exposedTags, and a boolean exposeTrunk.  This is just one suggestion; there certainly are other good possibilities.



> code test case for SVNRepositoryConnection used  for connection
> ---------------------------------------------------------------
>
>                 Key: DNA-240
>                 URL: https://jira.jboss.org/jira/browse/DNA-240
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Serge Emmanuel Pagop
>            Assignee: Serge Emmanuel Pagop
>             Fix For: 0.4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Mon Mar  2 12:43:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 2 Mar 2009 12:43:23 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-91) Implement node type
	management
In-Reply-To: <33272333.1212431842222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31019993.1236015803106.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455010#action_12455010 ] 

Randall Hauch commented on DNA-91:
----------------------------------

Applied the "DNA-91_Full" patch, which looks very good. 

The only question is whether the JcrNodeType implementation methods (e.g., the 'can*' methods) should check the supertypes in addition to the node type?

> Implement node type management
> ------------------------------
>
>                 Key: DNA-91
>                 URL: https://jira.jboss.org/jira/browse/DNA-91
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>    Affects Versions: 0.2
>            Reporter: Randall Hauch
>            Assignee: Johnny Verhaeg
>             Fix For: 0.4
>
>         Attachments: DNA-91_Full.patch, DNA-91_Prelim.patch, DNA-91_With_Builtins.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar  2 12:43:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 2 Mar 2009 12:43:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-91) Implement node type
	management
In-Reply-To: <33272333.1212431842222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4616705.1236015802515.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455009#action_12455009 ] 

Randall Hauch commented on DNA-91:
----------------------------------

Applied the patch, which looks very good.  

The only question is whether the JcrNodeType implementation methods (e.g., the 'can*' methods) should check the supertypes in addition to the node type?

> Implement node type management
> ------------------------------
>
>                 Key: DNA-91
>                 URL: https://jira.jboss.org/jira/browse/DNA-91
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>    Affects Versions: 0.2
>            Reporter: Randall Hauch
>            Assignee: Johnny Verhaeg
>             Fix For: 0.4
>
>         Attachments: DNA-91_Full.patch, DNA-91_Prelim.patch, DNA-91_With_Builtins.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar  2 12:43:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 2 Mar 2009 12:43:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-91) Implement node type
	management
In-Reply-To: <33272333.1212431842222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28756640.1236015802656.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-91:
-----------------------------

    Comment: was deleted


> Implement node type management
> ------------------------------
>
>                 Key: DNA-91
>                 URL: https://jira.jboss.org/jira/browse/DNA-91
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>    Affects Versions: 0.2
>            Reporter: Randall Hauch
>            Assignee: Johnny Verhaeg
>             Fix For: 0.4
>
>         Attachments: DNA-91_Full.patch, DNA-91_Prelim.patch, DNA-91_With_Builtins.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar  2 15:07:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 2 Mar 2009 15:07:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-286) Implement namespace
	management
In-Reply-To: <23913041.1235603864149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1160516.1236024442516.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-286.
-------------------------------

    Resolution: Done


This change corrects the behavior of the Session's namespace-related methods, which are not the same as those in the NamespaceRegistry implementation associated with the workspace.  This also corrected several of the TCK tests associated with namespaces.

Note that the StringValueFactory in 'dna-graph' was changed to use a DNA namespace registry to convert a Name and Path to a string using the namespace prefixes.  (This change affected a number of unit tests.)  The result is that any Name and Path property values are treated correctly and properly converted to a string using the current namespace prefixes in the namespace registry.  However, the BinaryValueFactory implementations should not use this StringValueFactory, since they need to convert values using the non-prefixed form (that is, the namespace URI).

In the case of our JCR implementation, the above change to the Graph factories means that property values are properly mapped to strings using the Session's local mappings (which fall back on the Workspace's mappings).  This corrected at least one TCK test.

I believe this addresses all the concerns documented above.  Therefore, marking as resolved.  But as always, if this is not true, please reopen.

> Implement namespace management
> ------------------------------
>
>                 Key: DNA-286
>                 URL: https://jira.jboss.org/jira/browse/DNA-286
>             Project: DNA
>          Issue Type: Sub-task
>          Components: API, JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-286.patch
>
>
> Our JCR implementation needs a namespace registry that stores the namespaces and their prefixes in such a way that they can be clustered.  The best approach is probably to store the namespaces under "/jcr:system/" in a DNA-specific location (as the JCR spec does not specify that the namespaces are available as content.  By doing this, the namespace registry would automatically work across a cluster (any clients that are using the same RepositorySource).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 10:33:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 3 Mar 2009 10:33:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-287)
 AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
Message-ID: <27699021.1236094402293.JavaMail.jira@cloud.prod.atl2.jboss.com>

AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
----------------------------------------------------------------

                 Key: DNA-287
                 URL: https://jira.jboss.org/jira/browse/DNA-287
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers
         Attachments: DNA-287.patch

AbstractJcrNode.getDepth(int depth) treats depth parameter as a relative depth.  That is, getDepth(0) returns the current node.  According to spec, getDepth(0) should return the root node and getDepth(n) should return the current node if the current node's depth is n.

Also, the spec indicates that the method should throw an ItemNotFoundException if the depth parameter is negative.  The current code throws an IllegalArgumentException.

Fixing this behavior allows a few more TCK tests to pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 10:33:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 3 Mar 2009 10:33:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-287)
 AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
In-Reply-To: <27699021.1236094402293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6914500.1236094402344.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-287:
--------------------------------

    Attachment: DNA-287.patch


Fixes the behavior of the getDepth method.

> AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
> ----------------------------------------------------------------
>
>                 Key: DNA-287
>                 URL: https://jira.jboss.org/jira/browse/DNA-287
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-287.patch
>
>
> AbstractJcrNode.getDepth(int depth) treats depth parameter as a relative depth.  That is, getDepth(0) returns the current node.  According to spec, getDepth(0) should return the root node and getDepth(n) should return the current node if the current node's depth is n.
> Also, the spec indicates that the method should throw an ItemNotFoundException if the depth parameter is negative.  The current code throws an IllegalArgumentException.
> Fixing this behavior allows a few more TCK tests to pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 12:30:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 3 Mar 2009 12:30:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-287)
 AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
In-Reply-To: <27699021.1236094402293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15414220.1236101422484.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-287:
--------------------------------

    Attachment: DNA-287.patch


The property implementation had the same issue.  This patch also corrects getAncestor behavior for properties by hoisting the correct implementation into AbstractJcrItem and removing the node- and property-specific getDepth and getAncestor implementations.

> AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
> ----------------------------------------------------------------
>
>                 Key: DNA-287
>                 URL: https://jira.jboss.org/jira/browse/DNA-287
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-287.patch, DNA-287.patch
>
>
> AbstractJcrNode.getDepth(int depth) treats depth parameter as a relative depth.  That is, getDepth(0) returns the current node.  According to spec, getDepth(0) should return the root node and getDepth(n) should return the current node if the current node's depth is n.
> Also, the spec indicates that the method should throw an ItemNotFoundException if the depth parameter is negative.  The current code throws an IllegalArgumentException.
> Fixing this behavior allows a few more TCK tests to pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 12:52:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 3 Mar 2009 12:52:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-288) JcrRepository.login
 Does Not Match JCR 1.0 Specification
Message-ID: <995733.1236102742410.JavaMail.jira@cloud.prod.atl2.jboss.com>

JcrRepository.login Does Not Match JCR 1.0 Specification
--------------------------------------------------------

                 Key: DNA-288
                 URL: https://jira.jboss.org/jira/browse/DNA-288
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers
            Priority: Minor


According to the spec, attempts to log in to an unrecognized workspace should result in a NoSuchWorkspaceException being thrown.  Currently, the JcrRepository first attempts to create the named workspace and only throws an exception if creation fails.

Fixing this behavior allows a TCK test to pass.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 13:47:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 3 Mar 2009 13:47:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-288) JcrRepository.login
 Does Not Match JCR 1.0 Specification
In-Reply-To: <995733.1236102742410.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29303903.1236106042321.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-288:
--------------------------------

    Attachment: DNA-288.patch


Attached patch that changes behavior when logging in to named workspace that does not already exist

> JcrRepository.login Does Not Match JCR 1.0 Specification
> --------------------------------------------------------
>
>                 Key: DNA-288
>                 URL: https://jira.jboss.org/jira/browse/DNA-288
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Priority: Minor
>         Attachments: DNA-288.patch
>
>
> According to the spec, attempts to log in to an unrecognized workspace should result in a NoSuchWorkspaceException being thrown.  Currently, the JcrRepository first attempts to create the named workspace and only throws an exception if creation fails.
> Fixing this behavior allows a TCK test to pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 14:22:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 3 Mar 2009 14:22:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-288) JcrRepository.login
 Does Not Match JCR 1.0 Specification
In-Reply-To: <995733.1236102742410.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1375467.1236108142349.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-288.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Applied the patch that corrects the behavior when the workspace name submitted to the login method does not match the name of an existing workspace.  The patch also adds to the JCR TCK tests.

> JcrRepository.login Does Not Match JCR 1.0 Specification
> --------------------------------------------------------
>
>                 Key: DNA-288
>                 URL: https://jira.jboss.org/jira/browse/DNA-288
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>            Priority: Minor
>         Attachments: DNA-288.patch
>
>
> According to the spec, attempts to log in to an unrecognized workspace should result in a NoSuchWorkspaceException being thrown.  Currently, the JcrRepository first attempts to create the named workspace and only throws an exception if creation fails.
> Fixing this behavior allows a TCK test to pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 15:36:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 3 Mar 2009 15:36:23 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-287)
 AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
In-Reply-To: <27699021.1236094402293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5910666.1236112583192.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-287.
-------------------------------

    Resolution: Done


Applied the patch that corrects the behavior of get ancestor, which per the spec is absolute and not relative (as was implemented).

> AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
> ----------------------------------------------------------------
>
>                 Key: DNA-287
>                 URL: https://jira.jboss.org/jira/browse/DNA-287
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-287.patch, DNA-287.patch
>
>
> AbstractJcrNode.getDepth(int depth) treats depth parameter as a relative depth.  That is, getDepth(0) returns the current node.  According to spec, getDepth(0) should return the root node and getDepth(n) should return the current node if the current node's depth is n.
> Also, the spec indicates that the method should throw an ItemNotFoundException if the depth parameter is negative.  The current code throws an IllegalArgumentException.
> Fixing this behavior allows a few more TCK tests to pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 15:36:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 3 Mar 2009 15:36:23 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-287)
 AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
In-Reply-To: <27699021.1236094402293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23387847.1236112583288.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch reassigned DNA-287:
---------------------------------

    Assignee: Randall Hauch


> AbstractJcrNode.getAncestor Does Not Match JCR 1.0 Specification
> ----------------------------------------------------------------
>
>                 Key: DNA-287
>                 URL: https://jira.jboss.org/jira/browse/DNA-287
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>         Attachments: DNA-287.patch, DNA-287.patch
>
>
> AbstractJcrNode.getDepth(int depth) treats depth parameter as a relative depth.  That is, getDepth(0) returns the current node.  According to spec, getDepth(0) should return the root node and getDepth(n) should return the current node if the current node's depth is n.
> Also, the spec indicates that the method should throw an ItemNotFoundException if the depth parameter is negative.  The current code throws an IllegalArgumentException.
> Fixing this behavior allows a few more TCK tests to pass.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 16:16:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 3 Mar 2009 16:16:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-289) AbstractJcrItem.isSame
 Does Not Match JCR 1.0 Specification
Message-ID: <11393145.1236114982445.JavaMail.jira@cloud.prod.atl2.jboss.com>

AbstractJcrItem.isSame Does Not Match JCR 1.0 Specification
-----------------------------------------------------------

                 Key: DNA-289
                 URL: https://jira.jboss.org/jira/browse/DNA-289
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers


AbstractJcrItem.isSame currently compares the two items based on reference equality of their workspaces.  According to spec, it should compare them based on reference equality of their repositories and logical equality of their workspace names.

Fixing this will correct three TCK test failures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 16:18:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 3 Mar 2009 16:18:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-289) AbstractJcrItem.isSame
 Does Not Match JCR 1.0 Specification
In-Reply-To: <11393145.1236114982445.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20920228.1236115102566.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-289:
--------------------------------

    Attachment: DNA-289.patch


Attached patch that modifies AbstractJcrItem.isSame behavior to adhere to spec.  Behavior in node and property implementations was already correct per spec.

> AbstractJcrItem.isSame Does Not Match JCR 1.0 Specification
> -----------------------------------------------------------
>
>                 Key: DNA-289
>                 URL: https://jira.jboss.org/jira/browse/DNA-289
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-289.patch
>
>
> AbstractJcrItem.isSame currently compares the two items based on reference equality of their workspaces.  According to spec, it should compare them based on reference equality of their repositories and logical equality of their workspace names.
> Fixing this will correct three TCK test failures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 19:28:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 3 Mar 2009 19:28:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-290) Getting child nodes or
 properties by pattern is not implemented
Message-ID: <26766222.1236126502277.JavaMail.jira@cloud.prod.atl2.jboss.com>

Getting child nodes or properties by pattern is not implemented
---------------------------------------------------------------

                 Key: DNA-290
                 URL: https://jira.jboss.org/jira/browse/DNA-290
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.4


AbstractJcrNode.getNodes(String pattern) and getProperties(String pattern) methods are not implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 19:37:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 3 Mar 2009 19:37:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-290) Getting child nodes
 or properties by pattern is not implemented
In-Reply-To: <26766222.1236126502277.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12946117.1236127042276.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-290.
-------------------------------

    Resolution: Done


Implemented the AbstractJcrNode.getNodes(String pattern) and AbstractJcrNode.getProperties(String pattern), which makes a few more of the JCR TCK tests pass.  In the process, the way AbstractJcrNode stores children was (dramatically) simplified, and a few different kinds of NodeIterator and PropertyIterator implementations were added (including empty ones).

Also changed how DNA Path.Segment objects are created when no SNS index is specified, so the objects are now created with an index of 1 rather than -1.  This was done because it was leaking -1 in some cases, and it also more closely aligns with JCR.  Found and corrected minor related bugs in a few test cases.

> Getting child nodes or properties by pattern is not implemented
> ---------------------------------------------------------------
>
>                 Key: DNA-290
>                 URL: https://jira.jboss.org/jira/browse/DNA-290
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> AbstractJcrNode.getNodes(String pattern) and getProperties(String pattern) methods are not implemented.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar  3 19:56:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 3 Mar 2009 19:56:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-289)
 AbstractJcrItem.isSame Does Not Match JCR 1.0 Specification
In-Reply-To: <11393145.1236114982445.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8962978.1236128182504.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-289.
-------------------------------

    Fix Version/s: 0.4
       Resolution: Done
         Assignee: Randall Hauch


Applied the patch.  One test had to be updated (minor issue), since it was updated for DNA-290 after the patch was uploaded.  Also added another JCR TCK unit test to the mix, since all of its test methods were passing.

> AbstractJcrItem.isSame Does Not Match JCR 1.0 Specification
> -----------------------------------------------------------
>
>                 Key: DNA-289
>                 URL: https://jira.jboss.org/jira/browse/DNA-289
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-289.patch
>
>
> AbstractJcrItem.isSame currently compares the two items based on reference equality of their workspaces.  According to spec, it should compare them based on reference equality of their repositories and logical equality of their workspace names.
> Fixing this will correct three TCK test failures.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 13:57:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 13:57:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-291) JCR property objects
 do not have PropertyDefinition
Message-ID: <10115749.1236193042280.JavaMail.jira@cloud.prod.atl2.jboss.com>

JCR property objects do not have PropertyDefinition
---------------------------------------------------

                 Key: DNA-291
                 URL: https://jira.jboss.org/jira/browse/DNA-291
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.4


Our JCR Property objects are not properly initialized with a valid PropertyDefinition.  Per the JSR-170 spec, each Property must have a PropertyDefinition.  I think when first implemented, we didn't have a NodeTypeManager implementation, so this was not really possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 14:09:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 14:09:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-291) JCR property objects
 do not have PropertyDefinition
In-Reply-To: <10115749.1236193042280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24666762.1236193762291.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455480#action_12455480 ] 

Randall Hauch commented on DNA-291:
-----------------------------------

Restructured how our Property implementations create Value objects, since the Value objects cannot be cached in the Property.  Section 6.2.7 of JSR-170 says that Value objects can become unusable after Value.getStream() is called, and the proper procedure in this case is for the client to get a new Value object.  Therefore Property objects have to be able to re-create new Value objects.

This change led me to look more into how JcrAbstractProperty, JcrProperty, and JcrMultiValueProperty are implemented.  I was able to simplify them quite a bit by having them hold onto the DNA Property instance, and to pass in the PropertyDefinition into the constructor.  Several other errors were found in the current code, including "Property.getNode()" does not return the parent node that owns the property (that's "Property.getParent()"), but should instead return the node pointed to by the reference property value.

The JcrSession.populateNode(...) method was also refactored to validate the DNA graph node using the primary node type and mixin types, and to find and associate the appropriate PropertyDefinition with each of the node's properties.

All of these changes had a fairly large impact on the unit tests for these classes, so these were fixed.  Note that any test methods that check for AssertionException is not a valid test (as the tests should be able be run without assertions enabled to verify the behavior is still correct).  

Also enabled several JCR TCK tests, since we're now passing all of their test methods.  Not too many remain for JCR Level 1 compliance!

> JCR property objects do not have PropertyDefinition
> ---------------------------------------------------
>
>                 Key: DNA-291
>                 URL: https://jira.jboss.org/jira/browse/DNA-291
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Our JCR Property objects are not properly initialized with a valid PropertyDefinition.  Per the JSR-170 spec, each Property must have a PropertyDefinition.  I think when first implemented, we didn't have a NodeTypeManager implementation, so this was not really possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 14:11:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 14:11:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-291) JCR property objects
 do not have PropertyDefinition
In-Reply-To: <10115749.1236193042280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25748110.1236193882287.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455481#action_12455481 ] 

Randall Hauch commented on DNA-291:
-----------------------------------

Renamed JcrProperty to JcrSingleValueProperty to more closely match the existing JcrMultiValueProperty and reduce confusion.

> JCR property objects do not have PropertyDefinition
> ---------------------------------------------------
>
>                 Key: DNA-291
>                 URL: https://jira.jboss.org/jira/browse/DNA-291
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Our JCR Property objects are not properly initialized with a valid PropertyDefinition.  Per the JSR-170 spec, each Property must have a PropertyDefinition.  I think when first implemented, we didn't have a NodeTypeManager implementation, so this was not really possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 14:40:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 14:40:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-291) JCR property objects
 do not have PropertyDefinition
In-Reply-To: <10115749.1236193042280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10645786.1236195622497.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455483#action_12455483 ] 

Randall Hauch commented on DNA-291:
-----------------------------------

Changed the JcrSession.populateNode(...) method to look for "*" property definitions in the primary type or mixins' NodeType, and to use that for properties for which there is no explicit property defintion.

> JCR property objects do not have PropertyDefinition
> ---------------------------------------------------
>
>                 Key: DNA-291
>                 URL: https://jira.jboss.org/jira/browse/DNA-291
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Our JCR Property objects are not properly initialized with a valid PropertyDefinition.  Per the JSR-170 spec, each Property must have a PropertyDefinition.  I think when first implemented, we didn't have a NodeTypeManager implementation, so this was not really possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 14:42:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 14:42:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-291) JCR property objects
 do not have PropertyDefinition
In-Reply-To: <10115749.1236193042280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27477555.1236195742376.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-291.
-------------------------------

    Resolution: Done


This problem has been addressed, so based upon the TCK unit tests and the DNA unit tests, I'm marking this as resolved.

> JCR property objects do not have PropertyDefinition
> ---------------------------------------------------
>
>                 Key: DNA-291
>                 URL: https://jira.jboss.org/jira/browse/DNA-291
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Our JCR Property objects are not properly initialized with a valid PropertyDefinition.  Per the JSR-170 spec, each Property must have a PropertyDefinition.  I think when first implemented, we didn't have a NodeTypeManager implementation, so this was not really possible.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 16:02:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 4 Mar 2009 16:02:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-292) System View Creates
 Nodes With Primary Type That Is Not Defined in Type Load
Message-ID: <917947.1236200542313.JavaMail.jira@cloud.prod.atl2.jboss.com>

System View Creates Nodes With Primary Type That Is Not Defined in Type Load
----------------------------------------------------------------------------

                 Key: DNA-292
                 URL: https://jira.jboss.org/jira/browse/DNA-292
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers


DNA stores persistently mapped namespaces (including built-in namespaces like "sv", "nt") in a system view within the content graph.  The nodes storing the data have a primaryType of dna:namespace.  DNA does not currently have a type source (e.g., BuiltInTypeSource) that defines this type, so the org.apache.jackrabbit.test.api.nodetype.NodeTypeTest.testGetPrimaryItemName test case fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 16:06:40 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 16:06:40 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-293) JcrSession creates
 Property
 instances that use the PropertyType.UNDEFINED, which is not allowed
Message-ID: <16405064.1236200800201.JavaMail.jira@cloud.prod.atl2.jboss.com>

JcrSession creates Property instances that use the PropertyType.UNDEFINED, which is not allowed
-----------------------------------------------------------------------------------------------

                 Key: DNA-293
                 URL: https://jira.jboss.org/jira/browse/DNA-293
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.4


The "undefined" property type is only allowed in property definitions.  According to the JSR-170 specification (Section, 6.2.5):

    "This constant can be used within a property definition (see 6.7.6 Property Definitions) to specify that the property in 
    question may be of any type. However, it cannot be the actual type of any property instance. For example it will 
    never be returned by Property.getType and (in level 2 implementations) it cannot be assigned as the type when 
    creating a new property."

When the property definition has a type of "undefined", then we'll need to choose what actual type to use.  There doesn't appear to be any guidance on this in the spec (anybody?), so barring that the most logical approach is probably to look at the first property value.  

Note that this is one reason why the DNA graph API was designed with the value factories to allow (or encourage) the client to convert the property values to the type desired by the client.  Because of this, it doesn't matter so much what type the value actually is, but rather that it can be converted to the type needed by the user.  So this should make the above assumption (about choosing the property type based upon value) a pretty decent one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 16:18:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 16:18:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-293) JcrSession creates
 Property
 instances that use the PropertyType.UNDEFINED, which is not allowed
In-Reply-To: <16405064.1236200800201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15735930.1236201502280.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455505#action_12455505 ] 

Randall Hauch commented on DNA-293:
-----------------------------------

Actually, I just found this in Section 8.5.2.9 of the JSR-170 spec (which is Section 7.5.2.9 of the draft JSR-283 spec), which is about how to deal with property values in SQL queries when the property definition's type is "undefined":

    "When a node type T defines a property P with an UNDEFINED property type this means that two 
    node instances of type T can each have a property called P but with differing property types. 
    In such cases the database view of T is a single column of type VARCHAR (see below). In other 
    words, the different types are converted to strings."

I'm not sure whether this is a better strategy for choosing the actual property type for a Property instance.  It is likely that the SQL query functionality needs to use the PropertyDefinition objects (without the luxury of actual Property instances) to plan queries.


> JcrSession creates Property instances that use the PropertyType.UNDEFINED, which is not allowed
> -----------------------------------------------------------------------------------------------
>
>                 Key: DNA-293
>                 URL: https://jira.jboss.org/jira/browse/DNA-293
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The "undefined" property type is only allowed in property definitions.  According to the JSR-170 specification (Section, 6.2.5):
>     "This constant can be used within a property definition (see 6.7.6 Property Definitions) to specify that the property in 
>     question may be of any type. However, it cannot be the actual type of any property instance. For example it will 
>     never be returned by Property.getType and (in level 2 implementations) it cannot be assigned as the type when 
>     creating a new property."
> When the property definition has a type of "undefined", then we'll need to choose what actual type to use.  There doesn't appear to be any guidance on this in the spec (anybody?), so barring that the most logical approach is probably to look at the first property value.  
> Note that this is one reason why the DNA graph API was designed with the value factories to allow (or encourage) the client to convert the property values to the type desired by the client.  Because of this, it doesn't matter so much what type the value actually is, but rather that it can be converted to the type needed by the user.  So this should make the above assumption (about choosing the property type based upon value) a pretty decent one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 16:27:06 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 16:27:06 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-293) JcrSession creates
 Property
 instances that use the PropertyType.UNDEFINED, which is not allowed
In-Reply-To: <16405064.1236200800201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11071147.1236202026737.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455506#action_12455506 ] 

Randall Hauch commented on DNA-293:
-----------------------------------

I guess one argument for using PropertyType.STRING as the property type is that every property value can be converted to a String, meaning that if the property has multiple values of differing types, and code is using Property.getType() to determine how to deal with the value, they'd expect a String and always get a value.  If, however, Property.getType() returned PropertyType.URI but there was a value that didn't convert to a URI (for example, maybe a String containing a malformed URI), they'd get a ValueFormatException.

So, given this, should we just use PropertyType.STRING as the default?  Maybe.  Thoughts?

> JcrSession creates Property instances that use the PropertyType.UNDEFINED, which is not allowed
> -----------------------------------------------------------------------------------------------
>
>                 Key: DNA-293
>                 URL: https://jira.jboss.org/jira/browse/DNA-293
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The "undefined" property type is only allowed in property definitions.  According to the JSR-170 specification (Section, 6.2.5):
>     "This constant can be used within a property definition (see 6.7.6 Property Definitions) to specify that the property in 
>     question may be of any type. However, it cannot be the actual type of any property instance. For example it will 
>     never be returned by Property.getType and (in level 2 implementations) it cannot be assigned as the type when 
>     creating a new property."
> When the property definition has a type of "undefined", then we'll need to choose what actual type to use.  There doesn't appear to be any guidance on this in the spec (anybody?), so barring that the most logical approach is probably to look at the first property value.  
> Note that this is one reason why the DNA graph API was designed with the value factories to allow (or encourage) the client to convert the property values to the type desired by the client.  Because of this, it doesn't matter so much what type the value actually is, but rather that it can be converted to the type needed by the user.  So this should make the above assumption (about choosing the property type based upon value) a pretty decent one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 16:59:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 16:59:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-293) JcrSession creates
 Property
 instances that use the PropertyType.UNDEFINED, which is not allowed
In-Reply-To: <16405064.1236200800201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2786182.1236203962286.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455514#action_12455514 ] 

Randall Hauch commented on DNA-293:
-----------------------------------

Changed JcrSession.populateNode(...) to never use PropertyType.UNDEFINED for the actual property type on a property.  This means that even though UNDEFINED is allows on PropertyDefinition, it is not allowed on an actual Property instance.  Therefore, I added the actual property type as an int field to JcrAbstractProperty, and modified the subclasses and the code where the constructors are called (mostly JcrSession and unit tests).

The current choice is to use PropertyType.STRING, since all property values can be converted to a String.  See the issue for more details and a discussion of this logic.

> JcrSession creates Property instances that use the PropertyType.UNDEFINED, which is not allowed
> -----------------------------------------------------------------------------------------------
>
>                 Key: DNA-293
>                 URL: https://jira.jboss.org/jira/browse/DNA-293
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The "undefined" property type is only allowed in property definitions.  According to the JSR-170 specification (Section, 6.2.5):
>     "This constant can be used within a property definition (see 6.7.6 Property Definitions) to specify that the property in 
>     question may be of any type. However, it cannot be the actual type of any property instance. For example it will 
>     never be returned by Property.getType and (in level 2 implementations) it cannot be assigned as the type when 
>     creating a new property."
> When the property definition has a type of "undefined", then we'll need to choose what actual type to use.  There doesn't appear to be any guidance on this in the spec (anybody?), so barring that the most logical approach is probably to look at the first property value.  
> Note that this is one reason why the DNA graph API was designed with the value factories to allow (or encourage) the client to convert the property values to the type desired by the client.  Because of this, it doesn't matter so much what type the value actually is, but rather that it can be converted to the type needed by the user.  So this should make the above assumption (about choosing the property type based upon value) a pretty decent one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 17:01:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 17:01:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-293) JcrSession creates
 Property
 instances that use the PropertyType.UNDEFINED, which is not allowed
In-Reply-To: <16405064.1236200800201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22995292.1236204082519.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455515#action_12455515 ] 

Randall Hauch commented on DNA-293:
-----------------------------------

I'm not marking this as resolved just yet, in the hopes that this logic will be reviewed by some others.

> JcrSession creates Property instances that use the PropertyType.UNDEFINED, which is not allowed
> -----------------------------------------------------------------------------------------------
>
>                 Key: DNA-293
>                 URL: https://jira.jboss.org/jira/browse/DNA-293
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The "undefined" property type is only allowed in property definitions.  According to the JSR-170 specification (Section, 6.2.5):
>     "This constant can be used within a property definition (see 6.7.6 Property Definitions) to specify that the property in 
>     question may be of any type. However, it cannot be the actual type of any property instance. For example it will 
>     never be returned by Property.getType and (in level 2 implementations) it cannot be assigned as the type when 
>     creating a new property."
> When the property definition has a type of "undefined", then we'll need to choose what actual type to use.  There doesn't appear to be any guidance on this in the spec (anybody?), so barring that the most logical approach is probably to look at the first property value.  
> Note that this is one reason why the DNA graph API was designed with the value factories to allow (or encourage) the client to convert the property values to the type desired by the client.  Because of this, it doesn't matter so much what type the value actually is, but rather that it can be converted to the type needed by the user.  So this should make the above assumption (about choosing the property type based upon value) a pretty decent one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 17:10:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 17:10:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-293) JcrSession creates
 Property
 instances that use the PropertyType.UNDEFINED, which is not allowed
In-Reply-To: <16405064.1236200800201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4304765.1236204622280.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455517#action_12455517 ] 

Randall Hauch commented on DNA-293:
-----------------------------------

Actually, Section 6.2.4 of JSR-170 describes the Property.getType() method as follows:

    "Returns the type of this Property. The type returned is that which was set at property creation. Note that 
    for some property p, the type returned by p.getType() may differ from the type returned by 
    p.getDefinition.getRequiredType() only in the case where the latter returns UNDEFINED. The type of 
    a property instance is never UNDEFINED (it must always have some actual type). See 6.2.5 Property 
    Types and 6.7.18 Discovery of Constraints on Existing Items."

To me, this means that the PropertyType is set when the Property instance is created, and should define how the property values are stored on the graph (e.g., any values should be converted to that type as they're set, as long as the type is the same as the PropertyDefinition's required type or, if that is UNDEFINED, then any type).  Therefore, when reading the node back in from the DNA graph, I think we should base the PropertyType on the first value, since we would have chose the kind of value to match the client-supplied property type.  So, changing the implementation to do this.
 

> JcrSession creates Property instances that use the PropertyType.UNDEFINED, which is not allowed
> -----------------------------------------------------------------------------------------------
>
>                 Key: DNA-293
>                 URL: https://jira.jboss.org/jira/browse/DNA-293
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The "undefined" property type is only allowed in property definitions.  According to the JSR-170 specification (Section, 6.2.5):
>     "This constant can be used within a property definition (see 6.7.6 Property Definitions) to specify that the property in 
>     question may be of any type. However, it cannot be the actual type of any property instance. For example it will 
>     never be returned by Property.getType and (in level 2 implementations) it cannot be assigned as the type when 
>     creating a new property."
> When the property definition has a type of "undefined", then we'll need to choose what actual type to use.  There doesn't appear to be any guidance on this in the spec (anybody?), so barring that the most logical approach is probably to look at the first property value.  
> Note that this is one reason why the DNA graph API was designed with the value factories to allow (or encourage) the client to convert the property values to the type desired by the client.  Because of this, it doesn't matter so much what type the value actually is, but rather that it can be converted to the type needed by the user.  So this should make the above assumption (about choosing the property type based upon value) a pretty decent one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar  4 17:19:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 4 Mar 2009 17:19:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-293) JcrSession creates
 Property
 instances that use the PropertyType.UNDEFINED, which is not allowed
In-Reply-To: <16405064.1236200800201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26872945.1236205162546.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455518#action_12455518 ] 

Randall Hauch commented on DNA-293:
-----------------------------------

Changed how JcrSession.populateNode(...) determines the PropertyType for an existing DNA Property instance.  It is now based upon the first value, since the Java type for that value should be based upon the PropertyType specified when creating or updating the JCR property.

> JcrSession creates Property instances that use the PropertyType.UNDEFINED, which is not allowed
> -----------------------------------------------------------------------------------------------
>
>                 Key: DNA-293
>                 URL: https://jira.jboss.org/jira/browse/DNA-293
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The "undefined" property type is only allowed in property definitions.  According to the JSR-170 specification (Section, 6.2.5):
>     "This constant can be used within a property definition (see 6.7.6 Property Definitions) to specify that the property in 
>     question may be of any type. However, it cannot be the actual type of any property instance. For example it will 
>     never be returned by Property.getType and (in level 2 implementations) it cannot be assigned as the type when 
>     creating a new property."
> When the property definition has a type of "undefined", then we'll need to choose what actual type to use.  There doesn't appear to be any guidance on this in the spec (anybody?), so barring that the most logical approach is probably to look at the first property value.  
> Note that this is one reason why the DNA graph API was designed with the value factories to allow (or encourage) the client to convert the property values to the type desired by the client.  Because of this, it doesn't matter so much what type the value actually is, but rather that it can be converted to the type needed by the user.  So this should make the above assumption (about choosing the property type based upon value) a pretty decent one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar  5 09:57:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 5 Mar 2009 09:57:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14917790.1236265042365.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455610#action_12455610 ] 

Randall Hauch commented on DNA-194:
-----------------------------------

Refactored the TCK unit tests to make it easy to add Level 2 and Optional unit tests from the Jackrabbit TCK unit tests.  The Level 2 tests can be uncommented to start implementing the update capability.

> Implement update JCR capability
> -------------------------------
>
>                 Key: DNA-194
>                 URL: https://jira.jboss.org/jira/browse/DNA-194
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar  5 09:59:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 5 Mar 2009 09:59:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-292) System View Creates
 Nodes With Primary Type That Is Not Defined in Type Load
In-Reply-To: <917947.1236200542313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32860148.1236265162279.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-292:
--------------------------------

    Attachment: DNA-292.patch


Added patch that builds in the dna:namespace type and adds support for chaining of node type sources.

> System View Creates Nodes With Primary Type That Is Not Defined in Type Load
> ----------------------------------------------------------------------------
>
>                 Key: DNA-292
>                 URL: https://jira.jboss.org/jira/browse/DNA-292
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-292.patch
>
>
> DNA stores persistently mapped namespaces (including built-in namespaces like "sv", "nt") in a system view within the content graph.  The nodes storing the data have a primaryType of dna:namespace.  DNA does not currently have a type source (e.g., BuiltInTypeSource) that defines this type, so the org.apache.jackrabbit.test.api.nodetype.NodeTypeTest.testGetPrimaryItemName test case fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar  5 12:58:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 5 Mar 2009 12:58:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-91) Implement node type
	management
In-Reply-To: <33272333.1212431842222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2625471.1236275902562.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-91:
-------------------------------

    Attachment: DNA-91-supertypes.patch


It seems like they would be a lot more useful if they did.  Here is a patch that corrects that behavior (not respecting definitions from supertypes) and cleans up the can* methods in general.

> Implement node type management
> ------------------------------
>
>                 Key: DNA-91
>                 URL: https://jira.jboss.org/jira/browse/DNA-91
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>    Affects Versions: 0.2
>            Reporter: Randall Hauch
>            Assignee: Johnny Verhaeg
>             Fix For: 0.4
>
>         Attachments: DNA-91-supertypes.patch, DNA-91_Full.patch, DNA-91_Prelim.patch, DNA-91_With_Builtins.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar  5 13:16:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 5 Mar 2009 13:16:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-91) Implement node type
	management
In-Reply-To: <33272333.1212431842222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11649974.1236276983026.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-91.
------------------------------

    Resolution: Done


Applied the patch.

> Implement node type management
> ------------------------------
>
>                 Key: DNA-91
>                 URL: https://jira.jboss.org/jira/browse/DNA-91
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>    Affects Versions: 0.2
>            Reporter: Randall Hauch
>            Assignee: Johnny Verhaeg
>             Fix For: 0.4
>
>         Attachments: DNA-91-supertypes.patch, DNA-91_Full.patch, DNA-91_Prelim.patch, DNA-91_With_Builtins.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar  5 13:20:46 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 5 Mar 2009 13:20:46 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-292) System View Creates
 Nodes With Primary Type That Is Not Defined in Type Load
In-Reply-To: <917947.1236200542313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17166640.1236277246835.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455694#action_12455694 ] 

Randall Hauch commented on DNA-292:
-----------------------------------

Applied the patch.  Nice work.

> System View Creates Nodes With Primary Type That Is Not Defined in Type Load
> ----------------------------------------------------------------------------
>
>                 Key: DNA-292
>                 URL: https://jira.jboss.org/jira/browse/DNA-292
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-292.patch
>
>
> DNA stores persistently mapped namespaces (including built-in namespaces like "sv", "nt") in a system view within the content graph.  The nodes storing the data have a primaryType of dna:namespace.  DNA does not currently have a type source (e.g., BuiltInTypeSource) that defines this type, so the org.apache.jackrabbit.test.api.nodetype.NodeTypeTest.testGetPrimaryItemName test case fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar  5 13:22:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 5 Mar 2009 13:22:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-292) System View Creates
 Nodes With Primary Type That Is Not Defined in Type Load
In-Reply-To: <917947.1236200542313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <137710.1236277342280.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-292.
-------------------------------

    Fix Version/s: 0.4
       Resolution: Done
         Assignee: Randall Hauch


Marking as resolved.  Adding support for CND files, etc. will be handled as other issues.

> System View Creates Nodes With Primary Type That Is Not Defined in Type Load
> ----------------------------------------------------------------------------
>
>                 Key: DNA-292
>                 URL: https://jira.jboss.org/jira/browse/DNA-292
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-292.patch
>
>
> DNA stores persistently mapped namespaces (including built-in namespaces like "sv", "nt") in a system view within the content graph.  The nodes storing the data have a primaryType of dna:namespace.  DNA does not currently have a type source (e.g., BuiltInTypeSource) that defines this type, so the org.apache.jackrabbit.test.api.nodetype.NodeTypeTest.testGetPrimaryItemName test case fails.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar  5 16:00:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 5 Mar 2009 16:00:23 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-294) Define a custom node
 type for the root node in a repository
Message-ID: <10562869.1236286823193.JavaMail.jira@cloud.prod.atl2.jboss.com>

Define a custom node type for the root node in a repository
-----------------------------------------------------------

                 Key: DNA-294
                 URL: https://jira.jboss.org/jira/browse/DNA-294
             Project: DNA
          Issue Type: Task
          Components: JCR
    Affects Versions: 0.3
            Reporter: Randall Hauch
             Fix For: 0.4


The JCR Specification says (at least in Section 6.7.10):

    "Which NodeType is returned when this method is called on the root node of a workspace is up to the implementation, 
    though the returned type must, of course, be consistent with the child nodes and properties of the root node."

Although some of the examples (e.g, Section 6.6.1) show the primary type for the root node being "nt:unstructured".  While this is probably a good simple example, defining a DNA-specific node type would allow us to say the following:
1) the root node is autocreated
2) the root node is not autoprotected
3) the root node can have any properties
4) the root node is mix:referenceable (which says the "jcr:uuid" property is mandatory, autocreated and protected)
5) the root node allows any children, including allowing same-name-siblings
6) the root node always has a "jcr:system" child node that does not allow same-name-siblings, and that has its own type (again the spec says the type is implementation specific) that also is auto-created and protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar  6 11:39:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 6 Mar 2009 11:39:23 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-294) Define a custom node
 type for the root node in a repository
In-Reply-To: <10562869.1236286823193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16406864.1236357563321.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-294:
--------------------------------

    Attachment: DNA-294.patch


I believe this patch addresses those requirements.

> Define a custom node type for the root node in a repository
> -----------------------------------------------------------
>
>                 Key: DNA-294
>                 URL: https://jira.jboss.org/jira/browse/DNA-294
>             Project: DNA
>          Issue Type: Task
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-294.patch
>
>
> The JCR Specification says (at least in Section 6.7.10):
>     "Which NodeType is returned when this method is called on the root node of a workspace is up to the implementation, 
>     though the returned type must, of course, be consistent with the child nodes and properties of the root node."
> Although some of the examples (e.g, Section 6.6.1) show the primary type for the root node being "nt:unstructured".  While this is probably a good simple example, defining a DNA-specific node type would allow us to say the following:
> 1) the root node is autocreated
> 2) the root node is not autoprotected
> 3) the root node can have any properties
> 4) the root node is mix:referenceable (which says the "jcr:uuid" property is mandatory, autocreated and protected)
> 5) the root node allows any children, including allowing same-name-siblings
> 6) the root node always has a "jcr:system" child node that does not allow same-name-siblings, and that has its own type (again the spec says the type is implementation specific) that also is auto-created and protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar  6 11:53:42 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 6 Mar 2009 11:53:42 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30995175.1236358422379.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455947#action_12455947 ] 

Randall Hauch commented on DNA-194:
-----------------------------------

None of the nodes had a Node.getDefinition() implementation.  To properly implement this, I refactored how JcrSession was creating and populating nodes, and I added some utility methods to the JcrNodeTypeManager (which is now a separate package-protected class rather than an inner class).

This allows all of the Level 2 TCK unit tests to get further, but none of the other update functionality is implemented, so none of the Level 2 TCK tests run successfully.

I also made a number of utility methods final, in the hopes that they can be inlined since they are called very frequently.

> Implement update JCR capability
> -------------------------------
>
>                 Key: DNA-194
>                 URL: https://jira.jboss.org/jira/browse/DNA-194
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar  6 12:03:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 6 Mar 2009 12:03:23 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-294) Define a custom node
 type for the root node in a repository
In-Reply-To: <10562869.1236286823193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4400443.1236359003721.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12455952#action_12455952 ] 

Randall Hauch commented on DNA-294:
-----------------------------------

Applied the patch.  Also changed the JcrNodeTypeManager.getRootNodeDefinition() method to return "dna:root" node type (rather than "nt:unstructured").

> Define a custom node type for the root node in a repository
> -----------------------------------------------------------
>
>                 Key: DNA-294
>                 URL: https://jira.jboss.org/jira/browse/DNA-294
>             Project: DNA
>          Issue Type: Task
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-294.patch
>
>
> The JCR Specification says (at least in Section 6.7.10):
>     "Which NodeType is returned when this method is called on the root node of a workspace is up to the implementation, 
>     though the returned type must, of course, be consistent with the child nodes and properties of the root node."
> Although some of the examples (e.g, Section 6.6.1) show the primary type for the root node being "nt:unstructured".  While this is probably a good simple example, defining a DNA-specific node type would allow us to say the following:
> 1) the root node is autocreated
> 2) the root node is not autoprotected
> 3) the root node can have any properties
> 4) the root node is mix:referenceable (which says the "jcr:uuid" property is mandatory, autocreated and protected)
> 5) the root node allows any children, including allowing same-name-siblings
> 6) the root node always has a "jcr:system" child node that does not allow same-name-siblings, and that has its own type (again the spec says the type is implementation specific) that also is auto-created and protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar  6 12:05:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 6 Mar 2009 12:05:23 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-294) Define a custom node
 type for the root node in a repository
In-Reply-To: <10562869.1236286823193.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28692318.1236359123044.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-294.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Marking as resolved, since we now have the node type(s).

> Define a custom node type for the root node in a repository
> -----------------------------------------------------------
>
>                 Key: DNA-294
>                 URL: https://jira.jboss.org/jira/browse/DNA-294
>             Project: DNA
>          Issue Type: Task
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-294.patch
>
>
> The JCR Specification says (at least in Section 6.7.10):
>     "Which NodeType is returned when this method is called on the root node of a workspace is up to the implementation, 
>     though the returned type must, of course, be consistent with the child nodes and properties of the root node."
> Although some of the examples (e.g, Section 6.6.1) show the primary type for the root node being "nt:unstructured".  While this is probably a good simple example, defining a DNA-specific node type would allow us to say the following:
> 1) the root node is autocreated
> 2) the root node is not autoprotected
> 3) the root node can have any properties
> 4) the root node is mix:referenceable (which says the "jcr:uuid" property is mandatory, autocreated and protected)
> 5) the root node allows any children, including allowing same-name-siblings
> 6) the root node always has a "jcr:system" child node that does not allow same-name-siblings, and that has its own type (again the spec says the type is implementation specific) that also is auto-created and protected

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar  6 18:23:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 6 Mar 2009 18:23:23 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-295) TCK Tests for
 Session.export* Methods Fail
Message-ID: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>

TCK Tests for Session.export* Methods Fail
------------------------------------------

                 Key: DNA-295
                 URL: https://jira.jboss.org/jira/browse/DNA-295
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers


The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar  6 18:27:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 6 Mar 2009 18:27:22 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3266367.1236382042279.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-295:
--------------------------------

    Attachment: DNA-295.patch


Attached patch implements session.export*View methods as per sections 6.4.1 and 6.4.2 of the 1.0 spec with the exception of not properly encoding binary values.  I don't know how to test this until write support is at least partially implemented.

The change required:
 - Adding a new text encoder to escape XML entities (&amp;, &quot;, etc)
 - Adding a new DNA built-in type dna:xmltext to support the special document view xmltext import (see section 6.4.2.3)
 - Adding a base class for exporters, a system view exporter class, and a document view exporter class that use TraversingItemVisitor.Default to walk through the content tree and generate the views.
 - Modifying the test repository to include some more challenging cases to test encoding.

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-295.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Mar  8 15:03:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sun, 8 Mar 2009 15:03:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16360023.1236539002286.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-295:
--------------------------------

    Attachment: DNA-295.patch


Tighter patch that also more fully utilizes the Base64 class to handle export of binary properties.  Now handles all cases except strings that contain characters in the XML that cannot be legally written to an XML file.  This replaces the previous patch.

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-295.patch, DNA-295.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar  9 12:34:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 9 Mar 2009 12:34:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21484446.1236616462282.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-295:
--------------------------------

    Attachment: DNA-295_final.patch


This patch also corrects the corner case for invalid XML characters as described in 6.4.2.1 rule #7, thanks to Randall's help.

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-295.patch, DNA-295.patch, DNA-295_final.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar  9 14:28:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 9 Mar 2009 14:28:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9821453.1236623303349.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-295:
--------------------------------

    Attachment: DNA-295_namespace.patch


Added missing changes to namespaces.

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-295.patch, DNA-295.patch, DNA-295_final.patch, DNA-295_namespace.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar  9 18:31:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 9 Mar 2009 18:31:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28746567.1236637882282.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12456306#action_12456306 ] 

Randall Hauch commented on DNA-295:
-----------------------------------

We had an IRC discussion about whether to use the a "dna:xmltext" node type.  Section 6.4.2.3 of the JSR-170 specification says nothing about a required node type, but instead states that the node must be named "jcr:xmltext" and must have a single-valued property "jcr:xmlcharacters".  The TCK tests do check that when this structure appears, the "jcr:xmlcharacters" property is single-valued.

Currently, our implementation returns the NodeDefinition for a node based upon the most appropriate node definition for the parent, and the PropertyDefinition for each property in the node based upon the property definitions for the primary type and mixins.  The question is, therefore, how to get the PropertyDefinition for the "jcr:xmlcharacters" node to be single-valued.

To my understanding, there are several options:
1) Continue to use a custom DNA-specific type (e.g., "dna:xmltext") for the nodes named "jcr:xmltext", and this node type would contain one single-valued property definition for the "jcr:xmlcharacters" property.  In reality, these "jcr:xmltext" nodes may exist in the JCR repository, so we should probably have real node types for them.
2) Allow the use of any node type (e.g., "nt:unstructured"), but instead look in the JcrSession code that loads nodes to look for the "jcr:xmltext/jcr:xmlcharacters" pattern, and assign a property definition that is single-valued.  This is kind of a hack, especially if the PropertyDefinition is not in the NodeTypeManager.  Also, this checking would be done on every node loaded by the JcrSession.  

Generally speaking, option #1 is simply more attractive.  Plus, I think we're actually going to need a node type that defines the "jcr:xmltext/jcr:xmlcharacters" structure.  Section 7.2.4 of the spec defines how Document View importing may choose the primary node type for the imported nodes.  The implementation may use "nt:unstructured" for the node (representing each XML element), or it may dynamically create node types per the structure or per an XML Schema.  In the case were we're dynamically creating node types, one effective way would be to define a mixin called called "dna:xmlcontent" that defines that the node has one or more (per section 4.2.3) child nodes called "jcr:xmltext", each with a single-valued property called "jcr:xmlcharacters".  In order to property define this mixin (or any other node type that is similar), it needs to reference another node type for the "jcr:xmltext" node.  This is because the "jcr:xmltext" node has restrictions on its properties, yet a child definition cannot place restrictions on the properties of the child; instead, a child definition can only refer to the required or allowed node types for its children.  

So, to do anything interesting with Document View import and primary node types and mixin types, we'll want a node type for "jcr:xmltext" with a property property type for "jcr:xmlcharacters".  And I think this offers more support for option #1.

Therefore, I think we should continue along the lines that Brian provided with the namespace patch added to the "final" patch.  More to follow shortly after those are evaluated. 

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-295.patch, DNA-295.patch, DNA-295_final.patch, DNA-295_namespace.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       



From jira-events at lists.jboss.org  Tue Mar 10 09:18:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 10 Mar 2009 09:18:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28493033.1236691102316.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-295:
--------------------------------

    Attachment: DNA-295_namespace2.patch


Replacement for namespace patch.  Also requires that dna:xmltext in repository XML be changed to dna:xmlText.

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-295.patch, DNA-295.patch, DNA-295_final.patch, DNA-295_namespace.patch, DNA-295_namespace2.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 10 11:22:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 10 Mar 2009 11:22:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9777029.1236698543181.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12456427#action_12456427 ] 

Randall Hauch commented on DNA-295:
-----------------------------------

Applied the "DNA-295_final.patch" and "DNA-295_namespace2.patch" files, and cleaned up a few very minor things (like changed the repositoryJackrabbitTck.xml file to be more DRY by removing the "jcr:primaryTime" attributes since the importer looks at the element name for the primary type).

There still is an outstanding issue with DnaLexicon.XML_TEXT (which should be removed and replaced with references to JcrLexicon.XMLTEXT).

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-295.patch, DNA-295.patch, DNA-295_final.patch, DNA-295_namespace.patch, DNA-295_namespace2.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 10 12:33:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 10 Mar 2009 12:33:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33172306.1236702802316.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-295:
--------------------------------

    Attachment: DNA-295_cache.patch


Added cache for Name -> local name lookups, re-enabled jcr:xmltext instead of dna:xmltext for xmltext child node.

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-295.patch, DNA-295.patch, DNA-295_cache.patch, DNA-295_final.patch, DNA-295_namespace.patch, DNA-295_namespace2.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 10 12:38:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 10 Mar 2009 12:38:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28738879.1236703102279.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12456460#action_12456460 ] 

Randall Hauch commented on DNA-295:
-----------------------------------

Applied the "cache" patch that streamlined the conversion of DNA Name objects to strings containing the prefixed form of the Name.

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-295.patch, DNA-295.patch, DNA-295_cache.patch, DNA-295_final.patch, DNA-295_namespace.patch, DNA-295_namespace2.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 10 12:42:40 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 10 Mar 2009 12:42:40 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-295) TCK Tests for
 Session.export* Methods Fail
In-Reply-To: <5279057.1236381803087.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2281275.1236703360097.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-295.
-------------------------------

    Fix Version/s: 0.4
       Resolution: Done
         Assignee: Randall Hauch


Marking as resolved.

> TCK Tests for Session.export* Methods Fail
> ------------------------------------------
>
>                 Key: DNA-295
>                 URL: https://jira.jboss.org/jira/browse/DNA-295
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-295.patch, DNA-295.patch, DNA-295_cache.patch, DNA-295_final.patch, DNA-295_namespace.patch, DNA-295_namespace2.patch
>
>
> The TCK tests for Session.exportSystemView and Session.exportDocumentView fail as these methods have not yet been implemented as per sections 6.4.1 and 6.4.2 of the JCR 1.0 Specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 10 12:44:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 10 Mar 2009 12:44:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-293) JcrSession creates
 Property
 instances that use the PropertyType.UNDEFINED, which is not allowed
In-Reply-To: <16405064.1236200800201.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6909298.1236703462286.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-293.
-------------------------------

    Resolution: Done


Marking as resolved.

> JcrSession creates Property instances that use the PropertyType.UNDEFINED, which is not allowed
> -----------------------------------------------------------------------------------------------
>
>                 Key: DNA-293
>                 URL: https://jira.jboss.org/jira/browse/DNA-293
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The "undefined" property type is only allowed in property definitions.  According to the JSR-170 specification (Section, 6.2.5):
>     "This constant can be used within a property definition (see 6.7.6 Property Definitions) to specify that the property in 
>     question may be of any type. However, it cannot be the actual type of any property instance. For example it will 
>     never be returned by Property.getType and (in level 2 implementations) it cannot be assigned as the type when 
>     creating a new property."
> When the property definition has a type of "undefined", then we'll need to choose what actual type to use.  There doesn't appear to be any guidance on this in the spec (anybody?), so barring that the most logical approach is probably to look at the first property value.  
> Note that this is one reason why the DNA graph API was designed with the value factories to allow (or encourage) the client to convert the property values to the type desired by the client.  Because of this, it doesn't matter so much what type the value actually is, but rather that it can be converted to the type needed by the user.  So this should make the above assumption (about choosing the property type based upon value) a pretty decent one.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 11 10:34:42 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 11 Mar 2009 10:34:42 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22235457.1236782082375.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-194:
--------------------------------

    Attachment: DNA-194_move_value_cast.patch


Converts the JcrNodeType logic to determine whether a value can be cast to another type into the JcrValue class where it can be used to actually convert the value to a value of another type.

> Implement update JCR capability
> -------------------------------
>
>                 Key: DNA-194
>                 URL: https://jira.jboss.org/jira/browse/DNA-194
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-194_move_value_cast.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 11 10:46:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 11 Mar 2009 10:46:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17455302.1236782782382.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12456694#action_12456694 ] 

Randall Hauch commented on DNA-194:
-----------------------------------

Applied the "...move_value_cast" patch.  Also made the "createValueFormatException(...)" methods private to increase likelihood they'll be inlined. All tests pass.

> Implement update JCR capability
> -------------------------------
>
>                 Key: DNA-194
>                 URL: https://jira.jboss.org/jira/browse/DNA-194
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-194_move_value_cast.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 11 15:02:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 11 Mar 2009 15:02:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-296) JcrSession Sometimes
 Eschews Single-Valued Variants of PropertyDefinitions
Message-ID: <29349413.1236798142280.JavaMail.jira@cloud.prod.atl2.jboss.com>

JcrSession Sometimes Eschews Single-Valued Variants of PropertyDefinitions
--------------------------------------------------------------------------

                 Key: DNA-296
                 URL: https://jira.jboss.org/jira/browse/DNA-296
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers


JcrSession.populateNode infers the property definition for each property by doing a property lookup by name and, if that fails, by checking for a matching residual property definition.  This lookup also needs to compare by cardinality (single-valued vs. multi-valued).

Correcting this obviates the need for dna:xmlText and dna:xmlContent from the DNA-295 defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 11 15:06:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 11 Mar 2009 15:06:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-296) JcrSession Sometimes
 Eschews Single-Valued Variants of PropertyDefinitions
In-Reply-To: <29349413.1236798142280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8670234.1236798382291.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-296:
--------------------------------

    Attachment: DNA-194_prop_def_lookup.patch


Please ignore the patch name.  This is for DNA-296.  It modifies the property definition lookup, deletes the dna:xmlText and dna:xmlContent types, and makes the xmltext portion of the TCK repository use nt:unstructured as a primary type instead.

> JcrSession Sometimes Eschews Single-Valued Variants of PropertyDefinitions
> --------------------------------------------------------------------------
>
>                 Key: DNA-296
>                 URL: https://jira.jboss.org/jira/browse/DNA-296
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-194_prop_def_lookup.patch
>
>
> JcrSession.populateNode infers the property definition for each property by doing a property lookup by name and, if that fails, by checking for a matching residual property definition.  This lookup also needs to compare by cardinality (single-valued vs. multi-valued).
> Correcting this obviates the need for dna:xmlText and dna:xmlContent from the DNA-295 defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 11 15:14:33 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 11 Mar 2009 15:14:33 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-296) JcrSession Sometimes
 Eschews Single-Valued Variants of PropertyDefinitions
In-Reply-To: <29349413.1236798142280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8792068.1236798873056.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12456779#action_12456779 ] 

Randall Hauch commented on DNA-296:
-----------------------------------

Applied the patch that corrects the assignment of the PropertyDefinition to each Property instance.

> JcrSession Sometimes Eschews Single-Valued Variants of PropertyDefinitions
> --------------------------------------------------------------------------
>
>                 Key: DNA-296
>                 URL: https://jira.jboss.org/jira/browse/DNA-296
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 0.4
>
>         Attachments: DNA-194_prop_def_lookup.patch
>
>
> JcrSession.populateNode infers the property definition for each property by doing a property lookup by name and, if that fails, by checking for a matching residual property definition.  This lookup also needs to compare by cardinality (single-valued vs. multi-valued).
> Correcting this obviates the need for dna:xmlText and dna:xmlContent from the DNA-295 defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 11 15:14:33 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 11 Mar 2009 15:14:33 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-296) JcrSession Sometimes
 Eschews Single-Valued Variants of PropertyDefinitions
In-Reply-To: <29349413.1236798142280.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17151673.1236798873137.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-296.
-------------------------------

    Fix Version/s: 0.4
       Resolution: Done
         Assignee: Randall Hauch


This patch closes out this issue.

> JcrSession Sometimes Eschews Single-Valued Variants of PropertyDefinitions
> --------------------------------------------------------------------------
>
>                 Key: DNA-296
>                 URL: https://jira.jboss.org/jira/browse/DNA-296
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-194_prop_def_lookup.patch
>
>
> JcrSession.populateNode infers the property definition for each property by doing a property lookup by name and, if that fails, by checking for a matching residual property definition.  This lookup also needs to compare by cardinality (single-valued vs. multi-valued).
> Correcting this obviates the need for dna:xmlText and dna:xmlContent from the DNA-295 defect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 11 17:07:24 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 11 Mar 2009 17:07:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-297)
 JcrSession.exportDocumentView Does
 Not Export Carriage Returns, Line Feeds, and Tabs Correctly
Message-ID: <4764598.1236805644738.JavaMail.jira@cloud.prod.atl2.jboss.com>

JcrSession.exportDocumentView Does Not Export Carriage Returns, Line Feeds, and Tabs Correctly
----------------------------------------------------------------------------------------------

                 Key: DNA-297
                 URL: https://jira.jboss.org/jira/browse/DNA-297
             Project: DNA
          Issue Type: Bug
    Affects Versions: 0.4
            Reporter: Brian Carothers
            Priority: Minor


JcrSession.exportDocumentView did not properly encode carriage returns, line feeds, or tabs during export as described in section 6.4.4 of the 1.0.1 specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 11 18:06:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 11 Mar 2009 18:06:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-297)
 JcrSession.exportDocumentView Does
 Not Export Carriage Returns, Line Feeds, and Tabs Correctly
In-Reply-To: <4764598.1236805644738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23996832.1236809182591.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-297:
--------------------------------

    Attachment: DNA-297.patch


This patch adds a corrected text encoder for the document view export and modifies the repository to test for line feeds and tabs in the export.  Exported carriage returns were emitted correctly (as verified in a debugger), but were converted to new lines by the XML Parser that the TCK test uses to read the values from the file.

Instead JcrSessionTest was modified to add a hard-coded test case that exports a particular tree structure and does a string compare against an expected result.

> JcrSession.exportDocumentView Does Not Export Carriage Returns, Line Feeds, and Tabs Correctly
> ----------------------------------------------------------------------------------------------
>
>                 Key: DNA-297
>                 URL: https://jira.jboss.org/jira/browse/DNA-297
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Priority: Minor
>         Attachments: DNA-297.patch
>
>
> JcrSession.exportDocumentView did not properly encode carriage returns, line feeds, or tabs during export as described in section 6.4.4 of the 1.0.1 specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 11:05:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 12 Mar 2009 11:05:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-298) SVNRepositoryTest
	Fails on Windows
Message-ID: <31105963.1236870322527.JavaMail.jira@cloud.prod.atl2.jboss.com>

SVNRepositoryTest Fails on Windows
----------------------------------

                 Key: DNA-298
                 URL: https://jira.jboss.org/jira/browse/DNA-298
             Project: DNA
          Issue Type: Bug
          Components: Connectors
    Affects Versions: 0.4
         Environment: JDK 1.6.0_012, Windows XP
            Reporter: Brian Carothers
            Priority: Minor


Two tests in SVNRepositoryTest fail when running on Windows.  The tests are:

shouldCreateFSRepositoryIfProtocolIsOfTypeFile
shouldAllowMultipleConnectionsToBeOpenAtTheSameTime

Both fail with (essentially) the same stack trace:

org.jboss.dna.graph.connector.RepositorySourceException: Protocol is not supported by this connector or there is problem in the svn url
	at org.jboss.dna.connector.svn.SVNRepositorySource.getConnection(SVNRepositorySource.java:300)
	at org.jboss.dna.connector.svn.SVNRepositorySourceTest.shouldCreateFSRepositoryIfProtocolIsOfTypeFile(SVNRepositorySourceTest.java:240)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
	at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
	at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
	at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
	at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
	at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
	at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
	at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
	at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
	at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
	at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
	at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 11:10:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 12 Mar 2009 11:10:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-298) SVNRepositoryTest
	Fails on Windows
In-Reply-To: <31105963.1236870322527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32358111.1236870622283.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-298:
--------------------------------

    Attachment: DNA-298.patch


On Windows, the URIs constructed by the test will look something like this:  (Note the extra colon after the drive name)

file://localhost/C:/workspaces/jbossdna3-source/trunk/extensions/dna-connector-svn/target/copy_of%20dummy_svn_repos

So this line in SVNRepositorySource:

String usedProtocol = this.getSVNURL().substring(0, this.getSVNURL().lastIndexOf(":"));

Sets usedProtocol to this:

"file://localhost/C"

Instead of this:

"file"

Patch is attached that makes the tests pass on my Windows box.

> SVNRepositoryTest Fails on Windows
> ----------------------------------
>
>                 Key: DNA-298
>                 URL: https://jira.jboss.org/jira/browse/DNA-298
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>         Environment: JDK 1.6.0_012, Windows XP
>            Reporter: Brian Carothers
>            Priority: Minor
>         Attachments: DNA-298.patch
>
>
> Two tests in SVNRepositoryTest fail when running on Windows.  The tests are:
> shouldCreateFSRepositoryIfProtocolIsOfTypeFile
> shouldAllowMultipleConnectionsToBeOpenAtTheSameTime
> Both fail with (essentially) the same stack trace:
> org.jboss.dna.graph.connector.RepositorySourceException: Protocol is not supported by this connector or there is problem in the svn url
> 	at org.jboss.dna.connector.svn.SVNRepositorySource.getConnection(SVNRepositorySource.java:300)
> 	at org.jboss.dna.connector.svn.SVNRepositorySourceTest.shouldCreateFSRepositoryIfProtocolIsOfTypeFile(SVNRepositorySourceTest.java:240)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> 	at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> 	at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> 	at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> 	at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> 	at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> 	at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> 	at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> 	at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> 	at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> 	at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> 	at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 12:11:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 12:11:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-298) SVNRepositoryTest
 Fails on Windows
In-Reply-To: <31105963.1236870322527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7175948.1236874282687.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12456953#action_12456953 ] 

Randall Hauch commented on DNA-298:
-----------------------------------

Applied the patch and verified the patch does not change the behavior on OS-X, so I've committed the patch.

The Hudson continuous integration builds run on Linux, so they should verify that the patch also works on Linux.  If they pass, then we can mark this issue as resolved.

> SVNRepositoryTest Fails on Windows
> ----------------------------------
>
>                 Key: DNA-298
>                 URL: https://jira.jboss.org/jira/browse/DNA-298
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>         Environment: JDK 1.6.0_012, Windows XP
>            Reporter: Brian Carothers
>            Priority: Minor
>         Attachments: DNA-298.patch
>
>
> Two tests in SVNRepositoryTest fail when running on Windows.  The tests are:
> shouldCreateFSRepositoryIfProtocolIsOfTypeFile
> shouldAllowMultipleConnectionsToBeOpenAtTheSameTime
> Both fail with (essentially) the same stack trace:
> org.jboss.dna.graph.connector.RepositorySourceException: Protocol is not supported by this connector or there is problem in the svn url
> 	at org.jboss.dna.connector.svn.SVNRepositorySource.getConnection(SVNRepositorySource.java:300)
> 	at org.jboss.dna.connector.svn.SVNRepositorySourceTest.shouldCreateFSRepositoryIfProtocolIsOfTypeFile(SVNRepositorySourceTest.java:240)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> 	at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> 	at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> 	at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> 	at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> 	at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> 	at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> 	at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> 	at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> 	at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> 	at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> 	at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 12:43:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 12:43:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-297)
 JcrSession.exportDocumentView
 Does Not Export Carriage Returns, Line Feeds, and Tabs Correctly
In-Reply-To: <4764598.1236805644738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3082012.1236876202426.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12456967#action_12456967 ] 

Randall Hauch commented on DNA-297:
-----------------------------------

I tried this patch, and there is one failure in JcrSessionTest.shouldExportMultiLinePropertiesInSystemView(JcrSessionTest.java:419).  The error contains some unformatted output, but here's the more readable result:

Expected:

<?xml version="1.0" encoding="UTF-8"?>
<sv:node xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sv="http://www.jcp.org/jcr/sv/1.0" xmlns:mix="http://www.jcp.org/jcr/mix/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" sv:name="c">
	<sv:property sv:name="jcr:primaryType" sv:type="Name">
		<sv:value>nt:unstructured</sv:value>
	</sv:property>
	<sv:property sv:name="multiLineProperty" sv:type="String">
		<sv:value>Line 1\nLine 2\rLine\t3</sv:value>
	</sv:property>
	<sv:property sv:name="stringProperty" sv:type="String">
		<sv:value>value</sv:value>
	</sv:property>
</sv:node>

But got:

<?xml version="1.0" encoding="UTF-8"?>
<sv:node xmlns:jcr="http://www.jcp.org/jcr/1.0" xmlns:nt="http://www.jcp.org/jcr/nt/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:sv="http://www.jcp.org/jcr/sv/1.0" xmlns:mix="http://www.jcp.org/jcr/mix/1.0" sv:name="c">
	<sv:property sv:name="jcr:primaryType" sv:type="Name">
		<sv:value>nt:unstructured</sv:value>
	</sv:property>
	<sv:property sv:name="stringProperty" sv:type="String">
		<sv:value>value</sv:value>
	</sv:property>
	<sv:property sv:name="multiLineProperty" sv:type="String">
		<sv:value>Line 1\nLine 2\rLine\t3</sv:value>
	</sv:property>
</sv:node>

If you look at these closely, there two major differences: 1) the namespace declarations are in a different order, and 2) the order of the last two properties are switched.

I've seen evidence of problems like this in situations where different JDKs/JREs are ordering the contents of a HashSet (or HashMap) differently.  I suspect that this is the problem here.  I'm on OS-X running Apple's JDK 1.5.0_16 (version build 1.5.0_16-b06-284 of the JRE), and from another recent issue I know that Brian is running JDK 1.6.0_012 on Windows XP.

So, technically the only problem is in the JcrSessionTest, since it's comparing string values.  We can either 
1) find some other way to validate the output that is independent of ordering of properties and namespaces; or 
2) we can have the export take a little more time and guarantee ordering so the export output is consistent and repeatable on different platforms.  Note, however, that the latter is really not a requirement of JCR.

I have not committed the patch.

> JcrSession.exportDocumentView Does Not Export Carriage Returns, Line Feeds, and Tabs Correctly
> ----------------------------------------------------------------------------------------------
>
>                 Key: DNA-297
>                 URL: https://jira.jboss.org/jira/browse/DNA-297
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Priority: Minor
>         Attachments: DNA-297.patch
>
>
> JcrSession.exportDocumentView did not properly encode carriage returns, line feeds, or tabs during export as described in section 6.4.4 of the 1.0.1 specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 12:49:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 12:49:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-298) SVNRepositoryTest
	Fails on Windows
In-Reply-To: <31105963.1236870322527.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3696496.1236876562646.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-298.
-------------------------------

    Fix Version/s: 0.4
       Resolution: Done
         Assignee: Randall Hauch


The build with this commit was successful, so I'm marking this as resolved.

> SVNRepositoryTest Fails on Windows
> ----------------------------------
>
>                 Key: DNA-298
>                 URL: https://jira.jboss.org/jira/browse/DNA-298
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>         Environment: JDK 1.6.0_012, Windows XP
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: DNA-298.patch
>
>
> Two tests in SVNRepositoryTest fail when running on Windows.  The tests are:
> shouldCreateFSRepositoryIfProtocolIsOfTypeFile
> shouldAllowMultipleConnectionsToBeOpenAtTheSameTime
> Both fail with (essentially) the same stack trace:
> org.jboss.dna.graph.connector.RepositorySourceException: Protocol is not supported by this connector or there is problem in the svn url
> 	at org.jboss.dna.connector.svn.SVNRepositorySource.getConnection(SVNRepositorySource.java:300)
> 	at org.jboss.dna.connector.svn.SVNRepositorySourceTest.shouldCreateFSRepositoryIfProtocolIsOfTypeFile(SVNRepositorySourceTest.java:240)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> 	at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> 	at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> 	at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> 	at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> 	at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> 	at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> 	at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> 	at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> 	at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> 	at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> 	at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 13:43:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 12 Mar 2009 13:43:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-297)
 JcrSession.exportDocumentView Does
 Not Export Carriage Returns, Line Feeds, and Tabs Correctly
In-Reply-To: <4764598.1236805644738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2790493.1236879803323.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-297:
--------------------------------

    Attachment: DNA-297_redux.patch


Replacement for the first patch that changes the test to be a little less dangerous.

> JcrSession.exportDocumentView Does Not Export Carriage Returns, Line Feeds, and Tabs Correctly
> ----------------------------------------------------------------------------------------------
>
>                 Key: DNA-297
>                 URL: https://jira.jboss.org/jira/browse/DNA-297
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Priority: Minor
>         Attachments: DNA-297.patch, DNA-297_redux.patch
>
>
> JcrSession.exportDocumentView did not properly encode carriage returns, line feeds, or tabs during export as described in section 6.4.4 of the 1.0.1 specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 15:14:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 15:14:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-299) Path.isNormalized() is
 incorrect if the path begins with parent reference(s)
Message-ID: <25571171.1236885262276.JavaMail.jira@cloud.prod.atl2.jboss.com>

Path.isNormalized() is incorrect if the path begins with parent reference(s)
----------------------------------------------------------------------------

                 Key: DNA-299
                 URL: https://jira.jboss.org/jira/browse/DNA-299
             Project: DNA
          Issue Type: Bug
          Components: API, Graph
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.4


The different implementations of Path consider a path that begins with a one or more parent references as not normalized.  For example, "../a" should be considered normalized, but it is not.  Normalized means that there are no self-reference segments (e.g., "."), and that all parent references that can be removed are removed.  Therefore, "../a" should be normalized, whereas "/../a" is not normalized.

There were no unit tests that covered these conditions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 15:20:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 15:20:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-299) Path.isNormalized()
 is incorrect if the path begins with parent reference(s)
In-Reply-To: <25571171.1236885262276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <33447885.1236885622278.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457010#action_12457010 ] 

Randall Hauch commented on DNA-299:
-----------------------------------

Added the tests to verify it was failing, then corrected the logic in all Path implementations (although RootPath was correct, since it always considered itself normalized).

> Path.isNormalized() is incorrect if the path begins with parent reference(s)
> ----------------------------------------------------------------------------
>
>                 Key: DNA-299
>                 URL: https://jira.jboss.org/jira/browse/DNA-299
>             Project: DNA
>          Issue Type: Bug
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The different implementations of Path consider a path that begins with a one or more parent references as not normalized.  For example, "../a" should be considered normalized, but it is not.  Normalized means that there are no self-reference segments (e.g., "."), and that all parent references that can be removed are removed.  Therefore, "../a" should be normalized, whereas "/../a" is not normalized.
> There were no unit tests that covered these conditions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 15:57:16 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 15:57:16 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-299) Path.isNormalized()
 is incorrect if the path begins with parent reference(s)
In-Reply-To: <25571171.1236885262276.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16105165.1236887836097.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-299.
-------------------------------

    Resolution: Done


Marking as resolved, since success with all unit tests confirmed by continuous integration.

> Path.isNormalized() is incorrect if the path begins with parent reference(s)
> ----------------------------------------------------------------------------
>
>                 Key: DNA-299
>                 URL: https://jira.jboss.org/jira/browse/DNA-299
>             Project: DNA
>          Issue Type: Bug
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The different implementations of Path consider a path that begins with a one or more parent references as not normalized.  For example, "../a" should be considered normalized, but it is not.  Normalized means that there are no self-reference segments (e.g., "."), and that all parent references that can be removed are removed.  Therefore, "../a" should be normalized, whereas "/../a" is not normalized.
> There were no unit tests that covered these conditions.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 16:12:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 16:12:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-300) The DNA
 PathNotFoundException
 message text does not include the lowest existing path that was found
Message-ID: <5772515.1236888742293.JavaMail.jira@cloud.prod.atl2.jboss.com>

The DNA PathNotFoundException message text does not include the lowest existing path that was found
---------------------------------------------------------------------------------------------------

                 Key: DNA-300
                 URL: https://jira.jboss.org/jira/browse/DNA-300
             Project: DNA
          Issue Type: Bug
          Components: API, Graph
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Minor
             Fix For: 0.4


The PathNotFoundException that is part of the DNA Graph API has the lowest existing path that was found along the requested path. This path, however, is only available as a field on the exception, and does not show up in the exception message, either through getMessage() or getLocalizedMessage().  The message should include the lowest existing path, and should be internationalized using GraphI18n.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 16:16:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 16:16:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-300) The DNA
 PathNotFoundException
 message text does not include the lowest existing path that was found
In-Reply-To: <5772515.1236888742293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32201880.1236888982406.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457020#action_12457020 ] 

Randall Hauch commented on DNA-300:
-----------------------------------

Added the lowest existing path to the message (and localized message) of the PathNotFoundException in the DNA Graph API.  Of course, this is only added when there is a lowest existing path.

> The DNA PathNotFoundException message text does not include the lowest existing path that was found
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DNA-300
>                 URL: https://jira.jboss.org/jira/browse/DNA-300
>             Project: DNA
>          Issue Type: Bug
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> The PathNotFoundException that is part of the DNA Graph API has the lowest existing path that was found along the requested path. This path, however, is only available as a field on the exception, and does not show up in the exception message, either through getMessage() or getLocalizedMessage().  The message should include the lowest existing path, and should be internationalized using GraphI18n.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 16:24:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 16:24:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-300) The DNA
 PathNotFoundException
 message text does not include the lowest existing path that was found
In-Reply-To: <5772515.1236888742293.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24495201.1236889462574.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-300.
-------------------------------

    Resolution: Done


Marking as resolved.

> The DNA PathNotFoundException message text does not include the lowest existing path that was found
> ---------------------------------------------------------------------------------------------------
>
>                 Key: DNA-300
>                 URL: https://jira.jboss.org/jira/browse/DNA-300
>             Project: DNA
>          Issue Type: Bug
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> The PathNotFoundException that is part of the DNA Graph API has the lowest existing path that was found along the requested path. This path, however, is only available as a field on the exception, and does not show up in the exception message, either through getMessage() or getLocalizedMessage().  The message should include the lowest existing path, and should be internationalized using GraphI18n.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 16:43:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 16:43:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27420369.1236890602696.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457023#action_12457023 ] 

Randall Hauch commented on DNA-194:
-----------------------------------

Small optimization in the NameValueFactory that maintains a single static/shared instance for Name objects that have no namespace URI and a local name of "*".  These are use pretty prevelently in the JCR type manager to represent residual child and property definitions.  This is a minimal memory improvement, but really reduces the time to parse and create a Name.

> Implement update JCR capability
> -------------------------------
>
>                 Key: DNA-194
>                 URL: https://jira.jboss.org/jira/browse/DNA-194
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-194_move_value_cast.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 16:56:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 16:56:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-297)
 JcrSession.exportDocumentView
 Does Not Export Carriage Returns, Line Feeds, and Tabs Correctly
In-Reply-To: <4764598.1236805644738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18350337.1236891382413.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457025#action_12457025 ] 

Randall Hauch commented on DNA-297:
-----------------------------------

Applied the "redux" patch, and verified that all tests do pass (locally).  Will resolve as soon as the continue integration confirm all tests pass.

> JcrSession.exportDocumentView Does Not Export Carriage Returns, Line Feeds, and Tabs Correctly
> ----------------------------------------------------------------------------------------------
>
>                 Key: DNA-297
>                 URL: https://jira.jboss.org/jira/browse/DNA-297
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Priority: Minor
>         Attachments: DNA-297.patch, DNA-297_redux.patch
>
>
> JcrSession.exportDocumentView did not properly encode carriage returns, line feeds, or tabs during export as described in section 6.4.4 of the 1.0.1 specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 12 17:12:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Mar 2009 17:12:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-297)
 JcrSession.exportDocumentView Does
 Not Export Carriage Returns, Line Feeds, and Tabs Correctly
In-Reply-To: <4764598.1236805644738.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18299018.1236892342539.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-297.
-------------------------------

    Fix Version/s: 0.4
       Resolution: Done
         Assignee: Randall Hauch


Marking as resolved.

> JcrSession.exportDocumentView Does Not Export Carriage Returns, Line Feeds, and Tabs Correctly
> ----------------------------------------------------------------------------------------------
>
>                 Key: DNA-297
>                 URL: https://jira.jboss.org/jira/browse/DNA-297
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: DNA-297.patch, DNA-297_redux.patch
>
>
> JcrSession.exportDocumentView did not properly encode carriage returns, line feeds, or tabs during export as described in section 6.4.4 of the 1.0.1 specification.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 16 18:49:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 16 Mar 2009 18:49:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10906009.1237243762847.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-194:
------------------------------

    Attachment: dna-194-session-cache.patch


Uploaded a patch file that captures the refactoring to pull the management of the session's cached and updated state out of the individual Node and Property implementations and into a new "SessionCache" class.

This class does a couple of different things.  First, it centralizes all of the information about the nodes and properties that have been loaded from the repository source, making it easier to track the cached information as well as track/manage the changes made within the session.  Remember that some activities, such as "refresh" or "save" can be performed on one node but could potentially affect many other objects. By centralizing all the cached and transient state, it's much easier to manage all this information.  It also makes it much easier to alter the data structure used to manage the cache (for example to make it thread-safe), should that be required at a later time.

Second, it manages the Node and Property implementation objects (which can be held onto by clients), ensuring that the same Node and Property instances are always returned for the same logical instance.  These instances are managed by ReferenceMaps, allowing the garbage collector to remove entries when clients no longer hold onto the Node and Property objects (with normal references).  The implementation classes of Node and Property (e.g., AbstractJcrNode and its concrete subclasses, and AbstractJcrProperty and its concrete subclasses) no longer directly hold onto the detailed node and property information being cached in SessionCache, but rather hold identifiers and dynamically look up the information when necessary.  This ensures that a particular Node implementation object obtained for a node will always present the most up-to-date information about the node, even if that information is changed by the session or other objects.  

(Note that it would be very easy for each Node and Property implementation to locally cache the reference to the SessionCache's node information and/or property information, saving some repeated lookups using the SessionCache's methods, but since the SessionCache knows about the implementations it could invalidate these local references when needed.  This could be done at a later time when we've proven that the current simple approach needs to be improved.)

> Implement update JCR capability
> -------------------------------
>
>                 Key: DNA-194
>                 URL: https://jira.jboss.org/jira/browse/DNA-194
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-194-session-cache.patch, DNA-194_move_value_cast.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 00:24:36 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 17 Mar 2009 00:24:36 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-301) Most state managed
 within the
 Workspace should be shared among multiple Session instances
Message-ID: <27883920.1237263876479.JavaMail.jira@cloud.prod.atl2.jboss.com>

Most state managed within the Workspace should be shared among multiple Session instances
-----------------------------------------------------------------------------------------

                 Key: DNA-301
                 URL: https://jira.jboss.org/jira/browse/DNA-301
             Project: DNA
          Issue Type: Task
          Components: API, JCR
    Affects Versions: 0.3
            Reporter: Randall Hauch
             Fix For: 0.4


Our current JcrWorkspace implementation is created to be used only by the one JcrSession instance associated with it.  Currently, each Session would have it's own Workspace implementation, each of which would have its own copy of the namespace registry and node type manager.  

However, one common use case for JCR involves creating many Session instances for the same workspace (e.g., this is the web app scenario).  This means that we'd have a lot of Workspace instances (same number as Session instances) each with their own copy of the data.  In fact, the node type manager should actually be "owned" (at least logically) by the repository, per section 6.7.9: "There is one node type registry per repository, therefore the NodeTypeManager is not workspace-specific; it provides introspection methods for the global, repository-wide set of available node types."

Therefore, a number of things that are currently in the JcrWorkspace implementation should be pulled out and reused for all JcrWorkspace instances created by the JcrRepository for the same logical workspace.  This issue captures the set of tasks that are involved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 00:30:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 17 Mar 2009 00:30:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-302) Make
 JcrNodeTypeManager not dependent on JcrSession
Message-ID: <26976618.1237264222615.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make JcrNodeTypeManager not dependent on JcrSession
---------------------------------------------------

                 Key: DNA-302
                 URL: https://jira.jboss.org/jira/browse/DNA-302
             Project: DNA
          Issue Type: Sub-task
          Components: API, JCR
    Affects Versions: 0.3
            Reporter: Randall Hauch
             Fix For: 0.4


The JcrNodeTypeManager should not be dependent upon a JcrSession instance.  Most of the methods (including those in JcrNodeType, JcrNodeDefinition, and JcrPropertyDefinition) only need an ExecutionContext.  JcrNodeDefinition.getDefaultPrimaryType() seems to depend upon the NodeTypeManager to dynamically look up a type (there may be others).  This main mean that the JcrNodeTypeManager needs a method to allow adding types from a JcrNodeTypeSource (rather than a JcrNodeTypeSource be passed into the constructor).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 00:36:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 17 Mar 2009 00:36:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-303) The workspace
 NamespaceRegistry implementation should be shared
Message-ID: <28165566.1237264582270.JavaMail.jira@cloud.prod.atl2.jboss.com>

The workspace NamespaceRegistry implementation should be shared
---------------------------------------------------------------

                 Key: DNA-303
                 URL: https://jira.jboss.org/jira/browse/DNA-303
             Project: DNA
          Issue Type: Sub-task
          Components: API, JCR
    Affects Versions: 0.3
            Reporter: Randall Hauch
             Fix For: 0.4


The JcrWorkspace class currently uses the GraphNamespaceRegistry, which implements DNA's NamespaceRegistry implementation on top of namespace mappings stored in a graph.  While this works for a single ExecutionContext, having a shared implementation for multiple JcrWorkspace objects means that the update methods need to be done with the ExecutionContext of the user making the changes.  This would require changing the design a fair amount.

The NamespaceRegistry implementation would also need to be thread-safe.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 00:47:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 17 Mar 2009 00:47:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-301) Most state managed
 within the
 Workspace should be shared among multiple Session instances
In-Reply-To: <27883920.1237263876479.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20021819.1237265242331.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457587#action_12457587 ] 

Randall Hauch commented on DNA-301:
-----------------------------------

The current design is intensionally not thread-safe.  According to the JCR spec, Session is not safe to be called concurrently by multiple threads.  So, by having each session have its own workspace (and associated state), each session's workspace owns copies of the namespace registry and node type manager.  Moving to a design where each session's workspace uses a shared namespace registry and node type manager would mean these now need to be thread-safe (since they're concurrently accessible and updatable through separate Sessions and threads).

So, currently we can have no locking because each workspace has its own copies.  And since there will likely not be large numbers of node types or namespace mappings, memory usage probably won't be a problem even with large numbers of Sessions (and therefore Workspaces).  IMO, the larger problem will be the time required to update all these copies when a change is made, and any latency between the change and the last session to be made aware of the change.

I'm not convinced that these changes need to be in 0.4, so I'm willing to push them.  I am interested in feedback, however.

> Most state managed within the Workspace should be shared among multiple Session instances
> -----------------------------------------------------------------------------------------
>
>                 Key: DNA-301
>                 URL: https://jira.jboss.org/jira/browse/DNA-301
>             Project: DNA
>          Issue Type: Task
>          Components: API, JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>             Fix For: 0.4
>
>
> Our current JcrWorkspace implementation is created to be used only by the one JcrSession instance associated with it.  Currently, each Session would have it's own Workspace implementation, each of which would have its own copy of the namespace registry and node type manager.  
> However, one common use case for JCR involves creating many Session instances for the same workspace (e.g., this is the web app scenario).  This means that we'd have a lot of Workspace instances (same number as Session instances) each with their own copy of the data.  In fact, the node type manager should actually be "owned" (at least logically) by the repository, per section 6.7.9: "There is one node type registry per repository, therefore the NodeTypeManager is not workspace-specific; it provides introspection methods for the global, repository-wide set of available node types."
> Therefore, a number of things that are currently in the JcrWorkspace implementation should be pulled out and reused for all JcrWorkspace instances created by the JcrRepository for the same logical workspace.  This issue captures the set of tasks that are involved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 00:55:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 17 Mar 2009 00:55:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-301) Most state managed
 within the
 Workspace should be shared among multiple Session instances
In-Reply-To: <27883920.1237263876479.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1699703.1237265722320.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-301:
------------------------------

    Fix Version/s: 0.5
                       (was: 0.4)


Changing the fix version to 0.5, since this is not critical for 0.4 functionality and is more of an optimization for larger numbers of Session instances to the same workspace.  However, we should keep these changes in mind, should any modifications be required to these components in 0.4.

> Most state managed within the Workspace should be shared among multiple Session instances
> -----------------------------------------------------------------------------------------
>
>                 Key: DNA-301
>                 URL: https://jira.jboss.org/jira/browse/DNA-301
>             Project: DNA
>          Issue Type: Task
>          Components: API, JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>
> Our current JcrWorkspace implementation is created to be used only by the one JcrSession instance associated with it.  Currently, each Session would have it's own Workspace implementation, each of which would have its own copy of the namespace registry and node type manager.  
> However, one common use case for JCR involves creating many Session instances for the same workspace (e.g., this is the web app scenario).  This means that we'd have a lot of Workspace instances (same number as Session instances) each with their own copy of the data.  In fact, the node type manager should actually be "owned" (at least logically) by the repository, per section 6.7.9: "There is one node type registry per repository, therefore the NodeTypeManager is not workspace-specific; it provides introspection methods for the global, repository-wide set of available node types."
> Therefore, a number of things that are currently in the JcrWorkspace implementation should be pulled out and reused for all JcrWorkspace instances created by the JcrRepository for the same logical workspace.  This issue captures the set of tasks that are involved.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 00:55:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 17 Mar 2009 00:55:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-302) Make
 JcrNodeTypeManager not dependent on JcrSession
In-Reply-To: <26976618.1237264222615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23235246.1237265722361.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-302:
------------------------------

    Fix Version/s: 0.5
                       (was: 0.4)


Changing the fix version to 0.5, since this is not critical for 0.4 functionality and is more of an optimization for larger numbers of Session instances to the same workspace.  However, we should keep these changes in mind, should any modifications be required to these components in 0.4.

> Make JcrNodeTypeManager not dependent on JcrSession
> ---------------------------------------------------
>
>                 Key: DNA-302
>                 URL: https://jira.jboss.org/jira/browse/DNA-302
>             Project: DNA
>          Issue Type: Sub-task
>          Components: API, JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>
> The JcrNodeTypeManager should not be dependent upon a JcrSession instance.  Most of the methods (including those in JcrNodeType, JcrNodeDefinition, and JcrPropertyDefinition) only need an ExecutionContext.  JcrNodeDefinition.getDefaultPrimaryType() seems to depend upon the NodeTypeManager to dynamically look up a type (there may be others).  This main mean that the JcrNodeTypeManager needs a method to allow adding types from a JcrNodeTypeSource (rather than a JcrNodeTypeSource be passed into the constructor).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 00:55:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 17 Mar 2009 00:55:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-303) The workspace
 NamespaceRegistry implementation should be shared
In-Reply-To: <28165566.1237264582270.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12812312.1237265722441.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-303:
------------------------------

    Fix Version/s: 0.5
                       (was: 0.4)


Changing the fix version to 0.5, since this is not critical for 0.4 functionality and is more of an optimization for larger numbers of Session instances to the same workspace.  However, we should keep these changes in mind, should any modifications be required to these components in 0.4.

> The workspace NamespaceRegistry implementation should be shared
> ---------------------------------------------------------------
>
>                 Key: DNA-303
>                 URL: https://jira.jboss.org/jira/browse/DNA-303
>             Project: DNA
>          Issue Type: Sub-task
>          Components: API, JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>
> The JcrWorkspace class currently uses the GraphNamespaceRegistry, which implements DNA's NamespaceRegistry implementation on top of namespace mappings stored in a graph.  While this works for a single ExecutionContext, having a shared implementation for multiple JcrWorkspace objects means that the update methods need to be done with the ExecutionContext of the user making the changes.  This would require changing the design a fair amount.
> The NamespaceRegistry implementation would also need to be thread-safe.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 10:39:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 17 Mar 2009 10:39:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-304) SessionCache Uses
 Graph Layer
 Cardinality for Properties Instead of Cardinality from JCR Property
 Definition
Message-ID: <14660899.1237300762809.JavaMail.jira@cloud.prod.atl2.jboss.com>

SessionCache Uses Graph Layer Cardinality for Properties Instead of Cardinality from JCR Property Definition
------------------------------------------------------------------------------------------------------------

                 Key: DNA-304
                 URL: https://jira.jboss.org/jira/browse/DNA-304
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers


At the graph layer, property cardinality (whether the property is single- or multi-valued) is determined based on the values set on the property (i.e., any property with only one value is single-valued, any property with more than one value is multi-valued).   At the JCR layer, property cardinality is supposed to be based on the property definition in use for the property.  

The SessionCache is currently basing the JCR layer cardinality on the graph layer cardinality instead of the JCR property definition.  

Example:
Consider a node that has one value for jcr:mixinTypes.  At the graph layer, this property will be single-valued.  At the JCR layer, this property should be multi-valued based on the jcr:mixinTypes property definition from the nt:base type (which is inherited by all nodes).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 10:41:40 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 17 Mar 2009 10:41:40 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-304) SessionCache Uses
 Graph Layer
 Cardinality for Properties Instead of Cardinality from JCR Property
 Definition
In-Reply-To: <14660899.1237300762809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25539694.1237300900844.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-304:
--------------------------------

    Attachment: DNA-304.patch


Fix for the issue.  I have a test case for it as well, but it is tied up with the constraint changes.  I will upload it with those.

> SessionCache Uses Graph Layer Cardinality for Properties Instead of Cardinality from JCR Property Definition
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-304
>                 URL: https://jira.jboss.org/jira/browse/DNA-304
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-304.patch
>
>
> At the graph layer, property cardinality (whether the property is single- or multi-valued) is determined based on the values set on the property (i.e., any property with only one value is single-valued, any property with more than one value is multi-valued).   At the JCR layer, property cardinality is supposed to be based on the property definition in use for the property.  
> The SessionCache is currently basing the JCR layer cardinality on the graph layer cardinality instead of the JCR property definition.  
> Example:
> Consider a node that has one value for jcr:mixinTypes.  At the graph layer, this property will be single-valued.  At the JCR layer, this property should be multi-valued based on the jcr:mixinTypes property definition from the nt:base type (which is inherited by all nodes).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 11:47:46 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 17 Mar 2009 11:47:46 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-304) SessionCache Uses
 Graph Layer
 Cardinality for Properties Instead of Cardinality from JCR Property
 Definition
In-Reply-To: <14660899.1237300762809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21836260.1237304866478.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457682#action_12457682 ] 

Randall Hauch commented on DNA-304:
-----------------------------------

Applied the patch the corrected SessionCache to determine the multiplicity using the property definition rather than the number of values in the DNA property.  All current tests pass.

> SessionCache Uses Graph Layer Cardinality for Properties Instead of Cardinality from JCR Property Definition
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-304
>                 URL: https://jira.jboss.org/jira/browse/DNA-304
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-304.patch
>
>
> At the graph layer, property cardinality (whether the property is single- or multi-valued) is determined based on the values set on the property (i.e., any property with only one value is single-valued, any property with more than one value is multi-valued).   At the JCR layer, property cardinality is supposed to be based on the property definition in use for the property.  
> The SessionCache is currently basing the JCR layer cardinality on the graph layer cardinality instead of the JCR property definition.  
> Example:
> Consider a node that has one value for jcr:mixinTypes.  At the graph layer, this property will be single-valued.  At the JCR layer, this property should be multi-valued based on the jcr:mixinTypes property definition from the nt:base type (which is inherited by all nodes).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 12:36:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 17 Mar 2009 12:36:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-305)
 JcrNodeType.canSetProperty Does Not Enforce Constraints
Message-ID: <844610.1237307782830.JavaMail.jira@cloud.prod.atl2.jboss.com>

JcrNodeType.canSetProperty Does Not Enforce Constraints
-------------------------------------------------------

                 Key: DNA-305
                 URL: https://jira.jboss.org/jira/browse/DNA-305
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers


JCRNodeType.canSetProperty does not currently perform any validations against the constraints for the property.  This does not meet the JCR 1.0 specification and will probably cause L2 tests to fail in the TCK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 12:42:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 17 Mar 2009 12:42:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-305)
 JcrNodeType.canSetProperty Does Not Enforce Constraints
In-Reply-To: <844610.1237307782830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32801757.1237308143110.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-305:
--------------------------------

    Attachment: DNA-305.patch


Patch to add constraint checking capabilities to the property definition.  Constraints are lazily parsed and the resulting constraint checked is cached locally for reuse.

> JcrNodeType.canSetProperty Does Not Enforce Constraints
> -------------------------------------------------------
>
>                 Key: DNA-305
>                 URL: https://jira.jboss.org/jira/browse/DNA-305
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-305.patch
>
>
> JCRNodeType.canSetProperty does not currently perform any validations against the constraints for the property.  This does not meet the JCR 1.0 specification and will probably cause L2 tests to fail in the TCK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 17 17:39:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 17 Mar 2009 17:39:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-305)
 JcrNodeType.canSetProperty Does Not Enforce Constraints
In-Reply-To: <844610.1237307782830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30018549.1237325962494.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-305:
--------------------------------

    Attachment: DNA-305_revised.patch


Modifed previous patch to move logic from ConstraintCheckerFactory into JcrPropertyDefinition per IRC discussion

> JcrNodeType.canSetProperty Does Not Enforce Constraints
> -------------------------------------------------------
>
>                 Key: DNA-305
>                 URL: https://jira.jboss.org/jira/browse/DNA-305
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-305.patch, DNA-305_revised.patch
>
>
> JCRNodeType.canSetProperty does not currently perform any validations against the constraints for the property.  This does not meet the JCR 1.0 specification and will probably cause L2 tests to fail in the TCK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 00:40:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 00:40:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-304) SessionCache Uses
 Graph Layer
 Cardinality for Properties Instead of Cardinality from JCR Property
 Definition
In-Reply-To: <14660899.1237300762809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10903706.1237351222771.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457810#action_12457810 ] 

Randall Hauch commented on DNA-304:
-----------------------------------

Applied the changes to the test cases.

> SessionCache Uses Graph Layer Cardinality for Properties Instead of Cardinality from JCR Property Definition
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-304
>                 URL: https://jira.jboss.org/jira/browse/DNA-304
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 0.4
>
>         Attachments: DNA-304.patch
>
>
> At the graph layer, property cardinality (whether the property is single- or multi-valued) is determined based on the values set on the property (i.e., any property with only one value is single-valued, any property with more than one value is multi-valued).   At the JCR layer, property cardinality is supposed to be based on the property definition in use for the property.  
> The SessionCache is currently basing the JCR layer cardinality on the graph layer cardinality instead of the JCR property definition.  
> Example:
> Consider a node that has one value for jcr:mixinTypes.  At the graph layer, this property will be single-valued.  At the JCR layer, this property should be multi-valued based on the jcr:mixinTypes property definition from the nt:base type (which is inherited by all nodes).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 00:40:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 00:40:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-304) SessionCache Uses
 Graph Layer
 Cardinality for Properties Instead of Cardinality from JCR Property
 Definition
In-Reply-To: <14660899.1237300762809.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23604500.1237351222817.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-304.
-------------------------------

    Fix Version/s: 0.4
       Resolution: Done
         Assignee: Randall Hauch


Marking as resolved, since this appears to have fixed the issue and since we now have a test case for this condition.

> SessionCache Uses Graph Layer Cardinality for Properties Instead of Cardinality from JCR Property Definition
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-304
>                 URL: https://jira.jboss.org/jira/browse/DNA-304
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-304.patch
>
>
> At the graph layer, property cardinality (whether the property is single- or multi-valued) is determined based on the values set on the property (i.e., any property with only one value is single-valued, any property with more than one value is multi-valued).   At the JCR layer, property cardinality is supposed to be based on the property definition in use for the property.  
> The SessionCache is currently basing the JCR layer cardinality on the graph layer cardinality instead of the JCR property definition.  
> Example:
> Consider a node that has one value for jcr:mixinTypes.  At the graph layer, this property will be single-valued.  At the JCR layer, this property should be multi-valued based on the jcr:mixinTypes property definition from the nt:base type (which is inherited by all nodes).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 10:14:24 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 10:14:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-306) Add ability to run all
 TCK unit tests within Hudson, showing success and failure rate
Message-ID: <28370398.1237385664158.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add ability to run all TCK unit tests within Hudson, showing success and failure rate
-------------------------------------------------------------------------------------

                 Key: DNA-306
                 URL: https://jira.jboss.org/jira/browse/DNA-306
             Project: DNA
          Issue Type: Task
          Components: Development Environment, Testing
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Priority: Minor
             Fix For: 0.4


Currently our use of the JCR TCK unit tests (again, not the official TCK but a subset of what's run within the TCK) is handled within a JUnit test suite in the "dna-jcr" project, and as we develop new features we're uncommenting tests as we pass them.  This does not give us any information about how we're progressing.  We want to run the tests (perhaps nightly) and make these stats available to let people know how we're doing and proceeding towards Level 1 and Level 2 compatibility.

Comments, thoughts, and approaches welcome.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 10:18:49 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 10:18:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-306) Add ability to run
 all TCK unit tests within Hudson, showing success and failure rate
In-Reply-To: <28370398.1237385664158.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22379185.1237385929325.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457907#action_12457907 ] 

Randall Hauch commented on DNA-306:
-----------------------------------

One approach to doing this is to create another project dependent upon "dna-jcr" and that has a class similar to "JcrTckTest".  Then, create a Maven profile in the parent POM that includes these tests (or runs only them, although we're not yet publishing snapshots).  Finally, we could create another Hudson job to run this profile nightly (or on some other schedule).

It would be ideal if the Hudson results would distinguish the Level 1, Level 2, and optional tests.  Currently, the JcrTckTest results don't really show this breakdown, so we may want to break them down into multiple unit test classes.

> Add ability to run all TCK unit tests within Hudson, showing success and failure rate
> -------------------------------------------------------------------------------------
>
>                 Key: DNA-306
>                 URL: https://jira.jboss.org/jira/browse/DNA-306
>             Project: DNA
>          Issue Type: Task
>          Components: Development Environment, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> Currently our use of the JCR TCK unit tests (again, not the official TCK but a subset of what's run within the TCK) is handled within a JUnit test suite in the "dna-jcr" project, and as we develop new features we're uncommenting tests as we pass them.  This does not give us any information about how we're progressing.  We want to run the tests (perhaps nightly) and make these stats available to let people know how we're doing and proceeding towards Level 1 and Level 2 compatibility.
> Comments, thoughts, and approaches welcome.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 10:28:22 2009
From: jira-events at lists.jboss.org (Steve Jacobs (JIRA))
Date: Wed, 18 Mar 2009 10:28:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-306) Add ability to run
 all TCK unit tests within Hudson, showing success and failure rate
In-Reply-To: <28370398.1237385664158.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1026626.1237386502787.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457916#action_12457916 ] 

Steve Jacobs commented on DNA-306:
----------------------------------

Yes - distinguishing between the test levels will be very helpful to anyone looking to adopt DNA or replace their existing repository.

> Add ability to run all TCK unit tests within Hudson, showing success and failure rate
> -------------------------------------------------------------------------------------
>
>                 Key: DNA-306
>                 URL: https://jira.jboss.org/jira/browse/DNA-306
>             Project: DNA
>          Issue Type: Task
>          Components: Development Environment, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> Currently our use of the JCR TCK unit tests (again, not the official TCK but a subset of what's run within the TCK) is handled within a JUnit test suite in the "dna-jcr" project, and as we develop new features we're uncommenting tests as we pass them.  This does not give us any information about how we're progressing.  We want to run the tests (perhaps nightly) and make these stats available to let people know how we're doing and proceeding towards Level 1 and Level 2 compatibility.
> Comments, thoughts, and approaches welcome.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 11:55:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 11:55:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-307) Build process needs to
 allow for
 DNA to be deployable within a container such as JBoss AS/EAP
Message-ID: <29350772.1237391722300.JavaMail.jira@cloud.prod.atl2.jboss.com>

Build process needs to allow for DNA to be deployable within a container such as JBoss AS/EAP
---------------------------------------------------------------------------------------------

                 Key: DNA-307
                 URL: https://jira.jboss.org/jira/browse/DNA-307
             Project: DNA
          Issue Type: Feature Request
          Components: Server
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


DNA should be built such that it can be deployed in and made available to other applications (e.g, JBoss Tools, Teiid Designer, etc.) via a container such as JBoss AS/ESP.  The Maven build process would need to produce a WAR file, and we need to determine how configuration affects this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:08:46 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:08:46 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Deleted: (DNA-307) Build process needs to
 allow for
 DNA to be deployable within a container such as JBoss AS/EAP
Message-ID: <9562683.1237392526853.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnny Verhaeg deleted DNA-307:
-------------------------------


> Build process needs to allow for DNA to be deployable within a container such as JBoss AS/EAP
> ---------------------------------------------------------------------------------------------
>
>                 Key: DNA-307
>                 URL: https://jira.jboss.org/jira/browse/DNA-307
>             Project: DNA
>          Issue Type: Feature Request
>            Reporter: Johnny Verhaeg
>
> DNA should be built such that it can be deployed in and made available to other applications (e.g, JBoss Tools, Teiid Designer, etc.) via a container such as JBoss AS/ESP.  The Maven build process would need to produce a WAR file, and we need to determine how configuration affects this.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:08:46 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:08:46 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-308) Develop Eclipse
 plug-in that provides simple publishing capabilities
Message-ID: <8122682.1237392526796.JavaMail.jira@cloud.prod.atl2.jboss.com>

Develop Eclipse plug-in that provides simple publishing capabilities
--------------------------------------------------------------------

                 Key: DNA-308
                 URL: https://jira.jboss.org/jira/browse/DNA-308
             Project: DNA
          Issue Type: Feature Request
          Components: API
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


Providing an Eclipse plug-in to access DNA would provide applications such as JBoss Tools immediate ability to integrate with DNA.  The plug-in should initially provide simple capabilities such as:
- Managing connections to one or more DNA repositories
- Publishing files, specifically those in an Eclipse workspace
- Un-publishing files

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:15:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:15:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-309) Design URLs,
 leaving room for future UI features and maybe WebDAV
Message-ID: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>

Design URLs, leaving room for future UI features and maybe WebDAV
-----------------------------------------------------------------

                 Key: DNA-309
                 URL: https://jira.jboss.org/jira/browse/DNA-309
             Project: DNA
          Issue Type: Sub-task
          Components: Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:19:38 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:19:38 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-310) Create dna-web
 subproject, with primary artifact being WAR file
Message-ID: <25392891.1237393178475.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create dna-web subproject, with primary artifact being WAR file
---------------------------------------------------------------

                 Key: DNA-310
                 URL: https://jira.jboss.org/jira/browse/DNA-310
             Project: DNA
          Issue Type: Sub-task
          Components: Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


DNA should be provided via a WAR file so that it can be deployed in and made available to applications such as JBoss Tools, Teiid Designer, etc., via a container such as JBoss AS/EASP.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:27:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:27:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-311) Use RESTEasy (and
 JAX-RS API) to
 implement Java classes with methods for publishing and un-publishing
 content
Message-ID: <1899590.1237393642272.JavaMail.jira@cloud.prod.atl2.jboss.com>

Use RESTEasy (and JAX-RS API) to implement Java classes with methods for publishing and un-publishing content
-------------------------------------------------------------------------------------------------------------

                 Key: DNA-311
                 URL: https://jira.jboss.org/jira/browse/DNA-311
             Project: DNA
          Issue Type: Sub-task
          Components: Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


Note, RESTEasy also implements AtomPub

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:29:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:29:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-312) Implement HTTP GET
 action for any resource at any path (folder or file)
Message-ID: <30424163.1237393762745.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement HTTP GET action for any resource at any path (folder or file)
-----------------------------------------------------------------------

                 Key: DNA-312
                 URL: https://jira.jboss.org/jira/browse/DNA-312
             Project: DNA
          Issue Type: Sub-task
          Components: Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


This provides basic read capability of the artifacts published to the repository

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:33:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:33:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-313) Implement HTTP PUT
 action for any resource at any path (folder or file)
Message-ID: <15735318.1237394002292.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement HTTP PUT action for any resource at any path (folder or file)
-----------------------------------------------------------------------

                 Key: DNA-313
                 URL: https://jira.jboss.org/jira/browse/DNA-313
             Project: DNA
          Issue Type: Sub-task
          Components: Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


Provides basic publish capability

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:35:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:35:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-314) Implement HTTP POST
 action for any resource at any path (folder or file)
Message-ID: <24399333.1237394122523.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement HTTP POST action for any resource at any path (folder or file)
------------------------------------------------------------------------

                 Key: DNA-314
                 URL: https://jira.jboss.org/jira/browse/DNA-314
             Project: DNA
          Issue Type: Sub-task
          Components: Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


Not sure yet what this action would do other than duplicate a PUT

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:37:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:37:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-315) Implement HTTP DELETE
 action for any resource at any path (folder or file)
Message-ID: <25391097.1237394242588.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement HTTP DELETE action for any resource at any path (folder or file)
--------------------------------------------------------------------------

                 Key: DNA-315
                 URL: https://jira.jboss.org/jira/browse/DNA-315
             Project: DNA
          Issue Type: Sub-task
          Components: Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


Provides basic un-publish capability

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:39:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:39:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-316) Get DNA running in a
 web app and used by JAX-RS classes
Message-ID: <15203247.1237394362511.JavaMail.jira@cloud.prod.atl2.jboss.com>

Get DNA running in a web app and used by JAX-RS classes
-------------------------------------------------------

                 Key: DNA-316
                 URL: https://jira.jboss.org/jira/browse/DNA-316
             Project: DNA
          Issue Type: Sub-task
          Components: Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


We still have to determine what presentation technology to start with (GWT, Flex, JavaFX, Seam, etc.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-312) Implement HTTP GET
 action for any resource at any path (folder or file)
In-Reply-To: <30424163.1237393762745.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30268222.1237394503144.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-312:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Implement HTTP GET action for any resource at any path (folder or file)
> -----------------------------------------------------------------------
>
>                 Key: DNA-312
>                 URL: https://jira.jboss.org/jira/browse/DNA-312
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> This provides basic read capability of the artifacts published to the repository

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-311) Use RESTEasy (and
 JAX-RS API) to
 implement Java classes with methods for publishing and un-publishing
 content
In-Reply-To: <1899590.1237393642272.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12866433.1237394503196.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-311:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Use RESTEasy (and JAX-RS API) to implement Java classes with methods for publishing and un-publishing content
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-311
>                 URL: https://jira.jboss.org/jira/browse/DNA-311
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Note, RESTEasy also implements AtomPub

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:41 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:41:41 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-317) Integrate and test by
 deploying into container
Message-ID: <6645297.1237394501447.JavaMail.jira@cloud.prod.atl2.jboss.com>

Integrate and test by deploying into container
----------------------------------------------

                 Key: DNA-317
                 URL: https://jira.jboss.org/jira/browse/DNA-317
             Project: DNA
          Issue Type: Sub-task
          Components: Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


Such as JBoss AS/EAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-317) Integrate and test by
 deploying into container
In-Reply-To: <6645297.1237394501447.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20071282.1237394503244.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-317:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Integrate and test by deploying into container
> ----------------------------------------------
>
>                 Key: DNA-317
>                 URL: https://jira.jboss.org/jira/browse/DNA-317
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Such as JBoss AS/EAP

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-316) Get DNA running in a
 web app and used by JAX-RS classes
In-Reply-To: <15203247.1237394362511.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22809590.1237394503284.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-316:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Get DNA running in a web app and used by JAX-RS classes
> -------------------------------------------------------
>
>                 Key: DNA-316
>                 URL: https://jira.jboss.org/jira/browse/DNA-316
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> We still have to determine what presentation technology to start with (GWT, Flex, JavaFX, Seam, etc.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-310) Create dna-web
 subproject, with primary artifact being WAR file
In-Reply-To: <25392891.1237393178475.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2656292.1237394503323.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-310:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Create dna-web subproject, with primary artifact being WAR file
> ---------------------------------------------------------------
>
>                 Key: DNA-310
>                 URL: https://jira.jboss.org/jira/browse/DNA-310
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> DNA should be provided via a WAR file so that it can be deployed in and made available to applications such as JBoss Tools, Teiid Designer, etc., via a container such as JBoss AS/EASP.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-314) Implement HTTP POST
 action for any resource at any path (folder or file)
In-Reply-To: <24399333.1237394122523.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8859496.1237394503365.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-314:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Implement HTTP POST action for any resource at any path (folder or file)
> ------------------------------------------------------------------------
>
>                 Key: DNA-314
>                 URL: https://jira.jboss.org/jira/browse/DNA-314
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Not sure yet what this action would do other than duplicate a PUT

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-308) Develop Eclipse
 plug-in that provides simple publishing capabilities
In-Reply-To: <8122682.1237392526796.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <658997.1237394503410.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-308:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Develop Eclipse plug-in that provides simple publishing capabilities
> --------------------------------------------------------------------
>
>                 Key: DNA-308
>                 URL: https://jira.jboss.org/jira/browse/DNA-308
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Providing an Eclipse plug-in to access DNA would provide applications such as JBoss Tools immediate ability to integrate with DNA.  The plug-in should initially provide simple capabilities such as:
> - Managing connections to one or more DNA repositories
> - Publishing files, specifically those in an Eclipse workspace
> - Un-publishing files

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-315) Implement HTTP DELETE
 action for any resource at any path (folder or file)
In-Reply-To: <25391097.1237394242588.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32476043.1237394503092.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-315:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Implement HTTP DELETE action for any resource at any path (folder or file)
> --------------------------------------------------------------------------
>
>                 Key: DNA-315
>                 URL: https://jira.jboss.org/jira/browse/DNA-315
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Provides basic un-publish capability

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-309) Design URLs,
 leaving room for future UI features and maybe WebDAV
In-Reply-To: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16047289.1237394503449.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-309:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Design URLs, leaving room for future UI features and maybe WebDAV
> -----------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:41:43 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:41:43 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-313) Implement HTTP PUT
 action for any resource at any path (folder or file)
In-Reply-To: <15735318.1237394002292.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8659060.1237394503494.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-313:
------------------------------

    Fix Version/s: 0.5


Targeting to the next release (currently named 0.5)

> Implement HTTP PUT action for any resource at any path (folder or file)
> -----------------------------------------------------------------------
>
>                 Key: DNA-313
>                 URL: https://jira.jboss.org/jira/browse/DNA-313
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Provides basic publish capability

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:43:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:43:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-318) Provide
 documentation/examples/tutorial explaining use of RESTful API
Message-ID: <8849439.1237394602464.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide documentation/examples/tutorial explaining use of RESTful API
---------------------------------------------------------------------

                 Key: DNA-318
                 URL: https://jira.jboss.org/jira/browse/DNA-318
             Project: DNA
          Issue Type: Sub-task
          Components: Documentation, Web Application
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:49:23 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:49:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-319) Create plug-in project
	in SVN
Message-ID: <26330711.1237394963598.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create plug-in project in SVN
-----------------------------

                 Key: DNA-319
                 URL: https://jira.jboss.org/jira/browse/DNA-319
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg


Unlike other DNA projects, this project will be built using an Eclipse IDE or Ant tasks, and not using Maven, unless we can figure out some way to maintain the Eclipse manifest, build.properties, plugin.xml, etc. in the Maven world.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:49:23 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:49:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-319) Create plug-in project
	in SVN
In-Reply-To: <26330711.1237394963598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9078039.1237394963644.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnny Verhaeg updated DNA-319:
-------------------------------

    Fix Version/s: 0.5


> Create plug-in project in SVN
> -----------------------------
>
>                 Key: DNA-319
>                 URL: https://jira.jboss.org/jira/browse/DNA-319
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Unlike other DNA projects, this project will be built using an Eclipse IDE or Ant tasks, and not using Maven, unless we can figure out some way to maintain the Eclipse manifest, build.properties, plugin.xml, etc. in the Maven world.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:52:40 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:52:40 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-320) Create connection
	management view
Message-ID: <16194240.1237395160384.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create connection management view
---------------------------------

                 Key: DNA-320
                 URL: https://jira.jboss.org/jira/browse/DNA-320
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


To create and maintain connections to one or more repositories deployed in a container

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:56:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 12:56:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25405697.1237395382540.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457985#action_12457985 ] 

Randall Hauch commented on DNA-194:
-----------------------------------

Improved the mutable versions of the cached reprentations, and added a large number of unit tests.  The mutable objects should be ready to track adding/removing children and adding/changing/removing properties.  Making the SessionCache to use them is next.

> Implement update JCR capability
> -------------------------------
>
>                 Key: DNA-194
>                 URL: https://jira.jboss.org/jira/browse/DNA-194
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-194-session-cache.patch, DNA-194_move_value_cast.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 12:58:23 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 12:58:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-321) Create
	publishing-related actions
Message-ID: <5477247.1237395503468.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create publishing-related actions
---------------------------------

                 Key: DNA-321
                 URL: https://jira.jboss.org/jira/browse/DNA-321
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


Minimally to publish (tied to HTTP PUT action) and un-publish (tied to HTTP DELETE) files or folders.  Should also action for retrieving what has been published to repository, but to be complete this will require an additional task that provides a view for browsing the results.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:00:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:00:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-322) Create context menu
 and menu bar items tied to publishing actions
Message-ID: <24871012.1237395622388.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create context menu and menu bar items tied to publishing actions
-----------------------------------------------------------------

                 Key: DNA-322
                 URL: https://jira.jboss.org/jira/browse/DNA-322
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:02:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:02:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-322) Create context menu
 and menu bar items tied to publishing actions
In-Reply-To: <24871012.1237395622388.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32899195.1237395742340.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnny Verhaeg updated DNA-322:
-------------------------------

    Description: The context menu items would at a minimum appear in context menus for views representing content in a workspace


> Create context menu and menu bar items tied to publishing actions
> -----------------------------------------------------------------
>
>                 Key: DNA-322
>                 URL: https://jira.jboss.org/jira/browse/DNA-322
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> The context menu items would at a minimum appear in context menus for views representing content in a workspace

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:04:24 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:04:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-321) Create
	publishing-related actions
In-Reply-To: <5477247.1237395503468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32255556.1237395864375.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457989#action_12457989 ] 

Johnny Verhaeg commented on DNA-321:
------------------------------------

All actions should log their activity

> Create publishing-related actions
> ---------------------------------
>
>                 Key: DNA-321
>                 URL: https://jira.jboss.org/jira/browse/DNA-321
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Minimally to publish (tied to HTTP PUT action) and un-publish (tied to HTTP DELETE) files or folders.  Should also action for retrieving what has been published to repository, but to be complete this will require an additional task that provides a view for browsing the results.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:06:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:06:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-323) Create view of
 artifacts published in repositories
Message-ID: <31794775.1237395982713.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create view of artifacts published in repositories
--------------------------------------------------

                 Key: DNA-323
                 URL: https://jira.jboss.org/jira/browse/DNA-323
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


View should allow for multiple repositories, be activated via context menu and menu bar items that reside next to publishing-related actions, and should show mapping to associated workspace items.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:08:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 13:08:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-305)
 JcrNodeType.canSetProperty Does Not Enforce Constraints
In-Reply-To: <844610.1237307782830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11324033.1237396102721.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457992#action_12457992 ] 

Randall Hauch commented on DNA-305:
-----------------------------------

Applied the patch, which is an interim commit to add in the constraint checking.  Future changes will remove the JcrSession references from JcrNodeTypeManager, JcrPropertyDefinition, etc. under DNA-302.

> JcrNodeType.canSetProperty Does Not Enforce Constraints
> -------------------------------------------------------
>
>                 Key: DNA-305
>                 URL: https://jira.jboss.org/jira/browse/DNA-305
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-305.patch, DNA-305_revised.patch
>
>
> JCRNodeType.canSetProperty does not currently perform any validations against the constraints for the property.  This does not meet the JCR 1.0 specification and will probably cause L2 tests to fail in the TCK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:10:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:10:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-324) Create
 publishing-related
 decorators that can be attached to workspace-related views
Message-ID: <19751728.1237396222571.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create publishing-related decorators that can be attached to workspace-related views
------------------------------------------------------------------------------------

                 Key: DNA-324
                 URL: https://jira.jboss.org/jira/browse/DNA-324
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


We may want to model our approach after SCM repository plug-ins, while making sure we don't conflict with those plug-ins or "over-decorate".

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:14:39 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:14:39 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-321) Create
	publishing-related actions
In-Reply-To: <5477247.1237395503468.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19482185.1237396479707.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457996#action_12457996 ] 

Johnny Verhaeg commented on DNA-321:
------------------------------------

Unpublish action should only be enabled when item is determined to be published

> Create publishing-related actions
> ---------------------------------
>
>                 Key: DNA-321
>                 URL: https://jira.jboss.org/jira/browse/DNA-321
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Minimally to publish (tied to HTTP PUT action) and un-publish (tied to HTTP DELETE) files or folders.  Should also action for retrieving what has been published to repository, but to be complete this will require an additional task that provides a view for browsing the results.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:14:39 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 18 Mar 2009 13:14:39 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-305)
 JcrNodeType.canSetProperty Does Not Enforce Constraints
In-Reply-To: <844610.1237307782830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32867647.1237396479747.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12457997#action_12457997 ] 

Brian Carothers commented on DNA-305:
-------------------------------------

This revision does not correctly handle the case of a path constraint consisting of segments with namespaces when the namespaces are remapped.  For example, if the constraint value is 'myapp:foo/myapp:bar', the current code will not work correctly if the "myapp" prefix is transiently remapped to "myapp2"

> JcrNodeType.canSetProperty Does Not Enforce Constraints
> -------------------------------------------------------
>
>                 Key: DNA-305
>                 URL: https://jira.jboss.org/jira/browse/DNA-305
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-305.patch, DNA-305_revised.patch
>
>
> JCRNodeType.canSetProperty does not currently perform any validations against the constraints for the property.  This does not meet the JCR 1.0 specification and will probably cause L2 tests to fail in the TCK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:18:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:18:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-325) Create preference page
 for working with DNA
Message-ID: <9917150.1237396702286.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create preference page for working with DNA
-------------------------------------------

                 Key: DNA-325
                 URL: https://jira.jboss.org/jira/browse/DNA-325
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


Page would include ability to modify decorators, logging levels, etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:21:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:21:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-326) Create documentation
Message-ID: <13759744.1237396882299.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create documentation
--------------------

                 Key: DNA-326
                 URL: https://jira.jboss.org/jira/browse/DNA-326
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


- Feature welcome page
- Links from Eclipse welcome page
- Normal User's guide/Help docs
- Links from dialog "question mark" icon
- Links from dialog "light-bulbs" (optional)
- Cheatsheets (optional)


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:25:41 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:25:41 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-327) Create feature
Message-ID: <13711834.1237397141278.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create feature
--------------

                 Key: DNA-327
                 URL: https://jira.jboss.org/jira/browse/DNA-327
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


including about dialog icons and settings, icons for use within views and wizards, etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:27:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:27:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-327) Create feature
In-Reply-To: <13711834.1237397141278.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11470875.1237397242470.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnny Verhaeg updated DNA-327:
-------------------------------

    Description: including about dialog icons and settings, etc.  (was: including about dialog icons and settings, icons for use within views and wizards, etc.)


> Create feature
> --------------
>
>                 Key: DNA-327
>                 URL: https://jira.jboss.org/jira/browse/DNA-327
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> including about dialog icons and settings, etc.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:27:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 13:27:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-305)
 JcrNodeType.canSetProperty Does Not Enforce Constraints
In-Reply-To: <844610.1237307782830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8396909.1237397242429.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458002#action_12458002 ] 

Randall Hauch commented on DNA-305:
-----------------------------------

Could the namespace issue be addressed by just storing the fully-qualified (unprefixed) paths?  From JSR-170 1.0.1 Section 6.7.16:

    The constraint string returned must reflect the namespace mapping in the current Session (i.e., the 
    current state of the namespace registry overlaid with any session-specific mappings). Constraint strings for 
    PATH properties should be stored in fully-qualified form (using the actual URI instead of the prefix) and then be 
    converted to prefix form according to the current mapping. 


> JcrNodeType.canSetProperty Does Not Enforce Constraints
> -------------------------------------------------------
>
>                 Key: DNA-305
>                 URL: https://jira.jboss.org/jira/browse/DNA-305
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-305.patch, DNA-305_revised.patch
>
>
> JCRNodeType.canSetProperty does not currently perform any validations against the constraints for the property.  This does not meet the JCR 1.0 specification and will probably cause L2 tests to fail in the TCK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:27:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:27:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-319) Create plug-in
	project in SVN
In-Reply-To: <26330711.1237394963598.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2897034.1237397242353.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458001#action_12458001 ] 

Johnny Verhaeg commented on DNA-319:
------------------------------------

Need to provide icons for use in views and wizards

> Create plug-in project in SVN
> -----------------------------
>
>                 Key: DNA-319
>                 URL: https://jira.jboss.org/jira/browse/DNA-319
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Unlike other DNA projects, this project will be built using an Eclipse IDE or Ant tasks, and not using Maven, unless we can figure out some way to maintain the Eclipse manifest, build.properties, plugin.xml, etc. in the Maven world.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:29:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:29:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-328) Create update site
Message-ID: <15378134.1237397362425.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create update site
------------------

                 Key: DNA-328
                 URL: https://jira.jboss.org/jira/browse/DNA-328
             Project: DNA
          Issue Type: Sub-task
          Components: Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


Include update site URL on project site

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:31:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:31:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-329) Create build scripts
 for integration with Hudson and running of continuous tests
Message-ID: <23285601.1237397482306.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create build scripts for integration with Hudson and running of continuous tests
--------------------------------------------------------------------------------

                 Key: DNA-329
                 URL: https://jira.jboss.org/jira/browse/DNA-329
             Project: DNA
          Issue Type: Sub-task
          Components: Testing, Views
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:31:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:31:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-326) Create documentation
In-Reply-To: <13759744.1237396882299.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29513859.1237397482346.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnny Verhaeg updated DNA-326:
-------------------------------

    Component/s: Documentation


> Create documentation
> --------------------
>
>                 Key: DNA-326
>                 URL: https://jira.jboss.org/jira/browse/DNA-326
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Documentation, Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> - Feature welcome page
> - Links from Eclipse welcome page
> - Normal User's guide/Help docs
> - Links from dialog "question mark" icon
> - Links from dialog "light-bulbs" (optional)
> - Cheatsheets (optional)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:37:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:37:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-330) Develop sequencer that
 uses Teiid MMR shredder library
Message-ID: <6937011.1237397842557.JavaMail.jira@cloud.prod.atl2.jboss.com>

Develop sequencer that uses Teiid MMR shredder library
------------------------------------------------------

                 Key: DNA-330
                 URL: https://jira.jboss.org/jira/browse/DNA-330
             Project: DNA
          Issue Type: Feature Request
          Components: Sequencers
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


This sequencer, along with the DNA-55 and DNA-308, will provide Teiid users with equivalent capabilities offered in the MetaMatrix proprietary product for shredding models and metamodels in a metadata repository and querying that metadata via the Teiid MMR.VDB.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:39:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:39:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-331) Create subproject for
	sequencer
Message-ID: <7652237.1237397962509.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create subproject for sequencer
-------------------------------

                 Key: DNA-331
                 URL: https://jira.jboss.org/jira/browse/DNA-331
             Project: DNA
          Issue Type: Sub-task
          Components: Sequencers
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


Not sure where this should live - the extensions folder, the sandbox, or under some other "DNA add-on" folder

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:41:33 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 13:41:33 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-332) Implement sequencer to
 use Teiid MMR shredder library
Message-ID: <3145672.1237398093101.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement sequencer to use Teiid MMR shredder library
-----------------------------------------------------

                 Key: DNA-332
                 URL: https://jira.jboss.org/jira/browse/DNA-332
             Project: DNA
          Issue Type: Sub-task
          Components: Sequencers
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.5


The sequencer will most likely use JNDI to obtain a data source from the container and pass it to the shredder

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 13:59:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 18 Mar 2009 13:59:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-55) REST-based API for
 remote access and usage
Message-ID: <3490866.1237399162340.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-55:
-----------------------------

    Fix Version/s: 0.5
                       (was: 0.4)


Changed the target release from 0.4 to 0.5 to reflect current roadmap.

We should definitely look at using RESTeasy, since that's a JAX-RS implementation that makes it pretty easy to make something that can deploy to a number of web/app servers.

> REST-based API for remote access and usage
> ------------------------------------------
>
>                 Key: DNA-55
>                 URL: https://jira.jboss.org/jira/browse/DNA-55
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Server, Web Application
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>
> Create a DNA server that uses a REST-based API, allowing client applications to access and use the repository using HTTP for protocol/transport.  
> AtomPub is also very interesting (as it is RESTful) for a message structure, but it doesn't currently support hierarchical data.  And although one could build a repository to be flatter (or at least exposed though collections; see how Bento does it: http://www.filemaker.com/bento/), it may be difficult to have no way of interacting with the hierarchical data.  Bento and iTunes both show how powerful user-defined collections (and "smart collections") can be, so maybe adopting a collection-only approach would work (at least for remote access).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Wed Mar 18 14:25:22 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Wed, 18 Mar 2009 14:25:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-308) Develop Eclipse
 plug-in that provides simple publishing capabilities
In-Reply-To: <8122682.1237392526796.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15888513.1237400722500.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Johnny Verhaeg updated DNA-308:
-------------------------------

    Component/s: Views
                     (was: API)


> Develop Eclipse plug-in that provides simple publishing capabilities
> --------------------------------------------------------------------
>
>                 Key: DNA-308
>                 URL: https://jira.jboss.org/jira/browse/DNA-308
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Providing an Eclipse plug-in to access DNA would provide applications such as JBoss Tools immediate ability to integrate with DNA.  The plug-in should initially provide simple capabilities such as:
> - Managing connections to one or more DNA repositories
> - Publishing files, specifically those in an Eclipse workspace
> - Un-publishing files

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 19 10:36:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 19 Mar 2009 10:36:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-309) Design URLs,
 leaving room for future UI features and maybe WebDAV
In-Reply-To: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8220375.1237473383372.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458131#action_12458131 ] 

Randall Hauch commented on DNA-309:
-----------------------------------

The most obvious first approach for a URI design is to directly represent each node in the repository as a resource, and to map the repository operations to GET (read), PUT (update/create), POST (create), and DELETE (delete).  For example, "/a/b/c/d" would identify the node "/a/b/c/d".  A "GET /a/b/c/d" request would obtain a representation of the "/a/b/c/d" node.

Perhaps the first challenge to this approach is whether to also treat properties as resources.  If each property were treated as a resource, then the URI design would have to distinguish a node property named the same as a that of a child of the same node.  For example, if a node /a/b/c in the previous example contained a child "d" and a property "d", then is "/a/b/c/d" referring to the node or the property?  One option is to distinguish properties with a character ('@' comes to mind), although which character would depend on URL escaping requirements.  It probably is possible to require this character only when there is a child with the same name as a property name (something that is not too frequent, I expect).

The kind of resource to return (e.g., JSON, XML, HTML, etc.) should be driven by the "accept" HTTP header, which specifies the media ranges (mime types with optional parameters) that are being requested.  Multiple mime types can be specified, with precedence rules and quality factor denoting the preferred order.  See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html  By using the HTTP header, the URI no longer needs to deal with extensions or any other mechanism to denote the desired response format.  And this means that the URI design can more closely match the resource names.  Here's an example of a GET request to obtain a JSON representation of node "/a/b/c/d":

 GET /a/b/c/d
 Host: myhost.example.com
 Accept: application/json

URI query parameters are useful to supply additional criteria and information about the representation to be returned, such as depth of the representation or reading just the properties or children.  This seems to be an acceptable way of affecting the representation.

What about operations, like move or copy?  One choice is to use query parameters (e.g., PUT with a "?moveTo=/a/b/e" or POST with a "?copyOf=/a/b/e").  Another option would be to allow actions or operations in the representation that is PUT by the client.  The following example is an HTTP request to move node "/a/b/c/d" to "/a/b/e" and simultaneously set the "jcr:title" property to "This is a new title":

 PUT /a/b/c/d
 Host: host.example.com
 Accept: application/json
 Content-Length: nnn
 Content-Type: application/json
 
 {
   "dna-action:moveTo": "/a/b/e"
   "jcr:title" : "This is the new title"
 }

> Design URLs, leaving room for future UI features and maybe WebDAV
> -----------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 19 10:47:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 19 Mar 2009 10:47:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-309) Design URLs,
 leaving room for future UI features and maybe WebDAV
In-Reply-To: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10353736.1237474042661.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458139#action_12458139 ] 

Randall Hauch commented on DNA-309:
-----------------------------------

The URI design may need to make room for different repositories, workspaces, etc.  The first segment of the URI (below the host or application URI) might specify the repository name, the second the workspace name, followed by the path to the node.  For example:

    /repoA/myWorkspace/a/b/c/d

would identify the node "/a/b/c/d" in the "myWorkspace" workspace of the "repoA" repository configured by the RESTful server.  

What about searching?  Well, search could be done using the "/search" URI, making that a reserved name and unusable for the repository name in the configuration.  That probably is pretty acceptable.  

What about a web application for users to view, navigate, edit the content through a browser?  Well, its quite likely that this application would be in a different WAR (perhaps still deployed to the same server).  However, there are two options if the web app is to be in the same WAR file: reserve the "/ui" URI for this (might be a good idea anyway), or simply use the HTTP accept header to specify that a client wants the (probably rich) HTML for a resource.

> Design URLs, leaving room for future UI features and maybe WebDAV
> -----------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 19 10:47:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 19 Mar 2009 10:47:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-309) Design URLs,
 leaving room for future UI features and maybe WebDAV
In-Reply-To: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11143312.1237474042697.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458140#action_12458140 ] 

Randall Hauch commented on DNA-309:
-----------------------------------

I just ran across this blog entry (http://www.michaelnygard.com/blog/2009/03/update_sun_cloud_api_not_the_s.html) that praises the Sun Cloud API, is which a RESTful API for creating and managing cloud resources.  The most interesting thing is that it is fully discoverable, since you start by doing a "GET /" with the resulting JSON response telling you what requests are allowed.  (Each pair under a parent is either a name/string pair or a name/resource pair, where the resource is given by a URI fragment that is the resource that applies.)  Subsequent requests result in similar JSON responses.  See http://kenai.com/projects/suncloudapis/pages/HelloCloud for an example interaction.

BTW, JSON is that it is a great match for representing tree structures, and would be a great approach for the representations returned by this RESTful server.  After all, DNA and JCR repository content is really a tree (with property values referring to other nodes making it a graph).

> Design URLs, leaving room for future UI features and maybe WebDAV
> -----------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar 20 12:11:35 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Mar 2009 12:11:35 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-55) Web Application with
 REST-based API for remote access and usage
Message-ID: <7118728.1237565495150.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-55:
-----------------------------

    Summary: Web Application with REST-based API for remote access and usage  (was: REST-based API for remote access and usage)


> Web Application with REST-based API for remote access and usage
> ---------------------------------------------------------------
>
>                 Key: DNA-55
>                 URL: https://jira.jboss.org/jira/browse/DNA-55
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Server, Web Application
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>
> Create a DNA server that uses a REST-based API, allowing client applications to access and use the repository using HTTP for protocol/transport.  
> AtomPub is also very interesting (as it is RESTful) for a message structure, but it doesn't currently support hierarchical data.  And although one could build a repository to be flatter (or at least exposed though collections; see how Bento does it: http://www.filemaker.com/bento/), it may be difficult to have no way of interacting with the hierarchical data.  Bento and iTunes both show how powerful user-defined collections (and "smart collections") can be, so maybe adopting a collection-only approach would work (at least for remote access).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar 20 12:16:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Mar 2009 12:16:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-308) Eclipse plug-in
 providing simple publishing capabilities
In-Reply-To: <8122682.1237392526796.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1301875.1237565782384.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-308:
------------------------------

        Summary: Eclipse plug-in providing simple publishing capabilities  (was: Develop Eclipse plug-in that provides simple publishing capabilities)
    Description: 
Providing an Eclipse plug-in to access DNA would provide applications such as JBoss Tools immediate ability to integrate with DNA by publishing files to a JBoss DNA Web Application with RESTful API.  

The plug-in should initially provide simple capabilities such as:
- Managing connections to one or more DNA repositories
- Publishing files, specifically those in an Eclipse workspace
- Un-publishing files

  was:
Providing an Eclipse plug-in to access DNA would provide applications such as JBoss Tools immediate ability to integrate with DNA.  The plug-in should initially provide simple capabilities such as:
- Managing connections to one or more DNA repositories
- Publishing files, specifically those in an Eclipse workspace
- Un-publishing files



> Eclipse plug-in providing simple publishing capabilities
> --------------------------------------------------------
>
>                 Key: DNA-308
>                 URL: https://jira.jboss.org/jira/browse/DNA-308
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> Providing an Eclipse plug-in to access DNA would provide applications such as JBoss Tools immediate ability to integrate with DNA by publishing files to a JBoss DNA Web Application with RESTful API.  
> The plug-in should initially provide simple capabilities such as:
> - Managing connections to one or more DNA repositories
> - Publishing files, specifically those in an Eclipse workspace
> - Un-publishing files

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar 20 12:16:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Mar 2009 12:16:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-330) Teiid model sequencer
 that uses the Teiid MMR shredder library
In-Reply-To: <6937011.1237397842557.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16025234.1237565782436.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-330:
------------------------------

    Summary: Teiid model sequencer that uses the Teiid MMR shredder library  (was: Develop sequencer that uses Teiid MMR shredder library)


> Teiid model sequencer that uses the Teiid MMR shredder library
> --------------------------------------------------------------
>
>                 Key: DNA-330
>                 URL: https://jira.jboss.org/jira/browse/DNA-330
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Sequencers
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> This sequencer, along with the DNA-55 and DNA-308, will provide Teiid users with equivalent capabilities offered in the MetaMatrix proprietary product for shredding models and metamodels in a metadata repository and querying that metadata via the Teiid MMR.VDB.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar 20 12:23:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 20 Mar 2009 12:23:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-302) Make
 JcrNodeTypeManager not dependent on JcrSession
In-Reply-To: <26976618.1237264222615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26513650.1237566202536.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-302:
--------------------------------

    Attachment: DNA-302.patch


Added patch to split JcrNodeTypeManager into repository-scoped functionality (RepositoryNodeTypeManager) and session-scoped functionality (JcrNodeTypeManager) with the key difference being that the session-scoped node type manager is able to translate names based on transient namespace remappings.

The RepositoryNodeTypeManager is the maintainer of node type information for the entire repository at run-time. The
repository manager maintains a list of all node types and the ability to retrieve node types by Name. 

The JCR 1.0 and 2.0 specifications both require that node type information be shared across all sessions within a 
repository and that the javax.jcr.NodeTypeManager perform operations based on the string versions of Names based 
on the permanent (workspace-scoped) and transient (session-scoped) namespace mappings. DNA achieves this by 
maintaining a single master repository of all node type information (the RepositoryNodeTypeManager) and per-session 
wrappers (JcrNodeTypeManager) for this master repository that perform String to Name translation based on the
javax.jcr.Session's transient mappings and then delegating node type lookups to the repository manager.

Also removed JcrSession references from all the type-related objects and replaced them with ExecutionContexts.

> Make JcrNodeTypeManager not dependent on JcrSession
> ---------------------------------------------------
>
>                 Key: DNA-302
>                 URL: https://jira.jboss.org/jira/browse/DNA-302
>             Project: DNA
>          Issue Type: Sub-task
>          Components: API, JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: DNA-302.patch
>
>
> The JcrNodeTypeManager should not be dependent upon a JcrSession instance.  Most of the methods (including those in JcrNodeType, JcrNodeDefinition, and JcrPropertyDefinition) only need an ExecutionContext.  JcrNodeDefinition.getDefaultPrimaryType() seems to depend upon the NodeTypeManager to dynamically look up a type (there may be others).  This main mean that the JcrNodeTypeManager needs a method to allow adding types from a JcrNodeTypeSource (rather than a JcrNodeTypeSource be passed into the constructor).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar 20 14:24:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Mar 2009 14:24:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21429668.1237573462602.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458431#action_12458431 ] 

Randall Hauch commented on DNA-194:
-----------------------------------

Added most of the infrastructure to allow updates to the SessionCache.  The cached representations of the nodes are changed and corresponding requests are accumulated in a Graph.Batch that are sent to the repository store when SessionCache.save() is called.  This implementation hooks some of the infrastructure up to the JcrAbstractNode implementation, although more tests need to be written to verify the behavior.  

Currently, only deleting nodes has been tested and is thought to be complete.  Changing properties, creating children, and moving nodes are partially implemented.  (Some changes to the node type manager are required, but there is currently an ongoing refactoring of JcrNodeTypeManager.  This is the primary reason for committing this partially-complete work.)

> Implement update JCR capability
> -------------------------------
>
>                 Key: DNA-194
>                 URL: https://jira.jboss.org/jira/browse/DNA-194
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-194-session-cache.patch, DNA-194_move_value_cast.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar 20 14:40:25 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Mar 2009 14:40:25 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-302) Make
 JcrNodeTypeManager not dependent on JcrSession
In-Reply-To: <26976618.1237264222615.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1644180.1237574425913.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458436#action_12458436 ] 

Randall Hauch commented on DNA-302:
-----------------------------------

Applied the patch.

> Make JcrNodeTypeManager not dependent on JcrSession
> ---------------------------------------------------
>
>                 Key: DNA-302
>                 URL: https://jira.jboss.org/jira/browse/DNA-302
>             Project: DNA
>          Issue Type: Sub-task
>          Components: API, JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: DNA-302.patch
>
>
> The JcrNodeTypeManager should not be dependent upon a JcrSession instance.  Most of the methods (including those in JcrNodeType, JcrNodeDefinition, and JcrPropertyDefinition) only need an ExecutionContext.  JcrNodeDefinition.getDefaultPrimaryType() seems to depend upon the NodeTypeManager to dynamically look up a type (there may be others).  This main mean that the JcrNodeTypeManager needs a method to allow adding types from a JcrNodeTypeSource (rather than a JcrNodeTypeSource be passed into the constructor).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar 20 18:37:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 20 Mar 2009 18:37:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-305)
 JcrNodeType.canSetProperty Does Not Enforce Constraints
In-Reply-To: <844610.1237307782830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26720775.1237588642739.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-305:
--------------------------------

    Attachment: DNA-305_path_namespace.patch


Added patch that makes path constraints support transient namespace remapping and modified test cases to verify this.  Also moved test node type into class to clean up the package and make JcrPropertyDefinitionTest more consistent with the approach in SessionCacheTest.  This fix should allow the defect to be resolved.

> JcrNodeType.canSetProperty Does Not Enforce Constraints
> -------------------------------------------------------
>
>                 Key: DNA-305
>                 URL: https://jira.jboss.org/jira/browse/DNA-305
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-305.patch, DNA-305_path_namespace.patch, DNA-305_revised.patch
>
>
> JCRNodeType.canSetProperty does not currently perform any validations against the constraints for the property.  This does not meet the JCR 1.0 specification and will probably cause L2 tests to fail in the TCK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar 20 21:48:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 20 Mar 2009 21:48:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-285) Pass all Level 1 TCK
	unit tests
In-Reply-To: <18642947.1235148944956.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7258800.1237600102500.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-285:
--------------------------------

    Attachment: DNA-285_basic.patch


Added implementation of the simplest query methods for an L1-compliant repository.  Uncommented the TCK tests that now pass.

> Pass all Level 1 TCK unit tests
> -------------------------------
>
>                 Key: DNA-285
>                 URL: https://jira.jboss.org/jira/browse/DNA-285
>             Project: DNA
>          Issue Type: Sub-task
>            Reporter: Randall Hauch
>         Attachments: DNA-285_basic.patch
>
>
> We don't currently pass all of the Level 1 TCK unit tests.  See dna-jcr/src/test/java/org/jboss/dna/jcr/JackrabbitJcrTckTest.java, and specifically the JcrLevelOneTestSuite nested class.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Fri Mar 20 23:09:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 20 Mar 2009 23:09:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-306) Add ability to run all
 TCK unit tests within Hudson, showing success and failure rate
In-Reply-To: <28370398.1237385664158.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19598892.1237604962386.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-306:
--------------------------------

    Attachment: DNA-306.patch


Added new project called dna-jcr-tck that consists of a set of unit tests that exercise the TCK.  There is 1 unit test each for: Level 1 compliance tests, Level 2 compliance tests, locking tests (opt. feat.), versioning tests (opt. feat.), JCR-SQL tests (opt. feat.), and observation tests (opt. feat.).

Please let me know if this was not what was intended.

> Add ability to run all TCK unit tests within Hudson, showing success and failure rate
> -------------------------------------------------------------------------------------
>
>                 Key: DNA-306
>                 URL: https://jira.jboss.org/jira/browse/DNA-306
>             Project: DNA
>          Issue Type: Task
>          Components: Development Environment, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: DNA-306.patch
>
>
> Currently our use of the JCR TCK unit tests (again, not the official TCK but a subset of what's run within the TCK) is handled within a JUnit test suite in the "dna-jcr" project, and as we develop new features we're uncommenting tests as we pass them.  This does not give us any information about how we're progressing.  We want to run the tests (perhaps nightly) and make these stats available to let people know how we're doing and proceeding towards Level 1 and Level 2 compatibility.
> Comments, thoughts, and approaches welcome.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Mar 21 10:00:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Sat, 21 Mar 2009 10:00:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-309) Design URLs,
 leaving room for future UI features and maybe WebDAV
In-Reply-To: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3905583.1237644022342.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458490#action_12458490 ] 

Randall Hauch commented on DNA-309:
-----------------------------------

Another interesting blog from Roy Fielding, entitled "It's okay to use POST": http://roy.gbiv.com/untangled/2009/it-is-okay-to-use-post

Reminder, it is appropriate to use PUT when _replacing_ a resource, since PUT really requires a whole definition of the resource.  POST, on the other hand, specifies that the server accept the enclosed entity as a _subordinate_ of the resource with the supplied URI (e.g., POST a file under a directory with URI, or POST a property or set of properties under a node, or POST a child under a parent node).  This is different from PUT, which means that the enclosed entity be stored under the supplied URI.

Recall that GET and HEAD (identical to GET except that the server may not return a message body in the response) are "safe" methods in that they imply the client only asked for a retrieval, and they should not have the significance of any action other than a retrieval.  This doesn't mean that the server won't change its state; instead, it means that the client did not ask for side effects and therefore should not be accountable for them.

Also, PUT, POST and DELETE are idempotent, meaning multiple invocations do not change the result.  The OPTIONS and TRACE methods are also idempotent.

BTW, it is not clear to me what effect that same-name-siblings have on resource URIs.

> Design URLs, leaving room for future UI features and maybe WebDAV
> -----------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Mar 21 10:10:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Sat, 21 Mar 2009 10:10:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-309) Design URLs,
 leaving room for future UI features and maybe WebDAV
In-Reply-To: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25299976.1237644622322.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458491#action_12458491 ] 

Randall Hauch commented on DNA-309:
-----------------------------------

Here is an open source project that provides a web application that can respond to RESTful requests by accessing a JCR applications: http://code.google.com/p/jc-rest/   At the moment it doesn't appear to support updates, but it would be interesting to see the kind of REST operations it expects.

> Design URLs, leaving room for future UI features and maybe WebDAV
> -----------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sat Mar 21 10:12:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Sat, 21 Mar 2009 10:12:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-309) Design URLs,
 leaving room for future UI features and maybe WebDAV
In-Reply-To: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25724851.1237644742296.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458492#action_12458492 ] 

Randall Hauch commented on DNA-309:
-----------------------------------

Here is part of RFC-2616 that defines the HTTP/1.1 methods: http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

> Design URLs, leaving room for future UI features and maybe WebDAV
> -----------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 15:10:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 23 Mar 2009 15:10:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-333) BasicName.getString
 Doesn't Use Provided TextEncoder When the Name Has No Namespace
Message-ID: <33371175.1237835422656.JavaMail.jira@cloud.prod.atl2.jboss.com>

BasicName.getString Doesn't Use Provided TextEncoder When the Name Has No Namespace 
------------------------------------------------------------------------------------

                 Key: DNA-333
                 URL: https://jira.jboss.org/jira/browse/DNA-333
             Project: DNA
          Issue Type: Bug
          Components: Graph
    Affects Versions: 0.4
            Reporter: Brian Carothers


If one creates a BasicName with no namespace (e.g., "*") and calls one of the overloaded versions of getString that allows a TextEncoder to be specified, the encoder is not used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 15:30:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 23 Mar 2009 15:30:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-333) BasicName.getString
 Doesn't Use Provided TextEncoder When the Name Has No Namespace
In-Reply-To: <33371175.1237835422656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19357768.1237836622361.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-333:
--------------------------------

    Attachment: DNA-333.patch


Added patch to handle this case correctly.  The patch also changes the behavior of BasicName.getString(TextEncoder) to return the encoded local name ONLY when called.  It used to return "{}" + localName.

> BasicName.getString Doesn't Use Provided TextEncoder When the Name Has No Namespace 
> ------------------------------------------------------------------------------------
>
>                 Key: DNA-333
>                 URL: https://jira.jboss.org/jira/browse/DNA-333
>             Project: DNA
>          Issue Type: Bug
>          Components: Graph
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-333.patch
>
>
> If one creates a BasicName with no namespace (e.g., "*") and calls one of the overloaded versions of getString that allows a TextEncoder to be specified, the encoder is not used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 15:30:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 15:30:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-334) Should not allow
 creating a Name from a string with multiple non-escaped colons
Message-ID: <6544066.1237836622491.JavaMail.jira@cloud.prod.atl2.jboss.com>

Should not allow creating a Name from a string with multiple non-escaped colons
-------------------------------------------------------------------------------

                 Key: DNA-334
                 URL: https://jira.jboss.org/jira/browse/DNA-334
             Project: DNA
          Issue Type: Bug
          Components: Graph
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.4


According to the JCR TCK, it should not be possible to convert the string "a:b:c" into a name, since the second colon is not escaped.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 15:32:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 15:32:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-334) Should not allow
 creating a Name from a string with multiple non-escaped colons
In-Reply-To: <6544066.1237836622491.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32437357.1237836742420.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-334.
-------------------------------

    Resolution: Done


Changed regular expression used in the NameValueFactory to create values, allowing only a single non-escaped colon in the name.  Added a test case to verify that this change indeed was required and has the correct behavior.

> Should not allow creating a Name from a string with multiple non-escaped colons
> -------------------------------------------------------------------------------
>
>                 Key: DNA-334
>                 URL: https://jira.jboss.org/jira/browse/DNA-334
>             Project: DNA
>          Issue Type: Bug
>          Components: Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> According to the JCR TCK, it should not be possible to convert the string "a:b:c" into a name, since the second colon is not escaped.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 15:40:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 15:40:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-335) DNA's NodeTypeManager
 implementation does not allow multiple definitions
 with the same name
Message-ID: <21319415.1237837222292.JavaMail.jira@cloud.prod.atl2.jboss.com>

DNA's NodeTypeManager implementation does not allow multiple definitions with the same name
-------------------------------------------------------------------------------------------

                 Key: DNA-335
                 URL: https://jira.jboss.org/jira/browse/DNA-335
             Project: DNA
          Issue Type: Bug
            Reporter: Randall Hauch


The JCR Specification (version 1.0.1) does not preclude that there may be multiple property definitions with the same name, or that there may be multiple child definitions with the same name.  JCR 1.0 (version 1.0.1) DOES say that there may be multiple residual definitions with the same name.  However, the draft version of the JSR-283 specification does have a new section 4.7.15 that specifically addresses and allows multiple definitions with the same name, as long as they are distinguishable from the other definitions with the same name (for property definitions, this means the type must be different; for child node definitions, this means the required primary types attribute).

There are a number of places where the logic is expecting a single property definition (or child definition) given a node type and a definition name.  This is obviously flawed.  Also, our logic to select the "best" property definition or "best" child node definition doesn't seem to be correct, in that it tends to favor less-restricted definitions that are lower in the type hierarchy rather than very good matching definitions higher in the type hierarchy.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 15:45:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 15:45:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-335) DNA's NodeTypeManager
 implementation does not allow multiple definitions
 with the same name
In-Reply-To: <21319415.1237837222292.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7122912.1237837522411.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-335:
------------------------------

    Attachment: dna-335-definitionsWithSameName.patch


Attached a patch file that contains the set of changes to handle multiple property definitions with the same name, and multiple child node definitions with the same name.  The patch also corrects and centralizes the logic of selecting the "best" property definition (given the name, values, etc.) and "best" child node definition (given the names, primary type, number of children with the same name, etc.).  The JcrNodeType now maintains a cache of various definitions keyed by their name, since searching by name is by far the most frequently used mechanism to access definitions.

> DNA's NodeTypeManager implementation does not allow multiple definitions with the same name
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-335
>                 URL: https://jira.jboss.org/jira/browse/DNA-335
>             Project: DNA
>          Issue Type: Bug
>            Reporter: Randall Hauch
>         Attachments: dna-335-definitionsWithSameName.patch
>
>
> The JCR Specification (version 1.0.1) does not preclude that there may be multiple property definitions with the same name, or that there may be multiple child definitions with the same name.  JCR 1.0 (version 1.0.1) DOES say that there may be multiple residual definitions with the same name.  However, the draft version of the JSR-283 specification does have a new section 4.7.15 that specifically addresses and allows multiple definitions with the same name, as long as they are distinguishable from the other definitions with the same name (for property definitions, this means the type must be different; for child node definitions, this means the required primary types attribute).
> There are a number of places where the logic is expecting a single property definition (or child definition) given a node type and a definition name.  This is obviously flawed.  Also, our logic to select the "best" property definition or "best" child node definition doesn't seem to be correct, in that it tends to favor less-restricted definitions that are lower in the type hierarchy rather than very good matching definitions higher in the type hierarchy.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 16:52:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 16:52:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-333) BasicName.getString
 Doesn't Use Provided TextEncoder When the Name Has No Namespace
In-Reply-To: <33371175.1237835422656.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19012847.1237841542465.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-333.
-------------------------------

    Fix Version/s: 0.4
       Resolution: Done
         Assignee: Randall Hauch


Marking as resolved.

> BasicName.getString Doesn't Use Provided TextEncoder When the Name Has No Namespace 
> ------------------------------------------------------------------------------------
>
>                 Key: DNA-333
>                 URL: https://jira.jboss.org/jira/browse/DNA-333
>             Project: DNA
>          Issue Type: Bug
>          Components: Graph
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-333.patch
>
>
> If one creates a BasicName with no namespace (e.g., "*") and calls one of the overloaded versions of getString that allows a TextEncoder to be specified, the encoder is not used.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 22:19:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 22:19:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-335) DNA's NodeTypeManager
 implementation does not allow multiple definitions with the same name
In-Reply-To: <21319415.1237837222292.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6465025.1237861162290.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458690#action_12458690 ] 

Randall Hauch commented on DNA-335:
-----------------------------------

Applied the "dna-335-definitionsWithSameName" patch (see attached), albeit with a few smaller changes, including a correction to JcrNodeDefinition.allowsChildWithType(...), and a change to RepositoryNodeTypeManager.findPropertyDefinition(...) to not skip over property definitions that have an undefined property type.

It would be ideal if we add test cases for the RepositoryNodeTypeManager.find* methods, with separate test cases for each expected behavior.  The logic to find the best property definition or child node definition is certainly not trivial, and it would be very very nice to have some thorough specifications.

> DNA's NodeTypeManager implementation does not allow multiple definitions with the same name
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-335
>                 URL: https://jira.jboss.org/jira/browse/DNA-335
>             Project: DNA
>          Issue Type: Bug
>            Reporter: Randall Hauch
>         Attachments: dna-335-definitionsWithSameName.patch
>
>
> The JCR Specification (version 1.0.1) does not preclude that there may be multiple property definitions with the same name, or that there may be multiple child definitions with the same name.  JCR 1.0 (version 1.0.1) DOES say that there may be multiple residual definitions with the same name.  However, the draft version of the JSR-283 specification does have a new section 4.7.15 that specifically addresses and allows multiple definitions with the same name, as long as they are distinguishable from the other definitions with the same name (for property definitions, this means the type must be different; for child node definitions, this means the required primary types attribute).
> There are a number of places where the logic is expecting a single property definition (or child definition) given a node type and a definition name.  This is obviously flawed.  Also, our logic to select the "best" property definition or "best" child node definition doesn't seem to be correct, in that it tends to favor less-restricted definitions that are lower in the type hierarchy rather than very good matching definitions higher in the type hierarchy.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 22:31:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 22:31:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-285) Pass all Level 1 TCK
	unit tests
In-Reply-To: <18642947.1235148944956.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28538332.1237861882276.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458691#action_12458691 ] 

Randall Hauch commented on DNA-285:
-----------------------------------

Applied the patch ("DNA-285_basic") that adds an implementation of the simplest query methods for an L1-compliant repository, and that uncommented the related TCK tests that now pass.

> Pass all Level 1 TCK unit tests
> -------------------------------
>
>                 Key: DNA-285
>                 URL: https://jira.jboss.org/jira/browse/DNA-285
>             Project: DNA
>          Issue Type: Sub-task
>            Reporter: Randall Hauch
>         Attachments: DNA-285_basic.patch
>
>
> We don't currently pass all of the Level 1 TCK unit tests.  See dna-jcr/src/test/java/org/jboss/dna/jcr/JackrabbitJcrTckTest.java, and specifically the JcrLevelOneTestSuite nested class.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 22:36:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 22:36:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-305)
 JcrNodeType.canSetProperty Does Not Enforce Constraints
In-Reply-To: <844610.1237307782830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22752612.1237862182390.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458692#action_12458692 ] 

Randall Hauch commented on DNA-305:
-----------------------------------

Applied the patch.

> JcrNodeType.canSetProperty Does Not Enforce Constraints
> -------------------------------------------------------
>
>                 Key: DNA-305
>                 URL: https://jira.jboss.org/jira/browse/DNA-305
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 0.4
>
>         Attachments: DNA-305.patch, DNA-305_path_namespace.patch, DNA-305_revised.patch
>
>
> JCRNodeType.canSetProperty does not currently perform any validations against the constraints for the property.  This does not meet the JCR 1.0 specification and will probably cause L2 tests to fail in the TCK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 22:36:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 22:36:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-305)
 JcrNodeType.canSetProperty Does Not Enforce Constraints
In-Reply-To: <844610.1237307782830.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1881054.1237862182426.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-305.
-------------------------------

    Fix Version/s: 0.4
       Resolution: Done
         Assignee: Randall Hauch


Marking as resolved, since all known issues have been addressed.

> JcrNodeType.canSetProperty Does Not Enforce Constraints
> -------------------------------------------------------
>
>                 Key: DNA-305
>                 URL: https://jira.jboss.org/jira/browse/DNA-305
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-305.patch, DNA-305_path_namespace.patch, DNA-305_revised.patch
>
>
> JCRNodeType.canSetProperty does not currently perform any validations against the constraints for the property.  This does not meet the JCR 1.0 specification and will probably cause L2 tests to fail in the TCK.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 22:42:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 23 Mar 2009 22:42:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-335) DNA's NodeTypeManager
 implementation does not allow multiple definitions
 with the same name
In-Reply-To: <21319415.1237837222292.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29311518.1237862542399.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-335:
--------------------------------

    Attachment: DNA-335_clean_type_source.patch


Added patch that simplifies RepositoryTypeManager's internal type handling by combining the primaryNodeTypes and mixinNodeTypes into a single map under the assumption that lookups of types by name (which must check primary and mixin types) will be the most common option and retrieval of all primary or mixin types will be relatively rare.

This also allows for a simplification of the JcrNodeTypeSource hierarchy.

> DNA's NodeTypeManager implementation does not allow multiple definitions with the same name
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-335
>                 URL: https://jira.jboss.org/jira/browse/DNA-335
>             Project: DNA
>          Issue Type: Bug
>            Reporter: Randall Hauch
>         Attachments: dna-335-definitionsWithSameName.patch, DNA-335_clean_type_source.patch
>
>
> The JCR Specification (version 1.0.1) does not preclude that there may be multiple property definitions with the same name, or that there may be multiple child definitions with the same name.  JCR 1.0 (version 1.0.1) DOES say that there may be multiple residual definitions with the same name.  However, the draft version of the JSR-283 specification does have a new section 4.7.15 that specifically addresses and allows multiple definitions with the same name, as long as they are distinguishable from the other definitions with the same name (for property definitions, this means the type must be different; for child node definitions, this means the required primary types attribute).
> There are a number of places where the logic is expecting a single property definition (or child definition) given a node type and a definition name.  This is obviously flawed.  Also, our logic to select the "best" property definition or "best" child node definition doesn't seem to be correct, in that it tends to favor less-restricted definitions that are lower in the type hierarchy rather than very good matching definitions higher in the type hierarchy.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 22:52:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 22:52:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-335) DNA's NodeTypeManager
 implementation does not allow multiple definitions with the same name
In-Reply-To: <21319415.1237837222292.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31019723.1237863142290.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458695#action_12458695 ] 

Randall Hauch commented on DNA-335:
-----------------------------------

Verified and applied the "DNA-335_clean_type_source" patch.

> DNA's NodeTypeManager implementation does not allow multiple definitions with the same name
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-335
>                 URL: https://jira.jboss.org/jira/browse/DNA-335
>             Project: DNA
>          Issue Type: Bug
>            Reporter: Randall Hauch
>         Attachments: dna-335-definitionsWithSameName.patch, DNA-335_clean_type_source.patch
>
>
> The JCR Specification (version 1.0.1) does not preclude that there may be multiple property definitions with the same name, or that there may be multiple child definitions with the same name.  JCR 1.0 (version 1.0.1) DOES say that there may be multiple residual definitions with the same name.  However, the draft version of the JSR-283 specification does have a new section 4.7.15 that specifically addresses and allows multiple definitions with the same name, as long as they are distinguishable from the other definitions with the same name (for property definitions, this means the type must be different; for child node definitions, this means the required primary types attribute).
> There are a number of places where the logic is expecting a single property definition (or child definition) given a node type and a definition name.  This is obviously flawed.  Also, our logic to select the "best" property definition or "best" child node definition doesn't seem to be correct, in that it tends to favor less-restricted definitions that are lower in the type hierarchy rather than very good matching definitions higher in the type hierarchy.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Mon Mar 23 23:21:38 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Mar 2009 23:21:38 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-306) Add ability to run
 all TCK unit tests within Hudson, showing success and failure rate
In-Reply-To: <28370398.1237385664158.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5417828.1237864898710.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458696#action_12458696 ] 

Randall Hauch commented on DNA-306:
-----------------------------------

Thanks for the patch, Brian.  Just what I was looking for, though I did move the project into the root of the project (rather than in the "extensions" directory). 

The patch adds a 'dna-jcr-tck' project that shows how the project is doing relative to the JCR TCK unit tests.  These unit tests are NOT the official TCK, but are reportedly some of the tests that comprise the TCK and are available via the Jackrabbit project.  Also changed the parent POM to include this module only when using the 'jcr-tck' profile (e.g., 'mvn install -P jcr-tck').

Will soon be adding a nightly Hudson job to run these.

> Add ability to run all TCK unit tests within Hudson, showing success and failure rate
> -------------------------------------------------------------------------------------
>
>                 Key: DNA-306
>                 URL: https://jira.jboss.org/jira/browse/DNA-306
>             Project: DNA
>          Issue Type: Task
>          Components: Development Environment, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: DNA-306.patch
>
>
> Currently our use of the JCR TCK unit tests (again, not the official TCK but a subset of what's run within the TCK) is handled within a JUnit test suite in the "dna-jcr" project, and as we develop new features we're uncommenting tests as we pass them.  This does not give us any information about how we're progressing.  We want to run the tests (perhaps nightly) and make these stats available to let people know how we're doing and proceeding towards Level 1 and Level 2 compatibility.
> Comments, thoughts, and approaches welcome.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 00:50:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Mar 2009 00:50:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-306) Add ability to run
 all TCK unit tests within Hudson, showing success and failure rate
In-Reply-To: <28370398.1237385664158.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21376477.1237870222811.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458700#action_12458700 ] 

Randall Hauch commented on DNA-306:
-----------------------------------

Added a Hudson build to run every Monday-Friday in the wee hours of the morning.  The latest results are always available here:

http://hudson.qa.jboss.com/hudson/view/DNA/job/DNA%20JCR%20API%20compatibility%20on%20JDK1.5/org.jboss.dna$dna-jcr-tck/lastBuild/testReport/org.jboss.dna.jcr/

Hudson's formatting isn't great, but the top of that page shows that we're passing 35% of the tests (actually, it shows that we're failing 683 of the 1045 tests).  However, at the bottom of that page (below all the individual failures) are some more useful statistics, including a breakdown of the status for each compliance level.

Current status:
- 90.3% pass rate on Level 1
- 12.1% pass rate on Level 2

> Add ability to run all TCK unit tests within Hudson, showing success and failure rate
> -------------------------------------------------------------------------------------
>
>                 Key: DNA-306
>                 URL: https://jira.jboss.org/jira/browse/DNA-306
>             Project: DNA
>          Issue Type: Task
>          Components: Development Environment, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: DNA-306.patch
>
>
> Currently our use of the JCR TCK unit tests (again, not the official TCK but a subset of what's run within the TCK) is handled within a JUnit test suite in the "dna-jcr" project, and as we develop new features we're uncommenting tests as we pass them.  This does not give us any information about how we're progressing.  We want to run the tests (perhaps nightly) and make these stats available to let people know how we're doing and proceeding towards Level 1 and Level 2 compatibility.
> Comments, thoughts, and approaches welcome.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 00:52:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Mar 2009 00:52:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-306) Add ability to run
 all TCK unit tests within Hudson, showing success and failure rate
In-Reply-To: <28370398.1237385664158.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30375401.1237870342298.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-306.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Marking as resolved.

> Add ability to run all TCK unit tests within Hudson, showing success and failure rate
> -------------------------------------------------------------------------------------
>
>                 Key: DNA-306
>                 URL: https://jira.jboss.org/jira/browse/DNA-306
>             Project: DNA
>          Issue Type: Task
>          Components: Development Environment, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: DNA-306.patch
>
>
> Currently our use of the JCR TCK unit tests (again, not the official TCK but a subset of what's run within the TCK) is handled within a JUnit test suite in the "dna-jcr" project, and as we develop new features we're uncommenting tests as we pass them.  This does not give us any information about how we're progressing.  We want to run the tests (perhaps nightly) and make these stats available to let people know how we're doing and proceeding towards Level 1 and Level 2 compatibility.
> Comments, thoughts, and approaches welcome.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 08:39:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 24 Mar 2009 08:39:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-335) DNA's NodeTypeManager
 implementation does not allow multiple definitions
 with the same name
In-Reply-To: <21319415.1237837222292.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <249968.1237898362650.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-335:
--------------------------------

    Attachment: DNA-335_overriding_definitions.patch


Added patch that changes the behavior to be more consistent with the implications of section 4.7.7 in the JCR 2.0 spec.  Subtypes can override definitions of their supertypes (or their super-supertypes, etc.).  Included some very rudimentary test cases as a sanity check.  A more complete test suite is forthcoming.

This patch retains the support for multiple inheritance but adds the assumption that any future type registration support will limit overriding to cases where the overriding property or child node definition is "more narrow" than the definition being overridden.  In the case of properties, this implies that the required type of the property in the subtype's property definition can ALWAYS be cast to the required type of the property in the supertype's definition.

> DNA's NodeTypeManager implementation does not allow multiple definitions with the same name
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-335
>                 URL: https://jira.jboss.org/jira/browse/DNA-335
>             Project: DNA
>          Issue Type: Bug
>            Reporter: Randall Hauch
>         Attachments: dna-335-definitionsWithSameName.patch, DNA-335_clean_type_source.patch, DNA-335_overriding_definitions.patch
>
>
> The JCR Specification (version 1.0.1) does not preclude that there may be multiple property definitions with the same name, or that there may be multiple child definitions with the same name.  JCR 1.0 (version 1.0.1) DOES say that there may be multiple residual definitions with the same name.  However, the draft version of the JSR-283 specification does have a new section 4.7.15 that specifically addresses and allows multiple definitions with the same name, as long as they are distinguishable from the other definitions with the same name (for property definitions, this means the type must be different; for child node definitions, this means the required primary types attribute).
> There are a number of places where the logic is expecting a single property definition (or child definition) given a node type and a definition name.  This is obviously flawed.  Also, our logic to select the "best" property definition or "best" child node definition doesn't seem to be correct, in that it tends to favor less-restricted definitions that are lower in the type hierarchy rather than very good matching definitions higher in the type hierarchy.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 10:37:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Mar 2009 10:37:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-335) DNA's NodeTypeManager
 implementation does not allow multiple definitions with the same name
In-Reply-To: <21319415.1237837222292.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11582901.1237905443806.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458785#action_12458785 ] 

Randall Hauch commented on DNA-335:
-----------------------------------

Applied the "DNA-335_overriding_definitions" patch.

> DNA's NodeTypeManager implementation does not allow multiple definitions with the same name
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-335
>                 URL: https://jira.jboss.org/jira/browse/DNA-335
>             Project: DNA
>          Issue Type: Bug
>            Reporter: Randall Hauch
>         Attachments: dna-335-definitionsWithSameName.patch, DNA-335_clean_type_source.patch, DNA-335_overriding_definitions.patch
>
>
> The JCR Specification (version 1.0.1) does not preclude that there may be multiple property definitions with the same name, or that there may be multiple child definitions with the same name.  JCR 1.0 (version 1.0.1) DOES say that there may be multiple residual definitions with the same name.  However, the draft version of the JSR-283 specification does have a new section 4.7.15 that specifically addresses and allows multiple definitions with the same name, as long as they are distinguishable from the other definitions with the same name (for property definitions, this means the type must be different; for child node definitions, this means the required primary types attribute).
> There are a number of places where the logic is expecting a single property definition (or child definition) given a node type and a definition name.  This is obviously flawed.  Also, our logic to select the "best" property definition or "best" child node definition doesn't seem to be correct, in that it tends to favor less-restricted definitions that are lower in the type hierarchy rather than very good matching definitions higher in the type hierarchy.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 14:14:34 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Mar 2009 14:14:34 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-336) JcrValue.asType(int
 desiredPropertyType) skips a number of valid conversions and has duplicate
 logic
Message-ID: <3493545.1237918474976.JavaMail.jira@cloud.prod.atl2.jboss.com>

JcrValue.asType(int desiredPropertyType) skips a number of valid conversions and has duplicate logic
----------------------------------------------------------------------------------------------------

                 Key: DNA-336
                 URL: https://jira.jboss.org/jira/browse/DNA-336
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.4


Currently the JcrValue implementation has a method "asType(int propertyType)" that creates a new JcrValue object with the original values converted to the specified type. There are a couple of cases that are missed:

1) The code does not do any conversion to LONG of DOUBLE.  However, according to the JCR 1.0 specification, it is possible to convert these if the current type is a STRING, BINARY, DATE, DOUBLE, or LONG.  
2) The code does not do any conversion to REFERENCE.  However, according to the JCR 1.0 specification, it is possible to convert these if the current type is a STRING, NAME, or BINARY.
3) The conversion to a number of types exclude going to BINARY
4) The conversion to NAME and PATH both have somewhat complex logic to determine if a conversion is possible, even the current value factories do the same checks.  The code should just let the value factories do the checks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 14:18:25 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Mar 2009 14:18:25 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-336) JcrValue.asType(int
 desiredPropertyType) skips a number of valid conversions and has duplicate
 logic
In-Reply-To: <3493545.1237918474976.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24423048.1237918705028.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch resolved DNA-336.
-------------------------------

    Resolution: Done


Marking as resolved.

> JcrValue.asType(int desiredPropertyType) skips a number of valid conversions and has duplicate logic
> ----------------------------------------------------------------------------------------------------
>
>                 Key: DNA-336
>                 URL: https://jira.jboss.org/jira/browse/DNA-336
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Currently the JcrValue implementation has a method "asType(int propertyType)" that creates a new JcrValue object with the original values converted to the specified type. There are a couple of cases that are missed:
> 1) The code does not do any conversion to LONG of DOUBLE.  However, according to the JCR 1.0 specification, it is possible to convert these if the current type is a STRING, BINARY, DATE, DOUBLE, or LONG.  
> 2) The code does not do any conversion to REFERENCE.  However, according to the JCR 1.0 specification, it is possible to convert these if the current type is a STRING, NAME, or BINARY.
> 3) The conversion to a number of types exclude going to BINARY
> 4) The conversion to NAME and PATH both have somewhat complex logic to determine if a conversion is possible, even the current value factories do the same checks.  The code should just let the value factories do the checks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 14:18:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Mar 2009 14:18:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-336) JcrValue.asType(int
 desiredPropertyType) skips a number of valid
 conversions and has duplicate logic
In-Reply-To: <3493545.1237918474976.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3270468.1237918703093.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458879#action_12458879 ] 

Randall Hauch commented on DNA-336:
-----------------------------------

Changed the JcrValue.asType(int) logic to first ensure the value matches the current required type (in most cases this should just return the actual value if the type is correct), and to then convert to the desired property type.  Corrected a number of conversions to include several combinations that was excluded.

Also added a check to the NameValueFactory to ensure that the relative path (of size 1) has no SNS index.

> JcrValue.asType(int desiredPropertyType) skips a number of valid conversions and has duplicate logic
> ----------------------------------------------------------------------------------------------------
>
>                 Key: DNA-336
>                 URL: https://jira.jboss.org/jira/browse/DNA-336
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Currently the JcrValue implementation has a method "asType(int propertyType)" that creates a new JcrValue object with the original values converted to the specified type. There are a couple of cases that are missed:
> 1) The code does not do any conversion to LONG of DOUBLE.  However, according to the JCR 1.0 specification, it is possible to convert these if the current type is a STRING, BINARY, DATE, DOUBLE, or LONG.  
> 2) The code does not do any conversion to REFERENCE.  However, according to the JCR 1.0 specification, it is possible to convert these if the current type is a STRING, NAME, or BINARY.
> 3) The conversion to a number of types exclude going to BINARY
> 4) The conversion to NAME and PATH both have somewhat complex logic to determine if a conversion is possible, even the current value factories do the same checks.  The code should just let the value factories do the checks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 17:15:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Mar 2009 17:15:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-309) Design URLs and
 rerepresentations, 
 leaving room for future UI features and maybe WebDAV
In-Reply-To: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9249998.1237929322428.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Hauch updated DNA-309:
------------------------------

    Summary: Design URLs and rerepresentations, leaving room for future UI features and maybe WebDAV  (was: Design URLs, leaving room for future UI features and maybe WebDAV)


> Design URLs and rerepresentations, leaving room for future UI features and maybe WebDAV
> ---------------------------------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 17:18:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Mar 2009 17:18:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-309) Design URLs and
 rerepresentations, leaving room for future UI features and maybe WebDAV
In-Reply-To: <14708676.1237392922690.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23390619.1237929502286.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458919#action_12458919 ] 

Randall Hauch commented on DNA-309:
-----------------------------------

Very nice couple of links on RESTful representations (including how to self-describe and use link templates): 
http://www.subbu.org/blog/2008/09/on-linking-part-1 and http://www.subbu.org/blog/2008/09/on-linking-part-2

Another good post by one of our own: http://bill.burkecentral.com/2009/03/24/mediatype-as-your-idl/

> Design URLs and rerepresentations, leaving room for future UI features and maybe WebDAV
> ---------------------------------------------------------------------------------------
>
>                 Key: DNA-309
>                 URL: https://jira.jboss.org/jira/browse/DNA-309
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Web Application
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.5
>
>
> For right now, we need URLs for just publishing and un-publishing content.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Tue Mar 24 18:35:22 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Mar 2009 18:35:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24747485.1237934122316.JavaMail.jira@cloud.prod.atl2.jboss.com>


    [ https://jira.jboss.org/jira/browse/DNA-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12458938#action_12458938 ] 

Randall Hauch commented on DNA-194:
-----------------------------------

Added (and tested) functionality to set properties and remove properties.  However, none of the TCK unit tests could be run, however, since adding nodes appears to be a prerequisite of all of the Level 2 TCK unit tests.  I guess that's next on the list.

> Implement update JCR capability
> -------------------------------
>
>                 Key: DNA-194
>                 URL: https://jira.jboss.org/jira/browse/DNA-194
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-194-session-cache.patch, DNA-194_move_value_cast.patch
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 26 10:05:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 26 Mar 2009 10:05:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-337) Namespace Registries
 Create Two Nodes at /jcr:system/dna:namespaces
Message-ID: <13698106.1238076323288.JavaMail.jira@cloud.prod.atl2.jboss.com>

Namespace Registries Create Two Nodes at /jcr:system/dna:namespaces
-------------------------------------------------------------------

                 Key: DNA-337
                 URL: https://jira.jboss.org/jira/browse/DNA-337
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers
            Priority: Minor


After initializing a repository and creating a session, the system creates two nodes (same name siblings) at /jcr:system/dna:namespaces.  This confounds the RepositoryNodeTypeManagers attempts to assign a primary type to either dna:namespaces node as the definition of the dna:system type (the primary type for /jcr:system) does not allow SNS for the dna:namespaces node.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 26 10:19:24 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 26 Mar 2009 10:19:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-337) Namespace Registries
 Create Two Nodes at /jcr:system/dna:namespaces
In-Reply-To: <13698106.1238076323288.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22169164.1238077164783.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-337:
--------------------------------

    Attachment: DNA-337.patch


The problem is that the namespace registry implementations project the namespace mappings into the graph as nodes with name of the mapping prefix located under the /jcr:system/dna:namespaces node.  For example, the built-in mapping from "jcr" to "http://www.jcp.org/jcr/1.0" causes the creation of a node at /jcr:system/dna:namespaces/jcr.  This is eminently sensible.  

Except for the trivial mapping from the empty prefix to the empty namespace ("" -> "").  This causes a node to be added at "/jcr:system/dna:namespaces/", which our path factory helpfully converts to "/jcr:system/dna:namespaces".  In and of itself, this was actually helpful as the trivial mapping seemed to always occur first and actually served to create the "/jcr:system/dna:namespaces" node, which had to exist so that the other mappings had a location under which to store their nodes.

BUT, we have two layers of namespace registries, the persistent-scoped registry and the session-scoped registry.  Each is currently projecting their mappings onto the system view at JCR session initialization (which is probably wrong).  This is innocuous at the moment since both have the exact same set of mappings at JCR session intiialization time and the net effect is to overwrite each mapping with the same data.

EXCEPT for the /jcr:system/dna:namespaces node, which got created twice - once by the persistent registry and once by the transient registry.

The attached patch works around this problem by not storing the trivial mapping in the system view and adding code to explicitly create the dna:namespaces node if it is not already there.  My thinking is that the presence of the trivial mapping in the namespace mappings is simply an optimization that DNA performs so that it can always look up the URI by prefix (and vice versa) without adding a separate check to see if the prefix is even set on the given Name.  There may well be a better approach.

I have added test cases for this as well, but they are too hard to separate from the other stuff that I'm working on to extract at this time.  They'll be included in the type projection patch.

> Namespace Registries Create Two Nodes at /jcr:system/dna:namespaces
> -------------------------------------------------------------------
>
>                 Key: DNA-337
>                 URL: https://jira.jboss.org/jira/browse/DNA-337
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Priority: Minor
>         Attachments: DNA-337.patch
>
>
> After initializing a repository and creating a session, the system creates two nodes (same name siblings) at /jcr:system/dna:namespaces.  This confounds the RepositoryNodeTypeManagers attempts to assign a primary type to either dna:namespaces node as the definition of the dna:system type (the primary type for /jcr:system) does not allow SNS for the dna:namespaces node.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 26 10:33:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 26 Mar 2009 10:33:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-338) Definitions That Allow
 SNS Are Not Used For Nodes Without SNS
Message-ID: <14866962.1238078002336.JavaMail.jira@cloud.prod.atl2.jboss.com>

Definitions That Allow SNS Are Not Used For Nodes Without SNS
-------------------------------------------------------------

                 Key: DNA-338
                 URL: https://jira.jboss.org/jira/browse/DNA-338
             Project: DNA
          Issue Type: Bug
          Components: Graph
    Affects Versions: 0.4
            Reporter: Brian Carothers


Currently, RepositoryNodeTypeManager.findChildNodeDefinition will not consider definitions that allow SNS if the child node does not require SNS.  That is, if a new child node is added (and, hence, does not yet have any SNS) to a parent node that would only allow the child node with SNS (i.e., there's not definition that supports the child without SNS), findChildNodeDefinition returns null.

Section 6.7.7 (regarding child node definitions) in the JCR 1.0 spec reads (in part) that the child node definition indicates "[w]hether this child node can have same-name siblings, meaning that the parent node can have more than one child node of this name."  I may be reading too much into the use of the word "can" instead of "must", but I think that SNS definitions allow for a single node, just like multi-valued property definitions support a multi-valued property that happens to have one value.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Thu Mar 26 12:07:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 26 Mar 2009 12:07:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-338) Definitions That Allow
 SNS Are Not Used For Nodes Without SNS
In-Reply-To: <14866962.1238078002336.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15951688.1238083642475.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-338:
--------------------------------

    Attachment: DNA-338.patch


This patch changes the JcrNodeType.allChildNodeDefinitions to require only SNS-compatible definitions if requiresSns is true.  If the requiresSns is not true, this method will return all child node definitions (regardless of SNS status) that match the given property name.

> Definitions That Allow SNS Are Not Used For Nodes Without SNS
> -------------------------------------------------------------
>
>                 Key: DNA-338
>                 URL: https://jira.jboss.org/jira/browse/DNA-338
>             Project: DNA
>          Issue Type: Bug
>          Components: Graph
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-338.patch
>
>
> Currently, RepositoryNodeTypeManager.findChildNodeDefinition will not consider definitions that allow SNS if the child node does not require SNS.  That is, if a new child node is added (and, hence, does not yet have any SNS) to a parent node that would only allow the child node with SNS (i.e., there's not definition that supports the child without SNS), findChildNodeDefinition returns null.
> Section 6.7.7 (regarding child node definitions) in the JCR 1.0 spec reads (in part) that the child node definition indicates "[w]hether this child node can have same-name siblings, meaning that the parent node can have more than one child node of this name."  I may be reading too much into the use of the word "can" instead of "must", but I think that SNS definitions allow for a single node, just like multi-valued property definitions support a multi-valued property that happens to have one value.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Mar 29 13:45:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sun, 29 Mar 2009 13:45:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-339) JCR Type Registration
 and Unregistration
Message-ID: <17047195.1238348722448.JavaMail.jira@cloud.prod.atl2.jboss.com>

JCR Type Registration and Unregistration
----------------------------------------

                 Key: DNA-339
                 URL: https://jira.jboss.org/jira/browse/DNA-339
             Project: DNA
          Issue Type: Feature Request
          Components: JCR
    Affects Versions: 0.4
            Reporter: Brian Carothers


It would be useful for DNA to support type registration and unregistration (a la JSR 2.0 (draft) spec section 6.10).  


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


From jira-events at lists.jboss.org  Sun Mar 29 15:03:22 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sun, 29 Mar 2009 15:03:22 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-339) JCR Type Registration
 and Unregistration
In-Reply-To: <17047195.1238348722448.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5262488.1238353402567.JavaMail.jira@cloud.prod.atl2.jboss.com>


     [ https://jira.jboss.org/jira/browse/DNA-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Carothers updated DNA-339:
--------------------------------

    Attachment: DNA-339_RFC.patch


Attached an approximate solution for feedback.  Salient features are:

- A JSR-283-like approach to type registration, currently only implemented in the RepositoryNodeTypeManager
- Addition of a nodetypes package in the source directory that contains equivalent versions of the registration-related interfaces that exist in JCR 2.0 and not JCR 1.0
- Partial validation implementation for type registration (maybe 75% right)
- Projection of types under the /jcr:system/jcr:nodeTypes node (not needed for registration, but hard to isolate my changes at this point)

Missing features are:
- Type unregistration
- Full validation of types at registration time
- Extra validation required for type updating
- Proper internationalization of exceptions from type registration
- Logging

Potentially offensive features are:
- Refactor of findPropertyDefinition
- Thread-safety approach (partially implemented) for RepositoryTypeManager.nodeTypes
- Requirement that users order the types to be registered to eliminate forward references

Apologies for including the DNA-337 and DNA-338 fixes in this patch.  By the time I got this together, there was no good way to extricate them.

> JCR Type Registration and Unregistration
> ----------------------------------------
>
>                 Key: DNA-339
>                 URL: https://jira.jboss.org/jira/browse/DNA-339
>             Project: DNA
>          Issue Type: Feature Request
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>         Attachments: DNA-339_RFC.patch
>
>
> It would be useful for DNA to support type registration and unregistration (a la JSR 2.0 (draft) spec section 6.10).  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


