Demo

Configuring AsyncFW

The AsyncFW framework uses an object based approached to application configuration. It based on the FWDirect model. While FWDirect allows you create your own customer classes to access via JavaScript, the AsyncFW configuration objects consist of two classes used by the server side framework for configuring Database connection pools and a number of environmental variables.

The Basics

Configuring AsyncFW is done with two properties files FWMaster.properties, and FWDefault.properties. Both of these files must exist in your project’s /src folder (the root of your classes folder).

*The above is a sample Eclipse project named JCounselor, and shows the properties files, and their proper location.

FWMaster.properties

AsyncFW uses a two tier configuration model. The FWMaster.properties is the top level parent properties file, and it must be named exactly as shown. All other properties files, are defined within the FWMaster, you may have many child properties files, but only one FWMaster.properties.

The FWMaster.properties files is used to define three things;

1) Identifies all child Properties files

2) Identifies the current Environment

3) List replacement values for each environment

Sample FWMaster.properties;

*Note: Lines starting with the ‘#’ (pound) character are comments. Comments are included for informational purposes only.

file.property.1 = /FWDefault.properties

#file.property.2 = /YourCustomProps.properties

Environment = dev

#Environment = test

#Environment = prod

#Replacement parm in properties file will be @LogName@

#Replacement parm in properties file will be @FormsDB@

#Replacement parm in properties file will be @ApplicationDB@

replace.dev.LogName = Framework_dev

replace.dev.LogFileName = Framework_log

replace.dev.FormsDB = jdbc/FWConPool

replace.dev.ApplicationDB = jdbc/FWConPool

replace.test.LogName = Framework_test

replace.test.LogFileName = Framework_log

replace.test.FormsDB = jdbc/JCounselorForm

replace.test.ApplicationDB = jdbc/JCounselor

replace.prod.LogName = Framework_prod

replace.prod.LogFileName = Framework_log

replace.prod.FormsDB = jdbc/JCounselorForm

replace.prod.ApplicationDB = jdbc/JCounselor

file.property.n(1-99) tags are used to identify child properties files. Each tag name ends with a sequence number and is equated to the actual file name in your classes root directory.

file.property.1 = /FWDefault.properties

#file.property.2 = /YourCustomProps.properties

Environment = dev

#Environment = test

#Environment = prod

#Replacement parm in properties file will be @LogName@

#Replacement parm in properties file will be @FormsDB@

#Replacement parm in properties file will be @ApplicationDB@

Environment tag. The FWMaster.properties file may only contain one Environment tag, this tag is used to identify the current environment. This tag is handy for developers working in multiple environments (Development, test and production for example). It allows you to switch environments by simply changing this one tag. The Environment can also be used to support multiple applications – you can configure as many environments as you want.

replace.dev.LogName = Framework_dev

replace.dev.LogFileName = Framework_log

replace.dev.FormsDB = jdbc/FWConPool

replace.dev.ApplicationDB = jdbc/FWConPool

replace.test.LogName = Framework_test

replace.test.LogFileName = Framework_log

replace.test.FormsDB = jdbc/JCounselorForm

replace.test.ApplicationDB = jdbc/JCounselor

replace.prod.LogName = Framework_prod

replace.prod.LogFileName = Framework_log

replace.prod.FormsDB = jdbc/JCounselorForm

replace.prod.ApplicationDB = jdbc/JCounselor

Replacement tags. The replacement tags are always take the following three part form;

replace.environment.userdefined. The first part is always ‘replace’, the second part identifies the environment and must match the defined Environment tag, or it is ignored. The third part is defined by you.

How Replacement works:

First, it should be said that ‘Replacement’ is optional. You may choose to simply hardcode all properties settings within your child properties files. However, this makes deployment, or testing with multiple environments more challenging. I suggest using ‘replacement’, it will simplify your life in the future.

The third portion of the tag can be any meaningful string name. When AsyncFW loads the FWMaster.properties, it will also load all the child properties files. It will then take the third portion of the replace tag, and do a search and replace on child properties files for every occurrence of the specified string starting and ending with the ‘@’ character. The replacement value is the value assigned to the corresponding ‘replace’ tag.

Referring to the diagram above, you can see that the replace.dev.FormsDB tag is assigned the value jdbc/JCounselorForm in the FWMaster.properties file. The child property file(s) is then searched for all occurrences of the ‘@FormDB@’ string, if any are found, they are replaced with the value ‘jdbc/JCounselorForm’.

*NOTE: The above assumes that the Environment tag is set to ‘dev’.

FWMaster Conclusion

The FWMaster.properties file is required, and must be named as shown. It performs very little actual configuration, but provides a level of abstraction from your actual properties when the Environment tag is used.

Configuring Database references in the Web.xml

While you may have many Environments, and many databases configured in your properties files, those databases will not be available to your application (FWAdmin or your custom applications) until you include a reference in the applications Web.xml. The format is as follows;

(copy and past example)

<resource-ref>

<res-ref-name>jdbc/FWConPool</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-auth>Container</res-auth>

<res-sharing-scope>Shareable</res-sharing-scope>

</resource-ref>

The above is the default JNDI connection pool resource that comes preconfigured for FWAdmin, and in the sample Properties files which you may have downloaded. If you are content to continue to use this database, simply add the above to all your AsyncFW project’s web.xml file.

You can add as many database references as you need to the web.xml file.

Properties Internals

The AsyncFW framework uses Static Object based properties. This means that the properties above are available to your AsyncFW applications via getters and setters. For some background, or to create your own Properties Object Model outside of AsyncFW, please read this tutorial.

The AsyncFW Object Properties model, is somewhat more sophisticated than the model described in the generic tutorial above. In fact you can add your own configuration classes as needed.

Let’s look at the FWDefualt.properties file; You will notice that there are a number of lines that start with class.* these are class references that will be created at startup. For example;

class.com.FW.properties.EnvProps

class.com.FW.properties.DBProps

NOTE: both of the classes shown are part of the AsyncFW distribution, however that is not a requirement.

When the properties are loaded, the entries starting with class.* will be instantiated as objects and the assigned name is used as a reference. Let’s look at the EnvProps references a bit closer;

class.com.FW.properties.EnvProps = EnvProps

EvnProps.setAdmin = admin

EnvProps.setAdminPass = asyncFW

EnvProps.setValidatedTimeout = 25

EnvProps.setCometTimeout = 8

The above properties entries tell the AsyncFW framework to create an instance of the EnvProps object and to execute each of the ‘Set’ statements with the supplied values.

Since both the EnvProps and the DBProps classes are part of the AsyncFW framework, they are assumed to be static and are available for use by your application.

int intTimeOut = EnvProps.getCometTimeout();

String strFormDBName = DBProps.getFormDataBase();

S. Chappell