Could not find screen for Login.vm
Benjamin Yvernault
Horrible Exception: java.lang.Exception: Could not find screen for Login.vm at org.apache.turbine.modules.screens.VelocityScreen.buildTemplate(VelocityScreen.java:104) at org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.java:101) at org.apache.turbine.modules.Screen.build(Screen.java:57) at org.apache.turbine.modules.ScreenLoader.eval(ScreenLoader.java:104) at org.apache.turbine.modules.ScreenLoader.exec(ScreenLoader.java:119) at org.apache.turbine.modules.screens.TemplateScreen.doRedirect(TemplateScreen.java:163) at org.apache.turbine.modules.screens.TemplateScreen.doRedirect(TemplateScreen.java:187) at org.nrg.xdat.turbine.modules.screens.SecureScreen.isAuthorized(SecureScreen.java:226) at org.nrg.xdat.turbine.modules.screens.SecureScreen.doBuildTemplate(SecureScreen.java:121) at org.apache.turbine.modules.screens.TemplateScreen.doBuild(TemplateScreen.java:100) at org.apache.turbine.modules.Screen.build(Screen.java:57) at org.apache.turbine.modules.ScreenLoader.eval(ScreenLoader.java:104) at org.apache.turbine.modules.layouts.VelocityOnlyLayout.doBuild(VelocityOnlyLayout.java:92) at org.apache.turbine.modules.Layout.build(Layout.java:53) at org.apache.turbine.modules.LayoutLoader.exec(LayoutLoader.java:98) at org.apache.turbine.modules.pages.DefaultPage.doBuild(DefaultPage.java:146)
Herrick, Rick
I suspect that you’ve run into a very weird bug that happens on occasion that I’ve never been able to figure out. Sometimes the app name you choose makes PostgreSQL become case sensitive to names in the SQL. So in this case, if you go into psql and try to run this query:
SELECT pg_get_serial_sequence('xnat_projectData_resource','xnat_projectData_resource_id') AS col_name
That will fail, but this will work:
SELECT pg_get_serial_sequence('xnat_projectdata_resource','xnat_projectdata_resource_id') AS col_name
If that’s the case, you can try building your app again from scratch—i.e. delete the deployments and projects folders—and change the app name from qs-controls to qscontrols. I’ve had this happen with numbers in the app name as well as dashes. What’s weird is that I’ve had it work just fine with numbers and dashes in the app name too. And I’ve not been able to find what it is that triggers psql to become case sensitive.
--
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 http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.
The material in this message is private and may contain Protected Healthcare Information (PHI). 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.
Benjamin Yvernault
Benjamin Yvernault
Herrick, Rick
In psql, make sure you’re terminating the queries with a semicolon, so:
SELECT pg_get_serial_sequence('xnat_projectData_resource','xnat_projectData_resource_id') AS col_name;
When you see the psql prompt turn from ‘=>’ into ‘->’, that means it’s a continuous statement. This lets you do things like this:
xnat=> SELECT * FROM xdat_user
xnat-> WHERE login = 'admin';
That helps make the query more readable and easier to detect errors or things you want to change.
Now, what’s interesting is that I just ran these queries myself on a working XNAT installation:
xnat=> SELECT pg_get_serial_sequence('xnat_projectData_resource','xnat_projectData_resource_id') AS col_name;
ERROR: column "xnat_projectData_resource_id" of relation "xnat_projectdata_resource" does not exist
xnat=> \d xnat_projectData_resource
Table "public.xnat_projectdata_resource"
Column | Type | Modifiers
------------------------------------------------+-------------------+--------------------------------------------------------------------------------------------------
xnat_projectdata_id | character varying | not null
xnat_abstractresource_xnat_abstractresource_id | integer | not null
xnat_projectdata_resource_id | integer | not null default nextval('xnat_projectdata_resource_xnat_projectdata_resource_id_seq'::regclass)
Indexes:
"xnat_projectdata_resource_pkey" PRIMARY KEY, btree (xnat_projectdata_resource_id)
Foreign-key constraints:
"xnat_projectdata_resource_xnat_abstractresource_xnat_abstr_fkey" FOREIGN KEY (xnat_abstractresource_xnat_abstractresource_id) REFERENCES xnat_abstractresource(xnat_abstractresource_id) ON UPDATE CASCADE ON DELETE CASCADE
"xnat_projectdata_resource_xnat_projectdata_id_fkey" FOREIGN KEY (xnat_projectdata_id) REFERENCES xnat_projectdata(id) ON UPDATE CASCADE ON DELETE CASCADE
xnat=> SELECT pg_get_serial_sequence('xnat_projectdata_resource','xnat_projectdata_resource_id') AS col_name;
col_name
-------------------------------------------------------------------
public.xnat_projectdata_resource_xnat_projectdata_resource_id_seq
(1 row)
So I guess the column names are always case sensitive? But… in the SQL for this installation, the column names are camel-cased just as they are in the query. So it appears that PostgreSQL is lower-casing the names before creating them. And somehow the way all of this works changes based on the XNAT app name… Weird. So you can see why this is a hard thing to track down!
Benjamin Yvernault
You received this message because you are subscribed to a topic in the Google Groups "xnat_discussion" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/xnat_discussion/Su4IYP731lo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to xnat_discussi...@googlegroups.com.
Matt South
WARNING: Problem with directory [/usr/share/tomcat7/common/classes], exists: [false], isDirectory: [false], canRead: [false]
Aug 16, 2018 5:21:30 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat7/common], exists: [false], isDirectory: [false], canRead: [false]
Aug 16, 2018 5:21:30 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat7/server/classes], exists: [false], isDirectory: [false], canRead: [false]
Aug 16, 2018 5:21:30 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat7/server], exists: [false], isDirectory: [false], canRead: [false]
Aug 16, 2018 5:21:30 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
WARNING: Problem with directory [/usr/share/tomcat7/shared/classes], exists: [false], isDirectory: [false], canRead: [false]
Aug 16, 2018 5:21:30 PM org.apache.catalina.startup.ClassLoaderFactory validateFile
I realised after the email that I didn’t terminate the query, oups.Yes, I spend two days trying to find the issue. When I saw that changing the name of the xnat project app by removing the dash makes it work, it killed me :).Thank you Rick for your help.Ben
Herrick, Rick
Hey Matt,
Those Tomcat warnings are actually just an artifact of the packaging on Ubuntu/Debian. It’s fixed in later releases. Basically the CATALINA_BASE and CATALINA_HOME settings get screwed up. I think CATALINA_BASE should be /var/lib/tomcat7 and CATALINA_HOME should be /usr/share/tomcat7, but you’ve probably got CATALINA_BASE set to /usr/share/tomcat7. You should be able to find the values Tomcat’s using by looking in the catalina.out log. I have this on my VM:
Aug 15, 2018 11:14:05 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: CATALINA_BASE: /var/lib/tomcat7
Aug 15, 2018 11:14:05 AM org.apache.catalina.startup.VersionLoggerListener log
INFO: CATALINA_HOME: /usr/share/tomcat7
Sometimes messing with those variables can be like pulling out one of the bottom supports on a house of cards, so another workaround is to create symlinks between the folders (run as root or add sudo to each command):
$ ln -s /var/lib/tomcat7/common /usr/share/tomcat7/common
$ ln -s /var/lib/tomcat7/server /usr/share/tomcat7/server
$ ln -s /var/lib/tomcat7/shared /usr/share/tomcat7/shared
$ service tomcat7 restart
All that said, unless you’re adding classes to Tomcat directly (where they’re accessible to all web apps running on the server), these folders are irrelevant. That’s why the messages are warnings and not errors: you would see something bad happen if you tried to reference classes that aren’t contained on your web app’s classpath, but XNAT doesn’t do that. Historically there were certain types of code that needed to be in the Tomcat server folders in order to work properly because of issues with the Java security manager and that’s where those folders came from. Nowadays that sort of restriction isn’t really used any more.
Regarding setting the site ID, this is stored in two places: the configuration data store and the archive specification table. The latter is the easier one to see and change:
xnat=> SELECT site_id FROM arc_archivespecification;
site_id
---------
XNAT-BAD-MKAY
(1 row)
xnat=> UPDATE arc_archivespecification SET site_id = 'XNAT';
UPDATE 1
The configuration data store is a bit more complicated, because it’s stored as text in the configuration data table but you need to get to the currently active row through the xhbm_configuration table, so you’d need to do a query like this:
SELECT d.contents
FROM xhbm_configuration_data d
LEFT JOIN xhbm_configuration c ON d.id = c.config_data
WHERE c.tool = 'site' AND c.path = 'siteConfiguration' AND c.enabled = TRUE;
You can get the ID of the row in the data table as well, modify the contents in there to change the site ID, and update it directly back in the table. That should reset the site ID completely, so hopefully you’ll be able to start!
--
Rick Herrick
Sr. Programmer/Analyst
Neuroinformatics Research Group
Washington University School of Medicine
Phone: +1 (314) 273-1645
Visit this group at https://groups.google.com/group/xnat_discussion.
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.