On 25.05.14 17:18, Romain Manni-Bucau wrote: > Extras is a set of useful basic classes for JCache usage. OpenJPA is JCache > support for L2 cache in openjpa. > > The goal is to make what we propose with jcache module as usable as > possible and avoid glue code as much as possible in application code.
>From what I see, caching is something very generic and there is a plethora of strategies that you can use to cache you data. JCS for example is the caching layer for DB-Torque where auxiliaries like JDBCDiskCache would not make sense. Nevertheless they may be used in a different environment, e. g. when the calculation of the data to be cached takes a lot of time. Caching on the level of a request filter only works for simple web applications. Mostly, the lifetimes of page fragments are very different so that caching the complete request is not an option. I'm not sure that such "application examples" or templates should be in the scope of a project like this. I'm not aware of modules with this focus in other projects of Commons, but I may be wrong. What do others think? > I was not that happy to do so but it made default usage really easier and > opened several possibilities (L2 cache wouldn't have been seriousy possible > otherwise since often entities are not serializable for instance). Well, now, then how to handle the case in the current code when a disk cache needs the value to be serializable and it isn't? Throw an exception? Log something? What if fields of objects are not serializable? With the declared interface, FindBugs helps me to track down those problems. Without the declaration, you may find the problem only when you are in production. I hope I can get my concerns across. I like code that helps the developer avoiding errors, that's the whole point of this discussion. > We can create a branch from trunk (to keep code) and go back to a revision > which is ok for you if you want to discuss commits. Isn't this what "Community over Code" is supposed to mean? Peer review, learn from each other, discuss the better concept? Bye, Thomas. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
