Testing Blocker Tickets
|CLAW||#IslandoraCon demo works fine with 4.7.3-RC1|
git clone https://github.com/fcrepo4/fcrepo4 cd fcrepo4 git checkout <version>-RC
|fcrepo4||mvn clean install|
|fcrepo4||mvn clean install||mac||Jared Whiklo|
|fcrepo4||mvn clean install||windows||Aaron Birkland|
|fcrepo-module-auth-rbacl||mvn clean install||linux|
|fcrepo-module-auth-rbacl||mvn clean install||mac||Jared Whiklo|
|fcrepo-module-auth-rbacl||mvn clean install||windows|
|fcrepo-module-auth-xacml||mvn clean install||linux|
|fcrepo-module-auth-xacml||mvn clean install||mac||Jared Whiklo|
|fcrepo-module-auth-xacml||mvn clean install||windows|
|fcrepo-module-auth-webac||mvn clean install||linux|
|fcrepo-module-auth-webac||mvn clean install||mac|
|fcrepo-module-auth-webac||mvn clean install||windows|
|fcrepo-mint||mvn clean install||linux|
|fcrepo-mint||mvn clean install||mac|
|fcrepo-mint||mvn clean install||windows||Aaron Birkland|
|fcrepo-audit||mvn clean install||linux|
|fcrepo-audit||mvn clean install||mac|
|fcrepo-audit||mvn clean install||windows|
|fcrepo-webapp-plus||mvn clean install||linux|
|fcrepo-webapp-plus||mvn clean install||mac|
|fcrepo-webapp-plus||mvn clean install||windows|
|fcrepo-webapp-plus||mvn clean install -Pwebac||linux|
|fcrepo-webapp-plus||mvn clean install -Pwebac||mac|
|fcrepo-webapp-plus||mvn clean install -Pwebac||windows|
|fcrepo-webapp-plus||mvn clean install -Paudit||linux|
|fcrepo-webapp-plus||mvn clean install -Paudit||mac|
|fcrepo-webapp-plus||mvn clean install -Paudit||windows|
|fcrepo-webapp-plus||mvn clean install -P\!webac,\!audit||linux|
|fcrepo-webapp-plus||mvn clean install -P\!webac,\!audit||mac|
|fcrepo-webapp-plus||mvn clean install -P\!webac,\!audit||windows|
cd fcrepo-webapp; mvn clean install -Pone-click
|java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar||Linux|| |
|java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar||Mac||Youn Noh||Namespace prefix bindings in transactions that are rolled back persist.|
java -jar fcrepo-webapp-<version>-SNAPSHOT-jetty-console.jar
All of the below should take place in the HTML UI and non-vagrant tests should run against fcrepo-webapp-plus.
- Create nested containers
- Create binary resources
- Run fixity on binary
- Update Properties: Perform SPARQL-Update on container
- Update Properties: Perform SPARQL-Update on binary
- Delete container
- Delete binary
- Use transactions
- Create versions
- View versions
- Rollback versions
With Tomcat7 deployment, run above manual tests with alternate backend databases (Configuring JDBC Object Store)
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.
Size of Backup (du -h .)
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 destroy vagrant up
|Test steps||Tested by||Success?||Notes|
Same as above, plus:
- Verify audit events are in triplestore
- Verify resources are in triplestore (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)
- Verify resources are in Solr
- Verify authorization works for the two auth-enabled configurations
- Verify reindexing to triplestore works (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
- Start 4.7.0 with a new data directory
- Create a resource with SKOS namespace
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/
- Stop 4.7.0
- Start 4.7.2 with the same data directory – should start successfully
- Stop and start 4.7.2 with the same data directory – should display error on startup
- 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
 Testing scripts
just reporting out that I have not been able to reproduce a 4.7.0→4.7.2 upgrade problem.
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
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
I am able to reproduce the error and the fix with the following steps:
Create new object with obj.ttl
Stop tomcat and remove exploded war
Note: once we are in the BOOM state, it is not clear how to get out of it.
Update: I have also demonstrated the same behavior as noted above with the "file-simple" configuration:
Update: I have also demonstrated the same behavior as noted above with the "one-click".
Start the 4.7.0 one-click
Create new object with obj.ttl
curl -i -XPUT -H
Stop the 4.7.0 one-click
Replicated Andrew Woods results from above.
Ok, I've reproduced the issue following the above steps. It seems like the re-start is somehow important
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.
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
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
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
ns001from 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:
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.
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