Tag Archives: cdi

@CacheResult: JCache + CDI to the rescue of microservices?


JCache API comes with several built in interceptors for CDI making its usage decoupled from the cache API itself and more user friendly.

Let’s have a look to this API.

CacheResult: the method execution killer

Probable one of the most common use cache is to avoid to pay the cost of a method each time you call it.

Reasons can be as different as:

  • Computation done by the method is expensive
  • The method contacts a remote service and you want to cut off the implied latency
  • The method accesses a rate limited resource
  • ….

In this cache @CacheResult brings a nice and easy to setup solution. Simply decorating the method with @CacheResult you will avoid the actual method invocation after the first call and while it is cached.

Basic usage

Here a sample using a service simulating a slow method:

Continue reading

Lambda-CDI in Alpha!


Lambda + CDI in Alpha!

Lambda are nice new features of Java 8 and I’m sure we’re still missing
a lot of their uses to get nicer API in all domains where Java can be used (i.e all domains ;)).

However, it is often limited to JavaSE only. Typically, you can desire to get “injected” as method
parameter(s) some CDI beans – this would be the same for Spring beans or any IoC, but if you browsed this blog
you’ll understand that I’ll deal with CDI.

Now, the question is : how to link both worlds and get the best of them?

An example

Here is a simple sample showing you how mixing CDI and lambda can look like:

public class MyRuntimeBuilder {
    public void doSomething() {
       onEvent((MyEvent e, MyCdiEventProcessor processor) -> {
           processor.process(e);
       }).then((MyCdiWebSocket w) -> {
           w.send("Got it!");
       });
    }
}

Then, why do we need Lambda? There are several cases:

  • Laziness: if you need to “lookup” the instances after having called the builder (CDI not yet fully started for instance).
  • Contextuality: if you build a DSL, you would want to get “method scoped” instances, and not to rely on DSL “builder” injected instances
  • Closeness: make the “injections” closer to their use. In several cases it makes the code more readable.
  • Reusability: this way your lambdas can be reused (keep in mind a lambda can also be a method with “::” syntax)
  • Because it is fun 😉
  • And much more…

To make the contextuality point more obvious, think of JBatch: you define a set of steps and we advise you to use @Dependent instances
for JBatch components. If you add a DSL and a BatchBuilder API, you can not count on injected components in your builder. If you have
N times the same component (N > 1), here is what you get:

public class MyBatchBuilder {
    public void define() {
       job().id("my-batch")
        .step().id("download-csv")
          .batchlet((HttpConnection connection) -> {
            connection.configureProxy("myproxy", "8080");
            connection.download("http://csvbase.com/mycsv.csv");
          })
        .step().id("download-xml")
          .batchlet((HttpConnection connection) -> {
            connection.configureTimeout(5, TimeUnit.MINUTE);
            connection.download("http://xmlbase.com/myxml.xml");
          })
    }
}

In the sample below, we can suppose HttpConnection Instance must be used only once. If we use it twice, its configuration would leak
between steps.

CDI: from reflection to parameter instances

In this part, we’ll suppose that we have a java.lang.reflect.Method. The question is: how to get CDI parameters to call the method instance? Here, the solution is not provided by CDI but it is not that far.

You can get the parameter types and their annotations from the method (here, I’ll simplify a bit and skip annotations since a lambda doesn’t have parameter annotations). You just need to lookup the associated instance from the bean type.

To do so, we’ll use the BeanManager “getInjectableReference” method and we’ll need an InjectionPoint and a CreationalContext.

To get the BeanManager, we’ll use new CDI 1.1 “CDI” utility class. If you are on a CDI 1.0 server you can use DeltaSpike BeanManagerProvider:

BeanManager bm = CDI.current().getBeanManager();

Then we’ll implement an InjectionPoint. In CDI 1.1 you can create it from an “AnnotatedParameter”. I’ll enlarge that solution later, but for CDi 1.0 you can implement a custom injection point to get the same result. The easiest way is to create an implementation of “AnnotatedMethod” and “AnnotatedParameter”. Both are linked as expected.

Here is a proposal for their implementation – note that you can enhance it to support more metadata for qualifiers for instance:

// AnnotatedMethodImpl
public class AnnotatedMethodImpl<T> implements AnnotatedMethod<T> {
    private final AnnotatedType<T> annotatedType;
    private final Method method;
    private final Set<Annotation> annotations;
    private final List<AnnotatedParameter<T>> parameters;

    public AnnotatedMethodImpl(AnnotatedType<T> annotatedType, Method method, int paramCount, Type[] paramTypes) {
        this.annotatedType = annotatedType;
        this.method = method;
        this.annotations = new HashSet<>(asList(method.getAnnotations()));
        this.parameters = new LinkedList<>();

        for (int i = 0; i < paramCount; i++) {
            this.parameters.add(new AnnotatedParameterImpl<>(this, i, paramTypes[i], new HashSet<>(asList(method.getParameterAnnotations()[i]))));
        }
    }

    @Override
    public List<AnnotatedParameter<T>> getParameters() {
        return parameters;
    }

    @Override
    public Method getJavaMember() {
        return method;
    }

    @Override
    public boolean isStatic() {
        return Modifier.isStatic(method.getModifiers());
    }

    @Override
    public AnnotatedType<T> getDeclaringType() {
        return annotatedType;
    }

    @Override
    public Type getBaseType() {
        return method.getDeclaringClass();
    }

    @Override
    public Set<Type> getTypeClosure() {
        return Collections.singleton(getBaseType());
    }

    @Override
    public Set<Annotation> getAnnotations() {
        return annotations;
    }

    @Override
    public <T extends Annotation> T getAnnotation(Class<T> annotationType) {
        return (T) annotations.stream().filter(a -> a.annotationType() == annotationType).findFirst().orElse(null);
    }

    @Override
    public boolean isAnnotationPresent(Class<? extends Annotation> annotationType) {
        return annotations.stream().filter(a -> a.annotationType() == annotationType).findFirst().isPresent();
    }
}

// AnnotatedParameterImpl
public class AnnotatedParameterImpl<T> implements AnnotatedParameter<T> {
    private final AnnotatedMethod<T> method;
    private final int position;
    private final Set<Type> types = new HashSet<>();
    private final Set<Annotation> annotations;
    private final Type baseType;

    public AnnotatedParameterImpl(AnnotatedMethod<T> method, int position, Type baseType, Set<Annotation> annotations) {
        this.method = method;
        this.baseType = baseType;
        this.position = position;

        this.types.add(baseType);
        this.types.add(Object.class);

        this.annotations = new HashSet<>(annotations);
    }

    @Override
    public int getPosition() {
        return position;
    }

    @Override
    public AnnotatedCallable<T> getDeclaringCallable() {
        return method;
    }

    @Override
    public Type getBaseType() {
        return baseType;
    }

    @Override
    public Set<Type> getTypeClosure() {
        return types;
    }

    @Override
    public <T extends Annotation> T getAnnotation(Class<T> annotationType) {
        for (Annotation a : annotations) {
            if (a.annotationType().getName().equals(annotationType.getName())) {
                return (T) a;
            }
        }
        return null;
    }

    @Override
    public Set<Annotation> getAnnotations() {
        return annotations;
    }

    @Override
    public boolean isAnnotationPresent(Class<? extends Annotation> annotationType) {
        return getAnnotation(annotationType) != null;
    }
}

NB: you surely noticed that I didn’t use “method.getParameterTypes()” (or generic version) to get parameter types. In fact, I used a provided array of “Type” because lambda will not fill it properly (see next part).

Now, we have all we need to create an injection point and then make a lookup on a  parameter.

Let’s do it:

Type[] types = ...;
Method method = ...;

BeanManager bm = CDI.current().getBeanManager();

// create our Annotated*
AnnotatedMethod annotatedMethod = new AnnotatedMethodImpl<>(bm.createAnnotatedType(method.getDeclaringClass()), method, cdiBeanParameterNumber, types);
List<AnnotatedParameter<?>> annotatedMethodParameters = annotatedMethod.getParameters();

// for all parameters, get the parameter instance
Parameters parameters = new Parameters(); // just a small wrapper to keep tracking of CreationalContexts
for (int i = 0; i < cdiBeanNumber; i++) {
    CreationalContext<?> creational = bm.createCreationalContext(null);
    Object instance = bm.getInjectableReference(bm.createInjectionPoint(annotatedMethodParameters.get(i)), creational);
    parameters.addInstance(instance, creational);
}

Note: cdiBeanNumber is optional and we can use method.getParameterCount(). But in my implementation I’ll support CDI (and non-CDI) parameters, so I need a limit.

Now that we have all our parameters, we just need to call the method with it!

But wait, how do I get the Method? Are the method types right? Let’s dig into it!

Lambda: from instance to Method

Finding a lambda method it is not that hard. You simply iterate over the lambda methods and remove all Object methods and default methods:

public static void invokeLambda(Object lambda, Object...args) {
    Class<?> lambdaClass = lambda.getClass();
    for (Method method : lambdaClass.getMethods()) {
        Class<?> declaringClass = method.getDeclaringClass();
        if (declaringClass == Object.class) {
            continue;
        }
        if (declaringClass == Serializable.class) {
            continue;
        }
        if (method.isDefault()) {
            continue;
        }

        // TODO: invoke it!
        return;
    }
    throw new IllegalArgumentException(lambda + " not a lambda");
}

Now that you identified the “lambda method”, remember that it can be a lambda or a normal (java 7 like) implementation of the functional interface. To check it, an easy way is to check instance class name. If it contains “$$Lambda” then it is a generated class by the JVM to implement the lambda. If it is not the case then you can use “method.getGenericParameterTypes()” to get method parameter types. If it is the case you need few more code.

You have two cases to find the lambda parameter types:

  • Your functional interface is Serializable. In this case, serialize the lambda calling writeReplace method and cast it to SerializedLambda. You can get the signature of a SerializedLambda (“getImplMethodSignature()”). From this signature, you can build a “MethodType” with “MethodType.fromMethodDescriptorString” which will allow you to access parameter types.
  • If you don’t want to make your functional interface serializable to keep your API clean, you can get the “ConstantPool” from the lambda class, and the types from this instance. This is the job of the next snippet.

Note: in next snippet there is few reflection for sun.* invocations. This is not mandatory and a strong cast would have worked but allows to keep the build failing on sun.* imports – important for other parts of the code to avoid wrong imports not noticed.

private  static java.lang.reflect.Type[] methodTypeParameters(Object lambdaInstance) {
    try {
        ConstantPool pool = ConstantPool.class.cast(GET_CONSTANT_POOL.invoke(lambdaInstance.getClass()));
        String[] methodRef = pool.getMemberRefInfoAt(pool.getSize() - 2);

        // Type[] types = jdk.internal.org.objectweb.asm.Type.getArgumentTypes(methodRef[2]);
        Object[] argTypes = (Object[]) GET_ARGUMENTS_TYPE.invoke(null, methodRef[2]);

        Collection<java.lang.reflect.Type> types = new ArrayList<>(argTypes.length);
        ClassLoader loader = Thread.currentThread().getContextClassLoader();
        for (Object argType : argTypes) {
            Class<?> clazz = loader.loadClass(String.valueOf(GET_CLASS_NAME.invoke(argType)));
            types.add(clazz);
        }
        return types.toArray(new java.lang.reflect.Type[types.size()]);
    } catch (Exception e) {
        throw new IllegalStateException(e);
    }
}

This code is low level but the overall idea is:

  1. extract the types from the lambda class metadata.
  2. convert it in java qualified name thanks to the shaded version of asm included in the JVM
  3. load the associated class.

Put it all together

So now we are able to find lambda parameter types, and to lookup CDI beans by type. It is time to put it all together!

Click here to see the utility class with all that code: https://github.com/rmannibucau/lambda-cdi/blob/master/src/main/java/com/github/rmannibucau/blog/lambda/cdi/Lambdas.java

Lambdas utility use

Now we are able to call lambdas with CDI injections. Let’s see how to use our utility class.

First, define few functional interfaces:

@FunctionalInterface
public interface TaskWithCdiParameter<T> {
    void work(T cdiBean);
}

@FunctionalInterface
public interface TaskWithCdiParameterAndArgument<T, A> {
    void work(T cdiBean, A arg);
}

Then define a class based on these interfaces:

// this class stack tasks then execute them sequentially
public abstract class MyFlowBuilder implements Runnable {
    private final Collection<Runnable> tasks = new LinkedList<>();

    // cdi parameter(s)
    protected <T> void work(final TaskWithCdiParameter<T> task) {
        tasks.add(() -> Lambdas.invokeLambda(task));
    }

    // cdi params + args
    protected <T, A> void work(final TaskWithCdiParameterAndArgument<T, A> task, A arg) {
        tasks.add(() -> Lambdas.invokeLambda(task, arg));
    }

    public abstract void defineFlow();

    @Override
    public void run() {
        tasks.stream().forEach(Runnable::run);
    }
}

Finally define your own builder:

MyFlowBuilder builder = new MyFlowBuilder() {
    @Override
    public void defineFlow() {
        work((ABean1 bean) -> bean.call());
        work((ABean1 bean1, ABean2 bean2) -> {
            bean1.call();
            bean2.call();
        });
        work((ABean3 bean, String arg) -> bean.call(arg), "param");
        work(new TaskWithCdiParameter<ABean1>() { // java 7 style
            @Override
            public void work(ABean1 cdiBean) {
                cdiBean.call();
            }
        });
    }
};
builder.defineFlow();
builder.run();

This example is effortless but already shows you how to use CDI lambda injections of course. It also shows you how to mix them with parameters. This last case can easily be extended to support CDI qualifiers on lambda 🙂

Conclusion

Creating an API with lambda is not that obvious because you often need to:

  • Create several interfaces with N parameters (personally I use N in [0, 10] because I think N > 10
    makes API too complicated and doesn’t bring anything more – you can still create another type to aggregate several injections)
  • Duplicate this API with parameters or not (same rule – already makes 10*10 functional interfaces)
  • Potentially add some more behavior in the functional interfaces (small tip here is to create other
    instances of your functional interfaces from the current one)
  • If type is not enough (you can use qualifiers) then you can duplicate it again with
    qualifiers (10*10*2 interfaces)

To make it easy to maintain, you can generate them from templates (cucumber does it). I don’t get
into details here, because I’ll try to write another post about it soon.

However keep it in mind this has impacts on your API. You need to carefully think about it because skipping this generation step will make your life easier… but can make your API less user-friendly.

Finally, linking your lambda API with any other library is not that hard since you can get almost
all metadata you need (I would still love to see annotations in these metadatas but you can fix it with a custom signature enriching lambda with metadatas).

Don’t be afraid of the lambdas and enter the game, a lot of new API style are next our doors!

CDI and @Startup: SOLVED!


Speaking on the CDI list about CDI 2.0 standalone container API Jozef Hartinger sent an answer which is quite obvious when you know it but which can change your life if you don’t: how CDI 1.1 introduced @Startup without the need of EJBs.

Continue reading

CDI and Instance: 3 pitfalls you need to know


Recently on OpenWebBeans mailing list a nice discussion was started by Karl Kildén about its usage of CDI Instance.

This API is nice and useful but it is not as trivial as it can look. Let’s dig a bit into it.

Continue reading

Get git information in your CDI application easily thanks to DeltaSpike and git-commit-id-plugin


Having SCM information in the project is really interesting to dump them at startup for instance.

There are several ways to do it.

One easy is to use templating-maven-plugin and filter a .java with these information but it has several drawbacks:

Continue reading

TomEE, CDI and LoginModule


JAAS is not the best security framework it exists but it is often enough for simple needs. Once you passed the setup (I’ll not detail it here) it is generally nice to use. However when writing a CDI app you need to do the bridge yourself.

You can hook it up with DeltaSpike BeanProvider but it is not that obvious/fluent.

Continue reading

Adding legacy beans to CDI context: a CDI extension sample


Adding a bean which is not a CDI bean into the CDI context can easily be done through a CDI extension. However in some cases (typically when these beans are configuration aware) you need to extract their creation from the code (= configure them without updating the code. A common sample is an URL to configure.).

As a Proof Of Concept (PoC) i pushed on github cdi-light-config extension: https://github.com/rmannibucau/cdi-light-config.

Continue reading