Play 2.4.3 Cache API

[Thibault Meyer]

Hi,

The CacheAPI provided has built-in (with EHCache) is very nice on development or test mode. But it is not designed to be used on multi-server production environment.

Is it possible to write a new BackEnd (but still using play.cache.Cache.getOrElse(...) in project) using, by exemple Redis ?

playframework.com don't have documentation about this.

Thanks for your help.

[Will Sargent]

Sort of.  The cache documentation on custom implementations is at:

https://www.playframework.com/documentation/2.4.x/ScalaCache#Custom-implementations

You need to provide an implementation of CacheApi.

https://www.playframework.com/documentation/2.4.x/api/scala/index.html#play.api.cache.CacheApi

Unfortunately, the CacheAPI isn't quite as flexible as Spray's:

http://spray.io/documentation/1.2.3/spray-caching/

in the way it handles futures.

You may be able to make some headway by providing an interface to scalacache:

https://github.com/cb372/scalacache

Hope that helps,

Will.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/e74fb8d0-7268-479f-a5f3-5c168a8151d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thibault Meyer]

hi Will,

thank for these links.  Do you know an example of a custom implementation of CacheApi and how to register it ?  I'm new with dependency Injection, I don't see how it can work, how the right implementation (mine rather than default EHCache backend) will be used when i write this on the controller:

    String data  = play.cache.Cache.getOrElse("key", ...);

[Hob Spillane]

Thibault,

If you're looking for Redis support, there's a Redis plugin available for Play.  I used it with some success a while back.  It was fairly easy to install & configure.

https://github.com/typesafehub/play-plugins/tree/master/redis

If you want to implement the CacheApi yourself the trick is having your own Guice module.  The Play documentation doesn't delve too deeply into Guice.  Your module would look something like this:

import com.google.inject.AbstractModule;

class MyModule extends AbstractModule {

  @Override

  protected void configure() {

    bind(CacheApi.class).to(MyCacheImplementation.class);

  }

}

Then you have to make 2 configuration changes in your application.conf

• Disable the EHCacheModule with: play.modules.disabled += "play.api.cache.EhCacheModule"
• Enable your new module with: play.modules.enabled += "path.to.MyModule"
  

Hope that helps.

-Hob

[Thibault Meyer]

great !

thanks you for helping me.

[Igmar Palsenberg]

 

The CacheAPI provided has built-in (with EHCache) is very nice on development or test mode. But it is not designed to be used on multi-server production environment.

Is it possible to write a new BackEnd (but still using play.cache.Cache.getOrElse(...) in project) using, by exemple Redis ?

playframework.com don't have documentation about this.

Play's Cache API is very limited. I've written a version that implements the JSR cache, of course you can use Play's version and DI your implementation.

Igmar 

[Neil Chaudhuri]

To take your example a step further, what if you want to use EhCacheModule in development and MyModule in other modes? Can both modules be enabled simultaneously while only one is injected by mode?

[Neil Chaudhuri]

By the way, this module seems promising for Play-Redis integration as well. It has async support among many other cool features and is actively maintained unlike the other one. On the other hand, there is currently only one contributor at the moment, so if he gets busy, who knows what might happen if others don't help out?

[Igmar Palsenberg]

 

To take your example a step further, what if you want to use EhCacheModule in development and MyModule in other modes? Can both modules be enabled simultaneously while only one is injected by mode?

Sure. Assuming you have : 

@Singleton

public class SomeCacheModule extends AbstractModule {

     SomeCacheModule(Environment environment, Configuration configuration) {

         // Save to private var

     }

     @Override

     protected void configure() {

            if (this.environment.isDev()) {

                 // Do stuff                 

            } else {

                 // Do stuff in prod mode

            }

     }

}

Since we bind multiple versions of the same interface, we use Guice's PrivateModule, so that the injection can be driver by an annotation.

Igmar

[Neil Chaudhuri]

The tricky thing is I am using Scala and Scaldi rather than Java and Guice. So while this may be a Scaldi question primarily, let me ask here just in case anyone has an insight.

I am attempting to use default Play caching (with Ehcache on the backend) in dev while using Redis in test/prod. I am also using the library I mentioned before play-redis. Here is my wiring:

when (inTestMode or inProdMode) {
  bind[EnvironmentConfigurationProvider] toNonLazy new EnvironmentConfigurationProvider("REDIS_URL")
  bind[Configuration] toNonLazy {
    inject[EnvironmentConfigurationProvider].get
  }
  bind[CacheApi] to injected[SyncRedis]
}
bind[CacheApi] when inDevMode to injected[EhCacheApi]

Again, the binding approach is different with Scaldi compared to Guice, but hopefully this is fairly straightforward. Basically, I am binding CacheApi to different implementations based on mode. This gives me the following exception in Dev though:

InjectException: No binding found with following identifiers:
  * TypeTagIdentifier(play.api.cache.redis.EnvironmentConfigurationProvider)

I get the same exception if I remove the bind[CacheApi] lines. The funny thing is that EnvironmentConfigurationProvider is irrelevant in Dev. It is only necessary in Test and Prod when I'm using Redis.

As I said, this may be more of a Scaldi question, but I would appreciate any insight someone has on the caching and general wiring aspect.

Thanks.