I’m not sure why your database schema isn’t been migrated automatically. I just reset the type of the note column in both to VARCHAR(256) and restarted XNAT and the column was converted to TEXT automatically. That said, something is blocking that migration, so you can fix it by hand pretty easily. Shut down Tomcat then run this SQL:
SELECT dependencies_save_and_drop('xnat_imagescandata');
ALTER TABLE xnat_imagescandata ALTER COLUMN note TYPE TEXT;
ALTER TABLE xnat_imagescandata_history ALTER COLUMN note TYPE TEXT;
SELECT dependencies_restore('xnat_imagescandata');
This should get rid of the start-up messages about this issue.
The issue with “01” being appended to the site ID when generating subject and experiment IDs is an unfortunate side effect of fixes made to support multi-node XNAT configurations. It’s almost impossible to avoid collisions when generating IDs on multiple nodes (at least, it’s almost impossible the way XNAT currently does that and changing how IDs are generated and referenced is extremely difficult), so we had to start appending the node or host number to the site ID. Initially the node or host number was omitted if there was only a single node, but there are enough corner cases where this doesn’t work that the node/host number is included all the time. Then there’s a bug where XNAT should check the node list and omit the node/host number if there are no configured nodes, but that’s not working properly so it operates as if there’s a single node but more might be added, i.e. it adds the node/host number.
The only way to change back is to modify the IDGenerator code and deploy that as a patch or wait for a release with this as an update. I don’t know if we have an issue in our bug tracker for this but I’ll make sure we get one.
Lastly re the plugin settings page, I can’t really say what’s going on there. I don’t think it’s related at all to the database messages you’re seeing, though. Try going to the Plugin Settings page with the developer tools window open to the Network tab. Try filtering by Fetch/XHR and you should see something like this:

In fact, everything should be almost exactly the same up until the page load that’s highlighted, content.jsp?view=admin/plugins. That’s the page that actually loads the various plugin settings configurations. After that, you should see a number of other calls depending on what plugins you have installed. Almost everything after that in the screen shot above is driven by the DICOM Q/R plugin, specifically the siteSettings.yaml configuration. It’s conceivable something is failing to load properly and that’s breaking the page display overall, so if that’s happening something should show up in the network traffic or the console below.
The only thing I can think of outside of things that would manifest during the settings page load is that something changed in the page layout and/or JavaScript between your old version and the upgraded version. The fix for that would be (hopefully) just clearing your browser cache for the XNAT site.
--
Rick Herrick
XNAT Architect/Developer
Computational Imaging Laboratory
Washington University School of Medicine
From:
xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Martin Boswell <msbo...@lbl.gov>
Date: Monday, November 8, 2021 at 3:04 AM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] Re: After 1.8.3 upgrade, database messages in catalina.out and Plugin Settings doesn't load
|
* External Email - Caution * |
--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
xnat_discussi...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/xnat_discussion/e381e205-d110-4903-a9e5-da40b59851efn%40googlegroups.com.
The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.
My guess would be something hinky in the yaml file for your plugin’s site/project settings. The site-wide plugin settings page locates and loads all Spawner elements with IDs that contain siteSettings. I currently have this:
# http --session=admin --pretty=format --body --verify=no https://xnatdev.xnat.org/xapi/spawner/namespaces
[
"dqr:projectSettings",
"dqr:siteSettings",
"siteAdmin"
]
This means that the only site settings I’ll see on that page are for DQR. You should something similar but for the plugins you have installed. You could try removing the site settings from your plugin and verifying that the site-wide plugin settings page loads properly, then try restoring your site settings bit by bit.
A useful thing you can try is just completely nuking the site settings for your plugin by deleting that Spawner namespace. For example, to delete the DQR site settings plugin settings, I can just do:
# http --session=admin --pretty=format --body --verify=no https://xnatdev.xnat.org/xapi/spawner/namespaces
[
"dqr:projectSettings",
"dqr:siteSettings",
"siteAdmin"
]
# http --session=admin --pretty=format --verify=no DELETE https://xnatdev.xnat.org/xapi/spawner/elements/dqr:siteSettings
HTTP/1.1 200
Connection: keep-alive
Content-Length: 0
Content-Security-Policy: frame-ancestors 'self'
Date: Wed, 10 Nov 2021 17:05:27 GMT
Server: nginx/1.18.0 (Ubuntu)
Set-Cookie: SESSION_EXPIRATION_TIME="1636563927164,3600000"; Version=1; Path=/; Secure
# http --session=admin --pretty=format --body --verify=no https://xnatdev.xnat.org/xapi/spawner/namespaces
[
"dqr:projectSettings",
"siteAdmin"
]
You can restore the system settings as loaded on start-up easily as well:
# echo true | http --session=admin --pretty=format --body --verify=no POST https://xnatdev.xnat.org/xapi/spawner/initialize
HTTP/1.1 200
Connection: keep-alive
Content-Length: 0
Content-Security-Policy: frame-ancestors 'self'
Date: Wed, 10 Nov 2021 17:07:36 GMT
Server: nginx/1.18.0 (Ubuntu)
Set-Cookie: SESSION_EXPIRATION_TIME="1636564055976,3600000"; Version=1; Path=/; Secure
# http --session=admin --pretty=format --body --verify=no https://xnatdev.xnat.org/xapi/spawner/namespaces
[
"dqr:projectSettings",
"dqr:siteSettings",
"siteAdmin"
]
There are also a bunch of calls under the Spawner REST API where you can delete or modify specific elements, which may help you delete and restore elements in your plugin’s site settings without having to modify YAML, rebuild the plugin, and restart XNAT for each iteration. The easiest way to get at that REST API is through the Swagger page, which you can find at http://server/xapi/swagger-ui.html.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/ea25b070-054a-45f9-97ba-79b101ea4168n%40googlegroups.com.