The base.config
file is the main configuration file
for BASE. It is located in the <basedir>/www/WEB-INF/classes
directory.
This section has parameters needed for the database connection, such as the database dialect, username and password.
The Hibernate dialect to use when generating SQL commands to the database. Use:
org.hibernate.dialect.MySQLInnoDBDialect
for MySQL
org.hibernate.dialect.PostgreSQLDialect
for PostgreSQL
Other dialects may work but are not supported.
The JDBC driver to use when connecting to the database. Use:
com.mysql.jdbc.Driver
for MySQL
org.postgresql.Driver
for PostgreSQL
Other JDBC drivers may work but are not supported.
The connection URL that locates the BASE database. The exact syntax of the string depends on the JDBC driver. Here are two examples which leaves all other settings to their defaults:
jdbc:mysql://localhost/base2
for MySQL
jdbc:postgresql:base2
for PostgreSQL
You can get more information about the parameters that are supported on the connection URL by reading the documentation from MySQL and PostgreSQL.
![]() |
Note |
---|---|
For MySQL we recommend that you enable the server-side cursors feature.
It will reduce memory usage since the JDBC driver does not have to
load all data into memory:
Some MySQL versions (for example, 5.0.27) contains a bug that causes some
queries to fail if |
The name of the catalog where the dynamic database used to store analysed data is located. If not specified the same catalog as the regular database is used. The exact meaning of catalog depends on the actual database. For MySQL the catalog is the name of the database so this value is simply the name of the dynamic database. PostgreSQL does not support connecting to multiple databases with the same connection so this should have the same value as the database in the db.url setting.
The name of the schema where the dynamic database used to store analysed data is located. MySQL does not have schemas so this value should be left empty. PostgreSQL supports schemas and we recommend that the dynamic part is created in it's own schema to avoid mixing the dynamic tables with the regular ones.
The username to connect to the database. The user should have full permission to both the regular and the dynamic database.
The password for the user.
The batch size to use when inserting/updating items with the Batch API. A higher value requires more memory, a lower value degrades performance since the number of database connections increases. The default value is 50.
The location of an XML file which contains database-specific
queries overriding those that does not work from the
/common-queries.xml
file. Use:
/mysql-queries.xml
for MySQL/postgres-queries.xml
for PostgreSQLSee also Section J.1, “mysql-queries.xml and postgres-queries.xml”.
The location of an XML file describing the extended properties for extendable
item types, ie. the reporters. The default value is /extended-properties.xml
.
See Appendix D, extended-properties.xml reference for more information
about extended properties.
The location of an XML file describing all raw data types and their properties.
The default value is /raw-data-types.xml
.
See Appendix E, Platforms and raw-data-types.xml reference for more information
about raw data types.
The maximum number of items the export function should try to load in a single query. This setting exists because MySQL prior to 5.0.2 does not support scrollable result sets, but loads all data into memory. This will result in out of memory exception if exporting too many items at the same time. PostgreSQL does not have this problem. Use:
0 for PostgreSQL
0 for MySQL version 5.0.2 or above.
Requires that useCursorFetch=true
is specified in
the connection url and that defaultFetchSize=xxx
is set to a value > 0.
As large as possible value for other MySQL versions. A low value results in more queries and slower performance when exporting data.
This section describes parameters that are needed if you are going to use external authentication. If you let BASE handle this you will not have to bother about these settings. See Section 26.6.1, “Authentication plug-ins” for more information about external authentication.
The class name of the plug-in that acts as the authentication driver.
BASE ships with a simple plug-in that checks if a user has a valid email
account on a POP3 server. It is not enabled by default. The class name
of that plug-in is net.sf.basedb.core.authentication.POP3Authenticator
Initialisation parameters sent to the plug-in when calling the
init()
method. The syntax and meaning of this
string depends on the plug-in. For the POP3Authenticator
If this setting is 1 or TRUE, BASE will synchronize the extra information (name, address, email, etc.) sent by the authentication driver when a user logs in to BASE. This setting is ignored if the driver does not support extra information.
If passwords should be cached by BASE or not. If the passwords are cached a user may login to BASE even if the external authentication server is down. The cached passwords are only used if the external authentication does not answer properly.
How many days a cached password is valid if caching is enabled. A value of 0 caches the passwords forever.
This section contains setting that control the internal job queue. The internal job queue is a simple queue that executes jobs more or less in the order they were added to the queue. To make sure long-running jobs do not block the queue, there are four slots that uses the expected execution time to decide if a job should be allowed to execute or not.
If 0
or FALSE
the internal
job queue will be disabled.
If 1
or TRUE
the internal
job queue will ignore the useInternalJobQueue
flag specified on plug-ins. If 0
or FALSE
the internal job queue will only execute plug-ins which has
useInternalJobQueue=true
A class implementing the SignalReceiver
net.sf.basedb.core.signal.LocalSignalReceiver
Change to net.sf.basedb.core.signal.SocketSignalReceiver
Initialisation string sent to SignalReceiver.init()
.
The syntax and meaning of the string depends on the actual implementation
that is used. Please see the Javadoc for more information.
The number of seconds between checks to the database for jobs that are waiting for execution.
Maximum number of threads to reserve for jobs with a given expected execution time. A job with a short execution time may use a thread from one of the slots with longer execution time. When all threads are in use, new jobs will have to wait until an executing job has finished.
The priority to give to jobs. The priority is a value between 1 and 10. See http://java.sun.com/javase/6/docs/api/java/lang/Thread.html for more information about thread priorities.
This section contains settings that BASE uses when communicating with external job agents. See Section 21.2, “Installing job agents” for more information about job agents.
Number of seconds to keep job agent information in the internal cache. The information includes, CPU and memory usage and the status of executing jobs. This setting controls how long the information is kept in the cache before a new request is made to the job agent. The default value is 60 seconds.
The timeout in milliseconds to wait for a response from a job agent when sending a request to it. The default timeout is 1000 milliseconds. This should be more than enough if the job agent is on the internal network, but may have to be increased if it is located somewhere else.
This section contains settings for the secondary storage controller. See Section 26.6.2, “Secondary file storage plugins” for more information about secondary storage.
The class name of the plug-in that acts as the secondary storage controller.
BASE ships with a simple plug-in that just moves files to another directory,
but it is not enabled by default. The class name of that plug-in is
net.sf.basedb.core.InternalStorageController
Initialisation parameters sent to the plug-in when calling the
init()
method. The syntax and meaning of this
string depends on the plug-in. For the internal controller this is simply
the path to the secondary directory.
Interval in seconds between each execution of the secondary storage controller plug-in. It must be a value greater than zero or the secondary storage feature will be disabled.
Time-point values specifying the time(s) of day that the secondary storage controller
should be executed. If present, this setting overrides the
secondary.storage.interval setting.
Time-point values are given as comma-separated list of two-digit, 24-based hour
and two-digit minute values. For example: 03:10,09:00,23:59
.
The path to the directory where uploaded and generated files should be stored. This is the primary file storage. See the section called “Secondary storage controller” for information about how to configure the secondary storage. Files are not stored in the same directory structure or with the same names as in the BASE file system. The internal structure may contain sub-directories.
Number of minutes to cache a logged in user's permissions before reloading them. The default value is 10. This setting affect how quickly a changed permission propagate to a logged in user. Permissions are always reloaded when a user logs in.
Number of minutes to keep user sessions in the internal cache before the user is automatically logged out. The timeout is counted from the last access made from the user.
Defines if already existing helptexts in BASE should be overwritten when updating the program, Section 21.1, “Upgrade instructions”
true
will overwrite existing helptexts.
false
will leave the existing helptexts in database unchanged and only
insert new helptexts.
Enable this setting to let BASE detect if a plug-in JAR file is changed and automatically load and use the new code instead of the old code. This setting is useful for plug-in developers since they don't have to restart the web server each time the plug-in is recompiled.
true,yes,1
to enable
false,no,0
to disable (default if no value is specified)
The path to the directory where jar-files for external plugins should be located if they should be used with the auto-installer. All new plugins found in this directory, or in any of it's sub-directories, can be selected for installation, see Section 22.1, “Installing plug-ins”. The plugging auto-installer will not be available if this property isn't defined.
Another benefit is that all plug-ins inside this directory are registered with relative paths. This means that there is a lot less hassle when using job agents to run plug-ins. Just change this setting for the job agent installation and all plug-ins will work. For plug-ins that are outside of this directory you may have to manually register the path if it is different from the main path. It will also be a lot easier if you plan to move all plug-ins to a different directory. Just move the JAR files and change this setting. There is no need to change the paths for each plug-in in the database.