The goal of this project to provide a functional usage pattern for general project structuring.
Every service uses the same API, runs on the same port, and in the same environment.
sample/sample-rest-service
This is a simple basic REST implementation. Uses only built in tools Every additional sample service is an extension of this basic implementation.
sample/sample-jpa-service
The purpose of the service is to utilize the JPA server Since it is designed to be universal, it uses the H2 database. However, the management of each entity is handled as if it were a regular database underneath.
sample/sample-mongo-service
The purpose of the service is to demonstrate the usage of mongodb for simple read/write operations. The service built on the coff:ee mongo modul. More detailed information about this module can be found here: https://i-cell-mobilsoft-open-source.github.io/coffee/#common_module_coffee-module-mongodb To use the service,it is necessary to first run the Docker Mongo database.
The service is rin using Docker-compose, as it allows more advanced configurations compared to using docker alone.
docker-compose -f local_path/sampler/etc/docker-compose/docker-compose.local.wildfly.yml up --force-recreateThe --force-recreate switch is used to ensure that the previous docker container is deleted during startup
allowing a fresh environment to be created for each run.
This utilizes the Wildfly deploy autoscan feature,
which means that the WAR file is copied into the scanned directory for deployment.
This can be done either through the console (not convenient) or with the help of an ANT file (sample/sample-*-service/build.xml)..
The Wildfly server and its configuration are set up to run one service at a time.
So you can use the following deployment "copy" script, where you need to set <PROJECT_VERSION> to the actual version number.
# in case of sample-rest-service
docker cp local_path/sample/sample-rest-service/target/sample-rest-service-<PROJECT_VERSION>.war bs-sample-service:/opt/jboss/wildfly/standalone/deployments/ROOT.war
# in case of sample-jpa-service
docker cp local_path/sample/sample-jpa-service/target/sample-jpa-service-<PROJECT_VERSION>.war bs-sample-service:/opt/jboss/wildfly/standalone/deployments/ROOT.war
# in case of sample-mongo-service
docker cp local_path/sample/sample-mongo-service/target/sample-mongo-service-<PROJECT_VERSION>.war bs-sample-service:/opt/jboss/wildfly/standalone/deployments/ROOT.warHowever, more conveniently, using Ant with a single click from the IDE
e.g. the sample/sample-rest-service/build.xml Ant file, with the "deploy-war-docker" target (default)
This handles the paths, version numbers,
and eliminates the neet to remember anything, open console, etc
Some services, such as sample-mongo-service, require a mondodb service as well,
for this the etc/docker-compose/docker-compose.local.mongodb.yml ducker compose file is prepared.
The docker compose file etc/docker-compose/docker-compose.local.mongodb.yml needs to be started.
There is nothing else to do except to start it.
Starting .MongoDB
docker-compose -f local_path/sampler/etc/docker-compose/docker-compose.local.mongodb.yml up --force-recreateEverything else is set up.
The endpoints are not authenticated, the SwaggerUI page can be used to interact with the endpoints. Unfortunately, due to the complexity of the API, it may not work well in XML format due to XML namespaces, it is recommended to use JSON format instead.
sampler/sr-testsuite
The developer tests utilize the Roaster project. It is a completely independent REST application that performs external API calls on the deployed application. The developer UI can be executed directly using the JUnit or with Maven (by activating the "profile" switch), e.g.:
mvn verify -Dprofile (1)
mvn verify -Dprofile=sandbox,local (2)-
default parameters
-
selected profiles from the configuration files