From jira-events at lists.jboss.org  Tue Jan  6 09:24:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 6 Jan 2009 09:24:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-267) Change copyright year
	to 2009
Message-ID: <24695528.1231251843948.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change copyright year to 2009
-----------------------------

                 Key: DNA-267
                 URL: https://jira.jboss.org/jira/browse/DNA-267
             Project: DNA
          Issue Type: Task
          Components: API, Common, Connectors, Development Environment, Documentation, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers, Testing
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Trivial
             Fix For: 0.4


We need to change the copyright year to 2009.  We may want to consider updating the source headers while we're at it, to remove the copyright (similar to the latest style for JBoss projects).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan  7 14:47:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 7 Jan 2009 14:47:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-48) Development and
 testing kit for federation connectors
Message-ID: <3992573.1231357624000.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reassigned DNA-48:
--------------------------------

    Assignee: Randall Hauch


> Development and testing kit for federation connectors
> -----------------------------------------------------
>
>                 Key: DNA-48
>                 URL: https://jira.jboss.org/jira/browse/DNA-48
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors, Federation, Testing
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.5
>
>
> Developing federation connectors will require some documentation and test harnesses that simplifies the task of creating and testing connectors.  This should include unit- and integration-level tests, and ways of running these tests as regression tests.  Ideally this would also include a way to execute performance tests.

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

        


From jira-events at lists.jboss.org  Wed Jan  7 15:00:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 7 Jan 2009 15:00:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-48) Development and
 testing kit for federation connectors
Message-ID: <31880340.1231358403989.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-48:
----------------------------------

Added an initial set of JUnit test case classes under "org.jboss.dna.graph.connectors.test" (in the test source) that provide a foundation for writing simple unit test classes for a connector, since almost all of the test logic can be inherited.  Right now the tests include the WritableConnectorTest and ReadableConnectorTest abstract classes.  To use these to test a particular connector, the connector developer would create subclass these abstract classes, implementing the two abstract methods (one sets up the RepositorySource instance, and the other initializes the repository content to prepare for the tests).  All test methods are inherited from the abstract classes, so with minimal effort a connector developer can easily provide a series of (standard) benchmark functionality tests to ensure the connector is behaving correctly.  

It is likely that the connector developer will want to create additional tests.  There is a common abstract base class for the WritableConnectorTest and ReadableConnectorTest classes, and this common base class performs all the set up and initialization of the repository source.  So by extending this class, a custom connector test case class can test the repository using any methods.

As part of this effort, I also added "package-info.java" files for each package in the "org.jboss.dna.graph" project.  These package-level JavaDocs should help developers understand how to use the JBoss DNA Graph API. including how to write and test a custom connector.

Finally, I changed the test cases in the JPA connector to use this test harness.

> Development and testing kit for federation connectors
> -----------------------------------------------------
>
>                 Key: DNA-48
>                 URL: https://jira.jboss.org/jira/browse/DNA-48
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors, Federation, Testing
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.5
>
>
> Developing federation connectors will require some documentation and test harnesses that simplifies the task of creating and testing connectors.  This should include unit- and integration-level tests, and ways of running these tests as regression tests.  Ideally this would also include a way to execute performance tests.

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

        


From jira-events at lists.jboss.org  Wed Jan  7 16:01:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 7 Jan 2009 16:01:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-48) Development and testing
 kit for federation connectors
Message-ID: <3775440.1231362064432.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-48:
-----------------------------

    Description: Developing federation connectors will require some documentation and test harnesses that simplifies the task of creating and testing connectors.  This should include unit tests that verify the connectors' behavior matches that expected by DNA, and that can be used to check for regression.  Ideally this would also include a way to execute performance tests.  (was: Developing federation connectors will require some documentation and test harnesses that simplifies the task of creating and testing connectors.  This should include unit- and integration-level tests, and ways of running these tests as regression tests.  Ideally this would also include a way to execute performance tests.)


Changed the scope.  Will be putting the performance tests under another issue.

> Development and testing kit for federation connectors
> -----------------------------------------------------
>
>                 Key: DNA-48
>                 URL: https://jira.jboss.org/jira/browse/DNA-48
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors, Federation, Testing
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.5
>
>
> Developing federation connectors will require some documentation and test harnesses that simplifies the task of creating and testing connectors.  This should include unit tests that verify the connectors' behavior matches that expected by DNA, and that can be used to check for regression.  Ideally this would also include a way to execute performance tests.

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

        


From jira-events at lists.jboss.org  Wed Jan  7 16:03:14 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 7 Jan 2009 16:03:14 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-268) Add performance tests
 to the connector testing framework.
Message-ID: <19969579.1231362194133.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add performance tests to the connector testing framework.
---------------------------------------------------------

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


We already have a series of unit tests that verify functionality, but we should add unit tests (or integration-level tests) that measure performance of the connectors (including speed metrics, volume metrics, etc.).


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

        


From jira-events at lists.jboss.org  Wed Jan  7 16:05:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 7 Jan 2009 16:05:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-268) Add performance tests
 to the connector testing framework.
In-Reply-To: <19969579.1231362194133.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <17893593.1231362304024.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-268:
------------------------------

    Fix Version/s: Future Releases
                       (was: 0.4)


> Add performance tests to the connector testing framework.
> ---------------------------------------------------------
>
>                 Key: DNA-268
>                 URL: https://jira.jboss.org/jira/browse/DNA-268
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Priority: Minor
>             Fix For: Future Releases
>
>
> We already have a series of unit tests that verify functionality, but we should add unit tests (or integration-level tests) that measure performance of the connectors (including speed metrics, volume metrics, etc.).

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

        


From jira-events at lists.jboss.org  Wed Jan  7 16:05:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 7 Jan 2009 16:05:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-48) Development and
 testing kit for federation connectors
Message-ID: <4159409.1231362304069.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-48.
------------------------------

    Resolution: Done


> Development and testing kit for federation connectors
> -----------------------------------------------------
>
>                 Key: DNA-48
>                 URL: https://jira.jboss.org/jira/browse/DNA-48
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors, Federation, Testing
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.5
>
>
> Developing federation connectors will require some documentation and test harnesses that simplifies the task of creating and testing connectors.  This should include unit tests that verify the connectors' behavior matches that expected by DNA, and that can be used to check for regression.  Ideally this would also include a way to execute performance tests.

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

        


From jira-events at lists.jboss.org  Wed Jan  7 17:23:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 7 Jan 2009 17:23:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-267) Change copyright year
	to 2009
In-Reply-To: <24695528.1231251843948.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <12455208.1231366984120.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-267.
-------------------------------

    Resolution: Done


Updated the copyright statements for all code and source files, from "Copyright 2008" to "Copyright 2008-2009".  No other changes were made.

> Change copyright year to 2009
> -----------------------------
>
>                 Key: DNA-267
>                 URL: https://jira.jboss.org/jira/browse/DNA-267
>             Project: DNA
>          Issue Type: Task
>          Components: API, Common, Connectors, Development Environment, Documentation, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Trivial
>             Fix For: 0.4
>
>
> We need to change the copyright year to 2009.  We may want to consider updating the source headers while we're at it, to remove the copyright (similar to the latest style for JBoss projects).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan  8 13:18:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 8 Jan 2009 13:18:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-260) Add factory method to
 create a Binary instance from a (local) File
In-Reply-To: <18063324.1227458436493.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <10911272.1231438683989.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-260.
-------------------------------

    Resolution: Done


Created the BinaryFactory interface, which extends ValueFactory<Binary> and adds several methods for creating Binary objects from File objects, and from InputStream (or Reader) when then binary's hash is already known.  These latter methods will allow an implementation to maintain a pool of Binary objects keyed by their hash, so that only one Binary object per unique value is needed.  Also added a method to find a Binary value given the hash (so that connectors and clients that know the hash may attempt to reuse an existing Binary value with the same hash, without having to create the InputStream (or Reader), since that may be expensive even if the stream/reader is not used.

None of the factories in 'org.jboss.dna.graph' reuse Binary values, however; they always create a new object.

Also added some better error handling logic in IoUtil - getting an exception when closing a stream (in the finally block) will not stomp on an exception thrown from the try block.

> Add factory method to create a Binary instance from a (local) File
> ------------------------------------------------------------------
>
>                 Key: DNA-260
>                 URL: https://jira.jboss.org/jira/browse/DNA-260
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> A client sometimes has a file and wants to represent the content of the file with a Binary value object.  Currently, the client would have to obtain an InputStream or a Reader to the file, and create the Binary value object with that.  Then, when somebody wants to read the binary value, they have to create another stream/reader.  Essentially, the content is streamed 1+n times, where n is the number of times the value is read.  This can be very expensive when the size of the file is large (or very large, as in gigabytes).
> By adding a factor method that takes a File object, the factory could optimize the behavior.  Rather than creating a stream/reader to put the content into the Binary value object, the factory could just create a Binary implementation that delegates to a File.  Then, the only time a stream/reader is created is when the client wants to read the value.  In other words, the content is streamed only n times.
> We don't yet have a BinaryFactory interface, and are currently using ValueFactory<Binary>.  Therefore, the first step is to create the BinaryFactory interface and use this in the ValueFactories interface.  (Most uses of the 'getBinaryFactory()' method would not need to change, since they're either just immediately calling 'create(...)' on the returned reference, or are using ValueFactory<Binary>, which would still work.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan  9 16:38:14 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 9 Jan 2009 16:38:14 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-264) Connectors may need
 to determine the MIME type for content
In-Reply-To: <22148120.1228432116535.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7785929.1231537094155.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-264.
-------------------------------

    Resolution: Done


This change adds the ability in ExecutionContext to get a MimeTypeDetector, which can be used to get the MIME type for some content.  This allows a connector (such as the File System Connector) to detect the MIME type given the name/content.

Several options were considered, but this proved to be the "best" approach.  One option considered was adding a "getMimeTypeDetector()" to RepositoryContext, which are handed to RepositorySource instances when they're managed.  Since very few RepositorySource implementations need to use this, it seemed like it raised the bar (in terms of work) for connector implementors.  And, that only let the RepositorySource have access to a MimeTypeDetector, and the connector still had to pass it around to the different components that needed it (e.g., the RepositoryConnection implementation, and then the RequestProcessor implementation).  

Another option considered was moving the MimeTypes, MimeTypeDetectorConfig, and MimeTypeDetectors (the component library) classes from 'org.jboss.dna.repository' into 'org.jboss.dna.graph'.  This would have made the Graph project more heavy weight, and wouldn't have really solved the problem.  Using MimeTypes would have, however, since it contains static methods that delegate to a singleton MimeTypeDetectors library - but singletons have a lot of disadvantages when it comes to flexible configuration and dependencies.  Therefore this option was not chosen.

The final option considered (and chosen) was putting the "getMimeTypeDetector()" in ExecutionContext.  Since there are a lot of components in DNA that already have access to ExecutionContext, this approach made MIME type detection available to them all.  

This approach required providing a default implementation of a MimeTypeDetector in BasicExecutionContext (the default implementation of ExecutionContext), so there is now a new lightweight and reusable MimeTypeDetector implementation called ExtensionBasedMimeTypeDetector that reads a well-known properties file ("/org/jboss/dna/graph/MimeTypes.properties") as a resource from the classloader, and this file defines the extensions for each MIME type.  A file containing many common extensions is provided as part of 'org.jboss.dna.graph', although a user can either supply their own (at the same resource location) or use a different constructor that takes the mappings as a constructor parameter.  This implementation, which only looks at the name, may not be as powerful or robust as the Aperture extension's implementation, but it is very lightweight and easy to manage.

> Connectors may need to determine the MIME type for content
> ----------------------------------------------------------
>
>                 Key: DNA-264
>                 URL: https://jira.jboss.org/jira/browse/DNA-264
>             Project: DNA
>          Issue Type: Task
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>
> Some connectors may need to be able to determine the MIME type for content, and there's currently no way in the connector API to do that.  The 'dna-graph' project does have MimeTypeDetector interface, but that's meant as a lower-level interface for an implementation.  MimeType was designed to be the main entry point for general components, but that's currently in 'dna-repository' (and connectors don't currently require that).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan  9 16:50:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 9 Jan 2009 16:50:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-34) Federate content
 stored on file system
Message-ID: <27720953.1231537803971.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-34:
----------------------------------

The completion of DNA-264 included the last change to the file system connector so that the MIME type could be determined.

> Federate content stored on file system
> --------------------------------------
>
>                 Key: DNA-34
>                 URL: https://jira.jboss.org/jira/browse/DNA-34
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a connector for the federation engine that contributes and exposes content stored on the file system (in one or more directories) into the federated repository.  This connector would dynamically create the "nt:file" and "nt:folder" nodes to mirror the contents of the file system.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan  9 17:54:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 9 Jan 2009 17:54:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-34) Federate content stored
 on file system (read-only access)
Message-ID: <5549988.1231541643948.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-34:
-----------------------------

        Summary: Federate content stored on file system (read-only access)  (was: Federate content stored on file system)
    Description: Create a connector for the federation engine that contributes and exposes content stored on the file system (in one or more directories) into the federated repository.  This connector would dynamically create the "nt:file" and "nt:folder" nodes to mirror the contents of the file system.  The initial implementation only needs to support reading.  (was: Create a connector for the federation engine that contributes and exposes content stored on the file system (in one or more directories) into the federated repository.  This connector would dynamically create the "nt:file" and "nt:folder" nodes to mirror the contents of the file system.)


> Federate content stored on file system (read-only access)
> ---------------------------------------------------------
>
>                 Key: DNA-34
>                 URL: https://jira.jboss.org/jira/browse/DNA-34
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a connector for the federation engine that contributes and exposes content stored on the file system (in one or more directories) into the federated repository.  This connector would dynamically create the "nt:file" and "nt:folder" nodes to mirror the contents of the file system.  The initial implementation only needs to support reading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan  9 17:56:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 9 Jan 2009 17:56:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-269) Add update support to
 the File System connector
Message-ID: <31293415.1231541764010.JavaMail.jira@cloud.prod.atl2.jboss.com>

Add update support to the File System connector
-----------------------------------------------

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


The File System connector (DNA-34) currently only supports read-access to the files and folders.  Add update support, so a client can create files and folders (not other kinds of content) on the file system via the graph API and connector.

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

        


From jira-events at lists.jboss.org  Fri Jan  9 18:09:08 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 9 Jan 2009 18:09:08 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-34) Federate content
 stored on file system (read-only access)
Message-ID: <30305528.1231542548322.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-34.
------------------------------

    Resolution: Done


Completed the file system connector and read support.  Added unit test that uses the standard connector read tests.  Also fixed a bug in the AbstractValueFactory that neglected to look for a Binary object in "create(Object)".

> Federate content stored on file system (read-only access)
> ---------------------------------------------------------
>
>                 Key: DNA-34
>                 URL: https://jira.jboss.org/jira/browse/DNA-34
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> Create a connector for the federation engine that contributes and exposes content stored on the file system (in one or more directories) into the federated repository.  This connector would dynamically create the "nt:file" and "nt:folder" nodes to mirror the contents of the file system.  The initial implementation only needs to support reading.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 12 18:03:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 12 Jan 2009 18:03:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-270) Simplify the
 ExecutionContext framework
Message-ID: <14475404.1231801384116.JavaMail.jira@cloud.prod.atl2.jboss.com>

Simplify the ExecutionContext framework
---------------------------------------

                 Key: DNA-270
                 URL: https://jira.jboss.org/jira/browse/DNA-270
             Project: DNA
          Issue Type: Task
          Components: API, Connectors, Documentation, Examples, Graph, Sequencers
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.4


The ExecutionContext interface is used throughout the system.  It's defined in 'dna-graph', and used to represent the context or environment for executing various activities.  There is also ExecutionContextFactory, which is an interface for creating other contexts with different JAAS security contexts (login context or access control contexts).  There are also the Basic* implementations of these interfaces, as well as several subclasses (with various implementations).

The idea of using an interface for this was to simplify the design of the components that uses/took an ExecutionContext, to prevent propagating dependencies, and to allow customization.  However, since ExecutionContext is largely just an aggregation of references, there's little need to customize the behavior, and this doesn't really add any other dependencies to the classpath (all implementations of the aggregated components are already in 'dna-graph') and it doesn't expose any implementations through the method signatures.  Using interfaces also complicates the usage, since clients have to know about the concrete implementations.  This is even more true when they're setting up the DNA services and repositories in 'dna-repository' and 'dna-jcr'.

So, consider changing this interface to a concrete class, with methods that make it easy to create instances as well as instances with custom components (e.g., a new context that is the same as 'this' but with a supplied NamespaceRegistry implementation).

This will change the public API, but this should be acceptable given that we're not yet at 1.0 (and this really improves both the client code, and doesn't really change extension implementations).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 12 18:40:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 12 Jan 2009 18:40:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-270) Simplify the
 ExecutionContext framework
In-Reply-To: <14475404.1231801384116.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14163508.1231803604172.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-270:
------------------------------

    Attachment: dna-270-executioncontext.patch


Attached a patch file that has the proposed changes (relative to revision 701), and which results in all tests passing.

> Simplify the ExecutionContext framework
> ---------------------------------------
>
>                 Key: DNA-270
>                 URL: https://jira.jboss.org/jira/browse/DNA-270
>             Project: DNA
>          Issue Type: Task
>          Components: API, Connectors, Documentation, Examples, Graph, Sequencers
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-270-executioncontext.patch
>
>
> The ExecutionContext interface is used throughout the system.  It's defined in 'dna-graph', and used to represent the context or environment for executing various activities.  There is also ExecutionContextFactory, which is an interface for creating other contexts with different JAAS security contexts (login context or access control contexts).  There are also the Basic* implementations of these interfaces, as well as several subclasses (with various implementations).
> The idea of using an interface for this was to simplify the design of the components that uses/took an ExecutionContext, to prevent propagating dependencies, and to allow customization.  However, since ExecutionContext is largely just an aggregation of references, there's little need to customize the behavior, and this doesn't really add any other dependencies to the classpath (all implementations of the aggregated components are already in 'dna-graph') and it doesn't expose any implementations through the method signatures.  Using interfaces also complicates the usage, since clients have to know about the concrete implementations.  This is even more true when they're setting up the DNA services and repositories in 'dna-repository' and 'dna-jcr'.
> So, consider changing this interface to a concrete class, with methods that make it easy to create instances as well as instances with custom components (e.g., a new context that is the same as 'this' but with a supplied NamespaceRegistry implementation).
> This will change the public API, but this should be acceptable given that we're not yet at 1.0 (and this really improves both the client code, and doesn't really change extension implementations).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 12 18:44:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 12 Jan 2009 18:44:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-270) Simplify the
 ExecutionContext framework
In-Reply-To: <14475404.1231801384116.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <27571899.1231803843950.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-270:
-----------------------------------

Incidentally, this change also eliminates the practical difference between components that take an ExecutionContextFactory, and those that take an ExecutionContext, since an ExecutionContext instance will be created and passed to both kinds of components.  (The semantic difference is still there, in that when a factory is provided, the recipient needs to create a context; whereas if a context is provided, it could be used as is or could be used to create a subcontext.)  

> Simplify the ExecutionContext framework
> ---------------------------------------
>
>                 Key: DNA-270
>                 URL: https://jira.jboss.org/jira/browse/DNA-270
>             Project: DNA
>          Issue Type: Task
>          Components: API, Connectors, Documentation, Examples, Graph, Sequencers
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-270-executioncontext.patch
>
>
> The ExecutionContext interface is used throughout the system.  It's defined in 'dna-graph', and used to represent the context or environment for executing various activities.  There is also ExecutionContextFactory, which is an interface for creating other contexts with different JAAS security contexts (login context or access control contexts).  There are also the Basic* implementations of these interfaces, as well as several subclasses (with various implementations).
> The idea of using an interface for this was to simplify the design of the components that uses/took an ExecutionContext, to prevent propagating dependencies, and to allow customization.  However, since ExecutionContext is largely just an aggregation of references, there's little need to customize the behavior, and this doesn't really add any other dependencies to the classpath (all implementations of the aggregated components are already in 'dna-graph') and it doesn't expose any implementations through the method signatures.  Using interfaces also complicates the usage, since clients have to know about the concrete implementations.  This is even more true when they're setting up the DNA services and repositories in 'dna-repository' and 'dna-jcr'.
> So, consider changing this interface to a concrete class, with methods that make it easy to create instances as well as instances with custom components (e.g., a new context that is the same as 'this' but with a supplied NamespaceRegistry implementation).
> This will change the public API, but this should be acceptable given that we're not yet at 1.0 (and this really improves both the client code, and doesn't really change extension implementations).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 13 17:18:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 13 Jan 2009 17:18:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-271) Change mechanism to
 declare
 copyright, moving from source code into separate file included with
 distributions
In-Reply-To: <4358421.1231885084072.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <15766719.1231885084112.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-271:
------------------------------

    Attachment: COPYRIGHT.txt


> Change mechanism to declare copyright, moving from source code into separate file included with distributions
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-271
>                 URL: https://jira.jboss.org/jira/browse/DNA-271
>             Project: DNA
>          Issue Type: Task
>          Components: API, Common, Connectors, Development Environment, Documentation, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: AUTHORS.txt, COPYRIGHT.txt
>
>
> The copyright information in our source needs to be cleaned up and corrected.  In particular, we can place the copyright into a separate COPYRIGHT.txt file included in each distribution, and change the headers to refer to this file. Then the source only contains the license information (plus references to the copyright and authors files in the distribution).  This is actually a much better way to handle copyrights (since the year and the copyright text is in one place, and can be annotated as required), yet does not change any rights on existing code.  
> Also, SVN is the master record for each individual contribution, so pending decision by the community, the "@author" tags would be removed from the code, which would refer to a new AUTHORS.txt file.
> The content of the AUTHORS.txt, COPYRIGHT.txt, and new header are attached.  Note that the Eclipse preferences need to be changed accordingly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 13 17:18:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 13 Jan 2009 17:18:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-271) Change mechanism to
 declare
 copyright, moving from source code into separate file included with
 distributions
Message-ID: <4358421.1231885084072.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change mechanism to declare copyright, moving from source code into separate file included with distributions
-------------------------------------------------------------------------------------------------------------

                 Key: DNA-271
                 URL: https://jira.jboss.org/jira/browse/DNA-271
             Project: DNA
          Issue Type: Task
          Components: API, Common, Connectors, Development Environment, Documentation, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers, Testing
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Minor
             Fix For: 0.4
         Attachments: AUTHORS.txt, COPYRIGHT.txt

The copyright information in our source needs to be cleaned up and corrected.  In particular, we can place the copyright into a separate COPYRIGHT.txt file included in each distribution, and change the headers to refer to this file. Then the source only contains the license information (plus references to the copyright and authors files in the distribution).  This is actually a much better way to handle copyrights (since the year and the copyright text is in one place, and can be annotated as required), yet does not change any rights on existing code.  

Also, SVN is the master record for each individual contribution, so pending decision by the community, the "@author" tags would be removed from the code, which would refer to a new AUTHORS.txt file.

The content of the AUTHORS.txt, COPYRIGHT.txt, and new header are attached.  Note that the Eclipse preferences need to be changed accordingly.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 13 17:18:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 13 Jan 2009 17:18:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-271) Change mechanism to
 declare
 copyright, moving from source code into separate file included with
 distributions
In-Reply-To: <4358421.1231885084072.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19887660.1231885084159.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-271:
------------------------------

    Attachment: AUTHORS.txt


> Change mechanism to declare copyright, moving from source code into separate file included with distributions
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-271
>                 URL: https://jira.jboss.org/jira/browse/DNA-271
>             Project: DNA
>          Issue Type: Task
>          Components: API, Common, Connectors, Development Environment, Documentation, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: AUTHORS.txt, COPYRIGHT.txt
>
>
> The copyright information in our source needs to be cleaned up and corrected.  In particular, we can place the copyright into a separate COPYRIGHT.txt file included in each distribution, and change the headers to refer to this file. Then the source only contains the license information (plus references to the copyright and authors files in the distribution).  This is actually a much better way to handle copyrights (since the year and the copyright text is in one place, and can be annotated as required), yet does not change any rights on existing code.  
> Also, SVN is the master record for each individual contribution, so pending decision by the community, the "@author" tags would be removed from the code, which would refer to a new AUTHORS.txt file.
> The content of the AUTHORS.txt, COPYRIGHT.txt, and new header are attached.  Note that the Eclipse preferences need to be changed accordingly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 13 17:20:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 13 Jan 2009 17:20:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-271) Change mechanism to
 declare
 copyright, moving from source code into separate file included with
 distributions
In-Reply-To: <4358421.1231885084072.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16367018.1231885204010.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-271:
------------------------------

    Attachment: headers.txt


> Change mechanism to declare copyright, moving from source code into separate file included with distributions
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-271
>                 URL: https://jira.jboss.org/jira/browse/DNA-271
>             Project: DNA
>          Issue Type: Task
>          Components: API, Common, Connectors, Development Environment, Documentation, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: AUTHORS.txt, COPYRIGHT.txt, headers.txt
>
>
> The copyright information in our source needs to be cleaned up and corrected.  In particular, we can place the copyright into a separate COPYRIGHT.txt file included in each distribution, and change the headers to refer to this file. Then the source only contains the license information (plus references to the copyright and authors files in the distribution).  This is actually a much better way to handle copyrights (since the year and the copyright text is in one place, and can be annotated as required), yet does not change any rights on existing code.  
> Also, SVN is the master record for each individual contribution, so pending decision by the community, the "@author" tags would be removed from the code, which would refer to a new AUTHORS.txt file.
> The content of the AUTHORS.txt, COPYRIGHT.txt, and new header are attached.  Note that the Eclipse preferences need to be changed accordingly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 11:36:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 11:36:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-270) Simplify the
 ExecutionContext framework
In-Reply-To: <14475404.1231801384116.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11706913.1231950964023.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-270:
------------------------------

    Attachment:     (was: dna-270-executioncontext.patch)


> Simplify the ExecutionContext framework
> ---------------------------------------
>
>                 Key: DNA-270
>                 URL: https://jira.jboss.org/jira/browse/DNA-270
>             Project: DNA
>          Issue Type: Task
>          Components: API, Connectors, Documentation, Examples, Graph, Sequencers
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The ExecutionContext interface is used throughout the system.  It's defined in 'dna-graph', and used to represent the context or environment for executing various activities.  There is also ExecutionContextFactory, which is an interface for creating other contexts with different JAAS security contexts (login context or access control contexts).  There are also the Basic* implementations of these interfaces, as well as several subclasses (with various implementations).
> The idea of using an interface for this was to simplify the design of the components that uses/took an ExecutionContext, to prevent propagating dependencies, and to allow customization.  However, since ExecutionContext is largely just an aggregation of references, there's little need to customize the behavior, and this doesn't really add any other dependencies to the classpath (all implementations of the aggregated components are already in 'dna-graph') and it doesn't expose any implementations through the method signatures.  Using interfaces also complicates the usage, since clients have to know about the concrete implementations.  This is even more true when they're setting up the DNA services and repositories in 'dna-repository' and 'dna-jcr'.
> So, consider changing this interface to a concrete class, with methods that make it easy to create instances as well as instances with custom components (e.g., a new context that is the same as 'this' but with a supplied NamespaceRegistry implementation).
> This will change the public API, but this should be acceptable given that we're not yet at 1.0 (and this really improves both the client code, and doesn't really change extension implementations).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 11:38:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 11:38:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-270) Simplify the
 ExecutionContext framework
In-Reply-To: <14475404.1231801384116.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26426500.1231951084127.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-270:
------------------------------

    Attachment: dna-270.patch


Updated with a patch that corrects unit test failures.

> Simplify the ExecutionContext framework
> ---------------------------------------
>
>                 Key: DNA-270
>                 URL: https://jira.jboss.org/jira/browse/DNA-270
>             Project: DNA
>          Issue Type: Task
>          Components: API, Connectors, Documentation, Examples, Graph, Sequencers
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-270.patch
>
>
> The ExecutionContext interface is used throughout the system.  It's defined in 'dna-graph', and used to represent the context or environment for executing various activities.  There is also ExecutionContextFactory, which is an interface for creating other contexts with different JAAS security contexts (login context or access control contexts).  There are also the Basic* implementations of these interfaces, as well as several subclasses (with various implementations).
> The idea of using an interface for this was to simplify the design of the components that uses/took an ExecutionContext, to prevent propagating dependencies, and to allow customization.  However, since ExecutionContext is largely just an aggregation of references, there's little need to customize the behavior, and this doesn't really add any other dependencies to the classpath (all implementations of the aggregated components are already in 'dna-graph') and it doesn't expose any implementations through the method signatures.  Using interfaces also complicates the usage, since clients have to know about the concrete implementations.  This is even more true when they're setting up the DNA services and repositories in 'dna-repository' and 'dna-jcr'.
> So, consider changing this interface to a concrete class, with methods that make it easy to create instances as well as instances with custom components (e.g., a new context that is the same as 'this' but with a supplied NamespaceRegistry implementation).
> This will change the public API, but this should be acceptable given that we're not yet at 1.0 (and this really improves both the client code, and doesn't really change extension implementations).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 13:05:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 13:05:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-272) Move the In-Memory
 connector into "dna-graph"
Message-ID: <18646014.1231956304031.JavaMail.jira@cloud.prod.atl2.jboss.com>

Move the In-Memory connector into "dna-graph"
---------------------------------------------

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


The "in-memory" connector implementation is a good transient repository store, and having a transient store in "dna-graph" will simplify a number of things.  Right now, the only connectors are in extensions, so the core libraries (e.g., "dna-graph", "dna-repository", etc.) do not have access to any connector implementation, making it difficult to set up a default source.  For example, I'm working on a new configuration component in "dna-repository" that will set up all the DNA services, and the configuration component works by populating a configuration repository.  By default, the configuration component would instantiate a transient configuration repository, but there isn't an implementation available.  (The configuration component will also allow setting up the configuration repository, so one can use a remote source.)



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 13:05:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 13:05:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-58) Create repository
 configuration and component
In-Reply-To: <10425152.1208876804469.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24032375.1231956304276.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reassigned DNA-58:
--------------------------------

    Assignee: Randall Hauch  (was: Stefano Maestri)


> Create repository configuration and component
> ---------------------------------------------
>
>                 Key: DNA-58
>                 URL: https://jira.jboss.org/jira/browse/DNA-58
>             Project: DNA
>          Issue Type: Task
>          Components: Federation, Sequencers
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.5
>
>
> There needs to be a configuration object that wraps the sequencing service and makes working with the it easier.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 13:07:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 13:07:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-58) Create repository
 configuration and component
In-Reply-To: <10425152.1208876804469.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11254672.1231956423963.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-58:
-----------------------------

          Component/s: Connectors
        Fix Version/s: 0.4
                           (was: 0.5)
    Affects Version/s: 0.3
          Description: There needs to be a configuration object that wraps the sequencing and repository services and makes working with DNA repositories easier.  (was: There needs to be a configuration object that wraps the sequencing service and makes working with the it easier.)


The configuration component should work with a configuration repository, which by default should be a transient in-memory repository (that can be loaded from an XML document) but which can be set to use an external repository source (e.g., for use when one or more DNA processes are to use a central configuration repository).

> Create repository configuration and component
> ---------------------------------------------
>
>                 Key: DNA-58
>                 URL: https://jira.jboss.org/jira/browse/DNA-58
>             Project: DNA
>          Issue Type: Task
>          Components: Connectors, Federation, Sequencers
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.4
>
>
> There needs to be a configuration object that wraps the sequencing and repository services and makes working with DNA repositories easier.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 13:34:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 13:34:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-273) Define and document
 the official patch procedure
Message-ID: <2290513.1231958044394.JavaMail.jira@cloud.prod.atl2.jboss.com>

Define and document the official patch procedure
------------------------------------------------

                 Key: DNA-273
                 URL: https://jira.jboss.org/jira/browse/DNA-273
             Project: DNA
          Issue Type: Task
            Reporter: Randall Hauch
             Fix For: 0.4


We need to define our patch procedure so that it does not involve Eclipse patches, but rather uses standard patches that are compatible with SVN.  We then need to document this procedure in the Reference Guide.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 15:30:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 15:30:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-273) Define and document
 the official patch procedure
In-Reply-To: <2290513.1231958044394.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26437489.1231965004292.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-273:
-----------------------------------

We need to use only SVN-compatible patches so that any users (including those without Eclipse workspaces) can apply the patches.  (Although Eclipse can produce standard patch files for a project, it creates Eclipse-specific files when creating a patch from changes to multiple projects.)

Creating patches is very easy.  Let's assume we want to create a patch to capture local changes made against the latest revision of "trunk".  Simply go to the "trunk" folder in your local working area, and issue this command:  
     svn diff . > ~/DNA-000.patch
where "DNA-000" represents the JIRA issue number that describes the changes (and where the patch will be uploaded).  Note that the destination in the command creates the patch file in your home directory, but you could place it anywhere.  Also note that 'diff' ignores binary files, so any binary files need to be uploaded separately (http://www.igorexchange.com/node/89#creating_patches)

Now, someone else wants to apply the patch, so they download the patch file and apply the differences using the 'patch' utility:
    patch -p0 < ~/DNA-000.patch
The "-p0" option makes sure that all files can be found.

> Define and document the official patch procedure
> ------------------------------------------------
>
>                 Key: DNA-273
>                 URL: https://jira.jboss.org/jira/browse/DNA-273
>             Project: DNA
>          Issue Type: Task
>            Reporter: Randall Hauch
>             Fix For: 0.4
>
>
> We need to define our patch procedure so that it does not involve Eclipse patches, but rather uses standard patches that are compatible with SVN.  We then need to document this procedure in the Reference Guide.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 15:30:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 15:30:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-270) Simplify the
 ExecutionContext framework
In-Reply-To: <14475404.1231801384116.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24413440.1231965004370.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-270:
------------------------------

    Attachment: dna-270.patch


Updated the patch (again) to use a standard (non-Eclipse) patch format.  (See DNA-273)

> Simplify the ExecutionContext framework
> ---------------------------------------
>
>                 Key: DNA-270
>                 URL: https://jira.jboss.org/jira/browse/DNA-270
>             Project: DNA
>          Issue Type: Task
>          Components: API, Connectors, Documentation, Examples, Graph, Sequencers
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-270.patch, dna-270.patch
>
>
> The ExecutionContext interface is used throughout the system.  It's defined in 'dna-graph', and used to represent the context or environment for executing various activities.  There is also ExecutionContextFactory, which is an interface for creating other contexts with different JAAS security contexts (login context or access control contexts).  There are also the Basic* implementations of these interfaces, as well as several subclasses (with various implementations).
> The idea of using an interface for this was to simplify the design of the components that uses/took an ExecutionContext, to prevent propagating dependencies, and to allow customization.  However, since ExecutionContext is largely just an aggregation of references, there's little need to customize the behavior, and this doesn't really add any other dependencies to the classpath (all implementations of the aggregated components are already in 'dna-graph') and it doesn't expose any implementations through the method signatures.  Using interfaces also complicates the usage, since clients have to know about the concrete implementations.  This is even more true when they're setting up the DNA services and repositories in 'dna-repository' and 'dna-jcr'.
> So, consider changing this interface to a concrete class, with methods that make it easy to create instances as well as instances with custom components (e.g., a new context that is the same as 'this' but with a supplied NamespaceRegistry implementation).
> This will change the public API, but this should be acceptable given that we're not yet at 1.0 (and this really improves both the client code, and doesn't really change extension implementations).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 15:32:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 15:32:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-270) Simplify the
 ExecutionContext framework
In-Reply-To: <14475404.1231801384116.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31100981.1231965124186.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-270:
------------------------------

    Attachment:     (was: dna-270.patch)


> Simplify the ExecutionContext framework
> ---------------------------------------
>
>                 Key: DNA-270
>                 URL: https://jira.jboss.org/jira/browse/DNA-270
>             Project: DNA
>          Issue Type: Task
>          Components: API, Connectors, Documentation, Examples, Graph, Sequencers
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-270.patch
>
>
> The ExecutionContext interface is used throughout the system.  It's defined in 'dna-graph', and used to represent the context or environment for executing various activities.  There is also ExecutionContextFactory, which is an interface for creating other contexts with different JAAS security contexts (login context or access control contexts).  There are also the Basic* implementations of these interfaces, as well as several subclasses (with various implementations).
> The idea of using an interface for this was to simplify the design of the components that uses/took an ExecutionContext, to prevent propagating dependencies, and to allow customization.  However, since ExecutionContext is largely just an aggregation of references, there's little need to customize the behavior, and this doesn't really add any other dependencies to the classpath (all implementations of the aggregated components are already in 'dna-graph') and it doesn't expose any implementations through the method signatures.  Using interfaces also complicates the usage, since clients have to know about the concrete implementations.  This is even more true when they're setting up the DNA services and repositories in 'dna-repository' and 'dna-jcr'.
> So, consider changing this interface to a concrete class, with methods that make it easy to create instances as well as instances with custom components (e.g., a new context that is the same as 'this' but with a supplied NamespaceRegistry implementation).
> This will change the public API, but this should be acceptable given that we're not yet at 1.0 (and this really improves both the client code, and doesn't really change extension implementations).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 14 17:14:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 14 Jan 2009 17:14:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-273) Define and document
 the official patch procedure
In-Reply-To: <2290513.1231958044394.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <9938005.1231971243976.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-273:
-----------------------------------

Applying the patch using the command above does not remove empty files.  The following command, however, removes empty files (that were made empty because all of the lines were removed by the patch):
     patch -E -p0 < ~/DNA-000.patch

> Define and document the official patch procedure
> ------------------------------------------------
>
>                 Key: DNA-273
>                 URL: https://jira.jboss.org/jira/browse/DNA-273
>             Project: DNA
>          Issue Type: Task
>            Reporter: Randall Hauch
>             Fix For: 0.4
>
>
> We need to define our patch procedure so that it does not involve Eclipse patches, but rather uses standard patches that are compatible with SVN.  We then need to document this procedure in the Reference Guide.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 11:07:05 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Thu, 15 Jan 2009 11:07:05 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-274) commons-beanutils
 1.8.0 dependency needs to be uploaded to JBoss repository
Message-ID: <30747162.1232035625121.JavaMail.jira@cloud.prod.atl2.jboss.com>

commons-beanutils 1.8.0 dependency needs to be uploaded to JBoss repository
---------------------------------------------------------------------------

                 Key: DNA-274
                 URL: https://jira.jboss.org/jira/browse/DNA-274
             Project: DNA
          Issue Type: Bug
          Components: Development Environment
    Affects Versions: 0.4
            Reporter: Johnny Verhaeg
            Assignee: Johnny Verhaeg
            Priority: Blocker


Both dna-common-jdbc and dna-connector-jdbc-metadata depend on this library.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 11:11:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 11:11:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-270) Simplify the
 ExecutionContext framework
In-Reply-To: <14475404.1231801384116.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <31265933.1232035864277.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-270.
-------------------------------

    Resolution: Done


Changed ExecutionContext from an interface to a concrete class, and made it implement ExecutionContextFactory.  This allowed removing the BasicExecutionContext and BasicExecutionContextFactory implementations.  Also added methods to ExecutionContext to create "subcontext" (or context that inherit all of the same components except for one), allowing removal of the ExecutionContexts class.  These changes made it much easier to use (no need to know about an implementation, anybody can create a context or create a modified form of another context, less of a distinction between ExecutionContext and ExecutionContextFactory, etc.), yet provides a lot of flexibility for defining different combinations of components (including custom components) without requiring subclassing (though subclassing is not precluded).

There were two primary subinterfaces of ExecutionContext (SequencerContext and JcrExecutionContext); both of these were converted from classes to interfaces, eliminating their implementation classes.  Since both provide special kinds of contexts that only added components to the "context" (rather than changing the behavior of the existing components).

Also changed the documentation and examples to reflect these improvements.

> Simplify the ExecutionContext framework
> ---------------------------------------
>
>                 Key: DNA-270
>                 URL: https://jira.jboss.org/jira/browse/DNA-270
>             Project: DNA
>          Issue Type: Task
>          Components: API, Connectors, Documentation, Examples, Graph, Sequencers
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>         Attachments: dna-270.patch
>
>
> The ExecutionContext interface is used throughout the system.  It's defined in 'dna-graph', and used to represent the context or environment for executing various activities.  There is also ExecutionContextFactory, which is an interface for creating other contexts with different JAAS security contexts (login context or access control contexts).  There are also the Basic* implementations of these interfaces, as well as several subclasses (with various implementations).
> The idea of using an interface for this was to simplify the design of the components that uses/took an ExecutionContext, to prevent propagating dependencies, and to allow customization.  However, since ExecutionContext is largely just an aggregation of references, there's little need to customize the behavior, and this doesn't really add any other dependencies to the classpath (all implementations of the aggregated components are already in 'dna-graph') and it doesn't expose any implementations through the method signatures.  Using interfaces also complicates the usage, since clients have to know about the concrete implementations.  This is even more true when they're setting up the DNA services and repositories in 'dna-repository' and 'dna-jcr'.
> So, consider changing this interface to a concrete class, with methods that make it easy to create instances as well as instances with custom components (e.g., a new context that is the same as 'this' but with a supplied NamespaceRegistry implementation).
> This will change the public API, but this should be acceptable given that we're not yet at 1.0 (and this really improves both the client code, and doesn't really change extension implementations).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 12:28:05 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 12:28:05 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-275) Change plural package
 names to be singular
Message-ID: <4617127.1232040486009.JavaMail.jira@cloud.prod.atl2.jboss.com>

Change plural package names to be singular
------------------------------------------

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


We have several cases where we're using package names that are plural.  Many style guides recommend using singular nouns.  Above all, we need to be consistent (which we're not).

It's better to make these changes now rather than later.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 13:27:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 13:27:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-275) Change plural package
 names to be singular
In-Reply-To: <4617127.1232040486009.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20180489.1232044023990.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-275.
-------------------------------

    Resolution: Done


There were quite a few packages that were renamed, including those that were in our public API.  However, it is better to change these now, since we won't be able to do it later.

> Change plural package names to be singular
> ------------------------------------------
>
>                 Key: DNA-275
>                 URL: https://jira.jboss.org/jira/browse/DNA-275
>             Project: DNA
>          Issue Type: Task
>          Components: API
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>
> We have several cases where we're using package names that are plural.  Many style guides recommend using singular nouns.  Above all, we need to be consistent (which we're not).
> It's better to make these changes now rather than later.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 15:39:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 15:39:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-271) Change mechanism to
 declare
 copyright, moving from source code into separate file included with
 distributions
In-Reply-To: <4358421.1231885084072.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24267740.1232051943956.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-271:
------------------------------

    Attachment: DNA-271.patch


Attached the patch file that changes all of these files, plus added the new COPYRIGHT.txt and AUTHORS.txt files.  There were several source files without any header in them, and these were corrected.

> Change mechanism to declare copyright, moving from source code into separate file included with distributions
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-271
>                 URL: https://jira.jboss.org/jira/browse/DNA-271
>             Project: DNA
>          Issue Type: Task
>          Components: API, Common, Connectors, Development Environment, Documentation, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: AUTHORS.txt, COPYRIGHT.txt, DNA-271.patch, headers.txt
>
>
> The copyright information in our source needs to be cleaned up and corrected.  In particular, we can place the copyright into a separate COPYRIGHT.txt file included in each distribution, and change the headers to refer to this file. Then the source only contains the license information (plus references to the copyright and authors files in the distribution).  This is actually a much better way to handle copyrights (since the year and the copyright text is in one place, and can be annotated as required), yet does not change any rights on existing code.  
> Also, SVN is the master record for each individual contribution, so pending decision by the community, the "@author" tags would be removed from the code, which would refer to a new AUTHORS.txt file.
> The content of the AUTHORS.txt, COPYRIGHT.txt, and new header are attached.  Note that the Eclipse preferences need to be changed accordingly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 15:49:14 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 15:49:14 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-271) Change mechanism to
 declare
 copyright, moving from source code into separate file included with
 distributions
In-Reply-To: <4358421.1231885084072.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26411388.1232052554243.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-271.
-------------------------------

    Resolution: Done


Committed the patch, verifying that all unit tests pass.

> Change mechanism to declare copyright, moving from source code into separate file included with distributions
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-271
>                 URL: https://jira.jboss.org/jira/browse/DNA-271
>             Project: DNA
>          Issue Type: Task
>          Components: API, Common, Connectors, Development Environment, Documentation, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers, Testing
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.4
>
>         Attachments: AUTHORS.txt, COPYRIGHT.txt, DNA-271.patch, headers.txt
>
>
> The copyright information in our source needs to be cleaned up and corrected.  In particular, we can place the copyright into a separate COPYRIGHT.txt file included in each distribution, and change the headers to refer to this file. Then the source only contains the license information (plus references to the copyright and authors files in the distribution).  This is actually a much better way to handle copyrights (since the year and the copyright text is in one place, and can be annotated as required), yet does not change any rights on existing code.  
> Also, SVN is the master record for each individual contribution, so pending decision by the community, the "@author" tags would be removed from the code, which would refer to a new AUTHORS.txt file.
> The content of the AUTHORS.txt, COPYRIGHT.txt, and new header are attached.  Note that the Eclipse preferences need to be changed accordingly.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 21:51:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 21:51:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-272) Move the In-Memory
 connector into "dna-graph"
In-Reply-To: <18646014.1231956304031.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <82272.1232074263951.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-272.
-------------------------------

    Resolution: Done


Moved the In-Memory connector from its separate extension project and into the dna-graph project.  This change did cause the package names to differ slightly (the addition of the 'graph' intermediate package), and so this affected the repository example and the documentation.  Also changed the Maven files to remove the dna-connector-inmemory project.  All unit tests pass.

> Move the In-Memory connector into "dna-graph"
> ---------------------------------------------
>
>                 Key: DNA-272
>                 URL: https://jira.jboss.org/jira/browse/DNA-272
>             Project: DNA
>          Issue Type: Task
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The "in-memory" connector implementation is a good transient repository store, and having a transient store in "dna-graph" will simplify a number of things.  Right now, the only connectors are in extensions, so the core libraries (e.g., "dna-graph", "dna-repository", etc.) do not have access to any connector implementation, making it difficult to set up a default source.  For example, I'm working on a new configuration component in "dna-repository" that will set up all the DNA services, and the configuration component works by populating a configuration repository.  By default, the configuration component would instantiate a transient configuration repository, but there isn't an implementation available.  (The configuration component will also allow setting up the configuration repository, so one can use a remote source.)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 22:27:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 22:27:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-273) Define and document
 the official patch procedure
In-Reply-To: <2290513.1231958044394.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <13685268.1232076423967.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch commented on DNA-273:
-----------------------------------

Documented this procedure by adding a section to the "Developer Tools" chapter in the Reference Guide.


> Define and document the official patch procedure
> ------------------------------------------------
>
>                 Key: DNA-273
>                 URL: https://jira.jboss.org/jira/browse/DNA-273
>             Project: DNA
>          Issue Type: Task
>            Reporter: Randall Hauch
>             Fix For: 0.4
>
>
> We need to define our patch procedure so that it does not involve Eclipse patches, but rather uses standard patches that are compatible with SVN.  We then need to document this procedure in the Reference Guide.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 22:29:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 22:29:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-273) Define and document
 the official patch procedure
In-Reply-To: <2290513.1231958044394.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <2988144.1232076543946.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-273.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch


> Define and document the official patch procedure
> ------------------------------------------------
>
>                 Key: DNA-273
>                 URL: https://jira.jboss.org/jira/browse/DNA-273
>             Project: DNA
>          Issue Type: Task
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> We need to define our patch procedure so that it does not involve Eclipse patches, but rather uses standard patches that are compatible with SVN.  We then need to document this procedure in the Reference Guide.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 22:31:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 22:31:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-261) Improve how Binary
 values are created and managed
In-Reply-To: <20999853.1227459216412.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16873234.1232076664045.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-261:
------------------------------

    Fix Version/s: Future Releases
                       (was: 0.4)


Retargeting this to 0.5, since we've already added methods to the BinaryFactory interface for creating binary objects from a File.  This is probably sufficient for the time being, but we can provide in the future a new implementation that incorporates the benefits described in this issue.

> Improve how Binary values are created and managed
> -------------------------------------------------
>
>                 Key: DNA-261
>                 URL: https://jira.jboss.org/jira/browse/DNA-261
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Graph
>            Reporter: Randall Hauch
>            Priority: Minor
>             Fix For: Future Releases
>
>
> The current InMemoryBinaryValueFactory is creating separate InMemoryBinary objects each time 'create(...)' is called.  We should have a Binary factory (and corresponding Binary implementations) that caches the in-memory values using the content's hash as a key.  While this may slightly degrade performance (since the hash would be computed immediately rather than lazily if needed), it could result in more efficient use of memory.  Note that we'd probably have to use weak or soft references inside the Binary object to the cached values, so that as the Binary objects are garbage collected, the cache can remove the unused values.
> Another potential improvement is to store large values on disk, and to memory-map them using direct buffers.  This would keep large values (e.g., gigabyte-sized values, such as those used to represent very large files) out of memory.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 22:31:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 22:31:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-46) DNA should provide a
 JCR 1.0 API (JSR-170) implementation
Message-ID: <18466708.1232076664163.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reassigned DNA-46:
--------------------------------

    Assignee: Randall Hauch  (was: Johnny Verhaeg)


> DNA should provide a JCR 1.0 API (JSR-170) implementation
> ---------------------------------------------------------
>
>                 Key: DNA-46
>                 URL: https://jira.jboss.org/jira/browse/DNA-46
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, JCR
>    Affects Versions: 0.2
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.4
>
>
> DNA should provide a JCR 1.0 API (JSR-170) implementation.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 15 22:31:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 15 Jan 2009 22:31:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-194) Implement update JCR
	capability
In-Reply-To: <19952894.1218050517308.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <4047306.1232076664213.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reassigned DNA-194:
---------------------------------

    Assignee: Randall Hauch


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


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

        


From jira-events at lists.jboss.org  Fri Jan 16 13:36:03 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Fri, 16 Jan 2009 13:36:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-276) ExecutionContext story
 should be simplified by eliminating ExecutionContextFactory
Message-ID: <26667057.1232130963943.JavaMail.jira@cloud.prod.atl2.jboss.com>

ExecutionContext story should be simplified by eliminating ExecutionContextFactory
----------------------------------------------------------------------------------

                 Key: DNA-276
                 URL: https://jira.jboss.org/jira/browse/DNA-276
             Project: DNA
          Issue Type: Feature Request
          Components: Graph
    Affects Versions: 0.3
            Reporter: Johnny Verhaeg
             Fix For: 0.4


The relationship between the concrete ExecutionContext class and its implemented ExecutionContextFactory interface is a bit confusing and non-intuitive.  In particular, it's not really clear without understanding the implementation of ExecutionContext when to use the ExecutionContext constructor vs. the factory's create methods.  The factory should be eliminated, and the relevant "create" methods in the context should be changed to "with" methods, mimicking the other existing, more readable pattern used by ExecutionContext to, for instance, create a context with a different namespace registry.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 16 13:53:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 16 Jan 2009 13:53:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-276) ExecutionContext
 story should be simplified by eliminating ExecutionContextFactory
In-Reply-To: <26667057.1232130963943.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <11721908.1232131983997.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reassigned DNA-276:
---------------------------------

    Assignee: Randall Hauch


> ExecutionContext story should be simplified by eliminating ExecutionContextFactory
> ----------------------------------------------------------------------------------
>
>                 Key: DNA-276
>                 URL: https://jira.jboss.org/jira/browse/DNA-276
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Graph
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The relationship between the concrete ExecutionContext class and its implemented ExecutionContextFactory interface is a bit confusing and non-intuitive.  In particular, it's not really clear without understanding the implementation of ExecutionContext when to use the ExecutionContext constructor vs. the factory's create methods.  The factory should be eliminated, and the relevant "create" methods in the context should be changed to "with" methods, mimicking the other existing, more readable pattern used by ExecutionContext to, for instance, create a context with a different namespace registry.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 16 15:04:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 16 Jan 2009 15:04:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-276) ExecutionContext
 story should be simplified by eliminating ExecutionContextFactory
In-Reply-To: <26667057.1232130963943.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <19122057.1232136244004.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-276.
-------------------------------

    Resolution: Done


Remove the ExecutionContextFactory interface, and renamed the ExecutionContext.create(...) methods to 'with' (to mirror the other methods of creating a new context by changing an aspect).

> ExecutionContext story should be simplified by eliminating ExecutionContextFactory
> ----------------------------------------------------------------------------------
>
>                 Key: DNA-276
>                 URL: https://jira.jboss.org/jira/browse/DNA-276
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Graph
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The relationship between the concrete ExecutionContext class and its implemented ExecutionContextFactory interface is a bit confusing and non-intuitive.  In particular, it's not really clear without understanding the implementation of ExecutionContext when to use the ExecutionContext constructor vs. the factory's create methods.  The factory should be eliminated, and the relevant "create" methods in the context should be changed to "with" methods, mimicking the other existing, more readable pattern used by ExecutionContext to, for instance, create a context with a different namespace registry.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 16 15:45:04 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 16 Jan 2009 15:45:04 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-262) JCR-Level 2: Support
 persistent namespace changes
In-Reply-To: <19418054.1227540456463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <14925104.1232138704440.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-262:
------------------------------

    Fix Version/s: Future Releases
                       (was: 0.4)


> JCR-Level 2: Support persistent namespace changes
> -------------------------------------------------
>
>                 Key: DNA-262
>                 URL: https://jira.jboss.org/jira/browse/DNA-262
>             Project: DNA
>          Issue Type: Feature Request
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: Future Releases
>
>
> JCR Level 2 requires support for persisting changes to namespaces in the repository.  We can already support that with all of our connectors, since they're all able to store the namespace URIs for the content.  In fact, none of them currently store or use the prefixes.
> However, one thing DNA still doesn't have is the ability to manage the namespace prefixes in the connectors.  This probably will entail having a NamespaceRegistry implementation that can use a connector to populate the namespace registry.  This is a little tricky, tho, since the NamespaceRegistry is part of the ExecutionContext, which is passed to the connector's "execute(ExecutionContext,Request)" method.  So, while it is ideal that these namespace management methods are just additional requests, the dependency graph may imply that the namespace management methods need to be added to the RepositoryConnector interface.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 16 15:47:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 16 Jan 2009 15:47:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-262) JCR-Level 2: Support
 persistent namespace changes
In-Reply-To: <19418054.1227540456463.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24815402.1232138823963.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch reassigned DNA-262:
---------------------------------

    Assignee:     (was: Randall Hauch)


> JCR-Level 2: Support persistent namespace changes
> -------------------------------------------------
>
>                 Key: DNA-262
>                 URL: https://jira.jboss.org/jira/browse/DNA-262
>             Project: DNA
>          Issue Type: Feature Request
>          Components: JCR
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>             Fix For: Future Releases
>
>
> JCR Level 2 requires support for persisting changes to namespaces in the repository.  We can already support that with all of our connectors, since they're all able to store the namespace URIs for the content.  In fact, none of them currently store or use the prefixes.
> However, one thing DNA still doesn't have is the ability to manage the namespace prefixes in the connectors.  This probably will entail having a NamespaceRegistry implementation that can use a connector to populate the namespace registry.  This is a little tricky, tho, since the NamespaceRegistry is part of the ExecutionContext, which is passed to the connector's "execute(ExecutionContext,Request)" method.  So, while it is ideal that these namespace management methods are just additional requests, the dependency graph may imply that the namespace management methods need to be added to the RepositoryConnector interface.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 19 17:31:03 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 19 Jan 2009 17:31:03 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-277) Fix all text files in
 source code to have consistent line feeds
Message-ID: <21710954.1232404263947.JavaMail.jira@cloud.prod.atl2.jboss.com>

Fix all text files in source code to have consistent line feeds
---------------------------------------------------------------

                 Key: DNA-277
                 URL: https://jira.jboss.org/jira/browse/DNA-277
             Project: DNA
          Issue Type: Task
    Affects Versions: 0.3
            Reporter: Randall Hauch
            Assignee: Johnny Verhaeg
            Priority: Minor
             Fix For: 0.4


Currently, all of the text files in our source code have a mixture of carriage returns and line feeds.  And, our DNA preferences (for Eclipse) did not specify any special handling, so each developer's settings were used (and likely were the default settings for the platform).  Regardless of the preference settings, however, Eclipse editors always keep the line termination characters used in each particular file, so if a file was created on Windows, it will have \r\n for all lines, even when that file is modified on Linux or OS X.  There are a few cases where a file seems to have a mixture of line terminations.

We should probably have a consistent line terminator in all files, and that terminator should probably be '\n', which is the line terminator on *nix, for a couple of reasons.  First, the JBoss.org SVN repository is hosted on Linux, and being consistent probably helps somewhat.  Second, some tools (including Git) rely upon the '\n' character for determining line feeds, so that rules out the Mac style line feeds ('\r').  Third, there really is no need to store multiple characters.

We need to verify that the converting all files to use Unix line terminators is acceptable.  If so, we need to convert all of the files (that need it), update the Eclipse preferences, and have all developers make sure their Eclipse preference settings are correct.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 23 15:54:44 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Fri, 23 Jan 2009 15:54:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-274) commons-beanutils
 1.8.0 dependency needs to be uploaded to JBoss repository
In-Reply-To: <30747162.1232035625121.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1027192.1232744084176.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Johnny Verhaeg resolved DNA-274.
--------------------------------

    Resolution: Done


It's there now

> commons-beanutils 1.8.0 dependency needs to be uploaded to JBoss repository
> ---------------------------------------------------------------------------
>
>                 Key: DNA-274
>                 URL: https://jira.jboss.org/jira/browse/DNA-274
>             Project: DNA
>          Issue Type: Bug
>          Components: Development Environment
>    Affects Versions: 0.4
>            Reporter: Johnny Verhaeg
>            Assignee: Johnny Verhaeg
>            Priority: Blocker
>
> Both dna-common-jdbc and dna-connector-jdbc-metadata depend on this library.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 23 15:56:44 2009
From: jira-events at lists.jboss.org (Johnny Verhaeg (JIRA))
Date: Fri, 23 Jan 2009 15:56:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-277) Fix all text files in
 source code to have consistent line feeds
In-Reply-To: <21710954.1232404263947.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <20113756.1232744204143.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Johnny Verhaeg resolved DNA-277.
--------------------------------

    Resolution: Done


Changed preferences to set encoding to UTF-8 and create files using UNIX-style line delimiters.

> Fix all text files in source code to have consistent line feeds
> ---------------------------------------------------------------
>
>                 Key: DNA-277
>                 URL: https://jira.jboss.org/jira/browse/DNA-277
>             Project: DNA
>          Issue Type: Task
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Johnny Verhaeg
>            Priority: Minor
>             Fix For: 0.4
>
>
> Currently, all of the text files in our source code have a mixture of carriage returns and line feeds.  And, our DNA preferences (for Eclipse) did not specify any special handling, so each developer's settings were used (and likely were the default settings for the platform).  Regardless of the preference settings, however, Eclipse editors always keep the line termination characters used in each particular file, so if a file was created on Windows, it will have \r\n for all lines, even when that file is modified on Linux or OS X.  There are a few cases where a file seems to have a mixture of line terminations.
> We should probably have a consistent line terminator in all files, and that terminator should probably be '\n', which is the line terminator on *nix, for a couple of reasons.  First, the JBoss.org SVN repository is hosted on Linux, and being consistent probably helps somewhat.  Second, some tools (including Git) rely upon the '\n' character for determining line feeds, so that rules out the Mac style line feeds ('\r').  Third, there really is no need to store multiple characters.
> We need to verify that the converting all files to use Unix line terminators is acceptable.  If so, we need to convert all of the files (that need it), update the Eclipse preferences, and have all developers make sure their Eclipse preference settings are correct.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 28 21:15:54 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 28 Jan 2009 21:15:54 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-278) Create new utility
 class for determining validity of XML NCNames
Message-ID: <27662617.1233195354554.JavaMail.jira@cloud.prod.atl2.jboss.com>

Create new utility class for determining validity of XML NCNames
----------------------------------------------------------------

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


A namespace prefix in JCR must be a valid NCName, as defined by the XML specification.  We need a utility to perform this checking.  Currently, 'dna-common' is dependent upon only a minimal set of libraries (e.g,. logging and the optional JCIP annotations), and these do not have this utility.  A few libraries do have such utilities, but then we'd be dependent upon a library just for one class.

Implementation-wise, it doesn't seem to be too tough a nut to crack.  The only trick is how to quickly identify whether a character matches one (or more) of the character classes (as defined by the spec).  One approach would be to use ranges within each method, but that would require doing multiple math operations on each lookup.  The other approach would be to precompute the information so that lookups are fast.  Even with this latter approach there are multiple options for the structure:  have a bit set for each class keyed by character; the other is to have a one bitmask for each character (in a map or array).  The latter seems fastest (single index and a few bit operations) and smallest in memory footprint (only one data structure the size of the characters).


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 28 21:27:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 28 Jan 2009 21:27:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-279) Various improvements
 to the Graph API
Message-ID: <18200359.1233196064192.JavaMail.jira@cloud.prod.atl2.jboss.com>

Various improvements to the Graph API
-------------------------------------

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


The Graph API needs a few improvements, including:
1) add a request to verify the existance of a node (basically, this checks for existence and fetches the actual location)
2) add a way to copy a node by specifying the path of the desired location (in addition to the current mechanism of specifying the parent and inferring the name of the new node from the original).  This could be accomplished by adding the desired name to the CopyBranchRequest, and then updating all of the RequestProcessor implementations to use this optional information.  This may affect a number of classes.
3) make NamespaceRegistry.Namespace extend Comparable<Namespace> so that namespaces can be sorted naturally
4) improve the efficiency of the AbstractPath.equals(...) implementation, which is not efficiently iterating up the Path.Segment instances.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 28 21:34:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 28 Jan 2009 21:34:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-279) Various improvements
 to the Graph API
In-Reply-To: <18200359.1233196064192.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <16969344.1233196484189.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-279.
-------------------------------

    Resolution: Done


Made the improvements listed above.

> Various improvements to the Graph API
> -------------------------------------
>
>                 Key: DNA-279
>                 URL: https://jira.jboss.org/jira/browse/DNA-279
>             Project: DNA
>          Issue Type: Task
>          Components: API, Graph
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> The Graph API needs a few improvements, including:
> 1) add a request to verify the existance of a node (basically, this checks for existence and fetches the actual location)
> 2) add a way to copy a node by specifying the path of the desired location (in addition to the current mechanism of specifying the parent and inferring the name of the new node from the original).  This could be accomplished by adding the desired name to the CopyBranchRequest, and then updating all of the RequestProcessor implementations to use this optional information.  This may affect a number of classes.
> 3) make NamespaceRegistry.Namespace extend Comparable<Namespace> so that namespaces can be sorted naturally
> 4) improve the efficiency of the AbstractPath.equals(...) implementation, which is not efficiently iterating up the Path.Segment instances.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 28 21:34:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 28 Jan 2009 21:34:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-278) Create new utility
 class for determining validity of XML NCNames
In-Reply-To: <27662617.1233195354554.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <24114505.1233196484232.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch resolved DNA-278.
-------------------------------

    Resolution: Done


Created the implementation class by using a single structure to hold for each character a bitmask that describes the set of classifications that character belongs to.  For example, 'a' belongs to multiple character classes, so the bitmask ORs together the bitmask of each of those character classes.  A simple array is used to store all the bitmasks, indexed by the integer value of the character.  Then, each method (e.g., to check whether a character is a valid NCName starting character) simply has to look up the mask and perform a single bit operation.  (Some methods also have some shortcuts, as several of the classes have a very large range of characters (at the upper end) that are or are not in the character class, and these can be checked by simply comparing the integer value of the character with the lower end of the range.)

> Create new utility class for determining validity of XML NCNames
> ----------------------------------------------------------------
>
>                 Key: DNA-278
>                 URL: https://jira.jboss.org/jira/browse/DNA-278
>             Project: DNA
>          Issue Type: Task
>          Components: Common
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> A namespace prefix in JCR must be a valid NCName, as defined by the XML specification.  We need a utility to perform this checking.  Currently, 'dna-common' is dependent upon only a minimal set of libraries (e.g,. logging and the optional JCIP annotations), and these do not have this utility.  A few libraries do have such utilities, but then we'd be dependent upon a library just for one class.
> Implementation-wise, it doesn't seem to be too tough a nut to crack.  The only trick is how to quickly identify whether a character matches one (or more) of the character classes (as defined by the spec).  One approach would be to use ranges within each method, but that would require doing multiple math operations on each lookup.  The other approach would be to precompute the information so that lookups are fast.  Even with this latter approach there are multiple options for the structure:  have a bit set for each class keyed by character; the other is to have a one bitmask for each character (in a map or array).  The latter seems fastest (single index and a few bit operations) and smallest in memory footprint (only one data structure the size of the characters).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Jan 28 21:34:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 28 Jan 2009 21:34:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-278) Create new utility
 class for determining validity of XML NCNames
In-Reply-To: <27662617.1233195354554.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <7179821.1233196484282.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Randall Hauch updated DNA-278:
------------------------------

    Component/s: Common


> Create new utility class for determining validity of XML NCNames
> ----------------------------------------------------------------
>
>                 Key: DNA-278
>                 URL: https://jira.jboss.org/jira/browse/DNA-278
>             Project: DNA
>          Issue Type: Task
>          Components: Common
>    Affects Versions: 0.3
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.4
>
>
> A namespace prefix in JCR must be a valid NCName, as defined by the XML specification.  We need a utility to perform this checking.  Currently, 'dna-common' is dependent upon only a minimal set of libraries (e.g,. logging and the optional JCIP annotations), and these do not have this utility.  A few libraries do have such utilities, but then we'd be dependent upon a library just for one class.
> Implementation-wise, it doesn't seem to be too tough a nut to crack.  The only trick is how to quickly identify whether a character matches one (or more) of the character classes (as defined by the spec).  One approach would be to use ranges within each method, but that would require doing multiple math operations on each lookup.  The other approach would be to precompute the information so that lookups are fast.  Even with this latter approach there are multiple options for the structure:  have a bit set for each class keyed by character; the other is to have a one bitmask for each character (in a map or array).  The latter seems fastest (single index and a few bit operations) and smallest in memory footprint (only one data structure the size of the characters).

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

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


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  Wed Jan 28 22:00:44 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 28 Jan 2009 22:00: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: <20338814.1233198044192.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=12450171#action_12450171 ] 

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

Approach #2 happens to match the way that Graph instances are created.  Plus, just because we use factory methods doesn't mean that someone could extend Location, define their own factory implementations in their subclass, and then use those.  It just means that we wouldn't use them anywhere.

> 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
>
>
> 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 Jan 30 02:47:44 2009
From: jira-events at lists.jboss.org (Serge Emmanuel Pagop (JIRA))
Date: Fri, 30 Jan 2009 02:47:44 -0500 (EST)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-239) code test case for
 SVNRepositorySource used to manage the repos. content
In-Reply-To: <1909384.1224576860902.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <26466886.1233301664185.JavaMail.jira@cloud.prod.atl2.jboss.com>


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

Serge Emmanuel Pagop updated DNA-239:
-------------------------------------

    Summary: code test case for SVNRepositorySource used to manage the repos. content  (was: code test case for SVNRepositorySource used to mange the repos. content)


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


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

        


