Custom Logo when deploying XNAT 1.7 using WAR

81 views
Skip to first unread message

Jim Klo

unread,
Apr 4, 2019, 9:01:04 PM4/4/19
to xnat_discussion
I'm in the process of upgrading our XNAT 1.6 installation to 1.7 with a new Docker container.  

I've got most of the kinks worked out for our installation, however one of the issues I've run into which I'm not entirely 100% sure how to "fix" is the custom logo and site description, since instead of building a new WAR from source as was the method with 1.6, 1.7 already has a WAR distribution.  I'd rather not have to unpack and repack the WAR resources, but not sure what the right solution to update the logo would be.

Unfortunately because of the way Tomcat works, if the WAR redeploys (such as during a reboot), the exploded directory where one might store a custom logo should get destroyed and recreated.  

Bear with me I'm a bit new to XNAT... I found this page on the wiki: https://wiki.xnat.org/display/XNAT17/XNAT+Site+Settings which seems to describe some properties which I presume I can override the values from xnat-config.properties?  Seems pretty straightforward for something like "Site Description" which can just be a Markdown string, however for anything with a file, I'm not quite sure where to insert the files - mostly because a redeploy will wipe out the files copied into the exploded context root.

Thanks in advance for any clarity one can provide.

- Jim


Herrick, Rick

unread,
Apr 5, 2019, 2:03:55 PM4/5/19
to xnat_di...@googlegroups.com

The easiest way to do the description, as you’ve noted, is by setting the Site Description text. However you can set the page by reference as well (i.e. specifying a path to it within the webapp) and that’s just what you need to do with the logo. This requires a very very simple plugin, one that actually doesn’t even need any of the plugin infrastructure. I just built one with these files:

 

  • META-INF/resources/images/cthulhu.jpg
  • META-INF/resources/templates/screens/cthulhu-site.vm

 

Then ran:

 

$ jar cf cthulhu-branding.jar *

 

I copied that jar into the plugins folder on my XNAT installation, restarted Tomcat (which is required unfortunately; the upside is that once the plugin jar has been loaded, you can update those files in the jar and the changes take effect immediately), then changed the Site Description to use a page reference and set that to /screens/cthulhu-site.vm and the Site Logo Path to /images/cthulhu.jpg and voila:

 

 

This takes advantage of a feature in the Servlet 3.0 spec where anything in a jar file stored in the folder META-INF/resources is considered to be part of the web application. Basically everything in the root web application folder (i.e. the top level of the XNAT war file or the contents of the extracted folder under the Tomcat webapps folder) is joined with everything that’s stored in a jar file under META-INF/resources. That means that, as far as the web app is concerned, the images folder contains both logo.png (the default XNAT logo) and cthulhu.jpg, even though they’re actually stored in different places.

 

Just for reference I attached the files I built the jar from. Extract those somewhere then run that jar command above.

 

-- 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

Phone: +1 (314) 273-1645

--
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 post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at https://groups.google.com/group/xnat_discussion.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/7e61bf57-eff8-49ed-b08f-e9f45aaaf753%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

 


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.

cthulhu.zip

Jim Klo

unread,
Apr 5, 2019, 10:41:41 PM4/5/19
to xnat_discussion
So this sort of works... 

Creating the custom jar file and deploying via ${xnat.home}/plugins seems to work to add the custom resources - Thanks!.

However I cannot seem to override config via ${xnat.home}/config/xnat-conf.properties.  It seems like it's reading values stored in the DB or somewhere else versus what's in xnat-conf.properties.

e.g. I've added the following:

siteDescription=Page
siteDescriptionPage=/templates/screens/ncanda/site_description.vm
siteLogoPath=/images/ncanda/logo.png

archivePath=/fs/storage/XNAT/archive
prearchivePath=/fs/storage/XNAT/prearchive
pipelinePath=/usr/local/var/xnat/pipeline

It seems the pipelinePath got adopted... can can't verify the archivePath and prearchivePath since those are actually the same as previous install.  However none of the site* properties seem to be picked up.

FWIW our 1.6 image uses /fs/storage/XNAT in lieu of /data/xnat, somehow the old settings that use /fs/storage/XNAT got retained... not sure how or where, so not quite sure where these settings are getting stored.

Thanks,

- JK

To unsubscribe from this group and stop receiving emails from it, send an email to xnat_di...@googlegroups.com.

Herrick, Rick

unread,
Apr 8, 2019, 8:34:07 AM4/8/19
to xnat_di...@googlegroups.com

This is because of the difference between the xnat-conf.properties and prefs-init.ini/prefs-override.ini files:

 

  • xnat-conf.properties sets environment variables in the application context that used in place of value references in the code and configuration. The default xnat-conf.properties is mostly for configuration of the ORM environment, specifically database access and Hibernate settings.

 

  • prefs-init.ini is used to initialize values in the XNAT preferences database. It’s an INI file, so it’s organized by preference tool so anything for siteConfig is in a section headed with [siteConfig]. You can get actually get a full dump of all preferences in a particular XNAT system in INI format through the REST API:

 

$ http --session=admin --pretty=format –body https://xnatdev.xnat.org/xapi/prefs/ini

[siteConfig]

#Settings for tool siteConfig

#Mon Apr 08 07:24:05 CDT 2019

initialized=true

requireEventName=false

uiShowLeftBarBrowse=true

...

 

Note the initialize qualifier though: if you set a value in prefs-init.ini, e.g. siteConfig -> siteDescription, that value will only be set as long as there’s not already a value for siteDescription. This provides an easy way to initialize a new system without having to go through the setup process. For my Vagrant dev VMs, I usually have a prefs-init.ini with a siteConfig section that specifies values for siteUrl and initialize=true, so when I log in the first time I’m ready to work rather than have to enter values on the setup page.

 

  • prefs-override.ini is used to set and reset values on system startup/restart. Again, it’s an INI file organized by preference tool. This differs from prefs-init.ini in that, if you set a value for siteConfig -> siteDescription, the value for siteDescription will be set to whatever value is specified in your prefs-override.ini on system restart.

 

Try setting your values in prefs-init.ini or prefs-override.ini and starting again:

 

[siteConfig]

siteDescription=Page

siteDescriptionPage=/templates/screens/ncanda/site_description.vm

siteLogoPath=/images/ncanda/logo.png

archivePath=/fs/storage/XNAT/archive

prearchivePath=/fs/storage/XNAT/prearchive

pipelinePath=/usr/local/var/xnat/pipeline

 

One caveat: if this is a new system there’s no issue but on a system with any file resources already stored, setting a new value for archivePath can cause XNAT to become very grumpy. Fixing this issue will be one of the big development pushes for 1.8 development but for now just be aware!

 

-- 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

Phone: +1 (314) 273-1645

 

Image removed by sender.

To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.


To post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at https://groups.google.com/group/xnat_discussion.


For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
Forward
0 new messages