The boConfig.xml file (located at the root of every XEO Application) is the basic configuration file in a XEO Application.
The boConfig.xml file has a root element boConfig and then several child elements, each of them responsible for the configuration of different parts of the XEO Application.
Path to the directory where the XEO Packages (containing the XEO Models) are located (by default "bodef")
Example:
<definitiondir>.\bodef\</definitiondir>
Path to the directory where workplaces and profile definition files are located (by default "uidef\default")
Example:
<uidefinitiondir>.\uidef\default</uidefinitiondir>
The web context root of the application (it must also be configured in your Application Server as well, this value does not deploy the application in that address) - by default "/xeo".
Example:
<webcontextroot>/xeo</webcontextroot>
The encoding of the application - default is "UTF-8"
Example:
<encoding>UTF-8</encoding>
The deployment section configures the XEO Builder, it has several subconfigurations:
Example of a configuration:
<deployment> <class_dir>.\.build\classes\</class_dir> <src_dir>.\.build\src\</src_dir> <obj_dir>.\.build\bodef-deployment</obj_dir> <obj_compiler>C:/jdk1.6.0_14/bin/javac.exe</obj_compiler> <obj_templates>.\.templates</obj_templates> <obj_deployjspdir>.\.build\webresources\default\</obj_deployjspdir> <obj_moduleswebdir>.\base_lib\modules_web\</obj_moduleswebdir> <lib_dir>.\lib\</lib_dir> <tablespace>USERS</tablespace> </deployment>
_
This section allows to define the background workers (threads) available in the XEO Application (by default, only the FullText Indexer (Ebo_TextIndex) is active)
To know more about Background work, check the Threads and Schedules section.
Example:
<threads type="userThreads"> <thread interval="15000" ejb-name="ejb/boTextIndexAgent" name="boTextIndex Agent"/> </threads>
_
The datasources section, defines the implementation classes that are used in order to access the relational database.
Example (for Oracle connection):
<DataSources> <DataSource boql="true" name="DATA"> <Driver>netgest.bo.data.oracle.OracleDriver</Driver> <DML>jdbc/xeo</DML> <DDL>jdbc/xeo_nojta</DDL> </DataSource> <DataSource boql="true" name="SYS"> <Driver>netgest.bo.data.oracle.OracleDriver</Driver> <DML>jdbc/xeo_nojta</DML> <DDL>jdbc/xeo_nojta</DDL> </DataSource> </DataSources>
At the moment there are three driver implementations (MySQL, Oracle and SQL Server). XEO Studio will generate the approriate boConfig when you configure the database connection but the three driver implementations are as follows:
_
Configures the Logger for the XEO Application ( read more)
Configures the mail server to allow the XEO application to send mails. The mail configuration can include any number of properties (which you can access using XEO's API). The basic configuration is the following (the smpthost property is required to exists, although the values does not need to have a valid smtp server)
<mail> <smtphost>smtp.host.domain</smtphost> </mail>
If you have your own mail sending mechanism you can also use boConfig just to keep your configuration values. The boConfig.xml file is read and made available by a wrapper class (netgest.bo.system.boApplicationConfig) which can be accessed through class boApplication. The boApplicationConfig class has a method getMailConfig which returns a Properties instance. By default the only property will be "smtphost" but if you in the boconfig file you include additional elements, those elements will be transformed to properties, as follows:
<mail> <smtphost>smtp.host.domain</smtphost> <defaultuser>SUPERUSER</defaultuser> <serverPort>338</serverPort> <myVeryCustomConfiguration></myVeryCustomConfiguration> </mail>
If you used this configuration, when retrieving the Properties from the getMailConfig method you would have four properties (smtphost, defaultuser, serverPort and myVeryCustomConfiguration).
Not yet available in XEO
Enterprise Content Management (ECM) Repositories allow you to store documents, which can be used whithin a XEO Application (just like regular files). XEO supports Repositories which are compatible with the JCR 1.0 specification. You can configure several JCR repositories to be available in a XEO Application; to configure a single repository you use the following properties:
Repository Properties
Property Name | Type | Description | XML declaration | Notes |
---|---|---|---|---|
name | String | The repository identifier | name='JackRabbitXEO' | |
default | boolean | Whether this is the default repository or not | default = 'true' | If a repository is not specified when saving/reading, etc... the default repository is used |
classConnection | String | The fully qualified name of a class that implemets the netgest.io.jcr.ECMRepositoryConnection interface which is responsible for creating a JCR Session with the repository | classConnection='netgest.io.jcr.JackRabbitXEO' | |
showAllProperties | boolean | Whether the visual layer should try to display all properties of files/folders or only the ones declared in the File/Folder/Metadata nodes (see bellow) | showAllProperties='false' | |
repositoryConnection | XML element | Parameters to be passed to the connection class (see classConnection property) this is done automatically when instatianting the class. | <repositoryConnection> <parameters> <parameter name='foo' value='bar'> <parameter name='bar' value='foo'> </parameters> </repositoryConnection> |
System Properties
The system properties configuration allows you to declare which (if any) properties in JCR nodes are system specific and you don't to display them when using the visual components. You declare the system properties as follows (the example includes a real configuration for the JackRabbit repository):
<system> <!-- System Properties that we don't want to display in forms and etc.. --> <properties> <property name='jcr:createdBy'></property> <property name='jcr:uuid'></property> <property name='jcr:primaryType'></property> </properties> </system>
_
File Node Configuration
The file node configuration allows you to specify the nodes that will represent files (for the XEO Application) in the repository. You can specify:
Properties
You should configure the properties you want to have (or the ones the existing nodes already have) so that the implementation can correctly read/update the properties. The properties can be spread in the main node or child nodes.
Child Nodes
A File Node can have child nodes and have its properties stored in those file nodes (depending on the reposito
A sample XML configuration for the File Node when trying to use a default JackRabbit instalation
<fileNode type="nt:file" binaryProperty="jcr:data" createDate="jcr:created" updateDate='jcr:lastModified' mimeType="jcr:mimeType"> <properties> <property label='Create Date' name="jcr:created" type='attributeDate' mainNode='true'/> <property label='File' name='jcr:data' type='binary'></property> <property label='Encoding' name="jcr:encoding" type='attributeText' /> <property label='MimeType' name='jcr:mimeType' type='attributeText'></property> <property label='Date Update' name='jcr:lastModified' type='attributeDate'></property> </properties> <childNodes> <childNode name="jcr:content" type="nt:resource"> <properties> <property label='MimeType' name="jcr:mimeType" type="string"></property> <property label='Encoding' name="jcr:encoding" type="string"></property> <property label='File' name="jcr:data" type="binary"></property> <property label='Date Update' name="jcr:lastModified" type="date"></property> </properties> <childNode /> </childNodes> </fileNode>
And another when using a repository that has the nodes declared by default by the XEO framework
<fileNode type="xeo:file" binaryProperty="xeo:data" createDate="" updateDate="" mimeType=""> <properties> <property label='File' name='xeo:data' type='binary' mainNode='true'></property> </properties> <childNodes> </childNodes> </fileNode>
_
Folder Node Configuration
The file node configuration allows you to specify the nodes that will represent folders (for the XEO Application) in the repository. You can specify:
Like with FileNodes you should also declare the properties and the child nodes of a folder node. A sample XML configuration to use a default JackRabbit folder node in a XEO Application:
<folderNode type="nt:folder" createDate="jcr:created" updateDate="" childFilesType='nt:hierarchyNode'> <properties> <property label='Create Date' name="jcr:created" type='date' mainNode='true'/> </properties> <childNodes /> </folderNode>
And a configuration to XEO default folder nodes:
<folderNode type="xeo:folder" createDate="" updateDate="" childFilesType='xeo:hierarchyNode'> <properties /> <childNodes /> </folderNode>
Metadata Node Properties
You can also declare several different types of metadata nodes which can be associated to File and Folder Nodes. When declaring a metadata node you can define the following:
A sample XML configuration bellow (for XEO's default metadata nodes, JackRabbit by default does not provide such a node type):
<metadataNodes> <metadataNode type="xeo:metadata" name="metadata" canCreate="true" default="true"> <queryToReach>metadata/categories</queryToReach> <parent></parent> <properties /> <children /> </metadataNode> </metadataNodes>
_
Sample XML (for a complete configuration of one repository):
<?xml version="1.0" encoding="UTF-8"?> <ecmRepositories> <ecmRepository name='JackRabbitXEO' default='true' fileConnector='netgest.io.jcr.FileConnector' classConnection='netgest.io.jcr.JackRabbitXEOConnection' showAllProperties='false'> <repositoryConnection> <parameters> <parameter name='exampleParameter' value='bar'></parameter> </parameters> </repositoryConnection> <system> <!-- System Properties that we don't want to display in forms and etc.. --> <properties> <property name='jcr:createdBy'></property> <property name='jcr:uuid'></property> <property name='jcr:primaryType'></property> </properties> </system> <fileNode type="xeo:file" binaryProperty="xeo:data" createDate="" updateDate="" mimeType=""> <properties> <property label='File' name='xeo:data' type='binary' mainNode='true'></property> </properties> <childNodes> </childNodes> </fileNode> <folderNode type="xeo:folder" createDate="" updateDate="" childFilesType='xeo:hierarchyNode'> <properties> </properties> <childNodes /> </folderNode> <metadataNodes> <metadataNode type="xeo:metadata" name="metadata" canCreate="true" default="true"> <queryToReach>metadata/categories</queryToReach> <parent></parent> <properties> </properties> <children></children> </metadataNode> </metadataNodes> </ecmRepository> </ecmRepositories>
_
Repositories are used to represent data sources for the XEO application and are configured as following:
<Repositories> <Repository> <Name>default</Name> <UserName></UserName> <Password></Password> <DataSource>DATA</DataSource> <DataSourceDef>DATA</DataSourceDef> <Schema>_DATABASE_NAME_OR_SCHEMA</Schema> <Parent></Parent> </Repository> </Repositories>
The DATABASE_NAME_OR_SCHEMA value should be replaced with the name of the database (MySQL, SQLServer) used by the application, or the schema name (Oracle). Also, it's the only value you need to change.
The languages allows you to define the default language for the XEO Application and set the available languages for the application.
<languages> <ApplicationLanguage>PT</ApplicationLanguage> <availableLanguages> <language> <code>EN</code> <description>English</description> </language> <language> <code>PT</code> <description>Português</description> </language> </availableLanguages> </languages>
@Deprecated
@Deprecated
@Deprecated
When some modules are installed in a XEO Application, additional properties can be configured in boConfig: namely:
In order to configure the Content Management you'll need to define the XEO Models that used as Content and the XEO Models that are used as Images, like the following:
<Content_Manager> <Contents_Type>XEOCM_Contents;XEOAG_Contents;XEOCM_Noticias;XEOCM_Contents_Link;XEOCM_Document;XEOCM_Map</Contents_Type> <Images_Type>XEOCM_Image</Images_Type> </Content_Manager>
_
No permission to view TWiki.WebTopBar