I recently tested an ISLE migration build using the "latest" version of Discovery Garden's foxmlToSolr.xslt. Found [here(https://github.com/discoverygarden/basic-solr-config/blob/4.10.x/foxmlToSolr.xslt) and found that it (appeared) to cause a failure to re-index SOLR and even worse caused the Fedora Gsearch admin Update Index page (or any of the Gsearch pages) to white screen.
Not clear where the xslt validation error is stemming from, foxmlToSolr.xslt or another transform that it points to. Further digging and discovery needed.
Thanks!!
Please note / additional background information
1) ISLE uses a version of foxmlToSolr.xslt prior to December 2017 and uses the 4.10.x branch of the Discovery Garden basic solr config. Do not use any other branch please. If you diff these files you'll see differences. Apologies I've not had time to review what they specifically are due to time constraints.
2) All other transforms e.g islandora_transforms would be recent as of March 2018 from last image build pushed to Docker Hub.
3) It is also possible that the schema / solrconfig files may have changed since this last image push to Docker Hub.
4) Additional information re the Fedora Gsearch rest page white screening can be found in this islandora google group post
^ This is my only clue towards any potential failure culprit!
Steps to reproduce the issue
While I was using a specific migrated build, recommend testing using the default isle.localdomain build for faster testing. Please note I've not run these exact steps and am asking if someone can replicate as well, so apologies in advance if I've guessed all of the steps incorrectly below. I was able to consistently replicate using a migrated build.
Assumes that testing on a ISLE dev environment will not involve rebuilding images.
If starting from scratch, simply download current existing ISLE images and only run using the Test Site Installation Guide and then follow those involved steps prior to advancing to step 2. If you already have a working isle.localdomain environment and are fine with testing, proceed to step 2.
Clone the DG basic-solr-config repo or git clone -b 4.10.x https://github.com/discoverygarden/basic-solr-config/tree/4.10.x
Copy the foxmlToSolr.xslt file to the ISLE project directory e.g. ~/ISLE/fedora/gsearch. This should replace the current one there. (only for the test don't build images with this!)
Edit the docker-compose.yml. Under the fedoravolumes section add a line that points to the new foxmlToSolr.xslt file e.g. - ./fedora/gsearch/foxmlToSolr.xslt:/usr/local/tomcat//webapps/fedoragsearch/WEB-INF/classes/fgsconfigFinal/index/FgsIndex/foxmlToSolr.xslt
Run docker-compose up -d and attempt to view the Fedoragearch admin panel.
That SOLR reindexing will not fail and that the Fedora Gsearch Admin > Update Index page is viewable instead of a white screen.
What's the actual result?
SOLR reindexing by command line fails due to java error e.g. "java.net.UnknownServiceException: no content-type" (vague vague error) and the Fedora Gsearch Admin > Update Index page (or other pages) is not viewable as instead a white screen appears.
Issue description
I recently tested an ISLE migration build using the "latest" version of Discovery Garden's
foxmlToSolr.xslt
. Found [here(https://github.com/discoverygarden/basic-solr-config/blob/4.10.x/foxmlToSolr.xslt) and found that it (appeared) to cause a failure to re-index SOLR and even worse caused the Fedora Gsearch admin Update Index page (or any of the Gsearch pages) to white screen.Not clear where the xslt validation error is stemming from,
foxmlToSolr.xslt
or another transform that it points to. Further digging and discovery needed.Thanks!!
Please note / additional background information
1) ISLE uses a version of
foxmlToSolr.xslt
prior to December 2017 and uses the4.10.x
branch of the Discovery Garden basic solr config. Do not use any other branch please. If you diff these files you'll see differences. Apologies I've not had time to review what they specifically are due to time constraints.2) All other transforms e.g islandora_transforms would be recent as of March 2018 from last image build pushed to Docker Hub.
3) It is also possible that the schema / solrconfig files may have changed since this last image push to Docker Hub.
4) Additional information re the Fedora Gsearch rest page white screening can be found in this islandora google group post ^ This is my only clue towards any potential failure culprit!
Steps to reproduce the issue
While I was using a specific migrated build, recommend testing using the default
isle.localdomain
build for faster testing. Please note I've not run these exact steps and am asking if someone can replicate as well, so apologies in advance if I've guessed all of the steps incorrectly below. I was able to consistently replicate using a migrated build.Assumes that testing on a ISLE dev environment will not involve rebuilding images.
If starting from scratch, simply download current existing ISLE images and only run using the Test Site Installation Guide and then follow those involved steps prior to advancing to step 2. If you already have a working
isle.localdomain
environment and are fine with testing, proceed to step 2.Clone the DG basic-solr-config repo or
git clone -b 4.10.x https://github.com/discoverygarden/basic-solr-config/tree/4.10.x
Copy the
foxmlToSolr.xslt
file to the ISLE project directory e.g.~/ISLE/fedora/gsearch
. This should replace the current one there. (only for the test don't build images with this!)Edit the
docker-compose.yml
. Under thefedora
volumes
section add a line that points to the newfoxmlToSolr.xslt
file e.g. -./fedora/gsearch/foxmlToSolr.xslt:/usr/local/tomcat//webapps/fedoragsearch/WEB-INF/classes/fgsconfigFinal/index/FgsIndex/foxmlToSolr.xslt
Run
docker-compose up -d
and attempt to view the Fedoragearch admin panel._Please note, you'll need the default
fgsAdmin
and password to login to the panel from the Test Site Resources page. See section2.Fedora container
for this. Additionally you'll need to visit http://hostip:8080/manager/html or http://isle.localdomain:8080/manager/html to log into tomcat, see same section above for theadmin
user information._What's the expected result?
What's the actual result?