MyThinkPond

On Java, Python, Groovy, Grails, Spring, Node.js, Linux, Arduino, ARM, Embedded Devices & Web

Archive for the ‘Groovy’ Category

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

Posted by Venkatt Guhesan on December 11, 2016

linux_centos_logoIf 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:

Option #1: JavaMail API

Option #2: Linux sendmail or mailx invoked via Runtime.getRuntime().exec(invoke – linux – mail – command) [example here]

If you are a PHP or Ruby or Bash or Python developer, you can do the same using a native library available within the language or invoke a native Linux execute-command to invoke either sendmail or mailx.

What happens if you are developing a hybrid library that needs to send email both from Java and Python. Then most likely you want to leverage a common library accessible to all the various libraries. In this case, you’re going to depend on either sendmail or mailx.   Now let us throw in a additional problem into this mix. Suppose you are developing on a Windows platform but the end application is targeted to run on Linux. This now creates a new additional problem. Sendmail or Mailx do not exist for Windows. Well, this article provides a way to develop on Windows by invoking execute mailx calls from your native code to the underlying emulation of Linux on Windows.

Now that we have established the problem, let us walk through a solution.

Please note that this is not the only solution but a potential solution. If you know of other mechanisms, feel free to send me a link and I’ll add them in.

Solution

Step-1: Make sure that you have Cygwin installed (with email tool selected additionally) on your Windows computer.

# Download  setup-x86_64.exe from https://cygwin.com/setup-x86_64.exe
# and run it.

# When you run the setup, please additionally select "email" tool additionally. It is not added by default.

Once Cygwin is installed, most people traditionally use all the Cygwin tools from within a Cygwin Command-Prompt. The executables are located under “\bin\**” directory. Which means that if you run a “ls” in a DOS command-prompt, it will error saying “command not found”. There is a undocumented\not so known secret to emulating Linux commands natively in Windows. This is where your true Linux power comes in under native Windows.

Step-2: Add Cygwin\bin path natively to Windows PATH.

# In my computer, I have Cygwin installed at the following path: c:\cygwin64\

To add "c:\cygwin64\bin" the system path, perform these steps:

1. Start the System Control Panel applet (Start - Settings - Control Panel - System).
2. Select the Advanced tab.
3. Click the Environment Variables button.
4. Under System Variables, select Path, then click Edit.
5. Add c:\cygwin64\bin to the path.

Once Step-2 is completed. If you start a new DOS command-prompt and run a “ls” command, you should see the directory listing (same as a ‘dir’ command under Windows).

Step-3: The send email application uses “c:\cygwin64\etc\email\email.conf” for SMTP and other email properties.

# Edit c:\cygwin64\etc\email\email.conf and add your SMTP details (domain/server name, user-id, password)
# For this example, I have setup a *special* GMail Email account specially to test [Don't use your private GMail] so I will use the user-id and password for that Gmail account.

SMTP_SERVER = 'smtp.gmail.com'
SMTP_PORT = '587'
USE_TLS = 'true'
SMTP_AUTH = 'LOGIN'
SMTP_AUTH_USER = 'YOUR_TEST_GMAIL_ADDRESS@gmail.com'
SMTP_AUTH_PASS = 'YOUR_GMAIL_PASSWORD_GOES_HERE'
MY_NAME  = 'Venkatt Guhesan'
MY_EMAIL = 'foobar7634@gmail.com'

Step-4: Let’s test this under a DOS command-prompt.

# Open a DOS Command-Prompt and run the following:

echo "Test from Cygwin in Windows under DOS command-prompt" | email -s "Testing Email from Windows DOS" recipient_email_address@gmail.com 

# Within minutes, you should see an email in the Gmail inbox as expected.

# If you are not seeing it, then you can use the example below where you can pass in the SMTP arguments for validation. Maybe you typed in the password for the Gmail account incorrectly or you entered one of the parameters incorrectly in the c:\cygwin64\etc\email\email.conf file.

############### HERE IS AN EXAMPLE WITH SMTP PARAMETERS PASSED IN AS ARGUMENTS #######################
echo "Test from Cygwin in Windows under DOS command-prompt" | email -s "Tetsing Email" recipient_email_address@gmail.com -r smtp.gmail.com -p 587 -m login -u YOUR_TEST_GMAIL_ADDRESS@gmail.com -i YOUR_GMAIL_PASSWORD_GOES_HERE -tls
######################################################################################################

ss1

Once you have confirmed a successful email then the next step is to create a mailx application.

Step-5: Create a mailx.exe (mailx) within Cygwin’s bin directory.

For emulating mailx from Cygwin’s email.exe, you’re in luck. The format for mailx is identical to the email.exe’s arguments. All you are missing is mailx.exe. So simply copy email.exe under Cygwin’s bin directory to mailx.exe under the same Cygwin’s bin directory. And you’re all set!

# simply copy email.exe under Cygwin's bin directory to mailx.exe under the same Cygwin's bin directory

cd c:\cygwin64\bin
cp email.exe mailx.exe

# Now just like you running email (without the .exe suffix) you can run mailx (without the .exe suffix)

Step-6: Test sending an email using mailx


echo "Test from Cygwin-mailx in Windows under DOS command-prompt" | mailx -s "Testing Email from Windows DOS" recipient_email_address@gmail.com 

ss2

As a last step, now within your Java application, test Runtime.getRuntime().exec(“mailx command”);

Runtime.getRuntime().exec("echo 'Test from Cygwin-mailx in Windows under DOS command-prompt' | mailx -s 'Testing Email from Windows DOS' recipient_email_address@gmail.com");

Now your Java application as well as any Python, Bash, Linux shell applications and/or scripts are now leveraging the common “mailx” and your development is now consistently the same using one common mailx library.

Cheers!

Today’s inspirational quote:
theodore-roosevelt
  • We must all either wear out or rust out, every one of us. My choice is to wear out.
– Theodore Roosevelt, an American statesman, author, explorer, soldier, naturalist, and reformer who served as the 26th President of the United States from 1901 to 1909.

Posted in Bash, CentOS 6.X, CentOS7, Grails, Groovy, Java, Linux, Spring, Windows | Tagged: , , , , , , | Leave a Comment »

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

Posted by Venkatt Guhesan on February 2, 2014

If you’re using Grails 2.3.X and you’re developing, most likely you’re running your app like this:

grails run-app
#in one command-prompt/shell-terminal and
grails stop-app
#in another command-prompt/shell-terminal

With the latest version of Grails (version 2.3.5), the stop-app say:

grails stop-app
| Server Stopped
# But nothing happens and the server-process continues to run#

Here’s an undocumented fix that can come in handy:

# On terminal/command-prompt #1
# Run the way you do today
grails run-app
# On terminal/command-prompt #2, change-directory (cd) to the root folder where you have your Grails project
# Create a file with a file-name ".kill-run-app"
# For Linux (*Nix) environments
touch .kill-run-app
# For Windows where you do not have 'touch' command do the following instead
echo hello > .kill-run-app
# Wait for a few seconds and Grails will kill the app that's running

Now you can resume with starting a new instance of “grails run-app”.

Cheers & Happy Coding!

Posted in Grails, Groovy, Java | Tagged: , , , , | 1 Comment »

Grails – Adding JavaScript to bottom of page

Posted by Venkatt Guhesan on February 2, 2014

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

<!DOCTYPE html>
<html>
<head>
<meta name="layout" content="layoutPage"/>
<head>MyThinkPond.com Custom Page</head>
...
</head>
<body>
Some this page content
<script type="text/javascript" src="${request.contextPath}js/samplePage.js"></script>
</body>
</html>

and the layout page (layoutPage.gsp)

<!DOCTYPE html>
<html>
<head>
<title><g:layoutTitle default="MyThinkPond.com"/></title>
...
</head>
<body>
<div>
Some template (header) content
<g:layoutBody/>
</div>
<!-- Common JS Files -->
<script type="text/javascript" src="${request.contextPath}js/common.js"></script>
<!-- Begin: Custom Page JavaScript Should Go Here -->
<!-- End: Custom Page JavaScript Should Go Here -->
</body>
</html>

results in the following page in browser

<!DOCTYPE html>
<html>
<head>
<titleMyThinkPond.com Custom Page</title>
...
</head>
<body>

<div>
Some template (header) content
Some this page content
<script type="text/javascript" src="${request.contextPath}js/samplePage.js"></script>
</div>

<!-- Common JS Files -->
<script type="text/javascript" src="${request.contextPath}js/common.js"></script>
<!-- Begin: Custom Page JavaScript Should Go Here -->
<!-- End: Custom Page JavaScript Should Go Here -->
</body>
</html>

You can see that the JavaScript is included as part of the body and not at the bottom.

Here’s how you resolve this issue:

In your custom page, define a content block like this:

SamplePage.gsp

<!DOCTYPE html>
<html>
<head>
<meta name="layout" content="layoutPage"/>
<head>MyThinkPond.com Custom Page</head>
...
</head>
<body>
Some this page content
<content tag="javascript">
<script type="text/javascript" src="${request.contextPath}js/samplePage.js"></script>
</content>
</body>
</html>

In your template layout page add the content block to the bottom as needed like this:
layoutPage.gsp

<!DOCTYPE html>
<html>
<head>
<title><g:layoutTitle default="MyThinkPond.com"/></title>
...
</head>
<body>
<div>
Some template (header) content
<g:layoutBody/>
</div>
<!-- Common JS Files -->
<script type="text/javascript" src="${request.contextPath}js/common.js"></script>
<!-- Begin: Custom Page JavaScript Should Go Here -->
<g:pageProperty name="page.javascript"/>
<!-- End: Custom Page JavaScript Should Go Here -->
</body>
</html>

This will extract the JavaScript portion from samplePage and insert at the bottom of the layoutPage.

Here is the result of this magic in a page in the browser:

<!DOCTYPE html>
<html>
<head>
<titleMyThinkPond.com Custom Page</title>
...
</head>
<body>

<div>
Some template (header) content
Some this page content
</div>

<!-- Common JS Files -->
<script type="text/javascript" src="${request.contextPath}js/common.js"></script>
<!-- Begin: Custom Page JavaScript Should Go Here -->
<script type="text/javascript" src="${request.contextPath}js/samplePage.js"></script>
<!-- End: Custom Page JavaScript Should Go Here -->
</body>
</html>

You can see that the page specific JavaScript content got added towards the bottom as you intended it to be.

If this article has helped you, please add this article to your favorite social links so that others may also find this article.

Cheers & Happy Coding!

Posted in Grails, Groovy, Java | Tagged: , , , | 1 Comment »

Grails 2.X .gitignore file

Posted by Venkatt Guhesan on November 16, 2013

Grails

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.

 

 

 

So here are a few simple steps to help you create the correct .gitignore file for a Grails 2.X project:

Step-1: Create the following .gitignore file under the root Grails project folder:

*.iws
*Db.properties
*Db.script
.settings
.classpath
.project
.idea
eclipse
stacktrace.log
target
target-eclipse
/plugins
/web-app/plugins
/web-app/WEB-INF/classes
web-app/WEB-INF/tld/c.tld
web-app/WEB-INF/tld/fmt.tld

Step-2: Git does not allow you to check in empty (but essential folders). To avoid this you can run the following command:

find . -type d -empty -exec touch {}/.gitignore \;

The above command creates a empty “.gitignore” file below all folders. And since you now have non-empty folders, you can now check them in into Git so that if you check-out/clone the project in the future, you will have those essential but empty folders.

If you find this article useful, Tweet me on your Twitter account or +1 me on Google-Plus so that others can also benefit from this information.

Cheers

Posted in Grails, Groovy, Java, SourceControl - GIT | Tagged: , , , , | 2 Comments »

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

Posted by Venkatt Guhesan on October 24, 2011

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. These libraries are included as part of Tomcat and so an older version of those classes may give you a heartburn.

If your objective is to use some raw HTTP classes to create your requests and responses, then you can use the basic URL class to do most of the raw connection options. Although using HttpBuilder makes it a clean implementation, the URL class gives you very similar power without all the overhead of including the dependency classes.


def urlConnect = new URL(url)
def connection = urlConnect.openConnection()
//Set all of your needed headers
connection.setRequestProperty("X-Forwarded-For", "<your ip address>")

if(connection.responseCode == 200){
responseText = connection.content.text
}
else{
println "An error occurred:"
println connection.responseCode
println connection.responseMessage
}

So the trick to the Groovy URL class is to use the “openConnection()” method and then gain access to some of the raw functionality.

Cheers.

Posted in Grails, Groovy, Uncategorized | Tagged: , , , , | 7 Comments »

Not all Tomcat 6 classloaders must be equal

Posted by Venkatt Guhesan on July 1, 2011

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

  • Windows Vista, 32-bit
  • java version “1.6.0_26”
    Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
    Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
  • Grails (does not matter since I’ll be deploying a WAR)
  • Tomcat – apache-tomcat-6.0.32 (32-bit version of Tomcat)

Since the issue we are taking about deals with Grails, let’s get into he details of how I ended up with the WAR. In Grails, I issued the following command:

>grails war abcdefg.war

This creates a war file. When deployed under the 64-bit Tomcat, no issues. But when deployed under the 32-bit Tomcat. I was getting the

Jul 1, 2011 10:08:25 AM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart

(See my previous article on how I enabled debugging to get to the root cause of the issue.)

But after some debugging, what it boiled down to was a “Class Cannot Be Found” error:



Jul 1, 2011 11:29:25 AM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Error configuring application listener of class org.codehaus.groovy.grails.web.util.Log4jConfigListener
java.lang.ClassNotFoundException: org.codehaus.groovy.grails.web.util.Log4jConfigListener

In examining the war file, the JAR file named “grails-web-1.4.0.M1.jar” under the “/WEB-INF/lib” does not contain the needed “Log4jConfigListener” class under “grails-web-1.4.0.M1.jar\org\codehaus\groovy\grails\web\util\”

But clearly this class is inside this other JAR file named “grails-plugin-logging-1.4.0.M1.jar” under “\org\codehaus\groovy\grails\web\util\”.

And this identical war file works under the 64-bit Tomcat but not under the 32-bit Tomcat.

So how did I resolve the issue? I upgraded my 32-bit box to Tomcat 7.0 and this made it work. But clearly, there is an underlying issue with the class-loader under the 32-bit Tomcat 6.0.32.

Maybe someone reading this will have the answer to this issue.

Cheers!

Posted in Grails, Groovy, Java, Tomcat, web development | Tagged: , , , , | Leave a Comment »

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

Posted by Venkatt Guhesan on July 1, 2011

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.properties” file under ‘/WEB-INF/classes’ directory inside your WAR to help debug which one of the listeners is throwing this crazy error.

Well, this advise will most likely work for you if you are developing under an earlier version of Tomcat. If you are using versions 6.0 or above then continue to read on…

In Tomcat 6 or above, the default logger is the”java.util.logging” logger and not Log4J. So if you are trying to add a “log4j.properties” file – this will NOT work. The Java utils logger looks for a file called “logging.properties” as stated here:
http://tomcat.apache.org/tomcat-6.0-doc/logging.html

So to get to the debugging details create a “logging.properties” file under your”/WEB-INF/classes” folder of your WAR and you’re all set.

And now when you restart your Tomcat, you will see all of your debugging in it’s full glory!!!

Sample logging.properties file:

org.apache.catalina.core.ContainerBase.[Catalina].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].handlers = java.util.logging.ConsoleHandler

and you will most likely see a “class-not-found” exception. 😉

Look at the bright side, you’re now one step closer to the solution.

Happy coding!

Posted in Grails, Groovy, GWT, Java, Spring, Spring Framework, Tomcat, web development | Tagged: , , , , , | 25 Comments »

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

Posted by Venkatt Guhesan on June 10, 2011

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?

  1. Create a file called “settings.groovy” under “C:/Users/.grails” directory.
  2. Edit this file and add the following line:
    
    grails.work.dir="D:/grailswork"
    
    
  3. Make sure that the defined folder exists.
  4. Remove all other content, files and folders in the “.grails” folder.

Your are all set

Posted in Grails, Groovy, Java | Tagged: , , | 1 Comment »