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:
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”]
With a new Grails 2.X project you run into challenges on which folders to check-in into a GIT repository. You want to remove any non-essential files that Grails can rebuild at run-time. And if you are using either GITHub or BitBucket for your GIT repo’s the default .gitignore file created or provided by GITHub is setup for configured for a Grails 1.X project and not a Grails 2.X project.
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.
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™ SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot™ 64-Bit Server VM (build 19.1-b02, mixed mode) Grails 1.4.0.M1 Tomcat - apache-tomcat64-6.
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.
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.