Russell Frisch's Portfolio

Set it and Forget it Grails Logging

russellfrisch — Fri, 12 Feb 2010 19:07:27 +0000

One of the many nice features Grails borrowed from Rails is the ability to define environments, detect the active environment at runtime and setup different configurations for different environments. Generally when I’m developing an application I like to have as much useful logging enabled at all times so as to quick troubleshoot problems. In Struts and other Java frameworks this can be troublesome as there is the need to setup a custom deployment script or manually remember to reset debug levels for a production build.

Grails has a very elegant solution for this (as it does for so many other development tasks). Within the log4j enclosure found in your grails application’s Config.groovy file, create a new environments enclosure. You can then specify different logging configurations for each environment. An example of my preferred logging configuration is below. For the development environment I like to set “grails.app” to DEBUG as this will show any log.debugs you have created in any of your Controllers, Domains, Services, etc. I also set “org.hibernate.SQL” to DEBUG and “org.hibernate.type” to TRACE as this enables hibernate to log each query and the parameters for that query to the output window. Very useful for troubleshooting Domain relationships. For the test environment I keep the “grails.app” but turn off the hibernate logging as it has a significant impact on application performance.

With this configuration I no longer need to worry about how my logging is configured when I’m ready to “grails prod war”.

log4j = {


    error  'org.codehaus.groovy.grails.web.servlet',  //  controllers      
           'org.codehaus.groovy.grails.web.pages', //  GSP       
           'org.codehaus.groovy.grails.web.sitemesh', //  layouts       
           'org.codehaus.groovy.grails.web.mapping.filter', // URL mapping       
           'org.codehaus.groovy.grails.web.mapping', // URL mapping       
           'org.codehaus.groovy.grails.commons', // core / classloading       
           'org.codehaus.groovy.grails.plugins', // plugins       
           'org.codehaus.groovy.grails.orm.hibernate', // hibernate integration       
           'org.springframework',       
           'org.hibernate',       
           'net.sf.ehcache.hibernate' 
    warn   'org.apache.catalina' 
    environments {      
        development {       
            debug 'org.hibernate.SQL', 'grails.app'       
            trace 'org.hibernate.type'       
        }       
        test {       
            debug 'grails.app'       
        }       
    } 
}

Quick and Dirty Grails Authentication Controller Filter

russellfrisch — Fri, 12 Feb 2010 18:51:39 +0000

This is a quick and dirty method for ensuring users are authenticated when accessing your Grails site. Under grails-app/conf, create a Groovy class file with a name that ends in “Filters” (i.e. ControllerFilters.groovy) and copy and paste the below code snippet into this new class. The below code runs against any controllers/actions with the exception of controllers names “SessionContoller” and checks for the existence of a session variable called userId. If userId doesn’t exists, the user is either not authenticated or their session has timed out. The user is then either redirected to the login screen with a message advising them that they are not logged in or, if the request was AJAX based, a 401 (Unauthorized) error is returned.

// Enforce authentication on all controllers with the exception of the session controller


static filters = {      
  authentication(controller: '^(?:(?!session).)*$', action: "*") {       
    before = {       
      if (!session.userId) {       
        log.debug "session.userId not found"       
        if (request.xhr) { // If request is AJAX, send 401 (Unauthorized) Error       
          response.sendError(response.SC_UNAUTHORIZED)       
        } else {       
          flash.message = "You have been logged out."       
          redirect(controller: "session", action: 'create')       
        }       
        return false       
      }       
    }       
  }       
}

Stripes Framework: Struts done right.

russellfrisch — Tue, 09 Feb 2010 19:58:55 +0000

Do you have years of Struts 1.x web development experience that you don’t want to go to waste, and yet are growing tired of all the boilerplate code and configuration required for the simplest of Struts tasks? Perhaps you’ve been thinking about checking out Struts 2 but as you began to read up on it you see how vastly different it is then Struts 1. Is all your Struts experience now deprecated?

No. Check out the Stripes Framework.

I believe Stripes to be a ideal tool for Java web developers that grew up on Struts and are now wanting a framework where they can do more in less time with out having to start from scratch. As a Struts 1.x developer, I found Stripes very easy and intuitive and as was able to be productive with it almost immediately. Don’t take my word for it though, checkout a side by side comparison of Stripes and Struts. Stripes is well documented (both free online resources and books) and has a growing community of developers should you get stuck. So if you like Struts but you are still left wanting more, give Stripes a try.

IIS7 + ARR = Easy Java and ASP.NET Single Server Hosting

russellfrisch — Sat, 06 Feb 2010 05:47:20 +0000

Are you looking to host J2EE-based web applications alongside your ASP-based applications on the same Windows Server? Before this used relatively painful experience working with the Tomcat Connector and performing such fun tasks as making sure your isapi_redirect.dll was in the right place, creating workers and uriworkermap properties files and remembering to keep them current as new applications are added to the server.

Well my friends, the future is now. Thanks to a nice little Microsoft supported IIS7 extension called Application Request Routing. Easy Tomcat (or any server/port for that matter) proxying is but a few clicks and GUI configuration screens away. To start with I have Tomcat installed and running on port 8080 while IIS7 is at its default configuration running on port 80. Next are the few simple steps needed to get IIS7 to proxy based on a URL pattern to your Tomcat server, rewriting the URL both ways so the user never sees the port 8080.

From the link above, install the Application Request Routing extension
Within the IIS Manager, create a new Server Farm and add the current server to it, be sure to set the http port for this server farm to 8080
Next, in the Proxy configuration for the new server farm, check the option to rewrite the response URL.
Next either create a new URL Rewrite rule or modify the one that was auto-generated for you when you created the server farm. Here is where you specify the URL pattern that should redirect to Tomcat and the URL that this pattern should be rewritten to (be sure to include the port 8080 in this URL)
Once the rule has been saved, restart IIS

That’s it. If all went well, you should now be able to navigate to the URL and be quietly redirect to Tomcat with your URL looking no different that what you typed in.