Skip to content
This repository has been archived by the owner on Apr 15, 2021. It is now read-only.

Configuring Profiles

James E. Stark edited this page Jan 31, 2016 · 2 revisions

The profile configures the behaviour of the DomainModel and its associated DataStore. A profile configuration is loaded using a validating XML parser. The XML is validated against the XML schema stored in "Profile.xsd" in the resources.

A profile configuration file has the following tag structure:

profile

The profile tag functions as the root tag, enclosing the profile configuration. It consists of a name tag, an optional mutable tag, zero or more parameter tags, followed by one or more element tags.

name

The name tag contains the name of the profile and the associated DataStore. For a JPA based DataStore the name of the profile must match the name of the JPA unit as defined in persistence.xml for the associated database.

mutable

The mutable tag is a boolean value which determines if the associated DataStore is writable. If the value for the mutable tag is false then any attempt to get a transaction, or builder on the associated DataStore will cause the program to abort with an IllegalStateException. If it is not specified, then the mutable flag is assumed to be false.

parameter

Parameters for the JPA based DataStore are specified by the parameter tag. While parameter tags are intended to be used for providing the database connection details, any parameter recognized by the JPA implementation can be specified. All of the parameters will be passed to the JPA EntityManagerFactory when it is created.

The parameter tag has one required attribute:

  • name: The name of the parameter.

element

An element block defines the default configuration of the DataStore with respect to the specified Element class. The element block consists of an options generator tag followed by an optional implementation tag.

The element tag has one required attribute:

  • class: The fully qualified name of the element class. The specified class must be a subclass of Element.

generator

The generator tag contains the fully qualified name of the IdGenerator implementation class to be used for the element class specified in the enclosing element tag. IdGenerator implementations contain the algorithm used to determine the id number for a new element instance, prior to inserting it into the DataStore. All of the IdGenerator implementation are contained in the ca.uoguelph.socs.icc.edm.domain.datastore.idgenerator package. The IdGenerator implementations are listed in the following table.

Class Description
NullIdGenerator Assigns the value null to the id number
RandomIdGenerator Assigns a unique, 40 bit random value to the id number
SequentialIdGenerator Assigns a monotonically increasing sequential id number

The NullIdGenerator is intended to be used in cases where the database (or JPA implementation) will be assigning the id number. Using the NullIdGenerator in other situations will result in data loss or corruption.

Within the profile, the IdGenerator specifications are organized hierarchically. An IdGenerator implementation must be specified for the class Element, as that implementation acts as the default. Specifying an IdGenerator implementation for any other element class acts to override the default IdGenenerator for that class and its subclasses. One instance of the specified is shared among all of the subclasses of the element class specified in the enclosing element tag.

implementation

The implementation tag contains the fully qualified name of the default implementation class for the element. As the default implementation, the class specified here must be a subclass of the class specified in the enclosing element tag. For most of the Element interface classes the default implementation class is used when executing queries and creating new instances of the element. The classes: Element, Activity, SubActivity, and LogReference are exceptions and should not have default implementations specified. Since it is the root class, Element does not have a reasonable default implementation. Activity, SubActivity, and LogReference have their implementations determined by the value of the associated ActivityType, Activity and SubActivity respectively.

Clone this wiki locally