The login configuration for the administration console:
Remember that if these two parameters are not configured, it will be not possible
to use the administration console
The locale configuration:
This is the default locale of the application. The value is used in class
The configuration of the logger:
The value of log_category
is defined in the file log4j.xml
The configuration of the authentication and authorization:
Setting authentication in false
will also disable the authorization process. You can use these
values in the project's main action (see an example
The configuration of the database:
In the db_resources_names
, we define the logical names of the database resources. The names of the
resources must be separated by a comma. For example, we can declare three resources, for three different
databases like this: db_resources_names=db1,jdbc/db2,db3
can take these values:
- cp : for setting a connection pool.
- ds : for setting a datasource.
- pcm : for proprietary connection management.
For example, if the database resource with name db1
is a connection pool, the database resource with name jdbc/db2
is a datasource, and the database resource db3
is a proprietary connection management,
the configuration will be:
We can use any logical name for a connection pool. For a data source, we have to use the one set
in the application server or program used to configure the data source. A possible name will be
something like this: jdbc/mydb
In the default_db
is defined the logical name of the default database. For example,
a possible value is db1
These are the additional parameters for the proprietary connection management:
is created by adding the common prefix pcm_class_
and the name of the database resource (db3
in this example). In that parameter
is defined the complete name of the class to use for get and release database connections
(see proprietary connection management
These are the additional parameters for the connection pools:
In the connection_test_sql
we define the sql command that will be used for verifying if a connection is open. The
sql command is the same for all the connection pools.
The syntax of the parameters names are the same for all of them: the name of the parameter plus underscore
plus the logical name of the database resource. So, for set the driver for db1
we have to write
. If we have another database resource of connection pool type, for example
, then for setting the driver we have to write
The values of parameters cp_driver_
depends on the database we use.
You can find examples of some of them in the jfw.properties
found in the example webapp.
The values of parameters cp_username_
are the ones defined during
the database installation.
If you want to see in the JFW web console more information about every single connection, then
parameter must be set to true
are defined the number of database connections to keep in pool.
The right value of this parameter depends on your database installation. Remember that if the application
needs more contemporary connections than the one defined by this parameters, the connection pool will try
to open more connections. The temporary connections will be closed when the application releases them.
we define the auto commit behavior for all the connections managed
by this connection pool.
we define the time in minutes, before a connection used by the
application must be defined blocked and must be closed. Before a blocked connection is closed is
is set the period, in minutes, of execution of the thread which
verifies the status of the connections. If the value is 0
then the verification process is inactive.
The configuration of the scheduler:
In the scheduled_objects
are defined the class to execute and the scheduling type. The class
declared previously is available in the example webapp. Let's take a closer look at the possible
values for this parameter.
- com.jfw.examples.StartupSCH : the class to execute. Must extend the class
- Startup/0 : the type of scheduling and relative parameters. In this case the schedule
is of type startup (the class will be execute only once) and will be executed 0 ms after the
startup of the scheduler.
Other types of scheduling are:
- Period/number : the class will be executed every number
of ms after the startup
of the scheduler.
- Daily/HH:MM : the class will execute every day. The execution will be at time HH:MM.
- Weekly/DAY/HH:MM : the class will be executed every week. The execution will be at the day DAY and at the
time HH:MM. The DAY parameter can take one of these values: MO,TU,WE,TH,FR,SA,SU
- Monthly/DAY/HH:MM : the class will execute at day of the month DAY; this is a number
from 1 to 31 or the string lastday
if we want to declare the last day of the month.
The execution will be at time HH:MM.
- testing : a small description of the class.
- 1 : the unique id of the scheduled class. You have to add this number if the same class is added more times
in the scheduler (for example, with different schedule types).
If we want to schedule another class then we have to add at the end of the first the char @
example, if we want to add the class TestSCH
, of type period
we have to write:
must be declared if at least one schedule class has been set. The
directory defined in this parameter will be used for saving information of schedule execution.
are used if an error occurs during a schedule class execution. If
not set, then no error mail will be sent.
You can configure a file cleaner. The cleaner will delete old files in one or more directories
that have not been modified for a certain amount of days. You have to set the parameters file_cleaner
Also, you have to add the class that performs the cleanup in the scheduler:
Some other parameters are also exist but are facultative. You can find more info for this
parameters looking in the jfw.properties
Here is an example of a complete jfw.properties