From jira-events at lists.jboss.org  Wed Sep  2 09:22:24 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 2 Sep 2009 09:22:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-510) The JPA
 RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto'
 property
Message-ID: <595358742.1251897744336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

The JPA RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto' property
--------------------------------------------------------------------------------------------

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


The 'hibernate.hbm2ddl.auto' property defines Hibernate's behavior for interacting/changing the database schema.  Typically in production the database schema should already exist and should not be changed, while for development users may want to have Hibernate dynamically create the schema.  Therefore, one value is not sufficient, and the JpaSource class should allow setting this value.

(It may be worthwhile to add the ability to set arbitrary properties on the JpaSource, and then modify the DnaConfiguration and DnaEngine code to look for JavaBean methods for the properties, and if there are none to look for and use a "setProperty(String,String)" method on the RepositorySource.  This would make it possible to always add any Hibernate property to the JpaSource configuration.)

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

        

From jira-events at lists.jboss.org  Wed Sep  2 09:27:24 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 2 Sep 2009 09:27:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-511) The JPA Source should
 provide a way of producing the DDL for the database dialect
Message-ID: <314441080.1251898044107.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

The JPA Source should provide a way of producing the DDL for the database dialect
---------------------------------------------------------------------------------

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


Hibernate is capable of dynamically creating the schema, but this is really only practical in a development environment.  Production environments will rarely (ever?) want to allow the software to change the database, so having the DDL for the database used by the JpaSource would be very useful to have.  Hibernate is capable of generating this, and we should provide a mechanism for producing the DDL for the configured dialect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  2 09:31:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 2 Sep 2009 09:31:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-511) The JPA Source
 should provide a way of producing the DDL for the database dialect
In-Reply-To: <314441080.1251898044107.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <723304862.1251898283836.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-511:
-----------------------------------

One approach might be to provide a separate method that could be used in a simple Java application to produce the DDL, though this would likely require code to do this.  Another (potentially better) option is to specify a RepositorySource property that defines the file system path where this file should be generated, and upon startup the JpaSource would check this property and, if supplied, would generate the DDL definition.

Other suggestions are welcomed!

> The JPA Source should provide a way of producing the DDL for the database dialect
> ---------------------------------------------------------------------------------
>
>                 Key: DNA-511
>                 URL: https://jira.jboss.org/jira/browse/DNA-511
>             Project: DNA
>          Issue Type: Feature Request
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>             Fix For: 0.7
>
>
> Hibernate is capable of dynamically creating the schema, but this is really only practical in a development environment.  Production environments will rarely (ever?) want to allow the software to change the database, so having the DDL for the database used by the JpaSource would be very useful to have.  Hibernate is capable of generating this, and we should provide a mechanism for producing the DDL for the configured dialect.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  2 09:33:24 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 2 Sep 2009 09:33:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-510) The JPA
 RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto'
 property
In-Reply-To: <595358742.1251897744336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2018362982.1251898404354.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-510:
-----------------------------------

meetoblivion posted a potential (and untested) patch on the forum: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160702&postdays=0&postorder=asc&start=10

> The JPA RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto' property
> --------------------------------------------------------------------------------------------
>
>                 Key: DNA-510
>                 URL: https://jira.jboss.org/jira/browse/DNA-510
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>
> The 'hibernate.hbm2ddl.auto' property defines Hibernate's behavior for interacting/changing the database schema.  Typically in production the database schema should already exist and should not be changed, while for development users may want to have Hibernate dynamically create the schema.  Therefore, one value is not sufficient, and the JpaSource class should allow setting this value.
> (It may be worthwhile to add the ability to set arbitrary properties on the JpaSource, and then modify the DnaConfiguration and DnaEngine code to look for JavaBean methods for the properties, and if there are none to look for and use a "setProperty(String,String)" method on the RepositorySource.  This would make it possible to always add any Hibernate property to the JpaSource configuration.)

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

        

From jira-events at lists.jboss.org  Wed Sep  2 09:33:24 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 2 Sep 2009 09:33:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-510) The JPA
 RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto'
 property
In-Reply-To: <595358742.1251897744336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2076564525.1251898404729.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-510:
------------------------------

    Priority: Blocker  (was: Major)


> The JPA RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto' property
> --------------------------------------------------------------------------------------------
>
>                 Key: DNA-510
>                 URL: https://jira.jboss.org/jira/browse/DNA-510
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The 'hibernate.hbm2ddl.auto' property defines Hibernate's behavior for interacting/changing the database schema.  Typically in production the database schema should already exist and should not be changed, while for development users may want to have Hibernate dynamically create the schema.  Therefore, one value is not sufficient, and the JpaSource class should allow setting this value.
> (It may be worthwhile to add the ability to set arbitrary properties on the JpaSource, and then modify the DnaConfiguration and DnaEngine code to look for JavaBean methods for the properties, and if there are none to look for and use a "setProperty(String,String)" method on the RepositorySource.  This would make it possible to always add any Hibernate property to the JpaSource configuration.)

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

        

From jira-events at lists.jboss.org  Thu Sep  3 12:11:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 12:11:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-509) JPA Connector does
 not close all EntityManager instances that it creates
In-Reply-To: <1433619840.1251558923831.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1978849605.1251994283698.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-509:
-----------------------------------

Added to the JPA Connector project a new class that allows JpaSource and JpaConnection to hold onto a JPA EntityManager and EntityManagerFactory, while ensuring that the EntityManager and EntityManagerFactory instances are ALWAYS closed - as long as the JpaConnection objects and JpaSource objects are always closed (in any order).  It also allows the JpaSource to start using a new EntityManagerFactory if the settings are changed, without impacting any previously-opened and in-use connections.

Although I did try to find a way for the JpaSource to not have a 'close()' method, it simply was not possible to do without adding TREMENDOUS overhead to the creation of an EntityManagerFactory for every connection (remember, the EntityManagerFactory must be configured with each entity class, and does the schema validation/create/drop/update operations, and this had to be done on EVERY create new connection).  And rather than have 'close()' be an artifact of the JpaSource class, it's actually better if this method is defined on the RepositorySource interface and that all implementations provide a close() method.  This provides a standard way for the RepositorySource implementations to begin reclaiming resources such as connections, caches, files, and/or large objects.  RepositoryLibrary and RepositoryService were modified to ensure that all RepositorySource objects are closed when the library and service are shutdown (via their administrative interface).

The reusable connector framework unit tests were also modified to ensure that they all close the RepositorySource upon teardown of the tests (or, in the case of the reading tests, upon teardown after all tests are run).

> JPA Connector does not close all EntityManager instances that it creates
> ------------------------------------------------------------------------
>
>                 Key: DNA-509
>                 URL: https://jira.jboss.org/jira/browse/DNA-509
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JPA connector acquires several EntityManager instances, but does not close all of them.  This can cause a memory leak in the code, and can cause the JVM to run out of memory.  Because the EntityManager is the manager for all of the JPA entity beans (obviously), not closing them will retain objects in memory and prevent them from being garbage collected.
> There doesn't appear to be an easy way with the current JpaSource and JpaConnection design to properly do this, other than call the JpaSource.close() method.  Unfortunately that does not always work, as the current implementation of JpaSource.getConnection() may (if the model is changed) create a new EntityManagerFactory.  And even if the JpaConnection did close the EntityManager it's using, the JpaSource's EntityManagerFactory is not guaranteed to be called (even if we adopt a new RepositorySource.close() and require it to be called everywhere).
> The best way to fix this might be for the JpaSource to not have to maintain all this state (like it currently does), but instead to have an object in-between the JpaSource and JpaConnection that maintains the EntityManagerFactory and creates EntityManagers as needed.  The JpaSource can hold onto this, but wouldn't own the instances.  This intermediate object can always ensure that all EntityManagers and EntityManagerFactories are closed when no longer needed (e.g., using reference counts and a "last-one-to-leave-turn-the-lights-off" approach).  JpaConnection.close() would obvious signal to this object that it no longer needs its EntityManager.  
> JpaSource cannot properly do all this management, because its bean properties can be changed at any time, meaning that even after some connections to one database have been created, the JpaSource can be changed and pointed to a different database.  Yes, this isn't good practice, but it technically is possible and thus needs to be addressed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 12:15:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 12:15:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-509) JPA Connector does
 not close all EntityManager instances that it creates
In-Reply-To: <1433619840.1251558923831.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1972867447.1251994523620.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-509:
-----------------------------------

I should add that the RepositorySource is still usable after close() has been called, but if it is used (especially if getConnection() is called) then close() must be called again.  This was documented on the JavaDoc for RepositorySource.close().

> JPA Connector does not close all EntityManager instances that it creates
> ------------------------------------------------------------------------
>
>                 Key: DNA-509
>                 URL: https://jira.jboss.org/jira/browse/DNA-509
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JPA connector acquires several EntityManager instances, but does not close all of them.  This can cause a memory leak in the code, and can cause the JVM to run out of memory.  Because the EntityManager is the manager for all of the JPA entity beans (obviously), not closing them will retain objects in memory and prevent them from being garbage collected.
> There doesn't appear to be an easy way with the current JpaSource and JpaConnection design to properly do this, other than call the JpaSource.close() method.  Unfortunately that does not always work, as the current implementation of JpaSource.getConnection() may (if the model is changed) create a new EntityManagerFactory.  And even if the JpaConnection did close the EntityManager it's using, the JpaSource's EntityManagerFactory is not guaranteed to be called (even if we adopt a new RepositorySource.close() and require it to be called everywhere).
> The best way to fix this might be for the JpaSource to not have to maintain all this state (like it currently does), but instead to have an object in-between the JpaSource and JpaConnection that maintains the EntityManagerFactory and creates EntityManagers as needed.  The JpaSource can hold onto this, but wouldn't own the instances.  This intermediate object can always ensure that all EntityManagers and EntityManagerFactories are closed when no longer needed (e.g., using reference counts and a "last-one-to-leave-turn-the-lights-off" approach).  JpaConnection.close() would obvious signal to this object that it no longer needs its EntityManager.  
> JpaSource cannot properly do all this management, because its bean properties can be changed at any time, meaning that even after some connections to one database have been created, the JpaSource can be changed and pointed to a different database.  Yes, this isn't good practice, but it technically is possible and thus needs to be addressed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 14:55:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 14:55:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-509) JPA Connector does
 not close all EntityManager instances that it creates
In-Reply-To: <1433619840.1251558923831.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <647649299.1252004123575.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-509.
-------------------------------

    Resolution: Done


Marking as resolved, since this appears to have fixed all issues with running the full suite of unit tests.

> JPA Connector does not close all EntityManager instances that it creates
> ------------------------------------------------------------------------
>
>                 Key: DNA-509
>                 URL: https://jira.jboss.org/jira/browse/DNA-509
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The JPA connector acquires several EntityManager instances, but does not close all of them.  This can cause a memory leak in the code, and can cause the JVM to run out of memory.  Because the EntityManager is the manager for all of the JPA entity beans (obviously), not closing them will retain objects in memory and prevent them from being garbage collected.
> There doesn't appear to be an easy way with the current JpaSource and JpaConnection design to properly do this, other than call the JpaSource.close() method.  Unfortunately that does not always work, as the current implementation of JpaSource.getConnection() may (if the model is changed) create a new EntityManagerFactory.  And even if the JpaConnection did close the EntityManager it's using, the JpaSource's EntityManagerFactory is not guaranteed to be called (even if we adopt a new RepositorySource.close() and require it to be called everywhere).
> The best way to fix this might be for the JpaSource to not have to maintain all this state (like it currently does), but instead to have an object in-between the JpaSource and JpaConnection that maintains the EntityManagerFactory and creates EntityManagers as needed.  The JpaSource can hold onto this, but wouldn't own the instances.  This intermediate object can always ensure that all EntityManagers and EntityManagerFactories are closed when no longer needed (e.g., using reference counts and a "last-one-to-leave-turn-the-lights-off" approach).  JpaConnection.close() would obvious signal to this object that it no longer needs its EntityManager.  
> JpaSource cannot properly do all this management, because its bean properties can be changed at any time, meaning that even after some connections to one database have been created, the JpaSource can be changed and pointed to a different database.  Yes, this isn't good practice, but it technically is possible and thus needs to be addressed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 14:59:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 14:59:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-512) Add simple example (or
 integration test) that shows all of the code required to use JCR with a
 JDBC database
Message-ID: <1097746861.1252004363692.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Add simple example (or integration test) that shows all of the code required to use JCR with a JDBC database
------------------------------------------------------------------------------------------------------------

                 Key: DNA-512
                 URL: https://jira.jboss.org/jira/browse/DNA-512
             Project: DNA
          Issue Type: Task
          Components: Documentation, Examples, JCR, Testing
    Affects Versions: 0.5
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Minor
             Fix For: 0.6


We don't have an integration test that shows how to set up a JCR repository instance to use a JDBC database.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 15:07:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 15:07:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-512) Add simple example
 (or integration test) that shows all of the code required to use JCR with a
 JDBC database
In-Reply-To: <1097746861.1252004363692.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <155683561.1252004843651.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-512:
-----------------------------------

Created a new JcrRepositoryWithJpaConfigurationTest in the 'dna-integration-test' project that shows from start to finish how to configure a JBoss DNA JCR repository to use a JDBC database (in this case, HSQLDB).

Also updated the Reference Guide to more clearly document how to use custom security mechanisms.

> Add simple example (or integration test) that shows all of the code required to use JCR with a JDBC database
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-512
>                 URL: https://jira.jboss.org/jira/browse/DNA-512
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation, Examples, JCR, Testing
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.6
>
>
> We don't have an integration test that shows how to set up a JCR repository instance to use a JDBC database.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 15:09:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 15:09:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-512) Add simple example
 (or integration test) that shows all of the code required to use JCR with a
 JDBC database
In-Reply-To: <1097746861.1252004363692.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <485010467.1252004963546.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-512.
-------------------------------

    Resolution: Done


> Add simple example (or integration test) that shows all of the code required to use JCR with a JDBC database
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-512
>                 URL: https://jira.jboss.org/jira/browse/DNA-512
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation, Examples, JCR, Testing
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Minor
>             Fix For: 0.6
>
>
> We don't have an integration test that shows how to set up a JCR repository instance to use a JDBC database.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 16:03:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 16:03:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-510) The JPA
 RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto'
 property
In-Reply-To: <595358742.1251897744336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1791866571.1252008203609.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-510:
------------------------------

    Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration]  (was: [Documentation (Ref Guide, User Guide, etc.)])


> The JPA RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto' property
> --------------------------------------------------------------------------------------------
>
>                 Key: DNA-510
>                 URL: https://jira.jboss.org/jira/browse/DNA-510
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The 'hibernate.hbm2ddl.auto' property defines Hibernate's behavior for interacting/changing the database schema.  Typically in production the database schema should already exist and should not be changed, while for development users may want to have Hibernate dynamically create the schema.  Therefore, one value is not sufficient, and the JpaSource class should allow setting this value.
> (It may be worthwhile to add the ability to set arbitrary properties on the JpaSource, and then modify the DnaConfiguration and DnaEngine code to look for JavaBean methods for the properties, and if there are none to look for and use a "setProperty(String,String)" method on the RepositorySource.  This would make it possible to always add any Hibernate property to the JpaSource configuration.)

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

        

From jira-events at lists.jboss.org  Thu Sep  3 16:03:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 16:03:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-510) The JPA
 RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto'
 property
In-Reply-To: <595358742.1251897744336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <118947161.1252008203583.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-510:
-----------------------------------

Applied a modified version of the patch.  Note that the default 'autoGenerateSchema' property value is now 'validate', since that is the least disruptive on an existing database (such as a production database).  Therefore, note that 'create' used to be the default, so this may affect some users.

Updated the JPA Connector chapter in the Reference Guide to include the new property.

> The JPA RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto' property
> --------------------------------------------------------------------------------------------
>
>                 Key: DNA-510
>                 URL: https://jira.jboss.org/jira/browse/DNA-510
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The 'hibernate.hbm2ddl.auto' property defines Hibernate's behavior for interacting/changing the database schema.  Typically in production the database schema should already exist and should not be changed, while for development users may want to have Hibernate dynamically create the schema.  Therefore, one value is not sufficient, and the JpaSource class should allow setting this value.
> (It may be worthwhile to add the ability to set arbitrary properties on the JpaSource, and then modify the DnaConfiguration and DnaEngine code to look for JavaBean methods for the properties, and if there are none to look for and use a "setProperty(String,String)" method on the RepositorySource.  This would make it possible to always add any Hibernate property to the JpaSource configuration.)

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

        

From jira-events at lists.jboss.org  Thu Sep  3 16:03:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 16:03:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-510) The JPA
 RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto'
 property
In-Reply-To: <595358742.1251897744336.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <847537350.1252008203631.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-510.
-------------------------------

    Resolution: Done


Marking as resolved.

> The JPA RepositorySource should provide way to specify the 'hibernate.hbm2ddl.auto' property
> --------------------------------------------------------------------------------------------
>
>                 Key: DNA-510
>                 URL: https://jira.jboss.org/jira/browse/DNA-510
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The 'hibernate.hbm2ddl.auto' property defines Hibernate's behavior for interacting/changing the database schema.  Typically in production the database schema should already exist and should not be changed, while for development users may want to have Hibernate dynamically create the schema.  Therefore, one value is not sufficient, and the JpaSource class should allow setting this value.
> (It may be worthwhile to add the ability to set arbitrary properties on the JpaSource, and then modify the DnaConfiguration and DnaEngine code to look for JavaBean methods for the properties, and if there are none to look for and use a "setProperty(String,String)" method on the RepositorySource.  This would make it possible to always add any Hibernate property to the JpaSource configuration.)

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

        

From jira-events at lists.jboss.org  Thu Sep  3 16:20:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 16:20:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-505) Svn Repository
 Source with NPE and other issues while opening connection through Jcr
In-Reply-To: <1214704392.1251291863532.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1239141367.1252009223711.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-505:
-----------------------------------

Ah, I believe I know what the problem is.  "nt:resource" (the node type used for the "jcr:data" child node under each "nt:file" object) is required by the JCR specification to have "mix:referenceable", but the SVN connector is likely not including a jcr:uuid property in the list.  I'll modify my test case to see if this is the case.

> Svn Repository Source with NPE and other issues while opening connection through Jcr
> ------------------------------------------------------------------------------------
>
>                 Key: DNA-505
>                 URL: https://jira.jboss.org/jira/browse/DNA-505
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>         Environment: Mac OS X 10.5 - Jvm 1.5 - Maven 2
>            Reporter: Luiz Fernando Teston
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>         Attachments: 0001-fixing-a-few-null-pointer-exeptions.patch, DnaSvnUsingJcrWithProgramaticConfigurationTest.java
>
>
> Durring a test run to read data from some svn repository using Jcr api from DNA, it throws NullPointerException when trying to read jcr:content for nodes of type folder. This NPEs was really easy to solve. So, I created a patch for this. After this patch, when running the same unit test, it throws a repository source exception saying "svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace".
> The stack trace is here also:
> org.jboss.dna.graph.connector.RepositorySourceException: svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.checkThePath(SVNRepositoryRequestProcessor.java:1000)
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.process(SVNRepositoryRequestProcessor.java:151)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:641)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:239)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
> 	at org.jboss.dna.connector.svn.SVNRepositoryConnection.execute(SVNRepositoryConnection.java:176)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:314)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
> 	at java.lang.Thread.run(Thread.java:613)
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 16:56:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 16:56:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-505) Svn Repository
 Source with NPE and other issues while opening connection through Jcr
In-Reply-To: <1214704392.1251291863532.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1449955223.1252011383550.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-505:
-----------------------------------

Yes, that was indeed the problem (though it's not the 'jcr:data' child node, it's 'jcr:content' - oops).  And I was able to reproduce this in the integration test.

There really isn't a durable UUID available for each file in SVN (there is a single UUID for each repository, though).  And so the SVN connector does not return a 'jcr:uuid' property for the 'jcr:content' node, and this fouls up the SessionCache implementation.  However, while 'nt:file' and 'nt:folder' are not referenceable, 'nt:resource' is.  But lucky for us that the JCR spec does not require that the 'jcr:content' node has a type of 'nt:resource'; it merely says:

        "A common approach is to make the jcr:content a node of type nt:resource." (Section 6.7.22.6 of the 1.0.1 version of the JCR specification, page 160.)

So, a solution is to do the same thing we did in the file system connector: use a 'dna:resource' node type that is identical to 'nt:resource' except that it does not extend 'mix:referenceable'.  This appears to have fixed the problem.

> Svn Repository Source with NPE and other issues while opening connection through Jcr
> ------------------------------------------------------------------------------------
>
>                 Key: DNA-505
>                 URL: https://jira.jboss.org/jira/browse/DNA-505
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>         Environment: Mac OS X 10.5 - Jvm 1.5 - Maven 2
>            Reporter: Luiz Fernando Teston
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>         Attachments: 0001-fixing-a-few-null-pointer-exeptions.patch, DnaSvnUsingJcrWithProgramaticConfigurationTest.java
>
>
> Durring a test run to read data from some svn repository using Jcr api from DNA, it throws NullPointerException when trying to read jcr:content for nodes of type folder. This NPEs was really easy to solve. So, I created a patch for this. After this patch, when running the same unit test, it throws a repository source exception saying "svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace".
> The stack trace is here also:
> org.jboss.dna.graph.connector.RepositorySourceException: svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.checkThePath(SVNRepositoryRequestProcessor.java:1000)
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.process(SVNRepositoryRequestProcessor.java:151)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:641)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:239)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
> 	at org.jboss.dna.connector.svn.SVNRepositoryConnection.execute(SVNRepositoryConnection.java:176)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:314)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
> 	at java.lang.Thread.run(Thread.java:613)
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 16:58:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 16:58:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-505) Svn Repository
 Source with NPE and other issues while opening connection through Jcr
In-Reply-To: <1214704392.1251291863532.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1095335071.1252011503546.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-505:
-----------------------------------

Feu, would you mind getting the latest from trunk (revision 1193 or later) and trying out the SVN connector?  Please let me know how it goes.

> Svn Repository Source with NPE and other issues while opening connection through Jcr
> ------------------------------------------------------------------------------------
>
>                 Key: DNA-505
>                 URL: https://jira.jboss.org/jira/browse/DNA-505
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>         Environment: Mac OS X 10.5 - Jvm 1.5 - Maven 2
>            Reporter: Luiz Fernando Teston
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>         Attachments: 0001-fixing-a-few-null-pointer-exeptions.patch, DnaSvnUsingJcrWithProgramaticConfigurationTest.java
>
>
> Durring a test run to read data from some svn repository using Jcr api from DNA, it throws NullPointerException when trying to read jcr:content for nodes of type folder. This NPEs was really easy to solve. So, I created a patch for this. After this patch, when running the same unit test, it throws a repository source exception saying "svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace".
> The stack trace is here also:
> org.jboss.dna.graph.connector.RepositorySourceException: svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.checkThePath(SVNRepositoryRequestProcessor.java:1000)
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.process(SVNRepositoryRequestProcessor.java:151)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:641)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:239)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
> 	at org.jboss.dna.connector.svn.SVNRepositoryConnection.execute(SVNRepositoryConnection.java:176)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:314)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
> 	at java.lang.Thread.run(Thread.java:613)
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 17:00:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 17:00:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-464) Add use of file system
 connector to repositories example
In-Reply-To: <15709139.1245257456331.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <200225578.1252011623555.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-464:
------------------------------

    Fix Version/s: 0.7
                       (was: 0.6)


> Add use of file system connector to repositories example
> --------------------------------------------------------
>
>                 Key: DNA-464
>                 URL: https://jira.jboss.org/jira/browse/DNA-464
>             Project: DNA
>          Issue Type: Task
>          Components: Documentation, Examples, Federation
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>             Fix For: 0.7
>
>
> See DNA-462 for an issue raised by feu trying to use the file system connector in a federated repository.  The repositories example of the Getting Started document should show how to do this.

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

        

From jira-events at lists.jboss.org  Thu Sep  3 17:04:35 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 17:04:35 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-513) REST server does not
 correctly encode binary values
Message-ID: <1103556934.1252011875497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

REST server does not correctly encode binary values
---------------------------------------------------

                 Key: DNA-513
                 URL: https://jira.jboss.org/jira/browse/DNA-513
             Project: DNA
          Issue Type: Bug
          Components: Web Application
    Affects Versions: 0.5
            Reporter: Randall Hauch
            Assignee: Brian Carothers
             Fix For: 0.6


The REST server (or rather web application) does not properly encode binary values in the JSON results, and instead is embedding the toString() version of the byte[].  The binary values should instead be encoded in Base64, and the REST client should be able to then read (or upload) binary values using this approach.

(If the binary value is already a Base64-encoded representation, then the JSON content will just be a Base64-encoded representation of the value that happens to be Base64-encoded. Shouldn't be a problem.)

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

        

From jira-events at lists.jboss.org  Thu Sep  3 17:06:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 17:06:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-513) REST server does not
 correctly encode binary values
In-Reply-To: <1103556934.1252011875497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1393692863.1252011983542.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-513:
------------------------------

    Priority: Blocker  (was: Major)


Changed to BLOCKER, since this is a pretty big deal.  Brian has started looking at it, but I'll also take a look.

> REST server does not correctly encode binary values
> ---------------------------------------------------
>
>                 Key: DNA-513
>                 URL: https://jira.jboss.org/jira/browse/DNA-513
>             Project: DNA
>          Issue Type: Bug
>          Components: Web Application
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>            Priority: Blocker
>             Fix For: 0.6
>
>
> The REST server (or rather web application) does not properly encode binary values in the JSON results, and instead is embedding the toString() version of the byte[].  The binary values should instead be encoded in Base64, and the REST client should be able to then read (or upload) binary values using this approach.
> (If the binary value is already a Base64-encoded representation, then the JSON content will just be a Base64-encoded representation of the value that happens to be Base64-encoded. Shouldn't be a problem.)

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

        

From jira-events at lists.jboss.org  Thu Sep  3 17:08:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 17:08:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-499) Wrap system access,
 context class loader access, and reflection with doPrivileged
In-Reply-To: <1931841278.1249401689050.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <205984725.1252012103605.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-499:
-----------------------------------

I'm tempted to push this into 0.7, since it is not terribly critical yet, but it may touch several very critical parts of the code.  Thoughts?

> Wrap system access, context class loader access, and reflection with doPrivileged
> ---------------------------------------------------------------------------------
>
>                 Key: DNA-499
>                 URL: https://jira.jboss.org/jira/browse/DNA-499
>             Project: DNA
>          Issue Type: Bug
>          Components: API, Common, Connectors, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Vijay Kiran Duvvuri
>             Fix For: 0.6
>
>         Attachments: DNA-499.1.patch
>
>
> Several activities should make use of the Java SecurityManager to ensure the caller has the appropriate privileges to perform the activity.  These activities should be wrapped in a block such as the following:
> String lineSeparator = java.security.AccessController.doPrivileged(
>     new java.security.PrivilegedAction<String>() {
>         public String run() {
>             return System.getProperty("line.separator");
>         }
>     }
>  );
> obviously with the correct generic type for whatever is being returned from the run.  (Nice and concise, huh? Ugh.)
> We need to go through all of the (non-test) code and add this checking (if it is not already there) when the following types of activities are performed:
> - System.getProperty
> - System.setProperty
> - Thread.currentThread().getContextClassLoader()
> - All code executed via reflection

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 17:36:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 17:36:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-514) Update Base64 class
Message-ID: <1095720300.1252013783533.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update Base64 class
-------------------

                 Key: DNA-514
                 URL: https://jira.jboss.org/jira/browse/DNA-514
             Project: DNA
          Issue Type: Task
    Affects Versions: 0.6
            Reporter: Randall Hauch
             Fix For: 0.7


There is an updated version of the public domain Base64 class that we use, and it has a number of significant improvements and bug fixes.  However, it is no longer a drop-in replacement (plus we made a number of changes to fix formatting and behavior).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  3 17:53:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 3 Sep 2009 17:53:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-513) REST server does not
 correctly encode binary values
In-Reply-To: <1103556934.1252011875497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1979645371.1252014803737.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-513:
------------------------------

    Attachment: dna-513.1.patch


See attached patch that enhances the Base64 class to add the necessary method to work with an InputStream source, and fixes the JSON encoding from the server.  However, it does not yet address setting a property to a value that is Base64-encoded.

This is a git patch, so please apply with a 'patch -p1 dna-513.1.patch'.

> REST server does not correctly encode binary values
> ---------------------------------------------------
>
>                 Key: DNA-513
>                 URL: https://jira.jboss.org/jira/browse/DNA-513
>             Project: DNA
>          Issue Type: Bug
>          Components: Web Application
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: dna-513.1.patch
>
>
> The REST server (or rather web application) does not properly encode binary values in the JSON results, and instead is embedding the toString() version of the byte[].  The binary values should instead be encoded in Base64, and the REST client should be able to then read (or upload) binary values using this approach.
> (If the binary value is already a Base64-encoded representation, then the JSON content will just be a Base64-encoded representation of the value that happens to be Base64-encoded. Shouldn't be a problem.)

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

        

From jira-events at lists.jboss.org  Fri Sep  4 12:59:23 2009
From: jira-events at lists.jboss.org (Vijay Kiran Duvvuri (JIRA))
Date: Fri, 4 Sep 2009 12:59:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-499) Wrap system access,
 context class loader access, and reflection with doPrivileged
In-Reply-To: <1931841278.1249401689050.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1341051779.1252083563634.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Vijay Kiran Duvvuri commented on DNA-499:
-----------------------------------------

I also suggest we move it to 0.7, since there's lot of testing need to be done along with it.

> Wrap system access, context class loader access, and reflection with doPrivileged
> ---------------------------------------------------------------------------------
>
>                 Key: DNA-499
>                 URL: https://jira.jboss.org/jira/browse/DNA-499
>             Project: DNA
>          Issue Type: Bug
>          Components: API, Common, Connectors, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Vijay Kiran Duvvuri
>             Fix For: 0.6
>
>         Attachments: DNA-499.1.patch
>
>
> Several activities should make use of the Java SecurityManager to ensure the caller has the appropriate privileges to perform the activity.  These activities should be wrapped in a block such as the following:
> String lineSeparator = java.security.AccessController.doPrivileged(
>     new java.security.PrivilegedAction<String>() {
>         public String run() {
>             return System.getProperty("line.separator");
>         }
>     }
>  );
> obviously with the correct generic type for whatever is being returned from the run.  (Nice and concise, huh? Ugh.)
> We need to go through all of the (non-test) code and add this checking (if it is not already there) when the following types of activities are performed:
> - System.getProperty
> - System.setProperty
> - Thread.currentThread().getContextClassLoader()
> - All code executed via reflection

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  4 13:53:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 4 Sep 2009 13:53:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-499) Wrap system access,
 context class loader access, and reflection with doPrivileged
In-Reply-To: <1931841278.1249401689050.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <294199383.1252086803648.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-499:
------------------------------

    Fix Version/s: 0.7
                       (was: 0.6)


Pushing to 0.7, as discussed above.

> Wrap system access, context class loader access, and reflection with doPrivileged
> ---------------------------------------------------------------------------------
>
>                 Key: DNA-499
>                 URL: https://jira.jboss.org/jira/browse/DNA-499
>             Project: DNA
>          Issue Type: Bug
>          Components: API, Common, Connectors, Examples, Federation, Graph, JCR, Maven Classloader, Sequencers
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Vijay Kiran Duvvuri
>             Fix For: 0.7
>
>         Attachments: DNA-499.1.patch
>
>
> Several activities should make use of the Java SecurityManager to ensure the caller has the appropriate privileges to perform the activity.  These activities should be wrapped in a block such as the following:
> String lineSeparator = java.security.AccessController.doPrivileged(
>     new java.security.PrivilegedAction<String>() {
>         public String run() {
>             return System.getProperty("line.separator");
>         }
>     }
>  );
> obviously with the correct generic type for whatever is being returned from the run.  (Nice and concise, huh? Ugh.)
> We need to go through all of the (non-test) code and add this checking (if it is not already there) when the following types of activities are performed:
> - System.getProperty
> - System.setProperty
> - Thread.currentThread().getContextClassLoader()
> - All code executed via reflection

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  8 12:15:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 8 Sep 2009 12:15:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-513) REST server does not
 correctly encode binary values
In-Reply-To: <1103556934.1252011875497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <722113911.1252426523880.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-513:
-----------------------------------

I talked with Brian about this, and perhaps the most challenging aspect of this is knowing which properties (if any) are encoded in a client PUT/POST request.  Either every property value has to be looked at as possibly being encoded, or there has to be some annotation in the request defining whether a property value is encoded.  The former is expensive and potentially error prone (e.g., if a string property value is stored already encoded in the repository, or if a string property coincidentally matches an encoded representation).  The latter approach is less attractive, but is really the only surefire way for the client and server to know which properties have been encoded in the request and must be decoded prior to use.

There seem to be two options for annotating the properties: include the annotation in the name or in the value.  Annotating the name is quite straightforward as long as the annotation includes characters that are not normally allowed in a property name (so we always know that the annotation is what it is, and not coincidentally part of the property name).  Annotating the value appears on the surface to be pretty easy, but multi-valued properties and the wider range of values allowed make it more challenging and potentially more risky.

Therefore, the approach we're going to take is to annotation the property name to specify that the property value(s) has been encoded.  The format will be "{propertyName}/{encoding}/", where "{propertyName}" is the usual name of the property, and "{encoding}" is the lowercase name of the encoding that is used.  For example, a "jcr:data" property encoded in Base64 would be represented in the JSON representations as "jcr:data/base64/".  According to the JCR 2.0 PFD Section 3.2.2, the local name (which applies to property names) can only contain valid XmlChar except '/' | ':' | '[' | ']' | '|' | '*' (where the JCR 1.0 spec is a bit more lenient, and it basically says that a name is not valid if it begins or ends with a '/', ':', '[', ']', '*', ''', '"', '|' or any whitespace character).  Therefore the {propertyName}/{encoding}/" format is never a valid property name, so can always be used to determine the encoding.

> REST server does not correctly encode binary values
> ---------------------------------------------------
>
>                 Key: DNA-513
>                 URL: https://jira.jboss.org/jira/browse/DNA-513
>             Project: DNA
>          Issue Type: Bug
>          Components: Web Application
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Brian Carothers
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: dna-513.1.patch
>
>
> The REST server (or rather web application) does not properly encode binary values in the JSON results, and instead is embedding the toString() version of the byte[].  The binary values should instead be encoded in Base64, and the REST client should be able to then read (or upload) binary values using this approach.
> (If the binary value is already a Base64-encoded representation, then the JSON content will just be a Base64-encoded representation of the value that happens to be Base64-encoded. Shouldn't be a problem.)

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

        

From jira-events at lists.jboss.org  Wed Sep  9 15:05:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 9 Sep 2009 15:05:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-513) REST server does not
 correctly encode binary values
In-Reply-To: <1103556934.1252011875497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1868661417.1252523123721.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch reassigned DNA-513:
---------------------------------

    Assignee: Randall Hauch  (was: Brian Carothers)


> REST server does not correctly encode binary values
> ---------------------------------------------------
>
>                 Key: DNA-513
>                 URL: https://jira.jboss.org/jira/browse/DNA-513
>             Project: DNA
>          Issue Type: Bug
>          Components: Web Application
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: dna-513.1.patch
>
>
> The REST server (or rather web application) does not properly encode binary values in the JSON results, and instead is embedding the toString() version of the byte[].  The binary values should instead be encoded in Base64, and the REST client should be able to then read (or upload) binary values using this approach.
> (If the binary value is already a Base64-encoded representation, then the JSON content will just be a Base64-encoded representation of the value that happens to be Base64-encoded. Shouldn't be a problem.)

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

        

From jira-events at lists.jboss.org  Wed Sep  9 15:05:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 9 Sep 2009 15:05:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Work started: (DNA-513) REST server does
 not correctly encode binary values
In-Reply-To: <1103556934.1252011875497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <835406223.1252523123756.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Work on DNA-513 started by Randall Hauch.

> REST server does not correctly encode binary values
> ---------------------------------------------------
>
>                 Key: DNA-513
>                 URL: https://jira.jboss.org/jira/browse/DNA-513
>             Project: DNA
>          Issue Type: Bug
>          Components: Web Application
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: dna-513.1.patch
>
>
> The REST server (or rather web application) does not properly encode binary values in the JSON results, and instead is embedding the toString() version of the byte[].  The binary values should instead be encoded in Base64, and the REST client should be able to then read (or upload) binary values using this approach.
> (If the binary value is already a Base64-encoded representation, then the JSON content will just be a Base64-encoded representation of the value that happens to be Base64-encoded. Shouldn't be a problem.)

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

        

From jira-events at lists.jboss.org  Wed Sep  9 15:14:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 9 Sep 2009 15:14:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-513) REST server does not
 correctly encode binary values
In-Reply-To: <1103556934.1252011875497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1541970608.1252523663601.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-513:
------------------------------

    Attachment: DNA-513.2.patch


2nd version of the patch, which supersedes the previous patch.

The new approach is used, where the JSON representation of a property that has binary values has the property name annotated/suffixed with "/base64/".  Also, the PUT/GET property request and response representations were modified to include the name and the value(s).  Previously, the PUT request and GET response only included the value (or values), but this didn't allow the sender to say whether the property values were Base64 encoded.  I considered using "Content-Transfer-Encoding" header (with value of "base64"), but that pretty much means the entire body is encoded.  Works great for PUT/GET with a single property value, but breaks down with an array (since the '[', ',' and ']' characters aren't encoded.

A few test methods were added, and the changes appear to work.  However, before committing, I'd like some verification that this patch goes in the right direction.

> REST server does not correctly encode binary values
> ---------------------------------------------------
>
>                 Key: DNA-513
>                 URL: https://jira.jboss.org/jira/browse/DNA-513
>             Project: DNA
>          Issue Type: Bug
>          Components: Web Application
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: dna-513.1.patch, DNA-513.2.patch
>
>
> The REST server (or rather web application) does not properly encode binary values in the JSON results, and instead is embedding the toString() version of the byte[].  The binary values should instead be encoded in Base64, and the REST client should be able to then read (or upload) binary values using this approach.
> (If the binary value is already a Base64-encoded representation, then the JSON content will just be a Base64-encoded representation of the value that happens to be Base64-encoded. Shouldn't be a problem.)

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

        

From jira-events at lists.jboss.org  Wed Sep  9 18:09:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 9 Sep 2009 18:09:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-513) REST server does not
 correctly encode binary values
In-Reply-To: <1103556934.1252011875497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1935769164.1252534163657.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Brian Carothers commented on DNA-513:
-------------------------------------

This patch looks great.  Thanks for handling this, Randall!

> REST server does not correctly encode binary values
> ---------------------------------------------------
>
>                 Key: DNA-513
>                 URL: https://jira.jboss.org/jira/browse/DNA-513
>             Project: DNA
>          Issue Type: Bug
>          Components: Web Application
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: dna-513.1.patch, DNA-513.2.patch
>
>
> The REST server (or rather web application) does not properly encode binary values in the JSON results, and instead is embedding the toString() version of the byte[].  The binary values should instead be encoded in Base64, and the REST client should be able to then read (or upload) binary values using this approach.
> (If the binary value is already a Base64-encoded representation, then the JSON content will just be a Base64-encoded representation of the value that happens to be Base64-encoded. Shouldn't be a problem.)

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

        

From jira-events at lists.jboss.org  Wed Sep  9 20:08:24 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 9 Sep 2009 20:08:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-513) REST server does not
 correctly encode binary values
In-Reply-To: <1103556934.1252011875497.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1569694489.1252541304513.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-513.
-------------------------------

    Resolution: Done


I just moved the "/base64/" string literal into a private static constant.  All the tests pass, so I'm marking this as resolved.  Dan was going to test this commit with his local Eclipse plugin (and/or the RESTful client project), and should reopen this issue if there is a problem.

> REST server does not correctly encode binary values
> ---------------------------------------------------
>
>                 Key: DNA-513
>                 URL: https://jira.jboss.org/jira/browse/DNA-513
>             Project: DNA
>          Issue Type: Bug
>          Components: Web Application
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: dna-513.1.patch, DNA-513.2.patch
>
>
> The REST server (or rather web application) does not properly encode binary values in the JSON results, and instead is embedding the toString() version of the byte[].  The binary values should instead be encoded in Base64, and the REST client should be able to then read (or upload) binary values using this approach.
> (If the binary value is already a Base64-encoded representation, then the JSON content will just be a Base64-encoded representation of the value that happens to be Base64-encoded. Shouldn't be a problem.)

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

        

From jira-events at lists.jboss.org  Wed Sep  9 20:16:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 9 Sep 2009 20:16:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-515) JPA connector reports
 error when inserting default (and blank) namespace URI into Oracle database
Message-ID: <828612963.1252541783948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JPA connector reports error when inserting default (and blank) namespace URI into Oracle database
-------------------------------------------------------------------------------------------------

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


The user meetoblivion reported on the forums [1] that he was getting an error when he called
      session.getRootNode().addNode("somepage")
and 
      session.getRootNode().addNode("somepage","nt:unstructured");

The full stack trace is listed on the forum thread, but the relevant part is here:
      2009-09-08 10:45:10,059 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
      2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
      2009-09-08 10:45:10,108 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
      2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")

Oracle doesn't like empty VARCHAR values, and attempts instead to insert a NULL value rather than the empty VARCHAR value.  This is currently a problem, because the DNA_NAMESPACES.URI column is not nullable.

[1] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160723

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  9 20:18:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 9 Sep 2009 20:18:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-505) Svn Repository Source
 with NPE and other issues while opening connection through Jcr
In-Reply-To: <1214704392.1251291863532.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <733632773.1252541903961.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-505.
-------------------------------

    Resolution: Done


I'm marking this as resolved, since we haven't heard from Feu.  If this remains a problem, this issue can be reopened, or a new one can be created.

> Svn Repository Source with NPE and other issues while opening connection through Jcr
> ------------------------------------------------------------------------------------
>
>                 Key: DNA-505
>                 URL: https://jira.jboss.org/jira/browse/DNA-505
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>         Environment: Mac OS X 10.5 - Jvm 1.5 - Maven 2
>            Reporter: Luiz Fernando Teston
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>         Attachments: 0001-fixing-a-few-null-pointer-exeptions.patch, DnaSvnUsingJcrWithProgramaticConfigurationTest.java
>
>
> Durring a test run to read data from some svn repository using Jcr api from DNA, it throws NullPointerException when trying to read jcr:content for nodes of type folder. This NPEs was really easy to solve. So, I created a patch for this. After this patch, when running the same unit test, it throws a repository source exception saying "svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace".
> The stack trace is here also:
> org.jboss.dna.graph.connector.RepositorySourceException: svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.checkThePath(SVNRepositoryRequestProcessor.java:1000)
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.process(SVNRepositoryRequestProcessor.java:151)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:641)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:239)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
> 	at org.jboss.dna.connector.svn.SVNRepositoryConnection.execute(SVNRepositoryConnection.java:176)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:314)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
> 	at java.lang.Thread.run(Thread.java:613)
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  9 21:25:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Wed, 9 Sep 2009 21:25:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-515) JPA connector reports
 error when inserting default (and blank) namespace URI into Oracle database
In-Reply-To: <828612963.1252541783948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1600801364.1252545923980.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Brian Carothers updated DNA-515:
--------------------------------

    Attachment: DNA-515.patch


Attached patch that changes the string columns that allow empty strings to be nullable and correct nulls back to empty strings in the respective getters.

> JPA connector reports error when inserting default (and blank) namespace URI into Oracle database
> -------------------------------------------------------------------------------------------------
>
>                 Key: DNA-515
>                 URL: https://jira.jboss.org/jira/browse/DNA-515
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: DNA-515.patch
>
>
> The user meetoblivion reported on the forums [1] that he was getting an error when he called
>       session.getRootNode().addNode("somepage")
> and 
>       session.getRootNode().addNode("somepage","nt:unstructured");
> The full stack trace is listed on the forum thread, but the relevant part is here:
>       2009-09-08 10:45:10,059 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
>       2009-09-08 10:45:10,108 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
> Oracle doesn't like empty VARCHAR values, and attempts instead to insert a NULL value rather than the empty VARCHAR value.  This is currently a problem, because the DNA_NAMESPACES.URI column is not nullable.
> [1] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160723

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep  9 22:48:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 9 Sep 2009 22:48:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-515) JPA connector
 reports error when inserting default (and blank) namespace URI into Oracle
 database
In-Reply-To: <828612963.1252541783948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1119165166.1252550903619.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-515:
-----------------------------------

I applied the patch locally, and tried running the JPA connector unit tests against PostgreSQL 8.4, and all unit tests passed.  I also changed the JpaRepositoryTckTest configuration to run against a local PostgreSQL database, and everything passed except for 1 failure and 1 error, but in fact I get these same two issues when I run against HSQLDB (and have been for some time).  Interestingly, the nightly Hudson integration job ran last night, and has had no problems.

So in short, I think this patch looks good so far (at least with HSQLDB and PostgreSQL), though I'll have to see if I can test against Oracle tomorrow.

> JPA connector reports error when inserting default (and blank) namespace URI into Oracle database
> -------------------------------------------------------------------------------------------------
>
>                 Key: DNA-515
>                 URL: https://jira.jboss.org/jira/browse/DNA-515
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: DNA-515.patch
>
>
> The user meetoblivion reported on the forums [1] that he was getting an error when he called
>       session.getRootNode().addNode("somepage")
> and 
>       session.getRootNode().addNode("somepage","nt:unstructured");
> The full stack trace is listed on the forum thread, but the relevant part is here:
>       2009-09-08 10:45:10,059 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
>       2009-09-08 10:45:10,108 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
> Oracle doesn't like empty VARCHAR values, and attempts instead to insert a NULL value rather than the empty VARCHAR value.  This is currently a problem, because the DNA_NAMESPACES.URI column is not nullable.
> [1] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160723

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 09:01:36 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 09:01:36 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-516) Reference Guide
 example that defines node types programmatically has several typos
Message-ID: <858741291.1252587696140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Reference Guide example that defines node types programmatically has several typos
----------------------------------------------------------------------------------

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


The example in Reference Guide that shows how to programmatically define node types (http://jboss.org/file-access/default/members/dna/freezone/docs/0.5/manuals/reference/html_single/reference-guide-en.html#d0e6301) has several typos:

1) Change NodeTypeManager on line 2 to JcrNodeTypeManager
2) Change [code]childNode.setRequiredPrimaryTypeNames(...)[/code] to [code]childNode.setRequiredPrimaryTypes(...)[/code]
3) Add a boolean argument in the method call in the last line.

Also, the text in this section could be more clear about the in which package the DNA-specific interfaces exist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 09:03:46 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 09:03:46 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-516) Reference Guide
 example that defines node types programmatically has several typos
In-Reply-To: <858741291.1252587696140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1608749356.1252587826310.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-516:
------------------------------

    Description: 
The example in Reference Guide that shows how to programmatically define node types (http://jboss.org/file-access/default/members/dna/freezone/docs/0.5/manuals/reference/html_single/reference-guide-en.html#d0e6301) has several typos:

1) Change NodeTypeManager on line 2 to JcrNodeTypeManager
2) Change childNode.setRequiredPrimaryTypeNames(...) to childNode.setRequiredPrimaryTypes(...)
3) Add a boolean argument in the method call in the last line.

Also, the text in this section could be more clear about the in which package the DNA-specific interfaces exist.

  was:
The example in Reference Guide that shows how to programmatically define node types (http://jboss.org/file-access/default/members/dna/freezone/docs/0.5/manuals/reference/html_single/reference-guide-en.html#d0e6301) has several typos:

1) Change NodeTypeManager on line 2 to JcrNodeTypeManager
2) Change [code]childNode.setRequiredPrimaryTypeNames(...)[/code] to [code]childNode.setRequiredPrimaryTypes(...)[/code]
3) Add a boolean argument in the method call in the last line.

Also, the text in this section could be more clear about the in which package the DNA-specific interfaces exist.



> Reference Guide example that defines node types programmatically has several typos
> ----------------------------------------------------------------------------------
>
>                 Key: DNA-516
>                 URL: https://jira.jboss.org/jira/browse/DNA-516
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation, Examples
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>
> The example in Reference Guide that shows how to programmatically define node types (http://jboss.org/file-access/default/members/dna/freezone/docs/0.5/manuals/reference/html_single/reference-guide-en.html#d0e6301) has several typos:
> 1) Change NodeTypeManager on line 2 to JcrNodeTypeManager
> 2) Change childNode.setRequiredPrimaryTypeNames(...) to childNode.setRequiredPrimaryTypes(...)
> 3) Add a boolean argument in the method call in the last line.
> Also, the text in this section could be more clear about the in which package the DNA-specific interfaces exist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 09:45:36 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 09:45:36 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-516) Reference Guide
 example that defines node types programmatically has several typos
In-Reply-To: <858741291.1252587696140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <287072920.1252590336076.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-516:
-----------------------------------

Corrected the faulty sections in the Reference Guide, and added a bit more detail to the same sections.

However, JcrNodeTypeManager doesn't appear to have a way to register node types with a CndNodeTypeSource.  We should add a method that delegates to the existing (package-level) method on RepositoryNodeTypeManager.

> Reference Guide example that defines node types programmatically has several typos
> ----------------------------------------------------------------------------------
>
>                 Key: DNA-516
>                 URL: https://jira.jboss.org/jira/browse/DNA-516
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation, Examples
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>
> The example in Reference Guide that shows how to programmatically define node types (http://jboss.org/file-access/default/members/dna/freezone/docs/0.5/manuals/reference/html_single/reference-guide-en.html#d0e6301) has several typos:
> 1) Change NodeTypeManager on line 2 to JcrNodeTypeManager
> 2) Change childNode.setRequiredPrimaryTypeNames(...) to childNode.setRequiredPrimaryTypes(...)
> 3) Add a boolean argument in the method call in the last line.
> Also, the text in this section could be more clear about the in which package the DNA-specific interfaces exist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 09:53:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 09:53:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-515) JPA connector reports
 error when inserting default (and blank) namespace URI into Oracle database
In-Reply-To: <828612963.1252541783948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <539743357.1252590803644.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch reassigned DNA-515:
---------------------------------

    Assignee: Randall Hauch


> JPA connector reports error when inserting default (and blank) namespace URI into Oracle database
> -------------------------------------------------------------------------------------------------
>
>                 Key: DNA-515
>                 URL: https://jira.jboss.org/jira/browse/DNA-515
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: DNA-515.patch
>
>
> The user meetoblivion reported on the forums [1] that he was getting an error when he called
>       session.getRootNode().addNode("somepage")
> and 
>       session.getRootNode().addNode("somepage","nt:unstructured");
> The full stack trace is listed on the forum thread, but the relevant part is here:
>       2009-09-08 10:45:10,059 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
>       2009-09-08 10:45:10,108 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
> Oracle doesn't like empty VARCHAR values, and attempts instead to insert a NULL value rather than the empty VARCHAR value.  This is currently a problem, because the DNA_NAMESPACES.URI column is not nullable.
> [1] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160723

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 09:53:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 09:53:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Work started: (DNA-515) JPA connector
 reports error when inserting default (and blank) namespace URI into Oracle
 database
In-Reply-To: <828612963.1252541783948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1665558126.1252590803677.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Work on DNA-515 started by Randall Hauch.

> JPA connector reports error when inserting default (and blank) namespace URI into Oracle database
> -------------------------------------------------------------------------------------------------
>
>                 Key: DNA-515
>                 URL: https://jira.jboss.org/jira/browse/DNA-515
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: DNA-515.patch
>
>
> The user meetoblivion reported on the forums [1] that he was getting an error when he called
>       session.getRootNode().addNode("somepage")
> and 
>       session.getRootNode().addNode("somepage","nt:unstructured");
> The full stack trace is listed on the forum thread, but the relevant part is here:
>       2009-09-08 10:45:10,059 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
>       2009-09-08 10:45:10,108 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
> Oracle doesn't like empty VARCHAR values, and attempts instead to insert a NULL value rather than the empty VARCHAR value.  This is currently a problem, because the DNA_NAMESPACES.URI column is not nullable.
> [1] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160723

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 09:53:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 09:53:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Work started: (DNA-516) Reference Guide
 example that defines node types programmatically has several typos
In-Reply-To: <858741291.1252587696140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <109734228.1252590803701.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Work on DNA-516 started by Randall Hauch.

> Reference Guide example that defines node types programmatically has several typos
> ----------------------------------------------------------------------------------
>
>                 Key: DNA-516
>                 URL: https://jira.jboss.org/jira/browse/DNA-516
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation, Examples
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>
> The example in Reference Guide that shows how to programmatically define node types (http://jboss.org/file-access/default/members/dna/freezone/docs/0.5/manuals/reference/html_single/reference-guide-en.html#d0e6301) has several typos:
> 1) Change NodeTypeManager on line 2 to JcrNodeTypeManager
> 2) Change childNode.setRequiredPrimaryTypeNames(...) to childNode.setRequiredPrimaryTypes(...)
> 3) Add a boolean argument in the method call in the last line.
> Also, the text in this section could be more clear about the in which package the DNA-specific interfaces exist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 10:33:24 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 10 Sep 2009 10:33:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-516) Reference Guide
 example that defines node types programmatically has several typos
In-Reply-To: <858741291.1252587696140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2022659250.1252593204034.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Brian Carothers updated DNA-516:
--------------------------------

    Attachment: DNA-516.patch


Attached patch that exposes the RTNM registerNodeTypes(JcrNodeTypeSource) method to users through the JcrNodeTypeManager.  The JNTM is the class returned by a call to JcrWorkspace.getNodeTypeManager().

> Reference Guide example that defines node types programmatically has several typos
> ----------------------------------------------------------------------------------
>
>                 Key: DNA-516
>                 URL: https://jira.jboss.org/jira/browse/DNA-516
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation, Examples
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>         Attachments: DNA-516.patch
>
>
> The example in Reference Guide that shows how to programmatically define node types (http://jboss.org/file-access/default/members/dna/freezone/docs/0.5/manuals/reference/html_single/reference-guide-en.html#d0e6301) has several typos:
> 1) Change NodeTypeManager on line 2 to JcrNodeTypeManager
> 2) Change childNode.setRequiredPrimaryTypeNames(...) to childNode.setRequiredPrimaryTypes(...)
> 3) Add a boolean argument in the method call in the last line.
> Also, the text in this section could be more clear about the in which package the DNA-specific interfaces exist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 10:37:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 10 Sep 2009 10:37:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-516) Reference Guide
 example that defines node types programmatically has several typos
In-Reply-To: <858741291.1252587696140.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <93572123.1252593443692.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Brian Carothers resolved DNA-516.
---------------------------------

    Resolution: Done


Applied patch to complete issue.

> Reference Guide example that defines node types programmatically has several typos
> ----------------------------------------------------------------------------------
>
>                 Key: DNA-516
>                 URL: https://jira.jboss.org/jira/browse/DNA-516
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation, Examples
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>         Attachments: DNA-516.patch
>
>
> The example in Reference Guide that shows how to programmatically define node types (http://jboss.org/file-access/default/members/dna/freezone/docs/0.5/manuals/reference/html_single/reference-guide-en.html#d0e6301) has several typos:
> 1) Change NodeTypeManager on line 2 to JcrNodeTypeManager
> 2) Change childNode.setRequiredPrimaryTypeNames(...) to childNode.setRequiredPrimaryTypes(...)
> 3) Add a boolean argument in the method call in the last line.
> Also, the text in this section could be more clear about the in which package the DNA-specific interfaces exist.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 10:52:23 2009
From: jira-events at lists.jboss.org (Brian Carothers (JIRA))
Date: Thu, 10 Sep 2009 10:52:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-517) Update Reference Guide
 and Getting Started Document for New and Modified Features
Message-ID: <466833774.1252594343551.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Update Reference Guide and Getting Started Document for New and Modified Features
---------------------------------------------------------------------------------

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


We need to review the documentation and make sure that it is still accurate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 10:56:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 10:56:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-518) Failure and error
 running integration tests that run TCK unit tests using the JPA connector
Message-ID: <1941388502.1252594583611.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Failure and error running integration tests that run TCK unit tests using the JPA connector
-------------------------------------------------------------------------------------------

                 Key: DNA-518
                 URL: https://jira.jboss.org/jira/browse/DNA-518
             Project: DNA
          Issue Type: Bug
          Components: Connectors, JCR, Testing
    Affects Versions: 0.6
            Reporter: Randall Hauch
            Assignee: Randall Hauch
            Priority: Critical
             Fix For: 0.6


The TCK tests are failing when they're run against a repository using the JPA connector (both against HSQLDB and PostgreSQL):

JpaRepositoryTckTest
Tests for jpa(read-write)
org.apache.jackrabbit.test.api.NodeTest
testUpdate(org.apache.jackrabbit.test.api.NodeTest)
java.lang.IllegalArgumentException: The last segment of the actual location of </{}testroot/{}node1[2] && [{http://www.jboss.org/dna/1.0}uuid = c3863875-6422-46ee-b47f-5a12547e27d8]> does not have the requested child segment {}node1
	at org.jboss.dna.graph.request.CloneBranchRequest.setActualLocations(CloneBranchRequest.java:199)
	at org.jboss.dna.connector.store.jpa.model.basic.BasicRequestProcessor.process(BasicRequestProcessor.java:1672)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:261)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
	at org.jboss.dna.connector.store.jpa.JpaConnection.execute(JpaConnection.java:150)
	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:308)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:637)

org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest
testCloneNodesRemoveExistingTrue(org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest)
junit.framework.AssertionFailedError: null
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.assertTrue(Assert.java:20)
	at junit.framework.Assert.assertFalse(Assert.java:34)
	at junit.framework.Assert.assertFalse(Assert.java:41)
	at org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingTrue(WorkspaceCloneReferenceableTest.java:81)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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

        

From jira-events at lists.jboss.org  Thu Sep 10 10:56:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 10:56:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-517) Update Reference Guide
 and Getting Started Document for New and Modified Features
In-Reply-To: <466833774.1252594343551.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2147067316.1252594583634.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-517:
------------------------------

    Fix Version/s: 0.6
         Assignee: Brian Carothers


> Update Reference Guide and Getting Started Document for New and Modified Features
> ---------------------------------------------------------------------------------
>
>                 Key: DNA-517
>                 URL: https://jira.jboss.org/jira/browse/DNA-517
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>
> We need to review the documentation and make sure that it is still accurate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 11:38:24 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Thu, 10 Sep 2009 11:38:24 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-519) SVN Connector
 integration test runs in a very long time
Message-ID: <1669549818.1252597104126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

SVN Connector integration test runs in a very long time
-------------------------------------------------------

                 Key: DNA-519
                 URL: https://jira.jboss.org/jira/browse/DNA-519
             Project: DNA
          Issue Type: Patch
          Components: Connectors
    Affects Versions: 0.6
         Environment: Mac OS X 10.6 JDK 1.5 
            Reporter: Luiz Fernando Teston


During the tests on issue DNA-505 a test called SvnAndJcrIntegrationTest was created inside the project dna-integration-tests. The problem related to the issue DNA-505 was solved successfully but it takes a very long time to run. On my environment it takes more than 270 seconds to run the tests method on SvnAndJcrIntegrationTest. This tests appears to do not load so much nodes. When loading more nodes (for example, changing the Option.READ_DEPTH to a bigger value) the test takes a very long time to run and it could make the use of DNA SVN Connector very difficult in a situation where is needed to load all the repository. I don't know if there's a way to do this load in a faster way, but if it is possible, it should be really useful to my needs.

Thanks a lot for the help!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 11:38:25 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Thu, 10 Sep 2009 11:38:25 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-505) Svn Repository
 Source with NPE and other issues while opening connection through Jcr
In-Reply-To: <1214704392.1251291863532.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1881442563.1252597105600.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

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

Since the original problem (NPE) was solved, I just created the issue DNA-519 for the performance issues on Svn Connector. 

> Svn Repository Source with NPE and other issues while opening connection through Jcr
> ------------------------------------------------------------------------------------
>
>                 Key: DNA-505
>                 URL: https://jira.jboss.org/jira/browse/DNA-505
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>         Environment: Mac OS X 10.5 - Jvm 1.5 - Maven 2
>            Reporter: Luiz Fernando Teston
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>         Attachments: 0001-fixing-a-few-null-pointer-exeptions.patch, DnaSvnUsingJcrWithProgramaticConfigurationTest.java
>
>
> Durring a test run to read data from some svn repository using Jcr api from DNA, it throws NullPointerException when trying to read jcr:content for nodes of type folder. This NPEs was really easy to solve. So, I created a patch for this. After this patch, when running the same unit test, it throws a repository source exception saying "svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace".
> The stack trace is here also:
> org.jboss.dna.graph.connector.RepositorySourceException: svnRepositorySource does not allow same name siblings on nodes: read children of /{http://www.jcp.org/jcr/1.0}content[2] in the ""http://hamcrest.googlecode.com/svn/trunk/hamcrest-java"" workspace
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.checkThePath(SVNRepositoryRequestProcessor.java:1000)
> 	at org.jboss.dna.connector.svn.SVNRepositoryRequestProcessor.process(SVNRepositoryRequestProcessor.java:151)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:641)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:239)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
> 	at org.jboss.dna.connector.svn.SVNRepositoryConnection.execute(SVNRepositoryConnection.java:176)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:314)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:123)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
> 	at java.lang.Thread.run(Thread.java:613)
>  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 14:08:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 14:08:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-515) JPA connector reports
 error when inserting default (and blank) namespace URI into Oracle database
In-Reply-To: <828612963.1252541783948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1999013273.1252606103566.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-515.
-------------------------------

    Resolution: Done


meetoblivion agreed on the forum that this patch did work, so I'm marking this issue as resolved.

> JPA connector reports error when inserting default (and blank) namespace URI into Oracle database
> -------------------------------------------------------------------------------------------------
>
>                 Key: DNA-515
>                 URL: https://jira.jboss.org/jira/browse/DNA-515
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: DNA-515.patch
>
>
> The user meetoblivion reported on the forums [1] that he was getting an error when he called
>       session.getRootNode().addNode("somepage")
> and 
>       session.getRootNode().addNode("somepage","nt:unstructured");
> The full stack trace is listed on the forum thread, but the relevant part is here:
>       2009-09-08 10:45:10,059 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
>       2009-09-08 10:45:10,108 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
> Oracle doesn't like empty VARCHAR values, and attempts instead to insert a NULL value rather than the empty VARCHAR value.  This is currently a problem, because the DNA_NAMESPACES.URI column is not nullable.
> [1] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160723

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 14:16:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 14:16:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-518) JPA connector fails to
 properly clone a subgraph from another workspace
In-Reply-To: <1941388502.1252594583611.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1438919057.1252606583662.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-518:
------------------------------

        Summary: JPA connector fails to properly clone a subgraph from another workspace  (was: Failure and error running integration tests that run TCK unit tests using the JPA connector)
    Description: 
The JPA connector's implementation of CloneBranchRequest is not correct when cloning from another workspace.  This is used in the JCR API in the 'Node.update(String workspaceName)' method as well as the 'Workspace.clone( String srcWorkspace, String srcAbsPath, String destAbsPath, boolean removeExisting )'.

The problem appears to be that the removeExisting behavior only works by comparing exact UUIDs, whereas the removeExisting behavior (for clone) really should apply only to the specified path.  Yes, any existing nodes with the same UUIDs should be removed, but certainly if 'removeExisting' is true any existing node at the desired location for the clone should be removed as well.

This was discovered because the TCK tests are failing when they're run against a repository using the JPA connector (both against HSQLDB and PostgreSQL):

JpaRepositoryTckTest
Tests for jpa(read-write)
org.apache.jackrabbit.test.api.NodeTest
testUpdate(org.apache.jackrabbit.test.api.NodeTest)
java.lang.IllegalArgumentException: The last segment of the actual location of </{}testroot/{}node1[2] && [{http://www.jboss.org/dna/1.0}uuid = c3863875-6422-46ee-b47f-5a12547e27d8]> does not have the requested child segment {}node1
	at org.jboss.dna.graph.request.CloneBranchRequest.setActualLocations(CloneBranchRequest.java:199)
	at org.jboss.dna.connector.store.jpa.model.basic.BasicRequestProcessor.process(BasicRequestProcessor.java:1672)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:261)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
	at org.jboss.dna.connector.store.jpa.JpaConnection.execute(JpaConnection.java:150)
	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:308)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:637)

org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest
testCloneNodesRemoveExistingTrue(org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest)
junit.framework.AssertionFailedError: null
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.assertTrue(Assert.java:20)
	at junit.framework.Assert.assertFalse(Assert.java:34)
	at junit.framework.Assert.assertFalse(Assert.java:41)
	at org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingTrue(WorkspaceCloneReferenceableTest.java:81)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

  was:
The TCK tests are failing when they're run against a repository using the JPA connector (both against HSQLDB and PostgreSQL):

JpaRepositoryTckTest
Tests for jpa(read-write)
org.apache.jackrabbit.test.api.NodeTest
testUpdate(org.apache.jackrabbit.test.api.NodeTest)
java.lang.IllegalArgumentException: The last segment of the actual location of </{}testroot/{}node1[2] && [{http://www.jboss.org/dna/1.0}uuid = c3863875-6422-46ee-b47f-5a12547e27d8]> does not have the requested child segment {}node1
	at org.jboss.dna.graph.request.CloneBranchRequest.setActualLocations(CloneBranchRequest.java:199)
	at org.jboss.dna.connector.store.jpa.model.basic.BasicRequestProcessor.process(BasicRequestProcessor.java:1672)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:261)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
	at org.jboss.dna.connector.store.jpa.JpaConnection.execute(JpaConnection.java:150)
	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:308)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
	at java.lang.Thread.run(Thread.java:637)

org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest
testCloneNodesRemoveExistingTrue(org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest)
junit.framework.AssertionFailedError: null
	at junit.framework.Assert.fail(Assert.java:47)
	at junit.framework.Assert.assertTrue(Assert.java:20)
	at junit.framework.Assert.assertFalse(Assert.java:34)
	at junit.framework.Assert.assertFalse(Assert.java:41)
	at org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingTrue(WorkspaceCloneReferenceableTest.java:81)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:168)
	at junit.framework.TestCase.runBare(TestCase.java:134)
	at junit.framework.TestResult$1.protect(TestResult.java:110)
	at junit.framework.TestResult.runProtected(TestResult.java:128)
	at junit.framework.TestResult.run(TestResult.java:113)
	at junit.framework.TestCase.run(TestCase.java:124)
	at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at junit.framework.TestSuite.runTest(TestSuite.java:232)
	at junit.framework.TestSuite.run(TestSuite.java:227)
	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

     Complexity: High


> JPA connector fails to properly clone a subgraph from another workspace
> -----------------------------------------------------------------------
>
>                 Key: DNA-518
>                 URL: https://jira.jboss.org/jira/browse/DNA-518
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, JCR, Testing
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.6
>
>
> The JPA connector's implementation of CloneBranchRequest is not correct when cloning from another workspace.  This is used in the JCR API in the 'Node.update(String workspaceName)' method as well as the 'Workspace.clone( String srcWorkspace, String srcAbsPath, String destAbsPath, boolean removeExisting )'.
> The problem appears to be that the removeExisting behavior only works by comparing exact UUIDs, whereas the removeExisting behavior (for clone) really should apply only to the specified path.  Yes, any existing nodes with the same UUIDs should be removed, but certainly if 'removeExisting' is true any existing node at the desired location for the clone should be removed as well.
> This was discovered because the TCK tests are failing when they're run against a repository using the JPA connector (both against HSQLDB and PostgreSQL):
> JpaRepositoryTckTest
> Tests for jpa(read-write)
> org.apache.jackrabbit.test.api.NodeTest
> testUpdate(org.apache.jackrabbit.test.api.NodeTest)
> java.lang.IllegalArgumentException: The last segment of the actual location of </{}testroot/{}node1[2] && [{http://www.jboss.org/dna/1.0}uuid = c3863875-6422-46ee-b47f-5a12547e27d8]> does not have the requested child segment {}node1
> 	at org.jboss.dna.graph.request.CloneBranchRequest.setActualLocations(CloneBranchRequest.java:199)
> 	at org.jboss.dna.connector.store.jpa.model.basic.BasicRequestProcessor.process(BasicRequestProcessor.java:1672)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:261)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
> 	at org.jboss.dna.connector.store.jpa.JpaConnection.execute(JpaConnection.java:150)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:308)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:637)
> org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest
> testCloneNodesRemoveExistingTrue(org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest)
> junit.framework.AssertionFailedError: null
> 	at junit.framework.Assert.fail(Assert.java:47)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertFalse(Assert.java:34)
> 	at junit.framework.Assert.assertFalse(Assert.java:41)
> 	at org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingTrue(WorkspaceCloneReferenceableTest.java:81)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at junit.framework.TestCase.runTest(TestCase.java:168)
> 	at junit.framework.TestCase.runBare(TestCase.java:134)
> 	at junit.framework.TestResult$1.protect(TestResult.java:110)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.framework.TestResult.run(TestResult.java:113)
> 	at junit.framework.TestCase.run(TestCase.java:124)
> 	at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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

        

From jira-events at lists.jboss.org  Thu Sep 10 15:02:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 15:02:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-519) SVN Connector
 integration test runs in a very long time
In-Reply-To: <1669549818.1252597104126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1960251379.1252609343698.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-519:
------------------------------

    Fix Version/s: 0.7
       Complexity: High


I've briefly looked at the code for performance, there simply isn't an easy fix.  And in fact, using the Eclipse Subversive plugin (which uses the same SVNKit library) does hint that the SVNKit performance is pretty poor, since expanding uncached nodes in the plug-in take several seconds (even as many as 10!).  When debugging our connector, each of the SVNKit calls does take a very noticeable amount of time.  We probably need to see if there's a way of using a local snapshot of the repository.

Therefore, targeting to 0.7, as we're pushing to get 0.6 out the door and don't have time to adequately address this performance issue in the time remaining for 0.6. 

> SVN Connector integration test runs in a very long time
> -------------------------------------------------------
>
>                 Key: DNA-519
>                 URL: https://jira.jboss.org/jira/browse/DNA-519
>             Project: DNA
>          Issue Type: Patch
>          Components: Connectors
>    Affects Versions: 0.6
>         Environment: Mac OS X 10.6 JDK 1.5 
>            Reporter: Luiz Fernando Teston
>             Fix For: 0.7
>
>
> During the tests on issue DNA-505 a test called SvnAndJcrIntegrationTest was created inside the project dna-integration-tests. The problem related to the issue DNA-505 was solved successfully but it takes a very long time to run. On my environment it takes more than 270 seconds to run the tests method on SvnAndJcrIntegrationTest. This tests appears to do not load so much nodes. When loading more nodes (for example, changing the Option.READ_DEPTH to a bigger value) the test takes a very long time to run and it could make the use of DNA SVN Connector very difficult in a situation where is needed to load all the repository. I don't know if there's a way to do this load in a faster way, but if it is possible, it should be really useful to my needs.
> Thanks a lot for the help!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 15:20:23 2009
From: jira-events at lists.jboss.org (Luiz Fernando Teston (JIRA))
Date: Thu, 10 Sep 2009 15:20:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-519) SVN Connector
 integration test runs in a very long time
In-Reply-To: <1669549818.1252597104126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1084269824.1252610423751.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

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

That's right! I'll be watching this issue. When I see some new comment on this ticket I'll run this tests again. Before creating this new issue I tried also to find any performance problems, but this really wasn't simple.
 
Thanks for the help again! 

> SVN Connector integration test runs in a very long time
> -------------------------------------------------------
>
>                 Key: DNA-519
>                 URL: https://jira.jboss.org/jira/browse/DNA-519
>             Project: DNA
>          Issue Type: Patch
>          Components: Connectors
>    Affects Versions: 0.6
>         Environment: Mac OS X 10.6 JDK 1.5 
>            Reporter: Luiz Fernando Teston
>             Fix For: 0.7
>
>
> During the tests on issue DNA-505 a test called SvnAndJcrIntegrationTest was created inside the project dna-integration-tests. The problem related to the issue DNA-505 was solved successfully but it takes a very long time to run. On my environment it takes more than 270 seconds to run the tests method on SvnAndJcrIntegrationTest. This tests appears to do not load so much nodes. When loading more nodes (for example, changing the Option.READ_DEPTH to a bigger value) the test takes a very long time to run and it could make the use of DNA SVN Connector very difficult in a situation where is needed to load all the repository. I don't know if there's a way to do this load in a faster way, but if it is possible, it should be really useful to my needs.
> Thanks a lot for the help!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 15:30:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Thu, 10 Sep 2009 15:30:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-519) SVN Connector
 integration test runs in a very long time
In-Reply-To: <1669549818.1252597104126.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1107498260.1252611023758.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-519:
------------------------------

    Priority: Critical  (was: Major)


I'm raising the priority to Critical because ... well, it is.

> SVN Connector integration test runs in a very long time
> -------------------------------------------------------
>
>                 Key: DNA-519
>                 URL: https://jira.jboss.org/jira/browse/DNA-519
>             Project: DNA
>          Issue Type: Patch
>          Components: Connectors
>    Affects Versions: 0.6
>         Environment: Mac OS X 10.6 JDK 1.5 
>            Reporter: Luiz Fernando Teston
>            Priority: Critical
>             Fix For: 0.7
>
>
> During the tests on issue DNA-505 a test called SvnAndJcrIntegrationTest was created inside the project dna-integration-tests. The problem related to the issue DNA-505 was solved successfully but it takes a very long time to run. On my environment it takes more than 270 seconds to run the tests method on SvnAndJcrIntegrationTest. This tests appears to do not load so much nodes. When loading more nodes (for example, changing the Option.READ_DEPTH to a bigger value) the test takes a very long time to run and it could make the use of DNA SVN Connector very difficult in a situation where is needed to load all the repository. I don't know if there's a way to do this load in a faster way, but if it is possible, it should be really useful to my needs.
> Thanks a lot for the help!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 16:56:23 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Thu, 10 Sep 2009 16:56:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-520) DNA w/ JPA/Oracle -
 bad create table DNA_OPTIONS
Message-ID: <966817629.1252616183878.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

DNA w/ JPA/Oracle - bad create table DNA_OPTIONS 
-------------------------------------------------

                 Key: DNA-520
                 URL: https://jira.jboss.org/jira/browse/DNA-520
             Project: DNA
          Issue Type: Bug
         Environment: Oracle 10g
JBoss AS 5.1
JDK6
            Reporter: John Ament


The create table generated for DNA_OPTIONS is
create table DNA_OPTIONS (NAME varchar2(512 char) not null unique, VALUE varchar2(512 char) not null, primary key (NAME))

However, to work correctly in Oracle, it should be:

create table DNA_OPTIONS (NAME varchar2(512 char) not null, VALUE varchar2(512 char) not null, primary key (NAME))

which means we have to remove the unique=true attribute from dna options entity.

There may be another entity like this as well, will double check.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 10 19:23:23 2009
From: jira-events at lists.jboss.org (John Ament (JIRA))
Date: Thu, 10 Sep 2009 19:23:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-520) DNA w/ JPA/Oracle -
 bad create table DNA_OPTIONS
In-Reply-To: <966817629.1252616183878.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <11878216.1252625003665.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

John Ament commented on DNA-520:
--------------------------------

Sorry stated wrong.

In source (StoreOptionEntity.java) :

@Id
@Column( name = "NAME", nullable = false, unique = true, length = 512 )
private String name;

Should be

@Id
@Column( name = "NAME", nullable = false, length = 512 )
private String name;


> DNA w/ JPA/Oracle - bad create table DNA_OPTIONS 
> -------------------------------------------------
>
>                 Key: DNA-520
>                 URL: https://jira.jboss.org/jira/browse/DNA-520
>             Project: DNA
>          Issue Type: Bug
>         Environment: Oracle 10g
> JBoss AS 5.1
> JDK6
>            Reporter: John Ament
>
> The create table generated for DNA_OPTIONS is
> create table DNA_OPTIONS (NAME varchar2(512 char) not null unique, VALUE varchar2(512 char) not null, primary key (NAME))
> However, to work correctly in Oracle, it should be:
> create table DNA_OPTIONS (NAME varchar2(512 char) not null, VALUE varchar2(512 char) not null, primary key (NAME))
> which means we have to remove the unique=true attribute from dna options entity.
> There may be another entity like this as well, will double check.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 11 12:19:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 12:19:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-521) Define infrastructure
 for testing with multiple DBMSes
Message-ID: <146944420.1252685963539.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Define infrastructure for testing with multiple DBMSes
------------------------------------------------------

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


We need to support easily testing the different aspects of DNA (primarily integration testing, but including the JPA connector testing) on different DBMS systems.  There are several ways of doing this, but one seemingly attractive way is to define a Maven profile for each DBMS to define the dependencies, custom repositories for drivers, and Maven properties that define the database connection information.  Each project can then be done in a database-agnostic manner, where database-related information (e.g., connection properties, driver names, etc.) can be placed in a property file within the project's "/src/test/resources" area and defined in terms of the Maven properties.  Then the Maven build (or just test runs) can be executed by supplying the desired DBMS profile; ideally, the normal build process would be completed, and then the tests can be run using the different DBMS profiles.

The jBPM4 project defines the profiles in their parent POM [1], while the Hibernate project defines them is their "testsuite" project's POM [2].  I actually like how jBPM defines it in the parent POM, but I like how Hibernate's POM defines and organizes their profiles.  Also note Hibernate's use of one DBMS profile (currently HSQLDB) as the default, meaning that all tests would normally pick that up.  Also, an example of a Hibernate test resource file that picks up the Maven properties is at [3].

[1] https://anonsvn.jboss.org/repos/jbpm/jbpm4/trunk/pom.xml
[2] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/pom.xml
[3] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/src/test/resources/hibernate.properties

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

        

From jira-events at lists.jboss.org  Fri Sep 11 14:21:36 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 14:21:36 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-521) Define
 infrastructure for testing with multiple DBMSes
In-Reply-To: <146944420.1252685963539.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <176694152.1252693296496.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-521:
-----------------------------------

The database tests need to make sure they clean up after themselves, too, so they leave the database as they found it.

> Define infrastructure for testing with multiple DBMSes
> ------------------------------------------------------
>
>                 Key: DNA-521
>                 URL: https://jira.jboss.org/jira/browse/DNA-521
>             Project: DNA
>          Issue Type: Task
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> We need to support easily testing the different aspects of DNA (primarily integration testing, but including the JPA connector testing) on different DBMS systems.  There are several ways of doing this, but one seemingly attractive way is to define a Maven profile for each DBMS to define the dependencies, custom repositories for drivers, and Maven properties that define the database connection information.  Each project can then be done in a database-agnostic manner, where database-related information (e.g., connection properties, driver names, etc.) can be placed in a property file within the project's "/src/test/resources" area and defined in terms of the Maven properties.  Then the Maven build (or just test runs) can be executed by supplying the desired DBMS profile; ideally, the normal build process would be completed, and then the tests can be run using the different DBMS profiles.
> The jBPM4 project defines the profiles in their parent POM [1], while the Hibernate project defines them is their "testsuite" project's POM [2].  I actually like how jBPM defines it in the parent POM, but I like how Hibernate's POM defines and organizes their profiles.  Also note Hibernate's use of one DBMS profile (currently HSQLDB) as the default, meaning that all tests would normally pick that up.  Also, an example of a Hibernate test resource file that picks up the Maven properties is at [3].
> [1] https://anonsvn.jboss.org/repos/jbpm/jbpm4/trunk/pom.xml
> [2] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/pom.xml
> [3] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/src/test/resources/hibernate.properties

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

        

From jira-events at lists.jboss.org  Fri Sep 11 14:54:35 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 14:54:35 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-520) DNA w/ JPA/Oracle -
 bad create table DNA_OPTIONS
In-Reply-To: <966817629.1252616183878.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <611340341.1252695275829.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch reassigned DNA-520:
---------------------------------

    Assignee: Randall Hauch


> DNA w/ JPA/Oracle - bad create table DNA_OPTIONS 
> -------------------------------------------------
>
>                 Key: DNA-520
>                 URL: https://jira.jboss.org/jira/browse/DNA-520
>             Project: DNA
>          Issue Type: Bug
>         Environment: Oracle 10g
> JBoss AS 5.1
> JDK6
>            Reporter: John Ament
>            Assignee: Randall Hauch
>
> The create table generated for DNA_OPTIONS is
> create table DNA_OPTIONS (NAME varchar2(512 char) not null unique, VALUE varchar2(512 char) not null, primary key (NAME))
> However, to work correctly in Oracle, it should be:
> create table DNA_OPTIONS (NAME varchar2(512 char) not null, VALUE varchar2(512 char) not null, primary key (NAME))
> which means we have to remove the unique=true attribute from dna options entity.
> There may be another entity like this as well, will double check.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 11 14:57:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 14:57:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-520) DNA w/ JPA/Oracle -
 bad create table DNA_OPTIONS
In-Reply-To: <966817629.1252616183878.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <433994893.1252695443543.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-520:
-----------------------------------

Ah, you are correct.  The "unique=true" parameter is actually unnecessary since the column is already a primary key since it is annotated with @Id.  I guess the Oracle is just pretty strict about this.  Removing the parameter didn't seem to cause any other problems.

> DNA w/ JPA/Oracle - bad create table DNA_OPTIONS 
> -------------------------------------------------
>
>                 Key: DNA-520
>                 URL: https://jira.jboss.org/jira/browse/DNA-520
>             Project: DNA
>          Issue Type: Bug
>         Environment: Oracle 10g
> JBoss AS 5.1
> JDK6
>            Reporter: John Ament
>            Assignee: Randall Hauch
>
> The create table generated for DNA_OPTIONS is
> create table DNA_OPTIONS (NAME varchar2(512 char) not null unique, VALUE varchar2(512 char) not null, primary key (NAME))
> However, to work correctly in Oracle, it should be:
> create table DNA_OPTIONS (NAME varchar2(512 char) not null, VALUE varchar2(512 char) not null, primary key (NAME))
> which means we have to remove the unique=true attribute from dna options entity.
> There may be another entity like this as well, will double check.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 11 15:03:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 15:03:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-515) JPA connector
 reports error when inserting default (and blank) namespace URI into Oracle
 database
In-Reply-To: <828612963.1252541783948.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1438353126.1252695803575.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-515:
-----------------------------------

Although the previous change did address the possibility that Oracle will return null, it did not yet change the Hibernate annotations to allow for a null URI value.  Changing the NamespaceEntity annotations to account for null values.

> JPA connector reports error when inserting default (and blank) namespace URI into Oracle database
> -------------------------------------------------------------------------------------------------
>
>                 Key: DNA-515
>                 URL: https://jira.jboss.org/jira/browse/DNA-515
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.6
>
>         Attachments: DNA-515.patch
>
>
> The user meetoblivion reported on the forums [1] that he was getting an error when he called
>       session.getRootNode().addNode("somepage")
> and 
>       session.getRootNode().addNode("somepage","nt:unstructured");
> The full stack trace is listed on the forum thread, but the relevant part is here:
>       2009-09-08 10:45:10,059 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
>       2009-09-08 10:45:10,108 WARN  [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) SQL Error: 1400, SQLState: 23000
>       2009-09-08 10:45:10,108 ERROR [org.hibernate.util.JDBCExceptionReporter] (pool-159-thread-2) ORA-01400: cannot insert NULL into ("JCRPUBLIC"."DNA_NAMESPACES"."URI")
> Oracle doesn't like empty VARCHAR values, and attempts instead to insert a NULL value rather than the empty VARCHAR value.  This is currently a problem, because the DNA_NAMESPACES.URI column is not nullable.
> [1] http://www.jboss.org/index.html?module=bb&op=viewtopic&t=160723

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 11 15:05:36 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 15:05:36 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-520) DNA w/ JPA/Oracle -
 bad create table DNA_OPTIONS
In-Reply-To: <966817629.1252616183878.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1708859971.1252695936379.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-520.
-------------------------------

    Fix Version/s: 0.6
       Resolution: Done


Marking this as resolved, since I was able to test locally against an Oracle 11g instance.  See also DNA-515.

> DNA w/ JPA/Oracle - bad create table DNA_OPTIONS 
> -------------------------------------------------
>
>                 Key: DNA-520
>                 URL: https://jira.jboss.org/jira/browse/DNA-520
>             Project: DNA
>          Issue Type: Bug
>         Environment: Oracle 10g
> JBoss AS 5.1
> JDK6
>            Reporter: John Ament
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>
> The create table generated for DNA_OPTIONS is
> create table DNA_OPTIONS (NAME varchar2(512 char) not null unique, VALUE varchar2(512 char) not null, primary key (NAME))
> However, to work correctly in Oracle, it should be:
> create table DNA_OPTIONS (NAME varchar2(512 char) not null, VALUE varchar2(512 char) not null, primary key (NAME))
> which means we have to remove the unique=true attribute from dna options entity.
> There may be another entity like this as well, will double check.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 11 15:17:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 15:17:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-518) JPA connector fails to
 properly clone or update from another workspace
In-Reply-To: <1941388502.1252594583611.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <318151063.1252696643622.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-518:
------------------------------

          Summary: JPA connector fails to properly clone or update from another workspace  (was: JPA connector fails to properly clone a subgraph from another workspace)
    Fix Version/s: 0.7
                       (was: 0.6)
          Affects: [Documentation (Ref Guide, User Guide, etc.), Release Notes]


This will have to be a known issue for 0.6, as it's just too complex of an issue to fix this close to the release.

> JPA connector fails to properly clone or update from another workspace
> ----------------------------------------------------------------------
>
>                 Key: DNA-518
>                 URL: https://jira.jboss.org/jira/browse/DNA-518
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, JCR, Testing
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Critical
>             Fix For: 0.7
>
>
> The JPA connector's implementation of CloneBranchRequest is not correct when cloning from another workspace.  This is used in the JCR API in the 'Node.update(String workspaceName)' method as well as the 'Workspace.clone( String srcWorkspace, String srcAbsPath, String destAbsPath, boolean removeExisting )'.
> The problem appears to be that the removeExisting behavior only works by comparing exact UUIDs, whereas the removeExisting behavior (for clone) really should apply only to the specified path.  Yes, any existing nodes with the same UUIDs should be removed, but certainly if 'removeExisting' is true any existing node at the desired location for the clone should be removed as well.
> This was discovered because the TCK tests are failing when they're run against a repository using the JPA connector (both against HSQLDB and PostgreSQL):
> JpaRepositoryTckTest
> Tests for jpa(read-write)
> org.apache.jackrabbit.test.api.NodeTest
> testUpdate(org.apache.jackrabbit.test.api.NodeTest)
> java.lang.IllegalArgumentException: The last segment of the actual location of </{}testroot/{}node1[2] && [{http://www.jboss.org/dna/1.0}uuid = c3863875-6422-46ee-b47f-5a12547e27d8]> does not have the requested child segment {}node1
> 	at org.jboss.dna.graph.request.CloneBranchRequest.setActualLocations(CloneBranchRequest.java:199)
> 	at org.jboss.dna.connector.store.jpa.model.basic.BasicRequestProcessor.process(BasicRequestProcessor.java:1672)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:261)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
> 	at org.jboss.dna.connector.store.jpa.JpaConnection.execute(JpaConnection.java:150)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:308)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:637)
> org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest
> testCloneNodesRemoveExistingTrue(org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest)
> junit.framework.AssertionFailedError: null
> 	at junit.framework.Assert.fail(Assert.java:47)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertFalse(Assert.java:34)
> 	at junit.framework.Assert.assertFalse(Assert.java:41)
> 	at org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingTrue(WorkspaceCloneReferenceableTest.java:81)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at junit.framework.TestCase.runTest(TestCase.java:168)
> 	at junit.framework.TestCase.runBare(TestCase.java:134)
> 	at junit.framework.TestResult$1.protect(TestResult.java:110)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.framework.TestResult.run(TestResult.java:113)
> 	at junit.framework.TestCase.run(TestCase.java:124)
> 	at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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

        

From jira-events at lists.jboss.org  Fri Sep 11 16:26:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 16:26:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-517) Update Reference
 Guide and Getting Started Document for New and Modified Features
In-Reply-To: <466833774.1252594343551.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1586744051.1252700783549.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-517:
-----------------------------------

Made several changes, including:
1) Called out the new 'dna-connector-infinispan' project
2) Documented the binary property behavior in the REST service
3) Corrected the SVN connector property example
4) Changed versions of DNA components in examples from 0.5 to 0.6

> Update Reference Guide and Getting Started Document for New and Modified Features
> ---------------------------------------------------------------------------------
>
>                 Key: DNA-517
>                 URL: https://jira.jboss.org/jira/browse/DNA-517
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>            Assignee: Brian Carothers
>             Fix For: 0.6
>
>
> We need to review the documentation and make sure that it is still accurate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 11 16:52:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 16:52:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-517) Update Reference
 Guide and Getting Started Document for New and Modified Features
In-Reply-To: <466833774.1252594343551.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1957620489.1252702343721.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-517.
-------------------------------

    Resolution: Done
      Assignee: Randall Hauch  (was: Brian Carothers)


Marking as resolved.

> Update Reference Guide and Getting Started Document for New and Modified Features
> ---------------------------------------------------------------------------------
>
>                 Key: DNA-517
>                 URL: https://jira.jboss.org/jira/browse/DNA-517
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 0.5
>            Reporter: Brian Carothers
>            Assignee: Randall Hauch
>             Fix For: 0.6
>
>
> We need to review the documentation and make sure that it is still accurate.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 11 16:54:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 16:54:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-518) JPA connector fails to
 properly clone or update from another workspace
In-Reply-To: <1941388502.1252594583611.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <845130650.1252702463553.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-518:
------------------------------

    Priority: Blocker  (was: Critical)


> JPA connector fails to properly clone or update from another workspace
> ----------------------------------------------------------------------
>
>                 Key: DNA-518
>                 URL: https://jira.jboss.org/jira/browse/DNA-518
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, JCR, Testing
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.7
>
>
> The JPA connector's implementation of CloneBranchRequest is not correct when cloning from another workspace.  This is used in the JCR API in the 'Node.update(String workspaceName)' method as well as the 'Workspace.clone( String srcWorkspace, String srcAbsPath, String destAbsPath, boolean removeExisting )'.
> The problem appears to be that the removeExisting behavior only works by comparing exact UUIDs, whereas the removeExisting behavior (for clone) really should apply only to the specified path.  Yes, any existing nodes with the same UUIDs should be removed, but certainly if 'removeExisting' is true any existing node at the desired location for the clone should be removed as well.
> This was discovered because the TCK tests are failing when they're run against a repository using the JPA connector (both against HSQLDB and PostgreSQL):
> JpaRepositoryTckTest
> Tests for jpa(read-write)
> org.apache.jackrabbit.test.api.NodeTest
> testUpdate(org.apache.jackrabbit.test.api.NodeTest)
> java.lang.IllegalArgumentException: The last segment of the actual location of </{}testroot/{}node1[2] && [{http://www.jboss.org/dna/1.0}uuid = c3863875-6422-46ee-b47f-5a12547e27d8]> does not have the requested child segment {}node1
> 	at org.jboss.dna.graph.request.CloneBranchRequest.setActualLocations(CloneBranchRequest.java:199)
> 	at org.jboss.dna.connector.store.jpa.model.basic.BasicRequestProcessor.process(BasicRequestProcessor.java:1672)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:261)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
> 	at org.jboss.dna.connector.store.jpa.JpaConnection.execute(JpaConnection.java:150)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:308)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:637)
> org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest
> testCloneNodesRemoveExistingTrue(org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest)
> junit.framework.AssertionFailedError: null
> 	at junit.framework.Assert.fail(Assert.java:47)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertFalse(Assert.java:34)
> 	at junit.framework.Assert.assertFalse(Assert.java:41)
> 	at org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingTrue(WorkspaceCloneReferenceableTest.java:81)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at junit.framework.TestCase.runTest(TestCase.java:168)
> 	at junit.framework.TestCase.runBare(TestCase.java:134)
> 	at junit.framework.TestResult$1.protect(TestResult.java:110)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.framework.TestResult.run(TestResult.java:113)
> 	at junit.framework.TestCase.run(TestCase.java:124)
> 	at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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

        

From jira-events at lists.jboss.org  Fri Sep 11 21:28:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 11 Sep 2009 21:28:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-518) JPA connector fails
 to properly clone or update from another workspace
In-Reply-To: <1941388502.1252594583611.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1551972150.1252718903540.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-518:
-----------------------------------

Commented out the NodeTest and WorkspaceCloneReferenceableTest TCK test suites, since they break the JPA integration test, which breaks the build for the 0.6 release.  The comments are of the form "// DNA-518".

> JPA connector fails to properly clone or update from another workspace
> ----------------------------------------------------------------------
>
>                 Key: DNA-518
>                 URL: https://jira.jboss.org/jira/browse/DNA-518
>             Project: DNA
>          Issue Type: Bug
>          Components: Connectors, JCR, Testing
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.7
>
>
> The JPA connector's implementation of CloneBranchRequest is not correct when cloning from another workspace.  This is used in the JCR API in the 'Node.update(String workspaceName)' method as well as the 'Workspace.clone( String srcWorkspace, String srcAbsPath, String destAbsPath, boolean removeExisting )'.
> The problem appears to be that the removeExisting behavior only works by comparing exact UUIDs, whereas the removeExisting behavior (for clone) really should apply only to the specified path.  Yes, any existing nodes with the same UUIDs should be removed, but certainly if 'removeExisting' is true any existing node at the desired location for the clone should be removed as well.
> This was discovered because the TCK tests are failing when they're run against a repository using the JPA connector (both against HSQLDB and PostgreSQL):
> JpaRepositoryTckTest
> Tests for jpa(read-write)
> org.apache.jackrabbit.test.api.NodeTest
> testUpdate(org.apache.jackrabbit.test.api.NodeTest)
> java.lang.IllegalArgumentException: The last segment of the actual location of </{}testroot/{}node1[2] && [{http://www.jboss.org/dna/1.0}uuid = c3863875-6422-46ee-b47f-5a12547e27d8]> does not have the requested child segment {}node1
> 	at org.jboss.dna.graph.request.CloneBranchRequest.setActualLocations(CloneBranchRequest.java:199)
> 	at org.jboss.dna.connector.store.jpa.model.basic.BasicRequestProcessor.process(BasicRequestProcessor.java:1672)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:261)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:298)
> 	at org.jboss.dna.graph.request.processor.RequestProcessor.process(RequestProcessor.java:219)
> 	at org.jboss.dna.connector.store.jpa.JpaConnection.execute(JpaConnection.java:150)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:318)
> 	at org.jboss.dna.graph.connector.federation.ForkRequestProcessor$Channel$3.call(ForkRequestProcessor.java:308)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> 	at java.lang.Thread.run(Thread.java:637)
> org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest
> testCloneNodesRemoveExistingTrue(org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest)
> junit.framework.AssertionFailedError: null
> 	at junit.framework.Assert.fail(Assert.java:47)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertFalse(Assert.java:34)
> 	at junit.framework.Assert.assertFalse(Assert.java:41)
> 	at org.apache.jackrabbit.test.api.WorkspaceCloneReferenceableTest.testCloneNodesRemoveExistingTrue(WorkspaceCloneReferenceableTest.java:81)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at junit.framework.TestCase.runTest(TestCase.java:168)
> 	at junit.framework.TestCase.runBare(TestCase.java:134)
> 	at junit.framework.TestResult$1.protect(TestResult.java:110)
> 	at junit.framework.TestResult.runProtected(TestResult.java:128)
> 	at junit.framework.TestResult.run(TestResult.java:113)
> 	at junit.framework.TestCase.run(TestCase.java:124)
> 	at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:406)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at junit.framework.TestSuite.runTest(TestSuite.java:232)
> 	at junit.framework.TestSuite.run(TestSuite.java:227)
> 	at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)
> 	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
> 	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> 	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)

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

        

From jira-events at lists.jboss.org  Mon Sep 14 10:15:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 14 Sep 2009 10:15:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-522) CND files that use
 keywords as names cannot be read in
Message-ID: <717560.1252937723842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

CND files that use keywords as names cannot be read in
------------------------------------------------------

                 Key: DNA-522
                 URL: https://jira.jboss.org/jira/browse/DNA-522
             Project: DNA
          Issue Type: Bug
          Components: JCR, Sequencers
    Affects Versions: 0.6
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.7


The CND parser fails to load CND files that use keywords as unquoted names.  Apparently this is a 'feature' of ANTLR, since the generated lexer always returns keyword tokens whenever a token appears in the file (regardless of the position).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 15 12:07:23 2009
From: jira-events at lists.jboss.org (Barry LaFond (JIRA))
Date: Tue, 15 Sep 2009 12:07:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-326) Create documentation
In-Reply-To: <13759744.1237396882299.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1339520415.1253030843540.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Barry LaFond updated DNA-326:
-----------------------------

    Attachment: DNA_Doc_edits.txt


Read and found grammar and spelling errors in Chapter 5.

> Create documentation
> --------------------
>
>                 Key: DNA-326
>                 URL: https://jira.jboss.org/jira/browse/DNA-326
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Documentation, Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.7
>
>         Attachments: DNA_Doc_edits.txt
>
>
> - Feature welcome page
> - Links from Eclipse welcome page
> - Normal User's guide/Help docs
> - Links from dialog "question mark" icon
> - Links from dialog "light-bulbs" (optional)
> - Cheatsheets (optional)

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

        

From jira-events at lists.jboss.org  Wed Sep 16 10:40:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 16 Sep 2009 10:40:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-522) CND files that use
 keywords as names cannot be read in
In-Reply-To: <717560.1252937723842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <515969037.1253112023599.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-522:
-----------------------------------

ANTLR 3.0 by default treats keywords used in the parser as special tokens in the lexer, meaning that the lexer will always generate a keyword token whenever such a word appears in the input (regardless of whether that word is indeed a proper use of that keyword or just a coincidental match).  To fix this requires a lot of nasty workarounds, and this makes the generated parser really large.

So instead of using ANTLR, the parser was changed to use the TokenStream class added late last release.  This is a very simple framework that makes it possible to write a parser that is fairly efficient but extremely easy to understand when reading and extremely easy to debug.  Plus, the total lines of code for this CND importer/parser are actually reduced, even when excluding the generated code from the stats.  The same CndImporter interface was kept, so there were no other changes outside of the 'dna-cnd' project.

Also, one of the test cases used to this point attempted to import a namespace mapping where the URI was not quoted.  Technically this is not possible according to the JCR 2.0 Public Final Draft specification, and the reference implementation does not appear to support it.  Actually, there are several errors in the JCR 2.0 PFD specification section that talks about the CND grammar.  In particular, the definition of a string is unclear in the very least and like in error, since it attempts to define a string as a sequence of one or more XmlChar, where XmlChar appears to be defined as any of the characters allowed in the Char production of the XML specification (http://www.w3.org/TR/xml/#NT-Char) and therefore would allow nearly any unicode character (including whitespace, newlines, etc).  This is clearly NOT the behavior of the reference implementation, which treats a CND unquoted string simply as '[A-Za-z0-9:_]+'.  Therefore, the string behavior of the parser was cleaned up a bit, though it still is more lenient than the reference implementation.  Basically, our unquoted string is any non-whitespace character except the following: []<>=-+(),\"'/{*|

As a result of these changes, all existing unit tests and integration tests pass (though some of the dna-cnd tests were changed and new ones were added).

> CND files that use keywords as names cannot be read in
> ------------------------------------------------------
>
>                 Key: DNA-522
>                 URL: https://jira.jboss.org/jira/browse/DNA-522
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR, Sequencers
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> The CND parser fails to load CND files that use keywords as unquoted names.  Apparently this is a 'feature' of ANTLR, since the generated lexer always returns keyword tokens whenever a token appears in the file (regardless of the position).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 16 10:42:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 16 Sep 2009 10:42:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-522) CND files that use
 keywords as names cannot be read in
In-Reply-To: <717560.1252937723842.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1667143203.1253112143899.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-522.
-------------------------------

    Resolution: Done


Marking as resolved, since several new test cases verify that the behavior is now corrected.

> CND files that use keywords as names cannot be read in
> ------------------------------------------------------
>
>                 Key: DNA-522
>                 URL: https://jira.jboss.org/jira/browse/DNA-522
>             Project: DNA
>          Issue Type: Bug
>          Components: JCR, Sequencers
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> The CND parser fails to load CND files that use keywords as unquoted names.  Apparently this is a 'feature' of ANTLR, since the generated lexer always returns keyword tokens whenever a token appears in the file (regardless of the position).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 16 15:01:23 2009
From: jira-events at lists.jboss.org (Barry LaFond (JIRA))
Date: Wed, 16 Sep 2009 15:01:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-326) Create documentation
In-Reply-To: <13759744.1237396882299.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1301233705.1253127683806.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Barry LaFond updated DNA-326:
-----------------------------

    Attachment:     (was: DNA_Doc_edits.txt)


> Create documentation
> --------------------
>
>                 Key: DNA-326
>                 URL: https://jira.jboss.org/jira/browse/DNA-326
>             Project: DNA
>          Issue Type: Sub-task
>          Components: Documentation, Views
>    Affects Versions: 0.3
>            Reporter: Johnny Verhaeg
>             Fix For: 0.7
>
>
> - Feature welcome page
> - Links from Eclipse welcome page
> - Normal User's guide/Help docs
> - Links from dialog "question mark" icon
> - Links from dialog "light-bulbs" (optional)
> - Cheatsheets (optional)

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

        

From jira-events at lists.jboss.org  Wed Sep 16 15:16:23 2009
From: jira-events at lists.jboss.org (Barry LaFond (JIRA))
Date: Wed, 16 Sep 2009 15:16:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-523) Spelling and grammar
 errors in on-line JBoss DNA Reference Guide
Message-ID: <538188676.1253128583648.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Spelling and grammar errors in on-line JBoss DNA Reference Guide
----------------------------------------------------------------

                 Key: DNA-523
                 URL: https://jira.jboss.org/jira/browse/DNA-523
             Project: DNA
          Issue Type: Bug
          Components: Documentation
    Affects Versions: 0.6
            Reporter: Barry LaFond
            Priority: Minor
         Attachments: DNA_Doc_edits.txt

Found several grammar errors and typos in Chapter 5 of on-line document.  Attached text file of fixes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 16 15:16:23 2009
From: jira-events at lists.jboss.org (Barry LaFond (JIRA))
Date: Wed, 16 Sep 2009 15:16:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-523) Spelling and grammar
 errors in on-line JBoss DNA Reference Guide
In-Reply-To: <538188676.1253128583648.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <331733487.1253128583681.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Barry LaFond updated DNA-523:
-----------------------------

    Attachment: DNA_Doc_edits.txt


> Spelling and grammar errors in on-line JBoss DNA Reference Guide
> ----------------------------------------------------------------
>
>                 Key: DNA-523
>                 URL: https://jira.jboss.org/jira/browse/DNA-523
>             Project: DNA
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 0.6
>            Reporter: Barry LaFond
>            Priority: Minor
>         Attachments: DNA_Doc_edits.txt
>
>
> Found several grammar errors and typos in Chapter 5 of on-line document.  Attached text file of fixes.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 16 16:54:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 16 Sep 2009 16:54:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-521) Define
 infrastructure for testing with multiple DBMSes
In-Reply-To: <146944420.1252685963539.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <257048387.1253134463573.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-521:
-----------------------------------

The parent POM file was changed to define a new profiles for each database configuration, and each profile defines the dependencies and properties for the JPA Source objects used in the unit and integration tests.  

For the most part, I followed Hibernate's example.  Hibernate's POM is such that the database profile is specified explicitly on the Maven command (e.g., 'mvn -Poracle9i ...'), and thus is able to define a 'default' database profile that is used when no other profile is specified.  However, this means that if ANY other profile is explicitly used on the command line (e.g., 'mvn -Pintegration ...'), the default database profile is not used, and in effect NO database profile is used.  This causes a locking up of the build process.

jBPM's approach of using a property to refer to the database profile is actually superior in this respect, since there is a default database profile that is run when the "database" property is not set.  Thus, the database profiles and the other profiles remain orthogonal and independent.  Yet another advantage to this approach is that it encourages specifying only one database profile.  The cost is a bit more verbosity in the parent POM.  So, 'mvn -P integration clean install' still runs the integration builds as before (using the HSQLDB database), and to use a different database simply set the 'database' property to the name of the database profile.  For example, 'mvn -P integration -Ddatabase=oracle9i clean install' runs the integration tests against the 'oracle9i' database.

Note that it still is possible to specify the database via the '-P' flag, but then be sure to always include a database profile when using another profile.  For example, "mvn -P integration,oracle9i ..." does work.

The JPA unit tests were changed to read a resource file and set the JpaSource bean properties using the values in that resource file.  This resource file is simply a properties file where the values are substituted by Maven during the build with the properties in the selected profile.  Thus, each database profile can actually set any and all of the JpaSource bean properties (tho some integration tests explicitly override some of the property values, since they are related to the tests being run).  A number of database profiles has been added, but these will be updated as we acquire database instances in the QA lab.

The integration tests that use a JPA connector all work in a similar manner, except that the integration tests already load the DNA configuration from an XML file.  Here also the XML file (and the 'dna-integration-test/pom.xml' file) was changed so that Maven would substitute the properties in the database profile.


The short summary is this:  simply change or add the appropriate database profile in the parent POM file, and then specify the DBMS that should be used by including the '-Ddatabase=dbprofilename' parameter on the command line.  That's it.

> Define infrastructure for testing with multiple DBMSes
> ------------------------------------------------------
>
>                 Key: DNA-521
>                 URL: https://jira.jboss.org/jira/browse/DNA-521
>             Project: DNA
>          Issue Type: Task
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> We need to support easily testing the different aspects of DNA (primarily integration testing, but including the JPA connector testing) on different DBMS systems.  There are several ways of doing this, but one seemingly attractive way is to define a Maven profile for each DBMS to define the dependencies, custom repositories for drivers, and Maven properties that define the database connection information.  Each project can then be done in a database-agnostic manner, where database-related information (e.g., connection properties, driver names, etc.) can be placed in a property file within the project's "/src/test/resources" area and defined in terms of the Maven properties.  Then the Maven build (or just test runs) can be executed by supplying the desired DBMS profile; ideally, the normal build process would be completed, and then the tests can be run using the different DBMS profiles.
> The jBPM4 project defines the profiles in their parent POM [1], while the Hibernate project defines them is their "testsuite" project's POM [2].  I actually like how jBPM defines it in the parent POM, but I like how Hibernate's POM defines and organizes their profiles.  Also note Hibernate's use of one DBMS profile (currently HSQLDB) as the default, meaning that all tests would normally pick that up.  Also, an example of a Hibernate test resource file that picks up the Maven properties is at [3].
> [1] https://anonsvn.jboss.org/repos/jbpm/jbpm4/trunk/pom.xml
> [2] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/pom.xml
> [3] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/src/test/resources/hibernate.properties

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

        

From jira-events at lists.jboss.org  Wed Sep 16 19:16:23 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 16 Sep 2009 19:16:23 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-521) Define infrastructure
 for testing with multiple DBMSes
In-Reply-To: <146944420.1252685963539.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <38325079.1253142983746.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-521.
-------------------------------

    Resolution: Done


The change resolves this issue.

> Define infrastructure for testing with multiple DBMSes
> ------------------------------------------------------
>
>                 Key: DNA-521
>                 URL: https://jira.jboss.org/jira/browse/DNA-521
>             Project: DNA
>          Issue Type: Task
>    Affects Versions: 0.6
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> We need to support easily testing the different aspects of DNA (primarily integration testing, but including the JPA connector testing) on different DBMS systems.  There are several ways of doing this, but one seemingly attractive way is to define a Maven profile for each DBMS to define the dependencies, custom repositories for drivers, and Maven properties that define the database connection information.  Each project can then be done in a database-agnostic manner, where database-related information (e.g., connection properties, driver names, etc.) can be placed in a property file within the project's "/src/test/resources" area and defined in terms of the Maven properties.  Then the Maven build (or just test runs) can be executed by supplying the desired DBMS profile; ideally, the normal build process would be completed, and then the tests can be run using the different DBMS profiles.
> The jBPM4 project defines the profiles in their parent POM [1], while the Hibernate project defines them is their "testsuite" project's POM [2].  I actually like how jBPM defines it in the parent POM, but I like how Hibernate's POM defines and organizes their profiles.  Also note Hibernate's use of one DBMS profile (currently HSQLDB) as the default, meaning that all tests would normally pick that up.  Also, an example of a Hibernate test resource file that picks up the Maven properties is at [3].
> [1] https://anonsvn.jboss.org/repos/jbpm/jbpm4/trunk/pom.xml
> [2] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/pom.xml
> [3] https://anonsvn.jboss.org/repos/hibernate/core/trunk/testsuite/src/test/resources/hibernate.properties

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

        

From jira-events at lists.jboss.org  Fri Sep 18 16:18:01 2009
From: jira-events at lists.jboss.org (Jim McCollom (JIRA))
Date: Fri, 18 Sep 2009 16:18:01 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-467) Add search/query
 support to the graph API
In-Reply-To: <27219418.1245358316391.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <952831029.1253305081104.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Jim McCollom commented on DNA-467:
----------------------------------

Has any work begun on this or is it still in the planning stage ?

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

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

        

From jira-events at lists.jboss.org  Fri Sep 18 17:01:12 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 18 Sep 2009 17:01:12 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-467) Add search/query
 support to the graph API
In-Reply-To: <27219418.1245358316391.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1808648517.1253307672589.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

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

Actually, the work is pretty far along, and I'm actively working on it (now that 0.6 is out the door).  I'm actually working on a (local) branch, and am hoping to commit what I have to trunk relatively soon.

The design is based on the approach that JCR 2.0 has taken: multiple query languages are parsed into a single Abstract Syntax Tree (a "query model"), which is then executed by single engine.  This means that 'dna-graph' will have a QueryEngine component parses string queries (given the name of the language, and a registered parser for that language that transforms the string query into an AST representation), plans and optimizes the query, constructs a processing plan, and delegates to a 'QueryProcessor' component to execute the processing plan and generate the results.  These results are then returned to the caller of the QueryEngine.

This design allows us to do a couple of different things.  First, we can create multiple language parsers, yet have one engine.  Second, the planning and optimization components can either be customized or replaced, so the whole query engine framework can be reused.  Third, the query engine is completely independent of the execution, though the capabilities of the QueryProcessor can be taken into account during planning/optimization.  We're actually providing a QueryProceessor implementation that uses Lucene indexes, and with this a way to populate the Lucene indexes by scanning the graph content and/or updating the indexes based upon events.

We'll actually plug this query engine into the DNA JCR system in a couple of ways.  Each connector will optionally be able to support querying its content (either by pushing down the queries to the underlying system, or by having a Lucene index and just instantiating the query engine within the connector).  The federation connector will support queries by pushing down queries to the connectors being federated, and it will be able to manage a Lucene index for each connector that doesn't support queries.  Then, since the JCR implementation will basically just implemented on top of the federated connector, it just has to delegate the queries down to the federated connector.

Currently the following components are pretty complete (and have a lot of unit tests, though the tests are probably not sufficient): the QueryEngine, the AST classes, the query planner, the rule-based optimizer, and the QueryProcessor framework.  The Lucene-based QueryProcessor implementation is at least 50% done and what remains is mostly integration.  I'll be done with the JCR SQL2 parser (actually, the parser is complete and I have many unit tests, but only 50% of the parser is tested) in another day or so.

What's left is:
- commit the current state (I've been waiting to make sure all the pieces look like they'll fit together, and I'm probably no more than a few days away)
- write an XPath parser
- start integration testing of the query engine with the Lucene-based processor
- add query support to the connector API
- change some of our connectors to support queries (mostly just integrating the query engine and Lucene processor), though the federation connector will require some extra customization
- add support for text extraction
- expose through our JCR implementation
- make sure the events work and are wired correctly, as well as set up mechanisms to manage the scanning and re-indexing of all content

Another approach is to not yet put add query support to the connector API, but instead to just have our JCR implementation own the QueryEngine and Lucene-based processor.  I'm not sure if this will save much time or effort (mostly because of federation), but it is an option.

This is still a fair amount of work, but as you can see I think this design will be pretty powerful and will allow the connectors to really control how they handle queries.  When it's committed to trunk, we'll be able to divvy up the tasks.

WDYT so far?  Yeah, this is a really rough description, but I do hope to document this more and blog about some of the details.  

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

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

        

From jira-events at lists.jboss.org  Mon Sep 21 14:41:49 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Mon, 21 Sep 2009 14:41:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-524) JcrValueTest Fails Due
	To Timezone
Message-ID: <1068148493.1253558509465.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JcrValueTest Fails Due To Timezone
----------------------------------

                 Key: DNA-524
                 URL: https://jira.jboss.org/jira/browse/DNA-524
             Project: DNA
          Issue Type: Bug
          Components: Testing
    Affects Versions: 0.6
         Environment: Ubuntu 9.04
            Reporter: Dan Florian
            Assignee: Dan Florian
             Fix For: 0.7


JcrValueTest has 2 failures:

1. shouldProvideDateForDouble fails with this error:

java.lang.AssertionError: 
Expected: is <java.util.GregorianCalendar[time=0,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="US/Central",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=US/Central,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1969,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=6,HOUR_OF_DAY=18,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-21600000,DST_OFFSET=0]>
     got: <java.util.GregorianCalendar[time=0,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Chicago",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/Chicago,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1969,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=6,HOUR_OF_DAY=18,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-21600000,DST_OFFSET=0]>

	at org.junit.Assert.assertThat(Assert.java:502)
	at org.junit.Assert.assertThat(Assert.java:492)
	at org.jboss.dna.jcr.JcrValueTest.shouldProvideDateForDouble(JcrValueTest.java:159)

2. shouldProvideDateForLong fails with this error:

java.lang.AssertionError: 
Expected: is <java.util.GregorianCalendar[time=0,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="US/Central",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=US/Central,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1969,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=6,HOUR_OF_DAY=18,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-21600000,DST_OFFSET=0]>
     got: <java.util.GregorianCalendar[time=0,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Chicago",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/Chicago,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1969,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=6,HOUR_OF_DAY=18,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-21600000,DST_OFFSET=0]>

	at org.junit.Assert.assertThat(Assert.java:502)
	at org.junit.Assert.assertThat(Assert.java:492)
	at org.jboss.dna.jcr.JcrValueTest.shouldProvideDateForLong(JcrValueTest.java:192)

Tests are failing because expected timezone is "US/Central" and actual timezone is "America/Chicago." Changing the test to tests to check the milliseconds allows the tests to pass.

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

        

From jira-events at lists.jboss.org  Mon Sep 21 15:56:49 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Mon, 21 Sep 2009 15:56:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-467) Add search/query
 support to the graph API
In-Reply-To: <27219418.1245358316391.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <910204584.1253563009138.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

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

Added an initial version of the query engine functionality.  This design provides a way to define and supply queries (in a various languages) and have the engine parse them into a single Abstract Query Model (equivalent to the abstract syntax tree for a query), plan, validate, optimize and then process the portions atomic portions of the query plan.  This whole system was designed to be easily reused as-is or extended and customized to provide the desired behavior.  But because this is a generalized query engine capable of query over a 'graph', the actual processing of the atomic portions of the queries must be provided when the engine is used.  Part of this commit includes a new 'dna-search' project containing a specialization of the query engine with a processor capable of using a set of Lucene search indexes, along with utility and management methods to populate and update the indexes (by indexing the entire content and/or by updating the content based upon events).

A number of packages were added to 'dna-graph', including: an abstract query model (AQM) based upon the JSR-283 specification in 'o.j.dna.graph.query.model'; a query engine component in 'o.j.dna.graph.query', a query planning module in 'o.j.dna.graph.query.plan'; an extensible rule-based optimization module in 'o.j.dna.graph.query.optimize'; a simple way to define the schemata that is being queried in 'o.j.dna.query.validate'; a flexible processing plan model and execution framework in 'o.j.dna.graph.query.process'; and a framework for different query language parsers (including a JCR-SQL2 parser) in 'o.j.dna.query.parse'.  This entire query engine framework was designed to be reused and/or extended in multiple places, and so includes a way to accept and execute queries from a number of different an abstraction of the actual processing of the low-level atomic queries.  Numerous unit tests were added to test each of the components, including a large number of tests for the SQ!
 L parser.

A new 'dna-search' project was created and the initial Lucene-based query engine functionality was added.  Quite a few tests were added to verify the desired behavior.

At this point, the general query engine and the Lucene-based specialization are for the most part complete and thoroughly tested, but these components need to be integrated into the larger connector framework and JCR implementation.  All of the Lucene index generation and management needs to be coordinated and integrated with the administration and lifecycle of the DNA connectors and JCR engine.  Additionally, while there are methods to create/update the indexes, the ability to extract text from binary property values still needs to be added. In short, there still is a lot of outstanding work.

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

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

        

From jira-events at lists.jboss.org  Tue Sep 22 09:47:01 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 22 Sep 2009 09:47:01 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-525) Configure connection
 information for QA databases
Message-ID: <183174648.1253627221281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Configure connection information for QA databases
-------------------------------------------------

                 Key: DNA-525
                 URL: https://jira.jboss.org/jira/browse/DNA-525
             Project: DNA
          Issue Type: Task
          Components: Testing
    Affects Versions: 0.7
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.7


DNA-521 added the infrastructure for testing multiple databases, but didn't put in the correct connection information on the QA databases because we didn't yet have databases set up.  Now that we do have these databases, we have to update the connection information in the parent POM.xml.

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

        

From jira-events at lists.jboss.org  Tue Sep 22 13:05:09 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 22 Sep 2009 13:05:09 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-525) Configure connection
 information for QA databases
In-Reply-To: <183174648.1253627221281.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1327850507.1253639109782.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-525.
-------------------------------

    Resolution: Done


Successfully configured the connection information for Oracle 10g, Oracle 11g, Sybase 15, MySQL 5.x, MS SQL Server 2008, IBM DB2 v 9.x, and PostgreSQL 8.3 databases in the QA lab, which is accessible only to Red Hat employees.  Also, have not run any of the tests using these databases, so we may have problems.

> Configure connection information for QA databases
> -------------------------------------------------
>
>                 Key: DNA-525
>                 URL: https://jira.jboss.org/jira/browse/DNA-525
>             Project: DNA
>          Issue Type: Task
>          Components: Testing
>    Affects Versions: 0.7
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> DNA-521 added the infrastructure for testing multiple databases, but didn't put in the correct connection information on the QA databases because we didn't yet have databases set up.  Now that we do have these databases, we have to update the connection information in the parent POM.xml.

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

        

From jira-events at lists.jboss.org  Wed Sep 23 11:27:49 2009
From: jira-events at lists.jboss.org (Barry LaFond (JIRA))
Date: Wed, 23 Sep 2009 11:27:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-526) IllegalStateException
 calling TokenStream.canConsume(String str) after consuming all tokens via
 canConsume(String[])
Message-ID: <2101351563.1253719669245.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

IllegalStateException calling TokenStream.canConsume(String str) after consuming all tokens via canConsume(String[])
--------------------------------------------------------------------------------------------------------------------

                 Key: DNA-526
                 URL: https://jira.jboss.org/jira/browse/DNA-526
             Project: DNA
          Issue Type: Bug
          Components: Common
            Reporter: Barry LaFond


While parsing, I wished to call canConsume() for multiple "optional" properties.  Some are "multi-string" using canConsume("xxxx", "xxxx", ....)

If a previous canConsume() had finished parsing the tokens (i.e. currentToken == NULL), then a subsequent canConsume("xxxx") would result in the following exception:

java.lang.IllegalStateException: The 'start()' method must be called before tokens can be consumed or matched
	at org.jboss.dna.common.text.TokenStream.currentToken(TokenStream.java:1160)
	at org.jboss.dna.common.text.TokenStream.matches(TokenStream.java:866)
	at org.jboss.dna.common.text.TokenStream.canConsume(TokenStream.java:609)
	at ....

It appears that the canConsume( <MULTIPLE> ) methods do NOT call moveToNextToken() which is currently the only method that sets this.completed = TRUE.

Fix would be to add:  this.completed = this.currentToken == NULL before returning on the canConsume( <MULTIPLE> ) methods.

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

        

From jira-events at lists.jboss.org  Wed Sep 23 12:42:49 2009
From: jira-events at lists.jboss.org (Barry LaFond (JIRA))
Date: Wed, 23 Sep 2009 12:42:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-526) IllegalStateException
 calling TokenStream.canConsume(String str) after consuming all tokens via
 canConsume(String[])
In-Reply-To: <2101351563.1253719669245.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1440472357.1253724169248.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Barry LaFond updated DNA-526:
-----------------------------

    Attachment: dna-common_DNA_526.patch


Patch to ToekenStream.canConsume( <MULTIPLE> ) methods and added test cases to TokenStreamTest.java

> IllegalStateException calling TokenStream.canConsume(String str) after consuming all tokens via canConsume(String[])
> --------------------------------------------------------------------------------------------------------------------
>
>                 Key: DNA-526
>                 URL: https://jira.jboss.org/jira/browse/DNA-526
>             Project: DNA
>          Issue Type: Bug
>          Components: Common
>            Reporter: Barry LaFond
>         Attachments: dna-common_DNA_526.patch
>
>
> While parsing, I wished to call canConsume() for multiple "optional" properties.  Some are "multi-string" using canConsume("xxxx", "xxxx", ....)
> If a previous canConsume() had finished parsing the tokens (i.e. currentToken == NULL), then a subsequent canConsume("xxxx") would result in the following exception:
> java.lang.IllegalStateException: The 'start()' method must be called before tokens can be consumed or matched
> 	at org.jboss.dna.common.text.TokenStream.currentToken(TokenStream.java:1160)
> 	at org.jboss.dna.common.text.TokenStream.matches(TokenStream.java:866)
> 	at org.jboss.dna.common.text.TokenStream.canConsume(TokenStream.java:609)
> 	at ....
> It appears that the canConsume( <MULTIPLE> ) methods do NOT call moveToNextToken() which is currently the only method that sets this.completed = TRUE.
> Fix would be to add:  this.completed = this.currentToken == NULL before returning on the canConsume( <MULTIPLE> ) methods.

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

        

From jira-events at lists.jboss.org  Fri Sep 25 08:31:49 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Fri, 25 Sep 2009 08:31:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-524) JcrValueTest Fails
	Due To Timezone
In-Reply-To: <1068148493.1253558509465.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1542698918.1253881909645.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Dan Florian resolved DNA-524.
-----------------------------

    Resolution: Done


Test was changed to test milliseconds and now is working.

> JcrValueTest Fails Due To Timezone
> ----------------------------------
>
>                 Key: DNA-524
>                 URL: https://jira.jboss.org/jira/browse/DNA-524
>             Project: DNA
>          Issue Type: Bug
>          Components: Testing
>    Affects Versions: 0.6
>         Environment: Ubuntu 9.04
>            Reporter: Dan Florian
>            Assignee: Dan Florian
>             Fix For: 0.7
>
>
> JcrValueTest has 2 failures:
> 1. shouldProvideDateForDouble fails with this error:
> java.lang.AssertionError: 
> Expected: is <java.util.GregorianCalendar[time=0,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="US/Central",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=US/Central,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1969,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=6,HOUR_OF_DAY=18,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-21600000,DST_OFFSET=0]>
>      got: <java.util.GregorianCalendar[time=0,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Chicago",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/Chicago,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1969,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=6,HOUR_OF_DAY=18,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-21600000,DST_OFFSET=0]>
> 	at org.junit.Assert.assertThat(Assert.java:502)
> 	at org.junit.Assert.assertThat(Assert.java:492)
> 	at org.jboss.dna.jcr.JcrValueTest.shouldProvideDateForDouble(JcrValueTest.java:159)
> 2. shouldProvideDateForLong fails with this error:
> java.lang.AssertionError: 
> Expected: is <java.util.GregorianCalendar[time=0,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="US/Central",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=US/Central,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1969,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=6,HOUR_OF_DAY=18,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-21600000,DST_OFFSET=0]>
>      got: <java.util.GregorianCalendar[time=0,areFieldsSet=true,areAllFieldsSet=true,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/Chicago",offset=-21600000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/Chicago,offset=-21600000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=1969,MONTH=11,WEEK_OF_YEAR=1,WEEK_OF_MONTH=5,DAY_OF_MONTH=31,DAY_OF_YEAR=365,DAY_OF_WEEK=4,DAY_OF_WEEK_IN_MONTH=5,AM_PM=1,HOUR=6,HOUR_OF_DAY=18,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-21600000,DST_OFFSET=0]>
> 	at org.junit.Assert.assertThat(Assert.java:502)
> 	at org.junit.Assert.assertThat(Assert.java:492)
> 	at org.jboss.dna.jcr.JcrValueTest.shouldProvideDateForLong(JcrValueTest.java:192)
> Tests are failing because expected timezone is "US/Central" and actual timezone is "America/Chicago." Changing the test to tests to check the milliseconds allows the tests to pass.

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

        

From jira-events at lists.jboss.org  Fri Sep 25 10:54:49 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Fri, 25 Sep 2009 10:54:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-527)
 JcrSingleValuePropertyTest's Date Test Fails On Ubuntu
Message-ID: <487398944.1253890489290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

JcrSingleValuePropertyTest's Date Test Fails On Ubuntu
------------------------------------------------------

                 Key: DNA-527
                 URL: https://jira.jboss.org/jira/browse/DNA-527
             Project: DNA
          Issue Type: Bug
          Components: Graph, Testing
    Affects Versions: 0.6
         Environment: Ubuntu 9.04
            Reporter: Dan Florian
            Assignee: Dan Florian
             Fix For: 0.7


The "shouldProvideDate" test fails due to differences in the toString() values of the Calendar objects. Removing the asserts that check the toString(), the length of the toString(), and the Calendars will allow the test to pass. With these 3 assert removed the test is still checking the milliseconds of the date and the type which is sufficient. The Calendar test is failing because one calendar has an id of "GMT" while the other one is using "UTC."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 25 11:00:01 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Fri, 25 Sep 2009 11:00:01 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-527)
 JcrSingleValuePropertyTest's Date Test Fails On Ubuntu
In-Reply-To: <487398944.1253890489290.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1522854852.1253890801429.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Dan Florian resolved DNA-527.
-----------------------------

    Resolution: Done


No longer comparing Calendar objects or toString(). There is a problem with one case using "UTC" and the other using "GMT."

> JcrSingleValuePropertyTest's Date Test Fails On Ubuntu
> ------------------------------------------------------
>
>                 Key: DNA-527
>                 URL: https://jira.jboss.org/jira/browse/DNA-527
>             Project: DNA
>          Issue Type: Bug
>          Components: Graph, Testing
>    Affects Versions: 0.6
>         Environment: Ubuntu 9.04
>            Reporter: Dan Florian
>            Assignee: Dan Florian
>             Fix For: 0.7
>
>
> The "shouldProvideDate" test fails due to differences in the toString() values of the Calendar objects. Removing the asserts that check the toString(), the length of the toString(), and the Calendars will allow the test to pass. With these 3 assert removed the test is still checking the milliseconds of the date and the type which is sufficient. The Calendar test is failing because one calendar has an id of "GMT" while the other one is using "UTC."

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 25 16:08:49 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Fri, 25 Sep 2009 16:08:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-528) Loading Additional
 Mimetypes Via Stream Does Not Work in MimeTypeUtil
Message-ID: <803751172.1253909329116.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Loading Additional Mimetypes Via Stream Does Not Work in MimeTypeUtil
---------------------------------------------------------------------

                 Key: DNA-528
                 URL: https://jira.jboss.org/jira/browse/DNA-528
             Project: DNA
          Issue Type: Bug
          Components: Common
    Affects Versions: 0.6
         Environment: Ubuntu 9.04
            Reporter: Dan Florian
            Assignee: Dan Florian
             Fix For: 0.7


Custom extension to mimetype mappings are not available after load. I'm calling the static load(InputStream, Map) method and passing the resultant Map into the MimeTypeUtil constructor. However none of the mappings are available to the MimeTypeUtil object.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 25 17:19:49 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Fri, 25 Sep 2009 17:19:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-528) Loading Additional
 Mimetypes Via Stream Does Not Work in MimeTypeUtil
In-Reply-To: <803751172.1253909329116.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <2064099862.1253913589210.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Dan Florian resolved DNA-528.
-----------------------------

    Resolution: Done


Fixed a regex in constructor that was nulling out all extensions loaded using the load method. Also fixed a problem where hidden files (files with just an extension) were not getting a mimetype. Added some tests.

> Loading Additional Mimetypes Via Stream Does Not Work in MimeTypeUtil
> ---------------------------------------------------------------------
>
>                 Key: DNA-528
>                 URL: https://jira.jboss.org/jira/browse/DNA-528
>             Project: DNA
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 0.6
>         Environment: Ubuntu 9.04
>            Reporter: Dan Florian
>            Assignee: Dan Florian
>             Fix For: 0.7
>
>
> Custom extension to mimetype mappings are not available after load. I'm calling the static load(InputStream, Map) method and passing the resultant Map into the MimeTypeUtil constructor. However none of the mappings are available to the MimeTypeUtil object.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 25 18:38:49 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 25 Sep 2009 18:38:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-529) Upgrade to Lucene 2.9
Message-ID: <1409673643.1253918329250.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

Upgrade to Lucene 2.9
---------------------

                 Key: DNA-529
                 URL: https://jira.jboss.org/jira/browse/DNA-529
             Project: DNA
          Issue Type: Thirdparty Change
          Components: JCR
    Affects Versions: 0.7
            Reporter: Randall Hauch
            Assignee: Randall Hauch
             Fix For: 0.7


Lucene 2.9 was just released, and includes a whole host of new features.  Lucene 3.0 should be released soon as basically a 2.9 minus deprecations, so if that comes out soon we should probably just jump to that.

Lucene 2.9 is not yet in the JBoss Maven repository, so that needs to be done and will be a fair amount of work (considering all the many different modules that make up Lucene).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 25 18:40:49 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Fri, 25 Sep 2009 18:40:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-529) Upgrade to Lucene 2.9
In-Reply-To: <1409673643.1253918329250.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1674690620.1253918449160.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-529:
------------------------------

    Component/s: Search


> Upgrade to Lucene 2.9
> ---------------------
>
>                 Key: DNA-529
>                 URL: https://jira.jboss.org/jira/browse/DNA-529
>             Project: DNA
>          Issue Type: Thirdparty Change
>          Components: JCR, Search
>    Affects Versions: 0.7
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> Lucene 2.9 was just released, and includes a whole host of new features.  Lucene 3.0 should be released soon as basically a 2.9 minus deprecations, so if that comes out soon we should probably just jump to that.
> Lucene 2.9 is not yet in the JBoss Maven repository, so that needs to be done and will be a fair amount of work (considering all the many different modules that make up Lucene).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 29 12:36:00 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Tue, 29 Sep 2009 12:36:00 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Created: (DNA-530)
 ClasspathLocalizationRepository Should Not Use Thread Context Class Loader
Message-ID: <1642493893.1254242160427.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>

ClasspathLocalizationRepository Should Not Use Thread Context Class Loader
--------------------------------------------------------------------------

                 Key: DNA-530
                 URL: https://jira.jboss.org/jira/browse/DNA-530
             Project: DNA
          Issue Type: Bug
          Components: Common
    Affects Versions: 0.6
         Environment: Ubuntu 9.04
            Reporter: Dan Florian
            Assignee: Dan Florian
             Fix For: 0.7


Ran Eclipse with JBoss MetaMatrix Designer installed as well as the DNA Eclipse plugin. At startup MetaMatrix sets the current thread's context class loader. This was causing a problem (stack overflow) in I18N class used by the DNA Eclipse plugin. ClasspathLocalizationRepository should always use it's own class loader.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 29 13:29:49 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 29 Sep 2009 13:29:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Commented: (DNA-529) Upgrade to Lucene 2.9
In-Reply-To: <1409673643.1253918329250.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <932790158.1254245389230.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch commented on DNA-529:
-----------------------------------

Uploaded the 2.9.0 artifacts (well, those that we're using) into the JBoss Maven repository, and changed the POM files.  Removed use of deprecated methods, which required some changes to know whether IndexReader objects were allowed to change the indexes.  All unit tests run successfully.

> Upgrade to Lucene 2.9
> ---------------------
>
>                 Key: DNA-529
>                 URL: https://jira.jboss.org/jira/browse/DNA-529
>             Project: DNA
>          Issue Type: Thirdparty Change
>          Components: JCR, Search
>    Affects Versions: 0.7
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> Lucene 2.9 was just released, and includes a whole host of new features.  Lucene 3.0 should be released soon as basically a 2.9 minus deprecations, so if that comes out soon we should probably just jump to that.
> Lucene 2.9 is not yet in the JBoss Maven repository, so that needs to be done and will be a fair amount of work (considering all the many different modules that make up Lucene).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 29 14:15:02 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Tue, 29 Sep 2009 14:15:02 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-529) Upgrade to Lucene 2.9
In-Reply-To: <1409673643.1253918329250.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <1295219963.1254248102103.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch resolved DNA-529.
-------------------------------

    Resolution: Done


The upgrade was completed.

> Upgrade to Lucene 2.9
> ---------------------
>
>                 Key: DNA-529
>                 URL: https://jira.jboss.org/jira/browse/DNA-529
>             Project: DNA
>          Issue Type: Thirdparty Change
>          Components: JCR, Search
>    Affects Versions: 0.7
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> Lucene 2.9 was just released, and includes a whole host of new features.  Lucene 3.0 should be released soon as basically a 2.9 minus deprecations, so if that comes out soon we should probably just jump to that.
> Lucene 2.9 is not yet in the JBoss Maven repository, so that needs to be done and will be a fair amount of work (considering all the many different modules that make up Lucene).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 30 09:12:49 2009
From: jira-events at lists.jboss.org (Dan Florian (JIRA))
Date: Wed, 30 Sep 2009 09:12:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Resolved: (DNA-530)
 ClasspathLocalizationRepository Should Not Use Thread Context Class Loader
In-Reply-To: <1642493893.1254242160427.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>
Message-ID: <963527807.1254316369234.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Dan Florian resolved DNA-530.
-----------------------------

    Resolution: Done


In the constructor, removed the code that sets the class loader to the current thread's class loader if no class loader is specified. Now when no class loader is specified at construction the class loader of this class will be used.

> ClasspathLocalizationRepository Should Not Use Thread Context Class Loader
> --------------------------------------------------------------------------
>
>                 Key: DNA-530
>                 URL: https://jira.jboss.org/jira/browse/DNA-530
>             Project: DNA
>          Issue Type: Bug
>          Components: Common
>    Affects Versions: 0.6
>         Environment: Ubuntu 9.04
>            Reporter: Dan Florian
>            Assignee: Dan Florian
>             Fix For: 0.7
>
>
> Ran Eclipse with JBoss MetaMatrix Designer installed as well as the DNA Eclipse plugin. At startup MetaMatrix sets the current thread's context class loader. This was causing a problem (stack overflow) in I18N class used by the DNA Eclipse plugin. ClasspathLocalizationRepository should always use it's own class loader.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.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 Sep 30 12:08:49 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 30 Sep 2009 12:08:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Assigned: (DNA-468) Add XPath query
	language support
In-Reply-To: <19863639.1245358556324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <1967750861.1254326929655.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch reassigned DNA-468:
---------------------------------

    Assignee: Randall Hauch  (was: Johnny Verhaeg)


> Add XPath query language support
> --------------------------------
>
>                 Key: DNA-468
>                 URL: https://jira.jboss.org/jira/browse/DNA-468
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph, JCR
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>             Fix For: 0.7
>
>
> Create an XPath language binding for our graph model, so that we can parse XPath queries and produce query models that can then be executed.
> This can probably be done as a separate project dependent upon dna-graph, perhaps in the extensions folder (since it'd be a query language extension).  Maybe "extensions/dna-query-xpath"?

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

        

From jira-events at lists.jboss.org  Wed Sep 30 12:10:49 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 30 Sep 2009 12:10:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-468) Add XPath query
	language support
In-Reply-To: <19863639.1245358556324.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <295471937.1254327049245.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-468:
------------------------------

    Priority: Blocker  (was: Major)


> Add XPath query language support
> --------------------------------
>
>                 Key: DNA-468
>                 URL: https://jira.jboss.org/jira/browse/DNA-468
>             Project: DNA
>          Issue Type: Feature Request
>          Components: API, Graph, JCR
>    Affects Versions: 0.5
>            Reporter: Randall Hauch
>            Assignee: Randall Hauch
>            Priority: Blocker
>             Fix For: 0.7
>
>
> Create an XPath language binding for our graph model, so that we can parse XPath queries and produce query models that can then be executed.
> This can probably be done as a separate project dependent upon dna-graph, perhaps in the extensions folder (since it'd be a query language extension).  Maybe "extensions/dna-query-xpath"?

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

        

From jira-events at lists.jboss.org  Wed Sep 30 12:10:49 2009
From: jira-events at lists.jboss.org (Randall Hauch (JIRA))
Date: Wed, 30 Sep 2009 12:10:49 -0400 (EDT)
Subject: [dna-issues] [JBoss JIRA] Updated: (DNA-467) Add search/query
 support to the graph API
In-Reply-To: <27219418.1245358316391.JavaMail.jira@cloud.prod.atl2.jboss.com>
Message-ID: <845552251.1254327049221.JavaMail.jboss@jira01.app.mwc.hst.phx2.redhat.com>


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

Randall Hauch updated DNA-467:
------------------------------

    Priority: Blocker  (was: Critical)


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

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

        

