YAML configuration for DeltaSpike


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!

Continue reading

Sponsored Post Learn from the experts: Create a successful blog with our brand new courseThe WordPress.com Blog

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.

A single TomEE ApplicationComposer instance for all your tests!


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!

Continue reading

JavaEE and Swagger: TomEE example


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.

Continue reading

Mix TomEE embedded and Angular 2 with Maven


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.

Continue reading

Customize your TomEE instance with javascript and 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…

Continue reading

JPA + Java8 Stream = paginated findAll()


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.

Continue reading

CDI Mapper: get rid of the proxy layer!


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.

Continue reading

Align TomEE and DeltaSpike ciphering configuration


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:

  • TomEE does it using PasswordCipher API
  • DeltaSpike does it using ConfigFilter API
  • So finally you end up having to maintain two ciphering solutions which makes hard to production teams to maintain the configuration without developpers.

    Continue reading

JBatch: gradle and asciidoctor batch documentation


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:

Continue reading

DeltaSpike configuration: read where you want and decrypt passwords


DeltaSpike configuration: read where you want and decrypt passwords

DeltaSpike configuration is a very elegant configuration solution for CDI.

However to make it fitting your application you often need to integrate it:

  • to read the configuration from the source/location you desire
  • to use a custom algorithm to decrypt passwords or sensitive data

Read your own configuration file

There are generally three cases to add a custom configuration file:

  • respect a company convention
  • read it from outside the application (in ${tomee.base}/conf for instance ;))
  • read a custom format (yaml, xml, …)

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.

Decrypt passwords with your own algorithm

To decrypt password DeltaSpike uses org.apache.deltaspike.core.spi.config.ConfigFilter implementations. It has two methods:

  • filterValue: actual decryption
  • filterValueForLog: decryption for logging, in general I just log “xxxxxx” if my filter handles the value

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 :).

Conclusion

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.