YAML is a nice and readable format for configuration allowing to set your properties hierarchically making them organized and readable.
Let see how to use this format with Apache DeltaSpike @ConfigProperty injections!
WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.
TomEE ApplicationComposer is a nice solution for embedded EE testing. The goal is to describe its application in Java and deploy this model. However it starts OpenEJB and deploys/undeploys the application either by class or method depending the setup.
When this feature can be insane for small deployments which would benefit of an insanely easy configuration and simple mock solution it can be an issue for application deploying again and again the same model.
To avoid that the coming TomEE 7.0.0-M2 provides a new JUnit runner but you can already benefit from it with a single class!
More and more applications are composed of REST services. In JavaEE land it means you develop and expose JAX-RS services.
Once developped and well tested with TomEE the first thing you will realize is that to make an API useful you need to document it. There are a lot of ways to do it but Swagger seems to be the trendy one and it is indeed a nice solution as we’ll see in this post.
Since months a typical web application is a JAX-RS for the server-side and a javascript on the client-side.
This powerful architecture can sometimes reveal some challenges in the build pipeline.
However today it is not that hard to mix both frontend and backend build tools to get a single build pipeline easily integrable in a continuous integration solution.
To illustrate that we’ll digg into how to create an Angular 2 application packaged with Maven.
TomEE Maven plugin got recently a new feature allowing to use javascript (or groovy) to customize the TomEE instance you build using tomee:build goal.
Let’s see why and how to use this feature…
For batch tasks it is quite common to need to browse a full table. Depending the table it can be done in memory without thinking much or it can be too big and needs pagination.
A common solution was to use a kind of PageResult object which was representing the current page and its index and let the client/caller iterating over PageResults.
With java 8 streams the API can be more concise and efficient.
In a recent post (https://rmannibucau.wordpress.com/2015/12/01/write-your-own-cdi-extension-for-bean-mapping/) I explained how to implement a simple mapper with CDI integration. We can actually make it simpler leveraging on CDI a bit more.
When you develop an application relying on a container for its awesome features you often hit the fact you use several code bases to do the same thing. In the context of this post it will be the ciphering of the passwords in the configuration:
PasswordCipher APIConfigFilter APISo finally you end up having to maintain two ciphering solutions which makes hard to production teams to maintain the configuration without developpers.
Generally most of the documentation of a project is manual but when you can automate some part why not doing it. When we speak about JBatch documentation we can automate two main parts by checking the sources:
DeltaSpike configuration is a very elegant configuration solution for CDI.
However to make it fitting your application you often need to integrate it:
There are generally three cases to add a custom configuration file:
In this post we will tackle the second one since mixing the last two solves generally the first one and the last one is mainly the same solution with some specific conversion logic I don’t want to enter in for this post.
So our goal will be to read the configuration from ${catalina.base}/conf/my-app.properties and add it in deltaspike properties.
To do so we just need deltaspike core:
<dependency>
<groupId>org.apache.deltaspike.core</groupId>
<artifactId>deltaspike-core-api</artifactId>
<version>${deltaspike.version}</version>
</dependency>
<dependency>
<groupId>org.apache.deltaspike.core</groupId>
<artifactId>deltaspike-core-impl</artifactId>
<version>${deltaspike.version}</version>
</dependency>
Then we need to implement a custom org.apache.deltaspike.core.spi.config.ConfigSource reading ${catalina.base} from the corresponding system properties (our implementation will have a fallback on openejb.base property for openejb embedded tests):
import org.apache.deltaspike.core.impl.config.PropertiesConfigSource;
import java.io.BufferedInputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;
// uses ${base}/conf/my-app.properties as source
public class MyConfigSource extends PropertiesConfigSource {
public MyConfigSource() {
super(loadProperties());
}
public String getConfigName() {
return "MyAppConfig";
}
private static Properties loadProperties() {
return new Properties() {{
final File config = new File(
System.getProperty("catalina.base", System.getProperty("openejb.base", "")),
"conf/my-app.properties");
if (config.isFile()) {
try (final InputStream is = new BufferedInputStream(new FileInputStream(config))) {
load(is);
} catch (final IOException e) {
throw new IllegalArgumentException(e);
}
}
}};
}
}
Then to “activate” it just create a META-INF/services/org.apache.deltaspike.core.spi.config.ConfigSource containing our qualified class name.
To decrypt password DeltaSpike uses org.apache.deltaspike.core.spi.config.ConfigFilter implementations. It has two methods:
For this post the decryption will just reverse the value but a real implementation can use any ciphering considered secured in your environment:
import org.apache.deltaspike.core.spi.config.ConfigFilter;
public class MyConfigFilter implements ConfigFilter {
@Override
public String filterValue(final String key, final String value) {
return isEncrypted(key) ? decrypt(value) : value;
}
@Override // filter passwords and secrets in logs
public String filterValueForLog(final String key, final String value) {
return isEncrypted(key) ? "xxxxxx" : value;
}
// for the sample just "reverse" the string but in real life use some encryption
private String decrypt(final String value) {
return new StringBuilder(value).reverse().toString();
}
private boolean isEncrypted(final String key) {
return key.contains("password") || key.contains("secret");
}
}
As for ConfigSource and since this classes are used before CDI is started to configure DeltaSpike itself don’t forget to register the filter adding the fully qualified name in META-INF/services/org.apache.deltaspike.core.spi.config.ConfigFilter.
Now if you set for instance in your configuration:
my.password = tset
And get my.password injected:
@Inject @ConfigProperty(name = "my.password") private String pwd;
Then pwd value will be test :).
The code of this post can be found there: https://github.com/rmannibucau/deltaspike-config-example.
The interesting part is to understand deltaspike can be integrated with all kind of configuration and environment which is the main feature of a configuration API. Then you still get it integrated with CDI for free thanks to DeltaSpike @ConfigProperty which makes your application simple and decoupled from your actual configuration system.
