Skip to content

Latest commit

 

History

History
128 lines (99 loc) · 5.34 KB

README.adoc

File metadata and controls

128 lines (99 loc) · 5.34 KB

Registry

Registry is a web application to help school teachers tackle the administrative tasks of a school class. Although it is a fairly small application it implements all best practices as far as security, stability and scalability is concerned. Features are constantly added and feature requests are kindly encouraged. Currently, the application uses Greek localization, with English planned next.

Login

Default user credentials are: user:user123

Database

The application requires a Postgres database.

Create a PostgreSQL schema and user

Before deploying the application a Postgres database schema must created. Just for reference, to create a postgres schema follow these steps:

  1. Connect to postgres using psql

    $ psql --host=localhost --port=5432 --username=postgres

  2. Create the application user

    CREATE USER registry PASSWORD 'registry' createdb;

  3. Create the application database

    CREATE DATABASE registry OWNER = registry;

  4. Edit the pom.xml with the connection information provided in the end (update them accordingly for your environment if required).

  5. Initialize the database using flyway

    # mvn clean compile flyway:migrate
Connection information
host

localhost
port

5432
user

registry
password

registry
database

registry

Backup database

Restore database

Clean the database

After removing the existing database, recreate using the SQL command shown previously or using the following command:

$ createdb -U <user> -W -h <host> -O <owner> <new_database>

  • -U <user>: the user to connect with

  • -W: ask for password

  • -h <host>: the database host to connect to

  • -O <owner>: the owner of the new database

  • <new_database>: the new database name

Restore
$ pg_restore -U <user> -W -h <host> -v -d <database> <backup_file>

  • -U <user>: the user to connect with

  • -W: ask for password

  • -h <host>: the database host to connect to

  • -v: be verbose

  • -d <database>: the database name to restore to (must exist)

  • -O <owner>: the owner of the new database

  • <backup_file>: the backup file

Production datasource

When deploying a production build a JNDI datasource is required. For tomcat installations make sure to satisfy the following:

  1. Add the PostgreSQL JDBC driver into Tomcat lib.

  2. Edit Tomcat server.xml to include the following in the GlobalNamingResources section:

    <Resource name="RegistryDatasource"
    auth="Container"
    type="javax.sql.DataSource"
    driverClassName="org.postgresql.Driver"
    url="jdbc:postgresql://localhost:5432/registry"
    username="registry"
    password="registry"
    maxActive="10" maxIdle="4" maxWait="10000"
    testOnBorrow="true"
    validationQuery="select 1"
    validationInterval="360000"/>

  3. In the previous fragment the Resource element has an attribute name. The value of this attribute should be the same with the global attribute of the ResourceLink element of context.xml found in src/main/webapp/META-INF/context.xml

Build

To build the application the user interface (client) and server must be built individually. The client exists in a seperate repository.

Server

For the server build, maven is used. The build is profile based with profiles: local_ds, jndi_ds, bundle and deploy.

local_ds vs jndi_jd

The local_ds profile uses a Spring configured datasource, while the jndi_ds profile, expects a JNDI datasource to be in place when deploying. These two profiles should be considered as mutually exclusive.

The local datasource is configured in pom.xml through the dev.jdbc.user, dev.jdbc.password and dev.jdbc.url properties.

bundle

This profile instructs the build to include an already built and installed in the maven local repository user interface. When this profile is not enabled, the user should provide the user interface, typically preferred when developing user interface features

deploy

Deploys the application during the package phase to a configured Tomcat instance, using the tomcat manager application, as configured in pom.xml.

System properties

The application accepts two system properties:

spring.profiles.active

This can be either dev or prod and selects between local or JNDI datasource. Note that this should be aligned with the profile built and no default is provided.

secure

When this has the value false all application security is disabled. Typically preferred during development mode.

Build

During development the maven command to execute is:

mvn clean tomcat7:run-war -Pdev -Dmaven.test.skip -Dspring.profiles.active=dev -Dsecure=false

This will launch the application within an embedded tomcat. It uses a local datasource. It is required that the user provides the user interface.

When preparing a production release the command to use is:

mvn clean package -Dmaven.test.skip -Pprod,bundle,deploy

This command will build a production package to deploy on tomcat. This build requires a JNDI datasource and the user interface to be available as a maven artifact.

User interface

Check out the client code from registry-ui and follow the instructions in README.adoc. In priciple, the user interface must be built first and installed into a maven repository. Then the server application will pull the user interface as a depedency.