1. General
The appNG Manager is an appNG application to configure and maintain the appNG platform and its installed applications. The manager is a mandatory privileged application of appNG. After installation of appNG, a site manager is available with an installed manager application. By default, the manager is available on localhost at
The application has different pages to configure and monitor the appNG platform:
Page | Description |
---|---|
Sites |
Manage sites and applications of a site |
Applications |
Manage applications and templates; edit application resources |
Users |
Manage users, groups and role assignments |
Repositories |
Manage application repositories and install applications |
Platform |
Configure platform properties and manage database connections. |
System |
Monitor the system-, environment- and cluster status. View logfile and edit log configuration. |
2. Sites
An appNG site is a representation of a domain. An appNG installation can have several sites. Each site can have a different template, different configuration of some appNG platform features and a different set of appNG applications. The same appNG application can be installed in multiple sites with a different configuration.
2.1. Site Overview
The main page of the manager application lists all available sites. Among other things it shows if a site is active and running and the time when the site was started. It also provides a list of actions per site.
2.1.1. Reloading a site
In the list of available sites, each site has a list of actions. One of the actions is reload
. Click this link to reload a site.
If the site has been running, it is shut down. Afterwards, all site properties and site application properties are newly initialized with the active values from the database. Furthermore, all applications activated for the site, including their resources, are loaded and initialized. If necessary, schema migrations are applied to the application databases.
If a running site is configured to be inactive, reload the site to shut it down. Since it is configured to not be active, it will not be restarted.
2.1.2. Deleting a site
In the list of available sites, each site has a list of actions. One of the actions is delete
. Click this link to delete a site. This action has to be confirmed to avoid deletion by mistake.
When a site gets deleted, all information such as site attributes, site properties, application properties and application databases are removed. It is not possible to restore any of the deleted data. If you are not sure whether a site is needed in the future configure it to be inactive. |
2.2. Creating a site
A fresh default installation of appNG provides only the initially configured site manager. To create a new site, click on the link create site above or below the list of sites on the main page.
By clicking this link, a new form opens where the attributes of the new site have to be defined:
Attribute Name | Description |
---|---|
Name |
The name of the site. It must be unique per appNG platform and is used in the appNG url scheme. |
Host |
In simple setups, this value is identical with the domain. In more complex use scenarios it could be necessary that a site should be available from different domains. In such a case, the webserver of your choice has to map domains to host-values and set the request attribute |
Domain |
The DNS name incl. the protocol (http or https), as it will be used by the client. The value of this field is used to generate absolute URLs, where required. |
Description |
Some additional information about the site. |
active |
If a site is active, it is automatically started on appNG start-up. |
Create folder for JSP-contents |
Instructs appNG to create a folder in the local file system, where static resources and JSP files can be stored and processed. |
Template |
A site must have a template. On a fresh installation, the appNG default template is installed. Other templates can be installed on the platform. The template of choice can be configured per site. |
After the site has been created, a new item is visible in the list of available sites. The site is listed as active if it was created as active site. The site is not running.
To start the created site, it has to be configured as an active site and then it has to be reloaded. If the site is configured to be active, it will also be started automatically during the next platform start-up.
2.3. Editing a site
In the list of available sites, each site has a list of actions. One of the actions is edit
. Click this link to open the edit page of that site.
This page is partitioned in sections. The first section is similar to the form to create a site. Besides the site name, all attributes can be changed in that form. The other sections are described further down. Changes will be taken into account after a site reload.
A site reload is always necessary if a site attribute, site property, site application property or an application resource has been changed. |
If appNG runs in a cluster setup, the site reload is executed first on the node where the action has been executed. If the site has been successfully reloaded, a cluster event is sent by this node to all the other nodes in the cluster to also reload that site.
In a cluster setup with non-sticky sessions it might happen, that the next request after triggering the site reload will be processed by another node, where the site reload event was not yet received or where the site reload is ongoing. |
2.4. Configuring site properties
In addition to the site attributes, there are a lot of site properties. With site properties it is possible to disable, enable and configure site-specific appNG features. To change site properties, go to the edit page of a site. The page is partitioned in sections. The section to maintain the site properties has the name Site properties
.
As long as a property value has not been changed for a site, appNG uses the Default-Value
. In this case both fields Value
and Multilined value
are empty.
To update a property, enter a value in either the Value
or Multiline value
field. Note that it is not possible to save the property if both fields are filled. appNG will use the content of the Value
or the Multilined value
field, if it is not empty. After updating a property, a site reload is required.
A site property has the following attributes:
Attribute Name | Description |
---|---|
Name |
The name of the property. |
Active Value |
As described in Reloading a site, a property update will be only taken into account after a site reload. This attribute shows the value of the property after the next site reload. |
Default Value |
The default value defined by the platform on site creation. |
Multiline Value |
A normal value has a limited length of 255 characters. If a bigger value is needed, it must be defined in the |
Description |
A short description of the property |
Changed Value |
Is shown in the list of properties. Indicates if a value has been changed for that site (yellow) or if it still uses the platform default (green). |
If a property was changed and it shall use the default again it is necessary to empty the field value. It is also possible to copy just the default value as value. This will have the same effect, but the property would still be shown as changed value. |
A site can be configured using an manageable amount of properties. These can be roughly divided into the following categories:
-
Backend
Configures the management backend itself -
Caching
Configures caching using Ehcache -
Content
Properties for configuring content delivery from a site’s repository -
Indexing/Searching
Configures Lucene indexing and searching features -
UI
Affects the behavior of the management user interface
After changing site properties, you must perform a site reload to apply these changes. |
A detailed list of the available properties can be found here:
Name | Type | Category | Description | Default |
---|---|---|---|---|
xssExceptions |
multilined text |
Backend |
URL path prefixes where XSS protection is omitted. Contains one prefix per line. Supports blank lines and comments (#). |
|
appendTabId |
boolean |
UI |
If set to |
|
assetsDir |
text |
Content |
A semicolon-separated list of folder-names (relative to |
|
authApplication |
text |
Backend |
The name of the application which is responsible for the authentication |
|
authLoginPage |
text |
Backend |
The names of the login-pages (comma-separated) within the application defined in |
|
authLoginRef |
text |
Backend |
The action names (comma-separated) for the pages defined in |
|
authLogoutActionName |
text |
Backend |
The name for the parameter defining the action on the |
|
authLogoutActionValue |
text |
Backend |
The value for the parameter defining the action on the |
|
authLogoutPage |
text |
Backend |
The name of the logout-page within the application defined in |
|
authLogoutRef |
text |
Backend |
The reference-path for the logout-action |
|
cacheEnabled |
boolean |
Caching |
Set to |
|
cacheExceptions |
multiline text |
Caching |
URL path prefixes which are never cached. Contains one prefix per line (multiline value). |
|
cacheStatistics |
boolean |
Caching |
Set to |
|
cacheTimeToLive |
int |
Caching |
The default TTL for a cache entry in seconds, if there’s no matching path defined in |
|
cacheTimeouts |
multiline text |
Caching |
The cache timeouts as a multiline property, key=value |
|
cacheTimeoutsAntStyle |
boolean |
Caching |
Use Ant-style path matching for |
|
cacheClearOnShutdown |
boolean |
Caching |
Whether or not the Ehcache is cleared on a site shutdown/reload |
|
csrfProtectionEnabled |
boolean |
Backend |
Set to |
|
csrfProtectedMethods |
text |
Backend |
a comma-separated list of HTTP-methods to enable CSRF protection for (see |
|
csrfProtectedPaths |
text |
Backend |
a comma-separated list of path-prefixes to enable CSRF protection for (see |
|
DatasourceConfigurer |
text |
Backend |
The fully qualified name of a class implementing |
|
defaultPage |
text |
Content |
The name of the default-page (without extension) relative to one of the directories defined in |
|
defaultPageSize |
int |
UI |
The default page size (items per page) |
|
defaultApplication |
text |
Backend |
The application to be called after a successful login |
|
documentDir |
text |
Content |
A semicolon-separated list of folder-names (relative to |
|
encoding |
text |
Content |
The encoding for file-resources |
|
enforcePrimaryDomain |
boolean |
Backend |
Set to |
|
errorPage |
text |
Content |
The name of the default error-page (without extension) relative to |
|
errorPages |
text |
Content |
The name of the error-page per document-directory (see |
|
host |
text |
Backend |
The host of the site. For convenience only, do not change! |
The host of the site |
indexConfig |
text |
Indexing |
For each directory defined in |
|
indexDir |
text |
Indexing |
The folder containing the Lucene-Index, relative to |
|
indexFileSystemQueueSize |
int |
Indexing |
the queue size used per directory when indexing the file system |
|
indexFileTypes |
text |
Indexing |
A list of comma-separated file-extensions (without leading dot) which are being indexed |
|
indexQueueSize |
int |
Indexing |
The queue size used for document indexing |
|
indexTimeout |
int |
Indexing |
The timeout in milliseconds for indexing |
|
ldapDomain |
text |
Backend |
The Netbios Domain name to use, when "SAM" is used as principal scheme |
|
ldapGroupBaseDn |
text |
Backend |
The base-DN for LDAP-groups |
|
ldapHost |
text |
Backend |
The LDAP host in provider URL format ( |
|
ldapIdAttribute |
text |
Backend |
The name of the LDAP-attribute containing the user-id used for authentication |
|
ldapPassword |
text |
Backend |
Password of the LDAP service-user |
|
ldapPrincipalScheme |
text |
Backend |
How the LDAP principal is built from a given username when logging in: “DN”, “UPN” or “SAM”. (See LDAP connectivity for details.) |
SAM |
ldapStartTls |
boolean |
Backend |
Use STARTTLS for the LDAP connection. If you set this to |
|
ldapUser |
text |
Backend |
The name of the LDAP service-user for general LDAP lookups. If the value is a Distinguished Name (e.g. “cn=Service User,dc=mycompany,dc=com”) it will be used directly as LDAP principal. Otherwise the principal will be derived according to the value specified in |
|
ldapUserBaseDn |
text |
Backend |
The base-DN which is used to map a plain username to a Distinguished Name, if "DN" is used as principal scheme (see property |
|
locale |
text |
UI |
The default locale for the site. Use one of |
|
mailDisabled |
boolean |
Backend |
Set to |
|
mailHost |
text |
Backend |
The mail-host to use |
|
mailPort |
int |
Backend |
The mail-port to use |
|
manager-path |
text |
UI |
The path-suffix for the appNG-Webapplication |
|
name |
text |
Backend |
The name of the site. For convenience only, do not change! |
|
rewriteConfig |
text |
Content |
the location of the rewrite rules for UrlRewriteFilter (http://tuckey.org/urlrewrite), relative to |
|
searchChunkSize |
int |
Content |
The chunksize (items per page) for the search-tag |
|
searchMaxHits |
int |
Content |
The maximum number of hits for the search-tag |
|
serviceOutputFormat |
text |
Backend |
The output format to be used when actions/datasources are being called through service URLs |
|
serviceOutputType |
text |
Backend |
The output type to be used when actions/datasources are being called through service URLs |
|
service-path |
text |
Backend |
The path-suffix for the services offered by appNG (such as Webservices, SOAP, Actions, Datasources) |
|
siteRootDir |
text |
Backend |
The absolute path to the site’s root-directory |
|
supportedLanguages |
text |
Backend |
A comma-separated list of the languages supported by the site |
|
supportReloadFile |
boolean |
Backend |
If |
|
tagPrefix |
text |
Content |
The prefix used for the appNG JSP-tags. |
|
template |
text |
Backend |
The name of the template to use |
|
timeZone |
text |
UI |
The default timezone for the site. Use one of |
|
wwwDir |
text |
Content |
The name of the folder containing the web-contents, relative to |
|
2.5. Managing applications of a site
2.5.1. Assigning applications to a site
To assign a new application to a site, it first has to be installed on the platform. For installing applications on appNG read [Installing applications] in chapter Repositories in this manual.
To assign an application to a site, go to the edit page of a site. In the section Applications
a list of all available applications is shown. For each application not yet assigned to that site an action Activate
is available. By clicking this action the application gets activated for that site. On activation, appNG creates a database connection for the application for that site if the application requires a database. AppNG also clones the application properties into site application properties.
Once the activation is finished, the application appears as active in the list, but the column Requires Reload
shows, that the application is not started in the respective site. Finally the site has to be reloaded to start the application. This can be done directly by the reload site
link on top of the table.
If the application provides a role marked as admin role, it is automatically assigned to the group Administrators
in appNG. If not, the administrator of the platform has to care about assigning application roles to appropriate groups. In most cases there will be a kind of admin role which should be assigned to the group Administrators
. Other roles maybe have to be assigned to other groups but that depends on the application and the kind of groups created on the platform. Read more about that in the chapter Users and groups in this manual.
After assigning the role, the application will not be visible immediately because appNG processes the permissions for a user only during login. After logging out and in again, the menu entry for that new assigned application should be visible in the menu of the respective site.
2.5.2. Deactivating applications of a site
To unassign an application from a site, go to the edit page of a site. In the section Applications
a list of all available applications is shown. For each application assigned to that site an action Deactivate
is available. By clicking this action the application is deassigned for that site.
When an application is deassigned, all information such as application properties and the application database are deleted. It is not possible to restore any of the deleted data. |
2.5.3. Grant access to other sites
Without any additional configuration, a site cannot access an application in another site. In most cases this is not desired anyway. But if an application provides functionality to be used in different sites it is necessary to grant access to the application for that consuming site.
On the edit page of the site in section Applications
a list of all available applications is shown. Applications assigned to that site provide an action named Grant
. By clicking this link, a form appears where other sites can be selected to be granted the right to call this application in this site.
2.5.4. Configuring the applications of a site
An appNG application can provide properties to configure the application. Each site has its own application properties. Thus it is possible to run the same application with different configurations in different sites.
The site-specific application properties are similar to the site properties - they have the same attributes. Site-specific application properties also have the concept of a Default-Value
. As long as the value is not updated for that site, the property will always have the application’s default value.
In contrast to site properties, the default value of site-specific application properties can be implicitly changed when updating the application.
If a new version of an application changes the default value of a property, this new default value is also applied to the respective site application property in all sites, unless this property is a multilined value. |
Multilined values are treated differently. They do not have a default value. When assigning an application to a site, the multilined value is copied into the site’s application property. When the application gets updated with a new multilined value, the multilined values in site’s application will stay untouched.
Changes to the site-specific application properties will be taken into account after next site reload. |
2.6. Managing database connections
If an application needs a database, a new appNG database connection is created for each associated application of a site. If an application has been activated in multiple sites, multiple database connections (one in each site) have been created. The different application instances are thus independent of each other, each accessing their own database.
If the database server is managed by appNG, a database and a site- and application-specific user will be created automatically in the database server. If the database server is not managed by appNG, database and user have to be manually created in the database server and configured at the database connection in appNG.
The edit site page has a section to manage the Database connections
for the applications assigned to this site. A database connection has the following attributes:
Attribute Name | Description | Example |
---|---|---|
Type |
The type of the database. |
MYSQL |
Name |
The name of the database. This is generated and consists of the prefix |
|
JDBC-URL |
The JDBC url used to connect to the database. |
|
User-Name |
The name of the user used to connect to the database. This name is generated on database creation and is composed of site id and application id. |
|
Password |
A random password generated on database creation. |
|
Driver-Class |
The name of the |
|
Min. number of connections |
appNG uses connection pooling to avoid the overhead by opening and closing JDBC connections. This value defines the minimum number of connections in the pool. Default value is |
|
Max. number of connections |
This value defines the maximum number of open JDBC connections in that pool. Default value is |
|
Validation query |
appNG checks if a database is properly connected. Therefore it needs to execute a query. Default for mysql databases is |
|
Description |
The Administrator can add some more information about the connection. Per default it contains again the site and application name. |
manager - testapp |
If the database server is not managed by appNG, the JDBC connection has to be configured manually. Above examples for the name schema of |
This section of the appNG Manager also contains a folded form with an input field to |
2.7. Managing the site’s status
2.7.1. Caching
appNG provides integrated caching with Ehcache. Per default, the caching is disabled. The caching can be enabled per site. To enable caching, set the site property (see Configuring site properties) ehcacheEnabled
to true
. The site’s status section contains the cache statistics. It lists the following information:
Information | Description | Example |
---|---|---|
Average get time |
The average get time in seconds. Because Ehcache uses |
0.008894 |
Hits |
The number of times a requested item was found in the cache. |
1711886 |
Misses |
The number of times a requested element was not found in the cache. |
65480 |
Name |
The name of the cache. It is the prefix |
pageCache-manager |
Size |
This number is the actual number of elements in the cache, including expired elements that have not yet been removed. |
5866 |
Statistics accuracy |
Accurately measuring statistics can be expensive. appNG uses the setting for best effort and acceptable accuracy |
BEST_EFFORT |
Status |
The status of the cache. Can be one of |
STATUS_ALIVE |
This section also offers a link to clear the cache statistics. Maybe useful if cache settings have been changed. |
There is also a table where all elements in the cache are listed with their id (which is the request method plus the URL path), the type of response, size and some other useful information. It offers also two actions per item: to delete it from the cache or to view the item.
The cache is only based on protocol and URL path. That means that resources generated by appNG applications, which will not change often, may also be cached.
At the bottom of the item list is an action to clean the entire cache for that site. |
Cache exceptions as URL path prefixes can be maintained as multilined value in the site property |
2.7.2. Sessions
The status section contains a table listing all active sessions for that site. Each entry provides an action to manually expire the session immediately, unless it is the session of the current user.
If appNG runs in a cluster environment, it depends on the cluster setup whether the table shows only sessions of the current node or, if a central session store has been configured, of all nodes.
This table might be useful to check if there are authenticated users in a site before restarting it. For authenticated users their user-name appears in the respective column.
On the bottom of the table an action is available to expire all sessions, except the current user session, immediately.
3. Applications
The page Applications
shows the list of all installed applications. Each application in that list offers the two actions Edit
and Delete
.
3.1. Editing an application
Besides the three switches Privileged Application
, Hidden
and filebased
all information about an application is stored within the XML files of the application package. If something has been changed through the appNG manager, it might be overwritten by the next application update.
We advise to update information of the application within the application package source files to avoid that important changes are overwritten after application updates. |
This feature provides powerful possibilities to modify an installed application, which is useful for quickly testing small changes without deploying a new version of the application.
3.1.1. Update Application
In this section some of the main application attributes can be viewed and updated. The most important switches are at the bottom of the form:
Name | Description |
---|---|
Privileged Application |
A privileged application has elevated access rights in the appNG platform. This is for instance necessary if an application is designed to provide the authentication service for a site. |
Hidden |
An hidden application is not listed in the application menu of the site. It will still appear in the list of assigned application on the edit page of the site. This is useful if an application has no user interface. |
filebased |
If appNG runs as single instance, it does not matter whether the application resources are stored in the file system or in the database. But in a cluster scenario, it is necessary, that all resources of an application are stored in the database. All cluster nodes are connected to the same database so they will all use the same application resources. |
If the |
After toggling the |
Installing applications in |
3.1.2. Application Properties
This section shows all application properties which have been read from the application.xml
file during application installation.
An application property offers the method Edit
. It opens a form where the fields value
and Multilined value
can be changed. But this does not have any effect on properties of assigned applications nor does it have any effect on the site-specific application properties to be created on assignment.
An application property can be deleted. This does not have any effect on site-specific application properties of assigned application, but the deleted property will not be created as site application property when an application gets assigned to a site.
An application property can be created with an unique name. The given value will be set as the default value of the property. This new property will not be added to the list of site-specific application properties of already assigned applications, but it will be created as site-specific application property for upcoming application assignments.
Default values of existing application properties cannot be changed, but the property can be removed and created with the same name. This will affect only site-specific application properties of applications, which are assigned afterwards and will not affect the existing ones. |
During an application update, all properties which are part of the application.xml
of the new application package are overwritten. Existing application properties in appNG, with no counterpart in the application.xml
file, will stay untouched.
3.1.3. Roles
appNG has a fine-grained role and permission model. A permission is the right to see or do something. A role is a set of permissions. An appNG group aggregates roles, and groups can be assigned to appNG users.
Permissions and roles are defined in the application.xml
file of an application. The aggregation of permissions and roles can be modified within the appNG manager, but general changes should be done in the application.xml
file and changed by an application update.
The Roles
page shows the list of all available roles of that application. A role can be edited or deleted and a new role can be created.
Edit Role
By clicking the edit action of a role, a form opens where the user can change the name and description of a role as well as the assignment of permissions to that role. This change takes effect after next login. It will not take immediate effect for currently authenticated users.
Removed permissions of a role are re-assigned during the next application update, if the role still has that permission in the |
Delete Role
By clicking the delete action in the application roles overview, a role can be deleted. This change takes effect after the next login. It will not take immediate effect for currently authenticated users.
A deleted role will be created again on package update, if the deleted role is still part of the |
If the roles shipped together with the application do not meet your requirements, create your own roles. They will not be modified during an application update. See Create Role. |
Create Role
By clicking the action Create role
below or above the overview table, a form opens to define the name and description of the new role. It also gives the possibility to assign permissions to that new role.
A created role will stay untouched on application updates as long as the new application.xml
file of the application package does not contain a (new) role with the same name. Otherwise, the role is updated as described above.
3.1.4. Permissions
A permission is the right to see or do something. Permissions can be applied to a lot of elements like actions, datasources, pages, linkpanels and fields. Furthermore, application developers can test a permission programmatically.
A permission must be used either in the source XML (which describes the structure of the application and the user interface), or in the application source code, to have any effect. We suggest to not change the permissions of an application, unless an application developer advised you to do so.
3.1.5. Resources
This section lists all available resources which have been installed along with the package. The list can be filtered by type:
Name | Description |
---|---|
BEANS_XML |
|
JAR |
JAR files ( |
XML |
XML sources ( |
XSL |
XSL stylesheets ( |
SQL |
SQL scripts ( |
TPL |
custom (non-XSL) template resources |
RESOURCE |
custom resources, such as .js, .css, .jpg, .png |
DICTIONARY |
dictionaries ( |
APPLICATION |
|
ASSET |
Not supported yet |
The path statements describe the location of the files, relative to the application package respectively the application root folder.
Each element in the list can be deleted, even if this would lead to a situation where the application cannot startup anymore. All text files can be edited, which is useful during rapid prototyping. Furthermore, this function may be handy to apply a quick-fix. However, this should be the exemption, since the regular development workflow is omitted. New Resources can be uploaded. E.g. another dictionary file can be added to support another language.
All resources are removed and re-created on application update. That means, all changes applied to the resources and all additionally created resources are gone after the application update. If application resources have been edited or added, and if you want to keep these changes, make sure the new application contains the changes or the new resources. |
3.2. Deleting an application
The application overview provides an action per application to delete the application. After confirming to delete the application, the following actions are executed:
-
remove the application assignment from inactive sites
-
delete roles
-
delete permissions
-
delete resources
-
delete properties
An application assigned to an active site cannot be removed. |
4. Templates
Templates can be installed on or removed from the appNG platform. It is not possible to edit or change the contents of an installed template package. A site chooses the template to be used for all applications of that site in the edit site form.
5. Users and groups
appNG features a fine-grained user role and permission model. The key elements are:
Element | Description |
---|---|
permission |
The right to see or do something. Permissions are defined by the application in the |
role |
An aggregation of permissions of one application. Roles are defined in the |
group |
An aggregation of roles, also from different applications. Created and defined in the appNG manager. On installation the group |
user |
An account in appNG. Could be a pure appNG-local user or a user from an LDAP repository or Active Directory. A user can have multiple groups. In default installations, the user |
Permissions are added to a user by assigning groups to users and roles to groups and permissions to roles. The assignment has always a contributing nature. It will not happen that an assignment will remove the permission set by another assignment. The user will always have the super-set of all permissions of all groups and roles assigned to him.
The users page shows a list of all configured users.
5.1. LDAP connectivity
If the type LDAP user
or LDAP Group
is used, authentication will use an external LDAP server.
In case of LDAP user
the username is mapped to an LDAP principal and a simple bind is done against the LDAP server. The user is authenticated, if the bind succeeds. Note that the configured LDAP user
name and the one entered in the login mask, are the same, when using LDAP user
.
In case of LDAP Group
the configured name is interpreted as an LDAP group, which is resolved to the actual usernames. This comprises three steps:
-
The username entered in the login mask is used to bind in the same way as described for
LDAP user
above. -
The configured
LDAP Group
name is mapped to members by looking up themember
attributes of the objectcn=<name>,ldapGroupBaseDn
. This step makes use of the service credentials configured vialdapUser
andldapPassword
, to execute the lookup. -
The username entered in the login mask must be present in the
ldapIdAttribute
of at least one member object, found in the previous step, in order to be successful.
How usernames are mapped to ldap principals depends on the value of ldapPrincipalScheme
:
-
“DN” : results in
ldapIdAttribute=<username>,ldapUserBaseDn
-
“UPN”: results in
<username>@ldapDomain
-
“SAM”: results in
ldapDomain\<username>
The schemes “UPN” and “SAM” are Windows AD specific (see MSDN on supported authentication methods in AD). The default value is “SAM” to remain backward compatibility with older appNG versions
Property | Description | Example |
---|---|---|
|
The Netbios Domain name to use, when "SAM" is used as principal scheme |
|
|
The base-DN for LDAP-groups |
|
|
The LDAP host in provider URL format ( |
|
|
The name of the LDAP-attribute containing the user-id used for authentication |
|
|
Password of the LDAP service-user |
|
|
How the LDAP principal is built from a given username when logging in: “DN”, “UPN” or “SAM” as described above. |
SAM |
|
Use STARTTLS for the LDAP connection. If you set this to |
|
|
The name of the LDAP service-user for general LDAP lookups. If the value is a Distinguished Name (e.g. “cn=Service User,dc=mycompany,dc=com”) it will be used directly as LDAP principal. Otherwise the principal will be derived according to the value specified in |
|
|
The base-DN which is used to map a plain username to a Distinguished Name, if "DN" is used as principal scheme. |
|
Read more about site properties in Configuring site properties in this manual.
5.2. Users
5.2.1. Creating a user
Above and below the users list a link with the action to create a user is displayed. When clicking this link a new form opens, where the user attributes can be defined:
Attribute | Description | Example |
---|---|---|
Name |
User name as used for the login. Must be unique. |
|
Real Name |
The person’s real name |
|
E-Mail address of the person |
|
|
Description |
Some additional info about the user |
|
Type |
One of |
|
Language |
The preferred language of the user. Shows available appNG languages. |
|
Timezone |
The users timezone |
|
Password |
Must have at least 6 chars and max 64 chars |
|
Password Confirmation |
Must contain the same value as the |
|
Groups |
Select initial groups of the user |
|
5.3. Groups
On the page Users
there is another section Groups
. It lists all available groups configured in appNG. On appNG installation, the group Administrators is created. This is special group because if an application defines an admin-role in the application.xml
file, this role is automatically assigned to this group. It is also not possible to delete this group.
The overview table provides actions to create, edit and delete groups.
5.3.1. Creating a group
When clicking the Create group
action on top or bottom of the table, a new form opens where the attributes of the group can be defined:
Attribute | Description |
---|---|
Name |
Name of the group. Must be unique. |
Description |
Some additional info about the group. |
Roles |
Select roles from different applications to assign them to the group. Only roles of those applications are available which are assigned to the current site. |
6. Platform
The page Platform
contains all elements regarding the installed appNG platform.
6.1. Configuring the platform
The first section of the page Platform
lists the platform properties. A platform property can be created, deleted and edited.
Platform properties are created during the first (initial) startup of the platform. The default values are defined within the appNG platform. The default value may be overwritten during a platform update.
As long as the value or the multilined value of a property is not defined, appNG uses the default value.
6.2. Platform properties
The appNG platform can be configured by a manageable amount of properties.
When changing platform properties, appNG (means: Tomcat) needs to be restarted to apply those changes. |
A detailed list of the available properties can be found here:
Name | Type | Category | Description | Default |
---|---|---|---|---|
xssProtect |
boolean |
Security |
Set to |
|
applicationDir |
text |
Backend |
The folder used for installing file-based-applications, relative to the webapp-root |
|
rootPath |
text |
Backend |
The absolute root-path of the platform |
determined during installation |
cacheApplicationFolder |
text |
Caching |
The folder for the application-cache, relative to |
|
cacheFolder |
text |
Caching |
The cache folder, relative to |
|
cacheImageFolder |
text |
Caching |
The folder used for caching images, within the application-cache |
|
cachePlatformFolder |
text |
Caching |
The folder for the cache, relative to |
|
csrfFilterEnabled |
boolean |
Security |
Set to true to enable a filter preventing CSRF-attacks |
|
databasePrefix |
text |
Database |
The prefix to use when generating database names (in case |
empty |
databaseValidationPeriod |
text |
Database |
The idle database connection test period in minutes. If a database connection remains idle for the specified time, the validation query defined in the database connection will be sent to prevent a database connection timeout. |
|
defaultTemplate |
text |
UI |
The name of the default template to use (must be a folder located under |
|
devMode |
boolean |
Backend |
Disable for production use. If enabled, XML and XSL resources will be written to the cache directory. If disabled, XML and XSL resources will be cached in memory. |
|
ehcacheConfig |
text |
Caching |
The global page cache configuration using the Ehcache XML configuration format. This cache is used to cache HTTP responses. |
|
encoding |
text |
UI |
The charset/encoding used for http-responses. |
|
filebasedDeployment |
boolean |
Backend |
Set to |
|
formatOutput |
boolean |
UI |
Disable for production use. If enabled, debugging is easier, but Textarea values are formatted wrong. |
|
imageMagickPath |
text |
Backend |
The path to the ImageMagick executable |
|
jspFileType |
text |
Backend |
The file-extension for JSP-files. |
|
locale |
text |
UI |
The default locale for the site. Use one of |
|
logfile |
text |
Backend |
The name of the logfile generated by appNG |
|
mailDisabled |
boolean |
Backend |
Set to |
|
mailHost |
text |
Backend |
The mail-host to use |
|
mailPort |
text |
Backend |
The mail-port to use |
|
manageDatabases |
boolean |
Database |
If set to |
|
maxUploadSize |
text |
Backend |
The maximum size for file uploads in bytes |
|
mdcEnabled |
boolean |
Backend |
Set to |
|
messagingEnabled |
boolean |
Clustering |
Set to |
|
messagingReceiver |
text |
Clustering |
Define messaging implementation by referring class name. |
|
messagingGroupAddress |
text |
Clustering |
The multicast address used for messaging |
|
messagingGroupPort |
text |
Clustering |
The port used for multicast messaging |
|
monitorPerformance |
boolean |
Backend |
Set to |
|
passwordPolicyErrorMessageKey |
text |
Security |
The resource-bundle key (for messages-core) for the message which is being displayed when the password does not match the policy. |
|
passwordPolicyRegEx |
text |
Security |
A regular expression describing the password-policy |
|
repositoryPath |
text |
Backend |
The folder used for the content repositories of the site, relative to the webapp-root |
|
repositoryDefaultDigest |
text |
Security |
The default digest for a published local application repository |
empty |
repositoryCert |
text |
Security |
The certificate to use when verifying a signed remote application repository (PEM format) |
empty |
repositorySignature |
text |
Security |
The private key to use when signing a local published application repository (PEM format) |
empty |
repositoryTrustStore |
text |
Security |
The truststore used when verifying a signed remote application repository, using file-protocol. If empty, the default |
empty |
repositoryTrustStorePassword |
text |
Security |
The truststore’s password |
empty |
repositoryVerifySignature |
boolean |
Security |
When set to |
|
sessionTimeout |
text |
The timeout for a user session in seconds |
|
|
sharedSecret |
text |
Security |
The shared secret used for digest authentication |
none, generated during installation |
templateFolder |
text |
Backend |
The folder used for templates, relative to the webapp-root |
|
templatePrefix |
text |
Backend |
The path under which the resources of the active template are beeing served. |
|
timeZone |
text |
UI |
The default timezone for the site. Use one of |
|
uploadDir |
text |
Backend |
The folder for saving uploads, relative to the webapp-root |
|
vHostMode |
text |
Backend |
Defines whether the server is identified by its IP ( |
|
writeDebugFiles |
boolean |
Backend |
When set to |
|
xssAllowedTags |
text |
Security |
A list of additionally allowed HTML Tags, separated by |, optionally followed by a space-separated list of allowed attributes. Example: |
|
6.2.1. Edit platform property
Each property in the list of platform properties offers an action to edit it. By clicking this action a new form opens where the value or the multilined value of a property can be changed. Note that it is not possible to save the property if both fields are filled.
If the value or multilined value is defined, appNG will use this new value after a platform reload. Empty the value or multilined value field if appNG should use the default again.
6.2.2. Create platform property
On top and bottom of the table an action to create a platform property is displayed. The new property has to have an unique name. The given value will be used as default value. Creating a property can be used to activate and configure features for appNG not available in the default configuration. Properties can also be used as feature toggles to activate and configure new features during appNG platform development.
6.3. Reloading the platform
On top and bottom of the table an action to reload the platform is displayed. This action reinitializes the platform configuration and reloads all sites without restarting the whole Tomcat instance.
6.4. Managing the platform’s database connection
appNG stores all its configuration data like platform properties, sites, applications properties, site properties, site-specific application properties and also entire application resources in a database. The database is a fundamental component of each appNG installation.
The platform page has a section to manage the database connection. appNG currently supports three different kinds of database servers. Database connections are pre-configured for those database servers. Only one of them is active after a default installation.
Supported database servers are:
-
MYSQL
-
MSSQL
-
HSQL
HSQL is used for executing integration tests and for the appNG standalone version. For production use we recommend to use either MySQL or MSSQL.
6.4.1. Editing a database connection
This section allows to modify the existing database connections. It is not supported to delete or create database connections. To edit a database connection click on the table row or the edit action within a row. A new form opens where the database connection attributes can be maintained:
Attribute Name | Description | Example |
---|---|---|
Type |
The type of the database. |
MYSQL |
Name |
The name of the database. |
|
JDBC-URL |
The JDBC url used to connect to the database. |
|
User-Name |
The name of the user used to connect to the database. |
|
Password |
The password used to authenticate the database user. |
|
Driver-Class |
The name of the |
|
managed |
Flag to indicate whether the database is managed by appNG or not. If the database is not managed by appNG, a database administrator has to take care of creating databases for the platform as well as for applications requesting a database. |
|
active |
Flag to indicate whether this connection can be used by appNG. |
|
Min. number of connections |
appNG uses connection pooling to avoid the overhead by opening and closing JDBC connections. This value defines the minimum number of connections in the pool. Default value is |
|
Max. number of connections |
This value defines the maximum number of open JDBC connections in that pool. Default value is |
|
Validation query |
appNG checks if the database is properly connected. Therefore it needs to execute a query. Default for mysql databases is |
|
Description |
The Administrator can add some more information about the connection. |
appNG Root Database |
appNG can use database connections to different types of database servers at the same time. TODO: Explain, example, order of supported databases in application.xml
|
6.5. JAR-Files
The section JAR-Files
lists all Java archive files of the platform and JAR files which are provided by the Tomcat runtime environment. File name, version, title and vendor are displayed. This is useful to verify the version of the used libraries. It also helps to include library versions in bug reports. The information displayed here is read from the META-INF/MANIFEST.MF
of the respective library. If information is missing for a certain library, its MANIFEST.MF
is probably not well-maintained.
6.6. Events
There are certain events that occur within the appNG platform that are written to an event log. This event log can be shown, filtered and exported.
Events that are recorded include:
-
starting/stopping the platform
-
starting/stopping a site
-
assigning/removing an application to/from a site
-
user log-in and log-out, session expiration
-
creating/dropping databases
-
creating/modifing any of appNG’s core components
(sites, applications, users, groups, roles, permissions, resources and database connections)
A platform event has the following attributes:
Attribute Name | Description | Example |
---|---|---|
Created |
The date and time when the event occurred. |
|
Type |
The type of the event. One of |
|
Event |
A text describing the event. |
|
Application |
The application that triggered the event. One of |
|
Context |
The context the event was executed in, depending on the application that triggered the event. |
|
User |
The user that triggered the event. This is either a user that was signed in at the appNG Manager, |
|
Host |
The remote host or IP that triggered the event. May contain an IPv4 or IPv6 address or a host name. |
|
Host name |
The local host name of the appNG server where the event was triggered at. |
|
Request |
A universally unique identifier (UUID) for the request that triggered the event. Multiple events can be triggered by the same request. |
|
Session |
The first 8 characters of the HTTP session, if applicable (only the case when triggered by |
|
7. Repositories
appNG applications are installed from a repository. A repository can be a local folder where application packages can be copied to or uploaded into. A repository also implements some SOAP services to provide its applications to other appNG installations as a remote repository.
7.1. Creating a repository
On page Repository
a list of all available repositories is shown. On top and bottom of that list is a link to create a repository. By clicking this link, a new form opens where the repository attributes can be defined:
Attribute Name | Description | Example |
---|---|---|
Name |
Name of the repository. |
|
Description |
Some additional information about the repository. |
Local repository |
Type |
Type of the repository. One of |
|
URI |
Address of the repository. An URL of a remote repository (prefix: |
|
active |
Indicates if this repository is active |
|
7.2. Editing a repository
Each repository in the list offers an action to edit the repository configuration. In addition to the above mentioned attributes, further attributes appear depending on the chosen repository type.
7.2.1. Local Repository
Attribute Name | Description |
---|---|
Mode |
The repository can offer only snapshots, stables or both kinds of builds. |
Published |
Activate this checkbox if the repository shall be published as remote repository to other appNG instances. The SOAP provider service will be available under the URL |
Digest |
If this is a published repository, a digest for authentication (shared secret) can be defined to make sure only authorized appNG instances can use it as a remote repository. The digest is optional. |
7.2.2. Remote Repository
Attribute Name | Description |
---|---|
Name of remote repository |
Multiple repositories can be published under the same URL. Entering the name of the remote repository is required and identifies the repository in the remote appNG instance to be accessed. |
Digest |
The digest to authenticate against the remote repository. If the remote repository grants anonymous access, this field can be left empty. |
Upload trusted certificate |
Upload the certificate used to verify the contents of the remote repository. |
7.3. Deleting a repository
Each item in the list of repositories offers an action to delete the respective repository. After confirming the deletion, the configuration of that repository is removed from the appNG database. It does not remove any files in the local file system nor does it remove any applications installed from this repository.
7.4. Reloading a repository
When the page is rendered, the current list of available applications and their versions are read from the file system or retrieved via a SOAP request from the remote repository. This information is cached by the system to avoid unnecessary overhead. By clicking the action reload
, this cache is refreshed with the current data.
7.5. Listing the applications of a repository
Each item in the list of repositories offers an action Installation
. By clicking this action, a new section opens, showing a list of all available applications in that repository. It informs about the latest stable release and about the latest snapshot build. It also shows the currently installed version.
Depending on the installed version, each entry offers a set of actions:
Action | Description |
---|---|
Show application versions |
By clicking this action a table is shown with all versions of that application available in the repository. Each version in this list can be selected to be installed on the platform. It is also possible to downgrade an installed application, but this is technically only possible if no database schema migrations have been applied between the actual and the old version. |
Install latest release |
This action can be executed if the latest release is not equal to the currently installed release or if the currently installed version is a snapshot. By clicking this link, the latest release version of the application from the repository will be installed. |
Install latest snapshot |
This action can be executed if there is a snapshot build available of an application and if the currently installed version is not equal to this latest snapshot version. By clicking this link, the latest snapshot build of the application will be installed from the repository. |
As defined above, the |
Even if an application has been updated, the currently running instance in the site will still be the old one. To finally activate the newly installed application all sites where the application is assigned to needs to be restarted. |
7.6. Uploading applications
There are two ways to add an application version to a repository. By copying it into the file system folder of the local repository or by uploading the application.
Copying the application to the local file system folder does not automatically refresh the repository cache, although appNG should detect the new file. If it is not listed immediately, reloading the repository should help. |
Application packages can only be uploaded to local repositories. The upload form is placed above the list of available application versions of that repository. An application package (*.zip
file) can be selected from the local machine to be uploaded to the local repository.
After uploading the file, the repository cache is automatically refreshed and the application can be installed.
8. System
This page shows information about the runtime environment of the appNG platform.
8.1. Environment
8.2. Status
The Status section displays some information about the system status.
8.2.1. Processor
Shows the system load average for the last minute and the number of processors available to the Java virtual machine.
8.3. Logfile
Shows a tail view of the appNG logfile from the current node. If appNG runs in a cluster setup be aware that there are other logfiles on other nodes.
It also shows the current log4j configuration in an editable text field. Changes to the log configuration can be submitted. This will update the current log4j configuration immediately without a platform reload. It is optionally possible to propagate this configuration to all other nodes in the cluster.
8.4. Cluster Status
This section displays the status of all other nodes in the cluster. A status entry consists of:
Status Item | Description | |
---|---|---|
The cluster status is directly requested from the other nodes in the cluster. This timestamp shows when the data of the respective node has been retrieved. |
Memory status |
The current memory usage of the heap of the respective node that is used for object allocation. |
Node ID |
Node id defined as system property |
Last Updated |
Each entry can be enlarged to show also:
-
List and status of all sites of that node.
-
System properties of that node as shown in the Environment page of that node.
-
System Environment of that node as shown in the Environment page of that node.
9. Jobs
The appNG manager ships with three scheduled jobs.
They all have something to do with platform-events.
9.1. Database Report Job
Purpose:
This job collects all platform events containg 'jdbc:' in their message that occurred in the last hour/day/week/month, puts them into an Excel-file and sends
this file via e-mail to all users that own the role 'Database report receiver'.
Enabled by default: No.
Configuration
This job can be configured using the following application properties:
-
databaseReportReceivers
A semicolon separted list of receviers, additional to all users with role 'Database report receiver'.
Default:<none>
-
databaseReportSender
The sender for the database report email.
Default:report@example.com
-
databaseReportSubject
The subject for the database report email.
Default:appNG database report
-
databaseReportText
The text for the database report email.
Default:See attached file for a report of the database related platform events.
Additionally, the entry interval
in the job’s jobDataMap
can be used to set the time unit for the report (one of HOUR
, DAY
, WEEK
, MONTH
, defaults to DAY
).
9.2. Log Database Size Job
Purpose:
This job writes a platform event for each active and working database connection, may it be a global one or of a site’s application.
An entry looks like this:
Size of MYSQL database for site 'appng' located at 'jdbc:mysql://localhost:3306/my_app' is 16.44MB
Enabled by default: Yes.
Scheduled at: 0 0 1 1/1 * ? *
(every night at 1:00 am)
9.3. Platform Event Report Job
Purpose:
This job collects all platform events of certain types that occurred in the last hour/day/week/month, puts them into an Excel-file and sends
this file via e-mail to all users that own the role 'Event report receiver'.
Enabled by default: No.
Configuration
This job can be configured using the following application properties:
-
eventReportReceivers
A semicolon separted list of receviers, additional to all users with role 'Event report receiver'.
Default:<none>
-
eventReportSender
The sender for the event report email.
Ddefault:report@example.com
-
eventReportSubject
The subject for the event report email.
Default:appNG event report
-
eventReportText
The text for the event report email.
Default:See attached file for a report of the recent appNG platform events
-
eventReportTypes
The event types to be included in the even report email, separeted by space.
Default:CREATE UPDATE DELETE INFO ERROR WARN
Additionally, the entry interval
in the job’s jobDataMap
can be used to set the time unit for the report (one of HOUR
, DAY
, WEEK
, MONTH
, defaults to DAY
).