|
The Schema Object is one such method of control, allowing the application(s)
to register the different parts of applications with Expresso. These parts
could include database objects (dbobjects), controllers, jobs, and servlets.
These different parts are integrated into Expresso to allow better management
and services. Also, once integrated into the Expresso Framework, the schema
objects allow the various databases in one's application to be populated
(if necessary), various initial setups, and fine grained security to be
applied without giving up flexibility over the rest of the framework.
Every application (such as eContent, eForum, or your own application) has
one "schema" object. This Schema object tells Expresso what database objects, controllers, jobs and servlets are part of the application, so that Expresso
can automatically create the required database tables, populate them with
default values, and create default setup and configurations for the application
when it is first installed and initialized. The Schema object is also used
by Expresso to automatically enable management of the security for all
of the applications component objects.
Schema objects provide the configuration values that are automatically
created when the application is first integrated with the Expresso package
- that is to say when the package is initialized for the first time, with default values. An administrator of the Expresso package can then use the values to further
customize the application as he/she sees fit. The configuration values
range from requiring a certain directory path be available to the number
of seconds for timeout of a process. The configuration values are very
flexible and can be adapted to a wide breath of situations and environments.
The Configuration Manager allows further configuration of the Expresso
Framework as well as the applications that run under the framework. The
Configuration Manager achieves this by a set of XML files under the config
directory. In these configuration XML files, there are properties that
applies to the entire Expresso Framework, such as the underlying database,
and some that apply to certain applications. Using the Configuration Manager
in conjunction with the set of both Expresso Framework XML and application
XML files gives utmost flexibility in the day-to-day operations of the
framework.
Every application has access to the Configuration Manager (ConfigManager),
an object automatically initialized when Expresso starts up. This object
gives access to one or more sets of "properties" - typically
used for configuration information used by all applications running in
a particular context, such as the required information to connect to the
database server. Multiple "contexts" are supported by the database
manager to allow many different database contexts to be used at once, either
by one or a number of applications.
ConfigManager's first step on initialization is to read the expresso-config.xml file, and to create one or more "contexts" of configuration values. The Configuration Manager works by reading in the XML files at Expresso's startup. ConfigManager is a singleton object - that is, there is a single instance of ConfigManager running in any given Expresso application's virtual machine, even if several different db contexts and applications are installed. On startup, the Configuration Manager (expresso/core/misc/ConfigManager.java) will open and read the express-config.xml as well as any the application xml files. Furthermore, the ConfigManager will create one or more "contexts" of the configuration values. A context is a separate section in expresso-web.xml, and is typiclaly associated with a single database.The contexts are separate instances that a user can log into. Most of the configuration properties held by ConfigManager are therefore
specific to one context, although there are a few "system-wide"
configuration values available as well. Thus the ConfigManager holds both application specific and system-wide
configuration values, even though the application specific values grossly
outweighs the system-wide values.
Technically, ConfigManager uses the Struts digester class to read it's XML configuration
file. The Digester class was designed by the Struts folks to map XML to java
objects in a systematic fashion with pre-defined rules being applied along
the way. Any problems during this initialization process are logged to the standard
output of the servlet container - so if your system does not initialize
properly, or you see ConfigurationException errors when you attempt to
work with your application, examine the system output log. The Digester class provides logging through Log4J (another Apache package)
to a predefined logging area (usually a file). This logging provides both
record of transactions as well as a simpler debugging process. One of the advantages of Expresso, is Expresso is built upon other projects
to provide a best of breed solution.
Another advantage to the ConfigManager is the flexiblity of the class.
The ConfigManager supports "custom" configuration values, so you can use it's capabilities to read and maintain values that are specific to your particular application, eliminating the need to create a custom object to do this. This aleviates the need for the application developer to write any custom
code to read and parse the application's values. Furthermore, once the
application has been registered with the Expresso framework, the ConfigManager
is at the application's disposable.
ConfigManager then becomes available to all applications running in that
environment for them to request the value of any of it's configuration
settings - see the JavaDoc documentation for ConfigManager and the various
"Config" objects in the com.jcorporate.expresso.core.misc package
for details on what configuration values are available.
Every application also has access to Setup values, which are specific to
a particular context, but are further specific to one application - e.g.
eForum may use a different value for a particular Setup value than ePoll
does. These Setup values are both specific to the application and to the
context. For example, a setup value that would work for eContent (a content
management application built on Expresso) may or may not work for another
application such as ePoll (a polling application built on Expresso).
The Setup Values are parsed not by the ConfigManager, but the DBObject
class. These Setup values are maintained in the database, and are easily
editable through Expresso (as long as security permits). This makes for
on the fly changes to become effortless. Often used for global configuration
options for a particular application, they apply to all users of that application
in a particular context/database. eContent, for example, uses a Setup value
to tell it what server-side directory to use to store it's content in.
The values are available to any part of the package at runtime with a simple
method call to the Configuration Management object (ConfigManager), and
are automatically maintained in cache or read again as required.
Setup values are different from the values held by the ConfigManager in
several ways. They are more application-specific - e.g. there can be a
number of setup values that are only used by one particular application,
and another set of simiar values that are used by another application,
whereas ConfigManager's values are available to all applications. Setup
values can also be changed and re-read during execution, whereas ConfigManager's
values are only read during system startup. Setup values are stored in
the database for a particular context, and can be accesed via methods in
the "Setup" object in the com.jcorporate.expresso.services.dbobj
package.
Once Expresso is set up, you can use the Database Maintenance Servlet to
display and edit the list of configuration values. Setup Values can be
accessed from the Expresso Framework admin page (running on one's machine
of course). To view the Setup Values, click on the Setup in the left bar
to get a list of all currently installed setup values. After the Setup
Page finishes loading, click on Setup Values in the first table. Some uses
of Setup values are to hold the connection information for a SMTP server,
so that various Expresso functions can send emails automatically, and to
hold the preferences for the URL of the header of the standard frameset
used by Expresso - allowing easy customization to your own frame header
for your applications.
| Setup Code |
Description |
| AdminEmail |
Email address of Administrative / Support Contact. This value should be set
to the email address of a user who will receive support queries for the web site
being set up - it is used when building the "verify" email for email-based user
authentication. |
| AdminName |
Name of Administrative / Support Contact for Site webmaster. This is the
name to use for the email address specified above. |
| BaseDir |
Web Document Root Directory on Server. This should be set to the directory
of the root context of your web server. |
| CompanyName |
Name of Company - this value is also used for the "verify" email when
email-based user authentication is utilized. |
| ConnTimeOut |
Database Connection Timout Interval seconds - this is the number of seconds
that a database connection may be idle before it is considered "stale" and
returned to the connection pool. |
| ContextPath |
Context Path for Expresso - this is a very important setup value for all
other Express components to operate correctly. By default Expresso is installed
in the /components/expresso directory (relative to the root web directory), but
may be any other value depending on your installation. For Servlet API 2.2
installations, this is the Context Path for the application context of
Expresso. |
| DefaultGroup |
Default User Group for Self-registered users - this value supplies the code
of a security group. Users that use the self-register function of Expresso are
automatically made members of this group. |
| EmailValidateURL |
Full URL of Email Validation Servlet - this is the URL to use in the
user-authentication emails that are sent if this function is enabled. |
| HomePageURL |
Home Page URL - this is the URL included in the authentication email if
user-authentication via email is enabled. |
| HTTPServ |
Web Server Host Name - this is the system host name of the server hosting
this installation of Expresso. |
| LogLevel |
Level of detail in Log 0=min, 9=max - you may want to initially specify a
high level of detail (e.g. 9) and reduce the level once the system goes into
production. |
| MAILFrom |
Value for From field in Event E-Mails - this must be a valid email address
on the specified email server for outgoing event emails to be
operational. |
| MAILPassword |
Password for sending e-mail if required - if your email server requires a
username and password for outgoing emails the pasword must be specified
here. |
| MAILServer |
SMTP Server Name for sending E-Mails - the host name of the server hosting
your EMail server. Expresso uses this server for sending all of it's email
notifications and events. |
| MAILUserName |
User Name for sending e-mail if required - if the email server requires a
username and password this field specifies the username. |
| MaxConnections |
Maximum Number of allowed Database Connections - the connection pool will
throw an exception if more than this many connections are requested at any one
moment. This is useful if there is an external limit imposed on how many
connections to the database can be used - if there is no such limit, this value
should be set fairly high (e.g. 20 to 30 is reasonable). |
| MaxJobs |
Max Number of Server Jobs to run at once - this specifices the limit on the
number of JobHandler requests that will be processed in parallel. Specifying 1
indicates a single-threaded job queue. |
| RequireEmailValidate |
Require Email Validation for Account Activation - set to Y to enable to
email user-authentication process. |
| RestartServer |
Command Line to re-start Servlet Server - a command line on the server that
will re-initialize the servlet engine, used by the HealthCheck process if the
servlet engine fails (experimental) |
| ServletEvent |
Servlet Exceptions Trigger SYSERROR Event? - set this field to "Y" if you
wish to receive emails for any exceptions that users of Expresso or Expresso
applications encounter. A SYSERROR event will be triggerred, and the contents of
the email will include a full stack trace and other details of the error.
Setting of "N" will not email messages, and a setting of "E" will email all
exceptions *except* SecurityExceptions. |
| ServletPath |
Default path for Servlets - this is the prefix for servlets in Expresso, by
default /servlet. For Servlet 2.2API installations (such as J2EE) this is the
context path for the Expresso application. |
| ServletPort |
Port Number for Servlet Server - the HTTP port number to use for servlet
requests. Often the default of 80 if no port number is supplied in
URL's. |
| TempDir |
Temporary Directory - a temporary directory that Expresso can store files in
on the server. Should be an absolute path name ending with a "/". |
| TimerInterval |
Scan Job Queue and directories how often? - the Job Queue is scanned every
so many seconds for new job requests. |
Setup values take affect as soon as they are saved.
At a finer level of detail even than Setup values, which are application-specific,
Expresso also provides for the management of "User Preferences".
These are settings that are specific to a particular user, and may be used
for custom settings for that user - such as the presentation mode used
to display forum listings, for example.
For technical information about how to use configuration values, please
refer to the:
|
