Microservices

Recently in a project I encountered the following problem: The development team used Git with a branch-per-feature-like workflow and the integration server, Bamboo in this case, was configured not only to run the integration-tests for the master-branch but also for every change in a feature branch. As the team developed a Java EE web application ports like 8080 occasionally were already bound and builds failed. I knew a plug-in for Jenkins CI I to search for available ports and assign them to a build variable but I wanted to control such information directly within the Maven build life-cycle so I searched and finally found Sonatype’s Port Allocator Plug-in for Maven. ...

Feature flags are a common technique, often combined with continuous deployment and delivery and they allow us to rollback a specific feature, to create A/B tests or to rollout a specific feature for a specific test group, a specific amount of users or dedicated systems. In the following short examples I’d like you to demonstrate how easy it is to implement feature flags with the Togglz framework with a few steps in a Java EE environment. ...

Now that the long awaited stable version of the Arquillian framework is released I wanted to demonstrate some interesting features of this framework that really eases writing and running of integration tests for Java EE 6 applications in many different ways. In the following tutorial we are going to create some real-world examples using Enterprise JavaBeans, Contexts and Dependency Injection, the Java Persistence API and we’re finally running Drone/Selenium tests against a JEE Web Application that is using Java Server Faces. ...

Figure 1. REST-assured Integration Test Tutorial Logo There are many frameworks out there to facilitate testing RESTful webservices but there is one framework I’d like to acquaint you with is my favourite framework named REST-assured. REST-assured offers a bunch of nice features like a DSL-like syntax, XPath-Validation, Specification Reuse, easy file uploads and those features we’re going to explore in the following article. With a few lines of code and Jersey I have written a RESTful web service that allows us to explore the features of the REST-assured framework and to run tests against this service. ...

Today we’re going to take a look at two specific frameworks that enables you to efficiently test your REST-ful services: On the one side there is the framework REST-assured that offers a nice DSL-like syntax to create well readable tests – on the other side there is the Jersey-Test-Framework that offers a nice execution environment and is built upon the JAX-RS reference implementation, Jersey. In the following tutorial we’re going to create a simple REST service first and then implement integration tests for this service using both frameworks. ...

Using the contract-first approach to define a web service offers some advantages in contrast to the code-first approach. In the following tutorial we’re going to take a look at some details of this approach and we’re going to implement a real SOAP service using JAX-WS, Maven and the Eclipse IDE. Finally we’re going to run our service implementation on an embedded Jetty instance and we’re going to take a look at soapUI and how to test our service using this neat tool. ...

Java EE 6 is out and it indeed offers an interesting stack of technologies. So in today’s tutorial we are going to build a small sample web application that builds on this stack using Enterprise JavaBeans, Java Persistence API, Bean Validation, CDI and finally Java Server Faces and PrimeFaces. The application we’re going to develop is a simple blog app that allows us to create new articles, list them and – finally delete them. We’re also covering some additional topics like JSF navigation, i18n, Ajax-enabled components and the deployment on the GlassFish application server. ...

It is possible to create SOAP webservices with only a few lines of code using the JAX-WS annotations. In a productivity environment you might prefer using contract-first instead of code-first to create your webservice but for now we’re going to use the fast method and that means code-first and annotations olé! Creating the SOAP Service Create a class SampleService with two public methods Annotate this class with @WebService (javax.jws.WebService) – now all public methods of this class are exported for our SOAP service To change the name of an exported method, annotate the method with @WebMethod(operationName = “theDesiredName”) (javax.jws.WebMethod) Finally the service class could look like this package com.hascode.tutorial.soap; import javax.jws.WebMethod; import javax.jws.WebService; @WebService public class SampleService { @WebMethod(operationName = "getInfo") public String getInformation() { return "hasCode.com"; } public String doubleString(String inString) { return inString + inString; } } ...

There is still the urban myth that using Spring IoC container without thousands lines of XML code isn’t possible – so today we’re taking a look at annotation based configuration with Spring 3 and of course we’re using Maven.. Setup your project Create a simple Maven project using mvn archetype:generate // or mvn archetype:create Add a lot of dependencies and reference them to the Spring version defined as a property in your pom.xml. A good reference on Spring 3 and Maven artifacts can be found at Springsource.com <properties> <org.springframework.version>3.0.0.RELEASE</org.springframework.version> </properties> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${org.springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-expression</artifactId> <version>${org.springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-beans</artifactId> <version>${org.springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-aop</artifactId> <version>${org.springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${org.springframework.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context-support</artifactId> <version>${org.springframework.version}</version> </dependency> <dependency> <groupId>org.aspectj</groupId> <artifactId>com.springsource.org.aspectj.runtime</artifactId> <version>1.6.8.RELEASE</version> </dependency> </dependencies> ...

Define and Configure Log Groups This allows to configure a group of loggers at the same time Define a log group named myaspect with two packages application.properties logging.group.myaspect=com.hascode.package1,com.hascode.package2 Configure the log group and set all loggers to level TRACE application.properties logging.level.myaspect=TRACE This is also possible as parameter on startup java -Dlogging.level.myaspect=TRACE myapp.jar Use JUnit 5 with Spring Boot Use newer versions of Surefire and Failsafe plugins: <properties> [..] <maven-failsafe-plugin.version>2.22.0</maven-failsafe-plugin.version> <maven-surefire-plugin.version>2.22.0</maven-surefire-plugin.version> </properties> ...