Using Camel JCachePolicy with Caffeine in OSGi Blueprint

Question

I want to apply a camel-jcache route policy using a Caffeine cache in OSGi Blueprint. That policy allows to enclose a Camel route or part of a route with a caching facility, which ensures that the result of whatever happens within the route policy will be cached. Consider the following route:

<route id="my-konfig">
    <from uri="direct:my-konfig"/>
    <policy ref="jCachePolicy">
        <toD uri="... some enrichment call..."/>
        <transform>
            ... expensive transformation...
        </transform>
    </policy>
</route>

However, when I add a cache configuration to the blueprint like this:

<reference id="cachingProvider" interface="javax.cache.spi.CachingProvider"/>
<bean id="caffeineCacheManager" factory-ref="cachingProvider" factory-method="getCacheManager"/>
<bean id="caffeineCache" factory-ref="caffeineCacheManager" factory-method="getCache">
    <!-- see src/main/resources/application.conf for cache expiration policy -->
    <argument value="konfig-cache"/>
</bean>
<bean id="jCachePolicy" class="org.apache.camel.component.jcache.policy.JCachePolicy">
    <property name="cache" ref="caffeineCache"/>
    <property name="keyExpression">
        <bean class="org.apache.camel.model.language.SimpleExpression">
            <property name="expression" value="${exchangeProperty.typNr}"/>
        </bean>
    </property>
</bean>

then the blueprint bundle fails to start with a NullPointerException at BeanRecipe.setProperties.

I was able to track this down to a classloader problem. I am asking for a cache named konfig-cache, but the configuration for that cache is located in a file application.conf in the bundle resource (the default location for custom config in Typesafe Config). The OSGi runtime fails to load that file with the default classloaders.

How can I define the classloader which Caffeine's underlying Typesafe Config should use to locate the configuration file in the resource of the Blueprint bundle?

The related dependencies in pom.xml:

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-jsonpath</artifactId>
    <version>${camel.version}</version>
</dependency>
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-jcache</artifactId>
    <version>${camel.version}</version>
</dependency>
<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-caffeine</artifactId>
    <version>${camel.version}</version>
</dependency>
<dependency>
    <groupId>com.github.ben-manes.caffeine</g
    <artifactId>jcache</artifactId>
    <version>2.9.2</version>
</dependency>

And in my Karaf feature.xml:

<feature version="${camel.version}">camel-jcache</feature>
<feature version="${camel.version}">camel-caffeine</feature>
<bundle>mvn:com.github.ben-manes.caffeine/jcache/2.9.2</bundle>
<bundle>mvn:com.typesafe/config/1.4.2</bundle>

Finally, my src/main/resources/application.conf:

# Configuration for camel-caffeine in HOCON format
# see https://github.com/lightbend/config/blob/master/HOCON.md#hocon-human-optimized-config-object-notation
# see https://github.com/lightbend/config#standard-behavior
# see https://github.com/ben-manes/caffeine/blob/master/jcache/src/main/resources/reference.conf
# see example https://github.com/ben-manes/caffeine/blob/master/jcache/src/test/resources/application.conf
caffeine.jcache {

  konfig-cache {
    key-type = java.lang.String
    value-type = java.lang.Object

    # The eviction policy for automatically removing entries from the cache
    policy {
      # The expiration threshold before lazily evicting an entry. This single threshold is reset on
      # every operation where a duration is specified. As expected by the specification, if an entry
      # expires but is not accessed and no resource constraints force eviction, then the expired
      # entry remains in place.
      lazy-expiration {
        # The duration before a newly created entry is considered expired. If set to 0 then the
        # entry is considered to be already expired and will not be added to the cache. May be
        # a time duration or "eternal" to indicate no expiration.
        creation = 60m
        # The duration before a updated entry is considered expired. If set to 0 then the entry is
        # considered immediately expired. May be a time duration, null to indicate no change, or
        # "eternal" to indicate no expiration.
        update = 60m
        # The duration before a read of an entry is considered expired. If set to 0 then the entry
        # is considered immediately expired. May be a time duration, null to indicate no change, or
        # "eternal" to indicate no expiration.
        access = null
      }


      # The expiration thresholds before eagerly evicting an entry. These settings correspond to the
      # expiration supported natively by Caffeine where expired entries are collected during
      # maintenance operations.
      #eager-expiration {
      # Specifies that each entry should be automatically removed from the cache once a fixed
      # duration has elapsed after the entry's creation, or the most recent replacement of its
      # value. This setting cannot be combined with the variable configuration.
      #after-write = null

      # Specifies that each entry should be automatically removed from the cache once a fixed
      # duration has elapsed after the entry's creation, the most recent replacement of its value,
      # or its last read. Access time is reset by all cache read and write operation. This setting
      # cannot be combined with the variable configuration.
      #after-access = null

      # The expiry class to use when calculating the expiration time of cache entries. This
      # setting cannot be combined with after-write or after-access configurations.
      #variable = null
    }

    # The threshold before an entry is eligible to be automatically refreshed when the first stale
    # request for an entry occurs. This setting is honored only when combined with the
    # read-through configuration.
    #refresh {
    # Specifies that active entries are eligible for automatic refresh once a fixed duration has
    # elapsed after the entry's creation or the most recent replacement of its value.
    #after-write = 30s
    #}

    # The maximum bounding of the cache based upon its logical size
    maximum {
      # The maximum number of entries that can be held by the cache. This setting cannot be
      # combined with the weight configuration.
      size = 10
    }
  }
}

Answer 1

The CaffeineCachingProvider allows to pass a classloader to CachingProvider.getCacheManager(URI uri, ClassLoader classLoader).

The expected URI is simply the FQCN of the CaffeineCachingProvider.

Now for the classloader. In OSGi blueprint we can determine the classloader of the blueprint bundle and pass it to getCacheManager. The blueprint spec defines a number of environment managers with predefined reference names, among others the blueprint bundle itself, which goes by the name blueprintBundle. Since we are using Camel anyway, we can use Camel's BundleDelegatingClassLoader to simplify access to the bundle's classloader:

<bean id="caffeineCacheManager" factory-ref="cachingProvider" factory-method="getCacheManager">
    <argument value="com.github.benmanes.caffeine.jcache.spi.CaffeineCachingProvider"/>
    <argument>
        <bean class="org.apache.camel.core.osgi.utils.BundleDelegatingClassLoader">
            <argument ref="blueprintBundle"/>
        </bean>
    </argument>
</bean>