Group items matching

in title, tags, annotations or url

As we have just released the first milestone of the Spring Data JPA project I'd like to give you a quick introduction into its features. As you probably know, the Spring framework provides support to build a JPA based data access layer. So what does Spring Data JPA add to this base support? To answer that question I'd like to start with the data access components for a sample domain implemented using plain JPA + Spring and point out areas that leave room for improvement. After we've done that I will refactor the implementations to use the Spring Data JPA features to address these problem areas. The sample project as well as a step by step guide of the refactoring steps can be found on Github.

Writing your own logging framework is the perfect coding crime. If you can convince your manager to put it on the project plan, you are guaranteed to have success. At the end of each day, you will go home feeling happy and satisfied. It will feel like you are doing something creative. You will get the intellectual stimulation without the risk of failure. Even the Sun engineers fell into this trap. Prior to Java 4, we had a perfectly good logging framework in Log4J. However, instead of adopting this into the standard Java distribution, we ended up with java.util.logging. There are lots of Java logging frameworks available, even meta-logging frameworks like SLF4J and Jakarta Commons. These are supposed to abstract the logging frameworks so you can change the implementation without touching your code. http://www.javaspecialists.eu/archive/Issue177.html

XOM™ is a new XML object model. It is an open source (LGPL), tree-based API for processing XML with Java that strives for correctness, simplicity, and performance, in that order.

HttpClient Cache provides an HTTP/1.1-compliant caching layer to be used with HttpClient--the Java equivalent of a browser cache. The implementation follows the Decorator design pattern, where the CachingHttpClient class is a drop-in replacement for a DefaultHttpClient; requests that can be satisfied entirely from the cache will not result in actual origin requests. Stale cache entries are automatically validated with the origin where possible, using conditional GETs and the If-Modified-Since and/or If-None-Match request headers. HTTP/1.1 caching in general is designed to be semantically transparent; that is, a cache should not change the meaning of the request-response exchange between client and server. As such, it should be safe to drop a CachingHttpClient into an existing compliant client-server relationship. Although the caching module is part of the client from an HTTP protocol point of view, the implementation aims to be compatible with the requirements placed on a transparent caching proxy. Finally, CachingHttpClient includes support the Cache-Control extensions specified by RFC 5861 (stale-if-error and stale-while-revalidate).