Featured FREE Whitepapers

What's New Here?


Exception Handling Guidelines & Best Practices

Let’s review some basic exception design guidelines, summarized from Object Design: Roles, Responsibilities, and Collaborations (Rebecca Wirfs-Brock and Alan McKean, Addison-Wesley, 2003). Don’t try to handle coding errors. Unless your software is required to take extraordinary measures in error scenarios, don’t spend a lot of time designing it to detect and recover from programming errors. In the case of an out-of-bounds array index, divide-by zero error, or any other programming error, the best strategy is to fail fast (and leave an audit trail of the problem that can be used to troubleshoot it). Avoid declaring lots of exception classes. Create a new exception class only when you expect some handling of the code to take a significantly different action, based on the exception type. In my experience it is rarely the case and exception classes available in java API serve the purpose. Recast lower-level exceptions to higher-level ones whenever you raise an abstraction level. Don’t let implementation details leak out of a method invocation as exceptions. Otherwise, your users might think your software is broken. When low-level exceptions percolate up to a high-level handler, there’s little context to assist the handler in making informed decisions or reporting conditions that are traceable to any obvious cause. Recasting an exception whenever you cross an abstraction boundary enables exception handlers higher up in the call chain to make more informed decisions. If you want to include a problem trace when recasting them, you can always create a chained exception. A chained exception provides added context and holds a reference to the original lower level exception. You can repeatedly chain exceptions. Provide context along with an exception. What’s most important in exception handling is information that helps create an informed response. Exception classes hold information. You can design them to be packed with information in addition to the bare-bones stack trace information provided by default. You might include values of parameters that raised the exception, specific error text, or detailed information that could be useful to plan a recovery. Handle exceptions as close to the problem as you can. As a first line of defense, consider the initial requestor. If the caller knows enough to perform a corrective action, you can rectify the condition on the spot. If you propagate an exception far away from the source, it can be difficult to trace the source. Often objects further away from the problem can’t make meaningful decisions. Use exceptions only to signal emergencies. Exceptions shouldn’t be raised to indicate normal branching conditions that will alter the flow in the calling code. For example, a find operation may return zero, one, or many objects, so I wouldn’t raise an exception in this case. Instead, I’d design my find() method to return a null object or an empty collection. A dropped database connection, on the other hand, is a real emergency. There’s nothing that can be done to continue as planned. Don’t repeatedly re-throw the same exception. Although exceptions don’t cost anything until they’re raised, programs that frequently raise exceptions run more slowly. Reference: Exception Handling Guidelines/Best Practices from our JCG partner Sanjeev Kumar at the Architect’s Diary blog....

Building High Performance Applications

Performance is one word which is used to describe multiple scenarios’ when talking about the application performance. When someone says, I need a High Performance Application; it might mean any/all of the following :Low Web latency Application ( meaning low Page Loading times)  Application that can serve ever increasing number of users (scalability)  Application that does not go down (either highly available or continuously available)For each of the above, as an Architect you need to dig deeper to find out what the user is asking for. With the advent of cloud, every CIO is looking to build applications that meet all of the above scenarios. With the advent of elastic compute, one tends to think that by throwing hardware to the application, we may be able to achieve all of the above objectives. The techniques employed to achieve the above scenarios at times are different and it is important to find the right approach to the solution that meets the above objectives. We will examine some of the common techniques that can help us achieve the objectives Latency Contributors  Application Tier ing – One of the biggest contributors to the latency is the application tier ing. The hops from WebServer -> Application Server -> Database and back, data serialization/deserialization are some of the biggest contributor to the overall latency. Having Web and Application tier within the same box or even within same JVM can help reduce the network latency factor. One can have logical separation in the application code between Web Tier and Application Tier but need not have physical separation. Using Spring Container that has Web/App tier can help achieve the same. If the application is making use of SOA and making multiple web services or JMS message calls, network latency and serialization of data once again adds to the latency. Solutions like IBM Datapower XML Accelerators can be used to reduce the XML overheads. Similarly, the application can use Solace Message Router’s to speed up the messaging.  Bring Data closer to Application – Data needs to be close to the application so that making all those Database connection calls and getting data from DB can be reduced. Application can cache data to reduce the calls to DB. One can also use cache servers like memcached / ehCache to cache data at the Web/application Tier. Web Tier can cache data like static HTML fragments/images/javascript/CSS files. Application Tier can cache non-transactional data (like lookup maps). OR Mapping tools like Hibernate also support data caching. If it is an Internet Web Application, one can also make use of CDN (content delivery networks)/ Edge Networks (like Akamai) to speed up the delivery of static content. Disk I/O – Another weak link in the application performance chain is Disk I/O. One way to overcome the limitations with regards to the Disk I/O is too keep data in memory. In Memory databases (like Volt DB or Solid DB or Oracle TimesTen), XTP solutions (like Oracle coherence, IBM eXtreme Scale, GigaSpaces eXtreme Application Platform) can used to speed up the application performance. Optimized Hardware – The hardware on which application is hosted can also be tuned to reduce latency. Optimization s like 10G/20G network, fiber channels, low latency switches, SSD (Solid State Drives), not using virtualization can make sure the application latency is reduced. Transport Mechanism – At times, the transport mechanism can also add to the application latency. E.g. secure communication (like https) can add to the latency with the additional overhead of deciphering the data at the receiving end. One way is to offload the SSL at the Load Balancer/Firewall. In the end, you need to measure anything and everything to address the bottlenecks. Once the obvious bottlenecks have been addressed, one can start looking at things like – cache thrashing, poor algorithms, data bloating, wrong dimensioning etc to squeeze out that ounce of performance. All the techniques mentioned may not be applicable in all scenarios’, the architect needs to take a call based on the latency requirements. Application Scalability  Scalability means ability of an application to handle growing amount of data and concurrency in an efficient manner without impacting performance. Important thing to notice is scalability should not be at the cost of application performance. Some of the techniques that can help scale the application  Stateless Application/Service – The application should store its state in some centralized repository, but the application itself should be stateless. It means no storing of data or state on local file systems. Stateless application allows one to add any number of application instances to accommodate the increasing growth. But soon, the centralized repository starts becoming the bottleneck. With ever increasing data, repositories like (RDBMS) may start buckling down. One approach to this issue is to minimize mutable state in the database. To handle such scenarios, techniques like data sharding need to be applied. Another approach to managing write contention in the database is to look at the possibility of using NoSQL data stores for some or all of the application data.  Load Balancing – As the traffic starts going up, the application can handle the additional load by adding additional server instances to service the requests. The load balancer will make sure none of the servers are working beyond their stated load and new instance should be automatically added as and when the load goes up (auto scaling). One can also add load balance to database with techniques like Master-Master topology or Master-Slave(with partitioning read and write data) to handle the additional load. But if the data is going in Petabytes ranges, data sharding with data replication techniques need to be used. The in-memory data grid architecture can also be utilized to scale the data.  Fault Tolerance / Dynamic Discoverable Elements – When dealing with application that is running in large clusters, it is very important to avoid manual interventions. E.g. when the application load reaches a defined load, the application monitoring should be able to add a new instance and load balancer should be able to recognize the same to utilize it. Similarly, when data gets shard, the applications should be able to recognize and look up the new IP to connect. Similarly, if the application is not able to connect to particular resource, the application should be intelligent enough to recognize the fault and try accessing the alternate resource availability. The application will need to have a central meta data repository for all such fault tolerance scenarios that can be tapped by the application.  Application availability  Availability of an application is very much a function of scalability. Following factors have an impact on the application availability  Redundancy – The application needs to be scalable to be able to compensate for the loss of any instance (whether hardware or software). The redundancy needs to be build at all layers, Software, Hardware, Power and even at data center levels. Even if the data center goes, the user should be able to access the application. Many at times, the level of redundancy and down time is a factor of how money is being thrown at the solution. Remember some problems have no solutions within the context of today’s technology. E.g. real time data mirroring or data sync across data centers that are located geographically apart.  Fault Tolerance – The application needs to be fault tolerant (e.g. retry mechanism) to make sure it can take advantage of dynamically allocated resources to keep functioning.  Monitoring/Testing – Another overlooked factor of application availability is application monitoring. If application is not properly monitored, outages can go undetected leading to application unavailability. Ability to monitor the entire application stack and take corrective actions is very important. This capability is build over a period of time. Once the application has monitoring, auto-scaling features, testing to make sure they work is also important. Something like Chaos Monkey used by Netflix is very helpful.  Configuration Data – Any application that needs to be continuously available needs to be able to run using configuration. E.g. if the application introduces the new service interface, the application should have the ability to either make use of the new interface or keep using the old one. This factor becomes very important when rolling out new features/services and all of them cannot be rolled out at once. Reference: Building High Performance Applications from our JCG partner Munish K Gupta  at the Tech Spot blog....

Spring Remoting Support with Http Invoker

Spring HTTP Invoker is an important solution for Java-to-Java Remoting. This technology uses the standard Java serialization mechanism to expose services through HTTP and can be thought as an alternative solution instead of the custom serialization found in Hessian and Burlap. Also, it is only provided by Spring so both client and server applications have to be based on Spring. Spring supports HTTP invoker infrastructure via HttpInvokerProxyFactoryBean and HttpInvokerServiceExporter. HttpInvokerServiceExporter that exports the specified service bean as HTTP invoker service endpoint, accessible via an HTTP invoker proxy. HttpInvokerProxyFactoryBean is a factory bean for HTTP invoker proxies. Also Spring Remoting Support & RMI article is offered for Spring Remoting introduction and RMI Service & Client sample project. Let us look at Spring Remoting Support to develop Http Invoker Service & Client. Used Technologies :JDK 1.6.0_31  Spring 3.1.1  Tomcat 7.0  Maven 3.0.2STEP 1 : CREATE MAVEN PROJECT A maven project is created as below. (It can be created by using Maven or IDE Plug-in). STEP 2 : LIBRARIES Spring dependencies are added to Maven’ s pom.xml. <!-- Spring 3.1.x dependencies --> <properties> <spring.version>3.1.1.RELEASE</spring.version> </properties> <dependencies> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-core</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-context</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-remoting</artifactId> <version>2.0.8</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-web</artifactId> <version>${spring.version}</version> </dependency> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>${spring.version}</version> </dependency> <dependencies>STEP 3 : CREATE USER CLASS A new User Class is created. package com.otv.user; import java.io.Serializable; /** * User Bean * * @author onlinetechvision.com * @since 24 Feb 2012 * @version 1.0.0 * */ public class User implements Serializable { private long id; private String name; private String surname; /** * Get User Id * * @return long id */ public long getId() { return id; } /** * Set User Id * * @param long id */ public void setId(long id) { this.id = id; } /** * Get User Name * * @return long id */ public String getName() { return name; } /** * Set User Name * * @param String name */ public void setName(String name) { this.name = name; } /** * Get User Surname * * @return long id */ public String getSurname() { return surname; } /** * Set User Surname * * @param String surname */ public void setSurname(String surname) { this.surname = surname; } @Override public String toString() { StringBuilder strBuilder = new StringBuilder(); strBuilder.append("Id : ").append(getId()); strBuilder.append(", Name : ").append(getName()); strBuilder.append(", Surname : ").append(getSurname()); return strBuilder.toString(); } }STEP 4 : CREATE ICacheService INTERFACE ICacheService Interface representing a remote cache service interface, is created. package com.otv.cache.service; import java.util.concurrent.ConcurrentHashMap; import com.otv.user.User; /** * Cache Service Interface * * @author onlinetechvision.com * @since 10 Mar 2012 * @version 1.0.0 * */ public interface ICacheService { /** * Get User Map * * @return ConcurrentHashMap User Map */ public ConcurrentHashMap<Long, User> getUserMap(); }STEP 5 : CREATE CacheService CLASS CacheService Class is created by implementing ICacheService Interface. It provides access to the remote cache… package com.otv.cache.service; import java.util.concurrent.ConcurrentHashMap; import com.otv.user.User; /** * Cache Service Implementation * * @author onlinetechvision.com * @since 10 Mar 2012 * @version 1.0.0 * */ public class CacheService implements ICacheService { //User Map is injected... ConcurrentHashMap<Long, User> userMap; /** * Get User Map * * @return ConcurrentHashMap User Map */ public ConcurrentHashMap<Long, User> getUserMap() { return userMap; } /** * Set User Map * * @param ConcurrentHashMap User Map */ public void setUserMap(ConcurrentHashMap<Long, User> userMap) { this.userMap = userMap; } }STEP 6 : CREATE IHttpUserService INTERFACE IHttpUserService representing Http user service interface, is created. Also, it provides remote methods for the Http Clients… package com.otv.http.server; import java.util.List; import com.otv.user.User; /** * Http User Service Interface * * @author onlinetechvision.com * @since 10 Mar 2012 * @version 1.0.0 * */ public interface IHttpUserService { /** * Add User * * @param User user * @return boolean response of the method */ public boolean addUser(User user); /** * Delete User * * @param User user * @return boolean response of the method */ public boolean deleteUser(User user); /** * Get User List * * @return List user list */ public List<User> getUserList(); }STEP 7 : CREATE HttpUserService CLASS HttpUserService Class is created by implementing IHttpUserService Interface. package com.otv.http.server; import java.util.ArrayList; import java.util.List; import org.apache.log4j.Logger; import com.otv.cache.service.ICacheService; import com.otv.user.User; /** * Http User Service Implementation * * @author onlinetechvision.com * @since 10 Mar 2012 * @version 1.0.0 * */ public class HttpUserService implements IHttpUserService { private static Logger logger = Logger.getLogger(HttpUserService.class); //Remote Cache Service is injected... ICacheService cacheService; /** * Add User * * @param User user * @return boolean response of the method */ public boolean addUser(User user) { getCacheService().getUserMap().put(user.getId(), user); logger.debug("User has been added to cache. User : "+getCacheService().getUserMap().get(user.getId())); return true; } /** * Delete User * * @param User user * @return boolean response of the method */ public boolean deleteUser(User user) { getCacheService().getUserMap().remove(user.getId()); logger.debug("User has been deleted from cache. User : "+user); return true; } /** * Get User List * * @return List user list */ public List<User> getUserList() { List<User> list = new ArrayList<User>(); list.addAll(getCacheService().getUserMap().values()); logger.debug("User List : "+list); return list; } /** * Get Remote Cache Service * * @return ICacheService Remote Cache Service */ public ICacheService getCacheService() { return cacheService; } /** * Set Remote Cache Service * * @param ICacheService Remote Cache Service */ public void setCacheService(ICacheService cacheService) { this.cacheService = cacheService; } }STEP 8 : CREATE HttpUserService-servlet.xml HttpUserService Application Context is shown as follows. This xml has to be named as your_servlet_name-servlet.xml <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:util="http://www.springframework.org/schema/util" xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-3.0.xsdhttp://www.springframework.org/schema/utilhttp://www.springframework.org/schema/util/spring-util-3.0.xsd"> <!-- User Map Declaration --> <bean id="UserMap" class="java.util.concurrent.ConcurrentHashMap" /> <!-- Cache Service Declaration --> <bean id="CacheService" class="com.otv.cache.service.CacheService"> <property name="userMap" ref="UserMap"/> </bean> <!-- Http User Service Bean Declaration --> <bean id="HttpUserService" class="com.otv.http.server.HttpUserService" > <property name="cacheService" ref="CacheService"/> </bean> <!-- Http Invoker Service Declaration --> <bean id="HttpUserServiceExporter" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter"> <!-- service represents Service Impl --> <property name="service" ref="HttpUserService"/> <!-- serviceInterface represents Http Service Interface which is exposed --> <property name="serviceInterface" value="com.otv.http.server.IHttpUserService"/> </bean> <!-- Mapping configurations from URLs to request handler beans --> <bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="mappings"> <props> <prop key="/HttpUserService">HttpUserServiceExporter</prop> </props> </property> </bean> </beans>STEP 9 : CREATE web.xml web.xml is configured as follows : <?xml version="1.0" encoding="UTF-8"?> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5"> <display-name>OTV_SpringHttpInvoker</display-name> <!-- Spring Context Configuration' s Path definition --> <context-param> <param-name>contextConfigLocation</param-name> <param-value> /WEB-INF/HttpUserService-servlet.xml </param-value> </context-param> <!-- The Bootstrap listener to start up and shut down Spring's root WebApplicationContext. It is registered to Servlet Container --> <listener> <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class> </listener> <!-- Central dispatcher for HTTP-based remote service exporters. Dispatches to registered handlers for processing web requests.--> <servlet> <servlet-name>HttpUserService</servlet-name> <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class> <load-on-startup>2</load-on-startup> </servlet> <!-- Servlets should be registered with servlet container and mapped with url for the http requests. --> <servlet-mapping> <servlet-name>HttpUserService</servlet-name> <url-pattern>/HttpUserService</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>/pages/index.xhtml</welcome-file> </welcome-file-list> </web-app>STEP 10 : CREATE HttpUserServiceClient CLASSHttpUserServiceClient Class is created. It calls the Remote Http User Service and performs user operations. package com.otv.http.client; import org.apache.log4j.Logger; import org.springframework.context.ApplicationContext; import org.springframework.context.support.ClassPathXmlApplicationContext; import com.otv.http.server.IHttpUserService; import com.otv.user.User; /** * Http User Service Client * * @author onlinetechvision.com * @since 24 Feb 2012 * @version 1.0.0 * */ public class HttpUserServiceClient { private static Logger logger = Logger.getLogger(HttpUserServiceClient.class); /** * Main method of the Http User Service Client * */ public static void main(String[] args) { logger.debug("Http User Service Client is starting..."); //Http Client Application Context is started... ApplicationContext context = new ClassPathXmlApplicationContext("httpClientAppContext.xml"); //Remote User Service is called via Http Client Application Context... IHttpUserService httpClient = (IHttpUserService) context.getBean("HttpUserService"); //New User is created... User user = new User(); user.setId(1); user.setName("Bruce"); user.setSurname("Willis"); //The user is added to the remote cache... httpClient.addUser(user); //The users are gotten via remote cache... httpClient.getUserList(); //The user is deleted from remote cache... httpClient.deleteUser(user); logger.debug("Http User Service Client is stopped..."); } }STEP 11 : CREATE httpClientAppContext.xml Http Client Application Context is shown as follows : <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"> <!-- Http Invoker Client Declaration --> <bean id="HttpUserService" class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean"> <!-- serviceUrl demonstrates Http Service Url which is called--> <property name="serviceUrl" value="http://remotehost:port/OTV_SpringHttpInvoker-0.0.1-SNAPSHOT/HttpUserService"/> <!-- serviceInterface demonstrates Http Service Interface which is called --> <property name="serviceInterface" value="com.otv.http.server.IHttpUserService"/> </bean> </beans>STEP 12 : DEPLOY PROJECT After OTV_SpringHttpInvoker Project is deployed to Tomcat, Http User Service Client is started and output logs are shown as follows : .... 15.03.2012 21:26:41 DEBUG (DispatcherServlet.java:819) - DispatcherServlet with name 'HttpUserService' processing POST request for [/OTV_SpringHttpInvoker-0.0.1-SNAPSHOT/HttpUserService] 15.03.2012 21:26:41 DEBUG (AbstractUrlHandlerMapping.java:124) - Mapping [/HttpUserService] to HandlerExecutionChain with handler [org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter@f9104a] and 1 interceptor 15.03.2012 21:26:41 DEBUG (RemoteInvocationTraceInterceptor.java:73) - Incoming HttpInvokerServiceExporter remote call: com.otv.http.server.IHttpUserService.addUser 15.03.2012 21:26:41 DEBUG (HttpUserService.java:33) - User has been added to cache. User : Id : 1, Name : Bruce, Surname : Willis 15.03.2012 21:26:41 DEBUG (RemoteInvocationTraceInterceptor.java:79) - Finished processing of HttpInvokerServiceExporter remote call: com.otv.http.server.IHttpUserService.addUser 15.03.2012 21:26:41 DEBUG (DispatcherServlet.java:957) - Null ModelAndView returned to DispatcherServlet with name 'HttpUserService': assuming HandlerAdapter completed request handling 15.03.2012 21:26:41 DEBUG (FrameworkServlet.java:913) - Successfully completed request 15.03.2012 21:26:41 DEBUG (DispatcherServlet.java:819) - DispatcherServlet with name 'HttpUserService' processing POST request for [/OTV_SpringHttpInvoker-0.0.1-SNAPSHOT/HttpUserService] 15.03.2012 21:26:41 DEBUG (AbstractUrlHandlerMapping.java:124) - Mapping [/HttpUserService] to HandlerExecutionChain with handler [org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter@f9104a] and 1 interceptor 15.03.2012 21:26:41 DEBUG (RemoteInvocationTraceInterceptor.java:73) - Incoming HttpInvokerServiceExporter remote call: com.otv.http.server.IHttpUserService.getUserList 15.03.2012 21:26:41 DEBUG (HttpUserService.java:57) - User List : [Id : 1, Name : Bruce, Surname : Willis] 15.03.2012 21:26:41 DEBUG (RemoteInvocationTraceInterceptor.java:79) - Finished processing of HttpInvokerServiceExporter remote call: com.otv.http.server.IHttpUserService.getUserList 15.03.2012 21:26:41 DEBUG (DispatcherServlet.java:957) - Null ModelAndView returned to DispatcherServlet with name 'HttpUserService': assuming HandlerAdapter completed request handling 15.03.2012 21:26:41 DEBUG (FrameworkServlet.java:913) - Successfully completed request 15.03.2012 21:26:41 DEBUG (DispatcherServlet.java:819) - DispatcherServlet with name 'HttpUserService' processing POST request for [/OTV_SpringHttpInvoker-0.0.1-SNAPSHOT/HttpUserService] 15.03.2012 21:26:41 DEBUG (AbstractUrlHandlerMapping.java:124) - Mapping [/HttpUserService] to HandlerExecutionChain with handler [org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter@f9104a] and 1 interceptor 15.03.2012 21:26:41 DEBUG (RemoteInvocationTraceInterceptor.java:73) - Incoming HttpInvokerServiceExporter remote call: com.otv.http.server.IHttpUserService.deleteUser 15.03.2012 21:26:41 DEBUG (HttpUserService.java:45) - User has been deleted from cache. User : Id : 1, Name : Bruce, Surname : Willis 15.03.2012 21:26:41 DEBUG (RemoteInvocationTraceInterceptor.java:79) - Finished processing of HttpInvokerServiceExporter remote call: com.otv.http.server.IHttpUserService.deleteUser 15.03.2012 21:26:41 DEBUG (DispatcherServlet.java:957) - Null ModelAndView returned to DispatcherServlet with name 'HttpUserService': assuming HandlerAdapter completed request handling 15.03.2012 21:26:41 DEBUG (FrameworkServlet.java:913) - Successfully completed request ...STEP 13 : DOWNLOAD OTV_SpringHttpInvoker Reference: Spring Remoting Support with Http Invoker from our JCG partner Eren Avsarogullari at the Online Technology Vision blog....

Exposing Functionality Over HTTP with Groovy and Ultra-Lightweight HTTP Servers

I needed a quick and simple way to enable some users to query a table and figured out that the easiest solution was to use an embedded, ligthweight HTTP server so that the users could type a URL in their browser and get the results. The question was, of course, which server is best for it. I’d like to summarize here the options I’ve discovered – including Gretty, Jetty, Restlet, Jersey and others – and their pros & cons together with complete examples for most of them. I’ve on purpose avoided various frameworks that might support this easily such as Grails because it didn’t feel really lightweight and I needed only a very simple, temporary application. I used Groovy for its high productivity, especially regarding JDBC – with GSQL I needed only two lines to get the data from a DB in a user-friendly format. My ideal solution would make it possible to start the server with support for HTTPS and authorization and declare handlers for URLs programatically, in a single file (Groovy script), in just few lines of code. (Very similar to the Gretty solution below + the security stuff.) Side Notes Note on Grape Grape, the Groovy packaging engine, makes it possible to download dependencies at runtime via @Grab annotations. If you run your groovy script f.ex. via /bin/groovy then it will just work because Groovy is distributed together with Ivy, which is required for Grape to work. (If using IntelliJ then add ivy.jar manually to the project’s classpath and then invoke intention action (Mac: Alt+Enter) on the @Grab annotation to download it and add it to the classpath.) Note on HTTPS/SSL Configuration To enable HTTPS, you will need to create a keystore with a key pair, which is well described in the documentation of Jetty (step 1a). For the impatient:Run  keytool -keystore $HOME/.keystore -alias myGroovyServer -genkey -keyalg RSAWhen asked “What is your first and last name?”, provide the hostname where the service will be running, e.g. “localhost” or “myserver.example.com” Specify the same password for the keystore and the generated key (e.g. “myKeystorePsw”) When running the server, supply the (absolute) path to the generated file .keystore (in a server-specific way) and set the system property javax.net.ssl.keyStorePassword to the password1. Simple HTTP Request and Response Solutions Attempt 1: Gretty Gretty is a Groovy wrapper for Netty, the asynchronous web server, and is written in Groovy++. (Intro article for Gretty.) Pros: Well integrated with Groovy, simple to get started with, supports serving static resources and more, Netty is cool. Cons: Undocumented, the project seems to be dormant, no clear way to add user authorization and HTTPS. The code: @GrabConfig(systemClassLoader=true) @GrabResolver(name='gretty', root='http://groovypp.artifactoryonline.com/groovypp/libs-releases-local') @Grapes([ @Grab('org.mbte.groovypp:gretty:0.4.279'), @Grab('mysql:mysql-connector-java:5.1.16')])import org.mbte.gretty.httpserver.* import groovy.sql.Sqlclass Main {final def db = [url: 'jdbc:mysql://localhost:3306/user', user: 'dbUser', psw: 'dbPsw' ]def run() { startServer() }def getUser(def code) { println "Connecting to the DB to check '$code'..." def sql = Sql.newInstance( db.url, db.user, db.psw) return sql.firstRow("select * from users where code = $code") ?: "No such code found" }def startServer() { GrettyServer server = [] server.groovy = [ localAddress: new InetSocketAddress(6789), // no host => all defaultHandler: { response.redirect "/" }, "/:code": { get { def user = getUser(it.code) response.text = "The code '${it.code}' refers to $user\n" // => st. like: "The code 'abc' refers to [id:123, name:me@somewhere.no, code:abc]" } } ] server.start() println "Groovy server is ready to serve" } }new Main().run()Jetty Pros: Mature, powerful, often used in the embedded form, supports HTTPS and authorization (also programatically). Pitfall: You cannot use org.eclipse.jetty:jetty-server because Grape.grab will fail to download the dependency org.eclipse.jetty.orbit:javax.servlet due to Ivy getting confused by packaging vs. extension. Use org.eclipse.jetty.aggregate:jetty-server instead (the Jetty aggregate packages merge multiple smaller JARs). Example: Jetty with Security (based on the articles about Embedding Jetty (including SSL) for programatic configuration and handling requests via a custom handler or servlet (very well written indeed) and How to Configure Security with Embedded Jetty for programatic configuration of authentication and authorization) import groovy.sql.Sql import javax.servlet.* import javax.servlet.http.* import org.eclipse.jetty.server.* import org.eclipse.jetty.server.ssl.SslSelectChannelConnector import org.eclipse.jetty.servlet.* import org.eclipse.jetty.security.* import org.eclipse.jetty.util.security.*@GrabConfig(systemClassLoader = true) @Grapes([ @Grab('org.eclipse.jetty.aggregate:jetty-server:8.1.2.v20120308'), @Grab('org.eclipse.jetty.aggregate:jetty-servlet:8.1.2.v20120308'), @Grab(group='javax.servlet', module='javax.servlet-api', version='3.0.1'), @Grab('mysql:mysql-connector-java:5.1.16')]) class Main extends HttpServlet {final def db = [url: 'jdbc:mysql://localhost:3306/user', user: 'dbUser', psw: 'dbPsw' ]protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { final String code = request.pathInfo.substring(1); // skip leading '/' response.setContentType("text/plain");try { def user = getUser(code) response.setStatus(HttpServletResponse.SC_OK); response.getWriter().println("Usage of the code '${code}': $user\n") } catch (Exception e) { response.setStatus(HttpServletResponse.SC_INTERNAL_SERVER_ERROR) response.getWriter().println("Connection to the database failed. This may be due to temporary " + "connection problems or due to misconfiguration. Try later.") } }def getUser(def code) { println "Connecting to the DB to check '$code'..." def sql = Sql.newInstance( db.url, db.user, db.psw) return sql.firstRow("select * from users where code = $code") ?: "No such code found" }public static startServer() { Server server = new Server(); server.setHandler(createServletHandlerWithAuthentication( "/", new Main(), createAuthenticationConstraint())) server.setConnectors((Connector[])[createSslConnector()]) server.start(); server.join(); }/** Wrap the servlet in the servlet handler and configure it to run at the given URL, setting its security handler. */ private static createServletHandlerWithAuthentication(String contextPath, Servlet servlet, SecurityHandler securityHandler) { final String pathSpec = "/*" ServletContextHandler servletHandler = new ServletContextHandler(ServletContextHandler.NO_SESSIONS) servletHandler.setContextPath(contextPath) servletHandler.setSecurityHandler(securityHandler) servletHandler.addServlet(new ServletHolder(servlet), pathSpec) return servletHandler }/** Create HTTPS connector running at port 6789 and using key pair from the hard-coded keystore. */ private static Connector createSslConnector() { SslSelectChannelConnector ssl_connector = new SslSelectChannelConnector() ssl_connector.setPort(6789)def cf = ssl_connector.getSslContextFactory() cf.setKeyStore(System.getProperty("user.home") + "/.keystore") cf.setKeyStorePassword("myKeystorePsw") cf.setKeyManagerPassword("myKeystorePsw")return ssl_connector }/** Create a security handler requiring authentication with username/password. */ private static SecurityHandler createAuthenticationConstraint() { Constraint constraint = new Constraint(); constraint.setName(Constraint.__BASIC_AUTH); constraint.setRoles((String[])["user"]); constraint.setAuthenticate(true);ConstraintMapping cm = new ConstraintMapping(); cm.setConstraint(constraint); cm.setPathSpec("/*"); // auth. required for any URLdef loginSrv = new HashLoginService() loginSrv.putUser("myLogin", new Password("myPassword"), (String[])["user"]) loginSrv.setName("My App Realm")SecurityHandler sh = new ConstraintSecurityHandler() sh.setLoginService(loginSrv) sh.setConstraintMappings((ConstraintMapping[])[cm]);return sh } }Main.startServer()Additional resources:Post: Embedded Groovy executing Groovlets (Groovy scripts with access to request/response and support for generating HTML) Post: A Groovy+Jetty blog featuring support for command-line arguments, @Grab, and serving of static resources Post: Enabling HTTPS for an Embedded Jetty Winstone Winstone is a 200KB servlet container available via Maven, last release 2008. It seems to be focused on serving WARs. Sun Java 6 HttpServer Sun JRE 6+ contains a ligthweight, programmatically controled HTTP server, supporting also HTTPS. Example code. 2. REST-based Solutions Jersey JAX-RS Jersey, the reference implementation of JAX-RS (aka REST), can run on an embedded test server such as Grizzly, GlassFish, or Jetty. Pros: The reference implementation of JAX-RS, i.e. standard. Cons: Troubleshooting Jersey isn’t as easy as I’d like it to be. The documentation should be better (compare to Jetty’s), this is really a weak point (try to find anything about securing Jersey with an embedded Grizzly). Example: Jersey with embedded Grizzly, without security (If interested in security and authentication, check out the sample project https-clientserver-grizzly. It seems little to complex to me.) import groovy.sql.Sqlimport javax.ws.rs.* import javax.ws.rs.core.* import com.sun.jersey.api.core.* import com.sun.jersey.api.container.grizzly2.GrizzlyServerFactory import org.glassfish.grizzly.http.server.HttpServer@GrabConfig(systemClassLoader = true) @GrabResolver(name = 'gretty', root = 'http://groovypp.artifactoryonline.com/groovypp/libs-releases-local') @Grapes([ @Grab('com.sun.jersey:jersey-server:1.12'), @Grab('com.sun.jersey:jersey-core:1.12'), @Grab(group='com.sun.jersey', module='jersey-grizzly2', version='1.12'), @Grab(group='javax.ws.rs', module='jsr311-api', version='1.1.1'), @Grab('mysql:mysql-connector-java:5.1.16')])@Path("/{code}") class Main {final def db = [url: 'jdbc:mysql://localhost:3306/user', user: 'dbUser', psw: 'dbPsw' ]@GET @Produces("text/plain") public Response getUserByCode(@PathParam('code') String code) { try { def user = getUser(code) return Response.ok().entity("Usage of the code '${code}': $user\n".toString()).build(); } catch (Exception e) { Response.serverError().entity("Connection to the database failed. This may be due to temporary " + "connection problems or due to misconfiguration. Try later. Cause: $e".toString()).build(); } }def getUser(def code) { println "Connecting to the DB to check '$code'..." def sql = Sql.newInstance( db.url, db.user, db.psw) return sql.firstRow("select * from users where code = $code") ?: "No such code found" }public static startServer() { ResourceConfig resources = new ClassNamesResourceConfig(Main) def uri = UriBuilder.fromUri("http://localhost/").port(6789).build(); HttpServer httpServer = GrizzlyServerFactory.createHttpServer(uri, resources); println("Jersey app started with WADL available at ${uri}application.wadl") System.in.read(); httpServer.stop(); } }Main.startServer()RESTEasy with an Embedded TJWS (Tiny Java Web Server and Servlet Container) TJWS is trully miniature, 100KB footprint, runs also on Android, about 5 times smaller than the competitors LWS and Jetty. From the RESTEasy documentation: @Path("") public class MyResource {@GET public String get() { return "hello world"; }public static void main(String[] args) throws Exception { TJWSEmbeddedJaxrsServer tjws = new TJWSEmbeddedJaxrsServer(); tjws.setPort(8081); tjws.getRegistry().addPerRequestResource(MyResource.class); tjws.start(); } }TJWS itself supports SSL, I’m not sure about the JBoss TJWS plugin for RESTEasy (which is the only version of tjws availabe in Maven). It can be also embedded but isn’t available via Maven and I don’t know if it supports mapping of requests to code (instead of WARs and JSPs). Restlet with an Embedded Server See the article Building RESTful Web Apps with Groovy and Restlet, Part 1: Up and Running (2008). As Restlet is available in Maven, we could just @Grab the dependencies. What is even more interesting is the GroovyRestlet module that let you configure authorization and request handling programatically, with only few lines. (You can do this also in Java, with some more LoC.) Doc for the release 2.1: How to implement authorization and HTTPS, the simplest possible REST server in ~ 6 lines of Java. (Notice that Restlet comes with a simple HTTP server but can also use Jetty or Grizzly.) Pros: RESt (though non-standard), good integration with Groovy (though it might be outdated) Cons: As of 4/2012 Restlet is only in its private Maven repository though they’re going to be in Maven Central too, JAX-RS support isn’t fully implemented yet (Restlet 2.1-RC3). The documentation could be better (more comprehensive, more interlinked, more varied examples). To use HTTPS you must choose some other server than the internal one. Example: Restlet + SimpleFramework Server + HTTPS and Authentication (w/o Groovy integration) import groovy.sql.Sql import org.restlet.* import org.restlet.data.* import org.restlet.resource.* import org.restlet.security.*@GrabConfig(systemClassLoader = true) @GrabResolver(name = 'gretty', root = 'http://groovypp.artifactoryonline.com/groovypp/libs-releases-local') @GrabResolver(name = 'restlet', root = 'http://maven.restlet.org') @Grapes([ @Grab('org.restlet.jse:org.restlet:2.1-RC3'), @Grab('org.restlet.jse:org.restlet.ext.simple:2.1-RC3'), @Grab('mysql:mysql-connector-java:5.1.16')]) class Main extends ServerResource {final def db = [url: 'jdbc:mysql://localhost:3306/user', user: 'dbUser', psw: 'dbPsw' ]@Get public String getUser() { def code = getRequestAttributes().get("code") def user = getUser(code) return "Usage of the code '${code}': $user\n" }def getUser(def code) {println "Connecting to the DB to check '$code'..." def sql = Sql.newInstance( db.url, db.user, db.psw) return sql.firstRow("select * from users where code = $code") ?: "No such code found" }public static startServer() { Component component = new Component(); def userResourceFinder = component.getDefaultHost().createFinder(Main.class); component.getDefaultHost().attach("/{code}" , wrapResourceInAuthenticationCheck(component.getContext(), userResourceFinder)); configureHttpsServer(component, 6789) component.start() }/** * Add a Guard (a filter) that asks the user for username/password and checks it against a map. */ private static Restlet wrapResourceInAuthenticationCheck(Context context, Restlet resource) { MapVerifier verifier = new MapVerifier(); verifier.getLocalSecrets().put("myLogin", "myPassword".toCharArray());ChallengeAuthenticator guard = new ChallengeAuthenticator(context.createChildContext(), ChallengeScheme.HTTP_BASIC, "My App"); guard.setVerifier(verifier); guard.setNext(resource);return guard; }/** * Create the server, instruct it to use a SslContextFactory, and configure the factory with * our keystore and password. I guess that which server to use is determined by Restlet based on which * package (*.ext.simple.*, *.ext.jetty.* etc.) is available. */ private static void configureHttpsServer(Component component, int port) { def secureServer = component.getServers().add(Protocol.HTTPS, port);// See http://www.restlet.org/documentation/2.1/jse/ext/org/restlet/ext/ssl/DefaultSslContextFactory.html // for params such as keystore path and password System.setProperty("javax.net.ssl.keyStorePassword", "myKeystorePsw") // used for keystorePassword & keyPassword def confg = secureServer.getContext().getParameters() confg.add("sslContextFactory", "org.restlet.ext.ssl.DefaultSslContextFactory") // Beware: keystorePath shall default to ${user.home}/.keystore but doesn't seem to do so => set it explicitly confg.add("keystorePath", "${System.getProperty('user.home')}/.keystore") } }Main.startServer()ConclusionI’d perhaps use either Jetty if REST isn’t needed and Jersey+Jetty otherwise (I’d certainly pick Jetty over Grizzly as the documentation is much better). Restlet might be interesting too provided that the Groovy integration works and if you don’t mind using a non-standard REST implementation. Looking at the length of the code samples it might have been better to try Grails or st. similar after all Reference: Exposing Functionality Over HTTP with Groovy and Ultra-Lightweight HTTP Servers from our JCG partner Jakub Holy at the The Holy Java blog....

The all-new Play Module Repository

Back in November, I spoke to Nicolas Leroux of the Play framework about creating a module repository. He agreed it would be a good idea, but lack of time has prevented me from starting this. Following the stormy events of last week in the Play Google Group, I’ve decided to prioritise it. A working prototype should be available in a couple of weeks. The overview: 1. It’s open source  Obviously 2. It’s written in Play 2  Just to piss off the nay-sayers 3. Module creation At the moment, to get a module into the module repository you have to get authorisation from a member of the Play team. I want to have a repo where you can upload any module, as long as it conforms to certain minimum requirements. These area README file a license (preferably, but not constrained to, a business-friendly one) actual code, to prevent a bunch of empty modules being created4. Open accounts  Users can create accounts by logging in via twitter, facebook, etc, and link multiple sign-in methods to their accounts. 5. Security  Authentication will come via SecureSocial (so Jorge Aliss needs to start coding!) and authorisation will be implemented in Deadbolt 2. As a result, this will supercede the SociallySecure example app which showed how to integrate the two. 6. Modules are web-accessible   Modules can be downloaded directly through the browser 7. Modules are framework-accessible  Regardless of the version of Play, and therefore regardless of the dependency mechansim, the repository will serve modules directly to the framework. In other words, when you add modules to dependencies.yml or Build.scala, those modules will be fetched by the framework. Manual installation is not required. 8. Voting Any logged-in user can vote up a module. One vote per module, to keep things fair. 9. Commenting  Any logged-in user can comment. Because of the open sign-in method, I think it doesn’t make sense to have anonymous comments. Trolls can go elsewhere. 10. Play 1 modules  Play 1 modules will be hosted directly in the repo. 11. Play 2 modules  Play 2 modules can also be hosted in the repo, but since they can also be hosted in any Maven or Ivy repo it’s possible to link to the remote repo instead. This doesn’t impact point #7 since it will be transparent to the framework itself. 12. No ambiguity One very important point comes from Ben Verbeken – “We’ll just have to make sure it’s really obvious to the visitor that they are browsing either the play 1 or play 2 modules (no hidden filter feature, but a big red switch at the top e.g. )” The github repository (which is currently empty, because it was created nine minutes ago) can be found at https://github.com/playframework/modules.playframework.org At the moment, we’re purely at the planning stage but I plan to use my favourite development style (evolutionary prototying) to get something up and working fast. The github repo will be created tonight, and regular updates will be posted here. Peter Hilton has posted some more details over at the Play Google Group. Reference: The all-new Play Module Repository from our JCG partner Steve Chaloner at the Objectify blog....

Protect a REST service using HMAC (Play 2.0)

We have HTTPS, what more do we need? When you talk about security for REST based APIs, people often point to HTTPS. With HTTPS you can easily protect your services from prying eyes using methods everybody is familiar with. When you, however, require an additional level of security, or HTTPS just isn’t available, you need an alternative. For instance you might need to track the usage of your API for each customer, or need to know exactly who is makking all these calls. You could use HTTPS together with client authentication, but that would require setting up a complete PKI Infrastructure and a secure way to identify your customers and exchange private keys. And in contrast with WS-Security for SOAP based service, there isn’t a standard we can use for REST. A common way to solve this (Microsoft, Amazon, Google and Yahoo take this approach), is by signing your message based on a shared secret between the client and the service. Note that with this approach we only sign the data, we don’t encrypt it. The signature we’re talking about in this case, is something that is usually called a Hash-based Message Authentication Code (or HMAC for short). With an HMAC we create a message authentication code (MAC) for a request based on a secret key we’ve exchanged. In this article I’ll show you how you can implement this algorithm for a Play 2.0 based REST service. If you use a different technology the steps will be pretty much the same way though. HMAC Scenario For the client part, I’ll just use a simple HTTPClient based application. To implement this we’ll have to take the following steps:First, we need to exchange a shared secret with out client. Often this is sent by the API provider to the client using an email message, or the provider has a website where you can lookup the shared secret. Note that this secret is shared only between you and service, each client will have a different shared secret. This isn’t something you share like a public key,  To make sure the client and the service calculate the signature over the same content, we need to normalize the request that is to be signed. If we don’t do this, the server might interpret whitespace in a different manner as the client did and conclude that the signature is invalid.  Based on this normalized message, the client creates an HMAC value using the shared secret.  Now the client is ready to sent the request to the service. He adds the HMAC value to the headers, and also something that identifies him as user. For instance a username or some other public value.  When the service receives the request it extracts the username and the HMAC value from the headers. Based on the username, the service knows which shared secret should have been used to sign the message. The service would, for instance, retrieve this from a datastore somewhere.  The service now normalizes the request in the same manner as the client did, and calculates the HMAC value for itself.  If the HMAC from the client matches the calculated HMAC from the server, you know that the message’s integrity is guaranteed, and that the client is who he says he is. If either the wrong username was supplied, or an incorrect secret was used to calculate the headers, the HMAC values wouldn’t match.What do we need to do, to implement HMAC? In the following section we’ll at the following subjects.Determine the fields to use for input.  Create client code that can calculate this HMAC and add the corresponding headers  Create Play 2.0 based interceptor that checks the HMAC headersDetermine the input fields The first thing we need to do is determine the input for our HMAC calculation. The following table describes the elements we’ll include:Field DescriptionHTTP Method With REST the kind of HTTP method we execute defines the behavior on the server side. A DELETE to a specific URL is handled differently than a GET to that URL.Content-MD5 This HTTP header is a standard HTTP header. This is an MD5 hash of the body of the request. If we include this header into the HMAC code generation we get an HMAC value that changes as the request body changes.Content-Type header The Content-Type header is an important header when making REST calls. Depending on the media-type the server can respond differently to a request, therefore it should be included in the HMAC.Date header We also include the date the request was created to calculate the HMAC. On the server side we can make sure the date wasn’t changed in transit. Besides this we can add message expiration functionality on the server.Path The Path part of the URL that was invoked is also used in HMAC calculation, since an URI identifies a resource within REST.What we’ll include is pretty much the following information from a request: PUT /example/resource/1 Content-Md5: uf+Fg2jkrCZgzDcznsdwLg== Content-Type: text/plain; charset=UTF-8 Date: Tue, 26 Apr 2011 19:59:03 CESTClient code that can be used to create an HMAC signature Below you can see the client code with which we’ll make the calls to the HMAC protected service. This is just a quick HTTPClient based client with which we can test our Service. public class HMACClient { private final static String DATE_FORMAT = "EEE, d MMM yyyy HH:mm:ss z"; private final static String HMAC_SHA1_ALGORITHM = "HmacSHA1"; private final static String SECRET = "secretsecret"; private final static String USERNAME = "jos"; private static final Logger LOG = LoggerFactory.getLogger(HMACClient.class); public static void main(String[] args) throws HttpException, IOException, NoSuchAlgorithmException { HMACClient client = new HMACClient(); client.makeHTTPCallUsingHMAC(USERNAME); } public void makeHTTPCallUsingHMAC(String username) throws HttpException, IOException, NoSuchAlgorithmException { String contentToEncode = "{\"comment\" : {\"message\":\"blaat\" , \"from\":\"blaat\" , \"commentFor\":123}}"; String contentType = "application/vnd.geo.comment+json"; //String contentType = "text/plain"; String currentDate = new SimpleDateFormat(DATE_FORMAT).format(new Date()); HttpPost post = new HttpPost("http://localhost:9000/resources/rest/geo/comment"); StringEntity data = new StringEntity(contentToEncode,contentType,"UTF-8"); post.setEntity(data); String verb = post.getMethod(); String contentMd5 = calculateMD5(contentToEncode); String toSign = verb + "\n" + contentMd5 + "\n" + data.getContentType().getValue() + "\n" + currentDate + "\n" + post.getURI().getPath(); String hmac = calculateHMAC(SECRET, toSign); post.addHeader("hmac", username + ":" + hmac); post.addHeader("Date", currentDate); post.addHeader("Content-Md5", contentMd5); HttpClient client = new DefaultHttpClient(); HttpResponse response = client.execute(post); System.out.println("client response:" + response.getStatusLine().getStatusCode()); } private String calculateHMAC(String secret, String data) { try { SecretKeySpec signingKey = new SecretKeySpec(secret.getBytes(), HMAC_SHA1_ALGORITHM); Mac mac = Mac.getInstance(HMAC_SHA1_ALGORITHM); mac.init(signingKey); byte[] rawHmac = mac.doFinal(data.getBytes()); String result = new String(Base64.encodeBase64(rawHmac)); return result; } catch (GeneralSecurityException e) { LOG.warn("Unexpected error while creating hash: " + e.getMessage(), e); throw new IllegalArgumentException(); } } private String calculateMD5(String contentToEncode) throws NoSuchAlgorithmException { MessageDigest digest = MessageDigest.getInstance("MD5"); digest.update(contentToEncode.getBytes()); String result = new String(Base64.encodeBase64(digest.digest())); return result; } }And then use the HMAC algorithm to create a signature based on a shared secret. private String calculateHMAC(String secret, String data) { try { SecretKeySpec signingKey = new SecretKeySpec(secret.getBytes(), HMAC_SHA1_ALGORITHM); Mac mac = Mac.getInstance(HMAC_SHA1_ALGORITHM); mac.init(signingKey); byte[] rawHmac = mac.doFinal(data.getBytes()); String result = new String(Base64.encodeBase64(rawHmac)); return result; } catch (GeneralSecurityException e) { LOG.warn("Unexpected error while creating hash: " + e.getMessage(), e); throw new IllegalArgumentException(); } }After we’ve calculcated the HMAC value, we need to send it to the server. We do this by providing a custom header: post.addHeader("hmac", username + ":" + hmac);As you can see, we also add our username. This is needed by the server to determine which secret to use to calculate the HMAC value on the server side. When we now run this code, a simple POST operation will be executed that sends the following request to the server: POST /resources/rest/geo/comment HTTP/1.1[\r][\n] hmac: jos:+9tn0CLfxXFbzPmbYwq/KYuUSUI=[\r][\n] Date: Mon, 26 Mar 2012 21:34:33 CEST[\r][\n] Content-Md5: r52FDQv6V2GHN4neZBvXLQ==[\r][\n] Content-Length: 69[\r][\n] Content-Type: application/vnd.geo.comment+json; charset=UTF-8[\r][\n] Host: localhost:9000[\r][\n] Connection: Keep-Alive[\r][\n] User-Agent: Apache-HttpClient/4.1.3 (java 1.5)[\r][\n] [\r][\n] {"comment" : {"message":"blaat" , "from":"blaat" , "commentFor":123}}Implementing in Scala / Play So far we’ve seen what the client needs to do to provide us with the correct headers. Service providers often offer specific libraries, in multiple languages, that handle the details of signing the message. But as you can see, doing it by hand, isn’t that difficult. Now, let’s look at the server side, where we use scala together with the Play 2.0 framework to check whether the supplied header contains the correct information. For more information on setting up the correct scala environment to test this code look at my previous post on scala (http://www.smartjava.org/content/play-20-akka-rest-json-and-dependencies). The first thing to do is setup the correct routes to support this POST operation. We do this in the conf/routes file POST /resources/rest/geo/comment controllers.Application.addCommentThis is basic Play functionality. All POST calls to the /resource/rest/geo/comment URL will be passed on to the specified controller. Let’s look at what this operation looks like: def addComment() = Authenticated { (user, request) => { // convert the supplied json to a comment object val comment = Json.parse(request.body.asInstanceOf[String]).as[Comment] // pass the comment object to a service for processing commentService.storeComment(comment) println(Json.toJson(comment)) Status(201) } }Now it gets a bit more complicated. As you can see in the listing above, we’ve defined an addComment operation. But, instead of directly defining an Action like this: def processGetAllRequest() = Action { val result = service.processGetAllRequest; Ok(result).as("application/json"); }We, instead, define it like this: def addComment() = Authenticated { (user, request) => {What we do here is create a composite action http://www.playframework.org/documentation/2.0/ScalaActionsComposition). We can easily do this, since Scala is a functional language. The ‘Authenticated’ reference you see here is just a simple reference to a simple function, that takes another function as its argument. In the ‘Authenticated’ function we’ll check the HMAC signature. You can read this as using annotations, but now without the need for any special constructs. So, what does our HMAC check look like. import play.api.mvc.Action import play.api.Logger import play.api.mvc.RequestHeader import play.api.mvc.Request import play.api.mvc.AnyContent import play.api.mvc.Result import controllers.Application._ import java.security.MessageDigest import javax.crypto.spec.SecretKeySpec import javax.crypto.Mac import org.apache.commons.codec.binary.Base64 import play.api.mvc.RawBuffer import play.api.mvc.Codec /** * Obejct contains security actions that can be applied to a specific action called from * a controller. */ object SecurityActions { val HMAC_HEADER = "hmac" val CONTENT_TYPE_HEADER = "content-type" val DATE_HEADER = "Date" val MD5 = "MD5" val HMACSHA1 = "HmacSHA1" /** * Function authenticated is defined as a function that takes as parameter * a function. This function takes as argumens a user and a request. The authenticated * function itself, returns a result. * * This Authenticated function will extract information from the request and calculate * an HMAC value. * * */ def Authenticated(f: (User, Request[Any]) => Result) = { // we parse this as tolerant text, since our content type // is application/vnd.geo.comment+json, which isn't picked // up by the default body parsers. Alternative would be // to parse the RawBuffer manually Action(parse.tolerantText) { request => { // get the header we're working with val sendHmac = request.headers.get(HMAC_HEADER); // Check whether we've recevied an hmac header sendHmac match { // if we've got a value that looks like our header case Some(x) if x.contains(":") && x.split(":").length == 2 => { // first part is username, second part is hash val headerParts = x.split(":"); val userInfo = User.find(headerParts(0)) // Retrieve all the headers we're going to use, we parse the complete // content-type header, since our client also does this val input = List( request.method, calculateMD5(request.body), request.headers.get(CONTENT_TYPE_HEADER), request.headers.get(DATE_HEADER), request.path) // create the string that we'll have to sign val toSign = input.map( a => { a match { case None => "" case a: Option[Any] => a.asInstanceOf[Option[Any]].get case _ => a } }).mkString("\n") // use the input to calculate the hmac val calculatedHMAC = calculateHMAC(userInfo.secret, toSign) // if the supplied value and the received values are equal // return the response from the delegate action, else return // unauthorized if (calculatedHMAC == headerParts(1)) { f(userinfo, request) } else { Unauthorized } } // All the other possibilities return to 401 case _ => Unauthorized } } } } /** * Calculate the MD5 hash for the specified content */ private def calculateMD5(content: String): String = { val digest = MessageDigest.getInstance(MD5) digest.update(content.getBytes()) new String(Base64.encodeBase64(digest.digest())) } /** * Calculate the HMAC for the specified data and the supplied secret */ private def calculateHMAC(secret: String, toEncode: String): String = { val signingKey = new SecretKeySpec(secret.getBytes(), HMACSHA1) val mac = Mac.getInstance(HMACSHA1) mac.init(signingKey) val rawHmac = mac.doFinal(toEncode.getBytes()) new String(Base64.encodeBase64(rawHmac)) } }That’s a lot of code, but most of it will be pretty easy to understand. The ‘calculateHMAC’ and the ‘calculateMD5′ methods are just basic scala wrappers around Java functionality. The documentation inside this class should be enough to understand what is happening. I do, however, want to highlight a couple of interesting concepts in this code. The first thing is the method signatue: def Authenticated(f: (User, Request[Any]) => Result) = {What this means is that the Authenticated method itself, takes as it’s arguments another method (or function if you want to call it that). If you look back at the target of our route, you can see that we do just that: def addComment() = Authenticated { (user, request) => ...Now what happens when this ‘Authenticated’ method is called? The first thing we do, is check whether the HMAC header exists and is in the correct format: val sendHmac = request.headers.get(HMAC_HEADER); sendHmac match { // if we've got a value that looks like our header case Some(x) if x.contains(":") && x.split(":").length == 2 => { ... } // All the other possibilities return to 401 case _ => UnauthorizedWe do this by using a match against the HMAC header. If it contains a value that is of the correct format, we process the header and calculate the HMAC value in the same manner as our client did. If not we return a 401. If the HMAC value is correct we delegate to the provided function using this code: if (calculatedHMAC == headerParts(1)) { f(userInfo, request) } else { Unauthorized }And that pretty much is it. With this code you can easily use an HMAC to check whether the message has changed in transit, and whether your client is really known to you. Very easy as you can see. Just a small sidenote on JSON usage from Play 2.0. If you look at the action code, you can see I use the standard JSON functionality: def addComment() = Authenticated { (user, request) => { // convert the supplied json to a comment object val comment = Json.parse(request.body.asInstanceOf[String]).as[Comment] // pass the comment object to a service for processing commentService.storeComment(comment) println(Json.toJson(comment)) Status(201) } }First we parse the received JSON using ‘json.parse’ to a ‘comment’ class, then store the comment, and convert the command object back to a string value. Not the most useful code, but it does nicely demonstrate some of the JSON functionality provided by Play 2.0. To convert from JSON to an object and back again, something called “Implicit Conversions” is used. I won’t dive too much in the details, but a good explanation can be found here: http://www.codecommit.com/blog/ruby/implicit-conversions-more-powerful-t…. What happens here is that the JSON.parse and the Json.toJson method look for a specific method on the Comment class. And if it can’t find it there, it looks for the specific operation in its scope. To see how this works for the JSON parsing let’s look a the Comment class and its companion object: import play.api.libs.json.Format import play.api.libs.json.JsValue import play.api.libs.json.JsObject import play.api.libs.json.JsString import play.api.libs.json.JsNumber import play.api.libs.json.JsArray object Comment { implicit object CommentFormat extends Format[Comment] { def reads(json: JsValue): Comment = { val root = (json \ "comment") Comment( (root \ "message").as[String], (root \ "from").as[String], (root \ "commentFor").as[Long]) } def writes(comment: Comment): JsValue = { JsObject(List("comment" -> JsObject(Seq( "message" -> JsString(comment.message), "from" -> JsString(comment.message), "commentFor" -> JsNumber(comment.commentFor))))) } } } case class Comment(message: String, from: String, commentFor: Long) {}What you see here is that in the companion object we create a new ‘Format’ object. The ‘reads’ and ‘writes’ operations in this object will now be used by the JSON operation to convert from and to JSON when working with the ‘Comment’ class. Very powerful stuff, even though it’s a bit magic ;-) For more information on the Scala/Play environment I used for this example see my previous posts: http://www.smartjava.org/content/play-20-akka-rest-json-and-dependencies http://www.smartjava.org/content/using-querulous-scala-postgresql Reference: Protect a REST service using HMAC (Play 2.0) from our JCG partner Jos Dirksen at the Smart Java blog....

The Strategy Pattern

In a recent blog on I received a comment from Wojciech Soczy?ski about how the “strategy” pattern can be used to enforce the Single Responsibility Principle (SRP) when using Tell Don’t Ask (TDA). At some point I plan to discuss this further, but first thought that it would be a good idea to define the Strategy Pattern using the ShoppingCart example that I used a couple of weeks ago in my Tell Don’t Ask and its follow up Disassembling Tell Don’t Ask blogs:First a definition: in the simplest terms, you can define the Strategy Pattern as telling an object to do a job and to do it using ANOTHER object. To clarify this further I’m going to redesign the ShoppingCart slightly, by giving it a pay()* method: public class ShoppingCart {private final List<Item> items;public ShoppingCart() { items = new ArrayList<Item>(); }public void addItem(Item item) {items.add(item); }public double calcTotalCost() {double total = 0.0; for (Item item : items) { total += item.getPrice(); }return total; }public boolean pay(PaymentMethod method) {double totalCost = calcTotalCost(); return method.pay(totalCost); } }The thing to notice about the pay() method is that it takes one parameter of type PaymentMethod – it’s the PaymentMethod that’s the “ANOTHER” object in my definition above. The next thing to do is define the PaymentMethod as an interface. Why an interface? It’s because the power of this technique is that you can decide at run-time which concrete type you’ll pass into the ShoppingCart to make the payment. For example, given the Payment interface: public interface PaymentMethod {public boolean pay(double amount);}you can then define any concrete payment object such as a Visa or a MasterCard for example: public class Visa implements PaymentMethod {private final String name; private final String cardNumber; private final Date expires;public Visa(String name, String cardNumber, Date expires) { super(); this.name = name; this.cardNumber = cardNumber; this.expires = expires; }@Override public boolean pay(double amount) {// Open Comms to Visa // Verify connection // Paybill using these details return true; // if payment goes through }}…and public class MasterCard implements PaymentMethod {private final String name; private final String cardNumber; private final Date expires;public MasterCard(String name, String cardNumber, Date expires) { super(); this.name = name; this.cardNumber = cardNumber; this.expires = expires; }@Override public boolean pay(double amount) {// Open Comms to Mastercard // Verify connection // Paybill using these details return true; // if payment goes through }}The final thing to do is to demonstrate this with the unit test: payBillUsingVisa @Test public void payBillUsingVisa() {ShoppingCart instance = new ShoppingCart();Item a = new Item("gloves", 23.43); instance.addItem(a);Item b = new Item("hat", 10.99); instance.addItem(b);Date expiryDate = getCardExpireyDate(); PaymentMethod visa = new Visa("CaptainDebug", "1234234534564567", expiryDate);boolean result = instance.pay(visa); assertTrue(result);}private Date getCardExpireyDate() { Calendar cal = Calendar.getInstance(); cal.clear(); cal.set(2015, Calendar.JANUARY, 21); return cal.getTime(); }In the code above, you can see that I’m creating a ShoppingCart and then I add a few items. Finally, I create a new PaymentMethod in the form of a Visa object and inject it into the pay(PaymentMethod method) function, which is the crux of the matter. In a different situation I could have easily created a MasterCard object and used that as a direct replacement for Visa – i.e. the object that which is passed in as an argument is determined at runtime. And that defines the Strategy pattern, but that’s not the end of the blog. If you’ve ever used Spring, but never heard of the Strategy pattern, all this should feel a little familiar. This is because it turns out that the Guys at Spring use the Strategy Pattern to underpin their whole technology. If I take my example above and make a few slight changes I can come up with: @Component public class SpringShoppingCart {private final List<Item> items;@Autowired @Qualifier("Visa") private PaymentMethod method;public SpringShoppingCart() { items = new ArrayList<Item>(); }public void addItem(Item item) {items.add(item); }public double calcTotalCost() {double total = 0.0; for (Item item : items) { total += item.getPrice(); }return total; }public boolean pay() {double totalCost = calcTotalCost(); return method.pay(totalCost); } }The only difference between this incarnation and the first one is that the strategy class Visa is injected by Spring when the class is loaded using the @Autowired annotation. To sum this up, I guess guess that this means that the Strategy Pattern is the most popular pattern in the world. *For the purposes of this discussion I’m assuming that it’s okay for a ShoppingCart to pay for itself, but whether this is correct or not is a whole new blog… Reference: The Strategy Pattern from our JCG partner Roger Hughes at the Captain Debug’s Blog blog....

RabbitMQ: Scheduled Message Delivery

Earlier this month I gave a presentation at ComoRichWeb on RabbitMQ and one question from an attendee was “Is it possible to publish a message to be consumed at a later date?” I answered that it wasn’t possible to the best of my knowledge, but that there might be some hack to accomplish it. Well, this evening while trying to figure out how to use a push vs. polling model for timed notifications I discovered a clever hack using temporary queues, x-message-ttl and dead letter exchanges. The main idea behind this is utilizing a new feature available in 2.8.0, dead-letter exchanges. This AMQP extension allows you to specify an exchange on a queue that messages should be published to when a message either expires or is rejected with requeue set to false. With this in mind, we can simply create a queue for messages we want to be delivered later with an x-message-ttl set to the duration we want to wait before it is delivered. And to ensure the message is transferred to another queue we simply define the x-dead-letter-exchange to an exchange we created (in this case I’ll call it immediate) and bind a queue to it (the “right.now.queue”). In coffeescript with node-amqp this looks like this: amqp = require 'amqp' conn = amqp.createConnection() key = "send.later.#{new Date().getTime()}" conn.on 'ready', ->' conn.queue key, { arguments:{ "x-dead-letter-exchange":"immediate" , "x-message-ttl": 5000 } }Next I define the immediate exchange, bind a queue to it and subscribe. conn.exchange 'immediate'conn.queue 'right.now.queue', {autoDelete: false, durable: true}, (q) -> q.bind('immediate', 'right.now.queue') q.subscribe (msg, headers, deliveryInfo) -> console.log msg console.log headersFinally, after defining the queue I created earlier we want publish a message on it. So to revisit the earlier queue definition we add a publish call to publish directly to the queue (using the default exchange). conn.on 'ready', -> conn.queue key, { arguments:{ "x-dead-letter-exchange":"immediate" , "x-message-ttl": 5000 } }, -> conn.publish key, {v:1}, {contentType:'application/json'}The result of running this is we’ll see a 5 second wait and then the message content and headers get dumped to the console. Since the queue is only used temporarily in this scenario I also set the x-expires attribute of the queue to expire in a reasonable amount of time after the message expires. This makes sure we don’t wind up with a ton of unused queues just sitting around. Here’s the result of this exercise in its entirety. amqp = require 'amqp' events = require 'events' em = new events.EventEmitter() conn = amqp.createConnection() key = "send.later.#{new Date().getTime()}" conn.on 'ready', -> conn.queue key, { arguments:{ "x-dead-letter-exchange":"immediate" , "x-message-ttl": 5000 , "x-expires": 6000 } }, -> conn.publish key, {v:1}, {contentType:'application/json'} conn.exchange 'immediate'conn.queue 'right.now.queue', { autoDelete: false , durable: true }, (q) -> q.bind('immediate', 'right.now.queue') q.subscribe (msg, headers, deliveryInfo) -> console.log msg console.log headersYou can get this exercise in full on github. This is pretty interesting and I plan to experiment further with utilizing this in one of my production node.js applications that use interval based polling to trigger scheduled events. Reference: Scheduled Message Delivery with RabbitMQ from our JCG partner James Carr at the Rants and Musings of an Agile Developer blog....

5 useful methods JSF developers should know

The aim of this post is a summary about some handy methods for JSF developers they can use in their day-to-day work. An utility class is a good place to put all methods together. I would call such class FacesAccessor. The first method is probably the most used one. It returns managed bean by the given name. The bean must be registered either per faces-config.xml or annotation. Injection is good, but sometimes if beans are rare called, it’s not necessary to inject beans into each other. public static Object getManagedBean(final String beanName) { FacesContext fc = FacesContext.getCurrentInstance(); Object bean; try { ELContext elContext = fc.getELContext(); bean = elContext.getELResolver().getValue(elContext, null, beanName); } catch (RuntimeException e) { throw new FacesException(e.getMessage(), e); }if (bean == null) { throw new FacesException("Managed bean with name '" + beanName + "' was not found. Check your faces-config.xml or @ManagedBean annotation."); }return bean; }Using: @ManagedBean public class PersonBean { ... }PersonBean personBean = (PersonBean)FacesAccessor.getManagedBean("personBean");// do something with personBeanThe second method is useful for JSF component developers and everyone who would like to evaluate the given value expression #{…} and sets the result to the given value. public static void setValue2ValueExpression(final Object value, final String expression) { FacesContext facesContext = FacesContext.getCurrentInstance(); ELContext elContext = facesContext.getELContext();ValueExpression targetExpression = facesContext.getApplication().getExpressionFactory().createValueExpression(elContext, expression, Object.class); targetExpression.setValue(elContext, value); }Using:  I personally use this method for the “log off functionality”. After an user is logged off, he/she will see a special “logoff page”. The “logoff page” uses user settings (e.g. theme, language, etc.) from a sesion scoped bean. But this session scoped bean doesn’t exist more because the session was invalidated. What to do? Here is the code snippet from my logout method. UserSettings userSettings = (UserSettings) FacesAccessor.getManagedBean("userSettings");// invalidate session ExternalContext ec = FacesContext.getCurrentInstance().getExternalContext(); HttpSession session = (HttpSession) ec.getSession(false); session.invalidate();// create new session ((HttpServletRequest) ec.getRequest()).getSession(true);// restore last used user settings because login / logout pages reference "userSettings" FacesAccessor.setValue2ValueExpression(userSettings, "#{userSettings}");// redirect to the specified logout page ec.redirect(ec.getRequestContextPath() + "/views/logout.jsf");The third method maps a variable to the given value expression #{…}. It uses javax.el.VariableMapper to assign the expression to the specified variable, so that any reference to that variable will be replaced by the expression in EL evaluations. public static void mapVariable2ValueExpression(final String variable, final String expression) { FacesContext facesContext = FacesContext.getCurrentInstance(); ELContext elContext = facesContext.getELContext(); ValueExpression targetExpression = facesContext.getApplication().getExpressionFactory().createValueExpression(elContext, expression, Object.class); elContext.getVariableMapper().setVariable(variable, targetExpression); }Using:  Assume, “PersonBean” is a managed bean having “name” attribute and “PersonsBean” is a bean holding many instances of “PersonBean” (as array, collection or map). The following code allows to use “personBean” as a reference to a specific bean with “name” Oleg. FacesAccessor.mapVariable2ValueExpression("personBean", "#{personsBean.person['Oleg']}");In a facelets page, say so, personDetail.xhtml, we can write: <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets" xmlns:h="http://java.sun.com/jsf/html"> <ui:composition> ... <h:inputText value="#{personBean.name}"/> ... </ui:composition> </html>Note, the reference “personBean” was set in Java. This mapping can be also used in facelets in declarative way via ui:include / ui:param. <html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets"> <ui:composition> ... <ui:include src="personDetail.xhtml"> <ui:param name="personBean" value="#{personsBean.person['Oleg']}"/> </ui:include> ... </ui:composition> </html>The next two methods are used to create MethodExpression / MethodExpressionActionListener programmatically. They are handy if you use component binding via “binding” attribute or create some model classes in Java. public static MethodExpression createMethodExpression(String valueExpression, Class<?> expectedReturnType, Class<?>[] expectedParamTypes) { MethodExpression methodExpression = null; try { FacesContext fc = FacesContext.getCurrentInstance(); ExpressionFactory factory = fc.getApplication().getExpressionFactory(); methodExpression = factory. createMethodExpression(fc.getELContext(), valueExpression, expectedReturnType, expectedParamTypes); } catch (Exception e) { throw new FacesException("Method expression '" + valueExpression + "' could not be created."); } return methodExpression; }public static MethodExpressionActionListener createMethodActionListener(String valueExpression, Class<?> expectedReturnType, Class<?>[] expectedParamTypes) { MethodExpressionActionListener actionListener = null; try { actionListener = new MethodExpressionActionListener(createMethodExpression( valueExpression, expectedReturnType, expectedParamTypes)); } catch (Exception e) { throw new FacesException("Method expression for ActionListener '" + valueExpression + "' could not be created."); }return actionListener; }Using:  In one of my projects I have created PrimeFaces MenuModel with menu items programmatically. MenuItem mi = new MenuItem(); mi.setAjax(true); mi.setValue(...); mi.setProcess(...); mi.setUpdate(...); mi.setActionExpression(FacesAccessor.createMethodExpression( "#{navigationContext.setBreadcrumbSelection}", String.class, new Class[] {}));UIParameter param = new UIParameter(); param.setId(...); param.setName(...); param.setValue(...); mi.getChildren().add(param);Do you have nice methods you want to share here? Tips / tricks are welcome. Reference: 5 useful methods JSF developers should know from our JCG partner Oleg Varaksin at the Thoughts on software development blog....

Play framework 2 quicktip: Scala console

When I first started to play with Scala, I was amazed by the Scala interactive interpreter (also known as REPL, read-evaluate-print-loop). It was one of those things that you never expected to find in a statically typed, compiled language like java or scala. What would you say if we could have it for our play applications?… In scala OR JAVA! And yes, with tab completion and all the bells-and-whistles… Well, thanks to Peter Hausel (@pk11) from the play dev team, I found out how to do it. Just open a command prompt and type: cd <path_to_your_play2_app> play console[info] Loading project definition from /home/sas/Dropbox/Public/devel/play/apps/play2/todo/project [info] Set current project to todo (in build file:/home/sas/Dropbox/Public/devel/play/apps/play2/todo/) [info] Starting scala interpreter... [info] Welcome to Scala version 2.9.1.final (Java HotSpot(TM) Client VM, Java 1.6.0_31). Type in expressions to have them evaluated. Type :help for more information.That’s it, you are at the scala console, and what’s best, with tab completion enabled! Right there you can start playing with scala, and also with your application, like this: scala> val contact = models.Contact(1, "new contact", "new address") contact: models.Contact = Contact(1,new contact,new address)You can test your views, and of course you can also issue imports to save yourself quite a few keystrokes scala> import models._, views.html._ import models._ import views.html._scala> val contacts = Seq( Contact(1, "@develsas", "Buenos Aires"), Contact(2, "@pk11", "Paris") ) contacts: Seq[models.Contact] = List(Contact(1,@develsas,Buenos Aires), Contact(2,@pk11,Paris))scala> contact.list(contacts) res1: play.api.templates.Html = <!DOCTYPE html> <html> <head> <title>Contact list</title> <link rel="styles [...] <tr> <td>@develsas</td> <td>Buenos Aires</td> </tr> <tr> <td>@pk11</td> <td>Paris</td> </tr> [...]But when you try to access your database you’ll get the following error: scala> val contacts = Contact.all() java.lang.RuntimeException: There is no started application at scala.sys.package$.error(package.scala:27) [...]That’s easy, you just have to start your application scala> import play.core._ scala> new StaticApplication(new java.io.File(".")) [info] play - database [default] connected at jdbc:h2:data/db [info] play - Application started (Prod) res1: play.core.StaticApplication = play.core.StaticApplication@10cdd4And now you can play arround interactively with your running application scala> val contacts = Contact.all contacts: Seq[models.Contact] = List(Contact(1,Paul,Boston), Contact(3,Paolo,Roma), Contact(4,Paulain,Paris), Contact(5,Abelardo,San Justo))scala> val newContact = Contact(6, "new contact", "new address") newContact: models.Contact = Contact(6,new contact,new address)scala> Contact.insert(newContact) res2: Int = 1scala> val contacts = Contact.all contacts: Seq[models.Contact] = List(Contact(1,Paul,Boston), Contact(3,Paolo,Roma), Contact(4,Paulain,Paris), Contact(5,Abelardo,San Justo), Contact(6,new contact,new address))Now go check your database, you’ll see the new contact has been persisted to your db. One last tip. If you are working against the in-memory database, and you have defined any evolution script, you’ll receive this message when you start the application form play console: scala> new play.core.StaticApplication(new java.io.File(".")) [info] play - database [default] connected at jdbc:h2:mem:play [warn] play - Your production database [default] needs evolutions!# --- Rev:1,Ups - 74ff2d1 [...][warn] play - Run with -DapplyEvolutions.default=true if you want to run them automatically (be careful) PlayException: Database 'default' needs evolution! [An SQL script need to be run on your database.] at play.api.db.evolutions.EvolutionsPlugin$$anonfun$onStart$1.apply(Evolutions.scala:422) [...]The solution is quite easy, just start play with play -DapplyEvolutions.default=trueAnd your evolution scripts will be automatically applied when you start the application. Go ahead and give it a try. Grab, for example, the computer-database java demo $ cd <path_to_your_play2_installation>/samples/java/computer-database $ play -DapplyEvolutions.default=true[computer-database] $ console [info] Starting scala interpreter... [info] Welcome to Scala version 2.9.1.final (Java HotSpot(TM) Client VM, Java 1.7.0_03). Type in expressions to have them evaluated. Type :help for more information.scala> new play.core.StaticApplication(new java.io.File(".")) [info] play - database [default] connected at jdbc:h2:mem:play [info] play - Application started (Prod) res0: play.core.StaticApplication = play.core.StaticApplication@129796bAnd now, just start playing around with your app scala> val page = models.Computer.page(1, 10, "name", "asc", "") page: com.avaje.ebean.Page[models.Computer] = com.avaje.ebeaninternal.server.query.LimitOffsetPage@d386c9scala> val computerList = page.getList() computerList: java.util.List[models.Computer] = BeanList size[10] hasMoreRows[true] list[models.Computer@137, models.Computer@20d, models.Computer@12e, models.Computer@1b7, models.Computer@12d, models.Computer@14a, models.Computer@14b, models.Computer@21f, models.Computer@98, models.Computer@1a2]scala> computerList.get(0).name res2: java.lang.String = ASCI WhiteNevertheless, as soon as you start to play with the db, I faced a couple of problems. I could read from the database but I coudn’t write update nor inserts. I guess it’s the ebean voodoo magic that’s giving me troubles. With the scala version, I could really go much further, look at this (go ahead, don’t be shy and copy-paste this code) $ cd <path_to_your_play2_installation>/samples/scala/computer-database $ play -DapplyEvolutions.default=true[computer-database] $ console [info] Starting scala interpreter... [info] Welcome to Scala version 2.9.1.final (Java HotSpot(TM) Client VM, Java 1.7.0_03). Type in expressions to have them evaluated. Type :help for more information.scala> new play.core.StaticApplication(new java.io.File(".")) [info] play - database [default] connected at jdbc:h2:mem:play [info] play - Application started (Prod) res0: play.core.StaticApplication = play.core.StaticApplication@1eaf4b3scala> import models._, anorm._, play.api.db._, play.api.Play.current, anorm.SqlParser._import models._ import anorm._ import play.api.db._ import play.api.Play.current import anorm.SqlParser._scala> // clean-up everythingscala> DB.withConnection { implicit connection => SQL("delete from computer").executeUpdate() SQL("delete from company").executeUpdate() } res3: Int = 42scala> // just checkingscala> DB.withConnection { implicit connection => SQL("select count(*) from computer").as(scalar[Long].single) } res7: Long = 0scala> DB.withConnection { implicit connection => SQL("select count(*) from company").as(scalar[Long].single) } res8: Long = 0scala> Company.options res9: Seq[(String, String)] = List()Ok, let’s create a couple of companies scala> DB.withConnection { implicit connection => Seq((1, "my Company"), (2, "my second company")).map { company => SQL("insert into company values ( %s, '%s')".format(company._1, company._2) ).executeUpdate() } } res50: Seq[Int] = List(1, 1)scala> Company.options res51: Seq[(String, String)] = List((1,my Company), (2,my second company))And a couple of computers scala> val newComputer = Computer(NotAssigned, "my computer", None, None, Some(1)) newComputer: models.Computer = Computer(NotAssigned,my computer,None,None,Some(1))scala> Computer.insert(newComputer) res67: Int = 1scala> Computer.insert(Computer(NotAssigned, "my second comuter", None, None, Some(2)))scala> DB.withConnection { implicit connection => SQL("select * from computer").as(Computer.withCompany *) } res8: List[(models.Computer, Option[models.Company])] = List((Computer(1000,my computer,None,None,Some(1)),None), (Computer(1001,my second comuter,None,None,Some(2)),None))We’ll, this example is a little exagerated, but I guess you get an idea of what you can do with the play console, so keep hacking! Reference: Play framework 2 quicktip: interactively play with your application from the scala console from our JCG partner Sebastian Scarano at the Having fun with Play framework! blog....
Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below: