I have 2 apps (separate war files) deployed to the same Tomcat server. Both apps share the same login module that uses a combination of external authentication and the svySecurity module and they work fine in the developer. I’ve recently started testing them deployed to Tomcat. The first app works just fine, the 2nd app won’t log in due to the following exception.
I’ve verified that both apps have the same jar files and components included. It appears that for some reason when the sessions record is created (line 2757 in svySecurity.js) the id field is not being populated.
sessions table:
I have been unable to figure out why one app works and the other does. Thoughts?
I just upgraded to 2025.6.2.4084 and both apps worked for a short period of time. Then after making a small change and deploying an updated .war file the 2nd app no longer works.
Has anybody else run into issues with fields setup with a sequence type of “uuid generate” not generating a value?
This issue is very intermittent. It’s worked correctly a couple times but then stops working. I’ve added my own messages to see if when a sessions record is created if the id gets populated.
This code is in the login module “onSolutionOpen” and shows the id as null.
Does anyone know if there’s a way to turn on debugging to see what’s happening when the uuid is supposed to be generated? I need to get this working and at this time I don’t have a workaround. Thanks.
Hi Louis,
If you set a breakpoint where the session is initialized (i.e. line 2759), can you inspect the value?
What database is used and what is the SQL type for the column?
Best,
Sean
Sean,
It works in the developer, the issue only happens when the war file is deployed to tomcat.
I believe that the svy_security database is Postgress. The id column is defined as UUID (Text(36)) with the sequence type set to “uuid generator”. Also, with this coming from the svySecurity module I haven’t added any debug messages to it. I’ll try that though to see if I can get any more information.
Louis
Hi Louis,
Ah, so it breaks only in deployment. I suspect that the change to the default value is somehow not overridden.
Try updating this setting in your war file export:
Override default values: If checked, the default values will be overridden for the exported servers. This may break other solutions using the same tables, or cause tables to use nonexistent dbidentity or dbsequence sequences or other database auto enter types!
Best,
Sean
