making web application programming easier is possible



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:
  1. cp : for setting a connection pool.
  2. ds : for setting a datasource.
  3. 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.
  1. com.jfw.examples.StartupSCH : the class to execute. Must extend the class ScheduleBean.
  2. 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:
    1. Period/number : the class will be executed every number of ms after the startup of the scheduler.
    2. Daily/HH:MM : the class will execute every day. The execution will be at time HH:MM.
    3. 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
    4. 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.
  3. testing : a small description of the class.
  4. 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: