Grails on Google App Engine – Part 5: Conclusion

October 17, 2010 at 5:12 pm | Posted in GAE, Grails, Groovy, Java, Web | 4 Comments
Tags: , , , , , , , ,

Thanks to the App Engine plugin you can get Grails running on App Engine. Yeah, you got your favorite web application framework deployed on the cloud. But wait…there’s a problem. Grails comes with a lot of libraries that are bundled with the framework. You got Spring, Hibernate, Sitemesh and all the other libraries you added to your application. This is how we’re used to build applications. However, building applications for Google App Engine is different. The platform puts your application into sleep mode when you don’t get enough traffic. This is understandable from Google’s view on scalability but not from a software developer standpoint. Calling the application after a period of no usage will reinitialize your classes, Spring application contexts and libraries. If the application cannot serve the request within 30 seconds the user will get a com.google.apphosting.api.DeadlineExceededException. The cold startup time will even be longer the bigger your WAR file is and the more libraries you use. This gets extremely painful with Grails. Sometimes you have to call your application three times in a row, run into an initialization error and try again until Grails can serve your request. Google was talking about “reserved instances” that would not put your application into sleep mode for paying customers. However, this has not been realized yet. The GAE/J forum is full of frustrated users complaining about this issue. You can work around the cold startup time by setting up a cron job in cron.xml that pings your application every minute. From an architectural view this not only is unnecessary and useless traffic for your application it also will not fully solve the problem. I still ran into issues with requests that couldn’t finish with the deadline time period.

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
   <cron>
      <url>/user/ping</url>
      <description>Keep the app alive by ping every 1 minutes</description>
      <schedule>every 1 minutes</schedule>
   </cron>
</cronentries>

Clearly, App Engine calls for a lightweight application framework until the cold startup issues have been resolved by Google in some sort of form. This puts Grails out of the running as a production-ready framework on App Engine. No company can afford exceptions being thrown on paying customers. This is not an issue solely to Grails. I am sure the startup times for full-fledged Spring applications on App Engine are not extremely better. An alternative for a Groovy-based web framework can be seen in Gaelyk. Gaelyk is not as feature-rich as Grails but will give you the benefit of faster startup times. Implementing non-trivial web applications with Gaeylk can be painful to develop because it’s not as feature-rich as Grails is. I guess in the end there’s always a tradeoff.

More on this topic:

Grails on Google App Engine – Part 4: Third-Party Libraries

October 17, 2010 at 5:11 pm | Posted in GAE, Grails, Groovy, Java, Web | Leave a comment
Tags: , , , , , , , , ,

Certain aspects of web application development have already been solved by third-party libraries. Why implement a solution yourself when it’s already out there?! Not every existing library will work with App Engine though. Google published a page listing compatible libraries and frameworks for their platform. I will describe two very common use cases that I chose to use in my application: Security with Spring Security and making HTTP calls using HttpClient.

Security

Spring Security fits right into the Grails technology stack and it a proven solution for authenticating/authorizing users. This section will only describe the steps necessary to specifically integrate Spring Security with Grails on App Engine. For a detailed configuration description please refer to the Spring Security documentation. I set up my application with version 3.0.3 by dropping in the JAR files into the lib directory. Spring Security in it’s default configuration requires your container to support sessions. This is no problem for App Engine. You have to make sure though that you enable them. The configuration file appengine-web.xml has to have this entry to make it work:

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
   ...
   <sessions-enabled>true</sessions-enabled> 
   ...
</appengine-web-app>

First of all I declared my domain objects User and Role. Please see the Spring Security database schema for more information.

package com.favalike

import com.google.appengine.api.datastore.Key
import javax.jdo.annotations.*

@PersistenceCapable(identityType = IdentityType.APPLICATION, detachable="true")
class User {
   @PrimaryKey
   @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
   Key key

   @Persistent
   String username

   @Persistent
   String password

   @Persistent
   boolean enabled

   @Persistent(defaultFetchGroup = "true")
   List<Role> authorities = new ArrayList<Role>()
}
package com.favalike

import com.google.appengine.api.datastore.Key
import javax.jdo.annotations.*

@PersistenceCapable(identityType = IdentityType.APPLICATION, detachable="true")
class Role {
   @PrimaryKey
   @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
   Key key

   @Persistent
   String authority

   @Persistent
   User user
}

Because Spring Security doesn’t define a JDO UserDetailsService implementation that would be compatible with App Engine you have to write it yourself.

package com.favalike.security

import org.apache.commons.lang.StringUtils
import org.apache.commons.logging.Log
import org.apache.commons.logging.LogFactory
import org.springframework.context.support.MessageSourceAccessor
import org.springframework.dao.DataAccessException
import org.springframework.dao.DataRetrievalFailureException
import org.springframework.security.core.SpringSecurityMessageSource
import org.springframework.security.core.authority.GrantedAuthorityImpl
import org.springframework.security.core.userdetails.User
import org.springframework.security.core.userdetails.UserDetails
import org.springframework.security.core.userdetails.UserDetailsService
import org.springframework.security.core.userdetails.UsernameNotFoundException
import org.springframework.security.authentication.BadCredentialsException

class JdoUserDetailsService implements UserDetailsService {
   static final Log log = LogFactory.getLog(JdoUserDetailsService)
   def userService
   MessageSourceAccessor messages = SpringSecurityMessageSource.getAccessor()

   public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException, DataAccessException {
      if(StringUtils.isBlank(username)) {
         log.error "Username was empty. Authentication failed."
         throw new BadCredentialsException(messages.getMessage("login.username.blank", [] as Object[], "Username may not be empty"), username)
      }

      def user = null

      try {
         user = userService.findUserByUsername(username)
      }
      catch(Exception e) {
         log.error "Problem retrieving user from database", e
         throw new DataRetrievalFailureException(messages.getMessage("login.database.error", [] as Object[], "User could not be retrieved from database. Please try later"))
      }

      if(user == null) {
         log.error "User for username '${username}' not found in database. Authentication failed."
         throw new UsernameNotFoundException(messages.getMessage("JdbcDaoImpl.notFound", [username] as Object[], "Username {0} not found"), username)
      }

      if(log.infoEnabled) {
         log.info "Found user for username '${username}': ${user}"
      }

      def grantedAuthorities = []

      user.authorities.each { role ->
         grantedAuthorities << new GrantedAuthorityImpl(role.authority)
      }

      if(grantedAuthorities.size() == 0) {
         log.error "User needs to have at least one granted authority!"
         throw new UsernameNotFoundException(messages.getMessage("JdbcDaoImpl.noAuthority", [username] as Object[], "User {0} has no GrantedAuthority"), username)
      }

      if(log.infoEnabled) {
         log.info "User found for username '${username}'."
      }

      return new User(user.username, user.password, user.enabled, true, true, true, grantedAuthorities)
   }
}

I was able to put all the Spring wiring for Spring Security in grails-app/conf/spring/resources.groovy. My configuration is pretty much the ordinary security setup you would have to define for every application using Spring Security except that I defined it in Groovy.

beans = {
   // Security
   xmlns security: 'http://www.springframework.org/schema/security'

   jdoUserDetailsService(com.favalike.security.JdoUserDetailsService) {
      userService = ref('userService')
   }

   passwordEncoder(org.springframework.security.authentication.encoding.Md5PasswordEncoder)

   security.'http'('auto-config': true, 'access-denied-page': '/user/index') {
      security.'intercept-url'('pattern': '/user/index*', 'filters': 'none')
      security.'intercept-url'('pattern': '/user/signup', 'filters': 'none')
      security.'intercept-url'('pattern': '/favicon.ico', 'filters': 'none')
      security.'intercept-url'('pattern': '/**/*.html', 'access': 'ROLE_USER')
      security.'intercept-url'('pattern': '/**/*.js', 'access': 'ROLE_USER')
      security.'intercept-url'('pattern': '/**/*.gsp', 'access': 'ROLE_USER')
      security.'intercept-url'('pattern': '/**', 'access': 'ROLE_USER')
      security.'form-login'('authentication-failure-url': '/user/index?login_error=1', 'default-target-url': '/', 'login-page': '/user/index')
      security.'remember-me'('key': '99sdfll74soq')
      security.'logout'('logout-success-url': '/user/index')
   }

   security.'authentication-manager'('alias': 'authenticationManager') {
      security.'authentication-provider'('user-service-ref': 'jdoUserDetailsService') {
         security.'password-encoder'('hash': 'md5')
      }
   }
}

HTTP Calls

App Engine provides you with the URL Fetch API right out of the box. Even though the API does its job it is relatively feature-less. If you need more advanced feature sets like support for cookies you can turn to HttpClient. All you need to do is to download version 4 of the HttpComponents and drop the libraries into your lib directory. HttpClient needs some additional work to make it run on App Engine. It usually works with java.net package which is not allowed on App Engine. This posting shows you a way to work around it.

package com.favalike.http

import org.apache.commons.logging.Log
import org.apache.commons.logging.LogFactory
import org.apache.http.Header
import org.apache.http.HttpEntity
import org.apache.http.client.HttpClient
import org.apache.http.client.methods.HttpGet
import org.apache.http.client.methods.HttpUriRequest
import org.apache.http.conn.ClientConnectionManager
import org.apache.http.impl.client.DefaultHttpClient
import org.apache.http.params.BasicHttpParams
import org.apache.http.params.CoreConnectionPNames
import org.apache.http.params.CoreProtocolPNames
import org.apache.http.params.HttpParams
import org.apache.http.util.EntityUtils

class CommonsHttpRequestExecutor implements HttpRequestExecutor {
   static final Log log = LogFactory.getLog(CommonsHttpRequestExecutor)
   final Integer timeout

   CommonsHttpRequestExecutor(timeout) {
      this.timeout = timeout
   }

   def HttpResponse sendGetRequest(String url) {
      HttpGet httpGet = new HttpGet(url);

      if(log.debugEnabled) {
         log.debug("Sending GET request to URL '${httpget.getURI()}'")
      }

      executeHttpRequest(httpGet);
   }

   def executeHttpRequest(HttpUriRequest httpUriRequest) {
      HttpResponse httpResponse = new HttpResponse()
      HttpClient httpclient = getDefaultHttpClient()

      try {
         def response = httpclient.execute(httpUriRequest)
         populateResponseData(response, httpResponse)
      }
      catch(Exception e) {
         log.error("Error accessing site for url '${httpUriRequest.getURI()}'", e)
         httpResponse.errorMessage = e.message
         httpUriRequest.abort()
      }
      finally {
         httpclient.getConnectionManager().shutdown();
      }

      httpResponse
   }

   def getDefaultHttpClient() {
      ClientConnectionManager clientConnectionManager = new GAEConnectionManager();
      HttpParams params = new BasicHttpParams();
      params.setParameter(CoreConnectionPNames.CONNECTION_TIMEOUT, timeout);
      params.setParameter(CoreProtocolPNames.HTTP_CONTENT_CHARSET, "UTF-8");    
      new DefaultHttpClient(clientConnectionManager, params)
   }

   def populateResponseData(actualResponse, httpResponse) {
      httpResponse.statusCode = actualResponse.statusLine.statusCode
      httpResponse.reasonPhrase = actualResponse.statusLine.reasonPhrase
      httpResponse.statusLine = actualResponse.statusLine.toString()
      HttpEntity entity = actualResponse.getEntity();
      
      if(entity != null) {
         byte[] content = EntityUtils.toByteArray(entity)
         Header header = entity.getContentType() 
         httpResponse.responseBody = new String(content)
      }
   }
}

More on this topic:

Grails on Google App Engine – Part 3: Persistence

October 17, 2010 at 5:10 pm | Posted in GAE, Grails, Groovy, Java, Web | 4 Comments
Tags: , , , , , , , ,

The App Engine plugin installation script will prompt you for the persistence option you want to choose in your project. Google lets you select only one of its persistence implementations for BigTable: JDO or JPA. Using plain GORM is not an option. I decided to go with JDO for the simple fact that there’s more documentation for JDO than for JPA. Despite the fact that there’s documentation it certainly doesn’t cover all the questions I had. I found myself digging for answers to undescriptive exception messages for hours and hours in forums. Implementing persistence for my relatively easy domain model by far took the most of my development time making it a very frustrating experience. There are some good blogs about JDO persistence in App Engine that might be helpful to you: Google App Engine Java Persistence, Google App Engine Java Experiments. Often times I could only make things work by trail and error especially when it comes to modeling relationships.

Domain Classes

Grails domain classes have to reside in grails-app/domain and must be placed in a package. Only then the DataNucleus tool will enhance your classes. App Engine introduces its own data types. You definitely want to have a look at the list before you define the data types to your fields. It’s really a hassle to change the data type after you deployed your application to production and want to change the data type. Usually that means that you have to run a data migration script because App Engine might throw an exception on you for existing data. In my application I used the data type com.google.appengine.api.datastore.Key as primary key. The class Key has a String representation that you can use if you want to send it to your client code. This String representation can be converted back to a Key. The class you use for that is com.google.appengine.api.datastore.KeyFactory.

String bookmarkId = KeyFactory.keyToString(bookmark.key)
Key key = KeyFactory.stringToKey(bookmarkId)

You can try to exclude the default domain object fields id and version. However, that doesn’t quite propagate down to App Engine. The DataStore Viewer still shows both fields. I am not sure if there’s a different way around it.

static mapping = {
   id visible: false
   version visible: false
}

Defining relationships between domain objects can be tedious. More than often you run into funny error messages trying to store or retrieve data. You got to read the App Engine manual very closely to make them work. Especially when it comes down to defining many to many and self-referential owned relationship it can get hairy. Often times I had to fall back to just reference the Key of a different domain class to create a relationship.

Service Classes

The App Engine plugin automatically configures and provides you with Spring’s JdoTemplate that can be injected into your Grails services. Transaction boundaries can be set by wrapping your database interactions into a transactionTemplate. The JdoTemplate is easy to use and shouldn’t be new to you if you used one of Spring’s template implementations before like the JdbcTemplate. In some cases I had to fall back to the JDO low-level API because the JdoTemplate doesn’t provide the functionality. For my needs I created a super class that injects the JdoTemplate and the transactionTemplate.

class JdoService {
   def jdoTemplate
   def transactionTemplate
}

By default the JDO persistence configuration (jdoconfig.xml) created by the App Engine plugin auto-creates transactions. If you want to have full control over your transactions use the transactionTemplate. When you want to operate on more than one domain object within a transaction you have to set the property datanucleus.appengine.autoCreateDatastoreTxns to false.

<?xml version="1.0" encoding="utf-8"?>
<jdoconfig xmlns="http://java.sun.com/xml/ns/jdo/jdoconfig"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://java.sun.com/xml/ns/jdo/jdoconfig">

    <persistence-manager-factory name="transactions-optional">
        ...
        <property name="datanucleus.appengine.autoCreateDatastoreTxns" value="false"/>
    </persistence-manager-factory>
</jdoconfig>

Using the JdoTemplate doesn’t require you to close your connection. This is being handled by Spring. This is an example on how I used it:

def findAllByUser() {
   def bookmarks = []

   transactionTemplate.execute( { status ->
      def user = getLoggedInUser()
      bookmarks = jdoTemplate.find(Bookmark, "userKey == userKeyParam", "com.google.appengine.api.datastore.Key userKeyParam", [user.key] as Object[], "created asc")
   } as TransactionCallback)

   bookmarks
}

Despite the benefits of JdoTemplate you sometimes have to leverage the low-level API. However, you don’t have to create a class to retrieve the PersistenceManagerFactory. You can easily get it from the JdoTemplate. Make sure you close your resources after you used them. I wrote a little helper class to does that. One of the reasons I had to use the low-level API was to implement pagination. I chose to go down the naive, classic path of counting all records of a specific domain object and then retrieve the a list of these objects for the page we want to display. Using the range operator has implications for performance: the datastore must retrieve and then discard all results prior to the starting offset. For example, a query with a range of 5, 10 fetches 10 results from the datastore, then discards the first 5 and returns the remaining 5 to the application. I don’t expect users to have thousands and thousands of bookmarks in one folder so this would be a minor issue. Furthermore, I wanted to get up and running as soon as possible. Alternatively, this posting describes a performant but harder to implement solution.

def findAllByUserInRange(offset, max) {
   def bookmarks = []
   def total

   transactionTemplate.execute( { status ->
      def user = getLoggedInUser()
      Query query

      try {
         final filter = "userKey == userKeyParam"
         final parameters = "com.google.appengine.api.datastore.Key userKeyParam" 
         query = jdoTemplate.getPersistenceManagerFactory().getPersistenceManager().newQuery(Bookmark)
         query.setFilter(filter)
         query.declareParameters(parameters);
         query.setResult("count(this)")
         total = query.execute(user.key)
         query = jdoTemplate.getPersistenceManagerFactory().getPersistenceManager().newQuery(Bookmark)
         query.setFilter(filter)
         query.declareParameters(parameters);
         query.setOrdering("created asc")
         query.setRange(offset, offset + max)
         bookmarks = query.execute(user.key)
      }
      finally {
         JdoUtil.closeAll(query)
      }
   } as TransactionCallback)

   new Page(offset, max, total, bookmarks)
}

Indexes

The App Engine datastore maintains an index for every query an application intends to make. As the application makes changes to datastore entities, the datastore updates the indexes with the correct results. When the application executes a query, the datastore fetches the results directly from the corresponding index. As this might hold true for your development machine this isn’t necessarily true when you deploy your application to App Engine. Often times App Engine didn’t indicate that I have a missing index. You either have to analyze your queries very closely and add the indexes manually in grails-app/conf/datastore-indexes.xml or you’ll find yourself seeing exceptions. These exception can be fixed easily. However, you have to redeploy your application. It might take App Engine a while (sometimes 30 minutes or longer) to build the indexes once you have them defined. Indexes that are in the process of being built cannot serve the query causing an exception. This makes it impossible to deploy a new index without problems for your users. At the moment there’s no way to delete indexes over the administration console.

More on this topic:

Grails on Google App Engine – Part 2: Project Setup

October 17, 2010 at 5:09 pm | Posted in GAE, Grails, Groovy, Java, Web | 4 Comments
Tags: , , , , , , , ,

Setting up Grails for App Engine on my favorite IDE IntelliJ was as easy as installing the App Engine plugin. At the time of writing the latest plugin version is 0.8.10. It is by far not free of bugs but gets you where you want. It provides you with the basic setup to build, run and deploy your project in your development environment. The plugin was fully compatible with Grails 1.3.1. I didn’t try out to upgrade my project to the latest version of Grails yet. Stick to the plugin documentation to get the basic setup going. To be able to reference the GAE/J classes I dropped in the JAR files appengine-api-1.0-sdk-1.3.7.jar and jdo2-api-2.3-eb.jar into my project’s lib directory. It was extremely helpful to set up Log4J correctly right away. Earlier versions of the plugin had some Log4J-related bugs but they seem to be fixed now. Here’s an excerpt of my Config.groovy:

log4j = {
   appenders {
      console name:'stdout', layout:pattern(conversionPattern: '%d{dd MMM yyyy HH:mm:ss,SSS} [%t] %-5p %c{2} - %m%n')
   }

   debug  'grails.app', 'com.favalike'
   ...
}

The plugin still has a bug related to i18n. In case you’re using one of the messages.properties files to store internalized texts that would leave these files empty after building the WAR file. I could still make it work by applying the workaround described in the JIRA ticket. You got to change your Bootstrap.groovy as follows and build your WAR file for production environment: grails -Dgrails.env=production app-engine package.

import grails.util.Environment

class BootStrap {
   def messageSource

   def init = { servletContext ->
      if(Environment.getCurrent() == Environment.PRODUCTION) {
         messageSource.basenames = ['WEB-INF/grails-app/i18n/messages']
         messageSource.clearCache()
      }
   }

   def destroy = {
   }
} 

To improve performance from the get go I made sure I had precompilation enabled. Furthermore, static files can get served by dedicated servers and caches. Both settings are made in appengine-web.xml.

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
   ...
   <precompilation-enabled>true</precompilation-enabled>
   <static-files>
      <include path="/favicon.ico" />
      <include path="/css/**.css" />
      <include path="/images/**.*" />
      <include path="/js/**.js" expiration="1d" />    
   </static-files>
</appengine-web-app>

More on this topic:

Grails on Google App Engine – Part 1: A Case Study

October 17, 2010 at 5:08 pm | Posted in GAE, Grails, Groovy, Java, Web | 5 Comments
Tags: , , , , , , , , ,

Soon after Google had announced App Engine for Java I started to play around with the platform. Despite the limitations that App Engine imposes on developers I really wanted to know what all the buzz is about. Not only did I want to deploy a useful, non-trivial application I also wanted to get a feel for App Engine’s production readiness. Most of today’s developers are embracing (web) frameworks that help them to focus on implementing business logic. This might become an issue with App Engine for multiple reasons. Adding Megabytes of JAR files to your application increases the cold start up time. Furthermore, App Engine restricts the usage of certain specifications, technologies and frameworks. Over the past two years I became a big fan of Groovy and Grails. Therefore, I wanted to leverage the ease of use of Grails to implement a solution on App Engine. All I needed to get started was the Grails App Engine plugin. Even though I read about Gaelyk I wasn’t fully convinced that it would be able to provide me with all the functionality I needed to implement my application e.g. no support for taglibs or Sitemesh.

FavalikeTo limit the amount of work I’d have to put into this experiment I chose to implement a online bookmark manager with limited functionality. The features I wanted to cover should also take advantage of some of the services provided by App Engine. My plan was to use the Mail service and the URL Fetch API to get a feel on how easy it is to use them.

  • User registration and confirmation via email
  • User authenication
  • Management of bookmarks in folders per user
  • Tagging of bookmarks
  • Marking bookmarks as favorites
  • Automatic retrieval of URL meta data
  • Export of bookmarks as XML and HTML

The final result became Favalike which uses Grails 1.3.1 and the App Engine plugin 0.8.10. The following postings will describe my experience and the challenges I had to face in detail.

More on this topic:

Configuring Solr 1.4 logging with Log4J in Tomcat

January 6, 2010 at 9:15 pm | Posted in Java, Search, Software Development | 2 Comments
Tags: , , ,

Solr 1.4 logging is based on the “SLF4J” API. To configure Solr to use Log4J as standard logging implementation deploy the Solr web application to your Tomcat. Once the Solr web application got started add the libraries “slf4j-log4j12-1.5.5.jar” and “log4j-1.2.15.jar” to $CATALINA_HOME/webapps/solr/WEB-INF/lib. Delete the library “slf4j-jdk14-1.5.5.jar” from $CATALINA_HOME/webapps/solr/WEB-INF/lib.

Create the directory $CATALINA_HOME/webapps/solr/WEB-INF/classes and add the file log4j.properties. The file should hold your Log4J configuration. Here’s an example using a rolling log file:

log4j.rootLogger=ERROR, logfile

log4j.appender.logfile=org.apache.log4j.DailyRollingFileAppender
log4j.appender.logfile.File=${catalina.home}/logs/solr.log

log4j.appender.logfile.DatePattern='.'yyyy-MM-dd
log4j.appender.logfile.layout=org.apache.log4j.PatternLayout
log4j.appender.logfile.layout.ConversionPattern=%d %p [%c{3}] - [%t] - %X{ip}: %m%n

Alternatively, you can prepare your Solr web application WAR file to reflect the steps mentioned above. The Solr logging page (http://<host&gt;:<port>/solr/admin/logging) that comes with the web app will not reflect these changes. It only works for JDK logging that we just configured not to be used anymore. The Tomcat instance has to be restarted to reflect the changes.

GWT 1.6 Build Migration

April 8, 2009 at 9:11 pm | Posted in Build, Java, Software Development, Web | 2 Comments
Tags: , , , , , , ,

GWT 1.6 final officially got released yesterday. Most of you guys probably already have a GWT application sitting around that you want to upgrade from 1.5 to 1.6 to fully leverage the new features. One of the biggest changes is the structure of the WAR file. The public directory that got generated in 1.5 by running the projectCreator and applicationCreator tools does not exist anymore. HTML and CSS files will sit in the root directory of your WAR file. To convert your project have a look at the proposed project structure and apply it to your project. In your Ant build file you might have something similar to this one (assume that the WAR file got build before in a different target):

<path id="gwt.classpath">
   <pathelement location="src"/>
   <fileset dir="${libs.dir}/gwt/gwt-1.5.3">
      <include name="gwt-user.jar"/>
      <include name="gwt-dev-linux.jar"/>
      <include name="gwt-dev-mac.jar"/>
      <include name="gwt-dev-windows.jar"/>
   </fileset>
</path>

<target name="compile-gwt">
   <java classname="com.google.gwt.dev.GWTCompiler" fork="true">
      <arg line="-out ${gwt.compile.out}" />
      <arg value="${gwt.module}" />;
      <arg line="-style ${gwt.style}" />
      <classpath refid="gwt.classpath"/>
   </java>
</target>

<target name="gwtify-war">
   <!-- We don't need the GWT compiler tmp files-->
   <delete dir="${gwt.compile.out}/.gwt-tmp"/>
      
   <zip destfile="${operations-consoleweb.path.jar}" update="true">
      <fileset dir="${gwt.compile.out}">
         <include name="**/*.*"/>
      </fileset>
   </zip>
</target>

With the new version of the GWT compiler the temporary directory .gwt-tmp, as a by-product of the compilation process, is not being generated anymore. Use the new compiler class name com.google.gwt.dev.Compiler and you should be done.

<path id="gwt.classpath">
   <pathelement location="src"/>
   <fileset dir="${libs.dir}/gwt/gwt-1.6.4">
      <include name="gwt-user.jar"/>
      <include name="gwt-dev-linux.jar"/>
      <include name="gwt-dev-mac.jar"/>
      <include name="gwt-dev-windows.jar"/>
   </fileset>
</path>

<target name="compile-gwt">
   <java classname="com.google.gwt.dev.Compiler" fork="true">
      <classpath>
         <path refid="operations-console.module.sourcepath"/>
         <path refid="gwt.classpath"/>
      </classpath>
      <jvmarg value="-Xmx256M"/>
      <arg value="${gwt.module}"/>
   </java>
</target>

Building Seam with Maven 2

March 26, 2008 at 7:03 pm | Posted in Build, Java, Software Development | 5 Comments
Tags: , , , , , ,

JBoss Seam gives you a great build support if you want to go with Ant. But what about Maven 2? There doesn’t seem to be a lot of documentation about it. Here’s how I got it running. First of all you need to create a multi-module project. Maven 2 requires to have a POM for every artifact you want to build. What you need to set up is one project (through a directory) per artifact. The book “Better Builds with Maven” describes this procedure very well. After setting it up you should have something similar to this:

project
 - pom.xml
 |- ear
 |  - pom.xml
 |- ejb
 |  - pom.xml
 |- war
 |  - pom.xml

WAR will hold your JSF application files, EJB contains all EJB-related definitions and EAR ist just another project for building the enterprise archive. Each project will have their own POM file. On top of that you will have a parent POM which allows you to build all modules. In your parent POM define the Seam parent POM for usage:

<parent>
   <groupId>org.jboss.seam</groupId>
   <artifactId>parent</artifactId>
   <version>2.0.1.GA</version>
</parent>

You find the parent POM in the JBoss repository:

<repositories>
   <repository>
      <id>jboss-repository</id>
      <name>JBoss Repository</name>
      <url>http://repository.jboss.org/maven2</url>
   </repository>
</repositories>

Furthermore, you need to define your sub-modules (ear, ejb, war) as dependencies and modules. Add the JBoss Seam libraries you need. Moreover, don’t forget to set JDK >= 1.5 to build your code. Once you set up your project’s parent POM you’re ready to work on the module POMs. The only thing you have to do for the module POMs is to use your project’s parent POM and define the dependencies you need. For the EAR artifact you can use the Maven EAR Plugin to generate application.xml and jboss-app.xml. For a full code example have a look at the DVDStore Seam example build with Maven 2.

Ways to invoke Groovy from your Build

March 26, 2008 at 6:55 pm | Posted in Build, Groovy, Java, Software Development | 1 Comment
Tags: , , , , ,

There might be several reasons for you wanting to invoke Groovy from your Java build. Either you’re fed up with coding XML or you want to take a shortcut around the build systems sometimes cumbersome way to extend basic functionality. Custom Ant tasks and Maven Plugins hardly can overcome the shortcomings of XML expressiveness. Groovy can truly enrich your build through scripting. Java/Groovy hybrid applications also need a way to compile Groovy classes. No problem…support exists.


1. Ant

Compilation

The Groovy-All library comes with the Ant task groovyc that lets you compile your Groovy source files. It can be used very similar to the javac Ant task.

<taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc" classpathref="my.classpath"/>

<groovyc srcdir="${src.dir}" destdir="${bin.dir}">

Execution

The library also comes with the Ant task groovy that lets you execute your Groovy code. For more information see “Groovy in Action”, chapter 13.1.7 which gives a thorough code example. Previously compiled Groovy classes can be executed like regular Java classes using the Ant task java. First define the task definition in your build script:

<taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpathref="my.classpath"/>

Afterwards you can use all Groovy capabilities in your Ant targets:

<groovy>
   println "Your Groovy code here!"
<groovy/>

2. Maven 2

A very convenient way to configure Maven 2 to compile and execute your Groovy classes or scripts is to use the Groovy Maven Plugin. You have to stick to the Maven conventions to place your Groovy (test) sources in the right folders. Put your Groovy sources in <project-root>/src/main/groovy and your test sources to <project-root>/src/test/groovy.

First you need to add the Groovy Maven plugin and the Groovy runtime to your POM dependencies. Please check the Maven repository for the last versions:

<dependencies>
   <dependency>
      <groupId>org.codehaus.mojo</groupId>
      <artifactId>groovy-maven-plugin</artifactId>
      <version>1.0-beta-3</version>
   </dependency>
   <dependency>
      <groupId>org.codehaus.groovy</groupId>
      <artifactId>groovy-all</artifactId>
      <version>1.5.4</version>
   </dependency>
</dependencies>

Compilation

To compile your Groovy sources add the Groovy Maven plugin to your POM build definition. To start compilation run mvn compile in your shell.

<plugin>
   <groupId>org.codehaus.mojo.groovy</groupId>
   <artifactId>groovy-maven-plugin</artifactId>
   <executions>
      <execution>
         <goals>
            <goal>compile</goal>
         </goals>
      </execution>
   </executions>
</plugin>

Execution

There are several ways to execute your Groovy code:

a) Execute an inline Groovy script
b) Execute a local or remote Groovy script
c) Execute compiled Groovy classes

To execute your compiled Groovy classes you can simply use the Maven Exec plugin. Your Groovy classes are nothing else than regular Java class files. Run mvn exec:java in your shell.


3. Gant

Gant is a build tool that sits on top of Ant. You can use all tasks Ant provides. Instead of using XML to code your targets you use Groovy as scripting language. Therefore, the execution of Groovy syntax works right away. You don’t need to add additional notation to make this work.


Compilation

For compiling our Groovy classes to Java code we again use the groovyc.

sourceDirectory = 'src/main/groovy'
buildDirectory = 'bin'
Ant.taskdef(name : 'groovyc', classname : 'org.codehaus.groovy.ant.Groovyc')

target(compile : 'Compile source to build directory.') {
   groovyc(srcdir : sourceDirectory , destdir : buildDirectory)
}

Execution

I think it’s needless to say how to invoke Groovy in Gant. Simply use it!

“Seam in Action” Book Review

February 27, 2008 at 6:43 pm | Posted in Java, Media, Paper, Software Development | 1 Comment
Tags: , , , , , , , , , , ,

Seam in Action Softbound CoverIn the last couple of weeks I was busy reviewing Dan Allen‘s book “Seam in Action”. The book tries to give a practical insight into the internals of the JBoss Seam framework. Seam, unifying the Java EE platform, will help you assemble full-stack applications in no time avoiding its design flaws.

For a quick start check out Dan’s articles on IBM developerWorks:

“Seam is a powerful open source development platform for building rich Internet applications in Java. Seam integrates technologies such as Asynchronous JavaScript and XML (AJAX), JavaServer Faces (JSF), Java Persistence (JPA), Enterprise Java Beans (EJB 3.0) and Business Process Management (BPM) into a unified full-stack solution, complete with sophisticated tooling.”

Dan starts the book with chapter one as a very good introduction to the current problems with the JSF framework. It describes why Seam is needed as a complement to JSF to build real world applications. Throughout the book, the author uses examples and source code that are easy to follow. One example is the AJAX chapter where he picks typical use cases in modern web applications (asynchronous auto completion and form validation). The book teaches JBoss Seam step by step. It starts with an introduction to seam-gen, the code generation tool packaged with Seam, to easily create your own application in less than two hours. I really liked the discussion of development IDEs that you can use to develop Seam projects and when to use one or the other in favor of a specific feature. The book discusses all aspects that were introduced with Seam. Especially when it comes to new concepts like bijection, Dan provides clear explanations and makes good use of relevant examples.

Today’s applications integrate with a lot of other technologies and frameworks (especially when it comes to ORM). Seam makes heavy use of them. The book gives you the options you have when developing with Seam and how to implement them. Furthermore, Dan shows how to access JavaBeans managed by the Spring framework in your application. Many JSF projects already use Spring, which simplifies the migration from plain JSF to a “seamless” JSF application. Whenever possible, Dan compares alternatives. One example is his discussion of XML configuration vs. annotations. Here he provides a balanced and unbiased account about the pros and cons of each alternative.

JBoss Seam was developed to solve JSF’s design caveats and integration problems with other frameworks like Hibernate. The reader should have at least some working knowledge of the discussed technologies and frameworks. As a resume, “Seam in Action” is a down to earth guide for getting started quickly with Seam. The estimated publish date for the softbound print is June 2008. Two thumbs up!

Next Page »

Create a free website or blog at WordPress.com.
Entries and comments feeds.