JSR-107 JCache / Ehcache - XML Configuration for custom Serializer and Copier

726 views
Skip to first unread message

Steve Schols

unread,
Aug 30, 2017, 6:15:50 AM8/30/17
to ehcache-users
Hi all,

I have a question concerning JCache / Ehcache XML configuration.

I'm using the JSR 107 Cache Annotations CDI Reference Implementation together with Ehcache.

I want to annotate specific methods with @CacheResult, so that the result of these methods will be cached in a cache generated for that specific method.
In our case, these methods have Optional<T> as their return value, and as you probably know, Optional instances are not Serializable and thus cannot be cached by default.
The default used SerializingCopier and PlainJavaSerializer fail on this.

To solve this, I have implemented our own custom OptionalSerializer and OptionalCopier to be able to handle Optional values.

But I am not able to make JCache / Ehcache clear to use my custom Serializer and Copier when it comes around Optional return values.
I tried putting ehcache.xml on the classpath of JBoss EAP 6.4.0 (using JBoss modules) and I tried putting an ehcache.xml in the resources folder of the Maven module, but they are just plainly ignored. 
Even if I make those XML's invalid, I don't get any error.

I want to avoid creating a CacheManager, referring to our own ehcache.xml configuration file programmatically, since I would have to create the caches then at that point. I don't want this.
I want the caches to be created by the Cache Annotations CDI CacheResultInterceptor, and I don't seem to have an option to override a method to create a CacheManager of my own...

Does anyone know what I should do to solve this issue?
I just want to use the provided interceptors, and have an XML configuration that specifies that custom serializers and copiers will need to be used for specific return types.

beans.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
<interceptors>
<class>org.jsr107.ri.annotations.cdi.CacheResultInterceptor</class>
<class>org.jsr107.ri.annotations.cdi.CachePutInterceptor</class>
<class>org.jsr107.ri.annotations.cdi.CacheRemoveEntryInterceptor</class>
<class>org.jsr107.ri.annotations.cdi.CacheRemoveAllInterceptor</class>
</interceptors>
</beans>

Example method:

@CacheResult
public Optional<User> findUser(@CacheKey String username) {
return userDao.findUser(user);
}
  1. What version of Ehcache you are currently using;
    Ehcache 3.4.0

  2. Paste the configuration for the Cache/CacheManager you have an issue with;
    <ehcache:config xmlns:ehcache="http://www.ehcache.org/v3"
    xmlns:jcache="http://www.ehcache.org/v3/jsr107">

    <ehcache:service>
    <jcache:defaults default-template="defaultTemplate"/>
    </ehcache:service>

    <ehcache:cache-template name="defaultTemplate">
    <ehcache:value-type
    serializer="be.post.min.client.cache.OptionalSerializer"
    copier="be.post.min.client.cache.OptionalCopier">java.util.Optional</ehcache:value-type>
    </ehcache:cache-template>

    <ehcache:default-serializers>
    <ehcache:serializer type="java.util.Optional">be.post.min.client.cache.OptionalSerializer</ehcache:serializer>
    </ehcache:default-serializers>
    <ehcache:default-copiers>
    <ehcache:copier type="java.util.Optional">be.post.min.client.cache.OptionalCopier</ehcache:copier>
    </ehcache:default-copiers>

    </ehcache:config>

  3. Add any name and version of other library or framework you use Ehcache with (e.g. Hibernate);
    - Java EE 6
    - EJB 3.x
    - CDI 1.x
    - JCache 1.0.0 (JSR 107)
    - JSR 107 Cache Annotations CDI RI 1.0.0

  4. Providing JDK and OS versions maybe useful as well.
    - Java SDK 1.8 update 65
    - JBoss EAP 6.4.0
    - Windows 10

Steve Schols

unread,
Aug 30, 2017, 6:30:27 AM8/30/17
to ehcache-users
As an update:

The @CacheKey has to be deleted actually. It has nothing to do with JCache or Ehcache.
It's a remnant of our own AspectJ oriented Caching implementation.

So, just ignore the @CacheKey (I don't seem to be able to update my last message).

Op woensdag 30 augustus 2017 12:15:50 UTC+2 schreef Steve Schols:
Reply all
Reply to author
Forward
0 new messages