From dev to production

Support
#1

Hello,

Let say I made an application in development mode and now I am ready for production: Cuba/Deployment/UberJar.
Before to make a jar what setting are recommended for production?

I discovered this one:
cuba.web.productionMode = true

Anything else?

Best Regards,
-n

#2

Have a look at the following properties:

cuba.web.loginDialogDefaultUser
cuba.web.loginDialogDefaultPassword
cuba.gui.layoutAnalyzerEnabled
cuba.webContextName
cuba.webHostName
cuba.webPort
cuba.webAppUrl
cuba.automaticDatabaseUpdate
cuba.maxUploadSizeMb

You can decide on their values based on properties descriptions from the documentation

#3

Thank you! Very useful information.
However:

  1. What is cuba.gui.layoutAnalyzerEnabled? Allows you to disable the screen analyzer available in the context menu of the main window tabs and the modal window captions. I don’t understand. Do you have a screenshot?
  2. I’ve set cuba.webPort = 8081 in web-app.properties but the application still starts on 8080 port.
  3. cuba.automaticDatabaseUpdate this is very interesting feature. As far as I understand after deployment (let say into a VM) I can add some update.sql files in some location (where?) and the database structure should changes accordingly. In development phase these files are stored here: tomcat/webapps/app-core/WEB-INF/db. Is that correct? Can you detail a little bit please - maybe a use case scenario…?

Best Regards,
-n

#4

Just right-click on the tab on a screen and you will be able to invoke the analyzer

image

You should be able to specify the port at UberJar build settings:

image

DB-related files are in the UberJar folder LIB-INF\app-core\WEB-INF\db\. The CUBA will apply files located either in init or update folder depending on the DB state. You can safely change only 30.create-db.sql file and it will run only once, but if you’re brave enough you can change files generated by CUBA in update folder before building the UberJar. The cuba.automaticDatabaseUpdate property enables automatic SQL files execution during every deploy. Some people prefer updating production the DB manually in order to control the process, therefore they might want to disable it.