GuardEE :: a Microprofile Fault Tolerance & Config for JEE7

GuardEE is a no-deps portable JEE7 extension implementing Microprofile Fault Tolerance 1.0 specification & Microprofile Config 1.1 specification. It leverages JEE & CDI features to implement the specification.

⚠️
Early versions of GuardEE requires a Java 8 runtime
⚠️

Usage

As a portable extension, you just have to bring the implementation in your classpath and you're done.

Maven coordinates:

<dependency>
    <groupId>org.eclipse.microprofile.fault-tolerance</groupId>
    <artifactId>microprofile-fault-tolerance-api</artifactId>
    <version>1.0</version>
</dependency>
<dependency>
    <groupId>fr.brouillard.oss.jee</groupId>
    <artifactId>guardee-impl</artifactId>
    <version>X.Y.Z</version>
</dependency>

Gradle coordinates:

dependencies {
    compile 'org.eclipse.microprofile.fault-tolerance:microprofile-fault-tolerance-api:1.0'
    compile 'fr.brouillard.oss.jee:guardee-impl:X.Y.Z'
}

TCK compliance

Fault Tolerance

Mode / Filter	Status
all TCK	❌
Retry tests	✔️
Timeout tests	✔️
Fallback tests	✔️
CircuitBreaker tests	✔️
Config tests	❌
Invalid tests	blocked by wildfly/wildfly-arquillian#116
Bulkhead tests	✔️
Asynchronous tests	no TCK tests in 1.0

Config

Mode / Filter	Status
all TCK	❌
valid tests	✔️
Invalid tests	blocked by wildfly/wildfly-arquillian#116

as MP-1.1 TCK release is faulty for remote implementations, the TCK config tests need to integrate eclipse/microprofile-config#273 which corrects eclipse/microprofile-config#263

Build & Test

Build and run tests

mvn clean install

Filter the TCKs tests

mvn clean install -Dit.test=FILTER -Ptestng-scan -Dserver=widfly-local

Where FILTER is one of :

• Retry*
• Timeout*
• Fallback*
• CircuitBreaker*
• Config*

example with filtering on Retry tests: mvn clean install -Dit.test=Retry*

Launch tests on external server

mvn clean install -Ptestng-scan -Dserver=wildfly-remote

Branch policy

On this project several rules apply:

1. ONLY the master branch has to be considered as a public branch.
   As such, other branches have to be considered as temporary/working branches only and can be modified/rewritten/rebased/deleted.
2. In order to enforce previous point, master branch is protected (included for admins).
   That also means that any change to master has to go first to an integration branch that passes the protections in place:
   • green CI build

Release

In order to keep the project history clean, jgitver is used for version management.
oss & release profiles need to be activated during a release.

• once on a commit that builds successfully using Build & Test commands
• git tag -a -s -m "release X.Y.Z, additionnal reason" X.Y.Z: tag the current HEAD with the given tag name. The tag is signed by the author of the release. Adapt with gpg key of maintainer.
  • Matthieu Brouillard command: git tag -a -s -u 2AB5F258 -m "release X.Y.Z, additionnal reason" X.Y.Z
  • Matthieu Brouillard public key
• mvn -Poss,release -DskipTests deploy
• git push --follow-tags origin master