Openbravo.properties

Introduction

Several parameters should be configured for Openbravo to work correctly. These parameters can be configured through a graphical interface using the setup tool or by hand.

Contents

The content of this file include:

Date/time format

Define the date and time formats:

• dateFormat.js: date format used in Javascript controls.
• dateFormat.sql: date format used in the SQL controls.
• dateFormat.java: date format used by Java. For a list of possible values check the official documentation. Some examples:
  • dd-MM-yyyy
  • MM-dd-yyyy
  • yyyy-MM-dd
• dateTimeFormat.java: date and time format used by Java. For a list of possible values the URL above. Some examples:
  • dd-MM-yyyy HH:mm:ss
  • MM-dd-yyyy HH:mm:ss
  • yyyy-MM-dd HH:mm:ss
  • dd-MM-yyyy hh:mm:ss a   (12hrs AM/PM format. Available since Openbravo PR14Q3)
  • MM-dd-yyyy hh:mm:ss a   (12hrs AM/PM format. Available since Openbravo PR14Q3)
  • yyyy-MM-dd hh:mm:ss a   (12hrs AM/PM format. Available since Openbravo PR14Q3)
• dateTimeFormat.sql: date and time format used in the SQL controls.

After changing any of those properties above a complete re-compilation must be done, a smartbuild is not sufficient. This is needed as those values are incorporated in various generated files. Therefore, after changing any of these properties, ant compile.complete.deploy must be executed

General

• web.url: static content URL. Use the default value (@actual_url_context@/web) to make it dynamic. Don't change this unless you know what you are doing
• context.url: full URL of the context, only used by the Web Services installation and ant diagnostic task.
• attach.path: Absolute path to the attachments directory.
• source.path: root sources directory, used by modularity.
• application.version: Openbravo version, shown in the about box.
• context.name:: context name, used in the final war file.
• deploy.mode: how the context will be deployed into the servlet container. Valid options: war, class, none.
  In war mode a war file is created in lib/${context.name}.war. In class mode only the modified files are deployed into ${catalina.base}/webapps/${context.name}. In none mode everything the servlet container need is copied into the $OB_ROOT/WebContent directory, and no war is generated and no files are copied to the servlet container. This is useful for working with Eclipse.

Database

• bbdd.rdbms: name of the chosen database. Possible values:
  • Oracle: ORACLE
  • PostgreSQL: POSTGRE
• bbdd.driver: the JDBC driver, this depends on the chosen database. Possible values:
  • Oracle: oracle.jdbc.driver.OracleDriver
  • PostgreSQL: org.postgresql.Driver
• bbdd.url: the JDBC URL of the database. Possible values:
  • Oracle: jdbc:oracle:thin:@ip_address:port:SID (e.g. jdbc:oracle:thin:@localhost:1521:XE)
  • PostgreSQL: jdbc:postgresql://ip_address:port (e.g. jdbc:postgresql://localhost:5432)
• bbdd.sid: the SID in Oracle and the database name in PostgreSQL (lowercase letters and '_' accepted).
• bbdd.systemUser: the name of the database superuser. Usually it's system in Oracle and postgres in PostgreSQL.
• bbdd.systemPassword: the password of the database superuser.
• bbdd.user: the name of the user owner of the Openbravo database (lowercase letters and '_' accepted).
• bbdd.password: the password of the bbdd.user.
• bbdd.sessionConfig: additional options passed to the session. Currently this is mandatory. Possible values:
  • Oracle: ALTER SESSION SET NLS_DATE_FORMAT='DD-MM-YYYY' NLS_NUMERIC_CHARACTERS='.,'
  • PostgreSQL: select update_dateFormat('DD-MM-YYYY')
• db.queryTimeout.<timeoutProfile>=<timeout> allows to define a query timeout for a timeout profile. More info about this functionality can be found here
• java.security.egd: As reported in issue #12683, Oracle DB in some Linux boxes can delay on getting connection to database. This affects to build process, making it much slower. In these cases this property can be set to file:///dev/urandom which solves the problem.

Apache JDBC Connection Pool

This feature is available starting from 3.0PR15Q4.

• db.externalPoolClassName: Property used to configure the external connection pool. The default value is org.openbravo.apachejdbcconnectionpool.JdbcExternalConnectionPool. In that case Openbravo will start using the Apache JDBC connection Pool.
  • If the property is not given any value, the legacy connection pools are used.

All properties are explained in detail here.

Read-Only Pool

This feature is available starting from 3.0PR17Q2.

The read-only pool feature allows to retrieve connections from a secondary (backup) database which allows just read-only operations. Typically, this will be a stand-by database that must have its data updated as much as possible.

See Read-Only Pool for more details about the configuration of this pool.

Tomcat Manager

• tomcat.manager.url: URL to the Tomcat Manager, in the form http://ip_address[:port]/manager for Tomcat versions previous to 7. In Tomcat >=7 the form is http://ip_address[:port]/manager/text
• tomcat.manager.username: Tomcat Manager user name. In Tomcat >=7 this user must have manager-script role access. In previous versions, manager role access. See Tomcat's documentation.
• tomcat.manager.password: Tomcat Manager password.

Development parameters

Parameters specially useful for developers.

• bbdd.outputscript: path of the file generated by the update.database.script or create.database.script ant tasks.
• bbdd.verbosity: log info level displayed by the database ant tasks. Possible values: ERROR, INFO, WARN, DEBUG.
• minimizeJSandCSS: option to compress the CSS files. They are smaller and therefore faster. But the files are almost unreadable, so they are not useful for the development. Use it in production systems only. Possible values: yes, no.

Authentication

authentication.class: property used configure the authentication manager. Possible values:

• Default Authentication Manager: This is the default authentication manager that provides the classic login page. Class name org.openbravo.authentication.basic.DefaultAuthenticationManager.
• Autologon Authentication Manager: This is an authentication manager for demostration purposes. Class name org.openbravo.authentication.basic.AutologonAuthenticationManager.
• LAM Authentication Manager: This is the authentication manager used for Single Sign-on. Class name org.openbravo.authentication.lam.LamAuthenticationManager.
  From 3.0RC7 on the LAM Authentication Manager is no longer part of the Openbravo 3 distribution but instead available as a module. For details see the projects page.

This is an example using the default authentication manager.

authentication.class=org.openbravo.authentication.basic.DefaultAuthenticationManager
#authentication.class=org.openbravo.authentication.lam.LamAuthenticationManager
#authentication.class=org.openbravo.authentication.basic.AutologonAuthenticationManager
#authentication.autologon.username=Openbravo

Add-ons

• pentahoServer: URL to an external Pentaho Server. This is optional.

Hibernate

• hibernate.hbm.file: if this property is set then the hibernate mapping will be written to the file defined by this property, note the value should be the complete path including the file name and extension.

Safe mode

• safe.mode: activates or deactivates the safe mode. When safe mode is activated, if the last build wasn't succesful, the user will receive a warning when he tries to log in (if he has System Administrator priviledges), or he will receive an error (if he doesn't).

Log in security

These properties are explained in detail in Log in security document.

• login.trial.delay.increment: Seconds delay increment before checking user/password after failed login attempt.
• login.trial.delay.max: Maximum delay in seconds before checking user/password after failed login attempt.
• login.trial.user.lock: If the login security is enabled (login.trial.delay.increment is higher than 0), it represents the number of user/password failed before locking user.

Others

• allow.root: By default you are not allowed to run ant commands with the root user. Set this to true to override this.

This feature is available starting from 3.0MP20.

• background.policy: Background policy defines whether scheduled processes are executed in this environment (default) or not (no-execute). In instances having very resource demandant background processes that affect application responsiveness, can have two different servers with identical openbravo instances linked to a shared database, one of these instances would be used to serve the application to the users and would have no-execute value set in this property, whereas the other one would be used to execute processes so the value would be default. In the instance set not to execute background processes, it will not be allowed to schedule, unschedule nor kill processes, this must be performed in the instance allowing their execution. Note that there is a property which is also relevant for these type of setups: the import.disable.process property.

This feature is available starting from 3.0PR17Q1.

• application.server: If Openbravo is going to be deployed on WildFly, this property needs to be set with value wildfly (lower cased) before building the application.
• cluster [boolean]: Should be marked as true when Openbravo is deployed in a clustered environment.

This feature is available starting from 3.0PR17Q3.

• ws.maxInactiveInterval: (default 60) Minimum time in seconds to wait before expiring sessions created for stateful web services calls.

Edit

Available from 3.0PR15Q1

Openbravo.properties is a plain text file that you can edit manually by duplicating the Openbravo.properties.template file or using the assistant (console application).

Since 3.0PR15Q1 to configure Openbravo.properties file can (and in fact must) be done via console application. For that, go to the directory with the working clone of the repository and execute setup ant task:

cd openbravo-root
ant setup

The invocation of this ant target will compile and execute automatically a console application.By going through the console application provide all requested information and at the end, select Accept to apply the changes and close the application.

The recommended configuration option is [2], Default configuration that is the fastest option to configure the Openbravo.Properties file. Then you can change some specific properties.

As a result of these actions a new file Openbravo.properties, containing specified settings, will be created in config subdirectory.

Before 3.0PR15Q1 Openbravo.properties is a plain text file that you can edit manually by duplicating the Openbravo.properties.template file or using the graphical assistant (wizard).

To configure it using the wizard, first run the ant setup command to download the setup tool that matches your operating system and architecture:

cd openbravo-root
ant setup

Then, go to the config/ directory and run the setup-properties tool. For example, in Linux:

cd openbravo-root/config
./setup-properties-linux.bin

As a result of these actions a new file Openbravo.properties, containing specified settings, will be created in config subdirectory.

Note: If there is no setup binary for your operating system and architecture, send a request to <staff.rm at openbravo dot com>.

Overriding properties per instance

Available from 3.0PR15Q2

Openbravo installations within a Tomcat clustering can define some properties to be different between different cluster nodes while sharing a common Openbravo.properties file for the common properties.

This can be done by creating new properties files for each node wanting to override some properties. These files must be placed in the same config directory than common Openbravo.properties and be named hostName.Openbravo.properties, where hostName references the name of each node. Name of each host can be defined in 3 different manners:

• Starting from 3.0PR16Q3 it is possible to define the absolute path for this file by setting a JVM property named properties.path.
• Adding to the Tomcat's JVM a system property named machine.name which value is the hostName.
• If previous property is not set, it is taken from local host name. This name can be checked by executing ant host.name task in each node.

For example, having a cluster of 3 nodes named app1, app2 and app3. All the 3 nodes share the same webapp and sources directories. Background processes want to be run only in app1 node. In this case there would be a common Openbravo.properties file containing all the properties where background.policy would be set to no-execute. In addition there would be a app1.Openbravo.properties with background.policy set to default. In this manner, app1 instance would use the common Openbravo.properties for all the properties but for background.policy which would be overrident to default.

Developers: getting values for properties

The way to obtain the actual value for a concrete property is using OBPropertiesProvider.getInstance().getOpenbravoProperties().getProperty("propertyName") where propertyName is the name of the property to get the value for. OBPropertiesProvider manages file path location and property overwriting.