Testing Blocker Tickets

  • ...

External Projects



Tested by

Success? RC-1










Plum (tick)
Sufia (tick)



Tested by

Success? RC-1


CLAW(tick)#IslandoraCon demo works fine with 4.7.3-RC1

Testing Plan

git clone https://github.com/fcrepo4/fcrepo4
cd fcrepo4
git checkout <version>-RC

Sanity Builds

ProjectCommandPlatformTested bySuccess?Notes
fcrepo4mvn clean install


fcrepo4mvn clean install mac Jared Whiklo (tick)  
fcrepo4mvn clean installwindowsAaron Birkland (tick)  
fcrepo-module-auth-rbaclmvn clean installlinux(tick)  
fcrepo-module-auth-rbaclmvn clean install mac Jared Whiklo(tick)  
fcrepo-module-auth-rbaclmvn clean installwindows(tick)  
fcrepo-module-auth-xacmlmvn clean install linux(tick)  
fcrepo-module-auth-xacmlmvn clean install macJared Whiklo (tick)  
fcrepo-module-auth-xacmlmvn clean installwindows(tick)  
fcrepo-module-auth-webacmvn clean install linux(tick)  
fcrepo-module-auth-webacmvn clean install mac(tick)  
fcrepo-module-auth-webacmvn clean installwindows(tick)  
fcrepo-mintmvn clean install linux(tick)  
fcrepo-mintmvn clean install mac(tick)  
fcrepo-mintmvn clean installwindowsAaron Birkland (tick)  
fcrepo-auditmvn clean install linux(tick)  
fcrepo-auditmvn clean install mac(tick)  
fcrepo-auditmvn clean installwindows(tick) 
fcrepo-webapp-plusmvn clean install linux(tick)  
fcrepo-webapp-plusmvn clean install mac(tick)  
fcrepo-webapp-plusmvn clean install windows(tick) 
fcrepo-webapp-plusmvn clean install -Pwebac linux(tick) 


fcrepo-webapp-plusmvn clean install -Pwebac mac (tick) 
fcrepo-webapp-plusmvn clean install -Pwebac windows(tick) 
fcrepo-webapp-plusmvn clean install -Pauditlinux(tick) 


fcrepo-webapp-plusmvn clean install -Paudit mac (tick) 
fcrepo-webapp-plusmvn clean install -Paudit windows (tick) 
fcrepo-webapp-plusmvn clean install -P\!webac,\!auditlinux(tick)  
fcrepo-webapp-plusmvn clean install -P\!webac,\!audit mac (tick) 
fcrepo-webapp-plusmvn clean install -P\!webac,\!audit windows (tick) 

One-Click Run

cd fcrepo-webapp; mvn clean install -Pone-click
CommandPlatform Tested bySuccess? Notes
java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jarLinux(tick)
java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jarMac Youn Noh      (tick)Namespace prefix bindings in transactions that are rolled back persist.

java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar


Manual Tests

All of the below should take place in the HTML UI and non-vagrant tests should run against fcrepo-webapp-plus.

  1. Create nested containers
  2. Create binary resources
  3. Run fixity on binary
  4. Update Properties:  Perform SPARQL-Update on container
  5. Update Properties:  Perform SPARQL-Update on binary
  6. Delete container
  7. Delete binary
  8. Use transactions
  9. Create versions
  10. View versions
  11. Rollback versions

Database Tests

With Tomcat7 deployment, run above manual tests with alternate backend databases (Configuring JDBC Object Store)

DatabasePlatformTested bySuccess?Notes
MySQLMacOSX 10.11.6
MySQL 5.7.17


PostgreSQLMacOSX 10.12.5
PostgreSQL 9.4.5
Esmé Cowles(tick)

fcr:backup/fcr:restore Functionality

These tests are designed to ensure the proper function of the 'fcr:backup/fcr:restore' features by testing them against various Fedora configurations.  The validity of the 'restore' can only be determined by crawling the repository and verifying the successful retrieval of the repository's content.

If the anticipated Fedora release is not backwards compatible with the previous version of Fedora, then the "From Fedora Version" should be the previous version.  Otherwise, it is sufficient to test the fcr:backup/fcr:restore functionality using the same version.

See: RESTful HTTP API - Backup and Restore

# Backup
curl -X POST localhost:8080/rest/fcr:backup
# Restore
curl -X POST -d "/path/to/backup/directory" localhost:8080/rest/fcr:restore


  • These python scripts - fcrepo-testing - can be used to load RDF content and binary content to a Fedora repository and verify the integrity of the loaded resources.  Output from the load process can be used to verify the integrity of a 'restored' repository.  See the README for more info.
  • This script can be used to walk your repository, failing if a non-success response is encountered.


Tested by






From Fedora

To Fedora 

Number of

RDF Resources

Number of


Size of Backup (du -h .)



LinuxJettyfile-simple4. dataset

NB: "Success" is measured not by receiving a "204 No Content" message after the 'fcr:restore' command, but by performing a GET on every resource in the repository and receiving "200 OK" messages. 

Vagrant Tests

vagrant destroy
vagrant up
Test stepsTested bySuccess?Notes

















Manual Tests

Same as above, plus:

  1. Verify audit events are in triplestore (tick)
  2. Verify resources are in triplestore (tick) (Note: indexing works very poorly when using the testing scripts because rapidly adding and then removing items causes the message queue to get very backed up)
  3. Verify resources are in Solr (tick)
  4. Verify authorization works for the two auth-enabled configurations (tick)
  5. Verify reindexing to triplestore works (tick) (tested by looking in fuseki after each step: adding a resource, adding a dc:title, removing dc:title, deleting resource.  Did not test the camel separate reindexing feature.)

4.7.0 - 4.7.2 Upgrade Testing

Tests to verify if 4.7.3 resolves errors seen with upgrading from 4.7.0 to 4.7.2

  1. 4.7.2
    1. Start 4.7.0 with a new data directory
    2. Create a resource with SKOS namespace
      1. curl -X POST -d "<> a <http://www.w3.org/2004/02/skos/core#Concept>; <http://www.w3.org/2004/02/skos/core#prefLabel> 'foo' ." -H "Content-type: text/turtle" -D - http://localhost:8080/rest/

    3. Stop 4.7.0
    4. Start 4.7.2 with the same data directory – should start successfully
    5. Stop and start 4.7.2 with the same data directory – should display error on startup
  2. 4.7.3
    1. Repeat 1. with a clean data directory, but deploying 4.7.3 instead of 4.7.2 and verifying that the error does not occur
Tested bySuccess?Notes

[1] Testing scripts

[2] Fedora 4 Release Test Suite

  • No labels


  1. just reporting out that I have not been able to reproduce a 4.7.0→4.7.2 upgrade problem.

    I tried:

    • various permutations of levelDB, PostgreSQL, and LevelDB with no differences observed between them
    • Adding a mixture of objects, some using exclusively "built-in" namespaces, some with namespaces (such as SKOS) that were added later to the CND file in 4.7.1, and some with custom namespaces (e.g. <http://example.org/test#>
    • Using different classes of namespaces (custom, updated-in-4.7.2, built-in) together, in various positions (predicates vs objects)

    In all cases, creating these objects in 4.7.0, shutting down Fedora, and dropping 4.7.2 in its place did not cause any errors.  To verify, I

    • Started Fedora to see if there were any errors upon startup
    • Viewed each object with GET
    • Updated each object with PATCH.

    So I have not been able to confirm the working theory that modifying the CND file between releases causes any problems per se, and have not been able to confirm that reverting the CND file in 4.7.3 represents a fix 

    1. I am able to reproduce the error and the fix with the following steps:

        • Using tomcat8 and mysql
      JAVA_OPTS="${JAVA_OPTS} -Dfcrepo.modeshape.configuration=classpath:/config/jdbc-mysql/repository.json"
      1. Ensure mysql is clean... meaning there is no existing Fedora data
      2. Deploy 4.7.0
      3. Create new object with obj.ttl

        curl -i -XPUT -H"Content-Type: text/turtle" --data-binary @obj.ttl localhost:8080/fcrepo/rest/obj
      4. Stop tomcat and remove exploded war

      5. Deploy 4.7.3-RC - all is well
      6. Restart 4.7.3-RC - all is well
      7. Stop tomcat and remove exploded war
      8. Deploy 4.7.2 - all is well
      9. Restart 4.7.2 - BOOM!

      Note: once we are in the BOOM state, it is not clear how to get out of it.

      1. Update: I have also demonstrated the same behavior as noted above with the "file-simple" configuration:

        JAVA_OPTS="${JAVA_OPTS} -Dfcrepo.modeshape.configuration=classpath:/config/file-simple/repository.json"
        1. Update: I have also demonstrated the same behavior as noted above with the "one-click".


          1. Place all three versions of the one-click in the same directory (4.7.0, 4.7.2, 4.7.3-RC)
          2. Start the 4.7.0 one-click

            java -jar fcrepo-webapp-4.7.0-jetty-console.jar --headless
          3. Create new object with obj.ttl

            curl -i -XPUT -H"Content-Type: text/turtle" --data-binary @obj.ttl localhost:8080/rest/obj

          4. Stop the 4.7.0 one-click

          5. Start the 4.7.3-RC one-click - all is well
          6. Stop/Start the 4.7.3-RC one-click - all is well
          7. Stop the 4.7.3-RC one-click
          8. Start the 4.7.2 one-click - all is well
          9. Stop/Start the 4.7.2 one-click - BOOM!
          1. Replicated Andrew Woods results from above.

          2. Ok, I've reproduced the issue following the above steps.  It seems like the re-start is somehow important

            1. I was also able to reproduce using these steps — and I do not see the error when I repeat the steps using 4.7.3rc1.

              1. Agreed  I see:

                4.7.0→ 4.7.2: error

                4.7.0→4.7.3: no error

                4.7.2→4.7.3: no error

      2. Well that's interesting.  I just re-started the instance I had up from the other day (running 4.7.2 now).  no BOOM.  Let me start over and use the exact data you are

  2. It looks 4.7.1 and 4.7.2 make the fatal error of removing the ns00* namespaces from the modeshape node that defines namespaces.  This happens for all ns00* URIs that were not defined in 4.7.0's CND file, but are defined in 4.7.1, 4.7.2.  Otherwise, all data seems to be intact. 

    Taking a backup (fcr:backup) from 4.7.1, 4.7.2 (if it's still running, and hasn't already seen the error) results in an unrestorable backup, since it's missing the ns00* namespaces.

    I found that by manually editing the json in the backup, the backup can then be used just fine.

    In particular, suppose that 4.7.0 used ns001: for http://www.w3.org/2004/02/skos/core#.  Fedora 4.7.1 and 4.7.2 want to call it skos:, and remove ns001 from the namespace definition node.

    The namespaces node can be found by digging through the json of a backup.  Edit it it in order to add in the ns00* namespaces:

      "metadata": {
        "id": "a9789f6317f1e7mode:namespaces"
      "content": {
        "key": "a9789f6317f1e7mode:namespaces",
        "parent": "a9789f6317f1e7jcr:system",
        "properties": {
          "http://www.jcp.org/jcr/1.0": {
            "primaryType": {
              "$name": "mode:namespaces"
        "children": [
            "key": "a9789f6317f1e7mode:namespaces-http://www.jcp.org/jcr/1.0",
            "name": "jcr"
          },  .... {
            "key": "a9789f6317f1e7mode:namespaces-http://www.w3.org/2004/02/skos/core#",
            "name": "skos"
            "key": "a9789f6317f1e7mode:namespaces-http://www.w3.org/2004/02/skos/core#",
            "name": "ns001"

    That seems to be restorable into 4.7.3 via fcr:restore.  So it seems that there's a path forward to fixing repositories that have been affected by the underling issue.

  3. Here is a google doc containing potential release notes on how to identify and fix the corruption problem, for those who are running an affected 4.7.1 or 4.7.2 instance:  https://docs.google.com/document/d/1Dk2V2hqVyKs0V_70lAIObXT3_EjDIh8YxoZtdKnDdWU/edit?usp=sharing