From jira-events at lists.jboss.org  Mon Jun  1 14:29:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 1 Jun 2009 14:29:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-376) Add request to change
 the order of a child node (or nodes) relative to the other children
In-Reply-To: <21590252.1240329322777.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1861811.1243880996356.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-376:
--------------------------------

    Attachment: DNA-376_for_commit.patch


Attached patch that adds "before" semantics to graph moves and makes the required changes to implement them for the existing writable connectors.

I'll leave this out for a day or two for comment since it impacts the graph layer.

> Add request to change the order of a child node (or nodes) relative to the other children
> -----------------------------------------------------------------------------------------
>
>                 Key: DNA-376
>                 URL: https://jira.jboss.org/jira/browse/DNA-376
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: DNA-376.patch, DNA-376_for_commit.patch
>
>
> The current DNA Graph model does support ordered children, and while rename can be used to change the order of same-name-siblings, there currently is no way to change the order of the child nodes.  This is required to fully implement the JCR API.
> JCR handles this functionality by provided a method that essentially changes the position of a single child node.  The "Node.orderBefore(String childNameToBeMoved, String nameOfChildAtPosition)" can be used by calling on the parent node and supplying the name (with SNS index if needed) of the child to be moved and the name of the child before which the other child is to be moved.
> This same model can be used for the graph request.  It also would allow adding in the future another optional request that would contain multiple reorders, and that could be implemented in RequestProcessor to break into multiple ReorderChildRequest instances.
> The existing (writable) connectors will all be affected, since this will be a new mandatory request.

-- 
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 Jun  1 17:20:56 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Mon, 1 Jun 2009 17:20:56 -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: <1409939.1243891256603.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=12470137#action_12470137 ] 

Dan Florian commented on DNA-319:
---------------------------------

Created a branch in svn for this eclipse plugin-in project. The plugin.xml is pretty much done with extensions for the object contributions for publishing and unpublishings. These extensions turn into the right-click context menu items. Also have a view extension for the server view. Added a JAR dependency to Jettison JSON library. Using the Eclipse NLS way of I18n.

Still need to create icons for server, repository, and workspace. Also need to implement a way to obtain images from the plugin.

> 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
>            Assignee: Dan Florian
>             Fix For: 0.6
>
>
> 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  Mon Jun  1 17:23:56 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Mon, 1 Jun 2009 17:23:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-320) Create connection
	management view
In-Reply-To: <16194240.1237395160384.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30763290.1243891436740.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Dan Florian commented on DNA-320:
---------------------------------

The ServerView is pretty much implemented (view, treeviewer, contentprovider, labelprovider). This will manage (add, delete, edit) servers that host DNA repositories.

Need to implement a Server dialog that will allow the user to create and edit a server. The UI for the delete server is done. Would be nice to get key bindings for delete to work also.

> 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
>            Assignee: Dan Florian
>             Fix For: 0.6
>
>
> 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  Mon Jun  1 17:27:56 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Mon, 1 Jun 2009 17:27:56 -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: <12415551.1243891676323.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=12470139#action_12470139 ] 

Dan Florian commented on DNA-321:
---------------------------------

Still need to implement the publish/unpublish actions which will use JSON to communicate with a registered DNA server repository. Would like to get some tests for this also. DNA-322 will use the Eclipse Job framework to put these actions in the background so the user can continue to work while the publishing is taking place.

> 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
>            Assignee: Dan Florian
>             Fix For: 0.6
>
>
> 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  Mon Jun  1 17:29:56 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Mon, 1 Jun 2009 17:29:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (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: <11158037.1243891796316.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Dan Florian commented on DNA-322:
---------------------------------

The context menu has been created by adding extension the the plugin.xml. Dialogs for publishing and unpublishing still need to be created.

> 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
>            Assignee: Dan Florian
>             Fix For: 0.6
>
>
> 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  Tue Jun  2 07:54:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 2 Jun 2009 07:54:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-376) Add request to change
 the order of a child node (or nodes) relative to the other children
In-Reply-To: <21590252.1240329322777.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23293734.1243943696765.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-376:
--------------------------------

    Attachment: DNA-376_final.patch


Previous patch, but with JCR implementation of AbstractJcrNode.orderBefore added.

> Add request to change the order of a child node (or nodes) relative to the other children
> -----------------------------------------------------------------------------------------
>
>                 Key: DNA-376
>                 URL: https://jira.jboss.org/jira/browse/DNA-376
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: DNA-376.patch, DNA-376_final.patch, DNA-376_for_commit.patch
>
>
> The current DNA Graph model does support ordered children, and while rename can be used to change the order of same-name-siblings, there currently is no way to change the order of the child nodes.  This is required to fully implement the JCR API.
> JCR handles this functionality by provided a method that essentially changes the position of a single child node.  The "Node.orderBefore(String childNameToBeMoved, String nameOfChildAtPosition)" can be used by calling on the parent node and supplying the name (with SNS index if needed) of the child to be moved and the name of the child before which the other child is to be moved.
> This same model can be used for the graph request.  It also would allow adding in the future another optional request that would contain multiple reorders, and that could be implemented in RequestProcessor to break into multiple ReorderChildRequest instances.
> The existing (writable) connectors will all be affected, since this will be a new mandatory request.

-- 
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 Jun  2 09:18:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 2 Jun 2009 09:18:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-441) JcrWorkspace.move and
 .copy Don't Check Node Type Constraints or Permissions
In-Reply-To: <16118876.1243543317081.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1193411.1243948736630.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-441:
--------------------------------

    Summary: JcrWorkspace.move and .copy Don't Check Node Type Constraints or Permissions  (was: JcrWorkspace.move and .clone Don't Check Node Type Constraints or Permissions)


> JcrWorkspace.move and .copy Don't Check Node Type Constraints or Permissions
> ----------------------------------------------------------------------------
>
>                 Key: DNA-441
>                 URL: https://jira.jboss.org/jira/browse/DNA-441
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.5
>
>         Attachments: DNA-441.patch
>
>
> The workspace move and copy operations are missing some of the required checks, impacting the JR TCK nightly tests.

-- 
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 Jun  2 09:20:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 2 Jun 2009 09:20:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-437) TCK Tests Fail on
	Workspace.copy
In-Reply-To: <23785138.1243306976752.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28047372.1243948856362.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-437.
---------------------------------

    Fix Version/s: 0.5
       Resolution: Done
         Assignee: Brian Carothers


The fix for (the previously mis-titled) DNA-441 cleaned up all of the SNS handling and corrects this defect as well as can be done at this time.

The TCK tests erroneously assume that the repository supports locking even though this is not a required L1 or L2 feature in the JCR spec.  As a result, there are still two tests in the JR TCK (one each for move and copy) that fail when they attempt to lock a node.

> TCK Tests Fail on Workspace.copy
> --------------------------------
>
>                 Key: DNA-437
>                 URL: https://jira.jboss.org/jira/browse/DNA-437
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.5
>
>         Attachments: DNA-437.patch, DNA-437_take_two.patch
>
>
> Several of the TCK tests for Workspace.copy are currently failing.

-- 
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 Jun  2 15:28:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 2 Jun 2009 15:28:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-376) Add request to change
 the order of a child node (or nodes) relative to the other children
In-Reply-To: <21590252.1240329322777.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18287149.1243970936827.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-376.
---------------------------------

    Fix Version/s: 0.5
                       (was: 0.6)
       Resolution: Done
         Assignee: Brian Carothers  (was: Randall Hauch)


Resolved defect by applying DNA-376_final.patch which:

- Adds "before" property to MoveBranchRequest which can be used in lieu of the "into" property.  If the before is populated, the node should moved into the parent of the "before" location and located immediately before the child node with the "before" location.  Added test case to WriteableConnectorTest to test this behavior.
- Modified writable connectors to support "before" property on MoveBranchRequest and no longer require that "into" property is not null.
- Added support for "before" preposition on Graph and Graph.Batch for move operation.
- Modified JCR layer to support ordering of child nodes with AbstractJcrNode.orderBefore by adding a method to SessionCache.NodeEditor and adding comparable operations to ImmutableChildren and ChangedChildren
- Uncommented relevant tests in JcrTckTest


> Add request to change the order of a child node (or nodes) relative to the other children
> -----------------------------------------------------------------------------------------
>
>                 Key: DNA-376
>                 URL: https://jira.jboss.org/jira/browse/DNA-376
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>            Priority: Blocker
>             Fix For: 0.5
>
>         Attachments: DNA-376.patch, DNA-376_final.patch, DNA-376_for_commit.patch
>
>
> The current DNA Graph model does support ordered children, and while rename can be used to change the order of same-name-siblings, there currently is no way to change the order of the child nodes.  This is required to fully implement the JCR API.
> JCR handles this functionality by provided a method that essentially changes the position of a single child node.  The "Node.orderBefore(String childNameToBeMoved, String nameOfChildAtPosition)" can be used by calling on the parent node and supplying the name (with SNS index if needed) of the child to be moved and the name of the child before which the other child is to be moved.
> This same model can be used for the graph request.  It also would allow adding in the future another optional request that would contain multiple reorders, and that could be implemented in RequestProcessor to break into multiple ReorderChildRequest instances.
> The existing (writable) connectors will all be affected, since this will be a new mandatory request.

-- 
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 Jun  2 15:53:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 2 Jun 2009 15:53:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-370) JcrWorkspace.clone
 Is Not Implemented
In-Reply-To: <1486867.1240252882274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11744602.1243972436336.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers commented on DNA-370:
-------------------------------------

Committed changes to AbstractJcrNode.getCorrespondingNodePath(String) and .update(String) to handle error checking as per spec.

> JcrWorkspace.clone Is Not Implemented
> -------------------------------------
>
>                 Key: DNA-370
>                 URL: https://jira.jboss.org/jira/browse/DNA-370
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>
> JcrWorkspace.clone is not yet implemented.  This may not be important/useful for 0.4.  AbstractJcrNode.getCorrespondingNodePath is also not yet 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  Wed Jun  3 16:13:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 3 Jun 2009 16:13:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-389) Change Getting
 Started examples
 to use the DnaConfiguration and JcrConfiguration components
In-Reply-To: <5837059.1241105806747.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <85221.1244060036646.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-389:
-----------------------------------

Simplified and improved the DnaConfiguration and JcrConfiguration classes, and added to JcrConfiguration the ability to define the repositories separately from the repository sources and to define on these repositories the JCR options, namespaces, and node types in the configuration (including via the configuration API).  All the existing uses of the configuration classes were changed to use the new/modified methods.

> Change Getting Started examples to use the DnaConfiguration and JcrConfiguration components
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-389
>                 URL: https://jira.jboss.org/jira/browse/DNA-389
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation, Examples
>            Reporter: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> The DnaConfiguration and JcrConfiguration components were created previously (see DNA-58), but the Getting Started examples and document (and Reference Guide document) need to be changed to use them.

-- 
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 Jun  4 14:34:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 14:34:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-442) Node types should not
 have to be registered in a particular order
Message-ID: <27347726.1244140496319.JavaMail.jira@cloud.prod.atl2.jboss.com>

Node types should not have to be registered in a particular order
-----------------------------------------------------------------

                 Key: DNA-442
                 URL: https://jira.jboss.org/jira/browse/DNA-442
             Project: DNA
          Issue Type: Feature Request
          Components: JCR
    Affects Versions: 0.4
            Reporter: Randall Hauch
             Fix For: 0.5


Currently, the RepositoryNodeTypeManager.registerNodeTypes(...) methods require that the supplied node types are ordered such that referenced types appear before types that use/reference other types.  This can complicate the definition of the node types, and should be relaxed so that the order of the node types (within a batch of node types being registered).

-- 
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 Jun  4 14:59:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 14:59:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-442) Node types should not
 have to be registered in a particular order
In-Reply-To: <27347726.1244140496319.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <327050.1244141996315.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-442:
------------------------------

    Attachment: DNA-442.patch


Attached a patch for consideration.  This patch doesn't change any of the existing unit tests, but does seem to allow the node types to be registered in any order without affecting the actual types being registered.

> Node types should not have to be registered in a particular order
> -----------------------------------------------------------------
>
>                 Key: DNA-442
>                 URL: https://jira.jboss.org/jira/browse/DNA-442
>             Project: DNA
>          Issue Type: Feature Request
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: DNA-442.patch
>
>
> Currently, the RepositoryNodeTypeManager.registerNodeTypes(...) methods require that the supplied node types are ordered such that referenced types appear before types that use/reference other types.  This can complicate the definition of the node types, and should be relaxed so that the order of the node types (within a batch of node types being registered).

-- 
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 Jun  4 15:10:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 15:10:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-442) Node types should not
 have to be registered in a particular order
In-Reply-To: <27347726.1244140496319.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10254349.1244142656326.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-442:
------------------------------

    Attachment: DNA-442_v2.patch


Attached the correct patch file ("DNA-442_v2.patch")

> Node types should not have to be registered in a particular order
> -----------------------------------------------------------------
>
>                 Key: DNA-442
>                 URL: https://jira.jboss.org/jira/browse/DNA-442
>             Project: DNA
>          Issue Type: Feature Request
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: DNA-442.patch, DNA-442_v2.patch
>
>
> Currently, the RepositoryNodeTypeManager.registerNodeTypes(...) methods require that the supplied node types are ordered such that referenced types appear before types that use/reference other types.  This can complicate the definition of the node types, and should be relaxed so that the order of the node types (within a batch of node types being registered).

-- 
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 Jun  4 15:16:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 4 Jun 2009 15:16:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-442) Node types should
 not have to be registered in a particular order
In-Reply-To: <27347726.1244140496319.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6112854.1244143016534.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers commented on DNA-442:
-------------------------------------

This looks great!  Nice catch!

> Node types should not have to be registered in a particular order
> -----------------------------------------------------------------
>
>                 Key: DNA-442
>                 URL: https://jira.jboss.org/jira/browse/DNA-442
>             Project: DNA
>          Issue Type: Feature Request
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: DNA-442.patch, DNA-442_v2.patch
>
>
> Currently, the RepositoryNodeTypeManager.registerNodeTypes(...) methods require that the supplied node types are ordered such that referenced types appear before types that use/reference other types.  This can complicate the definition of the node types, and should be relaxed so that the order of the node types (within a batch of node types being registered).

-- 
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 Jun  4 15:20:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 15:20:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-442) Node types should not
 have to be registered in a particular order
In-Reply-To: <27347726.1244140496319.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31596076.1244143256364.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-442.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Marking as resolved, since this appears to solve the issue.

> Node types should not have to be registered in a particular order
> -----------------------------------------------------------------
>
>                 Key: DNA-442
>                 URL: https://jira.jboss.org/jira/browse/DNA-442
>             Project: DNA
>          Issue Type: Feature Request
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: DNA-442.patch, DNA-442_v2.patch
>
>
> Currently, the RepositoryNodeTypeManager.registerNodeTypes(...) methods require that the supplied node types are ordered such that referenced types appear before types that use/reference other types.  This can complicate the definition of the node types, and should be relaxed so that the order of the node types (within a batch of node types being registered).

-- 
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 Jun  4 17:34:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 17:34:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-443) Java sequencer is not
 saving content correctly
Message-ID: <5905127.1244151296321.JavaMail.jira@cloud.prod.atl2.jboss.com>

Java sequencer is not saving content correctly
----------------------------------------------

                 Key: DNA-443
                 URL: https://jira.jboss.org/jira/browse/DNA-443
             Project: DNA
          Issue Type: Bug
          Components: Examples, Sequencers
    Affects Versions: 0.4
            Reporter: Randall Hauch
             Fix For: 0.6


The Java sequencer doesn't appear to be sequencing the Java source code and saving it correctly.  The SequencingClientTest.shouldUploadAndSequenceJavaSourceFile() fails and has been temporarily ignored.

-- 
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 Jun  4 17:43:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 17:43:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-389) Change Getting
 Started examples
 to use the DnaConfiguration and JcrConfiguration components
In-Reply-To: <5837059.1241105806747.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9154277.1244151836330.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-389:
-----------------------------------

More minor corrections in how property types are determined for different values (including values that are instances of non-canonical classes, such as Integer).  Discovered DNA-443, so adding temporary ignore to the sequencing test of Java source code.

> Change Getting Started examples to use the DnaConfiguration and JcrConfiguration components
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-389
>                 URL: https://jira.jboss.org/jira/browse/DNA-389
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation, Examples
>            Reporter: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> The DnaConfiguration and JcrConfiguration components were created previously (see DNA-58), but the Getting Started examples and document (and Reference Guide document) need to be changed to use them.

-- 
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 Jun  4 17:47:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 17:47:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-405) Update the Getting
 Started doc
 and examples with the new configuration and to remove dependency on
 Jackrabbit
In-Reply-To: <24621769.1242235606776.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15534256.1244152076327.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-405:
-----------------------------------

Removed all remaining traces of Jackrabbit from the sequencer example.

> Update the Getting Started doc and examples with the new configuration and to remove dependency on Jackrabbit
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-405
>                 URL: https://jira.jboss.org/jira/browse/DNA-405
>             Project: DNA
>          Issue Type: Task
>          Components: Connectors, Documentation, Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> Per changes to the configuration, ObservationService (DNA-404), and SequencingService (DNA-401), we need to update the Getting Started doc and examples to use the new configuration mechanism and to remove dependency on Jackrabbit.

-- 
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 Jun  4 19:35:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 19:35:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-405) Update the Getting
 Started doc
 and examples with the new configuration and to remove dependency on
 Jackrabbit
In-Reply-To: <24621769.1242235606776.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14989891.1244158556313.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-405:
-----------------------------------

Continued the removal of most references and use of Jackrabbit, with the exception of the Jackrabbit API unit tests (aka, the TCK unit tests), the Maven classloader project, and the 'dna-integration-test' project.  Some documentation still needs to be updated.

> Update the Getting Started doc and examples with the new configuration and to remove dependency on Jackrabbit
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-405
>                 URL: https://jira.jboss.org/jira/browse/DNA-405
>             Project: DNA
>          Issue Type: Task
>          Components: Connectors, Documentation, Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> Per changes to the configuration, ObservationService (DNA-404), and SequencingService (DNA-401), we need to update the Getting Started doc and examples to use the new configuration mechanism and to remove dependency on Jackrabbit.

-- 
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 Jun  4 22:27:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 22:27:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-436) Repository example
 uses different
 path in configuration repository than assumed by RepositoryService
In-Reply-To: <27337052.1243267436372.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2571183.1244168876332.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-436.
-------------------------------

    Resolution: Done


Marking as resolved, since this issue appears to be fixed with the new and improved configuration mechanism (see DNA-389)

> Repository example uses different path in configuration repository than assumed by RepositoryService
> ----------------------------------------------------------------------------------------------------
>
>                 Key: DNA-436
>                 URL: https://jira.jboss.org/jira/browse/DNA-436
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation, Examples
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.5
>
>
> The RepositoryService looks for the configuration information in the repository source (supplied by name via the constructor) by default under the "/jcr:system" path.  However, the repository example has a configRepository.xml file in which the content is stored under the "/dna:system" path.  Although it's possible to use the RepositoryService constructor and specify the correct path, the examples should be such that the path used in the examples is that assumed by the RepositoryService.
> Therefore, we should change the repository example configuration file to reflect the current default used by the RepositoryService.

-- 
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 Jun  4 22:51:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 22:51:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-389) Change Getting
 Started examples
 to use the DnaConfiguration and JcrConfiguration components
In-Reply-To: <5837059.1241105806747.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20532791.1244170316456.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-389:
-----------------------------------

Corrected how JcrEngine returns the names of the repositories, using the configuration to get all of them regardless of which Repository objects were used by the engine.

> Change Getting Started examples to use the DnaConfiguration and JcrConfiguration components
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-389
>                 URL: https://jira.jboss.org/jira/browse/DNA-389
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation, Examples
>            Reporter: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> The DnaConfiguration and JcrConfiguration components were created previously (see DNA-58), but the Getting Started examples and document (and Reference Guide document) need to be changed to use them.

-- 
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 Jun  4 23:41:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 23:41:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-389) Change Getting
 Started examples
 to use the DnaConfiguration and JcrConfiguration components
In-Reply-To: <5837059.1241105806747.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <914798.1244173316328.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-389:
-----------------------------------

Updated the first few sections of the Getting Started guide to reflect the new configuration and that we're no longer dependent upon Jackrabbit.

> Change Getting Started examples to use the DnaConfiguration and JcrConfiguration components
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-389
>                 URL: https://jira.jboss.org/jira/browse/DNA-389
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation, Examples
>            Reporter: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> The DnaConfiguration and JcrConfiguration components were created previously (see DNA-58), but the Getting Started examples and document (and Reference Guide document) need to be changed to use them.

-- 
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 Jun  4 23:41:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 4 Jun 2009 23:41:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-405) Update the Getting
 Started doc
 and examples with the new configuration and to remove dependency on
 Jackrabbit
In-Reply-To: <24621769.1242235606776.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30329504.1244173316370.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-405:
-----------------------------------

Updated the first few sections of the Getting Started guide to reflect the new configuration and that we're no longer dependent upon Jackrabbit.

> Update the Getting Started doc and examples with the new configuration and to remove dependency on Jackrabbit
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-405
>                 URL: https://jira.jboss.org/jira/browse/DNA-405
>             Project: DNA
>          Issue Type: Task
>          Components: Connectors, Documentation, Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> Per changes to the configuration, ObservationService (DNA-404), and SequencingService (DNA-401), we need to update the Getting Started doc and examples to use the new configuration mechanism and to remove dependency on Jackrabbit.

-- 
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 Jun  5 11:23:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 5 Jun 2009 11:23:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-444) Update REST Servlet to
 Use New JcrConfiguration
Message-ID: <21415923.1244215436331.JavaMail.jira@cloud.prod.atl2.jboss.com>

Update REST Servlet to Use New JcrConfiguration
-----------------------------------------------

                 Key: DNA-444
                 URL: https://jira.jboss.org/jira/browse/DNA-444
             Project: DNA
          Issue Type: Bug
          Components: JCR, Server
    Affects Versions: 0.4
            Reporter: Brian Carothers
             Fix For: 0.5


The REST servlet also needs to be updated to use the new configuration

-- 
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 Jun  5 11:29:01 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 5 Jun 2009 11:29:01 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-444) Update REST Servlet to
 Use New JcrConfiguration
In-Reply-To: <21415923.1244215436331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10430876.1244215751760.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-444:
--------------------------------

    Attachment: DNA-444.patch


Attached patch that utilizes updated JcrConfiguration to load repository configuration from a configuration file and added startup lifecycle method to RepositoryProvider SPI.  

> Update REST Servlet to Use New JcrConfiguration
> -----------------------------------------------
>
>                 Key: DNA-444
>                 URL: https://jira.jboss.org/jira/browse/DNA-444
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR, Server
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 0.5
>
>         Attachments: DNA-444.patch
>
>
> The REST servlet also needs to be updated to use the new configuration

-- 
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 Jun  5 11:31:47 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 5 Jun 2009 11:31:47 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-444) Update REST Servlet
 to Use New JcrConfiguration
In-Reply-To: <21415923.1244215436331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5785573.1244215907241.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-444.
---------------------------------

    Resolution: Done
      Assignee: Brian Carothers


Committed patch to resolve issue

> Update REST Servlet to Use New JcrConfiguration
> -----------------------------------------------
>
>                 Key: DNA-444
>                 URL: https://jira.jboss.org/jira/browse/DNA-444
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR, Server
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.5
>
>         Attachments: DNA-444.patch
>
>
> The REST servlet also needs to be updated to use the new configuration

-- 
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 Jun  5 16:13:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 5 Jun 2009 16:13:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-443) Java sequencer is
 not saving content correctly
In-Reply-To: <5905127.1244151296321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11085839.1244232836321.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers commented on DNA-443:
-------------------------------------

The problem seems to be around line 151 of InMemoryRequestProcessor.  This trap is hitting:

        InMemoryNode parentNode = workspace.getNode(parent);
        if (parentNode == null) {
            Path lowestExisting = workspace.getLowestExistingPath(parent);
            request.setError(new PathNotFoundException(request.under(), lowestExisting,
                                                       GraphI18n.inMemoryNodeDoesNotExist.text(parent)));
            return;
        }

The parentNode seems to be null because the sequence of create node requests generated by the sequencer starts off like so:

 dna:compilationUnit
 dna:compilationUnit/dna:import/dna:importDeclaration/dna:importOnDemand/dna:typeImportOnDemandDeclaration

It seems as though the problem is that the request processor is trying to create dna:typeImportOnDemandDeclaration before dna:compilationUnit/dna:import exists.  

I see this as a problem with the sequencer.  We could make the request processors smart enough to build any missing nodes, but the interpolated nodes wouldn't have useful properties like jcr:primaryType, so I think that approach would just defer the problem.  

I'll poke around the sequencer and see if I can fix this.





> Java sequencer is not saving content correctly
> ----------------------------------------------
>
>                 Key: DNA-443
>                 URL: https://jira.jboss.org/jira/browse/DNA-443
>             Project: DNA
>          Issue Type: Bug
>          Components: Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>             Fix For: 0.6
>
>
> The Java sequencer doesn't appear to be sequencing the Java source code and saving it correctly.  The SequencingClientTest.shouldUploadAndSequenceJavaSourceFile() fails and has been temporarily ignored.

-- 
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 Jun  6 16:33:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 6 Jun 2009 16:33:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-440) Integrate Servlet
 Security with DNA ExecutionContext
In-Reply-To: <26488898.1243520636308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21204001.1244320436338.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-440:
--------------------------------

    Attachment: DNA-440_refactor_existing.patch


Attached and applied patch that takes first step towards integrating the security by refactoring the existing security from ExecutionContext proper into a new interface called o.j.d.graph.SecurityContext.  The existing JAAS code moves into an implementation of SecurityContext called JaasSecurityContext and JcrSession can now accept a new type of Credentials called o.j.d.jcr.SecurityContextCredentials that wraps an existing SecurityContext.

Next step is to create a SecurityContext class that wraps HttpServletRequest to be able to derive the user name and role information directly from the request and modify JcrResource to accept the new SecurityContext class.

> Integrate Servlet Security with DNA ExecutionContext
> ----------------------------------------------------
>
>                 Key: DNA-440
>                 URL: https://jira.jboss.org/jira/browse/DNA-440
>             Project: DNA
>          Issue Type: Sub-task
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-440_refactor_existing.patch
>
>
> The DNA JCR security approach is JAAS-based and relies on the ability to pass a LoginContext, AccessControlContext, or SimpleCredentials (which are used internally to create a LoginContext) to the ExecutionContext.  The Servlet specification does not expose any of these.  The REST server is mandatorily limited to what the Servlet specification provides.  There needs to be some sort of integration between the Servlet-based REST code and JAAS-based DNA implementation to allow authorization and access to JCR resources to occur based on web credentials.

-- 
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 Jun  6 19:48:07 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 6 Jun 2009 19:48:07 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-440) Integrate Servlet
 Security with DNA ExecutionContext
In-Reply-To: <26488898.1243520636308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4222239.1244332087917.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-440:
--------------------------------

    Attachment: DNA-440_rest_changes.patch


Attached patch that:

- Adds class ServletSecurityContext to wrap HttpServletRequests in a SecurityContext for authorization within DNA
- Makes JcrResource utilize a wrapped HttpServletRequest to login to the JCR Repository instead of a hardcoded user/password
- Refactors the SPI to remove the ability to get a repository by name and add the ability to get a session from a request, repository name, and workspace name
- Refactors surrounding classes in accord with change from prior line
- Modifies integration test WAR to require basic authentication for all URIs
- Modifies POM to add a valid user/password combination with the correct connect role; stripped all JAAS configuration
- Makes existing test cases use 
- Adds test cases for bad password and user without connect role

The REST integration test case throws out a bunch of spurious warnings about authorization failure, but since the test cases test that 1) nothing gets returned if authorization actually fails and 2) the right things do get returned when authorization works, I'm going to write this off as a Jetty quirk until proven otherwise.

> Integrate Servlet Security with DNA ExecutionContext
> ----------------------------------------------------
>
>                 Key: DNA-440
>                 URL: https://jira.jboss.org/jira/browse/DNA-440
>             Project: DNA
>          Issue Type: Sub-task
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-440_refactor_existing.patch, DNA-440_rest_changes.patch
>
>
> The DNA JCR security approach is JAAS-based and relies on the ability to pass a LoginContext, AccessControlContext, or SimpleCredentials (which are used internally to create a LoginContext) to the ExecutionContext.  The Servlet specification does not expose any of these.  The REST server is mandatorily limited to what the Servlet specification provides.  There needs to be some sort of integration between the Servlet-based REST code and JAAS-based DNA implementation to allow authorization and access to JCR resources to occur based on web credentials.

-- 
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 Jun  6 19:52:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 6 Jun 2009 19:52:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-440) Integrate Servlet
 Security with DNA ExecutionContext
In-Reply-To: <26488898.1243520636308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8726000.1244332376313.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-440.
---------------------------------

    Fix Version/s: 0.5
                       (was: 0.6)
       Resolution: Done
         Assignee: Brian Carothers


Applied patch that resolves defect as per IRC discussion with Randall last week.

> Integrate Servlet Security with DNA ExecutionContext
> ----------------------------------------------------
>
>                 Key: DNA-440
>                 URL: https://jira.jboss.org/jira/browse/DNA-440
>             Project: DNA
>          Issue Type: Sub-task
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.5
>
>         Attachments: DNA-440_refactor_existing.patch, DNA-440_rest_changes.patch
>
>
> The DNA JCR security approach is JAAS-based and relies on the ability to pass a LoginContext, AccessControlContext, or SimpleCredentials (which are used internally to create a LoginContext) to the ExecutionContext.  The Servlet specification does not expose any of these.  The REST server is mandatorily limited to what the Servlet specification provides.  There needs to be some sort of integration between the Servlet-based REST code and JAAS-based DNA implementation to allow authorization and access to JCR resources to occur based on web credentials.

-- 
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 Jun  7 09:48:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sun, 7 Jun 2009 09:48:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-445) Formally Delineate the
	Public API
Message-ID: <3872687.1244382536324.JavaMail.jira@cloud.prod.atl2.jboss.com>

Formally Delineate the Public API
---------------------------------

                 Key: DNA-445
                 URL: https://jira.jboss.org/jira/browse/DNA-445
             Project: DNA
          Issue Type: Feature Request
          Components: API
    Affects Versions: 0.4
            Reporter: Brian Carothers


DNA has a fairly large number of classes, not all of which are intended to be stable.  Although some examples and documentation "best practices" for utilizing the API are provided, there is no explicit contract in the API that indicates which portions of the API are expected to remain stable and supported over time.

A comparable discussion was occurring on the jboss-development mailing list (https://lists.jboss.org/mailman/listinfo/jboss-development)  Vol. 36 Issue 8 et al.  It appears that Eclipse uses annotations to provide this information.  These annotations (http://www.opends.org/promoted-builds/2.0.0-RC1/javadoc/org/opends/server/types/PublicAPI.html and http://www.eclipse.org/pde/pde-api-tools/) were tossed around in the discussion.

-- 
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 Jun  7 11:05:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sun, 7 Jun 2009 11:05:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-318) Provide
 documentation/examples/tutorial explaining use of RESTful API
In-Reply-To: <8849439.1237394602464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22347855.1244387156325.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers commented on DNA-318:
-------------------------------------

Bolstered Javadoc in dna-web-jcr-rest subproject as a precursor to putting comparable information into the Getting Started and Reference Guide documents.

> 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
>             Fix For: 0.6
>
>


-- 
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 Jun  7 18:33:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Sun, 7 Jun 2009 18:33:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-389) Change Getting
 Started examples
 to use the DnaConfiguration and JcrConfiguration components
In-Reply-To: <5837059.1241105806747.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8287431.1244414036317.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-389:
-----------------------------------

Updated the Getting Started document to reflect the new configuration approach, and restructured the document to better focus on the examples and high-level introduction, leaving the more detailed discussions for the Reference Guide (and removing more of the duplication).

> Change Getting Started examples to use the DnaConfiguration and JcrConfiguration components
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-389
>                 URL: https://jira.jboss.org/jira/browse/DNA-389
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation, Examples
>            Reporter: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> The DnaConfiguration and JcrConfiguration components were created previously (see DNA-58), but the Getting Started examples and document (and Reference Guide document) need to be changed to use them.

-- 
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 Jun  7 18:35:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Sun, 7 Jun 2009 18:35:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-405) Update the Getting
 Started doc and
 examples with the new configuration and to remove dependency on Jackrabbit
In-Reply-To: <24621769.1242235606776.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7092558.1244414156322.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-405.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Marking as resolved, since all references have been removed from the code and documentation.

> Update the Getting Started doc and examples with the new configuration and to remove dependency on Jackrabbit
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-405
>                 URL: https://jira.jboss.org/jira/browse/DNA-405
>             Project: DNA
>          Issue Type: Task
>          Components: Connectors, Documentation, Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> Per changes to the configuration, ObservationService (DNA-404), and SequencingService (DNA-401), we need to update the Getting Started doc and examples to use the new configuration mechanism and to remove dependency on Jackrabbit.

-- 
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 Jun  7 18:49:07 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Sun, 7 Jun 2009 18:49:07 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-446) Screenshots of example
 applications need to be updated in the Getting Started document
Message-ID: <24422151.1244414947255.JavaMail.jira@cloud.prod.atl2.jboss.com>

Screenshots of example applications need to be updated in the Getting Started document
--------------------------------------------------------------------------------------

                 Key: DNA-446
                 URL: https://jira.jboss.org/jira/browse/DNA-446
             Project: DNA
          Issue Type: Task
          Components: Documentation
    Affects Versions: 0.4
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.5


The screenshots in the Getting Started document showing the running examples need to be updated.

-- 
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 Jun  9 08:05:06 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 9 Jun 2009 08:05:06 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-447) Make REST PUT Method
 Support add/removeMixin Like POST Method
Message-ID: <13011531.1244549106943.JavaMail.jira@cloud.prod.atl2.jboss.com>

Make REST PUT Method Support add/removeMixin Like POST Method
-------------------------------------------------------------

                 Key: DNA-447
                 URL: https://jira.jboss.org/jira/browse/DNA-447
             Project: DNA
          Issue Type: Bug
          Components: JCR, Server
    Affects Versions: 0.4
            Reporter: Brian Carothers
            Assignee: Brian Carothers
            Priority: Minor
             Fix For: 1.0


The REST POST method automatically translates the jcr:mixinTypes property (if set on the request) into a series of addMixin calls.  The PUT method should compare the jcr:mixinTypes property (if present) to the existing mixin types for the node and attempt to add or remove mixin types as needed.

-- 
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 Jun  9 13:09:08 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 9 Jun 2009 13:09:08 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-55) Web Application with
 REST-based API for remote access and usage
Message-ID: <26281822.1244567348584.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-55.
--------------------------------

    Fix Version/s: 0.5
                       (was: 0.6)
       Resolution: Done
         Assignee: Brian Carothers


Committed some fairly exhaustive documentation into the DNA Reference Guide for the 0.5 release.

> 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
>            Assignee: Brian Carothers
>             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  Tue Jun  9 13:09:09 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 9 Jun 2009 13:09:09 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Closed: (DNA-318) Provide
 documentation/examples/tutorial explaining use of RESTful API
In-Reply-To: <8849439.1237394602464.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6980010.1244567349090.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers closed DNA-318.
-------------------------------

    Fix Version/s: 0.5
                       (was: 0.6)
       Resolution: Done
         Assignee: Brian Carothers


Committed some fairly exhaustive documentation into the DNA Reference Guide for the 0.5 release.

> 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
>            Assignee: Brian Carothers
>             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  Tue Jun  9 13:21:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 9 Jun 2009 13:21:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-415) Remove JSR-94 and the
 'org.jboss.dna.repository.rules' package
In-Reply-To: <10684499.1242958316352.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31184413.1244568116922.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-415:
--------------------------------

    Summary: Remove JSR-94 and the 'org.jboss.dna.repository.rules' package  (was: Remove JSR-92 and the 'org.jboss.dna.repository.rules' package)


Corrected JSR number in case anyone searches for it in the future

> Remove JSR-94 and the 'org.jboss.dna.repository.rules' package
> --------------------------------------------------------------
>
>                 Key: DNA-415
>                 URL: https://jira.jboss.org/jira/browse/DNA-415
>             Project: DNA
>          Issue Type: Task
>          Components: Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.5
>
>
> The 'org.jboss.dna.repository.rules' package is still not used by the sequencing service (nor are there plans to use it), so it should be removed.  It can always be resurrected from old releases (or from history).

-- 
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 Jun  9 18:51:57 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Tue, 9 Jun 2009 18:51:57 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-443) Java sequencer is not
 saving content correctly
In-Reply-To: <5905127.1244151296321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20074185.1244587917345.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-443.
---------------------------------

    Fix Version/s: 0.5
                       (was: 0.6)
       Resolution: Done
         Assignee: Brian Carothers


Well, the initial guess was in the ballpark but not correct.

Part of the StreamSequencerAdapter code (the buildPathTo part) was operating directly against the graph for reads and writes.  The other part (saveOutput) was operating against a destination that happened to be a batch.  The batch doesn't save until all of the processing for the output of a particular sequencer is complete, leading to some race conditions between the two parts of the code.  The batch is there to support a all-or-nothing save semantics for the output of a particular sequencer.

The most correct solution is to switch all of the code to use a batch, but this creates some challenges.  For one thing, the batch doesn't support the concept of createIfMissing semantics or reads of any sort.  I think that we would have to keep some sort of internal graph of nodes added to the batch while processing the sequencer output and check against that as well as the nodes in the graph.

My workaround for now is to make all of the operations in StreamSequencerAdapter work directly against the graph.  We can always revisit this in 0.6.

> Java sequencer is not saving content correctly
> ----------------------------------------------
>
>                 Key: DNA-443
>                 URL: https://jira.jboss.org/jira/browse/DNA-443
>             Project: DNA
>          Issue Type: Bug
>          Components: Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>             Fix For: 0.5
>
>
> The Java sequencer doesn't appear to be sequencing the Java source code and saving it correctly.  The SequencingClientTest.shouldUploadAndSequenceJavaSourceFile() fails and has been temporarily ignored.

-- 
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 Jun 10 00:32:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 00:32:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-443) Java sequencer is
 not saving content correctly
In-Reply-To: <5905127.1244151296321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23902336.1244608376376.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-443:
-----------------------------------

Actually, the batch 'create(...)' methods on the Graph.Batch class do indeed have the ability to create nodes if they are missing.  In fact, both the batch and non-batch works 
the same way:

   graph.create(path).ifAbsent()...   // or even .orUpdate()

or

   batch.create(path).ifAbsent()...

In fact, this style makes available several other methods than "ifAbsent()", such as "orUpdate()", "byAppending()", and "orReplace()".  These correspond to the different NodeConflictBehavior options.

I'll grant you that the "createIfMissing()" methods are not available in the batch mode.  Perhaps we should deprecate them, since the above methods are newer, more complete, and just as useful.  I think the only capability that the "createIfMissing()" methods have above the others is that they return an interface that has the "andReturn():Node" method, but I think all the non-batch "create()" methods could do this.

I will open an issue to resolve this discrepency in the Graph API, but I'm also going to reopen this issue for 0.6, since sequencers really should be operating in batch (in case there is an error in the middle of processing, and because a large batch with many operations will be significantly faster for most connectors than the same number of operations submitted individually).

> Java sequencer is not saving content correctly
> ----------------------------------------------
>
>                 Key: DNA-443
>                 URL: https://jira.jboss.org/jira/browse/DNA-443
>             Project: DNA
>          Issue Type: Bug
>          Components: Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>
> The Java sequencer doesn't appear to be sequencing the Java source code and saving it correctly.  The SequencingClientTest.shouldUploadAndSequenceJavaSourceFile() fails and has been temporarily ignored.

-- 
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 Jun 10 00:32:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 00:32:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Reopened: (DNA-443) Java sequencer is not
 saving content correctly
In-Reply-To: <5905127.1244151296321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21548034.1244608376412.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reopened DNA-443:
-------------------------------



> Java sequencer is not saving content correctly
> ----------------------------------------------
>
>                 Key: DNA-443
>                 URL: https://jira.jboss.org/jira/browse/DNA-443
>             Project: DNA
>          Issue Type: Bug
>          Components: Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>
> The Java sequencer doesn't appear to be sequencing the Java source code and saving it correctly.  The SequencingClientTest.shouldUploadAndSequenceJavaSourceFile() fails and has been temporarily ignored.

-- 
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 Jun 10 00:32:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 00:32:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-443) Java sequencer is not
 saving content correctly
In-Reply-To: <5905127.1244151296321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1292221.1244608376444.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-443:
------------------------------

    Fix Version/s: 0.6
                       (was: 0.5)


> Java sequencer is not saving content correctly
> ----------------------------------------------
>
>                 Key: DNA-443
>                 URL: https://jira.jboss.org/jira/browse/DNA-443
>             Project: DNA
>          Issue Type: Bug
>          Components: Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>
> The Java sequencer doesn't appear to be sequencing the Java source code and saving it correctly.  The SequencingClientTest.shouldUploadAndSequenceJavaSourceFile() fails and has been temporarily ignored.

-- 
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 Jun 10 00:40:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 00:40:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-448) The
 'createIfMissing()' methods should be removed from the Graph API
Message-ID: <8393411.1244608856485.JavaMail.jira@cloud.prod.atl2.jboss.com>

The 'createIfMissing()' methods should be removed from the Graph API
--------------------------------------------------------------------

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


This issue stemmed from DNA-443.  The existence of the "createIfMissing()" methods that exist only on the Graph interface (and not the Graph.Batch interface) mask the existence of newer, more powerful methods that can do the same thing on Graph and Graph.Batch:

   graph.create(path).ifAbsent()...

or

   batch.create(path).ifAbsent()...

In fact, this style makes available several other methods than "ifAbsent()", such as "orUpdate()", "byAppending()", and "orReplace()".  These correspond to the different NodeConflictBehavior options.

Unfortunately, the 'create()' methods just return the Conjunction interface, while the 'createIfMissing()' methods return the "GetNodeConjunction" interface (which extends Conjunction and adds the "andReturn():Node" method).  And there is at least one place where 'createIfMissing(...).andReturn()' is being called.  Looking at this now, I'm not sure why the Graph.create(...) methods can't return the GetNodeConjunction interface.  This would allow the existing uses of the 'createIfMissing(...).andReturn()' to replace them with 'create(...).ifAbsent().andReturn()' calls, and enable the removal of the 'createIfMissing(...)' methods. 

-- 
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 Jun 10 00:44:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 00:44:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-389) Change Getting
 Started examples to
 use the DnaConfiguration and JcrConfiguration components
In-Reply-To: <5837059.1241105806747.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4208168.1244609096342.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-389.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Marking as resolved.

> Change Getting Started examples to use the DnaConfiguration and JcrConfiguration components
> -------------------------------------------------------------------------------------------
>
>                 Key: DNA-389
>                 URL: https://jira.jboss.org/jira/browse/DNA-389
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation, Examples
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> The DnaConfiguration and JcrConfiguration components were created previously (see DNA-58), but the Getting Started examples and document (and Reference Guide document) need to be changed to use them.

-- 
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 Jun 10 00:51:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 00:51:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-449) Federation connector
 does not find
 it's configuration when imported using the JcrConfiguration
Message-ID: <27261542.1244609516322.JavaMail.jira@cloud.prod.atl2.jboss.com>

Federation connector does not find it's configuration when imported using the JcrConfiguration
----------------------------------------------------------------------------------------------

                 Key: DNA-449
                 URL: https://jira.jboss.org/jira/browse/DNA-449
             Project: DNA
          Issue Type: Bug
          Components: API, Connectors
    Affects Versions: 0.4
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Blocker
             Fix For: 0.5


When a configuration file is imported using the JcrConfiguration (or DnaConfiguration), the Federation Connector doesn't find the connector's workspace definitions.  I believe this is because the configuration files are imported with slightly modified paths.  This problem prevents the federation connector from being used, and thus is a bigger problem.

Fixing this should be pretty straightforward and is low risk, and simply involves supplying the correct path to the source configuration element when the RepositorySource's are initialized by the RepositoryLibrary, then changing the FederatedRepositorySource to use this new path.

-- 
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 Jun 10 01:02:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 01:02:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-445) Formally Delineate the
	Public API
In-Reply-To: <3872687.1244382536324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18248002.1244610176331.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-445:
------------------------------

    Fix Version/s: 1.0


I think this would be a good addition, though I suspect that it may not be immediately clear for some of our classes.  Targeting to 1.0.

> Formally Delineate the Public API
> ---------------------------------
>
>                 Key: DNA-445
>                 URL: https://jira.jboss.org/jira/browse/DNA-445
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 1.0
>
>
> DNA has a fairly large number of classes, not all of which are intended to be stable.  Although some examples and documentation "best practices" for utilizing the API are provided, there is no explicit contract in the API that indicates which portions of the API are expected to remain stable and supported over time.
> A comparable discussion was occurring on the jboss-development mailing list (https://lists.jboss.org/mailman/listinfo/jboss-development)  Vol. 36 Issue 8 et al.  It appears that Eclipse uses annotations to provide this information.  These annotations (http://www.opends.org/promoted-builds/2.0.0-RC1/javadoc/org/opends/server/types/PublicAPI.html and http://www.eclipse.org/pde/pde-api-tools/) were tossed around in the discussion.

-- 
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 Jun 10 08:54:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 10 Jun 2009 08:54:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-443) Java sequencer is
 not saving content correctly
In-Reply-To: <5905127.1244151296321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8992576.1244638496356.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers commented on DNA-443:
-------------------------------------

Sorry, I never even noticed the ifAbsent clause et al.  This doesn't exactly fix the problem though since the sequencer output goes through a GraphBatchDestination, not a true graph batch.  Should this be changed?

If it were changed, I think we'd hit the next problem (that I did a poor job of describing in my previous comment) - the inability to create a node at a certain SNS index if the node does not already exist at that SNS index.  Right now the CreateNodeRequest decomposes the location of the new node into a parent path and a child name.  This loses the SNS index.  


> Java sequencer is not saving content correctly
> ----------------------------------------------
>
>                 Key: DNA-443
>                 URL: https://jira.jboss.org/jira/browse/DNA-443
>             Project: DNA
>          Issue Type: Bug
>          Components: Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>
> The Java sequencer doesn't appear to be sequencing the Java source code and saving it correctly.  The SequencingClientTest.shouldUploadAndSequenceJavaSourceFile() fails and has been temporarily ignored.

-- 
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 Jun 10 10:53:58 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 10 Jun 2009 10:53:58 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-443) Java sequencer is not
 saving content correctly
In-Reply-To: <5905127.1244151296321.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7773810.1244645638110.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-443.
---------------------------------

    Fix Version/s: 0.5
                       (was: 0.6)
       Resolution: Done


Applied patch that changes all of the node creation to use the destination instead of doing direct writes to the graph.  Had to add an accumulator to keep track of the created paths.  This should have a beneficial effect on performance over the use of createIfMissing, since it avoids having to continually read in the nodes at the root of the graph.  The patch also adds a new test case to verify that the StreamSequencerAdapter is not creating extra nodes.

> Java sequencer is not saving content correctly
> ----------------------------------------------
>
>                 Key: DNA-443
>                 URL: https://jira.jboss.org/jira/browse/DNA-443
>             Project: DNA
>          Issue Type: Bug
>          Components: Examples, Sequencers
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>             Fix For: 0.5
>
>
> The Java sequencer doesn't appear to be sequencing the Java source code and saving it correctly.  The SequencingClientTest.shouldUploadAndSequenceJavaSourceFile() fails and has been temporarily ignored.

-- 
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 Jun 10 13:58:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 13:58:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-450) Add support to
 programmatically
 configure more complicated repository sources (e.g., federated) in
 DnaConfiguration
Message-ID: <26916616.1244656736782.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add support to programmatically configure more complicated repository sources (e.g., federated) in DnaConfiguration
-------------------------------------------------------------------------------------------------------------------

                 Key: DNA-450
                 URL: https://jira.jboss.org/jira/browse/DNA-450
             Project: DNA
          Issue Type: Feature Request
          Components: API, Connectors, Federation
    Affects Versions: 0.4
            Reporter: Randall Hauch
             Fix For: 0.6


The DnaConfiguration allows setting up repository sources, but it doesn't provide a way to do anything but set properties on those sources.  The DnaConfiguration should provide a way of adding configuration content underneath the node that represents the source.  This would make it possible to programmatically repository sources that have more complicated configuration requirements.

A workaround is to define the configuration in a file and then import that file.

-- 
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 Jun 10 14:15:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 14:15:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-451) RepositoryLibrary
 should observe
 the configuration source and should call RepositorySource.initialize(...)
 on any source whose configuration changes
Message-ID: <19329650.1244657756536.JavaMail.jira@cloud.prod.atl2.jboss.com>

RepositoryLibrary should observe the configuration source and should call RepositorySource.initialize(...) on any source whose configuration changes
----------------------------------------------------------------------------------------------------------------------------------------------------

                 Key: DNA-451
                 URL: https://jira.jboss.org/jira/browse/DNA-451
             Project: DNA
          Issue Type: Feature Request
          Components: Connectors
    Affects Versions: 0.5
            Reporter: Randall Hauch
            Priority: Minor
             Fix For: 0.6


RepositoryLibrary should observe the configuration source and should call RepositorySource.initialize(...) on any source whose configuration changes.  This will then signal each RepositorySource to update any stored configuration when the configuration repository changes.

-- 
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 Jun 10 15:57:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 10 Jun 2009 15:57:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-447) Make REST PUT Method
 Support add/removeMixin Like POST Method
In-Reply-To: <13011531.1244549106943.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16183810.1244663876494.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-447.
---------------------------------

    Fix Version/s: 0.5
                       (was: 1.0)
       Resolution: Done


Added check to JcrResources.setPropertyOnNode to handle the special case of the jcr:mixinTypes property and a corresponding test case.

Also added missing node.save() call for PUT handler.


> Make REST PUT Method Support add/removeMixin Like POST Method
> -------------------------------------------------------------
>
>                 Key: DNA-447
>                 URL: https://jira.jboss.org/jira/browse/DNA-447
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR, Server
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>            Priority: Minor
>             Fix For: 0.5
>
>
> The REST POST method automatically translates the jcr:mixinTypes property (if set on the request) into a series of addMixin calls.  The PUT method should compare the jcr:mixinTypes property (if present) to the existing mixin types for the node and attempt to add or remove mixin types as needed.

-- 
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 Jun 10 20:53:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 10 Jun 2009 20:53:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-452) Supply implementations
 for the
 different RequestProcessor methods in the federated connector
Message-ID: <438779.1244681636359.JavaMail.jira@cloud.prod.atl2.jboss.com>

Supply implementations for the different RequestProcessor methods in the federated connector
--------------------------------------------------------------------------------------------

                 Key: DNA-452
                 URL: https://jira.jboss.org/jira/browse/DNA-452
             Project: DNA
          Issue Type: Bug
          Components: Connectors, Federation
    Affects Versions: 0.5
            Reporter: Randall Hauch
             Fix For: 0.6


The federated connector's fork- and join-processors don't override all of the process(...) methods for the different kinds of update requests.  The default implementations do not work because of the fork and join separation.

-- 
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 Jun 11 05:25:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 11 Jun 2009 05:25:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-449) Federation connector
 does not find
 it's configuration when imported using the JcrConfiguration
In-Reply-To: <27261542.1244609516322.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28699947.1244712356579.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-449.
-------------------------------

    Resolution: Done


Corrected a number of issues with the federated connector.  One particularly nasty problem (and the last to be fixed) was the connector's join operations were fully awaiting until all the forking operations were completed before they were each joined.  The blocking queue was turned off, but this was causing most of the concurrency issues.

Marking this issue as resolved.

> Federation connector does not find it's configuration when imported using the JcrConfiguration
> ----------------------------------------------------------------------------------------------
>
>                 Key: DNA-449
>                 URL: https://jira.jboss.org/jira/browse/DNA-449
>             Project: DNA
>          Issue Type: Bug
>          Components: API, Connectors
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.5
>
>
> When a configuration file is imported using the JcrConfiguration (or DnaConfiguration), the Federation Connector doesn't find the connector's workspace definitions.  I believe this is because the configuration files are imported with slightly modified paths.  This problem prevents the federation connector from being used, and thus is a bigger problem.
> Fixing this should be pretty straightforward and is low risk, and simply involves supplying the correct path to the source configuration element when the RepositorySource's are initialized by the RepositoryLibrary, then changing the FederatedRepositorySource to use this new path.

-- 
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 Jun 11 05:27:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 11 Jun 2009 05:27:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-446) Screenshots of example
 applications need to be updated in the Getting Started document
In-Reply-To: <24422151.1244414947255.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4742003.1244712476322.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-446.
-------------------------------

    Resolution: Done


Marking as resolved.

> Screenshots of example applications need to be updated in the Getting Started document
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-446
>                 URL: https://jira.jboss.org/jira/browse/DNA-446
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation
>    Affects Versions: 0.4
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.5
>
>
> The screenshots in the Getting Started document showing the running examples need to be updated.

-- 
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 Jun 11 14:58:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 14:58:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-453) Implement
 Workspace.copy(String, String, String, boolean)
Message-ID: <16453302.1244746736796.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement Workspace.copy(String, String, String, boolean)
---------------------------------------------------------

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


DNA currently supports the same-workspace version of the workspace copy method.  It also must support the cross-workspace copy method for L2 compliance.

-- 
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 Jun 11 15:00:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 15:00:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-453) Implement
 Workspace.copy(String, String, String, boolean)
In-Reply-To: <16453302.1244746736796.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26777544.1244746856318.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-453:
--------------------------------

    Fix Version/s: 0.6


> Implement Workspace.copy(String, String, String, boolean)
> ---------------------------------------------------------
>
>                 Key: DNA-453
>                 URL: https://jira.jboss.org/jira/browse/DNA-453
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>
> DNA currently supports the same-workspace version of the workspace copy method.  It also must support the cross-workspace copy method for L2 compliance.

-- 
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 Jun 11 15:02:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 15:02:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-454) Implement XPath Queries
Message-ID: <15412177.1244746976310.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement XPath Queries
-----------------------

                 Key: DNA-454
                 URL: https://jira.jboss.org/jira/browse/DNA-454
             Project: DNA
          Issue Type: Sub-task
            Reporter: Brian Carothers
             Fix For: 0.6


XPath query support is required for L1 compliance.  At the moment, DNA supports creating the query, but the bits to execute the query are in place.

-- 
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 Jun 11 15:06:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 15:06:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-455) Add Sub-Project to
 Execute Official TCK
Message-ID: <28501370.1244747216332.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add Sub-Project to Execute Official TCK
---------------------------------------

                 Key: DNA-455
                 URL: https://jira.jboss.org/jira/browse/DNA-455
             Project: DNA
          Issue Type: Sub-task
          Components: JCR
    Affects Versions: 0.5
            Reporter: Brian Carothers
             Fix For: 0.6


JSR-170 compliance is achieved when all tests in the official TCK are passed.  This TCK is distinct from (but related to) the "unofficial" JackRabbit TCK that DNA currently runs each night.  In order to achieve full compliance(and make sure that future changes don't break it), an automated means of executing the official TCK (and passing or failing based on the results) should be added.

-- 
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 Jun 11 15:11:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 15:11:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-456) Add JSR-170
 Observation Optional Feature
Message-ID: <29781241.1244747516423.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add JSR-170 Observation Optional Feature
----------------------------------------

                 Key: DNA-456
                 URL: https://jira.jboss.org/jira/browse/DNA-456
             Project: DNA
          Issue Type: Feature Request
          Components: JCR
    Affects Versions: 0.5
            Reporter: Brian Carothers
             Fix For: 1.0


JSR-170 defines several optional features.  The observation feature would provide notification of node and property changes to registered listeners.

-- 
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 Jun 11 15:13:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 15:13:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-457) Add JSR-170 Locking
 Optional Feature
Message-ID: <12096963.1244747636309.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add JSR-170 Locking Optional Feature
------------------------------------

                 Key: DNA-457
                 URL: https://jira.jboss.org/jira/browse/DNA-457
             Project: DNA
          Issue Type: Feature Request
          Components: JCR
    Affects Versions: 0.5
            Reporter: Brian Carothers
             Fix For: 1.0


JSR-170 defines several optional features.  The locking feature allows users to lock nodes (and, optionally, their descendants) until the session terminates or until they are programatically unlocked.

-- 
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 Jun 11 15:32:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 15:32:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-453) Implement
 Workspace.copy(String, String, String)
In-Reply-To: <16453302.1244746736796.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1081698.1244748776307.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-453:
--------------------------------

    Summary: Implement Workspace.copy(String, String, String)  (was: Implement Workspace.copy(String, String, String, boolean))


> Implement Workspace.copy(String, String, String)
> ------------------------------------------------
>
>                 Key: DNA-453
>                 URL: https://jira.jboss.org/jira/browse/DNA-453
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>
> DNA currently supports the same-workspace version of the workspace copy method.  It also must support the cross-workspace copy method for L2 compliance.

-- 
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 Jun 11 15:41:07 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 15:41:07 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-458) Create
 SequencerOutputMap.addProperty Method
Message-ID: <21338228.1244749267793.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create SequencerOutputMap.addProperty Method
--------------------------------------------

                 Key: DNA-458
                 URL: https://jira.jboss.org/jira/browse/DNA-458
             Project: DNA
          Issue Type: Feature Request
          Components: Sequencers
    Affects Versions: 0.5
            Reporter: Brian Carothers
            Priority: Optional
             Fix For: 1.0


It would be helpful to either add an addProperty method to SequencerOutputMap or change the semantics of SequencerOutputMap.setProperty to append values instead of overwriting them.  This would allow multiple sequencers (e.g., a JAR sequencer, an ESB JAR sequencer, a SOA Governance sequencer) to operate on the same input and write to the same output nodes while adding one or more mixin types per sequencer (i.e., JAR sequencer adds java:jar mixin type, SOA-G sequencer adds jboss:artifact mixin type, no conflicts). 

There are, of course, other ways to solve this problem

-- 
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 Jun 11 16:50:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 16:50:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-459) Mandatory Child Nodes
 Can Be Removed
Message-ID: <32294891.1244753456406.JavaMail.jira@cloud.prod.atl2.jboss.com>

Mandatory Child Nodes Can Be Removed
------------------------------------

                 Key: DNA-459
                 URL: https://jira.jboss.org/jira/browse/DNA-459
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.5
            Reporter: Brian Carothers
             Fix For: 0.6


The JCR implementation will not allow a new node that is missing a mandatory child node to be saved.  It will, however, allow an existing node to be saved after a mandatory child node is removed and not replaced.  This violates the spec and breaks a TCK test case.

-- 
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 Jun 11 17:23:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 17:23:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-459) Mandatory Child Nodes
 Can Be Removed
In-Reply-To: <32294891.1244753456406.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18566685.1244755436323.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-459:
--------------------------------

    Attachment: DNA-459.patch


Attached patch that conservatively inspects every changed node (and its parent) to determine if node type definitions are violated.  This corrects the broken TCK test.

> Mandatory Child Nodes Can Be Removed
> ------------------------------------
>
>                 Key: DNA-459
>                 URL: https://jira.jboss.org/jira/browse/DNA-459
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-459.patch
>
>
> The JCR implementation will not allow a new node that is missing a mandatory child node to be saved.  It will, however, allow an existing node to be saved after a mandatory child node is removed and not replaced.  This violates the spec and breaks a TCK test case.

-- 
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 Jun 11 17:25:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 17:25:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-459) Mandatory Child Nodes
 Can Be Removed
In-Reply-To: <32294891.1244753456406.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19499120.1244755556316.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-459.
---------------------------------

    Resolution: Done
      Assignee: Brian Carothers


Committed patch to resolve issue.

> Mandatory Child Nodes Can Be Removed
> ------------------------------------
>
>                 Key: DNA-459
>                 URL: https://jira.jboss.org/jira/browse/DNA-459
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-459.patch
>
>
> The JCR implementation will not allow a new node that is missing a mandatory child node to be saved.  It will, however, allow an existing node to be saved after a mandatory child node is removed and not replaced.  This violates the spec and breaks a TCK test case.

-- 
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 Jun 11 19:19:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 19:19:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-460)
	NodeTypeManager.unregisterType
Message-ID: <11755013.1244762396313.JavaMail.jira@cloud.prod.atl2.jboss.com>

NodeTypeManager.unregisterType
------------------------------

                 Key: DNA-460
                 URL: https://jira.jboss.org/jira/browse/DNA-460
             Project: DNA
          Issue Type: Feature Request
          Components: JCR
    Affects Versions: 0.5
            Reporter: Brian Carothers
             Fix For: 1.0


The JSR-170 specification doesn't require (or really even mention) registering and unregistering custom node types.  But since DNA supports registering node types, it seems like its pretty important to support unregistering node types as well.  A swapTypes method to atomically port from one set of types to another may also be useful.

-- 
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 Jun 11 21:06:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 21:06:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-399) Need to Add
 Session.checkPermission
 Calls to Guard Read, Add Node, Set Property, and Remove Item Access
In-Reply-To: <12308912.1241888086497.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23454616.1244768816337.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-399:
--------------------------------

    Attachment: DNA-399.patch


Applied attached patch that adds permission checks to item reads, item removes, property modification and node addition calls and adds a new test case that extends the JR TCK framework, and adds a new workspace in RepositoryStubImpl creatively named 'otherWorkspace';

Adding the extra workspace will cause some false regressions in the nightly TCK run as it enables 3 cloning tests that silently passed when there was only one workspace in the repository.

I will leave this defect open for a few days (and probably post a forum topic) to try to get some feedback on if this is sufficient security for the 1.0 release.  I am curious whether there is any interest in being able to assign roles on a per repository and workspace basis in the case of multiple repositories feeding from a single JAAS source, if there is interest in adding an admin role that is required for type and namespace registration, or any other needed enhancements.

> Need to Add Session.checkPermission Calls to Guard Read, Add Node, Set Property, and Remove Item Access
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-399
>                 URL: https://jira.jboss.org/jira/browse/DNA-399
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-399.patch
>
>
> Now that JcrSession.checkPermission works (assuming patch takes), we need to add checkPermission calls to guard "read", "add_node", "remove", and "set_property" access, as per spec.

-- 
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 Jun 11 21:43:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 11 Jun 2009 21:43:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-453) Implement
 Workspace.copy(String, String, String)
In-Reply-To: <16453302.1244746736796.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29974330.1244771036317.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-453:
--------------------------------

    Attachment: DNA-453.patch


Randall, could you please review the attached patch and very that is a/the correct way to add the "fromWorkspace" capability to the graph grammar for copy operations?

Thanks!

> Implement Workspace.copy(String, String, String)
> ------------------------------------------------
>
>                 Key: DNA-453
>                 URL: https://jira.jboss.org/jira/browse/DNA-453
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-453.patch
>
>
> DNA currently supports the same-workspace version of the workspace copy method.  It also must support the cross-workspace copy method for L2 compliance.

-- 
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 Jun 11 23:26:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 11 Jun 2009 23:26:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-453) Implement
 Workspace.copy(String, String, String)
In-Reply-To: <16453302.1244746736796.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18008528.1244777216553.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-453:
-----------------------------------

This looks great.  It's optional, and when used is very readable.  Perfect.

> Implement Workspace.copy(String, String, String)
> ------------------------------------------------
>
>                 Key: DNA-453
>                 URL: https://jira.jboss.org/jira/browse/DNA-453
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-453.patch
>
>
> DNA currently supports the same-workspace version of the workspace copy method.  It also must support the cross-workspace copy method for L2 compliance.

-- 
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 Jun 12 09:08:59 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 12 Jun 2009 09:08:59 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-399) Need to Add
 Session.checkPermission
 Calls to Guard Read, Add Node, Set Property, and Remove Item Access
In-Reply-To: <12308912.1241888086497.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32045075.1244812139463.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-399:
--------------------------------

    JBoss Forum Reference: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156950


Added forum topic: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=156950

> Need to Add Session.checkPermission Calls to Guard Read, Add Node, Set Property, and Remove Item Access
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-399
>                 URL: https://jira.jboss.org/jira/browse/DNA-399
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-399.patch
>
>
> Now that JcrSession.checkPermission works (assuming patch takes), we need to add checkPermission calls to guard "read", "add_node", "remove", and "set_property" access, as per spec.

-- 
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 Jun 13 11:55:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 13 Jun 2009 11:55:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-460)
	NodeTypeManager.unregisterType
In-Reply-To: <11755013.1244762396313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18776936.1244908556321.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-460:
--------------------------------

    Attachment: DNA-460.patch


Committed most of unregisterTypes method.  Still need to add check that the type is not in use on any nodes, but this should be much easier after queries are implemented.  Leaving this open until that piece of the issue is corrected.


> NodeTypeManager.unregisterType
> ------------------------------
>
>                 Key: DNA-460
>                 URL: https://jira.jboss.org/jira/browse/DNA-460
>             Project: DNA
>          Issue Type: Feature Request
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>             Fix For: 1.0
>
>         Attachments: DNA-460.patch
>
>
> The JSR-170 specification doesn't require (or really even mention) registering and unregistering custom node types.  But since DNA supports registering node types, it seems like its pretty important to support unregistering node types as well.  A swapTypes method to atomically port from one set of types to another may also be useful.

-- 
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 Jun 14 18:58:07 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sun, 14 Jun 2009 18:58:07 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-453) Implement
 Workspace.copy(String, String, String)
In-Reply-To: <16453302.1244746736796.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9426915.1245020287528.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-453:
--------------------------------

    Attachment: DNA-453.patch


Attached patch that modifies the copy operation in Graph and Graph.Batch to support the "fromWorkspace" construct, allowing users to specify that the source node is in a workspace other than the current workspace.  The patch also moves the JcrWorkspace.copy(String, String) code into JcrWorkspace.copy(String, String, String) and generalizes it to support source nodes in workspaces other than the workspace represented by the JcrWorkspace.  

The patch modifies JcrWorkspace.copy(String, String) to call JcrWorkspace.copy(String, String, String) with the name of the current workspace as the source workspace.  This allows for the corner cases of the JcrWorkspace.copy(String, String, String) to be tested by the JR TCK tests.  Added an additional test to DnaTckTest to test copying from workspace to another.  For some reason the JR TCK tests don't actually do this.

Finally, the patch adds the concept of UuidConflictBehavior to the copy operation and CopyBranchRequest.  This feature is not yet implemented in the request processors, but is needed in order to implement the JcrWorkspace.clone(...)  and update(String) methods as copies from one workspace to another.

> Implement Workspace.copy(String, String, String)
> ------------------------------------------------
>
>                 Key: DNA-453
>                 URL: https://jira.jboss.org/jira/browse/DNA-453
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-453.patch, DNA-453.patch
>
>
> DNA currently supports the same-workspace version of the workspace copy method.  It also must support the cross-workspace copy method for L2 compliance.

-- 
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 Jun 14 19:09:08 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sun, 14 Jun 2009 19:09:08 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-453) Implement
 Workspace.copy(String, String, String)
In-Reply-To: <16453302.1244746736796.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10667801.1245020948365.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-453.
---------------------------------

    Resolution: Done
      Assignee: Brian Carothers


Applied patch to add missing functionality

> Implement Workspace.copy(String, String, String)
> ------------------------------------------------
>
>                 Key: DNA-453
>                 URL: https://jira.jboss.org/jira/browse/DNA-453
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-453.patch, DNA-453.patch
>
>
> DNA currently supports the same-workspace version of the workspace copy method.  It also must support the cross-workspace copy method for L2 compliance.

-- 
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 Jun 15 15:46:56 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Mon, 15 Jun 2009 15:46:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-461) new item in source
 doesn't appear in federated source projection
Message-ID: <27089832.1245095216332.JavaMail.jira@cloud.prod.atl2.jboss.com>

new item in source doesn't appear in federated source projection 
-----------------------------------------------------------------

                 Key: DNA-461
                 URL: https://jira.jboss.org/jira/browse/DNA-461
             Project: DNA
          Issue Type: Bug
          Components: Connectors, Examples, Federation
    Affects Versions: 0.5
         Environment: Mac OS 10.5.7 with JVM 1.6 and maven 2.1
            Reporter: Luiz Fernando Teston


I'm not sure if it is a bug or an error in my configuration or environment. I just follow the examples without getting the CNDs and also without importing the example data. When I create some new item using the graph api this item is created in a correct way on the repository source that I'm using (example: cars) but it doesn't appears on the projection on federated source (example: vehicles/cars). I created this test case that should be used on doc/examples/repository project. I also did this same test using the JAAS configuration. 


package org.jboss.example.dna.repository;

import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsNull.notNullValue;
import static org.junit.Assert.assertThat;

import java.net.URL;

import org.jboss.dna.graph.Graph;
import org.jboss.dna.jcr.JcrConfiguration;
import org.jboss.dna.jcr.JcrEngine;
import org.junit.Test;

public class FederationOnDifferentSourcesTest {

	@Test
	public void shouldHaveProjectionInsideFederatedSource()
			throws Exception {

		JcrConfiguration configuration = new JcrConfiguration();
		URL configUrl = Thread.currentThread().getContextClassLoader()
				.getResource("configRepository.xml");

		assertThat(configUrl, is(notNullValue()));

		configuration.loadFrom(configUrl);

		JcrEngine engine = configuration.build();

		engine.start();

		Graph vehiclesGraph = engine.getGraph("Vechicles");
		
		assertThat(vehiclesGraph.getNodeAt("/Cars"), is(notNullValue()));

	}

	@Test
	public void shouldCreateItemOnSourceRepositoryAndShowTheSameItemOnFederatedSource()
			throws Exception {

		JcrConfiguration configuration = new JcrConfiguration();
		URL configUrl = Thread.currentThread().getContextClassLoader()
				.getResource("configRepository.xml");

		assertThat(configUrl, is(notNullValue()));

		configuration.loadFrom(configUrl);

		JcrEngine engine = configuration.build();

		engine.start();

		Graph carsGraph = engine.getGraph("Cars");
		
		carsGraph.create("/Honda");

		assertThat(carsGraph.getNodeAt("/Honda"), is(notNullValue()));

		Graph vehiclesGraph = engine.getGraph("Vehicles");

		assertThat(vehiclesGraph.getNodeAt("/Cars/Honda"), is(notNullValue()));

	}

}


-- 
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 Jun 15 16:06:56 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Mon, 15 Jun 2009 16:06:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-462) filesystem source
 doesn't appear on federate source projection
Message-ID: <2012096.1245096416313.JavaMail.jira@cloud.prod.atl2.jboss.com>

filesystem source doesn't appear on federate source projection
--------------------------------------------------------------

                 Key: DNA-462
                 URL: https://jira.jboss.org/jira/browse/DNA-462
             Project: DNA
          Issue Type: Bug
          Components: Connectors
    Affects Versions: 0.5
         Environment: Mac OS 10.5.7 with JVM 1.6 and Maven 2.1
            Reporter: Luiz Fernando Teston


When I create a filesystem source I can access its contents using the graph api. But the same content doesn't appear on a federated source with the filesystem source on a projection path. I used the same logic on the docs/examples/repository project configuration, just adding the /tmp to a filesystem source. I've tested the same scenario using the JAAS configuration. The test case and configuration file is here:

-- configuration file: configRepositoryWithFileSystemConnector.xml --
<?xml version="1.0" encoding="UTF-8"?>
<!-- 
  ~ JBoss DNA (http://www.jboss.org/dna)
  ~
  ~ See the COPYRIGHT.txt file distributed with this work for information
  ~ regarding copyright ownership.  Some portions may be licensed
  ~ to Red Hat, Inc. under one or more contributor license agreements.
  ~ See the AUTHORS.txt file in the distribution for a full listing of 
  ~ individual contributors.
  ~
  ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
  ~ is licensed to you under the terms of the GNU Lesser General Public License as
  ~ published by the Free Software Foundation; either version 2.1 of
  ~ the License, or (at your option) any later version.
  ~
  ~ JBoss DNA is distributed in the hope that it will be useful,
  ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
  ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
  ~ for more details.
  ~
  ~ You should have received a copy of the GNU Lesser General Public License
  ~ along with this distribution; if not, write to:
  ~ Free Software Foundation, Inc.
  ~ 51 Franklin Street, Fifth Floor
  ~ Boston, MA  02110-1301  USA
  -->
<configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
    <!-- 
    Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
    In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
    JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
    -->
    <dna:sources jcr:primaryType="nt:unstructured">
        
        <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource">
            <defaultWorkspaceName>workspace2</defaultWorkspaceName>
            <directoryForDefaultWorkspace>/tmp/</directoryForDefaultWorkspace>
        </dna:source>
        
        <!-- 
        The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
        -->
        <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>
        <!-- 
        The 'Aircraft' repository is also an in-memory source with a single default workspace.
        By defining a default workspace, the clients using the Graph API will by default use that workspace,
        but can easily say to use other workspaces (or create, clone, or destroy workspaces).
        -->
        <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
            <!-- Define the name of the workspace used by default.  Optional, but convenient. -->
            <defaultWorkspaceName>workspace2</defaultWorkspaceName>
        </dna:source>
        <!-- 
        The 'Vehicles' repository is a federated source that owns none of its own content, but instead
        projects (in this case) all of the content from the 'Cars' source as if it appears
        under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
        -->
        <dna:source jcr:name="Vehicles">
            <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
            <dna:workspaces>
                <!-- 
                Unlike some other repository sources, federated sources have to define all of their workspaces,
                including how and where the content is projected.  So, we only need a single workspace,
                but we could actually define additional workspaces that expose various combinations or portions
                of 'Cars' and/or 'Aircraft' content.
                -->
                <dna:workspace jcr:name="virtual">
                    <dna:projections>
                        <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="workspace2">
                            <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules>
                        </dna:projection>
                        
                        
                        <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
                        <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace1">
                            <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
                        </dna:projection>
                        <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node. -->
                        <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace2">
                            <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
                        </dna:projection>
                        <!-- Project the 'System' content. Only needed when this source is accessed through JCR. -->
                        <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
                            <dna:projectionRules>/jcr:system => /</dna:projectionRules>
                        </dna:projection>
                    </dna:projections>
                </dna:workspace>
            </dna:workspaces>
        </dna:source>
        <!-- 
        A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
        -->
        <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
    </dna:sources>
    <!-- 
    Define the sequencers. This is an optional section. For this example, we're not using any sequencers. 
    -->
    <dna:sequencers>
        <!--dna:sequencer jcr:name="Image Sequencer" dna:classname="org.jboss.dna.sequencer.image.ImageMetadataSequencer">
            <dna:description>Image metadata sequencer</dna:description>        
            <dna:pathExpression>/foo/source => /foo/target</dna:pathExpression>
            <dna:pathExpression>/bar/source => /bar/target</dna:pathExpression>
        </dna:sequencer-->
    </dna:sequencers>
    <!-- 
    Define the mime type detectors. This is an optional section.  By default, each engine will use the 
    MIME type detector that uses filename extensions.  So we wouldn't need to define the same detector again,
    but this is how you'd define another extension.
    -->
    <dna:mimeTypeDetectors>
        <dna:mimeTypeDetector jcr:name="Detector">
            <dna:description>Standard extension-based MIME type detector</dna:description>        
            <!-- 
            Specify the implementation class (required), as a child element or attribute on parent element.
            -->
            <dna:classname>org.jboss.dna.graph.mimetype.ExtensionBasedMimeTypeDetector</dna:classname>
            <!-- 
            Specify the classpath (optional) as an ordered list of 'names', where each name is significant to 
            the classpath factory.  For example, a name could be an OSGI identifier or a Maven coordinate,
            depending upon the classpath factory being used.  If there is only one 'name' in the classpath,
            it may be specified as an attribute on the 'mimeTypeDetector' element.  If there is more than one
            'name', then they must be specified as child 'classpath' elements. Blank or empty values are ignored. 
             -->
            <dna:classpath></dna:classpath>
            <dna:classpath></dna:classpath>
        </dna:mimeTypeDetector>
    </dna:mimeTypeDetectors>
    <!-- 
    Define the JCR repositories 
    -->
    <dna:repositories>
        <!-- 
        Define a JCR repository that accesses the 'Cars' source directly.
        This of course is optional, since we could access the same content through 'vehicles'.
        -->
        <dna:repository jcr:name="Cars">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Cars</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
            <dna:options jcr:primaryType="dna:options">
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
            <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
            <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
            <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA -->
            <namespaces jcr:primaryType="dna:namespaces">
                <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
            </namespaces>
        </dna:repository>
        <!-- 
        Define a JCR repository that accesses the 'Aircraft' source directly.
        This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
        -->
        <dna:repository jcr:name="Aircraft">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Aircraft</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
            <dna:options jcr:primaryType="dna:options">
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
        </dna:repository>
        <!-- 
        Define a JCR repository that accesses the 'Vehicles' federated source directly,
        which is defined in the sources to be a projection of the 'Cars' and 'Vehicles' content.
        -->
        <!-- Define a JCR repository that accesses the 'Vehicles' federated source directly -->
        <dna:repository jcr:name="Vehicles">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Vehicles</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
            <dna:options jcr:primaryType="dna:options">
                <projectNodeTypes jcr:primaryType="dna:option" dna:value="false"/>
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
            <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
            <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
            <!-- Define any namespaces for this repository, other than those already defined by JCR, DNA or by imported content. -->
            <dna:namespaces jcr:primaryType="dna:namespaces">
                <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
                <air jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/aircraft/1.0"/>
            </dna:namespaces>
        </dna:repository>
    </dna:repositories>
</configuration>


-- test case --

package org.jboss.example.dna.repository;

import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsNull.notNullValue;
import static org.junit.Assert.assertThat;

import java.net.URL;

import org.jboss.dna.graph.Graph;
import org.jboss.dna.jcr.JcrConfiguration;
import org.jboss.dna.jcr.JcrEngine;
import org.junit.Test;

public class FileSystemConnectorUnderFederatedSourceTest {

	@Test
	public void shouldHaveProjectionOfFileSystemSourceInsideFederatedSource()
			throws Exception {

		JcrConfiguration configuration = new JcrConfiguration();
		URL configUrl = Thread.currentThread().getContextClassLoader()
				.getResource("configRepositoryWithFileSystemConnector.xml");

		assertThat(configUrl, is(notNullValue()));

		configuration.loadFrom(configUrl);

		JcrEngine engine = configuration.build();

		engine.start();

		Graph vehiclesGraph = engine.getGraph("Vechicles");

		assertThat(vehiclesGraph.getNodeAt("/FileSystem"), is(notNullValue()));

	}
}


-- 
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 Jun 15 16:16:00 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Mon, 15 Jun 2009 16:16:00 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-461) new item in source
 doesn't appear in federated source projection
In-Reply-To: <27089832.1245095216332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1749788.1245096960161.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Luiz Fernando Teston updated DNA-461:
-------------------------------------

    Description: 
I'm not sure if it is a bug or an error in my configuration or environment. I just follow the examples without getting the CNDs and also without importing the example data. When I create some new item using the graph api this item is created in a correct way on the repository source that I'm using (example: cars) but it doesn't appears on the projection on federated source (example: vehicles/cars). I created this test case that should be used on doc/examples/repository project. I also did this same test using the JAAS configuration. 


package org.jboss.example.dna.repository;

import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsNull.notNullValue;
import static org.junit.Assert.assertThat;

import java.net.URL;

import org.jboss.dna.graph.Graph;
import org.jboss.dna.jcr.JcrConfiguration;
import org.jboss.dna.jcr.JcrEngine;
import org.junit.Test;

public class FederationOnDifferentSourcesTest {

	@Test
	public void shouldHaveProjectionInsideFederatedSource()
			throws Exception {

		JcrConfiguration configuration = new JcrConfiguration();
		URL configUrl = Thread.currentThread().getContextClassLoader()
				.getResource("configRepository.xml");

		assertThat(configUrl, is(notNullValue()));

		configuration.loadFrom(configUrl);

		JcrEngine engine = configuration.build();

		engine.start();

		Graph vehiclesGraph = engine.getGraph("Vehicles");
		
		assertThat(vehiclesGraph.getNodeAt("/Cars"), is(notNullValue()));

	}

	@Test
	public void shouldCreateItemOnSourceRepositoryAndShowTheSameItemOnFederatedSource()
			throws Exception {

		JcrConfiguration configuration = new JcrConfiguration();
		URL configUrl = Thread.currentThread().getContextClassLoader()
				.getResource("configRepository.xml");

		assertThat(configUrl, is(notNullValue()));

		configuration.loadFrom(configUrl);

		JcrEngine engine = configuration.build();

		engine.start();

		Graph carsGraph = engine.getGraph("Cars");
		
		carsGraph.create("/Honda");

		assertThat(carsGraph.getNodeAt("/Honda"), is(notNullValue()));

		Graph vehiclesGraph = engine.getGraph("Vehicles");

		assertThat(vehiclesGraph.getNodeAt("/Cars/Honda"), is(notNullValue()));

	}

}


  was:
I'm not sure if it is a bug or an error in my configuration or environment. I just follow the examples without getting the CNDs and also without importing the example data. When I create some new item using the graph api this item is created in a correct way on the repository source that I'm using (example: cars) but it doesn't appears on the projection on federated source (example: vehicles/cars). I created this test case that should be used on doc/examples/repository project. I also did this same test using the JAAS configuration. 


package org.jboss.example.dna.repository;

import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsNull.notNullValue;
import static org.junit.Assert.assertThat;

import java.net.URL;

import org.jboss.dna.graph.Graph;
import org.jboss.dna.jcr.JcrConfiguration;
import org.jboss.dna.jcr.JcrEngine;
import org.junit.Test;

public class FederationOnDifferentSourcesTest {

	@Test
	public void shouldHaveProjectionInsideFederatedSource()
			throws Exception {

		JcrConfiguration configuration = new JcrConfiguration();
		URL configUrl = Thread.currentThread().getContextClassLoader()
				.getResource("configRepository.xml");

		assertThat(configUrl, is(notNullValue()));

		configuration.loadFrom(configUrl);

		JcrEngine engine = configuration.build();

		engine.start();

		Graph vehiclesGraph = engine.getGraph("Vechicles");
		
		assertThat(vehiclesGraph.getNodeAt("/Cars"), is(notNullValue()));

	}

	@Test
	public void shouldCreateItemOnSourceRepositoryAndShowTheSameItemOnFederatedSource()
			throws Exception {

		JcrConfiguration configuration = new JcrConfiguration();
		URL configUrl = Thread.currentThread().getContextClassLoader()
				.getResource("configRepository.xml");

		assertThat(configUrl, is(notNullValue()));

		configuration.loadFrom(configUrl);

		JcrEngine engine = configuration.build();

		engine.start();

		Graph carsGraph = engine.getGraph("Cars");
		
		carsGraph.create("/Honda");

		assertThat(carsGraph.getNodeAt("/Honda"), is(notNullValue()));

		Graph vehiclesGraph = engine.getGraph("Vehicles");

		assertThat(vehiclesGraph.getNodeAt("/Cars/Honda"), is(notNullValue()));

	}

}




> new item in source doesn't appear in federated source projection 
> -----------------------------------------------------------------
>
>                 Key: DNA-461
>                 URL: https://jira.jboss.org/jira/browse/DNA-461
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Examples, Federation
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5.7 with JVM 1.6 and maven 2.1
>            Reporter: Luiz Fernando Teston
>
> I'm not sure if it is a bug or an error in my configuration or environment. I just follow the examples without getting the CNDs and also without importing the example data. When I create some new item using the graph api this item is created in a correct way on the repository source that I'm using (example: cars) but it doesn't appears on the projection on federated source (example: vehicles/cars). I created this test case that should be used on doc/examples/repository project. I also did this same test using the JAAS configuration. 
> package org.jboss.example.dna.repository;
> import static org.hamcrest.core.Is.is;
> import static org.hamcrest.core.IsNull.notNullValue;
> import static org.junit.Assert.assertThat;
> import java.net.URL;
> import org.jboss.dna.graph.Graph;
> import org.jboss.dna.jcr.JcrConfiguration;
> import org.jboss.dna.jcr.JcrEngine;
> import org.junit.Test;
> public class FederationOnDifferentSourcesTest {
> 	@Test
> 	public void shouldHaveProjectionInsideFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		
> 		assertThat(vehiclesGraph.getNodeAt("/Cars"), is(notNullValue()));
> 	}
> 	@Test
> 	public void shouldCreateItemOnSourceRepositoryAndShowTheSameItemOnFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph carsGraph = engine.getGraph("Cars");
> 		
> 		carsGraph.create("/Honda");
> 		assertThat(carsGraph.getNodeAt("/Honda"), is(notNullValue()));
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		assertThat(vehiclesGraph.getNodeAt("/Cars/Honda"), is(notNullValue()));
> 	}
> }

-- 
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 Jun 15 16:17:56 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Mon, 15 Jun 2009 16:17:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-462) filesystem source
 doesn't appear on federate source projection
In-Reply-To: <2012096.1245096416313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <22570577.1245097076358.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Luiz Fernando Teston updated DNA-462:
-------------------------------------

    Description: 
When I create a filesystem source I can access its contents using the graph api. But the same content doesn't appear on a federated source with the filesystem source on a projection path. I used the same logic on the docs/examples/repository project configuration, just adding the /tmp to a filesystem source. I've tested the same scenario using the JAAS configuration. The test case and configuration file is here:

-- configuration file: configRepositoryWithFileSystemConnector.xml --
<?xml version="1.0" encoding="UTF-8"?>
<!-- 
  ~ JBoss DNA (http://www.jboss.org/dna)
  ~
  ~ See the COPYRIGHT.txt file distributed with this work for information
  ~ regarding copyright ownership.  Some portions may be licensed
  ~ to Red Hat, Inc. under one or more contributor license agreements.
  ~ See the AUTHORS.txt file in the distribution for a full listing of 
  ~ individual contributors.
  ~
  ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
  ~ is licensed to you under the terms of the GNU Lesser General Public License as
  ~ published by the Free Software Foundation; either version 2.1 of
  ~ the License, or (at your option) any later version.
  ~
  ~ JBoss DNA is distributed in the hope that it will be useful,
  ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
  ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
  ~ for more details.
  ~
  ~ You should have received a copy of the GNU Lesser General Public License
  ~ along with this distribution; if not, write to:
  ~ Free Software Foundation, Inc.
  ~ 51 Franklin Street, Fifth Floor
  ~ Boston, MA  02110-1301  USA
  -->
<configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
    <!-- 
    Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
    In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
    JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
    -->
    <dna:sources jcr:primaryType="nt:unstructured">
        
        <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource">
            <defaultWorkspaceName>workspace2</defaultWorkspaceName>
            <directoryForDefaultWorkspace>/tmp/</directoryForDefaultWorkspace>
        </dna:source>
        
        <!-- 
        The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
        -->
        <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>
        <!-- 
        The 'Aircraft' repository is also an in-memory source with a single default workspace.
        By defining a default workspace, the clients using the Graph API will by default use that workspace,
        but can easily say to use other workspaces (or create, clone, or destroy workspaces).
        -->
        <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
            <!-- Define the name of the workspace used by default.  Optional, but convenient. -->
            <defaultWorkspaceName>workspace2</defaultWorkspaceName>
        </dna:source>
        <!-- 
        The 'Vehicles' repository is a federated source that owns none of its own content, but instead
        projects (in this case) all of the content from the 'Cars' source as if it appears
        under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
        -->
        <dna:source jcr:name="Vehicles">
            <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
            <dna:workspaces>
                <!-- 
                Unlike some other repository sources, federated sources have to define all of their workspaces,
                including how and where the content is projected.  So, we only need a single workspace,
                but we could actually define additional workspaces that expose various combinations or portions
                of 'Cars' and/or 'Aircraft' content.
                -->
                <dna:workspace jcr:name="virtual">
                    <dna:projections>
                        <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="workspace2">
                            <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules>
                        </dna:projection>
                        
                        
                        <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
                        <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace1">
                            <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
                        </dna:projection>
                        <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node. -->
                        <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace2">
                            <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
                        </dna:projection>
                        <!-- Project the 'System' content. Only needed when this source is accessed through JCR. -->
                        <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
                            <dna:projectionRules>/jcr:system => /</dna:projectionRules>
                        </dna:projection>
                    </dna:projections>
                </dna:workspace>
            </dna:workspaces>
        </dna:source>
        <!-- 
        A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
        -->
        <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
    </dna:sources>
    <!-- 
    Define the sequencers. This is an optional section. For this example, we're not using any sequencers. 
    -->
    <dna:sequencers>
        <!--dna:sequencer jcr:name="Image Sequencer" dna:classname="org.jboss.dna.sequencer.image.ImageMetadataSequencer">
            <dna:description>Image metadata sequencer</dna:description>        
            <dna:pathExpression>/foo/source => /foo/target</dna:pathExpression>
            <dna:pathExpression>/bar/source => /bar/target</dna:pathExpression>
        </dna:sequencer-->
    </dna:sequencers>
    <!-- 
    Define the mime type detectors. This is an optional section.  By default, each engine will use the 
    MIME type detector that uses filename extensions.  So we wouldn't need to define the same detector again,
    but this is how you'd define another extension.
    -->
    <dna:mimeTypeDetectors>
        <dna:mimeTypeDetector jcr:name="Detector">
            <dna:description>Standard extension-based MIME type detector</dna:description>        
            <!-- 
            Specify the implementation class (required), as a child element or attribute on parent element.
            -->
            <dna:classname>org.jboss.dna.graph.mimetype.ExtensionBasedMimeTypeDetector</dna:classname>
            <!-- 
            Specify the classpath (optional) as an ordered list of 'names', where each name is significant to 
            the classpath factory.  For example, a name could be an OSGI identifier or a Maven coordinate,
            depending upon the classpath factory being used.  If there is only one 'name' in the classpath,
            it may be specified as an attribute on the 'mimeTypeDetector' element.  If there is more than one
            'name', then they must be specified as child 'classpath' elements. Blank or empty values are ignored. 
             -->
            <dna:classpath></dna:classpath>
            <dna:classpath></dna:classpath>
        </dna:mimeTypeDetector>
    </dna:mimeTypeDetectors>
    <!-- 
    Define the JCR repositories 
    -->
    <dna:repositories>
        <!-- 
        Define a JCR repository that accesses the 'Cars' source directly.
        This of course is optional, since we could access the same content through 'vehicles'.
        -->
        <dna:repository jcr:name="Cars">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Cars</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
            <dna:options jcr:primaryType="dna:options">
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
            <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
            <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
            <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA -->
            <namespaces jcr:primaryType="dna:namespaces">
                <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
            </namespaces>
        </dna:repository>
        <!-- 
        Define a JCR repository that accesses the 'Aircraft' source directly.
        This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
        -->
        <dna:repository jcr:name="Aircraft">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Aircraft</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
            <dna:options jcr:primaryType="dna:options">
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
        </dna:repository>
        <!-- 
        Define a JCR repository that accesses the 'Vehicles' federated source directly,
        which is defined in the sources to be a projection of the 'Cars' and 'Vehicles' content.
        -->
        <!-- Define a JCR repository that accesses the 'Vehicles' federated source directly -->
        <dna:repository jcr:name="Vehicles">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Vehicles</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
            <dna:options jcr:primaryType="dna:options">
                <projectNodeTypes jcr:primaryType="dna:option" dna:value="false"/>
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
            <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
            <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
            <!-- Define any namespaces for this repository, other than those already defined by JCR, DNA or by imported content. -->
            <dna:namespaces jcr:primaryType="dna:namespaces">
                <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
                <air jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/aircraft/1.0"/>
            </dna:namespaces>
        </dna:repository>
    </dna:repositories>
</configuration>


-- test case --

package org.jboss.example.dna.repository;

import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsNull.notNullValue;
import static org.junit.Assert.assertThat;

import java.net.URL;

import org.jboss.dna.graph.Graph;
import org.jboss.dna.jcr.JcrConfiguration;
import org.jboss.dna.jcr.JcrEngine;
import org.junit.Test;

public class FileSystemConnectorUnderFederatedSourceTest {

	@Test
	public void shouldHaveProjectionOfFileSystemSourceInsideFederatedSource()
			throws Exception {

		JcrConfiguration configuration = new JcrConfiguration();
		URL configUrl = Thread.currentThread().getContextClassLoader()
				.getResource("configRepositoryWithFileSystemConnector.xml");

		assertThat(configUrl, is(notNullValue()));

		configuration.loadFrom(configUrl);

		JcrEngine engine = configuration.build();

		engine.start();

		Graph vehiclesGraph = engine.getGraph("Vehicles");

		assertThat(vehiclesGraph.getNodeAt("/FileSystem"), is(notNullValue()));

	}
}


  was:
When I create a filesystem source I can access its contents using the graph api. But the same content doesn't appear on a federated source with the filesystem source on a projection path. I used the same logic on the docs/examples/repository project configuration, just adding the /tmp to a filesystem source. I've tested the same scenario using the JAAS configuration. The test case and configuration file is here:

-- configuration file: configRepositoryWithFileSystemConnector.xml --
<?xml version="1.0" encoding="UTF-8"?>
<!-- 
  ~ JBoss DNA (http://www.jboss.org/dna)
  ~
  ~ See the COPYRIGHT.txt file distributed with this work for information
  ~ regarding copyright ownership.  Some portions may be licensed
  ~ to Red Hat, Inc. under one or more contributor license agreements.
  ~ See the AUTHORS.txt file in the distribution for a full listing of 
  ~ individual contributors.
  ~
  ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
  ~ is licensed to you under the terms of the GNU Lesser General Public License as
  ~ published by the Free Software Foundation; either version 2.1 of
  ~ the License, or (at your option) any later version.
  ~
  ~ JBoss DNA is distributed in the hope that it will be useful,
  ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
  ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
  ~ for more details.
  ~
  ~ You should have received a copy of the GNU Lesser General Public License
  ~ along with this distribution; if not, write to:
  ~ Free Software Foundation, Inc.
  ~ 51 Franklin Street, Fifth Floor
  ~ Boston, MA  02110-1301  USA
  -->
<configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
    <!-- 
    Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
    In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
    JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
    -->
    <dna:sources jcr:primaryType="nt:unstructured">
        
        <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource">
            <defaultWorkspaceName>workspace2</defaultWorkspaceName>
            <directoryForDefaultWorkspace>/tmp/</directoryForDefaultWorkspace>
        </dna:source>
        
        <!-- 
        The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
        -->
        <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>
        <!-- 
        The 'Aircraft' repository is also an in-memory source with a single default workspace.
        By defining a default workspace, the clients using the Graph API will by default use that workspace,
        but can easily say to use other workspaces (or create, clone, or destroy workspaces).
        -->
        <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
            <!-- Define the name of the workspace used by default.  Optional, but convenient. -->
            <defaultWorkspaceName>workspace2</defaultWorkspaceName>
        </dna:source>
        <!-- 
        The 'Vehicles' repository is a federated source that owns none of its own content, but instead
        projects (in this case) all of the content from the 'Cars' source as if it appears
        under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
        -->
        <dna:source jcr:name="Vehicles">
            <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
            <dna:workspaces>
                <!-- 
                Unlike some other repository sources, federated sources have to define all of their workspaces,
                including how and where the content is projected.  So, we only need a single workspace,
                but we could actually define additional workspaces that expose various combinations or portions
                of 'Cars' and/or 'Aircraft' content.
                -->
                <dna:workspace jcr:name="virtual">
                    <dna:projections>
                        <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="workspace2">
                            <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules>
                        </dna:projection>
                        
                        
                        <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
                        <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace1">
                            <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
                        </dna:projection>
                        <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node. -->
                        <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace2">
                            <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
                        </dna:projection>
                        <!-- Project the 'System' content. Only needed when this source is accessed through JCR. -->
                        <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
                            <dna:projectionRules>/jcr:system => /</dna:projectionRules>
                        </dna:projection>
                    </dna:projections>
                </dna:workspace>
            </dna:workspaces>
        </dna:source>
        <!-- 
        A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
        -->
        <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
    </dna:sources>
    <!-- 
    Define the sequencers. This is an optional section. For this example, we're not using any sequencers. 
    -->
    <dna:sequencers>
        <!--dna:sequencer jcr:name="Image Sequencer" dna:classname="org.jboss.dna.sequencer.image.ImageMetadataSequencer">
            <dna:description>Image metadata sequencer</dna:description>        
            <dna:pathExpression>/foo/source => /foo/target</dna:pathExpression>
            <dna:pathExpression>/bar/source => /bar/target</dna:pathExpression>
        </dna:sequencer-->
    </dna:sequencers>
    <!-- 
    Define the mime type detectors. This is an optional section.  By default, each engine will use the 
    MIME type detector that uses filename extensions.  So we wouldn't need to define the same detector again,
    but this is how you'd define another extension.
    -->
    <dna:mimeTypeDetectors>
        <dna:mimeTypeDetector jcr:name="Detector">
            <dna:description>Standard extension-based MIME type detector</dna:description>        
            <!-- 
            Specify the implementation class (required), as a child element or attribute on parent element.
            -->
            <dna:classname>org.jboss.dna.graph.mimetype.ExtensionBasedMimeTypeDetector</dna:classname>
            <!-- 
            Specify the classpath (optional) as an ordered list of 'names', where each name is significant to 
            the classpath factory.  For example, a name could be an OSGI identifier or a Maven coordinate,
            depending upon the classpath factory being used.  If there is only one 'name' in the classpath,
            it may be specified as an attribute on the 'mimeTypeDetector' element.  If there is more than one
            'name', then they must be specified as child 'classpath' elements. Blank or empty values are ignored. 
             -->
            <dna:classpath></dna:classpath>
            <dna:classpath></dna:classpath>
        </dna:mimeTypeDetector>
    </dna:mimeTypeDetectors>
    <!-- 
    Define the JCR repositories 
    -->
    <dna:repositories>
        <!-- 
        Define a JCR repository that accesses the 'Cars' source directly.
        This of course is optional, since we could access the same content through 'vehicles'.
        -->
        <dna:repository jcr:name="Cars">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Cars</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
            <dna:options jcr:primaryType="dna:options">
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
            <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
            <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
            <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA -->
            <namespaces jcr:primaryType="dna:namespaces">
                <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
            </namespaces>
        </dna:repository>
        <!-- 
        Define a JCR repository that accesses the 'Aircraft' source directly.
        This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
        -->
        <dna:repository jcr:name="Aircraft">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Aircraft</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
            <dna:options jcr:primaryType="dna:options">
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
        </dna:repository>
        <!-- 
        Define a JCR repository that accesses the 'Vehicles' federated source directly,
        which is defined in the sources to be a projection of the 'Cars' and 'Vehicles' content.
        -->
        <!-- Define a JCR repository that accesses the 'Vehicles' federated source directly -->
        <dna:repository jcr:name="Vehicles">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Vehicles</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
            <dna:options jcr:primaryType="dna:options">
                <projectNodeTypes jcr:primaryType="dna:option" dna:value="false"/>
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
            <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
            <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
            <!-- Define any namespaces for this repository, other than those already defined by JCR, DNA or by imported content. -->
            <dna:namespaces jcr:primaryType="dna:namespaces">
                <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
                <air jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/aircraft/1.0"/>
            </dna:namespaces>
        </dna:repository>
    </dna:repositories>
</configuration>


-- test case --

package org.jboss.example.dna.repository;

import static org.hamcrest.core.Is.is;
import static org.hamcrest.core.IsNull.notNullValue;
import static org.junit.Assert.assertThat;

import java.net.URL;

import org.jboss.dna.graph.Graph;
import org.jboss.dna.jcr.JcrConfiguration;
import org.jboss.dna.jcr.JcrEngine;
import org.junit.Test;

public class FileSystemConnectorUnderFederatedSourceTest {

	@Test
	public void shouldHaveProjectionOfFileSystemSourceInsideFederatedSource()
			throws Exception {

		JcrConfiguration configuration = new JcrConfiguration();
		URL configUrl = Thread.currentThread().getContextClassLoader()
				.getResource("configRepositoryWithFileSystemConnector.xml");

		assertThat(configUrl, is(notNullValue()));

		configuration.loadFrom(configUrl);

		JcrEngine engine = configuration.build();

		engine.start();

		Graph vehiclesGraph = engine.getGraph("Vechicles");

		assertThat(vehiclesGraph.getNodeAt("/FileSystem"), is(notNullValue()));

	}
}




> filesystem source doesn't appear on federate source projection
> --------------------------------------------------------------
>
>                 Key: DNA-462
>                 URL: https://jira.jboss.org/jira/browse/DNA-462
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5.7 with JVM 1.6 and Maven 2.1
>            Reporter: Luiz Fernando Teston
>
> When I create a filesystem source I can access its contents using the graph api. But the same content doesn't appear on a federated source with the filesystem source on a projection path. I used the same logic on the docs/examples/repository project configuration, just adding the /tmp to a filesystem source. I've tested the same scenario using the JAAS configuration. The test case and configuration file is here:
> -- configuration file: configRepositoryWithFileSystemConnector.xml --
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- 
>   ~ JBoss DNA (http://www.jboss.org/dna)
>   ~
>   ~ See the COPYRIGHT.txt file distributed with this work for information
>   ~ regarding copyright ownership.  Some portions may be licensed
>   ~ to Red Hat, Inc. under one or more contributor license agreements.
>   ~ See the AUTHORS.txt file in the distribution for a full listing of 
>   ~ individual contributors.
>   ~
>   ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
>   ~ is licensed to you under the terms of the GNU Lesser General Public License as
>   ~ published by the Free Software Foundation; either version 2.1 of
>   ~ the License, or (at your option) any later version.
>   ~
>   ~ JBoss DNA is distributed in the hope that it will be useful,
>   ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>   ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
>   ~ for more details.
>   ~
>   ~ You should have received a copy of the GNU Lesser General Public License
>   ~ along with this distribution; if not, write to:
>   ~ Free Software Foundation, Inc.
>   ~ 51 Franklin Street, Fifth Floor
>   ~ Boston, MA  02110-1301  USA
>   -->
> <configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
>     <!-- 
>     Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
>     In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
>     JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
>     -->
>     <dna:sources jcr:primaryType="nt:unstructured">
>         
>         <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource">
>             <defaultWorkspaceName>workspace2</defaultWorkspaceName>
>             <directoryForDefaultWorkspace>/tmp/</directoryForDefaultWorkspace>
>         </dna:source>
>         
>         <!-- 
>         The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
>         -->
>         <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>
>         <!-- 
>         The 'Aircraft' repository is also an in-memory source with a single default workspace.
>         By defining a default workspace, the clients using the Graph API will by default use that workspace,
>         but can easily say to use other workspaces (or create, clone, or destroy workspaces).
>         -->
>         <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
>             <!-- Define the name of the workspace used by default.  Optional, but convenient. -->
>             <defaultWorkspaceName>workspace2</defaultWorkspaceName>
>         </dna:source>
>         <!-- 
>         The 'Vehicles' repository is a federated source that owns none of its own content, but instead
>         projects (in this case) all of the content from the 'Cars' source as if it appears
>         under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
>         -->
>         <dna:source jcr:name="Vehicles">
>             <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
>             <dna:workspaces>
>                 <!-- 
>                 Unlike some other repository sources, federated sources have to define all of their workspaces,
>                 including how and where the content is projected.  So, we only need a single workspace,
>                 but we could actually define additional workspaces that expose various combinations or portions
>                 of 'Cars' and/or 'Aircraft' content.
>                 -->
>                 <dna:workspace jcr:name="virtual">
>                     <dna:projections>
>                         <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="workspace2">
>                             <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules>
>                         </dna:projection>
>                         
>                         
>                         <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
>                         <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace1">
>                             <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node. -->
>                         <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace2">
>                             <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'System' content. Only needed when this source is accessed through JCR. -->
>                         <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
>                             <dna:projectionRules>/jcr:system => /</dna:projectionRules>
>                         </dna:projection>
>                     </dna:projections>
>                 </dna:workspace>
>             </dna:workspaces>
>         </dna:source>
>         <!-- 
>         A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
>         -->
>         <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
>     </dna:sources>
>     <!-- 
>     Define the sequencers. This is an optional section. For this example, we're not using any sequencers. 
>     -->
>     <dna:sequencers>
>         <!--dna:sequencer jcr:name="Image Sequencer" dna:classname="org.jboss.dna.sequencer.image.ImageMetadataSequencer">
>             <dna:description>Image metadata sequencer</dna:description>        
>             <dna:pathExpression>/foo/source => /foo/target</dna:pathExpression>
>             <dna:pathExpression>/bar/source => /bar/target</dna:pathExpression>
>         </dna:sequencer-->
>     </dna:sequencers>
>     <!-- 
>     Define the mime type detectors. This is an optional section.  By default, each engine will use the 
>     MIME type detector that uses filename extensions.  So we wouldn't need to define the same detector again,
>     but this is how you'd define another extension.
>     -->
>     <dna:mimeTypeDetectors>
>         <dna:mimeTypeDetector jcr:name="Detector">
>             <dna:description>Standard extension-based MIME type detector</dna:description>        
>             <!-- 
>             Specify the implementation class (required), as a child element or attribute on parent element.
>             -->
>             <dna:classname>org.jboss.dna.graph.mimetype.ExtensionBasedMimeTypeDetector</dna:classname>
>             <!-- 
>             Specify the classpath (optional) as an ordered list of 'names', where each name is significant to 
>             the classpath factory.  For example, a name could be an OSGI identifier or a Maven coordinate,
>             depending upon the classpath factory being used.  If there is only one 'name' in the classpath,
>             it may be specified as an attribute on the 'mimeTypeDetector' element.  If there is more than one
>             'name', then they must be specified as child 'classpath' elements. Blank or empty values are ignored. 
>              -->
>             <dna:classpath></dna:classpath>
>             <dna:classpath></dna:classpath>
>         </dna:mimeTypeDetector>
>     </dna:mimeTypeDetectors>
>     <!-- 
>     Define the JCR repositories 
>     -->
>     <dna:repositories>
>         <!-- 
>         Define a JCR repository that accesses the 'Cars' source directly.
>         This of course is optional, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Cars">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Cars</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA -->
>             <namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>             </namespaces>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Aircraft' source directly.
>         This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Aircraft">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Aircraft</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Vehicles' federated source directly,
>         which is defined in the sources to be a projection of the 'Cars' and 'Vehicles' content.
>         -->
>         <!-- Define a JCR repository that accesses the 'Vehicles' federated source directly -->
>         <dna:repository jcr:name="Vehicles">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Vehicles</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <projectNodeTypes jcr:primaryType="dna:option" dna:value="false"/>
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR, DNA or by imported content. -->
>             <dna:namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>                 <air jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/aircraft/1.0"/>
>             </dna:namespaces>
>         </dna:repository>
>     </dna:repositories>
> </configuration>
> -- test case --
> package org.jboss.example.dna.repository;
> import static org.hamcrest.core.Is.is;
> import static org.hamcrest.core.IsNull.notNullValue;
> import static org.junit.Assert.assertThat;
> import java.net.URL;
> import org.jboss.dna.graph.Graph;
> import org.jboss.dna.jcr.JcrConfiguration;
> import org.jboss.dna.jcr.JcrEngine;
> import org.junit.Test;
> public class FileSystemConnectorUnderFederatedSourceTest {
> 	@Test
> 	public void shouldHaveProjectionOfFileSystemSourceInsideFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepositoryWithFileSystemConnector.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		assertThat(vehiclesGraph.getNodeAt("/FileSystem"), is(notNullValue()));
> 	}
> }

-- 
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 Jun 17 10:00:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 10:00:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-461) new item in source
 doesn't appear in federated source projection
In-Reply-To: <27089832.1245095216332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10130465.1245247256315.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-461:
-----------------------------------

The example uses the following configuration for the "virtual" workspace in the "Vehicles" repository source:
                    <dna:projections>
                        <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace1">
                            <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
                        </dna:projection>
                        <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace2">
                            <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
                        </dna:projection>
                        <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
                            <dna:projectionRules>/jcr:system => /</dna:projectionRules>
                        </dna:projection>
                    </dna:projections>

Note that the "/Cars" node from the "Cars" repository is being projected, so any sibling of "/Cars" will not be.  (I admit there are too many "Cars" words, making it hard to tell a node from a repository source from a repository.

Try creating a "/Cars/Honda" node in the "Cars" repository, and then see if there is a "/Vehicles/Cars/Honda" node.

> new item in source doesn't appear in federated source projection 
> -----------------------------------------------------------------
>
>                 Key: DNA-461
>                 URL: https://jira.jboss.org/jira/browse/DNA-461
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Examples, Federation
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5.7 with JVM 1.6 and maven 2.1
>            Reporter: Luiz Fernando Teston
>
> I'm not sure if it is a bug or an error in my configuration or environment. I just follow the examples without getting the CNDs and also without importing the example data. When I create some new item using the graph api this item is created in a correct way on the repository source that I'm using (example: cars) but it doesn't appears on the projection on federated source (example: vehicles/cars). I created this test case that should be used on doc/examples/repository project. I also did this same test using the JAAS configuration. 
> package org.jboss.example.dna.repository;
> import static org.hamcrest.core.Is.is;
> import static org.hamcrest.core.IsNull.notNullValue;
> import static org.junit.Assert.assertThat;
> import java.net.URL;
> import org.jboss.dna.graph.Graph;
> import org.jboss.dna.jcr.JcrConfiguration;
> import org.jboss.dna.jcr.JcrEngine;
> import org.junit.Test;
> public class FederationOnDifferentSourcesTest {
> 	@Test
> 	public void shouldHaveProjectionInsideFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		
> 		assertThat(vehiclesGraph.getNodeAt("/Cars"), is(notNullValue()));
> 	}
> 	@Test
> 	public void shouldCreateItemOnSourceRepositoryAndShowTheSameItemOnFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph carsGraph = engine.getGraph("Cars");
> 		
> 		carsGraph.create("/Honda");
> 		assertThat(carsGraph.getNodeAt("/Honda"), is(notNullValue()));
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		assertThat(vehiclesGraph.getNodeAt("/Cars/Honda"), is(notNullValue()));
> 	}
> }

-- 
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 Jun 17 10:15:56 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Wed, 17 Jun 2009 10:15:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-461) new item in source
 doesn't appear in federated source projection
In-Reply-To: <27089832.1245095216332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26566241.1245248156785.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Luiz Fernando Teston commented on DNA-461:
------------------------------------------

I did that also and it didn't work. I did that changes:

		Graph carsGraph = engine.getGraph("Cars");
		
		carsGraph.create("/Cars"); // if I don't create this node I got an exception on next line saying that could not find Cars path.
		carsGraph.create("/Cars/Honda");

		assertThat(carsGraph.getNodeAt("/Cars/Honda"), is(notNullValue()));

		Graph vehiclesGraph = engine.getGraph("Vehicles");

		assertThat(vehiclesGraph.getNodeAt("/Vehicles/Cars/Honda"), is(notNullValue()));

On the last line I got an exception saying that this path could not be found. I also did this test with "/Cars/Honda" on assertion line.

> new item in source doesn't appear in federated source projection 
> -----------------------------------------------------------------
>
>                 Key: DNA-461
>                 URL: https://jira.jboss.org/jira/browse/DNA-461
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Examples, Federation
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5.7 with JVM 1.6 and maven 2.1
>            Reporter: Luiz Fernando Teston
>
> I'm not sure if it is a bug or an error in my configuration or environment. I just follow the examples without getting the CNDs and also without importing the example data. When I create some new item using the graph api this item is created in a correct way on the repository source that I'm using (example: cars) but it doesn't appears on the projection on federated source (example: vehicles/cars). I created this test case that should be used on doc/examples/repository project. I also did this same test using the JAAS configuration. 
> package org.jboss.example.dna.repository;
> import static org.hamcrest.core.Is.is;
> import static org.hamcrest.core.IsNull.notNullValue;
> import static org.junit.Assert.assertThat;
> import java.net.URL;
> import org.jboss.dna.graph.Graph;
> import org.jboss.dna.jcr.JcrConfiguration;
> import org.jboss.dna.jcr.JcrEngine;
> import org.junit.Test;
> public class FederationOnDifferentSourcesTest {
> 	@Test
> 	public void shouldHaveProjectionInsideFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		
> 		assertThat(vehiclesGraph.getNodeAt("/Cars"), is(notNullValue()));
> 	}
> 	@Test
> 	public void shouldCreateItemOnSourceRepositoryAndShowTheSameItemOnFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph carsGraph = engine.getGraph("Cars");
> 		
> 		carsGraph.create("/Honda");
> 		assertThat(carsGraph.getNodeAt("/Honda"), is(notNullValue()));
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		assertThat(vehiclesGraph.getNodeAt("/Cars/Honda"), is(notNullValue()));
> 	}
> }

-- 
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 Jun 17 10:23:56 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Wed, 17 Jun 2009 10:23:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-461) new item in source
 doesn't appear in federated source projection
In-Reply-To: <27089832.1245095216332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21659087.1245248636323.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Luiz Fernando Teston commented on DNA-461:
------------------------------------------

I did the same test on the last comment using the correct configuration file and it works ok! The line that creates the Cars node is mandatory. But this solved my problem!

> new item in source doesn't appear in federated source projection 
> -----------------------------------------------------------------
>
>                 Key: DNA-461
>                 URL: https://jira.jboss.org/jira/browse/DNA-461
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Examples, Federation
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5.7 with JVM 1.6 and maven 2.1
>            Reporter: Luiz Fernando Teston
>
> I'm not sure if it is a bug or an error in my configuration or environment. I just follow the examples without getting the CNDs and also without importing the example data. When I create some new item using the graph api this item is created in a correct way on the repository source that I'm using (example: cars) but it doesn't appears on the projection on federated source (example: vehicles/cars). I created this test case that should be used on doc/examples/repository project. I also did this same test using the JAAS configuration. 
> package org.jboss.example.dna.repository;
> import static org.hamcrest.core.Is.is;
> import static org.hamcrest.core.IsNull.notNullValue;
> import static org.junit.Assert.assertThat;
> import java.net.URL;
> import org.jboss.dna.graph.Graph;
> import org.jboss.dna.jcr.JcrConfiguration;
> import org.jboss.dna.jcr.JcrEngine;
> import org.junit.Test;
> public class FederationOnDifferentSourcesTest {
> 	@Test
> 	public void shouldHaveProjectionInsideFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		
> 		assertThat(vehiclesGraph.getNodeAt("/Cars"), is(notNullValue()));
> 	}
> 	@Test
> 	public void shouldCreateItemOnSourceRepositoryAndShowTheSameItemOnFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph carsGraph = engine.getGraph("Cars");
> 		
> 		carsGraph.create("/Honda");
> 		assertThat(carsGraph.getNodeAt("/Honda"), is(notNullValue()));
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		assertThat(vehiclesGraph.getNodeAt("/Cars/Honda"), is(notNullValue()));
> 	}
> }

-- 
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 Jun 17 11:36:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 11:36:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-461) new item in source
 doesn't appear in federated source projection
In-Reply-To: <27089832.1245095216332.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4848599.1245253016469.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-461.
-------------------------------

    Fix Version/s: 0.6
       Resolution: Rejected


BTW, the reason the "/Cars" node needed to be created first was because you're not importing any content into the "Cars" repository.  This import process created the "/Cars" node and everything below it.

I'm marking this defect as 'Rejected', since it was resolved by proper configuration.

> new item in source doesn't appear in federated source projection 
> -----------------------------------------------------------------
>
>                 Key: DNA-461
>                 URL: https://jira.jboss.org/jira/browse/DNA-461
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Examples, Federation
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5.7 with JVM 1.6 and maven 2.1
>            Reporter: Luiz Fernando Teston
>             Fix For: 0.6
>
>
> I'm not sure if it is a bug or an error in my configuration or environment. I just follow the examples without getting the CNDs and also without importing the example data. When I create some new item using the graph api this item is created in a correct way on the repository source that I'm using (example: cars) but it doesn't appears on the projection on federated source (example: vehicles/cars). I created this test case that should be used on doc/examples/repository project. I also did this same test using the JAAS configuration. 
> package org.jboss.example.dna.repository;
> import static org.hamcrest.core.Is.is;
> import static org.hamcrest.core.IsNull.notNullValue;
> import static org.junit.Assert.assertThat;
> import java.net.URL;
> import org.jboss.dna.graph.Graph;
> import org.jboss.dna.jcr.JcrConfiguration;
> import org.jboss.dna.jcr.JcrEngine;
> import org.junit.Test;
> public class FederationOnDifferentSourcesTest {
> 	@Test
> 	public void shouldHaveProjectionInsideFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		
> 		assertThat(vehiclesGraph.getNodeAt("/Cars"), is(notNullValue()));
> 	}
> 	@Test
> 	public void shouldCreateItemOnSourceRepositoryAndShowTheSameItemOnFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepository.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph carsGraph = engine.getGraph("Cars");
> 		
> 		carsGraph.create("/Honda");
> 		assertThat(carsGraph.getNodeAt("/Honda"), is(notNullValue()));
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		assertThat(vehiclesGraph.getNodeAt("/Cars/Honda"), is(notNullValue()));
> 	}
> }

-- 
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 Jun 17 12:16:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 12:16:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-463) Federation connector
 incorrectly expects identification properties on all source nodes
Message-ID: <9632703.1245255416346.JavaMail.jira@cloud.prod.atl2.jboss.com>

Federation connector incorrectly expects identification properties on all source nodes
--------------------------------------------------------------------------------------

                 Key: DNA-463
                 URL: https://jira.jboss.org/jira/browse/DNA-463
             Project: DNA
          Issue Type: Bug
    Affects Versions: 0.5
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Blocker
             Fix For: 0.6


The JoinProcessor always expects identification properties on all nodes coming from sources.  Since some connectors do not have identification properties, this causes a NullPointerException when accumulating the identification properties:

java.lang.NullPointerException
	at org.jboss.dna.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:272)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:235)
	at org.jboss.dna.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:164)
	at org.jboss.dna.graph.connector.federation.FederatedRepositoryConnection.execute(FederatedRepositoryConnection.java:220)
	at org.jboss.dna.graph.connector.RepositoryConnectionPool$ConnectionWrapper.execute(RepositoryConnectionPool.java:991)
	at org.jboss.dna.graph.Graph.execute(Graph.java:243)
	at org.jboss.dna.graph.Graph$5.process(Graph.java:186)
	at org.jboss.dna.graph.request.RequestBuilder.readNode(RequestBuilder.java:139)
	at org.jboss.dna.graph.Graph.getNodeAt(Graph.java:1843)
	at org.jboss.dna.graph.Graph.getNodeAt(Graph.java:1853)

The problem is this snippet:

        // Accumulate the identification properties ...
        for (Property propertyInSource : readFromSource.getActualLocationOfNode().getIdProperties()) {
            ...
        }

since the JavaDoc for getIdProperties() says that it should return null if there are no properties.  This code should be wrapped with a check to see if the Location has identification properties.

-- 
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 Jun 17 12:40:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 12:40:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-462) filesystem source
 doesn't appear on federate source projection
In-Reply-To: <2012096.1245096416313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26683465.1245256856432.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-462:
-----------------------------------

There appears to be several issues.

The first two issues are in the configuration, the "FileSystem" repository source has an extra "defaultWorkspaceName" property that is not required and is actually not used.  This doesn't cause a problem, but having it does make the second problem more difficult to spot.  So, if we remove this unnecessary property, remove the trailing '/' from the workspace name (for clarity), and make sure we don't create additional workspaces, the repository source definition becomes:

        <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource"> 
            <creatingWorkspacesAllowed>false</creatingWorkspacesAllowed> 
            <directoryForDefaultWorkspace>/tmp</directoryForDefaultWorkspace> 
        </dna:source> 

then the "TempFiles projection" can use the same projection rule but should use the "/tmp" as the workspace name:

        <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="/tmp"> 
            <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules> 
        </dna:projection> 

This is because the file system connector uses the path of the directory being exposed in a workspace as the workspace name.

Once the configuration has been corrected, the final issue is actually due to a bug in the federation connector, which appears as an NPE and has been logged as DNA-463.  Unfortunately there is no workaround.

> filesystem source doesn't appear on federate source projection
> --------------------------------------------------------------
>
>                 Key: DNA-462
>                 URL: https://jira.jboss.org/jira/browse/DNA-462
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5.7 with JVM 1.6 and Maven 2.1
>            Reporter: Luiz Fernando Teston
>
> When I create a filesystem source I can access its contents using the graph api. But the same content doesn't appear on a federated source with the filesystem source on a projection path. I used the same logic on the docs/examples/repository project configuration, just adding the /tmp to a filesystem source. I've tested the same scenario using the JAAS configuration. The test case and configuration file is here:
> -- configuration file: configRepositoryWithFileSystemConnector.xml --
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- 
>   ~ JBoss DNA (http://www.jboss.org/dna)
>   ~
>   ~ See the COPYRIGHT.txt file distributed with this work for information
>   ~ regarding copyright ownership.  Some portions may be licensed
>   ~ to Red Hat, Inc. under one or more contributor license agreements.
>   ~ See the AUTHORS.txt file in the distribution for a full listing of 
>   ~ individual contributors.
>   ~
>   ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
>   ~ is licensed to you under the terms of the GNU Lesser General Public License as
>   ~ published by the Free Software Foundation; either version 2.1 of
>   ~ the License, or (at your option) any later version.
>   ~
>   ~ JBoss DNA is distributed in the hope that it will be useful,
>   ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>   ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
>   ~ for more details.
>   ~
>   ~ You should have received a copy of the GNU Lesser General Public License
>   ~ along with this distribution; if not, write to:
>   ~ Free Software Foundation, Inc.
>   ~ 51 Franklin Street, Fifth Floor
>   ~ Boston, MA  02110-1301  USA
>   -->
> <configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
>     <!-- 
>     Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
>     In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
>     JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
>     -->
>     <dna:sources jcr:primaryType="nt:unstructured">
>         
>         <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource">
>             <defaultWorkspaceName>workspace2</defaultWorkspaceName>
>             <directoryForDefaultWorkspace>/tmp/</directoryForDefaultWorkspace>
>         </dna:source>
>         
>         <!-- 
>         The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
>         -->
>         <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>
>         <!-- 
>         The 'Aircraft' repository is also an in-memory source with a single default workspace.
>         By defining a default workspace, the clients using the Graph API will by default use that workspace,
>         but can easily say to use other workspaces (or create, clone, or destroy workspaces).
>         -->
>         <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
>             <!-- Define the name of the workspace used by default.  Optional, but convenient. -->
>             <defaultWorkspaceName>workspace2</defaultWorkspaceName>
>         </dna:source>
>         <!-- 
>         The 'Vehicles' repository is a federated source that owns none of its own content, but instead
>         projects (in this case) all of the content from the 'Cars' source as if it appears
>         under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
>         -->
>         <dna:source jcr:name="Vehicles">
>             <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
>             <dna:workspaces>
>                 <!-- 
>                 Unlike some other repository sources, federated sources have to define all of their workspaces,
>                 including how and where the content is projected.  So, we only need a single workspace,
>                 but we could actually define additional workspaces that expose various combinations or portions
>                 of 'Cars' and/or 'Aircraft' content.
>                 -->
>                 <dna:workspace jcr:name="virtual">
>                     <dna:projections>
>                         <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="workspace2">
>                             <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules>
>                         </dna:projection>
>                         
>                         
>                         <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
>                         <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace1">
>                             <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node. -->
>                         <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace2">
>                             <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'System' content. Only needed when this source is accessed through JCR. -->
>                         <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
>                             <dna:projectionRules>/jcr:system => /</dna:projectionRules>
>                         </dna:projection>
>                     </dna:projections>
>                 </dna:workspace>
>             </dna:workspaces>
>         </dna:source>
>         <!-- 
>         A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
>         -->
>         <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
>     </dna:sources>
>     <!-- 
>     Define the sequencers. This is an optional section. For this example, we're not using any sequencers. 
>     -->
>     <dna:sequencers>
>         <!--dna:sequencer jcr:name="Image Sequencer" dna:classname="org.jboss.dna.sequencer.image.ImageMetadataSequencer">
>             <dna:description>Image metadata sequencer</dna:description>        
>             <dna:pathExpression>/foo/source => /foo/target</dna:pathExpression>
>             <dna:pathExpression>/bar/source => /bar/target</dna:pathExpression>
>         </dna:sequencer-->
>     </dna:sequencers>
>     <!-- 
>     Define the mime type detectors. This is an optional section.  By default, each engine will use the 
>     MIME type detector that uses filename extensions.  So we wouldn't need to define the same detector again,
>     but this is how you'd define another extension.
>     -->
>     <dna:mimeTypeDetectors>
>         <dna:mimeTypeDetector jcr:name="Detector">
>             <dna:description>Standard extension-based MIME type detector</dna:description>        
>             <!-- 
>             Specify the implementation class (required), as a child element or attribute on parent element.
>             -->
>             <dna:classname>org.jboss.dna.graph.mimetype.ExtensionBasedMimeTypeDetector</dna:classname>
>             <!-- 
>             Specify the classpath (optional) as an ordered list of 'names', where each name is significant to 
>             the classpath factory.  For example, a name could be an OSGI identifier or a Maven coordinate,
>             depending upon the classpath factory being used.  If there is only one 'name' in the classpath,
>             it may be specified as an attribute on the 'mimeTypeDetector' element.  If there is more than one
>             'name', then they must be specified as child 'classpath' elements. Blank or empty values are ignored. 
>              -->
>             <dna:classpath></dna:classpath>
>             <dna:classpath></dna:classpath>
>         </dna:mimeTypeDetector>
>     </dna:mimeTypeDetectors>
>     <!-- 
>     Define the JCR repositories 
>     -->
>     <dna:repositories>
>         <!-- 
>         Define a JCR repository that accesses the 'Cars' source directly.
>         This of course is optional, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Cars">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Cars</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA -->
>             <namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>             </namespaces>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Aircraft' source directly.
>         This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Aircraft">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Aircraft</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Vehicles' federated source directly,
>         which is defined in the sources to be a projection of the 'Cars' and 'Vehicles' content.
>         -->
>         <!-- Define a JCR repository that accesses the 'Vehicles' federated source directly -->
>         <dna:repository jcr:name="Vehicles">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Vehicles</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <projectNodeTypes jcr:primaryType="dna:option" dna:value="false"/>
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR, DNA or by imported content. -->
>             <dna:namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>                 <air jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/aircraft/1.0"/>
>             </dna:namespaces>
>         </dna:repository>
>     </dna:repositories>
> </configuration>
> -- test case --
> package org.jboss.example.dna.repository;
> import static org.hamcrest.core.Is.is;
> import static org.hamcrest.core.IsNull.notNullValue;
> import static org.junit.Assert.assertThat;
> import java.net.URL;
> import org.jboss.dna.graph.Graph;
> import org.jboss.dna.jcr.JcrConfiguration;
> import org.jboss.dna.jcr.JcrEngine;
> import org.junit.Test;
> public class FileSystemConnectorUnderFederatedSourceTest {
> 	@Test
> 	public void shouldHaveProjectionOfFileSystemSourceInsideFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepositoryWithFileSystemConnector.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		assertThat(vehiclesGraph.getNodeAt("/FileSystem"), is(notNullValue()));
> 	}
> }

-- 
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 Jun 17 12:50:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 12:50:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-464) Add use of file system
 connector to repositories example
Message-ID: <15709139.1245257456331.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add use of file system connector to repositories example
--------------------------------------------------------

                 Key: DNA-464
                 URL: https://jira.jboss.org/jira/browse/DNA-464
             Project: DNA
          Issue Type: Task
          Components: Documentation, Examples, Federation
    Affects Versions: 0.5
            Reporter: Randall Hauch
             Fix For: 0.6


See DNA-462 for an issue raised by feu trying to use the file system connector in a federated repository.  The repositories example of the Getting Started document should show how to do 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 Jun 17 12:50:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 12:50:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-463) Federation connector
 incorrectly expects identification properties on all source nodes
In-Reply-To: <9632703.1245255416346.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11543349.1245257456375.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-463:
------------------------------

    Component/s: Connectors
                 Federation


> Federation connector incorrectly expects identification properties on all source nodes
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-463
>                 URL: https://jira.jboss.org/jira/browse/DNA-463
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Federation
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JoinProcessor always expects identification properties on all nodes coming from sources.  Since some connectors do not have identification properties, this causes a NullPointerException when accumulating the identification properties:
> java.lang.NullPointerException
> 	at org.jboss.dna.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:272)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:235)
> 	at org.jboss.dna.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:164)
> 	at org.jboss.dna.graph.connector.federation.FederatedRepositoryConnection.execute(FederatedRepositoryConnection.java:220)
> 	at org.jboss.dna.graph.connector.RepositoryConnectionPool$ConnectionWrapper.execute(RepositoryConnectionPool.java:991)
> 	at org.jboss.dna.graph.Graph.execute(Graph.java:243)
> 	at org.jboss.dna.graph.Graph$5.process(Graph.java:186)
> 	at org.jboss.dna.graph.request.RequestBuilder.readNode(RequestBuilder.java:139)
> 	at org.jboss.dna.graph.Graph.getNodeAt(Graph.java:1843)
> 	at org.jboss.dna.graph.Graph.getNodeAt(Graph.java:1853)
> The problem is this snippet:
>         // Accumulate the identification properties ...
>         for (Property propertyInSource : readFromSource.getActualLocationOfNode().getIdProperties()) {
>             ...
>         }
> since the JavaDoc for getIdProperties() says that it should return null if there are no properties.  This code should be wrapped with a check to see if the Location has identification properties.

-- 
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 Jun 17 13:21:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 13:21:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-463) Federation connector
 incorrectly expects identification properties on all source nodes
In-Reply-To: <9632703.1245255416346.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18707797.1245259316326.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-463:
-----------------------------------

Corrected the for loop that is aggregating the identifier properties on source node locations.  If the location does not even have identifier properties, then this aggregation process is not even performed.

Also added toString() implementations for ProjectedNode and FederatedRequest.

> Federation connector incorrectly expects identification properties on all source nodes
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-463
>                 URL: https://jira.jboss.org/jira/browse/DNA-463
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Federation
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JoinProcessor always expects identification properties on all nodes coming from sources.  Since some connectors do not have identification properties, this causes a NullPointerException when accumulating the identification properties:
> java.lang.NullPointerException
> 	at org.jboss.dna.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:272)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:235)
> 	at org.jboss.dna.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:164)
> 	at org.jboss.dna.graph.connector.federation.FederatedRepositoryConnection.execute(FederatedRepositoryConnection.java:220)
> 	at org.jboss.dna.graph.connector.RepositoryConnectionPool$ConnectionWrapper.execute(RepositoryConnectionPool.java:991)
> 	at org.jboss.dna.graph.Graph.execute(Graph.java:243)
> 	at org.jboss.dna.graph.Graph$5.process(Graph.java:186)
> 	at org.jboss.dna.graph.request.RequestBuilder.readNode(RequestBuilder.java:139)
> 	at org.jboss.dna.graph.Graph.getNodeAt(Graph.java:1843)
> 	at org.jboss.dna.graph.Graph.getNodeAt(Graph.java:1853)
> The problem is this snippet:
>         // Accumulate the identification properties ...
>         for (Property propertyInSource : readFromSource.getActualLocationOfNode().getIdProperties()) {
>             ...
>         }
> since the JavaDoc for getIdProperties() says that it should return null if there are no properties.  This code should be wrapped with a check to see if the Location has identification properties.

-- 
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 Jun 17 13:23:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 13:23:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-463) Federation connector
 incorrectly expects identification properties on all source nodes
In-Reply-To: <9632703.1245255416346.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5420810.1245259436523.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-463.
-------------------------------

    Resolution: Done


Marking as resolved, since this fixes the issue, and it also allows DNA-462 to be resolved.

> Federation connector incorrectly expects identification properties on all source nodes
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-463
>                 URL: https://jira.jboss.org/jira/browse/DNA-463
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Federation
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JoinProcessor always expects identification properties on all nodes coming from sources.  Since some connectors do not have identification properties, this causes a NullPointerException when accumulating the identification properties:
> java.lang.NullPointerException
> 	at org.jboss.dna.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:272)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:235)
> 	at org.jboss.dna.graph.connector.federation.JoinRequestProcessor.process(JoinRequestProcessor.java:164)
> 	at org.jboss.dna.graph.connector.federation.FederatedRepositoryConnection.execute(FederatedRepositoryConnection.java:220)
> 	at org.jboss.dna.graph.connector.RepositoryConnectionPool$ConnectionWrapper.execute(RepositoryConnectionPool.java:991)
> 	at org.jboss.dna.graph.Graph.execute(Graph.java:243)
> 	at org.jboss.dna.graph.Graph$5.process(Graph.java:186)
> 	at org.jboss.dna.graph.request.RequestBuilder.readNode(RequestBuilder.java:139)
> 	at org.jboss.dna.graph.Graph.getNodeAt(Graph.java:1843)
> 	at org.jboss.dna.graph.Graph.getNodeAt(Graph.java:1853)
> The problem is this snippet:
>         // Accumulate the identification properties ...
>         for (Property propertyInSource : readFromSource.getActualLocationOfNode().getIdProperties()) {
>             ...
>         }
> since the JavaDoc for getIdProperties() says that it should return null if there are no properties.  This code should be wrapped with a check to see if the Location has identification properties.

-- 
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 Jun 17 14:48:56 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Wed, 17 Jun 2009 14:48:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-465) NullPointerException
 occurs when
 reading a FileSystemSource repository through JCR using FederatedSource
Message-ID: <10094966.1245264536772.JavaMail.jira@cloud.prod.atl2.jboss.com>

NullPointerException occurs when reading a FileSystemSource repository through JCR using FederatedSource
--------------------------------------------------------------------------------------------------------

                 Key: DNA-465
                 URL: https://jira.jboss.org/jira/browse/DNA-465
             Project: DNA
          Issue Type: Bug
          Components: Connectors, Federation, JCR
    Affects Versions: 0.5
         Environment: Mac OS 10.5 with java 1.6 and maven 2.1
            Reporter: Luiz Fernando Teston


When reading a node from a federated filesystem connector using the JCR API it throws a NullPointerException. This node represents a file and it could be read normally by the graph api.

-- test method to be used inside the docs/gettingstarted/repository source --

	@Test
	public void shouldAccessFileSystemByFederatedJcr()
			throws Exception {
		JcrConfiguration configuration = new JcrConfiguration();
		URL url = Thread
				.currentThread()
				.getContextClassLoader()
				.getResource(
						"config/repository-federated-with-filesystem-connector-config.xml");
		assertNotNull(url);
		configuration.loadFrom(url);

		JcrEngine engine = configuration.build();

		engine.start();
		
		org.jboss.dna.graph.Node nodeFromGraph = engine.getGraph("Vehicles").getNodeAt("/Vehicles/FileSystem/FileThatExists");
		
		assertThat(nodeFromGraph, is(notNullValue()));
		
		Session session = engine.getRepository("Vehicles").login();
		
		Node nodeFromJcr = session.getRootNode().getNode("Vehicles/FileSystem/FileThatExists"); // here I got a NPE
		
		assertThat(nodeFromJcr, is(notNullValue()));
		
		engine.shutdown();
	}

-- configuration file to be used on this test --


<?xml version="1.0" encoding="UTF-8"?>
<!-- 
  ~ JBoss DNA (http://www.jboss.org/dna)
  ~
  ~ See the COPYRIGHT.txt file distributed with this work for information
  ~ regarding copyright ownership.  Some portions may be licensed
  ~ to Red Hat, Inc. under one or more contributor license agreements.
  ~ See the AUTHORS.txt file in the distribution for a full listing of 
  ~ individual contributors.
  ~
  ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
  ~ is licensed to you under the terms of the GNU Lesser General Public License as
  ~ published by the Free Software Foundation; either version 2.1 of
  ~ the License, or (at your option) any later version.
  ~
  ~ JBoss DNA is distributed in the hope that it will be useful,
  ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
  ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
  ~ for more details.
  ~
  ~ You should have received a copy of the GNU Lesser General Public License
  ~ along with this distribution; if not, write to:
  ~ Free Software Foundation, Inc.
  ~ 51 Franklin Street, Fifth Floor
  ~ Boston, MA  02110-1301  USA
  -->
<configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
    <!-- 
    Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
    In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
    JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
    -->
    <dna:sources jcr:primaryType="nt:unstructured">
        <!-- 
        The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
        -->
        <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>

        <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource"> 
            <creatingWorkspacesAllowed>false</creatingWorkspacesAllowed> 
            <directoryForDefaultWorkspace>/tmp</directoryForDefaultWorkspace> 
        </dna:source> 
        <!-- 
        The 'Aircraft' repository is also an in-memory source with a single default workspace.
        By defining a default workspace, the clients using the Graph API will by default use that workspace,
        but can easily say to use other workspaces (or create, clone, or destroy workspaces).
        -->
        <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
            <!-- Define the name of the workspace used by default.  Optional, but convenient.
-->
            <defaultWorkspaceName>workspace</defaultWorkspaceName>
        </dna:source>
        <!-- 
        The 'Vehicles' repository is a federated source that owns none of its own content, but instead
        projects (in this case) all of the content from the 'Cars' source as if it appears
        under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
        -->
        <dna:source jcr:name="Vehicles">
            <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
            <dna:workspaces>
                <!-- 
                Unlike some other repository sources, federated sources have to define all of their workspaces,
                including how and where the content is projected.  So, we only need a single workspace,
                but we could actually define additional workspaces that expose various combinations or portions
                of 'Cars' and/or 'Aircraft' content.
                -->
                <dna:workspace jcr:name="workspace">
                    <dna:projections>
                        <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
                        <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace">
                            <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
                        </dna:projection>
				        <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="/tmp"> 
				            <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules> 
				        </dna:projection> 
                        <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node.
-->
                        <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace">
                            <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
                        </dna:projection>
                        <!-- Project the 'System' content. Only needed when this source is accessed through JCR.
-->
                        <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
                            <dna:projectionRules>/jcr:system => /</dna:projectionRules>
                        </dna:projection>
                    </dna:projections>
                </dna:workspace>
            </dna:workspaces>
            
            <retryLimit>20</retryLimit>
            
        </dna:source>
        <!-- 
        A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
        -->
        <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
    </dna:sources>
  
    <!-- 
    Define the JCR repositories 
    -->
    <dna:repositories>
        <!-- 
        Define a JCR repository that accesses the 'Cars' source directly.
        This of course is optional, since we could access the same content through 'vehicles'.
        -->
        <dna:repository jcr:name="Cars">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Cars</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names
-->
            <dna:options jcr:primaryType="dna:options">
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
            <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here.
-->
            <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
            <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA
-->
            <namespaces jcr:primaryType="dna:namespaces">
                <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
            </namespaces>
        </dna:repository>
        <!-- 
        Define a JCR repository that accesses the 'Aircraft' source directly.
        This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
        -->
        <dna:repository jcr:name="Aircraft">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Aircraft</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names
-->
            <dna:options jcr:primaryType="dna:options">
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
        </dna:repository>
        <dna:repository jcr:name="Vehicles">
            <!-- Specify the source that should be used for the repository -->
            <dna:source>Vehicles</dna:source>
            <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names
-->
            <dna:options jcr:primaryType="dna:options">
                <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
            </dna:options>
        </dna:repository>
        
    </dna:repositories>
</configuration>

--- exception thrown by this test method ---

java.lang.NullPointerException
	at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:173)
	at com.google.common.collect.ReferenceMap$ReferenceStrategy$1.getDummyFor(ReferenceMap.java:475)
	at com.google.common.collect.ReferenceMap.get(ReferenceMap.java:168)
	at org.jboss.dna.jcr.SessionCache.findJcrNode(SessionCache.java:817)
	at org.jboss.dna.jcr.SessionCache.findJcrItem(SessionCache.java:941)
	at org.jboss.dna.jcr.AbstractJcrNode.getNode(AbstractJcrNode.java:542)
	at org.openspotligth.federation.configuration.DNAConfigFromFileTest.shouldAccessFileSystemByFederatedJcr(DNAConfigFromFileTest.java:116)
	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:585)
	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  Wed Jun 17 15:07:56 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Wed, 17 Jun 2009 15:07:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-462) filesystem source
 doesn't appear on federate source projection
In-Reply-To: <2012096.1245096416313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32250046.1245265676319.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Luiz Fernando Teston commented on DNA-462:
------------------------------------------

I updated my sources after the issue #463 resolution. After that my test described on this issue started to work.

> filesystem source doesn't appear on federate source projection
> --------------------------------------------------------------
>
>                 Key: DNA-462
>                 URL: https://jira.jboss.org/jira/browse/DNA-462
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5.7 with JVM 1.6 and Maven 2.1
>            Reporter: Luiz Fernando Teston
>
> When I create a filesystem source I can access its contents using the graph api. But the same content doesn't appear on a federated source with the filesystem source on a projection path. I used the same logic on the docs/examples/repository project configuration, just adding the /tmp to a filesystem source. I've tested the same scenario using the JAAS configuration. The test case and configuration file is here:
> -- configuration file: configRepositoryWithFileSystemConnector.xml --
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- 
>   ~ JBoss DNA (http://www.jboss.org/dna)
>   ~
>   ~ See the COPYRIGHT.txt file distributed with this work for information
>   ~ regarding copyright ownership.  Some portions may be licensed
>   ~ to Red Hat, Inc. under one or more contributor license agreements.
>   ~ See the AUTHORS.txt file in the distribution for a full listing of 
>   ~ individual contributors.
>   ~
>   ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
>   ~ is licensed to you under the terms of the GNU Lesser General Public License as
>   ~ published by the Free Software Foundation; either version 2.1 of
>   ~ the License, or (at your option) any later version.
>   ~
>   ~ JBoss DNA is distributed in the hope that it will be useful,
>   ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>   ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
>   ~ for more details.
>   ~
>   ~ You should have received a copy of the GNU Lesser General Public License
>   ~ along with this distribution; if not, write to:
>   ~ Free Software Foundation, Inc.
>   ~ 51 Franklin Street, Fifth Floor
>   ~ Boston, MA  02110-1301  USA
>   -->
> <configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
>     <!-- 
>     Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
>     In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
>     JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
>     -->
>     <dna:sources jcr:primaryType="nt:unstructured">
>         
>         <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource">
>             <defaultWorkspaceName>workspace2</defaultWorkspaceName>
>             <directoryForDefaultWorkspace>/tmp/</directoryForDefaultWorkspace>
>         </dna:source>
>         
>         <!-- 
>         The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
>         -->
>         <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>
>         <!-- 
>         The 'Aircraft' repository is also an in-memory source with a single default workspace.
>         By defining a default workspace, the clients using the Graph API will by default use that workspace,
>         but can easily say to use other workspaces (or create, clone, or destroy workspaces).
>         -->
>         <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
>             <!-- Define the name of the workspace used by default.  Optional, but convenient. -->
>             <defaultWorkspaceName>workspace2</defaultWorkspaceName>
>         </dna:source>
>         <!-- 
>         The 'Vehicles' repository is a federated source that owns none of its own content, but instead
>         projects (in this case) all of the content from the 'Cars' source as if it appears
>         under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
>         -->
>         <dna:source jcr:name="Vehicles">
>             <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
>             <dna:workspaces>
>                 <!-- 
>                 Unlike some other repository sources, federated sources have to define all of their workspaces,
>                 including how and where the content is projected.  So, we only need a single workspace,
>                 but we could actually define additional workspaces that expose various combinations or portions
>                 of 'Cars' and/or 'Aircraft' content.
>                 -->
>                 <dna:workspace jcr:name="virtual">
>                     <dna:projections>
>                         <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="workspace2">
>                             <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules>
>                         </dna:projection>
>                         
>                         
>                         <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
>                         <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace1">
>                             <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node. -->
>                         <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace2">
>                             <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'System' content. Only needed when this source is accessed through JCR. -->
>                         <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
>                             <dna:projectionRules>/jcr:system => /</dna:projectionRules>
>                         </dna:projection>
>                     </dna:projections>
>                 </dna:workspace>
>             </dna:workspaces>
>         </dna:source>
>         <!-- 
>         A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
>         -->
>         <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
>     </dna:sources>
>     <!-- 
>     Define the sequencers. This is an optional section. For this example, we're not using any sequencers. 
>     -->
>     <dna:sequencers>
>         <!--dna:sequencer jcr:name="Image Sequencer" dna:classname="org.jboss.dna.sequencer.image.ImageMetadataSequencer">
>             <dna:description>Image metadata sequencer</dna:description>        
>             <dna:pathExpression>/foo/source => /foo/target</dna:pathExpression>
>             <dna:pathExpression>/bar/source => /bar/target</dna:pathExpression>
>         </dna:sequencer-->
>     </dna:sequencers>
>     <!-- 
>     Define the mime type detectors. This is an optional section.  By default, each engine will use the 
>     MIME type detector that uses filename extensions.  So we wouldn't need to define the same detector again,
>     but this is how you'd define another extension.
>     -->
>     <dna:mimeTypeDetectors>
>         <dna:mimeTypeDetector jcr:name="Detector">
>             <dna:description>Standard extension-based MIME type detector</dna:description>        
>             <!-- 
>             Specify the implementation class (required), as a child element or attribute on parent element.
>             -->
>             <dna:classname>org.jboss.dna.graph.mimetype.ExtensionBasedMimeTypeDetector</dna:classname>
>             <!-- 
>             Specify the classpath (optional) as an ordered list of 'names', where each name is significant to 
>             the classpath factory.  For example, a name could be an OSGI identifier or a Maven coordinate,
>             depending upon the classpath factory being used.  If there is only one 'name' in the classpath,
>             it may be specified as an attribute on the 'mimeTypeDetector' element.  If there is more than one
>             'name', then they must be specified as child 'classpath' elements. Blank or empty values are ignored. 
>              -->
>             <dna:classpath></dna:classpath>
>             <dna:classpath></dna:classpath>
>         </dna:mimeTypeDetector>
>     </dna:mimeTypeDetectors>
>     <!-- 
>     Define the JCR repositories 
>     -->
>     <dna:repositories>
>         <!-- 
>         Define a JCR repository that accesses the 'Cars' source directly.
>         This of course is optional, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Cars">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Cars</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA -->
>             <namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>             </namespaces>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Aircraft' source directly.
>         This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Aircraft">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Aircraft</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Vehicles' federated source directly,
>         which is defined in the sources to be a projection of the 'Cars' and 'Vehicles' content.
>         -->
>         <!-- Define a JCR repository that accesses the 'Vehicles' federated source directly -->
>         <dna:repository jcr:name="Vehicles">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Vehicles</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <projectNodeTypes jcr:primaryType="dna:option" dna:value="false"/>
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR, DNA or by imported content. -->
>             <dna:namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>                 <air jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/aircraft/1.0"/>
>             </dna:namespaces>
>         </dna:repository>
>     </dna:repositories>
> </configuration>
> -- test case --
> package org.jboss.example.dna.repository;
> import static org.hamcrest.core.Is.is;
> import static org.hamcrest.core.IsNull.notNullValue;
> import static org.junit.Assert.assertThat;
> import java.net.URL;
> import org.jboss.dna.graph.Graph;
> import org.jboss.dna.jcr.JcrConfiguration;
> import org.jboss.dna.jcr.JcrEngine;
> import org.junit.Test;
> public class FileSystemConnectorUnderFederatedSourceTest {
> 	@Test
> 	public void shouldHaveProjectionOfFileSystemSourceInsideFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepositoryWithFileSystemConnector.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		assertThat(vehiclesGraph.getNodeAt("/FileSystem"), is(notNullValue()));
> 	}
> }

-- 
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 Jun 17 16:25:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 16:25:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-462) filesystem source
 doesn't appear on federate source projection
In-Reply-To: <2012096.1245096416313.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12827459.1245270356544.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-462.
-------------------------------

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


Marking as resolved since the correction (including DNA-463) worked for Luiz.

> filesystem source doesn't appear on federate source projection
> --------------------------------------------------------------
>
>                 Key: DNA-462
>                 URL: https://jira.jboss.org/jira/browse/DNA-462
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5.7 with JVM 1.6 and Maven 2.1
>            Reporter: Luiz Fernando Teston
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>
> When I create a filesystem source I can access its contents using the graph api. But the same content doesn't appear on a federated source with the filesystem source on a projection path. I used the same logic on the docs/examples/repository project configuration, just adding the /tmp to a filesystem source. I've tested the same scenario using the JAAS configuration. The test case and configuration file is here:
> -- configuration file: configRepositoryWithFileSystemConnector.xml --
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- 
>   ~ JBoss DNA (http://www.jboss.org/dna)
>   ~
>   ~ See the COPYRIGHT.txt file distributed with this work for information
>   ~ regarding copyright ownership.  Some portions may be licensed
>   ~ to Red Hat, Inc. under one or more contributor license agreements.
>   ~ See the AUTHORS.txt file in the distribution for a full listing of 
>   ~ individual contributors.
>   ~
>   ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
>   ~ is licensed to you under the terms of the GNU Lesser General Public License as
>   ~ published by the Free Software Foundation; either version 2.1 of
>   ~ the License, or (at your option) any later version.
>   ~
>   ~ JBoss DNA is distributed in the hope that it will be useful,
>   ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>   ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
>   ~ for more details.
>   ~
>   ~ You should have received a copy of the GNU Lesser General Public License
>   ~ along with this distribution; if not, write to:
>   ~ Free Software Foundation, Inc.
>   ~ 51 Franklin Street, Fifth Floor
>   ~ Boston, MA  02110-1301  USA
>   -->
> <configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
>     <!-- 
>     Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
>     In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
>     JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
>     -->
>     <dna:sources jcr:primaryType="nt:unstructured">
>         
>         <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource">
>             <defaultWorkspaceName>workspace2</defaultWorkspaceName>
>             <directoryForDefaultWorkspace>/tmp/</directoryForDefaultWorkspace>
>         </dna:source>
>         
>         <!-- 
>         The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
>         -->
>         <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>
>         <!-- 
>         The 'Aircraft' repository is also an in-memory source with a single default workspace.
>         By defining a default workspace, the clients using the Graph API will by default use that workspace,
>         but can easily say to use other workspaces (or create, clone, or destroy workspaces).
>         -->
>         <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
>             <!-- Define the name of the workspace used by default.  Optional, but convenient. -->
>             <defaultWorkspaceName>workspace2</defaultWorkspaceName>
>         </dna:source>
>         <!-- 
>         The 'Vehicles' repository is a federated source that owns none of its own content, but instead
>         projects (in this case) all of the content from the 'Cars' source as if it appears
>         under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
>         -->
>         <dna:source jcr:name="Vehicles">
>             <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
>             <dna:workspaces>
>                 <!-- 
>                 Unlike some other repository sources, federated sources have to define all of their workspaces,
>                 including how and where the content is projected.  So, we only need a single workspace,
>                 but we could actually define additional workspaces that expose various combinations or portions
>                 of 'Cars' and/or 'Aircraft' content.
>                 -->
>                 <dna:workspace jcr:name="virtual">
>                     <dna:projections>
>                         <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="workspace2">
>                             <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules>
>                         </dna:projection>
>                         
>                         
>                         <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
>                         <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace1">
>                             <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node. -->
>                         <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace2">
>                             <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'System' content. Only needed when this source is accessed through JCR. -->
>                         <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
>                             <dna:projectionRules>/jcr:system => /</dna:projectionRules>
>                         </dna:projection>
>                     </dna:projections>
>                 </dna:workspace>
>             </dna:workspaces>
>         </dna:source>
>         <!-- 
>         A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
>         -->
>         <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
>     </dna:sources>
>     <!-- 
>     Define the sequencers. This is an optional section. For this example, we're not using any sequencers. 
>     -->
>     <dna:sequencers>
>         <!--dna:sequencer jcr:name="Image Sequencer" dna:classname="org.jboss.dna.sequencer.image.ImageMetadataSequencer">
>             <dna:description>Image metadata sequencer</dna:description>        
>             <dna:pathExpression>/foo/source => /foo/target</dna:pathExpression>
>             <dna:pathExpression>/bar/source => /bar/target</dna:pathExpression>
>         </dna:sequencer-->
>     </dna:sequencers>
>     <!-- 
>     Define the mime type detectors. This is an optional section.  By default, each engine will use the 
>     MIME type detector that uses filename extensions.  So we wouldn't need to define the same detector again,
>     but this is how you'd define another extension.
>     -->
>     <dna:mimeTypeDetectors>
>         <dna:mimeTypeDetector jcr:name="Detector">
>             <dna:description>Standard extension-based MIME type detector</dna:description>        
>             <!-- 
>             Specify the implementation class (required), as a child element or attribute on parent element.
>             -->
>             <dna:classname>org.jboss.dna.graph.mimetype.ExtensionBasedMimeTypeDetector</dna:classname>
>             <!-- 
>             Specify the classpath (optional) as an ordered list of 'names', where each name is significant to 
>             the classpath factory.  For example, a name could be an OSGI identifier or a Maven coordinate,
>             depending upon the classpath factory being used.  If there is only one 'name' in the classpath,
>             it may be specified as an attribute on the 'mimeTypeDetector' element.  If there is more than one
>             'name', then they must be specified as child 'classpath' elements. Blank or empty values are ignored. 
>              -->
>             <dna:classpath></dna:classpath>
>             <dna:classpath></dna:classpath>
>         </dna:mimeTypeDetector>
>     </dna:mimeTypeDetectors>
>     <!-- 
>     Define the JCR repositories 
>     -->
>     <dna:repositories>
>         <!-- 
>         Define a JCR repository that accesses the 'Cars' source directly.
>         This of course is optional, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Cars">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Cars</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA -->
>             <namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>             </namespaces>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Aircraft' source directly.
>         This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Aircraft">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Aircraft</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Vehicles' federated source directly,
>         which is defined in the sources to be a projection of the 'Cars' and 'Vehicles' content.
>         -->
>         <!-- Define a JCR repository that accesses the 'Vehicles' federated source directly -->
>         <dna:repository jcr:name="Vehicles">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Vehicles</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names -->
>             <dna:options jcr:primaryType="dna:options">
>                 <projectNodeTypes jcr:primaryType="dna:option" dna:value="false"/>
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here. -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR, DNA or by imported content. -->
>             <dna:namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>                 <air jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/aircraft/1.0"/>
>             </dna:namespaces>
>         </dna:repository>
>     </dna:repositories>
> </configuration>
> -- test case --
> package org.jboss.example.dna.repository;
> import static org.hamcrest.core.Is.is;
> import static org.hamcrest.core.IsNull.notNullValue;
> import static org.junit.Assert.assertThat;
> import java.net.URL;
> import org.jboss.dna.graph.Graph;
> import org.jboss.dna.jcr.JcrConfiguration;
> import org.jboss.dna.jcr.JcrEngine;
> import org.junit.Test;
> public class FileSystemConnectorUnderFederatedSourceTest {
> 	@Test
> 	public void shouldHaveProjectionOfFileSystemSourceInsideFederatedSource()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL configUrl = Thread.currentThread().getContextClassLoader()
> 				.getResource("configRepositoryWithFileSystemConnector.xml");
> 		assertThat(configUrl, is(notNullValue()));
> 		configuration.loadFrom(configUrl);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		Graph vehiclesGraph = engine.getGraph("Vehicles");
> 		assertThat(vehiclesGraph.getNodeAt("/FileSystem"), is(notNullValue()));
> 	}
> }

-- 
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 Jun 17 16:35:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 17 Jun 2009 16:35:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-466) JCR requires
 connectors to expose UUID as identifier property
Message-ID: <5618761.1245270956476.JavaMail.jira@cloud.prod.atl2.jboss.com>

JCR requires connectors to expose UUID as identifier property
-------------------------------------------------------------

                 Key: DNA-466
                 URL: https://jira.jboss.org/jira/browse/DNA-466
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.5
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Blocker
             Fix For: 0.6


The JCR implementation currently expects connectors to return a UUID as the identifier property.  This is obviously incorrect, as it goes against several of the connectors we've already implemented.  In particular, the SessionCache is expecting to find the UUID, and submits requests to the source with only the UUID (not the path).

-- 
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 Jun 18 16:55:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 18 Jun 2009 16:55:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-468) Add XPath query
	language support
Message-ID: <19863639.1245358556324.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add XPath query language support
--------------------------------

                 Key: DNA-468
                 URL: https://jira.jboss.org/jira/browse/DNA-468
             Project: DNA
          Issue Type: Feature Request
          Components: API, Graph, JCR
    Affects Versions: 0.5
            Reporter: Randall Hauch
            Assignee: Johnny Verhaeg
             Fix For: 0.6


Create an XPath language binding for our graph model, so that we can parse XPath queries and produce query models that can then be executed.

This can probably be done as a separate project dependent upon dna-graph, perhaps in the extensions folder (since it'd be a query language extension).  Maybe "extensions/dna-query-xpath"?

-- 
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 Jun 18 16:51:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 18 Jun 2009 16:51:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-467) Add search/query
 support to the graph API
Message-ID: <27219418.1245358316391.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add search/query support to the graph API
-----------------------------------------

                 Key: DNA-467
                 URL: https://jira.jboss.org/jira/browse/DNA-467
             Project: DNA
          Issue Type: Feature Request
          Components: API, Connectors, Graph
    Affects Versions: 0.5
            Reporter: Randall Hauch
            Assignee: Johnny Verhaeg
            Priority: Critical
             Fix For: 0.6


The graph system needs to be able to push a search/query down to a connector, and we need to develop a query model (in the form of concrete classes, probably immutable).  Connectors can optionally support queries, and if they do they will process the query and return the results.

Particular language bindings would be put on top of this query model.  For example, JCR 1.0 defines an XPath language.  Support for each language would parse a query in that language and produce a query model.

-- 
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 Jun 18 16:57:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 18 Jun 2009 16:57:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-467) Add search/query
 support to the graph API
In-Reply-To: <27219418.1245358316391.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21071016.1245358676323.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-467:
-----------------------------------

The classes that make up a query model could probably go in 'dna-graph' in the 'org.jboss.dna.graph.query.model' package.  The 'org.jboss.dna.graph.query' package could then have the interfaces for executing queries, and "org.jboss.dna.graph.process' could have any abstract base classes for query processor implementations (if there are any).

> Add search/query support to the graph API
> -----------------------------------------
>
>                 Key: DNA-467
>                 URL: https://jira.jboss.org/jira/browse/DNA-467
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors, Graph
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Johnny Verhaeg
>            Priority: Critical
>             Fix For: 0.6
>
>
> The graph system needs to be able to push a search/query down to a connector, and we need to develop a query model (in the form of concrete classes, probably immutable).  Connectors can optionally support queries, and if they do they will process the query and return the results.
> Particular language bindings would be put on top of this query model.  For example, JCR 1.0 defines an XPath language.  Support for each language would parse a query in that language and produce a query model.

-- 
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 Jun 19 11:19:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 19 Jun 2009 11:19:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-370) JcrWorkspace.clone Is
 Not Implemented
In-Reply-To: <1486867.1240252882274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4049234.1245424796853.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-370:
--------------------------------

    Attachment: JpaConnector_with_clone_support.patch


I have modified the CopyBranchRequest to support the concept of UUID conflict behavior in an earlier patch.  This indicates whether UUID collisions should be handled by throwing an exception, removing the existing node and replacing it with the node from the copy, or always using new UUIDs to avoid collisions entirely.  This was pretty simple to support in the InMemoryRepository, but required some pretty major work in JpaConnector, including modification of the primary key of ChildEntity.

I'm attaching the JpaConnector portion of the overall work for a review and/or sanity check.

> JcrWorkspace.clone Is Not Implemented
> -------------------------------------
>
>                 Key: DNA-370
>                 URL: https://jira.jboss.org/jira/browse/DNA-370
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: JpaConnector_with_clone_support.patch
>
>
> JcrWorkspace.clone is not yet implemented.  This may not be important/useful for 0.4.  AbstractJcrNode.getCorrespondingNodePath is also not yet 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  Fri Jun 19 15:42:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 19 Jun 2009 15:42:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-370) JcrWorkspace.clone
 Is Not Implemented
In-Reply-To: <1486867.1240252882274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17086504.1245440576515.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-370:
-----------------------------------

The changes look good to me.  Changing the PK is indeed a better way to go.  However, the following index definition in ChildEntity is no longer needed and can be removed, as it duplicates the index that all databases should create for the PK.
   @Index( name = "CHILDUUID_INX", columnNames = {"WORKSPACE_ID", "CHILD_UUID"} ),

> JcrWorkspace.clone Is Not Implemented
> -------------------------------------
>
>                 Key: DNA-370
>                 URL: https://jira.jboss.org/jira/browse/DNA-370
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: JpaConnector_with_clone_support.patch
>
>
> JcrWorkspace.clone is not yet implemented.  This may not be important/useful for 0.4.  AbstractJcrNode.getCorrespondingNodePath is also not yet 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  Fri Jun 19 16:16:00 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 19 Jun 2009 16:16:00 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-466) JCR requires
 connectors to expose UUID as identifier property
In-Reply-To: <5618761.1245270956476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2048372.1245442560219.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-466:
-----------------------------------

The reason this was done in the first place was because the path of a node can change (as it or its parents are moved).  Ensuring the cached path is difficult to do efficiently.  If the Path is stored on each node, then the paths of all nodes below any moved node becomes invalid; changing all the cached paths on all nodes in this branch could be expensive if the cached branch is large.  Different means can be used to determine whether a cached path is still valid (e.g., if ChildPath objects are used, each ChildPath instance references the Path of it's parent; walk up the ancestors and ensure the ChildPath is indeed referencing the same Path instance as it's parent), but all those I've thought of add significant complexity.  Plus, although the Paths could be stored in a Map<UUID,Path>, the NodeInfo objects are already stored in a Map<UUID,NodeInfo>, and it would be more efficient to cache the Path in the NodeInfo.  But since the Path may change, the NodeInfo could no longer be mutable.

Perhaps the simplest solution is simply a Map<UUID,Path>, and to simply clear this map every time a node is used.  Retrieving a Path for a node would involve a simple map lookup, and any returned Path could be used as is.  If the map contains no Path, then one would be computed (by walking up the ancestors, checking of course for the existence in the map of a Path for each ancestor) and added to the map.  Although any move would require recomputing all node paths from scratch, this is not really any worse than what we have now.  And in many ways, it would actually be an improvement as there appears to be frequently-occurring situations where the Path for a node is retrieved multiple times.

Before I make these changes, I would like to measure the performance of reading all the nodes in a graph and obtaining each node's path (and perhaps doing this multiple times).  This can be done in the SessionCacheTest.  After the path caching is implemented, the performance should be no worse.

> JCR requires connectors to expose UUID as identifier property
> -------------------------------------------------------------
>
>                 Key: DNA-466
>                 URL: https://jira.jboss.org/jira/browse/DNA-466
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JCR implementation currently expects connectors to return a UUID as the identifier property.  This is obviously incorrect, as it goes against several of the connectors we've already implemented.  In particular, the SessionCache is expecting to find the UUID, and submits requests to the source with only the UUID (not the path).

-- 
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 Jun 19 18:34:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 19 Jun 2009 18:34:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-466) JCR requires
 connectors to expose UUID as identifier property
In-Reply-To: <5618761.1245270956476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7213835.1245450896331.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-466:
-----------------------------------

Here are some stats for walking a graph of 42 nodes in a JCR repository, BEFORE the path cache was added.  The first line has the stats for a cold SessionCache, while the other lines are for the SessionCache warmed from the prior runs.

42 samples: min=00:00:00.000,822; avg=00:00:00.004,539; median=00:00:00.004,77; stddev=2290766.3804887054; max=00:00:00.011,695
42 samples: min=00:00:00.000,145; avg=00:00:00.002,363; median=00:00:00.002,59; stddev=1504321.345995642; max=00:00:00.010,357
42 samples: min=00:00:00.000,211; avg=00:00:00.002,437; median=00:00:00.002,599; stddev=1511336.257570337; max=00:00:00.010,526

Here are the same stats for walking a graph of 42 nodes in a JCR repository, AFTER the path cache was added.

42 samples: min=00:00:00.000,587; avg=00:00:00.001,789; median=00:00:00.001,624; stddev=1223475.6189381357; max=00:00:00.007,328
42 samples: min=00:00:00.000,078; avg=00:00:00.000,292; median=00:00:00.000,082; stddev=872058.0812378004; max=00:00:00.005,323
42 samples: min=00:00:00.000,077; avg=00:00:00.000,081; median=00:00:00.000,082; stddev=2527.9615442409304; max=00:00:00.000,095

Notice the significantly improved performance.

> JCR requires connectors to expose UUID as identifier property
> -------------------------------------------------------------
>
>                 Key: DNA-466
>                 URL: https://jira.jboss.org/jira/browse/DNA-466
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JCR implementation currently expects connectors to return a UUID as the identifier property.  This is obviously incorrect, as it goes against several of the connectors we've already implemented.  In particular, the SessionCache is expecting to find the UUID, and submits requests to the source with only the UUID (not the path).

-- 
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 Jun 19 18:46:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 19 Jun 2009 18:46:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-466) JCR requires
 connectors to expose UUID as identifier property
In-Reply-To: <5618761.1245270956476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2984153.1245451616341.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-466:
-----------------------------------

Changed the JCR implementation to use the path and UUID when both are known.

However, there still is a problem.  When the JCR session is saved but the client holds onto Node objects, and then those Node objects are used, only the UUID of those nodes are retained (because they're in the Node implementation objects, and the session's cache is cleared after a save).

> JCR requires connectors to expose UUID as identifier property
> -------------------------------------------------------------
>
>                 Key: DNA-466
>                 URL: https://jira.jboss.org/jira/browse/DNA-466
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JCR implementation currently expects connectors to return a UUID as the identifier property.  This is obviously incorrect, as it goes against several of the connectors we've already implemented.  In particular, the SessionCache is expecting to find the UUID, and submits requests to the source with only the UUID (not the path).

-- 
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 Jun 19 18:55:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 19 Jun 2009 18:55:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-466) JCR requires
 connectors to expose UUID as identifier property
In-Reply-To: <5618761.1245270956476.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <5698472.1245452156339.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-466:
-----------------------------------

One benefit of the current connectors that don't support UUIDs is that they don't support updates, meaning the client has no need to use Session.save().  So until this issue is resolved completely, two workarounds for configurations that use these connectors are:
1) do not call Session.save(), Session.refresh(), Node.save(), or Node.refresh(); or
2) do not retain Node references after any of these methods

Obviously these are not ideal, and thus this issue will remain open.

> JCR requires connectors to expose UUID as identifier property
> -------------------------------------------------------------
>
>                 Key: DNA-466
>                 URL: https://jira.jboss.org/jira/browse/DNA-466
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JCR implementation currently expects connectors to return a UUID as the identifier property.  This is obviously incorrect, as it goes against several of the connectors we've already implemented.  In particular, the SessionCache is expecting to find the UUID, and submits requests to the source with only the UUID (not the path).

-- 
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 Jun 19 19:41:56 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Fri, 19 Jun 2009 19:41:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-465) NullPointerException
 occurs when
 reading a FileSystemSource repository through JCR using FederatedSource
In-Reply-To: <10094966.1245264536772.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <290488.1245454916449.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Luiz Fernando Teston commented on DNA-465:
------------------------------------------

After the comment on the issue DNA-466 at the time 19/Jun/09 06:55 PM, updated the sources and I repeated the test obtaining a new exception. This exception was thrown by the same line that before throws a NPE. I know that the issue DNA-466 is not close, but as I'm using the repository only as a read only repository, I thought that it should work now.  

shouldAccessFileSystemByFederatedJcr(org.openspotligth.federation.configuration.DNAConfigFromFileTest)  Time elapsed: 0.792 sec  <<< FAILURE!
java.lang.AssertionError
	at org.jboss.dna.jcr.cache.ChildNode.<init>(ChildNode.java:53)
	at org.jboss.dna.jcr.cache.ImmutableChildren.<init>(ImmutableChildren.java:57)
	at org.jboss.dna.jcr.SessionCache.createNodeInfoFrom(SessionCache.java:2467)
	at org.jboss.dna.jcr.SessionCache.findNodeInfo(SessionCache.java:2054)
	at org.jboss.dna.jcr.SessionCache.findJcrItem(SessionCache.java:934)
	at org.jboss.dna.jcr.AbstractJcrNode.getNode(AbstractJcrNode.java:542)
	at org.openspotligth.federation.configuration.DNAConfigFromFileTest.shouldAccessFileSystemByFederatedJcr(DNAConfigFromFileTest.java:133)

> NullPointerException occurs when reading a FileSystemSource repository through JCR using FederatedSource
> --------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-465
>                 URL: https://jira.jboss.org/jira/browse/DNA-465
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Federation, JCR
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5 with java 1.6 and maven 2.1
>            Reporter: Luiz Fernando Teston
>
> When reading a node from a federated filesystem connector using the JCR API it throws a NullPointerException. This node represents a file and it could be read normally by the graph api.
> -- test method to be used inside the docs/gettingstarted/repository source --
> 	@Test
> 	public void shouldAccessFileSystemByFederatedJcr()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL url = Thread
> 				.currentThread()
> 				.getContextClassLoader()
> 				.getResource(
> 						"config/repository-federated-with-filesystem-connector-config.xml");
> 		assertNotNull(url);
> 		configuration.loadFrom(url);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		
> 		org.jboss.dna.graph.Node nodeFromGraph = engine.getGraph("Vehicles").getNodeAt("/Vehicles/FileSystem/FileThatExists");
> 		
> 		assertThat(nodeFromGraph, is(notNullValue()));
> 		
> 		Session session = engine.getRepository("Vehicles").login();
> 		
> 		Node nodeFromJcr = session.getRootNode().getNode("Vehicles/FileSystem/FileThatExists"); // here I got a NPE
> 		
> 		assertThat(nodeFromJcr, is(notNullValue()));
> 		
> 		engine.shutdown();
> 	}
> -- configuration file to be used on this test --
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- 
>   ~ JBoss DNA (http://www.jboss.org/dna)
>   ~
>   ~ See the COPYRIGHT.txt file distributed with this work for information
>   ~ regarding copyright ownership.  Some portions may be licensed
>   ~ to Red Hat, Inc. under one or more contributor license agreements.
>   ~ See the AUTHORS.txt file in the distribution for a full listing of 
>   ~ individual contributors.
>   ~
>   ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
>   ~ is licensed to you under the terms of the GNU Lesser General Public License as
>   ~ published by the Free Software Foundation; either version 2.1 of
>   ~ the License, or (at your option) any later version.
>   ~
>   ~ JBoss DNA is distributed in the hope that it will be useful,
>   ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>   ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
>   ~ for more details.
>   ~
>   ~ You should have received a copy of the GNU Lesser General Public License
>   ~ along with this distribution; if not, write to:
>   ~ Free Software Foundation, Inc.
>   ~ 51 Franklin Street, Fifth Floor
>   ~ Boston, MA  02110-1301  USA
>   -->
> <configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
>     <!-- 
>     Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
>     In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
>     JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
>     -->
>     <dna:sources jcr:primaryType="nt:unstructured">
>         <!-- 
>         The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
>         -->
>         <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>
>         <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource"> 
>             <creatingWorkspacesAllowed>false</creatingWorkspacesAllowed> 
>             <directoryForDefaultWorkspace>/tmp</directoryForDefaultWorkspace> 
>         </dna:source> 
>         <!-- 
>         The 'Aircraft' repository is also an in-memory source with a single default workspace.
>         By defining a default workspace, the clients using the Graph API will by default use that workspace,
>         but can easily say to use other workspaces (or create, clone, or destroy workspaces).
>         -->
>         <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
>             <!-- Define the name of the workspace used by default.  Optional, but convenient.
> -->
>             <defaultWorkspaceName>workspace</defaultWorkspaceName>
>         </dna:source>
>         <!-- 
>         The 'Vehicles' repository is a federated source that owns none of its own content, but instead
>         projects (in this case) all of the content from the 'Cars' source as if it appears
>         under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
>         -->
>         <dna:source jcr:name="Vehicles">
>             <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
>             <dna:workspaces>
>                 <!-- 
>                 Unlike some other repository sources, federated sources have to define all of their workspaces,
>                 including how and where the content is projected.  So, we only need a single workspace,
>                 but we could actually define additional workspaces that expose various combinations or portions
>                 of 'Cars' and/or 'Aircraft' content.
>                 -->
>                 <dna:workspace jcr:name="workspace">
>                     <dna:projections>
>                         <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
>                         <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace">
>                             <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
>                         </dna:projection>
> 				        <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="/tmp"> 
> 				            <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules> 
> 				        </dna:projection> 
>                         <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node.
> -->
>                         <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace">
>                             <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'System' content. Only needed when this source is accessed through JCR.
> -->
>                         <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
>                             <dna:projectionRules>/jcr:system => /</dna:projectionRules>
>                         </dna:projection>
>                     </dna:projections>
>                 </dna:workspace>
>             </dna:workspaces>
>             
>             <retryLimit>20</retryLimit>
>             
>         </dna:source>
>         <!-- 
>         A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
>         -->
>         <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
>     </dna:sources>
>   
>     <!-- 
>     Define the JCR repositories 
>     -->
>     <dna:repositories>
>         <!-- 
>         Define a JCR repository that accesses the 'Cars' source directly.
>         This of course is optional, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Cars">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Cars</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names
> -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here.
> -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA
> -->
>             <namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>             </namespaces>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Aircraft' source directly.
>         This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Aircraft">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Aircraft</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names
> -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>         </dna:repository>
>         <dna:repository jcr:name="Vehicles">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Vehicles</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names
> -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>         </dna:repository>
>         
>     </dna:repositories>
> </configuration>
> --- exception thrown by this test method ---
> java.lang.NullPointerException
> 	at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:173)
> 	at com.google.common.collect.ReferenceMap$ReferenceStrategy$1.getDummyFor(ReferenceMap.java:475)
> 	at com.google.common.collect.ReferenceMap.get(ReferenceMap.java:168)
> 	at org.jboss.dna.jcr.SessionCache.findJcrNode(SessionCache.java:817)
> 	at org.jboss.dna.jcr.SessionCache.findJcrItem(SessionCache.java:941)
> 	at org.jboss.dna.jcr.AbstractJcrNode.getNode(AbstractJcrNode.java:542)
> 	at org.openspotligth.federation.configuration.DNAConfigFromFileTest.shouldAccessFileSystemByFederatedJcr(DNAConfigFromFileTest.java:116)
> 	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:585)
> 	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  Sat Jun 20 00:55:56 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Sat, 20 Jun 2009 00:55:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-465) NullPointerException
 occurs when
 reading a FileSystemSource repository through JCR using FederatedSource
In-Reply-To: <10094966.1245264536772.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7990415.1245473756487.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Luiz Fernando Teston commented on DNA-465:
------------------------------------------

As on the last comment of issue DNA-466 says that actually the read only connectors don't support uuids, I tried to remove the assertions on ChildNode (that thrown the AssertionError) and after that I removed also the assertions on ImmutableNodeInfo to try to see if removing the uuid related assertions should make the read only connectors (such as filesystem connector) to work through jcr, I got a NPE from line 2102 from SessionCache. After putting an "if (uuid != null && " on this if the last exception is a NPE from AbstractJcrNode. It seems that the uuid is used in a lot of places for cache purposes. 

shouldAccessFileSystemByFederatedJcr(org.openspotligth.federation.configuration.DNAConfigFromFileTest)  Time elapsed: 0.798 sec  <<< ERROR!
java.lang.NullPointerException
	at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:173)
	at com.google.common.collect.ReferenceMap$ReferenceStrategy$1.getDummyFor(ReferenceMap.java:475)
	at com.google.common.collect.ReferenceMap.get(ReferenceMap.java:168)
	at org.jboss.dna.jcr.SessionCache.findJcrNode(SessionCache.java:819)
	at org.jboss.dna.jcr.SessionCache.findJcrItem(SessionCache.java:943)
	at org.jboss.dna.jcr.AbstractJcrNode.getNode(AbstractJcrNode.java:542) 

> NullPointerException occurs when reading a FileSystemSource repository through JCR using FederatedSource
> --------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-465
>                 URL: https://jira.jboss.org/jira/browse/DNA-465
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, Federation, JCR
>    Affects Versions: 0.5
>         Environment: Mac OS 10.5 with java 1.6 and maven 2.1
>            Reporter: Luiz Fernando Teston
>
> When reading a node from a federated filesystem connector using the JCR API it throws a NullPointerException. This node represents a file and it could be read normally by the graph api.
> -- test method to be used inside the docs/gettingstarted/repository source --
> 	@Test
> 	public void shouldAccessFileSystemByFederatedJcr()
> 			throws Exception {
> 		JcrConfiguration configuration = new JcrConfiguration();
> 		URL url = Thread
> 				.currentThread()
> 				.getContextClassLoader()
> 				.getResource(
> 						"config/repository-federated-with-filesystem-connector-config.xml");
> 		assertNotNull(url);
> 		configuration.loadFrom(url);
> 		JcrEngine engine = configuration.build();
> 		engine.start();
> 		
> 		org.jboss.dna.graph.Node nodeFromGraph = engine.getGraph("Vehicles").getNodeAt("/Vehicles/FileSystem/FileThatExists");
> 		
> 		assertThat(nodeFromGraph, is(notNullValue()));
> 		
> 		Session session = engine.getRepository("Vehicles").login();
> 		
> 		Node nodeFromJcr = session.getRootNode().getNode("Vehicles/FileSystem/FileThatExists"); // here I got a NPE
> 		
> 		assertThat(nodeFromJcr, is(notNullValue()));
> 		
> 		engine.shutdown();
> 	}
> -- configuration file to be used on this test --
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- 
>   ~ JBoss DNA (http://www.jboss.org/dna)
>   ~
>   ~ See the COPYRIGHT.txt file distributed with this work for information
>   ~ regarding copyright ownership.  Some portions may be licensed
>   ~ to Red Hat, Inc. under one or more contributor license agreements.
>   ~ See the AUTHORS.txt file in the distribution for a full listing of 
>   ~ individual contributors.
>   ~
>   ~ JBoss DNA is free software. Unless otherwise indicated, all code in JBoss DNA
>   ~ is licensed to you under the terms of the GNU Lesser General Public License as
>   ~ published by the Free Software Foundation; either version 2.1 of
>   ~ the License, or (at your option) any later version.
>   ~
>   ~ JBoss DNA is distributed in the hope that it will be useful,
>   ~ but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
>   ~ or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public License
>   ~ for more details.
>   ~
>   ~ You should have received a copy of the GNU Lesser General Public License
>   ~ along with this distribution; if not, write to:
>   ~ Free Software Foundation, Inc.
>   ~ 51 Franklin Street, Fifth Floor
>   ~ Boston, MA  02110-1301  USA
>   -->
> <configuration xmlns:dna="http://www.jboss.org/dna/1.0" xmlns:jcr="http://www.jcp.org/jcr/1.0">
>     <!-- 
>     Define the sources for the content.  These sources are directly accessible using the DNA-specific Graph API.
>     In fact, this is how the DNA JCR implementation works.  You can think of these as being similar to
>     JDBC DataSource objects, except that they expose graph content via the Graph API instead of records via SQL or JDBC. 
>     -->
>     <dna:sources jcr:primaryType="nt:unstructured">
>         <!-- 
>         The 'Cars' repository is an in-memory source with a single default workspace (though others could be created, too).
>         -->
>         <dna:source jcr:name="Cars" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="workspace1"/>
>         <dna:source jcr:name="FileSystem" dna:classname="org.jboss.dna.connector.filesystem.FileSystemSource"> 
>             <creatingWorkspacesAllowed>false</creatingWorkspacesAllowed> 
>             <directoryForDefaultWorkspace>/tmp</directoryForDefaultWorkspace> 
>         </dna:source> 
>         <!-- 
>         The 'Aircraft' repository is also an in-memory source with a single default workspace.
>         By defining a default workspace, the clients using the Graph API will by default use that workspace,
>         but can easily say to use other workspaces (or create, clone, or destroy workspaces).
>         -->
>         <dna:source jcr:name="Aircraft" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource">
>             <!-- Define the name of the workspace used by default.  Optional, but convenient.
> -->
>             <defaultWorkspaceName>workspace</defaultWorkspaceName>
>         </dna:source>
>         <!-- 
>         The 'Vehicles' repository is a federated source that owns none of its own content, but instead
>         projects (in this case) all of the content from the 'Cars' source as if it appears
>         under '/Vehicles/Cars', while all the 'Aircraft' content appears under '/Vehicles/Aircraft'.
>         -->
>         <dna:source jcr:name="Vehicles">
>             <dna:classname>org.jboss.dna.graph.connector.federation.FederatedRepositorySource</dna:classname>
>             <dna:workspaces>
>                 <!-- 
>                 Unlike some other repository sources, federated sources have to define all of their workspaces,
>                 including how and where the content is projected.  So, we only need a single workspace,
>                 but we could actually define additional workspaces that expose various combinations or portions
>                 of 'Cars' and/or 'Aircraft' content.
>                 -->
>                 <dna:workspace jcr:name="workspace">
>                     <dna:projections>
>                         <!-- Project the 'Cars' content, starting with the '/Cars' node. -->
>                         <dna:projection jcr:name="Cars projection" dna:source="Cars" dna:workspaceName="workspace">
>                             <dna:projectionRules>/Vehicles/Cars => /Cars</dna:projectionRules>
>                         </dna:projection>
> 				        <dna:projection jcr:name="TempFiles projection" dna:source="FileSystem" dna:workspaceName="/tmp"> 
> 				            <dna:projectionRules>/Vehicles/FileSystem => /</dna:projectionRules> 
> 				        </dna:projection> 
>                         <!-- Project the 'Aicraft' content, starting with the '/Aircraft' node.
> -->
>                         <dna:projection jcr:name="Aircarft projection" dna:source="Aircraft" dna:workspaceName="workspace">
>                             <dna:projectionRules>/Vehicles/Aircraft => /Aircraft</dna:projectionRules>
>                         </dna:projection>
>                         <!-- Project the 'System' content. Only needed when this source is accessed through JCR.
> -->
>                         <dna:projection jcr:name="System projection" dna:source="System" dna:workspaceName="default">
>                             <dna:projectionRules>/jcr:system => /</dna:projectionRules>
>                         </dna:projection>
>                     </dna:projections>
>                 </dna:workspace>
>             </dna:workspaces>
>             
>             <retryLimit>20</retryLimit>
>             
>         </dna:source>
>         <!-- 
>         A 'System' source needed for the '/jcr:system' branch of the Vehicles source when it is access through JCR.
>         -->
>         <dna:source jcr:name="System" dna:classname="org.jboss.dna.graph.connector.inmemory.InMemoryRepositorySource" dna:retryLimit="3" dna:defaultWorkspaceName="default"/>
>     </dna:sources>
>   
>     <!-- 
>     Define the JCR repositories 
>     -->
>     <dna:repositories>
>         <!-- 
>         Define a JCR repository that accesses the 'Cars' source directly.
>         This of course is optional, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Cars">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Cars</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names
> -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>             <!-- Define any custom node types. Importing CND files via JcrConfiguration is equivalent to specifying here.
> -->
>             <dna:nodeTypes jcr:primaryType="dna:nodeTypes"/>
>             <!-- Define any namespaces for this repository, other than those already defined by JCR or DNA
> -->
>             <namespaces jcr:primaryType="dna:namespaces">
>                 <car jcr:primaryType="dna:namespace" dna:uri="http://jboss.org/dna/examples/cars/1.0"/>
>             </namespaces>
>         </dna:repository>
>         <!-- 
>         Define a JCR repository that accesses the 'Aircraft' source directly.
>         This of course isn't really necessary for this example, since we could access the same content through 'vehicles'.
>         -->
>         <dna:repository jcr:name="Aircraft">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Aircraft</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names
> -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>         </dna:repository>
>         <dna:repository jcr:name="Vehicles">
>             <!-- Specify the source that should be used for the repository -->
>             <dna:source>Vehicles</dna:source>
>             <!-- Define the options for the JCR repository, using camelcase version of JcrRepository.Option names
> -->
>             <dna:options jcr:primaryType="dna:options">
>                 <jaasLoginConfigName jcr:primaryType="dna:option" dna:value="dna-jcr"/>
>             </dna:options>
>         </dna:repository>
>         
>     </dna:repositories>
> </configuration>
> --- exception thrown by this test method ---
> java.lang.NullPointerException
> 	at com.google.common.base.Preconditions.checkNotNull(Preconditions.java:173)
> 	at com.google.common.collect.ReferenceMap$ReferenceStrategy$1.getDummyFor(ReferenceMap.java:475)
> 	at com.google.common.collect.ReferenceMap.get(ReferenceMap.java:168)
> 	at org.jboss.dna.jcr.SessionCache.findJcrNode(SessionCache.java:817)
> 	at org.jboss.dna.jcr.SessionCache.findJcrItem(SessionCache.java:941)
> 	at org.jboss.dna.jcr.AbstractJcrNode.getNode(AbstractJcrNode.java:542)
> 	at org.openspotligth.federation.configuration.DNAConfigFromFileTest.shouldAccessFileSystemByFederatedJcr(DNAConfigFromFileTest.java:116)
> 	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:585)
> 	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  Sat Jun 20 11:12:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 20 Jun 2009 11:12:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-370) JcrWorkspace.clone Is
 Not Implemented
In-Reply-To: <1486867.1240252882274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21589711.1245510776346.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-370:
--------------------------------

    Attachment: DNA-370_copy_behavior.patch


Applied the attached patch (DNA-370_copy_behavior) to add support for UuidConflictBehavior in the graph layer and each of the three connectors that currently support writes.  This includes the previous patch to modify the JPA connector and required some fairly heavy modifications of the JBoss Cache connector to support efficient look-ups by UUID.

The patch also corrects some configuration to allow the JR TCK clone tests to start working.  This will result in one false negative in the nightly TCK compatibility build, as there is a clone test that assumes the repository supports locking.

There is still some work left to be done to fully support clone.  If removeExisting is true, the JCR layer must first identify any conflicts and speculatively remove them to make sure that removing the existing nodes won't violate type constraints.  This check cannot be done at the graph or connector layer, as those layers are unaware of the JCR typing semantics.  Additionally, the update method must still be implemented.

> JcrWorkspace.clone Is Not Implemented
> -------------------------------------
>
>                 Key: DNA-370
>                 URL: https://jira.jboss.org/jira/browse/DNA-370
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-370_copy_behavior.patch, JpaConnector_with_clone_support.patch
>
>
> JcrWorkspace.clone is not yet implemented.  This may not be important/useful for 0.4.  AbstractJcrNode.getCorrespondingNodePath is also not yet 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  Sat Jun 20 20:11:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 20 Jun 2009 20:11:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-469) SessionCache Does Not
 Handle Node Definitions Correctly After Move
Message-ID: <6564419.1245543116319.JavaMail.jira@cloud.prod.atl2.jboss.com>

SessionCache Does Not Handle Node Definitions Correctly After Move
------------------------------------------------------------------

                 Key: DNA-469
                 URL: https://jira.jboss.org/jira/browse/DNA-469
             Project: DNA
          Issue Type: Bug
          Components: JCR
    Affects Versions: 0.5
            Reporter: Brian Carothers
             Fix For: 0.6


After a node is moved to a new parent, it will likely have a new node definition.  The SessionCache correctly calculates the new node definition... and then sets it on the parent instead of the child.



-- 
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 Jun 20 20:15:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 20 Jun 2009 20:15:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-469) SessionCache Does Not
 Handle Node Definitions Correctly After Move
In-Reply-To: <6564419.1245543116319.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16144039.1245543356369.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-469:
--------------------------------

    Attachment: DNA-469.patch


Attached patch that fixed the issue above.  It also properly clears the jcrNodes cache on a session refresh, sets the correct cardinality on the dnaint:nodeDefinition property from multi-valued to single-valued, and fixes a few cosmetic issues.

> SessionCache Does Not Handle Node Definitions Correctly After Move
> ------------------------------------------------------------------
>
>                 Key: DNA-469
>                 URL: https://jira.jboss.org/jira/browse/DNA-469
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-469.patch
>
>
> After a node is moved to a new parent, it will likely have a new node definition.  The SessionCache correctly calculates the new node definition... and then sets it on the parent instead of the child.

-- 
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 Jun 20 20:44:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 20 Jun 2009 20:44:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-370) JcrWorkspace.clone Is
 Not Implemented
In-Reply-To: <1486867.1240252882274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13086544.1245545096324.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-370:
--------------------------------

    Attachment: DNA-370_remove_items_constraint_check.patch


Committed attached patch to add constraint checking to clone with removeExisting = true.

> JcrWorkspace.clone Is Not Implemented
> -------------------------------------
>
>                 Key: DNA-370
>                 URL: https://jira.jboss.org/jira/browse/DNA-370
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-370_copy_behavior.patch, DNA-370_remove_items_constraint_check.patch, JpaConnector_with_clone_support.patch
>
>
> JcrWorkspace.clone is not yet implemented.  This may not be important/useful for 0.4.  AbstractJcrNode.getCorrespondingNodePath is also not yet 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  Sun Jun 21 22:26:07 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sun, 21 Jun 2009 22:26:07 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-469) SessionCache Does Not
 Handle Node Definitions Correctly After Move
In-Reply-To: <6564419.1245543116319.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27141210.1245637567960.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-469.
---------------------------------

    Resolution: Done
      Assignee: Brian Carothers


Applied the patch to resolve the issue

> SessionCache Does Not Handle Node Definitions Correctly After Move
> ------------------------------------------------------------------
>
>                 Key: DNA-469
>                 URL: https://jira.jboss.org/jira/browse/DNA-469
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-469.patch
>
>
> After a node is moved to a new parent, it will likely have a new node definition.  The SessionCache correctly calculates the new node definition... and then sets it on the parent instead of the child.

-- 
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 Jun 26 21:54:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 26 Jun 2009 21:54:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-470) Provide Base Set of
 Connector Classes for All Map-Based Connectors
Message-ID: <11258553.1246067696307.JavaMail.jira@cloud.prod.atl2.jboss.com>

Provide Base Set of Connector Classes for All Map-Based Connectors
------------------------------------------------------------------

                 Key: DNA-470
                 URL: https://jira.jboss.org/jira/browse/DNA-470
             Project: DNA
          Issue Type: Feature Request
          Components: API, Connectors
    Affects Versions: 0.5
            Reporter: Brian Carothers
            Assignee: Brian Carothers
             Fix For: 0.6


The InMemoryRepository and JBossCacheRepository can both be thought of as ways of implementing a connector that is backed by a Map of UUIDs to Nodes.  A future Infinispan-based connector would likely function in the same manner.  Both connectors could be simplified if they extended a basic, abstract implementation of a map-based connector.

-- 
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 Jun 26 22:52:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 26 Jun 2009 22:52:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-470) Provide Base Set of
 Connector Classes for All Map-Based Connectors
In-Reply-To: <11258553.1246067696307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24047283.1246071176563.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-470:
--------------------------------

    Attachment: DNA-470.patch


Attached patch that creates a new MapRepository class (and associated classes) based on the original InMemoryRepository implementation and refactors the In-Memory connector and JBoss Cache connector to utilize the new MapRepository.

> Provide Base Set of Connector Classes for All Map-Based Connectors
> ------------------------------------------------------------------
>
>                 Key: DNA-470
>                 URL: https://jira.jboss.org/jira/browse/DNA-470
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-470.patch
>
>
> The InMemoryRepository and JBossCacheRepository can both be thought of as ways of implementing a connector that is backed by a Map of UUIDs to Nodes.  A future Infinispan-based connector would likely function in the same manner.  Both connectors could be simplified if they extended a basic, abstract implementation of a map-based connector.

-- 
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 Jun 26 22:52:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 26 Jun 2009 22:52:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-470) Provide Base Set of
 Connector Classes for All Map-Based Connectors
In-Reply-To: <11258553.1246067696307.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11260366.1246071176604.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-470.
---------------------------------

    Resolution: Done


Applied patch to resolve defect

> Provide Base Set of Connector Classes for All Map-Based Connectors
> ------------------------------------------------------------------
>
>                 Key: DNA-470
>                 URL: https://jira.jboss.org/jira/browse/DNA-470
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-470.patch
>
>
> The InMemoryRepository and JBossCacheRepository can both be thought of as ways of implementing a connector that is backed by a Map of UUIDs to Nodes.  A future Infinispan-based connector would likely function in the same manner.  Both connectors could be simplified if they extended a basic, abstract implementation of a map-based connector.

-- 
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 Jun 27 20:30:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 27 Jun 2009 20:30:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-370) JcrWorkspace.clone Is
 Not Implemented
In-Reply-To: <1486867.1240252882274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <32146372.1246149056490.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-370:
--------------------------------

    Attachment: DNA-370_clone_request.patch


I tried to make workspace.update work with the existing CopyBranchRequest, but it required some changes that would have made the semantics of to(...) and into(...) ambiguous and dependent on whether the UUID conflict behavior was ALWAYS_CREATE_NEW or not.  Instead, I pulled the UUID behavior out of the CopyBranchRequest and added it into a new request - CloneBranchRequest.  This provides clear semantics for copy (always creates new UUIDs, may be between workspaces or within a single workspace, may function at the property or node level) and clone (always preserves UUIDs, only works between workspaces, may remove nodes from target workspace, only works at the node level).

The attached patch adds the new request and all of the associated changes on the graph side (adding clone operation) and the connector (implementing clone behavior for writable connectors) and modifies the workspace.clone and node.update operations accordingly.

> JcrWorkspace.clone Is Not Implemented
> -------------------------------------
>
>                 Key: DNA-370
>                 URL: https://jira.jboss.org/jira/browse/DNA-370
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-370_clone_request.patch, DNA-370_copy_behavior.patch, DNA-370_remove_items_constraint_check.patch, JpaConnector_with_clone_support.patch
>
>
> JcrWorkspace.clone is not yet implemented.  This may not be important/useful for 0.4.  AbstractJcrNode.getCorrespondingNodePath is also not yet 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  Sat Jun 27 20:34:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 27 Jun 2009 20:34:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-370) JcrWorkspace.clone
 Is Not Implemented
In-Reply-To: <1486867.1240252882274.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14112799.1246149296337.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers commented on DNA-370:
-------------------------------------

Committed change, but leaving defect open for a few days for comment.

> JcrWorkspace.clone Is Not Implemented
> -------------------------------------
>
>                 Key: DNA-370
>                 URL: https://jira.jboss.org/jira/browse/DNA-370
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-370_clone_request.patch, DNA-370_copy_behavior.patch, DNA-370_remove_items_constraint_check.patch, JpaConnector_with_clone_support.patch
>
>
> JcrWorkspace.clone is not yet implemented.  This may not be important/useful for 0.4.  AbstractJcrNode.getCorrespondingNodePath is also not yet 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  Sat Jun 27 22:14:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 27 Jun 2009 22:14:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-399) Need to Add
 Session.checkPermission
 Calls to Guard Read, Add Node, Set Property, and Remove Item Access
In-Reply-To: <12308912.1241888086497.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18032391.1246155296561.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-399:
--------------------------------

    Attachment: DNA-399_forum_feedback.patch


Attached patch that incorporates the feedback-to-date from the forum topic.  An additional "admin" role is added and security checks for permanently registering and unregistering types and namespaces were added that check for this role.  The admin role is a superset of the readwrite role, which is itself a superset of the readonly role.  The pattern for mapping roles was changed to be <role name>[.<repository name>[.<workspace name>]] instead of <role name>[.<workspace name>].  Finally, JcrRepository.login was modified to not allow users to log into workspaces to which they do not have at least readonly access.  JcrWorkspace.getAccessibleWorkspaceNames() was also modified to filter out workspace names to which the user does not have at least readonly access.

> Need to Add Session.checkPermission Calls to Guard Read, Add Node, Set Property, and Remove Item Access
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-399
>                 URL: https://jira.jboss.org/jira/browse/DNA-399
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-399.patch, DNA-399_forum_feedback.patch
>
>
> Now that JcrSession.checkPermission works (assuming patch takes), we need to add checkPermission calls to guard "read", "add_node", "remove", and "set_property" access, as per spec.

-- 
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 Jun 27 22:14:56 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 27 Jun 2009 22:14:56 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-399) Need to Add
 Session.checkPermission Calls to Guard Read, Add Node, Set Property, and
 Remove Item Access
In-Reply-To: <12308912.1241888086497.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13133847.1246155296600.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers resolved DNA-399.
---------------------------------

    Resolution: Done
      Assignee: Brian Carothers


Applied DNA-399_forum_feedback.patch to complete defect resolution.  Any additional feedback can be incorporated into a separate issue.

> Need to Add Session.checkPermission Calls to Guard Read, Add Node, Set Property, and Remove Item Access
> -------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-399
>                 URL: https://jira.jboss.org/jira/browse/DNA-399
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR
>    Affects Versions: 0.4
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>         Attachments: DNA-399.patch, DNA-399_forum_feedback.patch
>
>
> Now that JcrSession.checkPermission works (assuming patch takes), we need to add checkPermission calls to guard "read", "add_node", "remove", and "set_property" access, as per spec.

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

        


