Groovy

Developing email applications on Windows, targeted for Linux environment - email, mailx, sendmail

If you’re developing on a Windows platform for an application targeted for Linux or Unix that deals with email, then this article will be useful. Let us begin by understand the problem. Problem If you are a Java/Spring developer, (developing in Java is platform independent - runs on any platform where a JVM is available) then you have two options in front of you for sending emails from a Java application:

Grails 2.3.5 - grails stop-app - does not stop the app running via run-app

If you’re using Grails 2.3.X and you’re developing, most likely you’re running your app like this: [sourcecode language=“jscript”] grails run-app #in one command-prompt/shell-terminal and grails stop-app #in another command-prompt/shell-terminal [/sourcecode] With the latest version of Grails (version 2.3.5), the stop-app say: [sourcecode language=“jscript”] grails stop-app | Server Stopped But nothing happens and the server-process continues to run# [/sourcecode] Here’s an undocumented fix that can come in handy: [sourcecode language=“jscript”] On terminal/command-prompt #1 Run the way you do today grails run-app

Grails - Adding JavaScript to bottom of page

In Grails using the templating (Sitemesh) if you were to include per-page JavaScript resources then it shows up much earlier in the layout content as part of the <g:layoutBody> Here is an example illustrating the problem: SamplePage.gsp [sourcecode language=“html”] MyThinkPond.com Custom Page ... Some this page content [/sourcecode] and the layout page (layoutPage.gsp) [sourcecode language=“html”] ... Some template (header) content [/sourcecode] results in the following page in browser [sourcecode language=“html”]

Grails - Groovy - Alternative to HttpBuilder - adding headers to your HTTP request

Developing with Grails and Groovy can be a blessing and and pain all at the same time. The development moves at a rapid rate but when you decide to include libraries that depend on other libraries, your pain starts to build up. For example, when you include the module “HttpBuilder"in your project you may run into issues with Xerces and xml-apis, especially when you attempt to deploy the WAR file under Tomcat.

Not all Tomcat 6 classloaders must be equal

Today, while doing some Grails development I came across a peculiar issue that perplexed me and I’m documenting it for all others to benefit. (Also see my other blog from today for the issue that started this journey). Here are my specifications: Development Machine Windows-7, 64-bit java version “1.6.0_24” Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Grails 1.4.0.M1 Tomcat - apache-tomcat64-6.0.32 Local Deployment Server

Tomcat 6+: Infamous "SEVERE: Error listenerStart" message - How-To debug this error?

I’m sure if you have been developing with Java and Tomcat for sometime, you are likely to run into the infamous debug error. SEVERE: Error listenerStart You will most likely start Googling it trying to find out what the heck is going on. And in trying to see the extended logging on what that “listenerStart” error means. After some lucky searches, you will see links asking you to drop a “log4j.

How-To: Change Grails User work and cache directory under windows

The directions below will help you move the Grails user work and cache directory to a different location. Why? Sometimes your default “primary drive” may be running out of space and you need to move your workspace else where. How? Create a file called “settings.groovy” under “C:/Users/.grails” directory. Edit this file and add the following line: [sourcecode language=“jscript”] grails.work.dir=“D:/grailswork” [/sourcecode] Make sure that the defined folder exists. Remove all other content, files and folders in the “.