From jira-events at lists.jboss.org  Thu Feb 12 15:59:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 15:59:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-281) Connector support for
	workspaces
Message-ID: <12204848.1234472384149.JavaMail.jira@cloud.prod.atl2.jboss.com>

Connector support for workspaces
--------------------------------

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


The connector framework doesn't currently have a notion of workspaces.  They were originally designed this way to keep things simple, but it turns out that not having workspaces means that a separate RepositorySource would be needed for each JCR workspace, and even if multiple RepositorySource instances connected to the back end system, a lot of inefficiencies would be introduced (including duplicate connection pools, inability to efficiently handle inter-workspace operations like copying or cloning, difficulty managing sources when creating new workspaces, etc.).

Therefore, to more closely match the JCR API and to more efficiently support inter-workspace operations (within the same repository), the DNA connector framework should have a notion of workspaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 16:11:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 16:11:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-281) Connector support
	for workspaces
In-Reply-To: <12204848.1234472384149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8439912.1234473104287.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-281:
-----------------------------------

Several different options were investigated:
1) Adding the name of the workspace to Location, allowing existing requests to operate against workspaces.  This may have involved fewer changes, since the Location object would be doing the work of maintaining the workspace reference.  However, considering that Location objects are used with every request and in every response, the additional size of the Location objects (many with the same workspace) would also make this option more memory intensive.  Also, some existing requests that take two Locations (e.g., move) may not make much sense if each Location had a different workspace. (The JCR spec does not define moving between workspaces, although copying and cloning are defined).  This option also complicates the Graph API by increasing the number of ways in which a node can be specified.

2) Add the name of the workspace to each Request (or in some cases like CopyBranchRequest, the names of the multiple workspaces).  This option has the advantage of tracking the workspace(s) only on the requests and not in the results, as the requests are really a transient representation of an operation, whereas the results of the requests (e.g., Locations, Property, values, etc.) would not contain the workspace references and would not increase in memory footprint.  This is considerable, as there would often be orders of magnitude fewer workspaces than there are nodes and Locations.  This design option also fits in a little better with the new types of requests needed to get the list of workspaces, create new workspaces, clone workspaces, or delete workspaces.

The design started with Option 1 since it was thought to be least intrusive and most straightforward, but this initial implementation highlighted the disadvantages.  Option 2 was then prototyped, and although there were more changes, option 2 appeared to be a more natural design that seemed to work better.  Therefore, option 2 was chosen for the implementation.

> Connector support for workspaces
> --------------------------------
>
>                 Key: DNA-281
>                 URL: https://jira.jboss.org/jira/browse/DNA-281
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The connector framework doesn't currently have a notion of workspaces.  They were originally designed this way to keep things simple, but it turns out that not having workspaces means that a separate RepositorySource would be needed for each JCR workspace, and even if multiple RepositorySource instances connected to the back end system, a lot of inefficiencies would be introduced (including duplicate connection pools, inability to efficiently handle inter-workspace operations like copying or cloning, difficulty managing sources when creating new workspaces, etc.).
> Therefore, to more closely match the JCR API and to more efficiently support inter-workspace operations (within the same repository), the DNA connector framework should have a notion of workspaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 16:22:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 16:22:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-281) Connector support
	for workspaces
In-Reply-To: <12204848.1234472384149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9548972.1234473764176.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-281:
-----------------------------------

Adding the notion of workspaces to the connectors does actually impact quite a few areas of the codebase.  First of all, every connector is affected because existing implementations have to be changed to support the notion of workspaces.  Also, we're adding new Request types (see below), and the RequestProcessor's "process(...)" methods for these new types do not have very useful default implementations, so all existing connectors need to be changed to provide them.  A number of connector implementations should actually benefit from this change.  For example, it makes a lot of sense to map the branches/tags in an SVN repository as workspaces in the SVN connector; this mirrors JCR's notion of a workspace (and the fact that a node in one workspace may have corresponding nodes in other workspaces, in much the same way that a file in one branch corresponds to that file in other branches).

Second, the change also impacts the Graph API.  With Option 2 as the design choice, additional methods were added to Graph to specify which workspace should be used (from that point forward, until another one is specified), to verify that a workspace exists (and to obtain the default workspace), to create new workspaces, to copy or clone a workspace as a new workspace, to obtain the names of the existing workspaces, and to delete a workspace.  These methods of course map directly to the new Request types:  VerifyWorkspaceRequest, CreateWorkspaceRequest, CopyWorkspaceRequest, CloneWorkspaceRequest, GetWorkspacesRequest, and DeleteWorkspaceRequest, respectively).

Thirdly, the change in the Graph API propagates to all the places in the code that using it ... that means a lot of test cases and a few higher-level projects.  This complicates the commit set, but doesn't really complicate the use of these components.

> Connector support for workspaces
> --------------------------------
>
>                 Key: DNA-281
>                 URL: https://jira.jboss.org/jira/browse/DNA-281
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The connector framework doesn't currently have a notion of workspaces.  They were originally designed this way to keep things simple, but it turns out that not having workspaces means that a separate RepositorySource would be needed for each JCR workspace, and even if multiple RepositorySource instances connected to the back end system, a lot of inefficiencies would be introduced (including duplicate connection pools, inability to efficiently handle inter-workspace operations like copying or cloning, difficulty managing sources when creating new workspaces, etc.).
> Therefore, to more closely match the JCR API and to more efficiently support inter-workspace operations (within the same repository), the DNA connector framework should have a notion of workspaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 16:38:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 16:38:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-281) Connector support
	for workspaces
In-Reply-To: <12204848.1234472384149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7915457.1234474724194.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-281:
-----------------------------------

Each connector can choose to support workspaces in a couple of different ways.

The connector framework supports the ability to discover the workspaces that are available in a source (or, rather, that are available to the supplied ExecutionContext).  In general, the connector would simply return the set of names of existing workspaces, where "existing" means something meaningful to the connector.  For example, the JPA Store connector allows defining on the source instance the names of some "predefined" workspaces; these workspaces don't need to be created by the client, becuase the connector always behaves as though those workspaces exist, even if they haven't yet been accessed or initialized.

The connector framework also supports the notion of a default workspace.  Basically, this is simply a way of allowing a connector to say which workspace should be used if none is specified by the client.  However, all requests require a non-null workspace name, with one exception: the VerifyWorkspaceRequest is intended to allow the client to verify that a workspace exists.  If the name of the workspace is null, the connector is free to respond with an error or to choose an existing workspace to use.

The ability to create new workspaces is defined as a new connector capability, so it's possible for connector implementations to not support creating new workspaces and to simply define the existing workspaces that are available.  The SVN connector is one example that might make use of this approach, since the workspaces might be defined by the (existing) branches and tags.  (Although branching could be implemented via cloning of a workspace, but this is probably beyond what's needed/desired.)

A connector implementation can combine these characteristics to produce a wide range of support.  For example, a connector that doesn't really support workspaces really supports just one (which should also be the default) and doesn't support creating new workspaces, cloning workspaces, or destroying existing workspaces.  On the other hand, a connector could support multiple workspaces and even allow the client to define new or cloned workspaces.  Or, as with the SVN connector, the connector may support multiple workspaces but may not allow clients creating, cloning or destroying workspaces.

> Connector support for workspaces
> --------------------------------
>
>                 Key: DNA-281
>                 URL: https://jira.jboss.org/jira/browse/DNA-281
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The connector framework doesn't currently have a notion of workspaces.  They were originally designed this way to keep things simple, but it turns out that not having workspaces means that a separate RepositorySource would be needed for each JCR workspace, and even if multiple RepositorySource instances connected to the back end system, a lot of inefficiencies would be introduced (including duplicate connection pools, inability to efficiently handle inter-workspace operations like copying or cloning, difficulty managing sources when creating new workspaces, etc.).
> Therefore, to more closely match the JCR API and to more efficiently support inter-workspace operations (within the same repository), the DNA connector framework should have a notion of workspaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 16:59:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 16:59:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-281) Connector support
	for workspaces
In-Reply-To: <12204848.1234472384149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26121668.1234475984157.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-281:
-----------------------------------

The Graph API changes to support workspaces are as follows.  Note that each example returns the graph's Workspace object, which has the name as well as access to the actual location of the root.

To use an existing workspace:
    Workspace ws = graph.useWorkspace("my workspace name");

Note that if the workspace name is null, the "default" workspace is to be used (whatever that means for the source, or if it's not supported, an exception will be thrown).  The resulting Workspace object will have the name of the actual workspace being used.

To create a new workspace:
    Workspace ws = graph.createWorkspace().named("new workspace name");

This will fail if the workspace cannot be created (e.g., it might already exist, or the source might not allow creating workspaces).  Or, you can always create a new workspace using this technique:
    Workspace ws = graph.createWorkspace().namedSomethingLike("workspace");

As long as the source supports creating new workspaces, it should create a workspace and adjust the supplied name so that it is unique.  Or, you can create a new workspace by cloning the contents of an existing workspace:
    Workspace ws1 = graph.createWorkspace().clonedFrom("original").named("something");
    Workspace ws2 = graph.createWorkspace().clonedFrom("original").namedSomethingLike("something");

As soon as these operations are performed, the graph will start using the resulting workspace (known as the "current" workspace).  You can also get the current workspace:
    Workspace ws = graph.getCurrentWorkspace();

or the name of the current workspace:
    String name = graph.getCurrentWorkspaceName();

which is identical to:
    String name = graph.getCurrentWorkspace() != null ? graph.getCurrentWorkspace().getName() : null;

You can also obtain the list of all available workspaces:
    Set<String> workspaceNames = graph.getWorkspaces();


> Connector support for workspaces
> --------------------------------
>
>                 Key: DNA-281
>                 URL: https://jira.jboss.org/jira/browse/DNA-281
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The connector framework doesn't currently have a notion of workspaces.  They were originally designed this way to keep things simple, but it turns out that not having workspaces means that a separate RepositorySource would be needed for each JCR workspace, and even if multiple RepositorySource instances connected to the back end system, a lot of inefficiencies would be introduced (including duplicate connection pools, inability to efficiently handle inter-workspace operations like copying or cloning, difficulty managing sources when creating new workspaces, etc.).
> Therefore, to more closely match the JCR API and to more efficiently support inter-workspace operations (within the same repository), the DNA connector framework should have a notion of workspaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 17:28:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 17:28:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-281) Connector support for
	workspaces
In-Reply-To: <12204848.1234472384149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20694767.1234477724210.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-281.
-------------------------------

    Resolution: Done


Implemented the changes to support workspaces in connectors.  This involved a lot of changes, including all connectors, the Graph API (and implementation), and all uses of the graph API (including a lot of test cases).

The SimpleRepositorySource that was available in dna-graph/src/java/test was removed because it started to mirror the code that is in the InMemoryRepositorySource (which is now in dna-graph).  This affected quite a few tests cases.

This change also made apparent a couple of issues with the current federation code.  These problems require more in-depth changes and will be done next, but shouldn't be mixed with this set of changes.  This also has implications for several higher-level projects (dna-jcr, getting started examples) that use the connector.  Therefore, these projects were temporarily removed and will be added back in shortly.

> Connector support for workspaces
> --------------------------------
>
>                 Key: DNA-281
>                 URL: https://jira.jboss.org/jira/browse/DNA-281
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Connectors
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The connector framework doesn't currently have a notion of workspaces.  They were originally designed this way to keep things simple, but it turns out that not having workspaces means that a separate RepositorySource would be needed for each JCR workspace, and even if multiple RepositorySource instances connected to the back end system, a lot of inefficiencies would be introduced (including duplicate connection pools, inability to efficiently handle inter-workspace operations like copying or cloning, difficulty managing sources when creating new workspaces, etc.).
> Therefore, to more closely match the JCR API and to more efficiently support inter-workspace operations (within the same repository), the DNA connector framework should have a notion of workspaces.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 17:37:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 17:37:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Work started: (DNA-282) Federation
 connector
 improperly handles root-level node with one projection of a non-root node
 from a single source
In-Reply-To: <33025480.1234478264160.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31469380.1234478264206.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Work on DNA-282 started by Randall Hauch.

> Federation connector improperly handles root-level node with one projection of a non-root node from a single source
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-282
>                 URL: https://jira.jboss.org/jira/browse/DNA-282
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>
> The federation connector currently has a problem when configured to project a non-root node from a single source into the root node of the federated repository.  The cache always has a root node with a specific UUID, and the single source's non-root node has a different UUID, so when the federation connector attempts to project that non-root node from the source into the root node of the federated repository, the cache is unable to store the node with the UUID from the source.
> This problem arose when working on DNA-281 - the test cases were changed to use the InMemory connector rather than the SimpleRepositorySource connector (used for testing only).  The simple implementation didn't maintain UUIDs, whereas the in-memory implementation does.  (This is one of the problems with using a "mock" or non-production implementation in tests.)
> So, although the code compiles, several of the federation connector's tests fail, and the problem also affects several of the JCR unit tests and the Getting Started repository example.  Therefore, after these are fixed, the corresponding projects need to be added back into the POM 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  Thu Feb 12 17:37:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 17:37:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-282) Federation connector
 improperly
 handles root-level node with one projection of a non-root node from a
 single source
Message-ID: <33025480.1234478264160.JavaMail.jira@cloud.prod.atl2.jboss.com>

Federation connector improperly handles root-level node with one projection of a non-root node from a single source
-------------------------------------------------------------------------------------------------------------------

                 Key: DNA-282
                 URL: https://jira.jboss.org/jira/browse/DNA-282
             Project: DNA
          Issue Type: Bug
          Components: Connectors
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Blocker


The federation connector currently has a problem when configured to project a non-root node from a single source into the root node of the federated repository.  The cache always has a root node with a specific UUID, and the single source's non-root node has a different UUID, so when the federation connector attempts to project that non-root node from the source into the root node of the federated repository, the cache is unable to store the node with the UUID from the source.

This problem arose when working on DNA-281 - the test cases were changed to use the InMemory connector rather than the SimpleRepositorySource connector (used for testing only).  The simple implementation didn't maintain UUIDs, whereas the in-memory implementation does.  (This is one of the problems with using a "mock" or non-production implementation in tests.)

So, although the code compiles, several of the federation connector's tests fail, and the problem also affects several of the JCR unit tests and the Getting Started repository example.  Therefore, after these are fixed, the corresponding projects need to be added back into the POM 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  Thu Feb 12 17:51:54 2009
From: jira-events at lists.jboss.org (Yaron Goldstein (JIRA))
Date: Thu, 12 Feb 2009 17:51:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
Message-ID: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>

fileSystemPaths property value is ignored for FileSystemSources configured through XML
--------------------------------------------------------------------------------------

                 Key: DNA-283
                 URL: https://jira.jboss.org/jira/browse/DNA-283
             Project: DNA
          Issue Type: Bug
          Components: Connectors
    Affects Versions: 0.4
            Reporter: Yaron Goldstein


The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 17:53:44 2009
From: jira-events at lists.jboss.org (Yaron Goldstein (JIRA))
Date: Thu, 12 Feb 2009 17:53:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <29236560.1234479224256.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Yaron Goldstein updated DNA-283:
--------------------------------

    Attachment: configRepository.xml


Sample configuration that defines a FileSystemSource and associated fileSystemPaths property.

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 17:53:45 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 17:53:45 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8428550.1234479225215.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-283:
------------------------------

    Fix Version/s: 0.4


> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 17:55:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 17:55:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4144294.1234479344146.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-283:
-----------------------------------

I suspect this is a problem with the code that uses reflection to call the setters on the RepositorySource instance.  This particular setter takes a String[] as an argument, and the reflection code probably doesn't handle arrays correctly (especially when there's only one value).

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 12 18:06:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 12 Feb 2009 18:06:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1520733.1234480004553.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-283:
-----------------------------------

Actually, I think the problem starts in the RepositoryService.createRepositorySource(...) method in the "dna-repository" projection.  The code (approximately line 290 of revision 723) calls the "isMultiple()" method on the Property to see if there are more than one value, and supplies an array to the reflection utility when there is multiple values.

This could be fixed one of two ways.  The first approach would be to catch the exception in "createRepositorySource(...)" and retry the reflection utility with an array of values.  Another approach would be to change the reflection utility (org.jboss.dna.common.util.Reflection in "dna-common") to support retrying any method signatures with an array in place of any single-valued parameter.  The former is probably the easiest, but the latter is probably the more correct way to do this.


> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 13 11:33:50 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 13 Feb 2009 11:33:50 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1907758.1234542830016.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-283:
------------------------------

    Attachment: dna-283.patch


Attached is a patch file that was applied to revision 723.  The patch contains a new method added to PropertyType to discover the property type given a Class parameter, and changes to RepositoryService to do a better job at figuring out how to convert the property values in the configuration repository into value(s) that are acceptable to the setter method.  This uses the value factories to do the conversion, so RepositoryService really only works with RepositorySource implementations that have property setters that accept any of our known/supported property types or primitives (or arrays of those property types or primitives).

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 13 11:45:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 13 Feb 2009 11:45:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16762503.1234543544215.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-283:
-----------------------------------

Updated the RepositorySource JavaDoc to better explain the kinds of Java properties that work best:

"Although any types can be used for these setters, other DNA components use reflection to set these properties and work best when the setters accept a single parameter that is a primitive, an array of primitives, a value compatible with PropertyType (e.g., Path, Name, URI, UUID, Reference, Binary, Long, Double, BigDecimal, DateTime, etc.), or an array of values that are compatible with PropertyType."

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 13 12:17:45 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 13 Feb 2009 12:17:45 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <6972309.1234545465259.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-283:
------------------------------

    Attachment: dna-283-version0.3.patch


Attached a version of this patch that can be applied to the 0.3 branch, although this patch won't be committed (since we don't currently release patches to releases issued before 1.0).

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283-version0.3.patch, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 13 12:27:45 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 13 Feb 2009 12:27:45 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13736919.1234546065193.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-283.
-------------------------------

    Resolution: Done


Marking as resolved, since this has been tested as being corrected.

@Yaron: if this still doesn't work for you, please reopen with the details.

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283-version0.3.patch, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 13 15:19:44 2009
From: jira-events at lists.jboss.org (Yaron Goldstein (JIRA))
Date: Fri, 13 Feb 2009 15:19:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Reopened: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27983475.1234556384295.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Yaron Goldstein reopened DNA-283:
---------------------------------



The dna-connector-filesystem tests no longer all pass.  The FileSystemConnectorCreateWorkspacesTest throws an error on shouldReturnListOfWorkspaceMatchingAbsoluteCanonicalPathsToDirectories() and the FileSystemSourceTest errors out on shouldCreateConnection() and shouldAllowMultipleConnectionsToBeOpenAtTheSameTime().

I also noticed that the dna-connector-filesystem module is not included in the main dna pom.  This may or may not be intentional for the current snapshot.

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283-version0.3.patch, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 13 16:59:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 13 Feb 2009 16:59:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21964719.1234562384246.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-283:
-----------------------------------

Thanks, Yaron.  Not sure what happened there.  The POM is now fixed, and the file system connector is fixed as well.  

But remember that the repository example in the Getting Started project does not currently run.  That's being fixed under DNA-282.

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283-version0.3.patch, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 13 18:51:44 2009
From: jira-events at lists.jboss.org (Yaron Goldstein (JIRA))
Date: Fri, 13 Feb 2009 18:51:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27900321.1234569104220.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Yaron Goldstein commented on DNA-283:
-------------------------------------

Thanks, Randall.  But it looks like the FileSystemConnectorCreateWorkspacesTest is still throwing an error on the shouldReturnListOfWorkspaceMatchingAbsoluteCanonicalPathsToDirectories() test.

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283-version0.3.patch, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 14 16:47:54 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 14 Feb 2009 16:47:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-284)
 FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
Message-ID: <31890504.1234648074761.JavaMail.jira@cloud.prod.atl2.jboss.com>

FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
-----------------------------------------------------------

                 Key: DNA-284
                 URL: https://jira.jboss.org/jira/browse/DNA-284
             Project: DNA
          Issue Type: Bug
    Affects Versions: 0.4
         Environment: Eclipse 3.4, JDK 1.6.0_12, Win XP
            Reporter: Brian Carothers
            Priority: Minor


When building from trunk and running "mvn install", the FileSystemConnectorCreateWorkspacesTest test fails.  Running in eclipse gives this stack trace:

java.lang.AssertionError: 
Expected: is <true>
     got: <false>

	at org.junit.Assert.assertThat(Assert.java:502)
	at org.junit.Assert.assertThat(Assert.java:492)
	at org.jboss.dna.connector.filesystem.FileSystemConnectorCreateWorkspacesTest.shouldReturnListOfWorkspacesMatchingAbsoluteCanonicalPathsToDirectories(FileSystemConnectorCreateWorkspacesTest.java:105)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
	at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
	at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
	at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
	at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
	at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
	at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
	at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
	at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
	at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
	at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
	at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)






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

        


From jira-events at lists.jboss.org  Sat Feb 14 16:53:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 14 Feb 2009 16:53:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-284)
 FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
In-Reply-To: <31890504.1234648074761.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11359751.1234648424142.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-284:
--------------------------------

    Attachment: DNA-284.patch


Patch that makes test not use Unix-specific separator chars.  This seems to be the intent based on the existing usage of getCanonicalPath.

> FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
> -----------------------------------------------------------
>
>                 Key: DNA-284
>                 URL: https://jira.jboss.org/jira/browse/DNA-284
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>         Environment: Eclipse 3.4, JDK 1.6.0_12, Win XP
>            Reporter: Brian Carothers
>            Priority: Minor
>         Attachments: DNA-284.patch
>
>
> When building from trunk and running "mvn install", the FileSystemConnectorCreateWorkspacesTest test fails.  Running in eclipse gives this stack trace:
> java.lang.AssertionError: 
> Expected: is <true>
>      got: <false>
> 	at org.junit.Assert.assertThat(Assert.java:502)
> 	at org.junit.Assert.assertThat(Assert.java:492)
> 	at org.jboss.dna.connector.filesystem.FileSystemConnectorCreateWorkspacesTest.shouldReturnListOfWorkspacesMatchingAbsoluteCanonicalPathsToDirectories(FileSystemConnectorCreateWorkspacesTest.java:105)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> 	at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> 	at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> 	at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> 	at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> 	at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> 	at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> 	at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> 	at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> 	at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> 	at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> 	at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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

        


From jira-events at lists.jboss.org  Sat Feb 14 17:46:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sat, 14 Feb 2009 17:46:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13518583.1234651604215.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers commented on DNA-283:
-------------------------------------

If you're on windows, please see https://jira.jboss.org/jira/browse/DNA-283.  Apologies in advance if I created a duplicate bug.

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283-version0.3.patch, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 15 21:17:46 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Sun, 15 Feb 2009 21:17:46 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-253) Add support in the
 JBoss Cache connector for JBoss Cache 3.0.
In-Reply-To: <27426591.1227146796418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <23862235.1234750666205.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-253:
--------------------------------

    Attachment: pom.xml.patch


It would appear that DNA doesn't use any of the deprecated methods.  Attached a trivial patch to the POM for dna-connector-jbosscache to update the version.

> Add support in the JBoss Cache connector for JBoss Cache 3.0. 
> --------------------------------------------------------------
>
>                 Key: DNA-253
>                 URL: https://jira.jboss.org/jira/browse/DNA-253
>             Project: DNA
>          Issue Type: Thirdparty Change
>          Components: Connectors
>            Reporter: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: pom.xml.patch
>
>
> JBoss Cache 3.0.0.GA is available (as of Nov 19, 2008), so we should add support for using it in DNA's JBoss Cache connector.  The connector is currently using 2.2.1.GA.  3.0.0.GA is supposed to be API compatible with 2.2.1.GA, but there are some deprecated methods and a new configuration format.  Hopefully we're not using any deprecated methods, and the connector does almost no configuration (instead, it assumes that any cache that requires connfiguration will be placed inside JNDI, or the name of the configuration will be referenced by the JBossCacheSource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 16 11:38:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 16 Feb 2009 11:38:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-284)
 FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
In-Reply-To: <31890504.1234648074761.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25987495.1234802324356.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-284.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Applied patch, verifying that the tests still pass on OS X and Linux.  We'll close this issue if confirmed that the patch fixes the issue on Windows (or reopen it if the fix does not correct the issue).

> FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
> -----------------------------------------------------------
>
>                 Key: DNA-284
>                 URL: https://jira.jboss.org/jira/browse/DNA-284
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>         Environment: Eclipse 3.4, JDK 1.6.0_12, Win XP
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>            Priority: Minor
>         Attachments: DNA-284.patch
>
>
> When building from trunk and running "mvn install", the FileSystemConnectorCreateWorkspacesTest test fails.  Running in eclipse gives this stack trace:
> java.lang.AssertionError: 
> Expected: is <true>
>      got: <false>
> 	at org.junit.Assert.assertThat(Assert.java:502)
> 	at org.junit.Assert.assertThat(Assert.java:492)
> 	at org.jboss.dna.connector.filesystem.FileSystemConnectorCreateWorkspacesTest.shouldReturnListOfWorkspacesMatchingAbsoluteCanonicalPathsToDirectories(FileSystemConnectorCreateWorkspacesTest.java:105)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> 	at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> 	at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> 	at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> 	at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> 	at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> 	at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> 	at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> 	at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> 	at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> 	at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> 	at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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

        


From jira-events at lists.jboss.org  Mon Feb 16 11:40:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 16 Feb 2009 11:40:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <18110683.1234802444280.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-283:
-----------------------------------

The patch (thanks Brian!) for DNA-284 has been applied.  Hopefully that was the issue for this.  Please reply with feedback.

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283-version0.3.patch, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 16 12:22:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 16 Feb 2009 12:22:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-253) Add support in the
 JBoss Cache connector for JBoss Cache 3.0.
In-Reply-To: <27426591.1227146796418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31293420.1234804964879.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-253.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Applied the patch (thanks, Brian!), and verified that the build completes and all tests pass.

> Add support in the JBoss Cache connector for JBoss Cache 3.0. 
> --------------------------------------------------------------
>
>                 Key: DNA-253
>                 URL: https://jira.jboss.org/jira/browse/DNA-253
>             Project: DNA
>          Issue Type: Thirdparty Change
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: pom.xml.patch
>
>
> JBoss Cache 3.0.0.GA is available (as of Nov 19, 2008), so we should add support for using it in DNA's JBoss Cache connector.  The connector is currently using 2.2.1.GA.  3.0.0.GA is supposed to be API compatible with 2.2.1.GA, but there are some deprecated methods and a new configuration format.  Hopefully we're not using any deprecated methods, and the connector does almost no configuration (instead, it assumes that any cache that requires connfiguration will be placed inside JNDI, or the name of the configuration will be referenced by the JBossCacheSource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 16 13:53:54 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 16 Feb 2009 13:53:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-284)
 FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
In-Reply-To: <31890504.1234648074761.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2527147.1234810434939.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers commented on DNA-284:
-------------------------------------

Not sure if I can verify my own patch, but the latest code does pass all tests on my Windows machine.

> FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
> -----------------------------------------------------------
>
>                 Key: DNA-284
>                 URL: https://jira.jboss.org/jira/browse/DNA-284
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>         Environment: Eclipse 3.4, JDK 1.6.0_12, Win XP
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>            Priority: Minor
>         Attachments: DNA-284.patch
>
>
> When building from trunk and running "mvn install", the FileSystemConnectorCreateWorkspacesTest test fails.  Running in eclipse gives this stack trace:
> java.lang.AssertionError: 
> Expected: is <true>
>      got: <false>
> 	at org.junit.Assert.assertThat(Assert.java:502)
> 	at org.junit.Assert.assertThat(Assert.java:492)
> 	at org.jboss.dna.connector.filesystem.FileSystemConnectorCreateWorkspacesTest.shouldReturnListOfWorkspacesMatchingAbsoluteCanonicalPathsToDirectories(FileSystemConnectorCreateWorkspacesTest.java:105)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> 	at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> 	at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> 	at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> 	at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> 	at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> 	at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> 	at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> 	at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> 	at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> 	at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> 	at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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

        


From jira-events at lists.jboss.org  Mon Feb 16 14:09:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 16 Feb 2009 14:09:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-153) Add support for
 Microsoft Word document metadata
In-Reply-To: <1572733.1213651353317.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14523484.1234811384207.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-153:
--------------------------------

    Attachment: Upgrade_POI_to_Latest.patch


Upgrades POI to the latest version (3.0.2).  The behavior of ExcelExtractor changed with this minor release (it now outputs style information when extracting all text), so I modified the ExcelMetadataReader to implement the old behavior instead.

> Add support for Microsoft Word document metadata
> ------------------------------------------------
>
>                 Key: DNA-153
>                 URL: https://jira.jboss.org/jira/browse/DNA-153
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Sequencers
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: Upgrade_POI_to_Latest.patch
>
>


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

        


From jira-events at lists.jboss.org  Mon Feb 16 14:11:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 16 Feb 2009 14:11:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-153) Add support for
 Microsoft Word document metadata
In-Reply-To: <1572733.1213651353317.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24312173.1234811504283.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-153:
--------------------------------

    Attachment: Extract_Word_Headers.patch


POI doesn't yet seem to support a clean way of extracting tables of contents, figures, captions, etc., so I wrote a snippet to infer the table of contents from paragraphs with heading styles.  This matches Word's own default way of building the table of contents.  

> Add support for Microsoft Word document metadata
> ------------------------------------------------
>
>                 Key: DNA-153
>                 URL: https://jira.jboss.org/jira/browse/DNA-153
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Sequencers
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: Extract_Word_Headers.patch, Upgrade_POI_to_Latest.patch
>
>


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

        


From jira-events at lists.jboss.org  Mon Feb 16 14:28:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 16 Feb 2009 14:28:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Closed: (DNA-284)
 FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
In-Reply-To: <31890504.1234648074761.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21371655.1234812524291.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch closed DNA-284.
-----------------------------



Marking as closed, since Brian reports the problem has been fixed.

> FileSystemConnectorCreateWorkspacesTest Fails on Windows XP
> -----------------------------------------------------------
>
>                 Key: DNA-284
>                 URL: https://jira.jboss.org/jira/browse/DNA-284
>             Project: DNA
>          Issue Type: Bug
>    Affects Versions: 0.4
>         Environment: Eclipse 3.4, JDK 1.6.0_12, Win XP
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>            Priority: Minor
>         Attachments: DNA-284.patch
>
>
> When building from trunk and running "mvn install", the FileSystemConnectorCreateWorkspacesTest test fails.  Running in eclipse gives this stack trace:
> java.lang.AssertionError: 
> Expected: is <true>
>      got: <false>
> 	at org.junit.Assert.assertThat(Assert.java:502)
> 	at org.junit.Assert.assertThat(Assert.java:492)
> 	at org.jboss.dna.connector.filesystem.FileSystemConnectorCreateWorkspacesTest.shouldReturnListOfWorkspacesMatchingAbsoluteCanonicalPathsToDirectories(FileSystemConnectorCreateWorkspacesTest.java:105)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
> 	at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
> 	at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
> 	at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
> 	at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
> 	at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
> 	at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
> 	at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
> 	at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
> 	at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
> 	at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
> 	at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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

        


From jira-events at lists.jboss.org  Mon Feb 16 15:39:44 2009
From: jira-events at lists.jboss.org (Yaron Goldstein (JIRA))
Date: Mon, 16 Feb 2009 15:39:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26277275.1234816784219.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Yaron Goldstein commented on DNA-283:
-------------------------------------

The patch for https://jira.jboss.org/jira/browse/DNA-284 did resolve the build issue.   Thanks!


> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283-version0.3.patch, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 16 15:46:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 16 Feb 2009 15:46:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-283) fileSystemPaths
 property value is
 ignored for FileSystemSources configured through XML
In-Reply-To: <19234843.1234479114339.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25562785.1234817204555.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-283.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Marking as resolved, per Yaron's previous comment.  (Thanks, Yaron!)

> fileSystemPaths property value is ignored for FileSystemSources configured through XML
> --------------------------------------------------------------------------------------
>
>                 Key: DNA-283
>                 URL: https://jira.jboss.org/jira/browse/DNA-283
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.4
>            Reporter: Yaron Goldstein
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: configRepository.xml, dna-283-version0.3.patch, dna-283.patch
>
>
> The fileSystemPaths property value is ignored for FileSystemSources configured through XML.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 18 18:34:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 18 Feb 2009 18:34:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-88) Incorporate JCR TCK
	tests
In-Reply-To: <19085088.1212431722162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2254280.1235000084164.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-88:
-------------------------------

    Attachment: DNA-88.patch


Implemented test wrapper as described in first comment.  Added test suite to only run JCR Level 1 tests for now.

> Incorporate JCR TCK tests
> -------------------------
>
>                 Key: DNA-88
>                 URL: https://jira.jboss.org/jira/browse/DNA-88
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-88.patch
>
>


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

        


From jira-events at lists.jboss.org  Wed Feb 18 22:27:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 18 Feb 2009 22:27:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-280) Create optimized
 versions of Location
In-Reply-To: <32312719.1233198044147.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2728465.1235014064271.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-280:
--------------------------------

    Attachment: DNA-280.patch


Workspace-based patch that implements option #2 as described above.

> Create optimized versions of Location
> -------------------------------------
>
>                 Key: DNA-280
>                 URL: https://jira.jboss.org/jira/browse/DNA-280
>             Project: DNA
>          Issue Type: Task
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-280.patch
>
>
> The Graph API uses the Location class to represent the location (path and/or identification properties) of a node.  So far, we haven't needed different implementations, but given that the current class has a number of optional member attributes and we'd like to add more, it is probably prudent to have different implementations that more optimally represent the combination of attributes that's possible.
> Currently, there are quite a few constructors and they are called in numerous places.  However, every place that one is created, an ExecutionContext is available.  Therefore, it seems like there are (at least) two valid approaches:
> 1) Change Location to an interface, create multiple implementation classes, define and implement a LocationFactory that instantiates the most appropriate implementation class, and add getLocationFactory() to the ExecutionContext.  This approach mirrors the way that the properties and value types are created, but Location objects are not used as property values.  It would even be possible to add a "with(LocationFactory)" method to ExecutionContext so that one can clone a context but specify the implementation of the LocationFactory that the clone should use.
> 2) Keep Location as an abstract class, but remove the constructors and replace with static factory methods.  This would likely mean that there is a single set of implementations that never need to be customized.  It also means that we could add methods that could return a new location with additional attributes set.  For example:
>         Location newLocation = location.with(uuid);
> Either way, we need to change the current implementation to be more flexible.  I think the choice comes down to whether it's appropriate to be consistent with the factory-style approach used by property values, or whether Location is different enough and we know we'll only have a single family of implementations that don't need to be extended or customized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 20 10:40:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Feb 2009 10:40:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-282) Federation connector
 improperly
 handles root-level node with one projection of a non-root node from a
 single source
In-Reply-To: <33025480.1234478264160.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28571203.1235144444510.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-282:
------------------------------

    Fix Version/s: 0.4


> Federation connector improperly handles root-level node with one projection of a non-root node from a single source
> -------------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-282
>                 URL: https://jira.jboss.org/jira/browse/DNA-282
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.4
>
>
> The federation connector currently has a problem when configured to project a non-root node from a single source into the root node of the federated repository.  The cache always has a root node with a specific UUID, and the single source's non-root node has a different UUID, so when the federation connector attempts to project that non-root node from the source into the root node of the federated repository, the cache is unable to store the node with the UUID from the source.
> This problem arose when working on DNA-281 - the test cases were changed to use the InMemory connector rather than the SimpleRepositorySource connector (used for testing only).  The simple implementation didn't maintain UUIDs, whereas the in-memory implementation does.  (This is one of the problems with using a "mock" or non-production implementation in tests.)
> So, although the code compiles, several of the federation connector's tests fail, and the problem also affects several of the JCR unit tests and the Getting Started repository example.  Therefore, after these are fixed, the corresponding projects need to be added back into the POM 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  Fri Feb 20 11:21:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Feb 2009 11:21:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-280) Create optimized
 versions of Location
In-Reply-To: <32312719.1233198044147.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <28133081.1235146904325.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-280:
-----------------------------------

Applied the patch.  (Nicely done, BTW.)

> Create optimized versions of Location
> -------------------------------------
>
>                 Key: DNA-280
>                 URL: https://jira.jboss.org/jira/browse/DNA-280
>             Project: DNA
>          Issue Type: Task
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-280.patch
>
>
> The Graph API uses the Location class to represent the location (path and/or identification properties) of a node.  So far, we haven't needed different implementations, but given that the current class has a number of optional member attributes and we'd like to add more, it is probably prudent to have different implementations that more optimally represent the combination of attributes that's possible.
> Currently, there are quite a few constructors and they are called in numerous places.  However, every place that one is created, an ExecutionContext is available.  Therefore, it seems like there are (at least) two valid approaches:
> 1) Change Location to an interface, create multiple implementation classes, define and implement a LocationFactory that instantiates the most appropriate implementation class, and add getLocationFactory() to the ExecutionContext.  This approach mirrors the way that the properties and value types are created, but Location objects are not used as property values.  It would even be possible to add a "with(LocationFactory)" method to ExecutionContext so that one can clone a context but specify the implementation of the LocationFactory that the clone should use.
> 2) Keep Location as an abstract class, but remove the constructors and replace with static factory methods.  This would likely mean that there is a single set of implementations that never need to be customized.  It also means that we could add methods that could return a new location with additional attributes set.  For example:
>         Location newLocation = location.with(uuid);
> Either way, we need to change the current implementation to be more flexible.  I think the choice comes down to whether it's appropriate to be consistent with the factory-style approach used by property values, or whether Location is different enough and we know we'll only have a single family of implementations that don't need to be extended or customized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 20 11:55:47 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Feb 2009 11:55:47 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-88) Incorporate JCR TCK
	tests
In-Reply-To: <19085088.1212431722162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20151408.1235148947595.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reassigned DNA-88:
--------------------------------

    Assignee: Randall Hauch


> Incorporate JCR TCK tests
> -------------------------
>
>                 Key: DNA-88
>                 URL: https://jira.jboss.org/jira/browse/DNA-88
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-88.patch
>
>


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

        


From jira-events at lists.jboss.org  Fri Feb 20 11:55:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Feb 2009 11:55:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-285) Pass all Level 1 TCK
	unit tests
Message-ID: <18642947.1235148944956.JavaMail.jira@cloud.prod.atl2.jboss.com>

Pass all Level 1 TCK unit tests
-------------------------------

                 Key: DNA-285
                 URL: https://jira.jboss.org/jira/browse/DNA-285
             Project: DNA
          Issue Type: Sub-task
            Reporter: Randall Hauch




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 20 12:07:56 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Feb 2009 12:07:56 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-285) Pass all Level 1 TCK
	unit tests
In-Reply-To: <18642947.1235148944956.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15087258.1235149676792.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-285:
------------------------------

    Description: We don't currently pass all of the Level 1 TCK unit tests.  See dna-jcr/src/test/java/org/jboss/dna/jcr/JackrabbitJcrTckTest.java, and specifically the JcrLevelOneTestSuite nested class.


> Pass all Level 1 TCK unit tests
> -------------------------------
>
>                 Key: DNA-285
>                 URL: https://jira.jboss.org/jira/browse/DNA-285
>             Project: DNA
>          Issue Type: Sub-task
>            Reporter: Randall Hauch
>
> We don't currently pass all of the Level 1 TCK unit tests.  See dna-jcr/src/test/java/org/jboss/dna/jcr/JackrabbitJcrTckTest.java, and specifically the JcrLevelOneTestSuite nested class.

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

        


From jira-events at lists.jboss.org  Fri Feb 20 12:09:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Feb 2009 12:09:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-88) Incorporate JCR TCK
	tests
In-Reply-To: <19085088.1212431722162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <3468777.1235149784263.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-88:
----------------------------------

Applied the patch that added the TCK unit tests to our unit tests.  We don't pass many of the Level 1 tests, so I commented out those tests that we don't currently pass.  I also created DNA-285 to capture that we want to uncomment these and pass all Level 1 unit tests.

> Incorporate JCR TCK tests
> -------------------------
>
>                 Key: DNA-88
>                 URL: https://jira.jboss.org/jira/browse/DNA-88
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-88.patch
>
>


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

        


From jira-events at lists.jboss.org  Fri Feb 20 12:11:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 20 Feb 2009 12:11:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-88) Incorporate JCR TCK
	tests
In-Reply-To: <19085088.1212431722162.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21908078.1235149904253.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-88.
------------------------------

    Resolution: Done


Created DNA-285 to capture the fact that we don't pass all of these tests yet.  But this issue is complete.

> Incorporate JCR TCK tests
> -------------------------
>
>                 Key: DNA-88
>                 URL: https://jira.jboss.org/jira/browse/DNA-88
>             Project: DNA
>          Issue Type: Sub-task
>          Components: JCR
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-88.patch
>
>


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

        


From jira-events at lists.jboss.org  Fri Feb 20 14:45:47 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 20 Feb 2009 14:45:47 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-280) Create optimized
 versions of Location
In-Reply-To: <32312719.1233198044147.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19508318.1235159147075.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-280:
--------------------------------

    Attachment: DNA-280-abstract.patch


Refactored Location into abstract class with one generic concrete subclass (PathPropertiesLocation) and two specific concrete subclasses per IRC discussion.  Added test case for Location.

> Create optimized versions of Location
> -------------------------------------
>
>                 Key: DNA-280
>                 URL: https://jira.jboss.org/jira/browse/DNA-280
>             Project: DNA
>          Issue Type: Task
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-280-abstract.patch, DNA-280.patch
>
>
> The Graph API uses the Location class to represent the location (path and/or identification properties) of a node.  So far, we haven't needed different implementations, but given that the current class has a number of optional member attributes and we'd like to add more, it is probably prudent to have different implementations that more optimally represent the combination of attributes that's possible.
> Currently, there are quite a few constructors and they are called in numerous places.  However, every place that one is created, an ExecutionContext is available.  Therefore, it seems like there are (at least) two valid approaches:
> 1) Change Location to an interface, create multiple implementation classes, define and implement a LocationFactory that instantiates the most appropriate implementation class, and add getLocationFactory() to the ExecutionContext.  This approach mirrors the way that the properties and value types are created, but Location objects are not used as property values.  It would even be possible to add a "with(LocationFactory)" method to ExecutionContext so that one can clone a context but specify the implementation of the LocationFactory that the clone should use.
> 2) Keep Location as an abstract class, but remove the constructors and replace with static factory methods.  This would likely mean that there is a single set of implementations that never need to be customized.  It also means that we could add methods that could return a new location with additional attributes set.  For example:
>         Location newLocation = location.with(uuid);
> Either way, we need to change the current implementation to be more flexible.  I think the choice comes down to whether it's appropriate to be consistent with the factory-style approach used by property values, or whether Location is different enough and we know we'll only have a single family of implementations that don't need to be extended or customized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 23 10:56:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Feb 2009 10:56:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-280) Create optimized
 versions of Location
In-Reply-To: <32312719.1233198044147.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20004257.1235404604827.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-280:
-----------------------------------

Applied the patch to add different Location implementations, specialized for the more frequent use cases.

> Create optimized versions of Location
> -------------------------------------
>
>                 Key: DNA-280
>                 URL: https://jira.jboss.org/jira/browse/DNA-280
>             Project: DNA
>          Issue Type: Task
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-280-abstract.patch, DNA-280.patch
>
>
> The Graph API uses the Location class to represent the location (path and/or identification properties) of a node.  So far, we haven't needed different implementations, but given that the current class has a number of optional member attributes and we'd like to add more, it is probably prudent to have different implementations that more optimally represent the combination of attributes that's possible.
> Currently, there are quite a few constructors and they are called in numerous places.  However, every place that one is created, an ExecutionContext is available.  Therefore, it seems like there are (at least) two valid approaches:
> 1) Change Location to an interface, create multiple implementation classes, define and implement a LocationFactory that instantiates the most appropriate implementation class, and add getLocationFactory() to the ExecutionContext.  This approach mirrors the way that the properties and value types are created, but Location objects are not used as property values.  It would even be possible to add a "with(LocationFactory)" method to ExecutionContext so that one can clone a context but specify the implementation of the LocationFactory that the clone should use.
> 2) Keep Location as an abstract class, but remove the constructors and replace with static factory methods.  This would likely mean that there is a single set of implementations that never need to be customized.  It also means that we could add methods that could return a new location with additional attributes set.  For example:
>         Location newLocation = location.with(uuid);
> Either way, we need to change the current implementation to be more flexible.  I think the choice comes down to whether it's appropriate to be consistent with the factory-style approach used by property values, or whether Location is different enough and we know we'll only have a single family of implementations that don't need to be extended or customized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 23 12:57:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Feb 2009 12:57:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-280) Create optimized
 versions of Location
In-Reply-To: <32312719.1233198044147.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <8020539.1235411864485.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-280:
-----------------------------------

Minor changes and improvements, including removal of duplicate CheckArg method calls.  Renamed *Location classes to Location* to follow some other naming patterns ("convention" is too harsh).  Also added LocationWithUuid, since we'll have a lot of Location objects that have only the UUID (not nearly as much as path+uuid, which is covered by LocationWithPathAndProperty).

> Create optimized versions of Location
> -------------------------------------
>
>                 Key: DNA-280
>                 URL: https://jira.jboss.org/jira/browse/DNA-280
>             Project: DNA
>          Issue Type: Task
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-280-abstract.patch, DNA-280.patch
>
>
> The Graph API uses the Location class to represent the location (path and/or identification properties) of a node.  So far, we haven't needed different implementations, but given that the current class has a number of optional member attributes and we'd like to add more, it is probably prudent to have different implementations that more optimally represent the combination of attributes that's possible.
> Currently, there are quite a few constructors and they are called in numerous places.  However, every place that one is created, an ExecutionContext is available.  Therefore, it seems like there are (at least) two valid approaches:
> 1) Change Location to an interface, create multiple implementation classes, define and implement a LocationFactory that instantiates the most appropriate implementation class, and add getLocationFactory() to the ExecutionContext.  This approach mirrors the way that the properties and value types are created, but Location objects are not used as property values.  It would even be possible to add a "with(LocationFactory)" method to ExecutionContext so that one can clone a context but specify the implementation of the LocationFactory that the clone should use.
> 2) Keep Location as an abstract class, but remove the constructors and replace with static factory methods.  This would likely mean that there is a single set of implementations that never need to be customized.  It also means that we could add methods that could return a new location with additional attributes set.  For example:
>         Location newLocation = location.with(uuid);
> Either way, we need to change the current implementation to be more flexible.  I think the choice comes down to whether it's appropriate to be consistent with the factory-style approach used by property values, or whether Location is different enough and we know we'll only have a single family of implementations that don't need to be extended or customized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 23 13:01:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Feb 2009 13:01:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-280) Create optimized
 versions of Location
In-Reply-To: <32312719.1233198044147.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1985548.1235412104988.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-280.
-------------------------------

    Resolution: Done


Marking as resolved.  Any new Location implementations will be handled as separate issues.

> Create optimized versions of Location
> -------------------------------------
>
>                 Key: DNA-280
>                 URL: https://jira.jboss.org/jira/browse/DNA-280
>             Project: DNA
>          Issue Type: Task
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: DNA-280-abstract.patch, DNA-280.patch
>
>
> The Graph API uses the Location class to represent the location (path and/or identification properties) of a node.  So far, we haven't needed different implementations, but given that the current class has a number of optional member attributes and we'd like to add more, it is probably prudent to have different implementations that more optimally represent the combination of attributes that's possible.
> Currently, there are quite a few constructors and they are called in numerous places.  However, every place that one is created, an ExecutionContext is available.  Therefore, it seems like there are (at least) two valid approaches:
> 1) Change Location to an interface, create multiple implementation classes, define and implement a LocationFactory that instantiates the most appropriate implementation class, and add getLocationFactory() to the ExecutionContext.  This approach mirrors the way that the properties and value types are created, but Location objects are not used as property values.  It would even be possible to add a "with(LocationFactory)" method to ExecutionContext so that one can clone a context but specify the implementation of the LocationFactory that the clone should use.
> 2) Keep Location as an abstract class, but remove the constructors and replace with static factory methods.  This would likely mean that there is a single set of implementations that never need to be customized.  It also means that we could add methods that could return a new location with additional attributes set.  For example:
>         Location newLocation = location.with(uuid);
> Either way, we need to change the current implementation to be more flexible.  I think the choice comes down to whether it's appropriate to be consistent with the factory-style approach used by property values, or whether Location is different enough and we know we'll only have a single family of implementations that don't need to be extended or customized.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 23 13:27:54 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Feb 2009 13:27:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-153) Add support for
 Microsoft Word document metadata
In-Reply-To: <1572733.1213651353317.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26416393.1235413674348.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-153:
-----------------------------------

Applied the "Upgrade_POI_to_Latest" patch (see attachments), which looks good.  Uploaded "org.apache.poi:poi:3.2-FINAL" and "org.apache.poi:poi-scratchpad:3.2-FINAL" artifacts to the JBoss Maven 2 repository.

> Add support for Microsoft Word document metadata
> ------------------------------------------------
>
>                 Key: DNA-153
>                 URL: https://jira.jboss.org/jira/browse/DNA-153
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Sequencers
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: Extract_Word_Headers.patch, Upgrade_POI_to_Latest.patch
>
>


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

        


From jira-events at lists.jboss.org  Mon Feb 23 13:37:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 23 Feb 2009 13:37:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-153) Add support for
 Microsoft Word document metadata
In-Reply-To: <1572733.1213651353317.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25052399.1235414264173.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-153:
--------------------------------

    Attachment: word.doc


Updated word doc for unit test.

> Add support for Microsoft Word document metadata
> ------------------------------------------------
>
>                 Key: DNA-153
>                 URL: https://jira.jboss.org/jira/browse/DNA-153
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Sequencers
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: Extract_Word_Headers.patch, Upgrade_POI_to_Latest.patch, word.doc
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 23 13:55:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Feb 2009 13:55:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-153) Add support for
 Microsoft Word document metadata
In-Reply-To: <1572733.1213651353317.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12608534.1235415344298.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-153:
-----------------------------------

Applied the "Extract_Word_Headers" patch and copied the new "word.doc" file into the "src/test/resources" folder (see attachments).  Looks good; all tests now pass.

> Add support for Microsoft Word document metadata
> ------------------------------------------------
>
>                 Key: DNA-153
>                 URL: https://jira.jboss.org/jira/browse/DNA-153
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Sequencers
>            Reporter: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: Extract_Word_Headers.patch, Upgrade_POI_to_Latest.patch, word.doc
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 23 13:55:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Feb 2009 13:55:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-153) Add support for
 Microsoft Word document metadata
In-Reply-To: <1572733.1213651353317.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21777894.1235415344397.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-153.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


Marking as resolved, since this captures the original intent of the issue.  Any additional features or problems can be handled as other issues.

> Add support for Microsoft Word document metadata
> ------------------------------------------------
>
>                 Key: DNA-153
>                 URL: https://jira.jboss.org/jira/browse/DNA-153
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Sequencers
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.5
>
>         Attachments: Extract_Word_Headers.patch, Upgrade_POI_to_Latest.patch, word.doc
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 23 14:21:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Mon, 23 Feb 2009 14:21:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-91) Implement node type
	management
In-Reply-To: <33272333.1212431842222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7800595.1235416904235.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

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

    Attachment: DNA-91_Prelim.patch


Preliminary patch that supports basic type operations and transient namespace remapping (more or less).  Does not support anything with item definitions.

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


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

        


From jira-events at lists.jboss.org  Mon Feb 23 14:27:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 23 Feb 2009 14:27:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-114) Create Microsoft
 Office file sequencer
In-Reply-To: <2691642.1213110675980.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <30572608.1235417264224.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-114.
-------------------------------

    Resolution: Done


Marking as resolved, since all subtasks were completed.  Any additional features or bugs should be addressed through separate issues.

> Create Microsoft Office file sequencer
> --------------------------------------
>
>                 Key: DNA-114
>                 URL: https://jira.jboss.org/jira/browse/DNA-114
>             Project: DNA
>          Issue Type: Task
>          Components: Sequencers
>            Reporter: Randall Hauch
>            Assignee: Michael Trezzi
>             Fix For: 0.5
>
>         Attachments: dna-sequencer-msoffice.zip
>
>
> Create a single sequencer that is capable of sequencing the Microsoft Office files, including Microsoft Word, Microsoft Excel, and Microsoft PowerPoint.  All of the files' standard metadata (author, title, word count, page count, etc.) should be extracted, as should metadata specific to the different kinds of files.  For example, the sequencer should extract all of the content of the Microsoft Excel spreadsheets, while it should extract at least the slide titles (and ideally thumbnails).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 24 09:37:54 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Feb 2009 09:37:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Reopened: (DNA-253) Add support in the
 JBoss Cache connector for JBoss Cache 3.0.
In-Reply-To: <27426591.1227146796418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <25512543.1235486274921.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reopened DNA-253:
-------------------------------



JBoss Cache 3.0.3.GA was just released.

> Add support in the JBoss Cache connector for JBoss Cache 3.0. 
> --------------------------------------------------------------
>
>                 Key: DNA-253
>                 URL: https://jira.jboss.org/jira/browse/DNA-253
>             Project: DNA
>          Issue Type: Thirdparty Change
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: pom.xml.patch
>
>
> JBoss Cache 3.0.0.GA is available (as of Nov 19, 2008), so we should add support for using it in DNA's JBoss Cache connector.  The connector is currently using 2.2.1.GA.  3.0.0.GA is supposed to be API compatible with 2.2.1.GA, but there are some deprecated methods and a new configuration format.  Hopefully we're not using any deprecated methods, and the connector does almost no configuration (instead, it assumes that any cache that requires connfiguration will be placed inside JNDI, or the name of the configuration will be referenced by the JBossCacheSource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 24 09:40:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 24 Feb 2009 09:40:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-253) Add support in the
 JBoss Cache connector for JBoss Cache 3.0.
In-Reply-To: <27426591.1227146796418.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19872914.1235486444156.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-253.
-------------------------------

    Resolution: Done


Updated to JBoss Cache 3.0.3.GA (just released today).

> Add support in the JBoss Cache connector for JBoss Cache 3.0. 
> --------------------------------------------------------------
>
>                 Key: DNA-253
>                 URL: https://jira.jboss.org/jira/browse/DNA-253
>             Project: DNA
>          Issue Type: Thirdparty Change
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: pom.xml.patch
>
>
> JBoss Cache 3.0.0.GA is available (as of Nov 19, 2008), so we should add support for using it in DNA's JBoss Cache connector.  The connector is currently using 2.2.1.GA.  3.0.0.GA is supposed to be API compatible with 2.2.1.GA, but there are some deprecated methods and a new configuration format.  Hopefully we're not using any deprecated methods, and the connector does almost no configuration (instead, it assumes that any cache that requires connfiguration will be placed inside JNDI, or the name of the configuration will be referenced by the JBossCacheSource.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 25 07:28:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 25 Feb 2009 07:28:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-91) Implement node type
	management
In-Reply-To: <33272333.1212431842222.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27741505.1235564924163.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

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

    Attachment: DNA-91_With_Builtins.patch


Second version of patch (still not final) that provides built-in types, canRemoveItem, canSetProperty, and fixes some bugs in the first patch.

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


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

        


From jira-events at lists.jboss.org  Wed Feb 25 18:17:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 25 Feb 2009 18:17:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-286) Implement namespace
	management
Message-ID: <23913041.1235603864149.JavaMail.jira@cloud.prod.atl2.jboss.com>

Implement namespace management
------------------------------

                 Key: DNA-286
                 URL: https://jira.jboss.org/jira/browse/DNA-286
             Project: DNA
          Issue Type: Sub-task
            Reporter: Randall Hauch
            Assignee: Randall Hauch




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Feb 25 18:22:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 25 Feb 2009 18:22:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-286) Implement namespace
	management
In-Reply-To: <23913041.1235603864149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2614982.1235604164171.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-286:
------------------------------

          Component/s: API
                       JCR
        Fix Version/s: 0.4
    Affects Version/s: 0.3
          Description: Our JCR implementation needs a namespace registry that stores the namespaces and their prefixes in such a way that they can be clustered.  The best approach is probably to store the namespaces under "/jcr:system/" in a DNA-specific location (as the JCR spec does not specify that the namespaces are available as content.  By doing this, the namespace registry would automatically work across a cluster (any clients that are using the same RepositorySource).


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

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

        


From jira-events at lists.jboss.org  Wed Feb 25 18:22:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 25 Feb 2009 18:22:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Work started: (DNA-286) Implement
	namespace management
In-Reply-To: <23913041.1235603864149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1487414.1235604164213.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Work on DNA-286 started by Randall Hauch.

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

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

        


From jira-events at lists.jboss.org  Fri Feb 27 17:21:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 27 Feb 2009 17:21:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-286) Implement namespace
	management
In-Reply-To: <23913041.1235603864149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17749241.1235773304932.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

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

    Resolution: Done


This change provides a new implementation of the NamespaceRegistry interface of the JCR API, along with refactoring the implementations of DNA's NamespaceRegistry.  In particular, a new GraphNamespaceRegistry class was added that stores the namespace mappings in the graph content (under a location provided into the constructor).  This allowed the new JcrNamespaceRegistry to simply delegate to that and do the simple mapping from DNA's interface to JCR's.  (The refactoring also changed a number of test cases that were directly instantiating a namespace registry.)

The other major change to the JCR implementation is the proper implementation of a session-specific (non-shared and non-persistent) namespace registry, on top of the shared (in a content-sense, not shared objects) and persistent registry that is in the JcrWorkspace.  This required changing how the JcrSession and JcrWorkspace objects are created.  The result is that now namespace mappings can be set on the session, and these override those in the workspace (that would be used for all sessions that use that repository's workspace).

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

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

        


From jira-events at lists.jboss.org  Fri Feb 27 23:24:44 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Fri, 27 Feb 2009 23:24:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-286) Implement namespace
	management
In-Reply-To: <23913041.1235603864149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <21009236.1235795084144.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Brian Carothers updated DNA-286:
--------------------------------

    Attachment: DNA-286.patch


I believe that the JCR spec does allow the remapping of built-in namespaces.  At least, that's the behavior that the Jackrabbit TCK explicitly tests.  This patch removes the checks that prohibit mapping new prefixes to the built-in URIs.

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

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

        


From jira-events at lists.jboss.org  Sat Feb 28 10:46:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Sat, 28 Feb 2009 10:46:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Reopened: (DNA-286) Implement namespace
	management
In-Reply-To: <23913041.1235603864149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2097309.1235836004288.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reopened DNA-286:
-------------------------------



Reopened this issue.

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

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

        


From jira-events at lists.jboss.org  Sat Feb 28 11:22:54 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Sat, 28 Feb 2009 11:22:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-286) Implement namespace
	management
In-Reply-To: <23913041.1235603864149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14688709.1235838174418.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-286:
-----------------------------------

Thanks for catching this, Brian.  However, I think we are both right, which means that the namespace management aspects of JCR are more complicated.

Section 7.2.1 specifies the behavior for the workspace-level namespace registry, and specifically says "Attempting to re-assign a built-in prefix (jcr, nt, mix, xml or the empty prefix) to a new URI will throw a NamespaceException." Also, "Attempting to register a namespace with a prefix that begins with the characters 'xml' (in any combination of case) will throw a NamespaceException."  So I believe the JcrWorkspace and JcrNamespaceRegistry code as originally committed is in fact compatible with this aspect.

However, according to the JSR-170 specification, Section 6.3 defines the Session-level (local) namespace mapping behavior to be slightly different.  Firstly, the URI supplied to the session-level methods must already be registered globally (in other words, the session methods only change the prefix of a globally-registered URI).  Secondly, the session-level methods DO allow remapping any of the built-in namespaces to different prefixes (except for the default namespace URI).  Thirdly, the new prefix may not begin with the characters 'xml' (in any combination of case).  Fourthly, the default prefix (an empty string) may not be used as a new prefix.  Fifthly, there are some subtleties regarding remapping of existing URIs to prefixes that are already used in a mapping (for more, see section 6.3.3 of JSR-170).

Interestingly, the draft JSR-283 specification (Section 4.3.3) seems to have language that makes the session-level namespace mappings more usable.  It specifically states that when a session is acquired, the workspace-level namespace mappings are copied into the session (though Section 5.3.1 states that workspace-level changes are immediately reflected in all Sessions, unless they are overridden in those Sessions, making it seem like the Sessions do not actually get a true "copy").  It also seems to relax the restrictions on mapping URIs that already are mapping, and addresses the cases when mappings are removed but are still needed (they are re-added, but using a different generated prefix so as to not clash with any workspace-level generated prefixes).  The draft JSR-283 specification seems to no longer require that the URI in the session-level mappings must already exist in the global mappings.

Suffice to say that the Session-level namespace management needs a little work.  We'll have to identify whether JSR-283 is indeed relaxing any behavior of JSR-170, and if so, whether those changes are better.  (Generally, I'd say we want to implement JSR-170, but the wording of JSR-170 in this case seems to have some major issues by only working with existing URIs.)  Hopefully the specs are not in conflict.

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

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

        


From jira-events at lists.jboss.org  Sat Feb 28 11:26:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Sat, 28 Feb 2009 11:26:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-286) Implement namespace
	management
In-Reply-To: <23913041.1235603864149.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9098736.1235838404155.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-286:
-----------------------------------

BTW, because of the issues outlined in my previous comment, the attached patch really applies only to the session-level methods.  However, because the code currently uses a single class for both, applying the patch as-is would make the workspace-level methods incorrect.  The fix will have to create separate classes (or a class whose instances can handle either situation).

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

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

        


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


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

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

    Attachment: DNA-91_Full.patch


Fresh iteration of the patch that works with the new namespace code, fixes the circular reference between nt:unstructured and the default primary type of its child nodes, and adds a canAddChildNode implementation.

This patch passes all of the Jackrabbit TCK nodetype tests save one failure caused by name translation.

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


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

        


