This project source code is available on github at https://github.com/deanhiller/playorm.


In today’s applications, if you are not using SLF4j you are way behind. The lead log4j developer left so log4j is pretty much dead and created an interface for all logging which resolves all of the classloading issues that commons-logging had. With SLF4J inerfaces, you can have commons-logging, log4j, jdklogging, and logback all in the same JVM and all working off ONE single configuration file. Every time you grab a 3rd party library, you just need to exclude that library’s log4j and commons-logging an use slf4j. As long as you use PlayOrm, it logs to SLF4J so if your SLF4J implementation is log4j, it uses log4j, if it is logback, it uses logback.
That said, internally during unit testing and such, PlayOrm uses logback. logback is the replacement for log4j but SLF4J can have any implementation you desire.
This means you need to use maven/ivy/grapes/gradle whatever to download your SLF4J implementation as we do not include one for you. We only include the SLF4J api.

To use Play’s Log4J implementation (which means you can configure logging in log4j.properties):
  1. Remove SLF4J-Simple-1.6.1.jar from your lib folder.
  2. Download SL4J and unzip.
  3. Copy SLF4J-API-1.7.2.jar into your lib folder.

Logs to pay attention to

The interface that every provider plugs into is NoSqlRawSession(providers being inmemory, cassandra, hadoop and mongodb). There is a proxy class called NoSqlRawLogger which implements this interface and sits on top of every provider.

Using your logger configuration(whether you use log4j, logback, commons, jdk, jula, etc), you can turn on or off these logs via your logging configuration by specifing “com.alvazan.orm.logging” and the level you would like. (You can’t just use the class as there is actually a few classes that help to log operations occurring on the provider).

You will notice the NoSqlRawSession interface takes alot of byte[] and returns a lot of byte[] but the NoSqlRawLogger knows the meta data for some of your schema and that which it does know, it will translate those into a readable format. It does this for all entities and even does this if you created a schema through the NoSqlTypedSession interface. If you would like something we are missing, please file an issue.

 << Back to Documentation Index