An update: I've swapped out the tomcat bundle for a fresh install; added my dimension extensions to the core common dimensions schema; added the fields to base-other-dimensions.xml; rebuilt all layers; verified that the new fields exist in the dimensions_common table; and still get this error message when attempting to save a record containing the dimensions group (media) Create request failed: java.lang.IllegalStateException: Cannot set IS_REMOVED on removed or properties that are not map elements I've come across this wiki page<http://wiki.collectionspace.org/display/deploy/Errors+encountered+in+configuring+PAHMA+deployment#ErrorsencounteredinconfiguringPAHMAdeployment-Resolved:"Status:400:Createrequestfailed:java.lang.IllegalStateException:CannotsetIS_REMOVEDonremovedorpropertiesthatarenotmapelements"> but it doesn't impact me with v4.0 code. Any thoughts? - Jesse On Wed, Apr 16, 2014 at 6:46 PM, Jesse Martinez <mjesse@gmail.com> wrote: > Thanks for the suggestions, guys. I have been following the best practices > of running 'ant deploy_services_artifacts' from > services/JaxRsServiceProvider for all my extension development work. > > I compared the output from merged-base-other-dimension.xml_walkerart-other-dimension.xml-.xml > on both OS X and the Ubuntu AWS VM, and they are identical. > > I compared the media_common.xsd file found > in collectionspace.media.schema.media_common.jar and my added text > fields, valueConvertedInch and valueConvertedCM, are only found on OS X and > not on Linux. > > Sounds odd, no? > > - Jesse > > > On Wed, Apr 16, 2014 at 6:24 PM, Aron Roberts <aron@socrates.berkeley.edu>wrote: > >> Hi Jesse, >> >> Responding privately and cc'ing Ray, since you and he are already >> having this conversation publicly on the Work list. >> >> First, do what Ray suggested in his latest note. >> >> Second, if for some reason that doesn't get your dimensions >> extension recognized on the Linux system, and you wanted to look >> further into this discrepancy across platforms, two possible places to >> look - now that we know you're using v4.0 - are: >> >> 1. The relevant XMLMerge 'merged*' file in >> $CSPACE_JEESERVER_HOME/temp, if any, representing the merges of the >> Application layer config file containing your extension field(s) with >> its counterpart config file(s). (Are these the same on both the OS X >> and Linux systems?) >> >> 2. The Nuxeo schema and doctype JAR files for the relevant document >> types you're modifying, in >> $CSPACE_JEESERVER_HOME/nuxeo-server/plugins. (I haven't looked at App >> layer config, but could that be CollectionObject and Media, if they >> include that tenant-other-dimensions.xml file?) >> >> These JARs are built by App layer generation code, that's invoked >> via an Ant target in the Services build (!) - Ray's latest note >> describes what you invoke to build these. >> >> As he suggests, one again, if you haven't already done so, you can >> try running 'ant deploy_services_artifacts' from >> services/JaxRsServiceProvider in the Services build tree - this is >> really quick. I believe you'd also need to restart Tomcat to get >> Nuxeo to pick up any changes in the built JARs. >> >> Aron >> >> On Wed, Apr 16, 2014 at 2:55 PM, Jesse Martinez <mjesse@gmail.com> wrote: >> > Hi Ray, >> > >> > I'm coming across an interesting issue with attempting to extend the >> > dimensions subgroup. I can have the extension picked up, with >> modification >> > made to tenant-other-dimensions.xml, on my local dev instance on my >> Mac, but >> > I can't duplicate this on a linux VM. The Linux instance doesn't catch >> the >> > dimensions config change on startup, which means Nuxeo doesn't update >> its db >> > schema. I can't figure out what could make a difference since they are >> both >> > built from the same source repo. Nonetheless, should I just add any >> > extensions to the core schema in order to get around this limitation? >> > >> > Thanks, >> > >> > - Jesse >> > >> > >> > On Wed, Apr 16, 2014 at 3:33 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> >> >> >> Hi Jesse, >> >> I don't think we've done that. Some time ago we wanted to add a >> >> dimensionNote field, but we got that put into the common schema, since >> it's >> >> not possible to insert a field from an extension schema into the >> repeating >> >> group. >> >> >> >> Are you running into a problem? >> >> >> >> Ray >> >> >> >> >> >> >> >> On Mon, Apr 14, 2014 at 4:33 PM, Jesse Martinez <mjesse@gmail.com> >> wrote: >> >>> >> >>> Hi all, >> >>> >> >>> Anyone have experience extending the dimensions subgroup? >> >>> >> >>> Thanks, >> >>> >> >>> - Jesse >> >>> >> >>> _______________________________________________ >> >>> Work mailing list >> >>> Work@lists.collectionspace.org >> >>> >> >>> >> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org >> >>> >> >> >> > >> > >> > _______________________________________________ >> > Work mailing list >> > Work@lists.collectionspace.org >> > >> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org >> > >> > >

Hi Jesse, That error usually means that something in app layer configuration doesn't match the services layer configuration. It's become more rare to see in 4.0 since one is automatically generated from the other, but it's happened to me when I make an app layer change, and forget to recreate the services artifacts. I would make sure the deployed app layer config looks as expected, make sure the deployed merged tenant bindings config looks as expected, and make sure the deployed xsd (in nuxeo-server/schemas) looks as expected. If all those look good, check the payload being sent from the UI to the app, and from the app to the services, to make sure they look right. Ray On Mon, Apr 21, 2014 at 9:26 AM, Jesse Martinez <mjesse@gmail.com> wrote: > An update: I've swapped out the tomcat bundle for a fresh install; added > my dimension extensions to the core common dimensions schema; added the > fields to base-other-dimensions.xml; rebuilt all layers; verified that the > new fields exist in the dimensions_common table; and still get this error > message when attempting to save a record containing the dimensions group > (media) > > Create request failed: java.lang.IllegalStateException: Cannot set > IS_REMOVED on removed or properties that are not map elements > > I've come across this wiki page<http://wiki.collectionspace.org/display/deploy/Errors+encountered+in+configuring+PAHMA+deployment#ErrorsencounteredinconfiguringPAHMAdeployment-Resolved:%22Status:400:Createrequestfailed:java.lang.IllegalStateException:CannotsetIS_REMOVEDonremovedorpropertiesthatarenotmapelements%22> but > it doesn't impact me with v4.0 code. > > Any thoughts? > > - Jesse > > > On Wed, Apr 16, 2014 at 6:46 PM, Jesse Martinez <mjesse@gmail.com> wrote: > >> Thanks for the suggestions, guys. I have been following the best >> practices of running 'ant deploy_services_artifacts' from >> services/JaxRsServiceProvider for all my extension development work. >> >> I compared the output from merged-base-other-dimension.xml_walkerart-other-dimension.xml-.xml >> on both OS X and the Ubuntu AWS VM, and they are identical. >> >> I compared the media_common.xsd file found >> in collectionspace.media.schema.media_common.jar and my added text >> fields, valueConvertedInch and valueConvertedCM, are only found on OS X and >> not on Linux. >> >> Sounds odd, no? >> >> - Jesse >> >> >> On Wed, Apr 16, 2014 at 6:24 PM, Aron Roberts <aron@socrates.berkeley.edu >> > wrote: >> >>> Hi Jesse, >>> >>> Responding privately and cc'ing Ray, since you and he are already >>> having this conversation publicly on the Work list. >>> >>> First, do what Ray suggested in his latest note. >>> >>> Second, if for some reason that doesn't get your dimensions >>> extension recognized on the Linux system, and you wanted to look >>> further into this discrepancy across platforms, two possible places to >>> look - now that we know you're using v4.0 - are: >>> >>> 1. The relevant XMLMerge 'merged*' file in >>> $CSPACE_JEESERVER_HOME/temp, if any, representing the merges of the >>> Application layer config file containing your extension field(s) with >>> its counterpart config file(s). (Are these the same on both the OS X >>> and Linux systems?) >>> >>> 2. The Nuxeo schema and doctype JAR files for the relevant document >>> types you're modifying, in >>> $CSPACE_JEESERVER_HOME/nuxeo-server/plugins. (I haven't looked at App >>> layer config, but could that be CollectionObject and Media, if they >>> include that tenant-other-dimensions.xml file?) >>> >>> These JARs are built by App layer generation code, that's invoked >>> via an Ant target in the Services build (!) - Ray's latest note >>> describes what you invoke to build these. >>> >>> As he suggests, one again, if you haven't already done so, you can >>> try running 'ant deploy_services_artifacts' from >>> services/JaxRsServiceProvider in the Services build tree - this is >>> really quick. I believe you'd also need to restart Tomcat to get >>> Nuxeo to pick up any changes in the built JARs. >>> >>> Aron >>> >>> On Wed, Apr 16, 2014 at 2:55 PM, Jesse Martinez <mjesse@gmail.com> >>> wrote: >>> > Hi Ray, >>> > >>> > I'm coming across an interesting issue with attempting to extend the >>> > dimensions subgroup. I can have the extension picked up, with >>> modification >>> > made to tenant-other-dimensions.xml, on my local dev instance on my >>> Mac, but >>> > I can't duplicate this on a linux VM. The Linux instance doesn't catch >>> the >>> > dimensions config change on startup, which means Nuxeo doesn't update >>> its db >>> > schema. I can't figure out what could make a difference since they are >>> both >>> > built from the same source repo. Nonetheless, should I just add any >>> > extensions to the core schema in order to get around this limitation? >>> > >>> > Thanks, >>> > >>> > - Jesse >>> > >>> > >>> > On Wed, Apr 16, 2014 at 3:33 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>> >> >>> >> Hi Jesse, >>> >> I don't think we've done that. Some time ago we wanted to add a >>> >> dimensionNote field, but we got that put into the common schema, >>> since it's >>> >> not possible to insert a field from an extension schema into the >>> repeating >>> >> group. >>> >> >>> >> Are you running into a problem? >>> >> >>> >> Ray >>> >> >>> >> >>> >> >>> >> On Mon, Apr 14, 2014 at 4:33 PM, Jesse Martinez <mjesse@gmail.com> >>> wrote: >>> >>> >>> >>> Hi all, >>> >>> >>> >>> Anyone have experience extending the dimensions subgroup? >>> >>> >>> >>> Thanks, >>> >>> >>> >>> - Jesse >>> >>> >>> >>> _______________________________________________ >>> >>> Work mailing list >>> >>> Work@lists.collectionspace.org >>> >>> >>> >>> >>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org >>> >>> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > Work mailing list >>> > Work@lists.collectionspace.org >>> > >>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org >>> > >>> >> >> >

I ran into a problem extending Contacts, where the schema was generated correctly, but tenant bindings were not. It looks like Dimension might have the same problem. See CSPACE-6185<http://issues.collectionspace.org/browse/CSPACE-6185> . Ray On Mon, Apr 21, 2014 at 11:59 AM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Jesse, > That error usually means that something in app layer configuration doesn't > match the services layer configuration. It's become more rare to see in 4.0 > since one is automatically generated from the other, but it's happened to > me when I make an app layer change, and forget to recreate the services > artifacts. I would make sure the deployed app layer config looks as > expected, make sure the deployed merged tenant bindings config looks as > expected, and make sure the deployed xsd (in nuxeo-server/schemas) looks as > expected. If all those look good, check the payload being sent from the UI > to the app, and from the app to the services, to make sure they look right. > > Ray > > > > On Mon, Apr 21, 2014 at 9:26 AM, Jesse Martinez <mjesse@gmail.com> wrote: > >> An update: I've swapped out the tomcat bundle for a fresh install; added >> my dimension extensions to the core common dimensions schema; added the >> fields to base-other-dimensions.xml; rebuilt all layers; verified that the >> new fields exist in the dimensions_common table; and still get this error >> message when attempting to save a record containing the dimensions group >> (media) >> >> Create request failed: java.lang.IllegalStateException: Cannot set >> IS_REMOVED on removed or properties that are not map elements >> >> I've come across this wiki page<http://wiki.collectionspace.org/display/deploy/Errors+encountered+in+configuring+PAHMA+deployment#ErrorsencounteredinconfiguringPAHMAdeployment-Resolved:%22Status:400:Createrequestfailed:java.lang.IllegalStateException:CannotsetIS_REMOVEDonremovedorpropertiesthatarenotmapelements%22> but >> it doesn't impact me with v4.0 code. >> >> Any thoughts? >> >> - Jesse >> >> >> On Wed, Apr 16, 2014 at 6:46 PM, Jesse Martinez <mjesse@gmail.com> wrote: >> >>> Thanks for the suggestions, guys. I have been following the best >>> practices of running 'ant deploy_services_artifacts' from >>> services/JaxRsServiceProvider for all my extension development work. >>> >>> I compared the output from merged-base-other-dimension.xml_walkerart-other-dimension.xml-.xml >>> on both OS X and the Ubuntu AWS VM, and they are identical. >>> >>> I compared the media_common.xsd file found >>> in collectionspace.media.schema.media_common.jar and my added text >>> fields, valueConvertedInch and valueConvertedCM, are only found on OS X and >>> not on Linux. >>> >>> Sounds odd, no? >>> >>> - Jesse >>> >>> >>> On Wed, Apr 16, 2014 at 6:24 PM, Aron Roberts < >>> aron@socrates.berkeley.edu> wrote: >>> >>>> Hi Jesse, >>>> >>>> Responding privately and cc'ing Ray, since you and he are already >>>> having this conversation publicly on the Work list. >>>> >>>> First, do what Ray suggested in his latest note. >>>> >>>> Second, if for some reason that doesn't get your dimensions >>>> extension recognized on the Linux system, and you wanted to look >>>> further into this discrepancy across platforms, two possible places to >>>> look - now that we know you're using v4.0 - are: >>>> >>>> 1. The relevant XMLMerge 'merged*' file in >>>> $CSPACE_JEESERVER_HOME/temp, if any, representing the merges of the >>>> Application layer config file containing your extension field(s) with >>>> its counterpart config file(s). (Are these the same on both the OS X >>>> and Linux systems?) >>>> >>>> 2. The Nuxeo schema and doctype JAR files for the relevant document >>>> types you're modifying, in >>>> $CSPACE_JEESERVER_HOME/nuxeo-server/plugins. (I haven't looked at App >>>> layer config, but could that be CollectionObject and Media, if they >>>> include that tenant-other-dimensions.xml file?) >>>> >>>> These JARs are built by App layer generation code, that's invoked >>>> via an Ant target in the Services build (!) - Ray's latest note >>>> describes what you invoke to build these. >>>> >>>> As he suggests, one again, if you haven't already done so, you can >>>> try running 'ant deploy_services_artifacts' from >>>> services/JaxRsServiceProvider in the Services build tree - this is >>>> really quick. I believe you'd also need to restart Tomcat to get >>>> Nuxeo to pick up any changes in the built JARs. >>>> >>>> Aron >>>> >>>> On Wed, Apr 16, 2014 at 2:55 PM, Jesse Martinez <mjesse@gmail.com> >>>> wrote: >>>> > Hi Ray, >>>> > >>>> > I'm coming across an interesting issue with attempting to extend the >>>> > dimensions subgroup. I can have the extension picked up, with >>>> modification >>>> > made to tenant-other-dimensions.xml, on my local dev instance on my >>>> Mac, but >>>> > I can't duplicate this on a linux VM. The Linux instance doesn't >>>> catch the >>>> > dimensions config change on startup, which means Nuxeo doesn't update >>>> its db >>>> > schema. I can't figure out what could make a difference since they >>>> are both >>>> > built from the same source repo. Nonetheless, should I just add any >>>> > extensions to the core schema in order to get around this limitation? >>>> > >>>> > Thanks, >>>> > >>>> > - Jesse >>>> > >>>> > >>>> > On Wed, Apr 16, 2014 at 3:33 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>>> >> >>>> >> Hi Jesse, >>>> >> I don't think we've done that. Some time ago we wanted to add a >>>> >> dimensionNote field, but we got that put into the common schema, >>>> since it's >>>> >> not possible to insert a field from an extension schema into the >>>> repeating >>>> >> group. >>>> >> >>>> >> Are you running into a problem? >>>> >> >>>> >> Ray >>>> >> >>>> >> >>>> >> >>>> >> On Mon, Apr 14, 2014 at 4:33 PM, Jesse Martinez <mjesse@gmail.com> >>>> wrote: >>>> >>> >>>> >>> Hi all, >>>> >>> >>>> >>> Anyone have experience extending the dimensions subgroup? >>>> >>> >>>> >>> Thanks, >>>> >>> >>>> >>> - Jesse >>>> >>> >>>> >>> _______________________________________________ >>>> >>> Work mailing list >>>> >>> Work@lists.collectionspace.org >>>> >>> >>>> >>> >>>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org >>>> >>> >>>> >> >>>> > >>>> > >>>> > _______________________________________________ >>>> > Work mailing list >>>> > Work@lists.collectionspace.org >>>> > >>>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org >>>> > >>>> >>> >>> >> >