| Java applications | ||
|---|---|---|
| Previous | Next | |
| Database repository | The web application runtime module | |
The server side components of iKnowBase are assembled as a single file
The main iKnowBase Java web modules, which may be enabled or disabled in the configuration, are:
See the module’s own chapter for details.
Jar plugins in the
./plugins directory (subdirectories are not scanned) are automatically included in the application.
War plugins (containing .jar files) must be extracted and the
extractedToDirectory/WEB-INF/lib must be added to
loader.path (see below). .
If you want to change or add more directories containing jar plugins, you may configure this using
loader.path in application.properties (recommended) or JVM option, or set
LOADER_PATH environment variable (use only one method).
loader.path JVM option or set
LOADER_PATH environment variable.
The
loader.path /
LOADER_PATH is a comma delimited list of jar files or directories containing jar files. Note that it does not support relative parent directory “../”.
First create the required directories, “plugins” to store the plugins, and “wars” to store the custom application (the output). Add all .jar/.war plugins and patches to the plugins directory:
mkdir /opt/iknowbase/production/plugins
mkdir /opt/iknowbase/production/wars
# Copy plugins, e.g. from /opt/my-plugins
# cp /my-plugins/*.jar /opt/iknowbase/production/plugins/
# cp /my-plugins/*.war /opt/iknowbase/production/plugins/
Next, create an instance-specific web application based on the original iKnowBase web application + all plugins. Always patch from the original application, as this ensures you know which plugins you’ve added at all times:
cd /opt/iknowbase/production
./iknowbase.sh assembleWar \
/opt/iknowbase/iknowbase-7.2.4/libs/iknowbase-boot-weblogic-7.2.4.war \
/opt/iknowbase/production/wars/iknowbase-boot-weblogic-7.2.4-custom.war \
/opt/iknowbase/production/plugins/*
Finally, deploy the newly created iKnowBase web application instead of the original web application.
For the iKnowBase web server, installation is quick and mostly automatic:
$ cd /opt/iknowbase/production
$ ./iknowbase.sh setIkbPassword orcladmin secretpassword
$ ./iknowbase.sh webServer
When the server has started, you should be able to navigate to a few interesting links:
For further configuration options, or if you want to install on an alternative application server, see the details for each of them:
During or after deployment, you need to configure security for the application (NOT the same as content security). Again, the configuration method will vary from application server to application server.
See Installation Guide > Web Application Security for details and examples.
In the default and recommended installation, the iKnowBase web application is deployed to “/”, so that you can access pages and components without an application-specific prefix. For compatibility reasons, the server will automatically also handle all requests to “/ikbViewer/*”, and redirect them to “/*”.
While it is technically possible to deploy to a different root (e.g. “/ikbViewer”), we do not recommend this. It brings no apparent benefit, but the user experience is negatively impacted. That said, should you choose to do so:
Note that the WebDAV service will not work when deployed to a context root other than “/”.
The iKnowBase application itself supports clustered deployment, but the “Instant” module does not. If you intend to use this modules in an otherwise clustered environment, it must be deployed to a standalone server instance with no clustering.
By default, iKnowBase runs with database persisted sessions. This means that session persistence / sticky sessions are not required. If you change the session configuration to memory sessions (Spring Session or native), you must use session persistence / sticky sessions.
You may configure the iKnowBase application to serve additional static resource locations, typically used for customer specific files (css, js, images).
Note: This was previously only available for the iKnowBase Web Server, but has now been extended to iKnowBase application regardless of deployment platform.
See options prefixed with
com.iknowbase.server.resource.custom in application.properies.SAMPLE for configuration details.
iKnowBase does not by default limit the size of files you may upload. If you want to set a max limit, use Spring Boot’s
multipart.* configuration options.
# Max file size (-1 = unlimited)
#multipart.max-file-size=-1
multipart.max-file-size=50MB
# Max total request size (-1 = unlimited)
#multipart.max-request-size=-1
multipart.max-request-size=100MB
iKnowBase uses Spring Session with database persistence by default. This means that the application itself handles all things related to sessions and does not
use the session features provided by the server platform.
All requests use this session setup, except requests for public static resources in /ressurs, /plugin-resources, or any custom-resources you have defined.
The advantages with this setup are
The disadvantages are
See the sub sections below for configuration details.
If for some reason you need to use native sessions provided by the application server, you may disable Spring Session by setting
com.iknowbase.spring.session.enabled=false
In native session mode, refer to documentation for Spring Boot and the application server for configuration options for sessions. All other sections in
this document regarding sessions describe configurations applicable for Spring Session.
By default, the iKnowBase separates session between different domains, so that a user that opens both http://www.example.com and http://intranet.example.com will have to log on to each of these sites. Technically, this is done by using different “session cookie domains” for the session cookie for each of these hosts.
Sometimes, it is desirable to share the session information between sites. To do that, configure the session cookie domain to be used by the server. It is important that this domain is the parent domain of the various hosts used, for example, to share the login session between http://www.example.com and http://intranett.example.com you must specify “example.com”; to share the login session between http://www.iknowbase.com and http://customers.iknowbase.com you must specify “iknowbase.com”.
com.iknowbase.spring.session.domainName=example.com
If you want to support more than one domain name at the same time, you can use a domain name expression instead of the static domainName value.
Example:
# Will match example.com for requests to www.example.com and intranett.example.com.
# Will match iknowbase.com for requests to www.iknowbase.com
# Will not match localhost and for localhost it will not override the cookie domain name either.
# Note: Double backslash is used in this regular expression configuration
com.iknowbase.spring.session.domainNamePattern=^.+?\\.(\\w+\\.[a-z]+)$
You must choose between
com.iknowbase.spring.session.domainName and
com.iknowbase.spring.session.domainNamePattern. Configuring both will result in startup error.
The iKnowBase application will use session cookie name
IKBSESSION. In case of session name collision you may change the session cookie name. Session cookie name can be set using:
...
com.iknowbase.spring.session.cookieName=JSESSIONID_CUSTOM_NAME
...
Default max session idle time is set to 2100 seconds / 35 minutes. This can be changed by setting:
com.iknowbase.spring.session.maxInactiveInterval=<NUMBER IF SECONDS>
You may encounter a session cookie collision if you deploy two iKnowBase applications on the same host on different ports or otherwise have additional applications
with the same cookie name running behind a load balancer.
As the host name is the same for both requests, the session cookie name will by default be valid for both requests. The session cookie is only valid on one server, which will result in a replaced session cookie and effective log out the authenticated user.
Resolve the issue by changing the session cookie name for one of the applications or use different hostnames for accessing the applications.
| Previous | Top | Next |
| Database repository | The web application runtime module |