TicketMonster is an online ticketing demo application that gets you started with JBoss technologies, and helps you learn and evaluate them.

Here are a few instructions for building and running it. You can learn more about the example from the tutorial.

mvn clean install

This will build our application into a fat-jar that gets bootstrapped with WildFly Swarm. This can be run with a simple java -jar command line because all of its dependencies and classpath modules are included in the uber jar. For example, after running mvn install you can run the microservice like this:

java -jar target/ticket-monster-orders-swarm.jar 

If you're changing this often, these two steps may not be ideal. You can run it with one command:

mvn wildfly-swarm:run

To run with docker:

mvn clean package -Pdefault,f8-build docker:build
docker run -it --rm -p 8080:8080 -e AB_OFF=true fabric8/ticket-monster-orders:1.0-SNAPSHOT

Can port forward to your local machine from vagrant like this:

vagrant ssh -- -vnNTL *:8080:$DOCKER_HOST_IP:8080

mvn clean package -Pmysql

mvn -Pf8,mysql fabric8:deploy

We need to refer to the mysql database template from https://github.com/christian-posta/ticket-monster-infra. We can install the template with:

oc create -f mysql-openshift-template.yml

Now let's create the mysql database for the admin microservice:

oc process ticket-monster-mysql -v DATABASE_SERVICE_NAME=mysqlorders | oc create -f -
oc deploy mysqlorders --latest

As root, we can reset the database:

mysql> drop database ticketmonster; create database ticketmonster;

mvn -Pdb-migration-mysql liquibase:update
mvn -Pdb-migration-mysql liquibase:updateSQL
mvn -Pdb-migration-mysql liquibase:status
mvn -Pdb-migration-mysql liquibase:tag -Dliquibase.tag=v2.0

Automatically discover diffs between the existing schema and what Hibernate sees currently

mvn -Pdb-migration-mysql liquibase:diff -Dliquibase.referenceUrl=hibernate:ejb3:primary

Generate the changeLog to a file:

mvn -Pmysql,db-migration-mysql liquibase:diff -Dliquibase.referenceUrl=hibernate:ejb3:primary -Dliquibase.diffChangeLogFile=target/changes.yml

From here you can evaluate what changes should go into the next update

After an update, it's recommended to tag if things went successful, or rollback if not.

Also, you can see what tags exist in the DB:

select ID, DATEEXECUTED,TAG from DATABASECHANGELOG WHERE TAG IS NOT NULL ORDER BY DATEEXECUTED;

TODO: eliminate sending back data model elements directly; we should make more clearly the "view" model and the "write" model .. this will involve cleaning up the DTO objects if they're not needed in the write model