[Logo] Terracotta Discussion Forums
  [Search] Search   [Recent Topics] Recent Topics   [Members]  Member Listing   [Groups] Back to home page 
[Register] Register / 
[Login] Login 
[Expert]
How to get cache to differentiate content by requested Content-Type ( json / xml )  XML
Forum Index -> Ehcache
Author Message
chandi

neo

Joined: 02/20/2012 16:16:56
Messages: 2
Offline

If the URL accesses the same resource but the content can be requested in different formats ( json, xml ) via the Content-Type header (as is the case with JAX-RS). How do I generate a cache key that embeds the Content-Type of the response? I guess SimpleCachingHeadersPageCachingFilter will need to be extended to handle this. Are there any examples out there on how to do this?

For example, the first client requests the resource as json and ehcache caches it. However, the second user requests the resource in xml format. However, ehcache does not differentiate between the two and serves the cached json version.

--
Chandi
rajoshi

seraphim

Joined: 07/04/2011 04:36:10
Messages: 1491
Offline

Hi,

Can you please share more details , how you are trying to achieve this . Your use case, source and configuration details.

Rakesh Joshi
Senior Consultant
Terracotta.
chandi

neo

Joined: 02/20/2012 16:16:56
Messages: 2
Offline

So, I'm running a REST backend using Jersey to serve geolocation data in multiple formats (XML and JSON). Here is the stub of the service

Code:
@Path("/map")
 public class MapDataService implements MapData {
 
 	@GET
 	@Path("buildings")
 	@Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
 	public Response getCampusList(@Context Request request) {
 		.....
 		return ....
 	}
 
 }


The data is served in XML ( default ) or JSON format based on the access header in the HTTP request ( JAX-RS does the conversion automatically ).

I want to cache the endpoint URLs for the GET requests as building the geolocation data is i/o heavy. However, hacache by default doesn't take the accept header of the request into account and the cache key just uses the request URL.

I've solved this issue already by creating a custom page caching filter and overriding the caclulateKey method....

CustomHeadersPageCachingFilter

Code:
/**
  * Embed access header in cache key if JSON request
  */
 public class CustomHeadersPageCachingFilter extends
 		SimpleCachingHeadersPageCachingFilter {
 	
 	protected static final String appJSONKey="application/json";
 	protected static final String textJSKey="text/javascript";
 
 	protected String calculateKey(HttpServletRequest httpRequest) {
 		StringBuffer stringBuffer = new StringBuffer();
 		stringBuffer.append(httpRequest.getMethod())
 				.append(httpRequest.getRequestURI())
 				.append(httpRequest.getQueryString());
 		
 		String acceptHeader = httpRequest.getHeader( "Accept" );
 		if ( acceptHeader != null ) {
 			String[] acceptHeaders = acceptHeader.split(",");
 			if ( Arrays.asList(acceptHeaders).contains( appJSONKey ) || Arrays.asList(acceptHeaders).contains( textJSKey ) ) {
 				stringBuffer.append("[" + appJSONKey + "]");
 			}
 		}
 		String key = stringBuffer.toString();
 		return key;
 	}
 
 } 



web.xml

Code:
  <filter>
     <filter-name>MapRESTServicesCachingFilter</filter-name>
     <filter-class>my.domain.com.CustomHeadersPageCachingFilter</filter-class>
     <init-param>
 			<param-name>suppressStackTraces</param-name>
 			<param-value>false</param-value>
 		</init-param>
 		<init-param>
 			<param-name>cacheName</param-name>
 			<param-value>MapRESTServicesCache</param-value>
 		</init-param>
   </filter>
   <filter-mapping>
     <filter-name>MapRESTServicesCachingFilter</filter-name>
     <url-pattern>/rest/map/*</url-pattern>
   </filter-mapping>


I'm a relative noob at this. Hope this is the correct way to handle this situation.
hhuynh

cherubim

Joined: 06/16/2006 11:54:06
Messages: 760
Offline

That's the correct to handle it. If you turn on Ehcache debug logging, you should be able to observe different keys for different request type, as expected.
 
Forum Index -> Ehcache
Go to:   
Powered by JForum 2.1.7 © JForum Team