Admin’s Corner is the documentation area for developers and administrators.

System Requirements for Server Operation

Domain
A registered domain is required for a production server, while a resolvable hostname is sufficient in an intranet environment. On a developer machine, localhost is adequate.
Jakarta EE Platform 10
The JavaComm Server runs on any Jakarta EE Platform 10.
Jakarta EE Web Profile 10
TThe JavaComm Server runs on any Jakarta EE Web Profile 10 platform, provided the required EE 10 extensions are available. We use Tomcat 10.1.44 as the reference server.
MariaDB
The SQL database manages global data and stores the system state. We use MariaDB 10.5.29 as the reference database.

Domain

The domain is managed by the domain provider or by the web hosting provider. The domain can be assigned an IP address through the management interface.

Alternatively, a domain can be connected to the Internet via a third-party provider. With FreeDNS, a domain can be assigned an IP address. To do this, the nameservers of FreeDNS must be entered at the domain provider. A DNS synchronization then takes place. After a few hours, the domain is globally accessible.

Tomcat

Tomcat is a servlet container and uses only the Jakarta EE 10 APIs that are required for the application. The server remains lean and efficient. The APIs are extracted into the Tomcat directory.

${CATALINA_HOME}/lib

The database driver must also be located in this directory. After a restart of Tomcat all extensions are active.

A certificate for domain validation is required to encrypt the data. Numerous certificate authorities issue DV certificates. We recommend Let’s Encrypt. You can obtain a certificate directly from Let's Encrypt or through your web hosting provider. Afterwards, the programs openssl and keytool are used to import the certificate into Tomcat’s keystore.

openssl pkcs12 -export -in merge.crt -inkey private.key -out letsencrypt_2025_11_03.p12
keytool -changealias -alias 1 -destalias asterix -keystore letsencrypt_2025_11_03.p12 -storepass obelix

  • merge.crt is a text file created by you that contains your Public Key as well as the certificate chain from Let’s Encrypt or another Certificate Authority (CA). The certificate chain is usually provided in a text file named bundle. In merge.crt, the order is: first the Public Key, then the certificate chain.

    ";
  • private.key is a text file that contains the Private Key of your certificate.

  • letsencrypt_2025_11_03.p12 is a keystore that is newly created with exactly one certificate. When the certificate expires, the keystore is discarded and a new one is created with the current certificate.

After importing with openssl, the certificate received a numeric alias. keytool changed this to a descriptive alias name. The alias was changed from 1 to asterix, and letsencrypt_2025_11_03.p12 was assigned the password obelix. Afterwards, letsencrypt_2025_11_03.p12 is copied to the following location:

${CATALINA_HOME}/conf/letsencrypt_2025_11_03.p12

In the final step, letsencrypt_2025_11_03.p12 must be specified in

/conf/server.xml ,

and port 443 must be configured for HTTPS. Tomcat can then start the server application, and encryption will be active.

<!-- Ein Auszug aus der Tomcat server.xml --> <Connector port="443" defaultSSLHostConfigName="mydomain.net" protocol="org.apache.coyote.http11.Http11Nio2Protocol" sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementation" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" compression="on"> <SSLHostConfig hostName="mydomain.net" sslProtocol="TLSv1.3" certificateVerification="none"> <Certificate certificateKeyAlias="asterix" certificateKeystoreFile="${CATALINA_HOME}/conf/letsencrypt_2025_11_03.p12" certificateKeystorePassword="obelix"> </Certificate> </SSLHostConfig> </Connector>

Logging

Logging can become a real issue if too much information is recorded. Web services are based on HTTP, and all requests to a server are automatically logged. Tomcat is no exception.

Excessive logging or requests containing a user ID can be suppressed using a log filter. For this purpose, the class net.javacomm.server.LogFilter was developed. This class defines a URL pattern that prevents logging for certain resources. The pattern should be adjusted according to specific requirements. By default, all URLs for screen sharing are suppressed to avoid excessively large log files.

Tomcat registers the class net.javacomm.server.LogFilter via the web.xml of javacommserver.war. If LogFilter detects a pattern from <filter-mapping>, it notifies the configuration of AccessLogValve in server.xml, so that logging is suppressed accordingly.

<!-- A snippet of web.xml in javacommserver.war --> <filter> <filter-name>LogFilter</filter-name> <filter-class>net.javacomm.server.LogFilter</filter-class> </filter> <filter-mapping> <filter-name>LogFilter</filter-name> <url-pattern>/screenshot/*</url-pattern> <url-pattern>/videokonferenz/*</url-pattern> </filter-mapping>

AccessLogValve must be extended in server.xml with the conditionUnless attribute. The value block comes from class net.javacomm.server.LogFilter.

<!-- A snippet of ${CATALINA_HOME}/conf/server.xml --> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b" conditionUnless="block" />

MariaDB

The server tables for administrative functions are managed via SQL scripts and the admin GUI. The admin GUI is part of the JavaComm client and is enabled only for users marked as program administrators in the TB_USER table. Program administrators cannot be created through the GUI; creation and removal are handled exclusively by a database administrator using SQL or a database management tool. DBeaver is highly suitable for this purpose. DBeaver is available as a desktop application or as an Eclipse plugin.

To set up the database and tables, a general script exists that is executed via the MariaDB client in batch mode.

Before executing the master script runolymp.cmd, the entries in the individual scripts should be checked and adapted to your specific requirements. The master script is idempotent. Users who do not wish to use MariaDB must consider three points:

  1. A suitable JDBC database driver must be copied to the Tomcat directory:

    /lib

  2. Some data types in the file olymp_tables_10_11_4.sql must be replaced with equivalents for the target database.
  3. Some SQL commands may need to be adjusted. The SQL commands are referenced by a unique key in the file sqlmapper.xml , which is located in the source code archive at:

    javacomm/javacommserver/src/main/resources/net/javacomm/database/sqlmapper

Tip:
All database commands are logged with their key in the file:

${CATALINA_HOME}/logs/javacommserver/database.log

before execution. If a command could not be executed, the log file contains the corresponding entry with the error cause.

Database and Email Configuration in Tomcat

The configuration of database and e-mail access credentials is performed through the context.xml file. This file is not distributed and is only accessible locally on the server. Tomcat requires the credentials in plain text in order to establish connections to the database and the mail server. Encrypting the file would not provide additional protection, as the decryption key would also need to be available locally.

Databases are fully accessible to administrators and are frequently replicated and backed up. For this reason, storing the credentials in context.xml is technically appropriate and follows common industry standards for Tomcat applications.

The file is located in the source code archive at:

javacomm/javacommserver/src/main/webapp/META-INF/context.xml

<!-- context.xml --> <?xml version="1.0" encoding="UTF-8"?> <Context path="/javacommserver" reloadable="true" > <Resource name="jdbc/olymp" auth="Container" type="javax.sql.DataSource" factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" testWhileIdle="true" testOnBorrow="true" testOnReturn="false" validationQuery="SELECT 1" validationInterval="30000" timeBetweenEvictionRunsMillis="30000" maxActive="100" minIdle="10" maxWait="10000" initialSize="10" removeAbandonedTimeout="60" removeAbandoned="true" logAbandoned="true" minEvictableIdleTimeMillis="30000" jmxEnabled="false" jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState; org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer" username="hades" password="persephone" driverClassName="org.mariadb.jdbc.Driver" url="jdbc:mariadb://localhost:3306/olymp"/> <Resource name="mail/portal" auth="Container" type="jakarta.mail.Session" mail.smtp.starttls.enable="true" mail.smtp.starttls.required="true" mail.smtp.auth="true" mail.smtp.ssl.enable="false" mail.smtp.ssl.checkserveridentity="false" mail.smtp.connectiontimeout="5000" /> <Environment name="adminmail" value="admin@domain.net" type="java.lang.String" /> <Environment name="mail.smtp.password" value="super_secret" type="java.lang.String" /> <Environment name="mail.smtp.user" value="mailuser@domain.net" type="java.lang.String" /> <Environment name="mail.smtp.host" value="mail.domain.net" type="java.lang.String" /> <Environment name="mail.smtp.port" value="587" type="java.lang.Integer" /> </Context>

The most important parameters briefly explained:

Database parameters:

  • username: From MariaDB’s perspective, Tomcat is a regular user named hades.
  • password: The password for the MariaDB user is persephone.
  • driverClassName: This class provides the connection logic between Tomcat and MariaDB.
  • url: This URL tells Tomcat on which host and port MariaDB accepts connections.

E-mail parameters:

  • adminmail: Administrators receive notifications about user registration requests through this mailbox.
  • mail.smtp.password: Tomcat uses this password to authenticate with the mail server.
  • mail.smtp.user: Tomcat logs in with this username.
  • mail.smtp.host: The mail server is reachable at this address.
  • mail.smtp.port: The mail server accepts requests on this port.

Administration Interface (AdminUI)

Users with administrator rights see the Administrator menu at the top right of the client. To grant a user these rights, a database administrator must set the ISADMIN column to 1 for the corresponding user in the TB_USER table.

The program administrator defines the login process and sets filters for nicknames and rooms. In addition, they specify the grace period for break rooms before they are converted into a forum. The administrator can also initiate the update process for all clients by specifying outdated program version numbers.

Menu Administrator manage

  • Domain
    A domain can be either restricted or public.

    • Restricted domain: used for operational or organizational purposes. Access is granted only after an identity check by a program administrator.
    • Public domain: used for social media or community purposes. Users can create an account without prior identity verification.

  • Mailserver
    The credentials for the administrator mailbox are configured.

  • Forum
    The threshold for break rooms is set in minutes before they are converted into a forum.

  • Chat module
    The retention period for messages in the chat module is set in hours. It can range from 24 to 720 hours.

  • Requests for user registration
    Account creations for a restricted domain are managed here.

  • Chat filters
    The chat filters block certain letter sequences in room names. The filters are applied retroactively to existing chat names.

  • Program versions
    Enter outdated program versions here. Clients using these versions will initiate the update process.

  • Nicknames
    Nicknames contains a list of prohibited names. New prohibited names are applied to existing nicknames. Affected names are automatically changed to a random string within one hour.

  • Users
    The program administrator can view certain user data and logically delete a user account if needed.
mvn
mvn -Pwinrunner
mvn -Plinrunner
mvn -Pwinportable
mvn -Plinportable
mvn -Prelease
mvn

Legal Info