Problems with the ESRI OpenSearch end point example for GeoPortal

1780
2
Jump to solution
07-22-2014 10:42 AM
LukeLambert
New Contributor II

I'm attempting to follow the ESRI example (found here) of adding an OpenSearch end point to GeoPortal.  I believe I've followed all of the steps faithfully, but when I use GeoPortal to search only the new NSIDC source I get the message:

Unable to load /geoportal/rest/find/document?rid=nsidc&ridName=National%20Snow%20and%20Ice%20Data%20Center&rids=nsidc&searchText=water&start=1&max=10&maxSearchTimeMilliSec=10000&f=searchpageresults&dojo.preventCache=1406049254363 status:500/geoportal/rest/find/document?rid=nsidc&ridName=National%20Snow%20and%20Ice%20Data%20Center&rids=nsidc&searchText=water&start=1&max=10&maxSearchTimeMilliSec=10000&f=searchpageresults

Clicking on the link I get the same error from Tomcat:

HTTP Status 500 - Error while getting items from repository with id of nsidcCould not get record from db with rid = nsidc

type: Status report

message: Error while getting items from repository with id of nsidcCould not get record from db with rid = nsidc

description: The server encountered an internal error that prevented it from fulfilling this request.

Apache Tomcat/6.0.41

Watching the the gpt log, I see the following stack trace when I search for "water"

Jul 22, 2014 1:17:07 PM com.esri.gpt.catalog.search.SearchFilterKeyword setSearchText

FINE: search text value posted

Jul 22, 2014 1:17:07 PM com.esri.gpt.catalog.search.SearchFilterKeyword setSearchText

FINE: search text value posted water

Jul 22, 2014 1:17:07 PM com.esri.gpt.catalog.search.GptRepository readHarvestRecords

INFO: DB Query SELECT PROTOCOL_TYPE, HOST_URL, PROTOCOL, TITLE, DOCUUID, ID FROM GPT_RESOURCE WHERE UPPER(TITLE)= ? AND ((APPROVALSTATUS = 'approved') OR (APPROVALSTATUS = 'reviewed')) AND SEARCHABLE = 'true'

Jul 22, 2014 1:17:07 PM com.esri.gpt.framework.sql.DatabaseReference openConnection

FINE: Connection opened for gpt, jndiName: jdbc/gpt, productName: PostgreSQL, driver: PostgreSQL Native Driver PostgreSQL 9.1 JDBC4 (build 901)

Jul 22, 2014 1:17:07 PM com.esri.gpt.control.georss.RestQueryServlet execute

SEVERE: Error executing query.

com.esri.gpt.catalog.search.SearchException: Error while getting items from repository  with id of nsidcCould not get record from db with rid = nsidc

        at com.esri.gpt.catalog.search.SearchEngineExternalCsw.init(Unknown Source)

        at com.esri.gpt.catalog.search.SearchEngineExternalCsw.init(Unknown Source)

        at com.esri.gpt.catalog.search.SearchEngineFactory.intializeEngine(Unknown Source)

        at com.esri.gpt.catalog.search.SearchEngineFactory.createSearchEngine(Unknown Source)

        at com.esri.gpt.catalog.search.SearchEngineFactory.createSearchEngine(Unknown Source)

        at com.esri.gpt.control.georss.RestQueryServlet.executeQuery1(Unknown Source)

        at com.esri.gpt.control.georss.RestQueryServlet.execute(Unknown Source)

        at com.esri.gpt.framework.context.BaseServlet.doPost(Unknown Source)

        at com.esri.gpt.framework.context.BaseServlet.doGet(Unknown Source)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)

        at javax.servlet.http.HttpServlet.service(HttpServlet.java:723)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)

        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)

        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:861)

        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:606)

        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)

        at java.lang.Thread.run(Thread.java:701)

Caused by: com.esri.gpt.catalog.search.SearchException: Could not get record from db with rid = nsidc

        at com.esri.gpt.catalog.search.GptRepository.readHarvestRecord(Unknown Source)

        ... 23 more

Jul 22, 2014 1:17:07 PM com.esri.gpt.framework.sql.DatabaseReference closeConnection

FINE: Closing connection for gpt, jndiName: jdbc/gpt

There are no other errors reported by either GPT or Tomcat.  Any help would be appreciated.

0 Kudos
1 Solution

Accepted Solutions
LukeLambert
New Contributor II

The NSIDC_GetRecords_Response.xslt error was a red herring.  Once I cleared that up, everything worked as advertised.  The main takeaway is not to list a new repository after another repository that might have a (regex) matching key.

View solution in original post

0 Kudos
2 Replies
LukeLambert
New Contributor II

One step further down the rabbit hole:

In the repository listings in gpt.xml, repositories are regex-matched by key name in the order they are listed.  Before any user additions, the last repository listed in gpt.xml has a key of '*', which will match anything.  Any other repository listed after that won't be considered.  There's no warning that a search request can match more than one key, that repository order matters, or that it's first key match rather than best key match.  See the 'getAttributes' method of SearchEngineFactory for the offending behavior.

With that hurdle overcome, I'm not getting an exception about not being able to parse the getRecordsResponse of the supplied NSIDC_GetRecords_Response.xslt.

0 Kudos
LukeLambert
New Contributor II

The NSIDC_GetRecords_Response.xslt error was a red herring.  Once I cleared that up, everything worked as advertised.  The main takeaway is not to list a new repository after another repository that might have a (regex) matching key.

0 Kudos