jfw.properties
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
JFWLocale.
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
here).
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
The
db_resources_types 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:
db_resources_types=cp,ds,pcm.
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:
The
pcm_class_db3 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
cp_driver_db1. If we have another database resource of connection pool type, for example
db3, then for setting the driver we have to write
cp_driver_db3.
The values of parameters
cp_driver_ and
cp_url_
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_ and
cp_password_ 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
the
cp_isdebug_ parameter must be set to
true.
In
cp_max_connections_ 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.
In
cp_auto_commit_ we define the auto commit behavior for all the connections managed
by this connection pool.
In
cp_dbclean_maxtime_ 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
rolled back.
In
cp_dbclean_freq_ 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
StartupSCH 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
ScheduleBean.
- 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
@. For
example, if we want to add the class
TestSCH, of type
period
we have to write:
The
schedule_objects_path 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.
The
schedule_thread_admins_email,
schedule_thread_email_object and
schedule_thread_sender_email 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,
file_cleaner_paths,
file_name and
file_cleaner_age_days:
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: