Errors encountered in configuring PAHMA deployment

Owned by Michael T. Black
Last updated: Oct 06, 2011Version comment

Important note: The following are notes made by a new deployer trying to learn how not to break things in CollectionSpace. When I offer a "solution" or state that the cause of an error is unknown, I am speaking strictly from my own perspective; while the CSpace team often provides helpful advice towards solving these problems, the following notes and pointers should not be construed to be those of the CSpace development team. These are simply notes I write as I try to find my way through problems I encounter. Feel free to add to or edit this page.

Helpful link: Guidelines for Bug Triage

UNRESOLVED: "Status:400:Service layer exceptionBad request during identifier cache map update: status not 200400" in nagpraclaim


Status: unresolved.
Scope: unknown; at least nagpraclaim.
Cause: I searched for all nagpraclaims by using the top right quick search, selecting "NAGPRA claims," and leaving the search box empty.
Solution: unknown

Resolved: "Status:0:Service layer exceptionUsername may not be null" in nagpraclaim


Status: Resolved.
Scope: unknown; at least nagpraclaim.
Cause: I created a new nagpraclaim record with only Claim Number (common, required), and it saved and displayed "New Record successfully created".  I added a value to Claim Name (domain/anthropology), and when I attempted to save the record, I got a "Status:400:Bad response" error (another error, not the current error).  If I deleted the entered Claim Name, I still couldn't save without this "Status:400:Bad response" error.  I clicked "Cancel changes," which rolled back to having just Claim Number entered.  I hit save and got the current error.  If I entered anything in Claim Name again and tried to save, I got this current error, not the other error as I did before.  When I clicked on "Create New," I was redirected to the login screen, so perhaps this was just due to my having been logged out after a period of inactivity.
Solution: Be sure you haven't been logged out after a period of inactivity.

UNRESOLVED: "Status:400:Bad response" in nagpraclaim


Status: unresolved.
Scope: only seen in nagpraclaim.
Cause: I created a new nagpraclaim record with only Claim Number (common, required), and it saved and displayed "New Record successfully created" (the server trace did indicate a NullPointerException, but this may have been related to other new fields I added).  I added a value to Claim Type (domain/anthropology), and when I attempted to save the record, I got this error.  If I set Claim Type back to "(none selected)" and tried to save again, the error persisted.  If I created a new record again with only Claim Number, there was no problem, as before.

After examining the PUT source generated during this error, as revealed by Firebug, I saw that three groups/lists didn't have all their fields included.  I examined the code for these. The first, nagpraClaimNoteList, a repeating note field, had code identical to another (working) repeating notes field (comments in collectionobject). The second, sentToOversightCommitteeGroup, had code identical to another (working) group in nagpraclaim.  This second group was, however, inadvertently duplicated in the nagpraclaims_anthropology.xsd schema (it should only be in the nagpraclaims_pahma.xsd schema).  Removing it did not resolve the error.  The third field, recommendationOfOversightCommitteeGroup, also had code identical to another (working) group in nagpraclaim.

Aron pointed me to the collectionspace.log, which contained the following line:

2011-10-06 11:42:42,463 DEBUG \[org.collectionspace.services.common.document.DocumentUtils\] Invalid input document. No such property was found nagpraClaimNoteList in schema nagpraclaims_common

This indicates to me that I hadn't properly pointed the field to the proper schema in our-tenant-tenant.xml.  And indeed, this is what I found in our-tenant-tenant.xml:

    <repeat id="nagpraClaimNoteList">
        <field id="nagpraClaimNote"></field>
    </repeat>

I changed this to the following and am redeploying and rebuilding to see if this resolves the error:

    <repeat id="nagpraClaimNoteList" section="anthropology">
        <field id="nagpraClaimNote" section="anthropology"></field>
    </repeat>

The above did not fix the error.
Solution: unknown.

Resolved: Variants of "Status:400:Create request failed: javax.ejb.EJBException: java.lang.NullPointerException"

As I understand it, the NullPointerException error indicates that something (e.g., name) is wrong with a (field) name somewhere in a schema, resulting in it not being found when it is needed.  What follows is a selection of some of the different causes of this annoyingly vague error message.

Resolved: "Status:400:Create request failed: javax.ejb.EJBException: java.lang.NullPointerException" in nagpraclaim

Status: Resolved.
Scope: This specific incident involved nagpraclaim only, but potentially any service with schema extensions could be affected.

Cause: I made an incomplete change to code during debugging.  A field in nagpraclaims_anthropology.xsd (nagpraClaimNoteList — a repeating note field) was defined with this code:

    <xs:element name="nagpraClaimNoteList" type="nagpraClaimNoteList"/>

    <xs:complexType name="nagpraClaimNoteList">
        <xs:sequence>
            <xs:element name="nagpraClaimNote" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>

A similar (working) field in collectionobject had this code in collectionobjects_common.xsd:

    <xs:element name="comments">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="comment" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

I revised this to the following and redeployed in an attempt to fix another error, but inadvertently left the initial line untouched:

    <xs:element name="nagpraClaimNoteList" type="nagpraClaimNoteList"/>

    <xs:element name="nagpraClaimNoteList">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="nagpraClaimNote" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

Having both <xs:element name lines in triggered the java.lang.NullPointerException error.

Solution: Revise the element definition to be only:

    <xs:element name="nagpraClaimNoteList">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="nagpraClaimNote" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

which works, but which Aron tells me is deprecated, or the newer, apparently better "venetian blind" format:

    <xs:element name="nagpraClaimNoteList" type="nagpraClaimNoteList"/>

    <xs:complexType name="nagpraClaimNoteList">
        <xs:sequence>
            <xs:element name="nagpraClaimNote" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>

Resolved: "Status:400:Create request failed: javax.ejb.EJBException: java.lang.NullPointerException" in collectionobject


I have this error in two different sets of circumstances, one resolved, one unresolved.  The resolved version is detailed here.  The unresolved version has its own entry, below.
Status: Resolved, but may reoccur whenever new custom fields are added to a deployment.
Scope: This appears to affect only collectionobject. Other types of records and authorities save without experiencing this problem.
Notes taken during debugging: http://wiki.collectionspace.org/x/QQDEB

Cause: I had added a repeating group of fields for Alternate Numbers (to replace Other Number, which had no Note field). As a shortcut, I cloned the .xsd schema code for otherNumbers and placed it in the PAHMA local schema extension, and edited it to suit pahmaAltNumGroupList. Unlike all but two other repeating groups of fields in the collectionobjects_common.xsd schema, otherNumbers had a type of "type=ns:otherNumbers". I mistakenly changed this to type="xs:pahmaAltNumGroupList".
Solution: Change type="xs:pahmaAltNumGroupList" to type="pahmaAltNumGroupList" (the pahmaAltNumGroupList complexType is defined later in the schema).

Resolved: "Status:400:Create request failed: javax.ejb.EJBException: java.lang.NullPointerException" in nagpraclaim


Status: Resolved.
Scope: This specific incident involved nagpraclaim only, but potentially any service with schema extensions could be affected.
Notes taken during debugging: http://wiki.collectionspace.org/x/AwD2B

Cause: The extension schemas were not referenced in the pom.xml <modules> declaration.  The NullPointerException error indicates that something (e.g., name) is wrong with a (field) name somewhere, resulting in it not being found when it is needed, as I understand it.  I knew nothing was wrong with the field names in the three schemas, as all worked like a charm when all fields were dumped into the common schema.  Somehow the domain and local extension fields were not making it into the merged schema.  In checking the pom.xml file in the directory enclosing all three schemas (nagpraclaim/3rdparty/), I saw that only the common schema was included:

 <modules>
       <module>nuxeo-platform-cs-nagpraclaim</module>
 </modules>

Solution: Change the <modules> declaration in the appropriate pom.xml (nagpraclaim/3rdparty/pom.xml) to the following:

 <modules>
       <module>nuxeo-platform-cs-nagpraclaim</module>
       <module>nuxeo-platform-cs-nagpraclaim-pahma</module>
       <module>nuxeo-platform-nagpraclaim-anthropology</module>
 </modules>

Resolved: "Status:400:Create request failed: java.lang.IllegalStateException: Cannot set IS_REMOVED on removed or properties that are not map elements"


Status: Resolved, but may reoccur whenever new custom fields are added to a deployment.
Summary: When attempting to save a record, the save fails and this message is displayed
Cause: Multiple:

  1. Mismatch between selector names in service layer (schemas, e.g. collectionobjects_pahma.xsd) and those in application layer (e.g., our-tenant-tenant.xml).
  2. Failure to run Ant deploy on services after adding new fields to schema

Solution: Multiple:

  1. Make sure selectors match across layers. This is made easier if the selectors are named according to convention.
  2. Run "mci;ant undeploy deploy create_db import" at root of services (is import necessary? can this be run just on the specific service that was altered?)

Resolved: "Status:400:Create request failed: org.nuxeo.ecm.core.api.ClientException: LoanIn is not a registered core type"


Status: Resolved
Summary: When trying to save a Loan In record, this error occurred
Cause: When cloning a new service from loanin, the Manifest.mf file in the new service was inadvertently left unrevised, and thus still pointed to loanin:

Manifest-Version: 1.0
Bundle-ManifestVersion: 1
Bundle-Name: NuxeoCS
Bundle-SymbolicName: org.collectionspace.loanin;singleton:=true
Bundle-Version: 1.0.0
Bundle-Localization: plugin
Bundle-Vendor: Nuxeo
Require-Bundle: org.nuxeo.runtime,
 org.nuxeo.ecm.core.api,
 org.nuxeo.ecm.core,
 org.nuxeo.ecm.core.api,
 org.nuxeo.ecm.platform.types.api,
 org.nuxeo.ecm.platform.versioning.api,
 org.nuxeo.ecm.platform.ui,
 org.nuxeo.ecm.platform.forms.layout.client,
 org.nuxeo.ecm.platform.ws,
 org.collectionspace.collectionspace_core
Provide-Package: org.collectionspace.loanin
Nuxeo-Component: OSGI-INF/core-types-contrib.xml,
 OSGI-INF/life-cycle-contrib.xml,
 OSGI-INF/ecm-types-contrib.xml,
 OSGI-INF/layouts-contrib.xml

Solution: Change the two incidences of "loanin" to the name of the new service.

UNRESOLVED (minor): "[Message string for key conditioncheckreason not found]"

Status: unresolved
Summary: This string "[Message string for key conditioncheckreason not found]" appears the first time a page is accessed after I rebuild the app and ui layers.  On subsequent page loads, the proper name of the record type appears.
Cause: unknown
Solution:

Resolved: "Invalid email/password combination"

Status: Resolved but reoccurs not infrequently
Summary: Correct email and password are entered, but user remains on login page and this message is displayed.
Cause: Multiple:

  1. Incorrect email and/or password were entered.
  2. Nuxeo server is not running.
  3. Nuxeo server is running, but isn't getting the correct Nuxeo password from the CSpace server.

Solution: Depends on cause:

  1. Verify that the credentials entered are the correct credentials for the deployment (regardless of what may be stated in the text on the login page). You're not entering "o" instead of "0" again, are you? When will you learn?
  2. Shut down the CSpace server (brutal:control-C; elegant: $JBOSS_HOME/bin/shutdown.sh -s 0.0.0.0:1199 -S), restart the Nuxeo server ($JBOSS_HOME/bin/nuxeoctl), then restart the CSpace server ($JBOSS_HOME/bin/run.sh -c cspace -b 0.0.0.0).
  3. Make sure that the username and password in service-config.xml ($JBOSS_HOME/server/cspace/cspace/config/services) are what Nuxeo is expecting. Check to make sure that the Nuxeo admin credentials given in service-config.xml allow you to login to the Nuxeo admin console. NB: The default Nuxeo admin account is Administrator/Administrator. This is acceptable in a local development environment, but should be changed for any real deployment.

    UNRESOLVED (minor): Non-standard characters sometimes replaced upon record save

   

Status: unresolved
Summary:
Cause:
Solution:

UNRESOLVED (minor): Term picker narrower than enclosing table cell

  

Status: unresolved
Summary:
Cause:
Solution:

Resolved: Labels for fields are not visible

Status: Resolved (mostly)
Summary:
Cause:
Solution:

Resolved: Term list has only one option: "Options not loaded"

Status: Partially resolved
Summary:
Cause:
Solution:

UNRESOLVED (minor): Terms used by custom fields do not show up under the RH Terms Used section

Status: unresolved
Summary:
Cause:
Solution:

Workaround found: "We've encountered an error retrieving search results. Please try again: URL:nagpraclaims?kw=&pgSz=10&wf_deleted=false: STATUS:400:Service layer exceptionBad request during identifier cache map update: status not 200400"

?

Status: unresolved, workaround found
Summary: When I try to do a wildcard search for nagpra claim records, I get this error.
Background: I split the common schema elements into common, anthropology, and pahma and assembled the three schemas.  I could not get the common-domain-local schema trio to play nice (even though I specified that a field was defined in a non-common schema: <field id="nagpraClaimName" section="anthropology" in-title="yes"></field>, CollectionSpace was still looking for {nagpraclaims_common:nagpraClaimName}), so I reversed my changes to our-tenant-tenant.xml (removed the section="anthropology" and section="pahma" attributes for non-common-schema fields).  I did not, however, re-consolidate the elements in the common schema.
Cause: CSpace was looking for a field in the common schema and did not find it defined there.
Solution: Multiple:

  1. Good: Fix the problem (presumably a binding problem) that is causing CSpace to look for all nagpraclaims fields in nagpraclaims.
  2. Bad: Leave all the fields in common until I figure out the solution to #1.

Resolved (by Glen): "We've encountered an error retrieving search results. Please try again: URL:collectionobjects?kw=&pgSz=10&wf_deleted=false: STATUS:400:Service layer exceptionBad request during identifier cache map update: status not 200400"

Status: Resolved (by Glen)
Summary: When I try to do a wildcard search for cataloging records on the pahmacspace.berkeley.edu instance, I get this error.
Cause: unknown
Solution: unknown

Resolved (by Glen): "Could not retrieve relation, missing relations_common"

Status: Resolved (by Glen)
Summary: When I try to save any record type on the pahmacspace.berkeley.edu instance, I get this error.
Cause: unknown
Solution: unknown

Resolved (by Glen): "Error creating Record: error"

Status: Resolved (by Glen)
Summary: When I try to save a new Taxon authority term, I get this error.
Cause: unknown
Solution: unknown

Resolved: "Error saving Record: error"

Status: Resolved
Summary: Error occurs when trying to save a new record after session has expired.
Cause: Expired session (user was automatically logged out of CSpace after period of inactivity).
Solution: Save data before stepping away from the computer for an extended period.  If data was unsaved (or you don't know if data was saved) and you don't know if your CollectionSpace session has expired, open a new browser window and navigate to CollectionSpace.  Login if necessary, then return to original window and save your data.

Resolved: Uneven spacing between collapsed sub-sections

Status: Resolved
Summary: I created a new sub-section and saw this irregularity.
Cause: Removal of seemingly unnecessary clear divs ("<div class="clear"></div>")
Solution: When cloning a sub-section, don't remove the final two clear divs. One is placed immediately after the information-subgroup div:

<div class="fl-container-flex fl-fix information-subgroup">
. . .
</div>
<div class="clear"></div>

And the other is placed immediately after the immediate parent div of the togglable header:

<div class="info-column fl-force-left">
. . .
</div>
<div class="clear"></div>

Resolved: A collapsed/open indicator (triangle) displays in content when ?[sub-]section is collapsed by default

 

Status: Resolved
Summary: When I set a sub-section to be collapsed/folded/closed by default, I saw this irregularity when I later opened the sub-section.
Cause: An extraneous selector in the div immediately below the [sub-]section heading div (the section content div)
Solution: Remove the extraneous "cs-togglable-collapsed" selector. The flawed code read:

     <div class="csc-recordEditor-header fl-container-flex header toggle csc-collection-object-textualInscriptionInformation-label cs-togglable-header cs-togglable-collapsed"></div>
     <div class="csc-recordEditor-togglable cs-togglable-collapsed fl-container-flex fl-fix content main" style="display:none;">

The corrected code reads:

     <div class="csc-recordEditor-header fl-container-flex header toggle csc-collection-object-textualInscriptionInformation-label cs-togglable-header cs-togglable-collapsed"></div>
     <div class="csc-recordEditor-togglable fl-container-flex fl-fix content main" style="display:none;">

UNRESOLVED (minor): Repeating field/group decorators are in wrong place when a default closed section is opened

Status: unresolved
Summary: When I set a sub-section to be collapsed/folded/closed by default, I saw this irregularity when I later opened the sub-section.
Cause: unknown
Solution: unknown

Resolved: Repeating field/group decorators are in wrong place after I tweaked the size of a field in the Template.html file

Status: Resolved
Summary: When I adjusted the size of a repeating field in CatalogingTemplate.html, the "+" (add repeat) is shoved to the left of the field's div, and the "x" (delete repeat) spills onto a new line.
Cause: There isn't enough room for both the field and the decorators inside the container.
Solution: Set the size of the field to be narrower than that of the container:

  <div class="info-column2-20 fl-force-left">
      <div class="info-pair-select">
	  <div class="header">
	      <div class="label csc-collection-object-forms-label"></div>
	  </div>
	  <div class="content">
	      <select class="csc-object-description-form input-select fixedwidth80"><option value="">Options not loaded</option></select>
	  </div>
      </div>
  </div>

The "fixedwidth80" is a custom selector that sets the field to be 80% of the width of the container.  80% seems to be the sweet spot; 90% still doesn't leave enough room, and 70% leaves too much room.