The description of the standard.conf parameters has been improved compared to previous releases and is a good source to understand its entries. But still you will find the real truth in the provided standard.conf file under XBUS_HOME/etc and in the configuration files for the repeatable tests under XBUS_HOME/test.

---

This section comprises some basic configuration of the xBus affecting things like tracelevels or timeouts.

Note that all entries of the Base section are pre-configured with good default values and usually must not be changed. The tables below describe all basic fields and their possible values.

global    required

chapter	section	key	example
Base	Trace	Level	Base_Trace_Level=3

Trace writes program-internal informations to the console or a file. Using this parameter, you can control how much information will be traced.

Currently levels 0 to 4 are supported.

• 4 = DEBUG: Intended only for the development phase or error diagnostic, really lots of information will be traced.
• 3 = INFO: Information which can be helpful during the test phase, e.g. begin and exit points of some important methods.
• 2 = WARN: Warnings in the presence of irregularities.
• 1 = ERROR: Only error messages will be written.
• 0 = ALWAYS: There are some trace entries which will be written always.

For productive operation, trace level 2 should be selected, to have only exceptional situations in the trace.

global    required

chapter	section	key	example
Base	Trace	Tracer	Base_Trace_Tracer=FileTrace

This entry allows to choose the target where the trace is written to:

• ConsoleTrace - trace will be written to the console
• FileTrace - trace will be written into a file (the following entry with the filename is required)

global    required

chapter	section	key	example
Base	Trace	MaxLength	Base_Trace_MaxLength=999999

This parameter sets the maximum length of a trace entry. Lines longer than the maximum value will be truncated.

global    optional

chapter	section	key	example
Base	Trace	Filename	Base_Trace_Filename=trace.log

This entry specifies the name of the file, where you want your traces to be written. It is required only for FileTrace.

Only the name of the file is needed, not the absolute path. The file is created relative to XBUS_HOME/log/.

global    optional

chapter	section	key	example
Base	Trace	MaxFileSize	Base_Trace_MaxFileSize=150000

This parameter sets the maximum length of a trace file. It is only necessary for the use of the trace file renamer. Whenever the trace file renamer is started, it will look for the trace file size. If its is more the specified value in bytes, the trace file is renamed by adding a timestamp. The next tracing will create a new trace file with the old name.

The following entries decribe the way of journaling. Whether a journal entry is written or not is ruled by system-specific configuration parameter.

global    required

chapter	section	key	example
Base	Journal	Implementation	Base_Journal_Implementation=DBJournal

This entry allows to choose the target where the journal is written to:

• DBJournal - The journal will be written into a database (some setup has to be done before).
• FileJournal - The journal will be written into a file named XBUS_HOME/log/journal_yyyymmdd.log

global    required

chapter	section	key	example
Base	Journal	MessageLength	Base_Journal_MessageLength=1024

This parameter defines the maximum number of bytes used for the request-message and the response-message. Messages longer than this maximum value will be truncated.

global    optional

chapter	section	key	example
Base	NotifyError	System1..n	Base_NotifyError_System1=ErrorMail Base_NotifyError_System2=ErrorLogFile

This parameter defines senders for error notification. The error notification happens, when a message cannot be processed and all retries have failed.

Typically a SMTPSender is specified to notify an administrator via email. But as a matter of principle all other senders could be used as well. Currently there is a technical limitation: The senders must not use transaction handling (cf. the respective tables in the chapter Technical Layer.

If no sender is specified, there is no error notification mechanism.

Note:

• Although this parameter is optional, it should not be ignored, because it is usually safer to be informed in time in case of an error.
• Each listed system must be defined with all necessary parameters from the System chapter.

global    optional

chapter	section	key	example
Base	NotifyError	MessageLength	Base_NotifyError_MessageLength=100

This parameter sets the maximum length of the message to send in the case of an error. Entries longer than the maximum value will be truncated.

The parameter is only necessary if at least one system for notifying errors was defined above.

global    required

chapter	section	key	example
Base	Receiver	WaitAfterError	Base_Receiver_WaitAfterError=5

This parameter will be used by all background receivers (except HTTPxxxReceiver). It specifies the time interval in seconds, how long the background receiver will wait before trying to process a message again in case of an error.

global    required

chapter	section	key	example
Base	FileReceiverThread MQReceiverThread POP3ReceiverThread HTTPReceiver	StopAfterErrors	Base_HTTPReceiver_StopAfterError=-1

Background receivers can be stopped after a specified amount of errors without a successful processing between them. -1 means this kind of background receiver will not be stopped automatically at all.

For more information about background services see here.

global    required

chapter	section	key	example
Base	FileReceiverThread MQReceiverThread POP3ReceiverThread	Timeout	Base_FileReceiverThread_Timeout=1

These background receivers use a polling mechanism to check wether a message is available. This is the global definition of the delay between the attempts in seconds.

Note This value may be overruled by a system-specific timeout.

global    optional

chapter	section	key	example
Base	ReceiverService	PreProcessor	Base_ReceiverService_PreProcessor=FolderPreparator
Base	ReceiverService	PreProcessor1..n	Base_ReceiverService_PreProcessor1=FolderPreparatorIn Base_ReceiverService_PreProcessor2=FolderPreparatorOut

The configured pre-processor(s) is(are) executed directly when the receiver service is started.
Using the PreProcessor notation without index number allows declaring just one pre-processor. This possibility is still in after the extension to multiple pre-processors for compatibility reasons.

global    optional

chapter	section	key	example
Base	System	AddressImplementation	Base_System_AddressImplementation=net.sf.xbus.Dealer

As explained on the Concepts page, most of the systems need some kind of address, where to read or write the data. Use this parameter to specify the name of a class, that enables an easy access to specific address information of your installation.

global    optional

chapter	section	key	example
Base	Variable	variable name	Base_Variable_BufferDir=$XBUS_HOME$/buffer

Variables allow defining repeated strings centrally, e.g. often used directory paths. As shown in the example the XBUS_HOME parameter my be used in variable values because it will be replaced prior to replace the variable within other terms.

global    optional

chapter	section	key	example
Base	DeletedMessageStore	Enabled	Base_DeletedMessageStore_Enabled=true

Setting this entry to true lets all deleted messages be written into the Deleted Message Store. If this entry doesn't exist or is set to false, the decision about using the Deleted Message Store can be made per system.

global    required

chapter	section	key	example
Base	DeletedMessageStore	Directory	Base_DeletedMessageStore_Directory=$XBUS_HOME$/log/DeletedMessages

Defines the directory, where the files with the deleted messages shall be written to.

global    optional

chapter	section	key	example
Base	XML	Encoding	Base_XML_Encoding=UTF-8

This entry stores the default encoding to be used for parsing and serializing all kinds of XML messages. If not set, the default UTF-8 is used.

global    optional

chapter	section	key	example
Base	XML	TransformerFactory	Base_XML_TransformerFactory=com.example.xml.CustomTransformerFactory

Used to provide a custom XML transformer factor. It sets the class name of the factory including the package name. The jar-file containing the TransformerFactory must be placed in XBUS_HOME/lib/runtime.