- About XNAT
- News & Events
- XNAT Marketplace
- Contact Us
These release notes address the 1.6.2 update only. For older 1.6 releases, see:
A bug in 1.6.1 prevents project members from editing project data (essentially, they become collaborators). This is fixed for 1.6.2.
Anonymization scripts in 1.5 (which were only applied through the upload applet) were stored in different places and followed different rules than in 1.6 (which is applied by both the applet script and during archiving from prearchive). A more comprehensive description of the changes, and how to port from 1.5, needs to go here.
Many new security features were introduced in XNAT 1.6. See the services.properties configuration wiki page for more information about how to configure your site's security. Some of the features are turned off by default, so make sure to turn them on if you want to use them. In particular, LDAP authentication has been moved from authentication.properties to services.properties.
The scan level field parameters/scanTime, previously defined in the individual scan modality types (e.g., mrScanData/parameters/scanTime, ctScanData/parameters/scanTime) has been replaced by imageScanData/startTime. Any customized files that use scan times will need to be modified accordingly.
XNATDev Team: The data will also need to be modified. I've been doing this by rerunning pullDataFromHeaders() on each session. It would probably be better to provide an SQL script that moves the values and removes the old table.
The methods of this class now require an event parameter to facilitate an audit trail.
If you had this set up in 1.5 you'll have to tweak it a bit for 1.6; more info here.
When you install a new XNAT from the 1.6 release and start Tomcat, before logging in and initializing the system, you may see a number of errors in the xdat.log and sql.log files. These are caused by delayed initialization of some of the dependent tables and will stop occurring once you've logged in and initialized the system settings. These errors take a couple of different forms, as shown below.
In xdat.log, you may see a couple of different messages relating to prearchive tables and meta-data.
2012-03-29 14:41:20,885 [http-8080-2] ERROR org.nrg.xnat.turbine.utils.ArcSpecManager - java.lang.NullPointerException at org.nrg.xnat.helpers.prearchive.PrearcDatabase.getPrearcPath(PrearcDatabase.java:115) at org.nrg.xnat.helpers.prearchive.PrearcDatabase.initDatabase(PrearcDatabase.java:94) at org.nrg.xnat.turbine.utils.ArcSpecManager.GetInstance(ArcSpecManager.java:219) at org.nrg.xnat.turbine.utils.ArcSpecManager.GetInstance(ArcSpecManager.java:53) at org.nrg.xnat.turbine.modules.screens.Configuration.doBuildTemplate(Configuration.java:14) at org.nrg.xdat.turbine.modules.screens.SecureScreen.doBuildTemplate(SecureScreen.java:84) [truncated]
2012-03-29 14:41:18,764 [org.springframework.scheduling.quartz.SchedulerFactoryBean#0_Worker-2] ERROR org.nrg.xnat.helpers.prearchive.PrearcTableBuilder - org.postgresql.util.PSQLException: ERROR: relation "xdat_search.prearchive" does not exist Position: 15 [truncated]
2012-03-29 14:42:07,225 [http-8080-6] ERROR org.nrg.xft.db.DBAction - org.postgresql.util.PSQLException: ERROR: relation "xdat_meta_element_meta_data" does not exist Where: PL/pgSQL function "update_ls_xdat_meta_element" line 6 at FOR over SELECT rows
The message that may appear in sql.log relates to the meta-data table initialization. It doesn't appear as an error, but may be repeated enough to cause concern and looks similar to this:
2012-03-29 14:42:19,886 - SELECT update_ls_xdat_meta_element(573,NULL)