Hi Everyone, I'm picking up this old thread (and moving it from Work to Talk), since I've recently tried to extend dimensions, as Jesse was trying to do when he started it. Here's what I've found: 1. The dimensions schema is not currently being generated from app layer config. This can be fixed by adding some missing tags and attributes to base-other-dimension.xml. See CSPACE-6397 for details. 2. The services tenant bindings for dimensions are also not being generated from app layer config. This can be worked around by hand writing the necessary tenant bindings for your extension, as we used to do pre-4.0. See CSPACE-6398 for details. 3. After fixing 1 and 2, it's possible to configure a schema extension on dimensions. However, the services layer doesn't quite do the right thing when retrieving records that contain dimensions, when schema extensions on dimensions exist. See CSPACE-6399 for details. Because of 3, I gave up on making a schema extension, and like Jesse, decided to hack the common dimension schema, to add the necessary fields. So in one branch of our code, the dimensions_common schema differs from the dimensions_common schema in other branches. This is dangerous, but the best solution I could come up with. Thanks, Ray On Thu, May 1, 2014 at 12:01 PM, Jesse Martinez <mjesse@gmail.com> wrote: > An update: So, I worked around this issue by attaching my schema extension > fields to the core common schema for dimensions. It's not the best approach > for a number of reasons. :-/ > > - Jesse > > > On Mon, Apr 21, 2014 at 3:07 PM, Ray Lee <rhlee@berkeley.edu> wrote: > >> 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 >>>>>> > >>>>>> >>>>> >>>>> >>>> >>> >> >

1. The dimensions schema is not currently being generated from app
layer config. This can be fixed by adding some missing tags and attributes
to base-other-dimension.xml. See CSPACE-6397 for details.
2. The services tenant bindings for dimensions are also not being
generated from app layer config. This can be worked around by hand writing
the necessary tenant bindings for your extension, as we used to do pre-4.0.
See CSPACE-6398 for details.
3. After fixing 1 and 2, it's possible to configure a schema extension
on dimensions. However, the services layer doesn't quite do the right thing
when retrieving records that contain dimensions, when schema extensions on
dimensions exist. See CSPACE-6399 for details.

Thanks, Ray. This is very useful to know and reminds me of the trouble I went through attempting to extend Dimensions too. And another peculiarity, which may or may not be related to this topic: The dimension field (within the dimensionSubGroup repeatable group) can't be converted to use a dynamic term list, at least in v4.0. The other static term lists in the dimensions group can be converted to use dynamic lists, but just not the dimension field. I'd be interested if anyone else has done something like this before. Thanks, Jesse On Tue, Jul 15, 2014 at 1:28 AM, Ray Lee <rhlee@berkeley.edu> wrote: > Hi Everyone, > I'm picking up this old thread (and moving it from Work to Talk), since > I've recently tried to extend dimensions, as Jesse was trying to do when he > started it. Here's what I've found: > > 1. The dimensions schema is not currently being generated from app > layer config. This can be fixed by adding some missing tags and attributes > to base-other-dimension.xml. See CSPACE-6397 for details. > 2. The services tenant bindings for dimensions are also not being > generated from app layer config. This can be worked around by hand writing > the necessary tenant bindings for your extension, as we used to do pre-4.0. > See CSPACE-6398 for details. > 3. After fixing 1 and 2, it's possible to configure a schema extension > on dimensions. However, the services layer doesn't quite do the right thing > when retrieving records that contain dimensions, when schema extensions on > dimensions exist. See CSPACE-6399 for details. > > Because of 3, I gave up on making a schema extension, and like Jesse, > decided to hack the common dimension schema, to add the necessary fields. > So in one branch of our code, the dimensions_common schema differs from the > dimensions_common schema in other branches. This is dangerous, but the best > solution I could come up with. > > Thanks, > Ray > > > On Thu, May 1, 2014 at 12:01 PM, Jesse Martinez <mjesse@gmail.com> wrote: > >> An update: So, I worked around this issue by attaching my schema >> extension fields to the core common schema for dimensions. It's not the >> best approach for a number of reasons. :-/ >> >> - Jesse >> >> >> On Mon, Apr 21, 2014 at 3:07 PM, Ray Lee <rhlee@berkeley.edu> wrote: >> >>> 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 >>>>>>> > >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >

1. The dimensions schema is not currently being generated from app
layer config. This can be fixed by adding some missing tags and attributes
to base-other-dimension.xml. See CSPACE-6397 for details.
2. The services tenant bindings for dimensions are also not being
generated from app layer config. This can be worked around by hand writing
the necessary tenant bindings for your extension, as we used to do pre-4.0.
See CSPACE-6398 for details.
3. After fixing 1 and 2, it's possible to configure a schema
extension on dimensions. However, the services layer doesn't quite do the
right thing when retrieving records that contain dimensions, when schema
extensions on dimensions exist. See CSPACE-6399 for details.

A belated response to an early August post by Jesse, below ... It's possible that Ray might have resolved this issue - which prevented adding dynamic (database-stored) term lists to extensions to Contacts and Dimensions - with his bugfix here: https://issues.collectionspace.org/browse/BAMPFA-37 Adding this fix to CollectionSpace's 'core' code is now being considered for part of the work during the remaining two weeks of development on release 4.1. Aron On Wed, Aug 6, 2014 at 5:32 PM, Jesse Martinez <mjesse@gmail.com> wrote: > Thanks, Ray. This is very useful to know and reminds me of the trouble I > went through attempting to extend Dimensions too. > > And another peculiarity, which may or may not be related to this topic: > The dimension field (within the dimensionSubGroup repeatable group) can't > be converted to use a dynamic term list, at least in v4.0. The other static > term lists in the dimensions group can be converted to use dynamic lists, > but just not the dimension field. I'd be interested if anyone else has done > something like this before. > > Thanks, > > Jesse > > > On Tue, Jul 15, 2014 at 1:28 AM, Ray Lee <rhlee@berkeley.edu> wrote: > >> Hi Everyone, >> I'm picking up this old thread (and moving it from Work to Talk), since >> I've recently tried to extend dimensions, as Jesse was trying to do when he >> started it. Here's what I've found: >> >> 1. The dimensions schema is not currently being generated from app >> layer config. This can be fixed by adding some missing tags and attributes >> to base-other-dimension.xml. See CSPACE-6397 for details. >> 2. The services tenant bindings for dimensions are also not being >> generated from app layer config. This can be worked around by hand writing >> the necessary tenant bindings for your extension, as we used to do pre-4.0. >> See CSPACE-6398 for details. >> 3. After fixing 1 and 2, it's possible to configure a schema >> extension on dimensions. However, the services layer doesn't quite do the >> right thing when retrieving records that contain dimensions, when schema >> extensions on dimensions exist. See CSPACE-6399 for details. >> >> Because of 3, I gave up on making a schema extension, and like Jesse, >> decided to hack the common dimension schema, to add the necessary fields. >> So in one branch of our code, the dimensions_common schema differs from the >> dimensions_common schema in other branches. This is dangerous, but the best >> solution I could come up with. >> >> Thanks, >> Ray >> >> >> On Thu, May 1, 2014 at 12:01 PM, Jesse Martinez <mjesse@gmail.com> wrote: >> >>> An update: So, I worked around this issue by attaching my schema >>> extension fields to the core common schema for dimensions. It's not the >>> best approach for a number of reasons. :-/ >>> >>> - Jesse >>> >>> >>> On Mon, Apr 21, 2014 at 3:07 PM, Ray Lee <rhlee@berkeley.edu> wrote: >>> >>>> 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 >>>>>>>> > >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > > _______________________________________________ > Talk mailing list > Talk@lists.collectionspace.org > > http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org > >

Thanks, everyone - super helpful. I'll read/comment before your dev meeting on Monday. So exciting to be back on the release cycle! Sent from my iPhone On Sep 19, 2014, at 6:52 PM, "Aron Roberts" <aronroberts@gmail.com<mailto:aronroberts@gmail.com>> wrote: A belated response to an early August post by Jesse, below ... It's possible that Ray might have resolved this issue - which prevented adding dynamic (database-stored) term lists to extensions to Contacts and Dimensions - with his bugfix here: https://issues.collectionspace.org/browse/BAMPFA-37 Adding this fix to CollectionSpace's 'core' code is now being considered for part of the work during the remaining two weeks of development on release 4.1. Aron On Wed, Aug 6, 2014 at 5:32 PM, Jesse Martinez <mjesse@gmail.com<mailto:mjesse@gmail.com>> wrote: Thanks, Ray. This is very useful to know and reminds me of the trouble I went through attempting to extend Dimensions too. And another peculiarity, which may or may not be related to this topic: The dimension field (within the dimensionSubGroup repeatable group) can't be converted to use a dynamic term list, at least in v4.0. The other static term lists in the dimensions group can be converted to use dynamic lists, but just not the dimension field. I'd be interested if anyone else has done something like this before. Thanks, Jesse On Tue, Jul 15, 2014 at 1:28 AM, Ray Lee <rhlee@berkeley.edu<mailto:rhlee@berkeley.edu>> wrote: Hi Everyone, I'm picking up this old thread (and moving it from Work to Talk), since I've recently tried to extend dimensions, as Jesse was trying to do when he started it. Here's what I've found: 1. The dimensions schema is not currently being generated from app layer config. This can be fixed by adding some missing tags and attributes to base-other-dimension.xml. See CSPACE-6397 for details. 2. The services tenant bindings for dimensions are also not being generated from app layer config. This can be worked around by hand writing the necessary tenant bindings for your extension, as we used to do pre-4.0. See CSPACE-6398 for details. 3. After fixing 1 and 2, it's possible to configure a schema extension on dimensions. However, the services layer doesn't quite do the right thing when retrieving records that contain dimensions, when schema extensions on dimensions exist. See CSPACE-6399 for details. Because of 3, I gave up on making a schema extension, and like Jesse, decided to hack the common dimension schema, to add the necessary fields. So in one branch of our code, the dimensions_common schema differs from the dimensions_common schema in other branches. This is dangerous, but the best solution I could come up with. Thanks, Ray On Thu, May 1, 2014 at 12:01 PM, Jesse Martinez <mjesse@gmail.com<mailto:mjesse@gmail.com>> wrote: An update: So, I worked around this issue by attaching my schema extension fields to the core common schema for dimensions. It's not the best approach for a number of reasons. :-/ - Jesse On Mon, Apr 21, 2014 at 3:07 PM, Ray Lee <rhlee@berkeley.edu<mailto:rhlee@berkeley.edu>> wrote: 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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:mjesse@gmail.com>> wrote: >>> >>> Hi all, >>> >>> Anyone have experience extending the dimensions subgroup? >>> >>> Thanks, >>> >>> - Jesse >>> >>> _______________________________________________ >>> Work mailing list >>> Work@lists.collectionspace.org<mailto:Work@lists.collectionspace.org> >>> >>> http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org >>> >> > > > _______________________________________________ > Work mailing list > Work@lists.collectionspace.org<mailto:Work@lists.collectionspace.org> > http://lists.collectionspace.org/mailman/listinfo/work_lists.collectionspace.org > _______________________________________________ Talk mailing list Talk@lists.collectionspace.org<mailto:Talk@lists.collectionspace.org> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org _______________________________________________ Talk mailing list Talk@lists.collectionspace.org<mailto:Talk@lists.collectionspace.org> http://lists.collectionspace.org/mailman/listinfo/talk_lists.collectionspace.org