Base OCF Reference Implementation Changes for OCF version 1.1 Changes for OCF version 1.1.1 Changes for OCF version 1.2 Configuration OpenCard Home
Let's now look at how the default properties loader works. The OpenCardPropertyFileLoader looks in the following places for property files (in the order given):
In case you wish to override a property that is already defined in the properties set you can do that by defining the property name name anew and adding an additional property with the name name.override that has the value true to your property file.
The following example will set the property OpenCard.property to the value new_value no matter what its value was before:
# Overriding a possibly already defined OpenCard property # with a new value OpenCard.property = new_value OpenCard.property.override = trueUsing the same properties strings as in the examples above, your properties file might look like this:
# Configuring the CardServiceRegistry OpenCard.services = com.ibm.opencard.service.MFCCardServiceFactory # Configuring the CardTerminalRegistry # The parameters after the class name are: # name, type, and address of the card terminal OpenCard.terminals = \ com.ibm.opencard.terminal.ibm5948.IBMCardTerminalFactory|IBM5948-1|IBM5948-B02|1 \ com.ibm.opencard.terminal.pcsc10.Pcsc10CardTerminalFactory # Configuring Tracing OpenCard.trace = opencard.core:6 opencard.opt:0 com.ibm.opencard:3 \ com.ibm.opencard.terminal.ibm5948.IBM5948CardTerminal:8 # Overriding OpenCard.property OpenCard.property = new_value OpenCard.property.override = trueback to top of page
You can configure the CardTerminalRegistry via the OpenCard.terminals property and the CardServiceRegistry via the OpenCard.services property.
The syntax of the property string for either property is as follows:
<record-0> <record-1> ... <record-N>where records are separated by white-space and each record consists of a class name and optional string parameters separated by a ``|'', i.e.,
class-name|param-1|param-2| ... |param-NThe following example illustrates how the property strings might look like:
Property name: Property string: OpenCard.services com.ibm.opencard.service.MFCCardServiceFactory OpenCard.terminals com.ibm.opencard.terminal.ibm5948.IBMCardTerminalFactory|IBM5948-1|IBM5948-B02|1 \ com.ibm.opencard.terminal.pcsc10.Pcsc10CardTerminalFactoryback to top of page
The utility class opencard.core.util.Tracer distinguishes the following trace levels:
package-prefix:trace-levelwhere package-prefix specifies the prefix of a package or class name and level specifies a number between 0 and 8 corresponding to the desired trace-level.
Example:
opencard.core:6 opencard.opt:0 com.ibm.opencard:3 \ com.ibm.opencard.terminal.ibm5948.IBM5948CardTerminal:8back to top of page
You can implement a different property loading mechanism that fits your purpose or platform better and have it replace the default mechanism. In order for your property loader to integrate with the FRAMEWORK, it must implement the interface
opencard.core.util.OpenCardConfigurationProvider.
You must tell the FRAMEWORK to use your class instead of the default loader. You do that via the following system property:
OpenCard.loaderClassName= fully-qualified_class_name
NOTE: Obviously, you must set this property prior to the OPENCARD properties loading mechanism being invoked, for instance via a command line flag of the JAVA interpreter or, if applicable, in the system-wide .properties file.
back to top of page