noor - نور

A ride with hessian

Kefah Issa — Sun, 30 Nov 2008 20:54:02 +0000

Today, I came across what I call a deep-sea pearl. I came to know Hessian, the binary web service protocol.

Some time ago I blogged about the same idea Predictable Binary Representation (PBR)
, naively thinking that no one has done this before.

With the help of few friends, and some googling there turned out to be a zillion solutions that attempt to address that very problem; the etch has been really scratched by many, and the need for a compact, and predictable binary protocol is a must, no matter how fast the internet is or will become.

Parsing JSON, despite the fact that its among the most elegant human-readable text-protocols, would consume CPU cycles, and would be susceptible to errors more likely than not.

With a Binary protocol, you could …

Know the total size of a message (aka packet) before hand
Have its checksum that you can verify
For every single data entry, you would exactly know what size in bytes to expect next and what the type of data is, as opposed to checking for special marking characters to tell when an end of that item is reached.
No need to escape any special characters, should they occur plainly within the data. The problems JSON and XML have because of this deficiency are huge. Why all that hassle?! A question that puzzled me for years.
Far more compact in size, even without compression. There are no xml tags repeating for every node. In hessian, a dictionary of entry-names is only defined once at the header, then corresponding id’s are used across the message.

From the technical perspective, when we talk about web services, we are talking about software-to-software communication. As such Human-readable protocols are mere overhead to say the least. We should focus more on optimizing software-to-software protocol than making it look good to the human eyes.

Forget about XML, JSON or anything similar; and consider the beauty, performance, and optimization of binary protocols.

Despite the competition from Thrift (by facebook), Protocol Buffers (by google), and ASN.1 (older standard), along many others, Hessian (by Caucho) stands out from the crowd …

Let me tell you why I quickly fell in love with Hessian,

Dead-simple to use, both server-side and client-side.
Can be equally used on Java, C/C++, .Net, Ruby, PHP, Flash and so forth.
Saves tons of bandwidth, cpu cycles and increases reliability
Runs via the firewall-friendly http-protocol

It was intriguing when reading the features and specifications. Being the hands-on person I am, I only believe what I can do …

So, lets roll up our sleeves and get in a quick practical session with Hessian ….

Hessian and Java

Preparations

Create few folders to host our samples

mkdir -p hessian/lib
cd hessian

I downloaded the latest hessian library jar file to my local lib folder.

wget 'http://hessian.caucho.com/download/hessian-3.2.0.jar'
mv hessian-3.2.0.jar lib

Using jetty 6.1.x or 7.x would do equally well,

wget 'http://dist.codehaus.org/jetty/jetty-6.1.12/jetty-6.1.12.zip'

Unpack

 unzip jetty-6.1.12.zip

we only need three jars, as we are going to use the compact embeddable jetty jars.

mv jetty-6.1.12/lib/jetty-* jetty-6.1.12/lib/servlet-api-2.5-6.1.12.jar lib/
rm -rf jetty-6.1.12

Make sure to define CLASSPATH environment variable that would properly point to all the jars in our lib folder. for that I use the following setenv.sh script that can be sourced every time needed.

setenv.sh

#!/bin/bash
CLASSPATH="."
for myjar in $(find $PWD/lib -iname '*.jar'); do CLASSPATH=$CLASSPATH:$myjar; done;
export CLASSPATH

Then you can source it like this

source setenv.sh

Define (create) our API interface using POJO

BasicAPI.java

public interface BasicAPI {
	public String hello ();
}

Create the service API implementation and expose via an embeddable servlet container

BasicService.java

import org.mortbay.jetty.servlet.Context;
import org.mortbay.jetty.Server;
import com.caucho.hessian.server.HessianServlet;
 
public class BasicService extends HessianServlet implements BasicAPI {
	private String _greeting = "Hello, world";
 
	public void setGreeting(String greeting) {
		_greeting = greeting;
	}
 
	public String hello() {
		return _greeting;
	}
 
	public static void main (String [] args) throws Exception {
		Server server = new Server(8080);  
		Context context = new Context(server, "/", Context.SESSIONS);
		context.addServlet(BasicService.class, "/basic");
		server.start();
	}
}

Compile the Java Server API and Interface and start our service

javac BasicService.java 
java BasicService

Create the Client app

Client.java

import com.caucho.hessian.client.*;
public class Client {
	public static void main (String [] args) throws Exception {
		String url = "http://localhost:8080/basic";
		HessianProxyFactory factory = new HessianProxyFactory();
		BasicAPI basic = (BasicAPI) factory.create(BasicAPI.class, url);
		System.out.println("basic.hello() said : " + basic.hello());
	}
}

Compile and run the client

javac Client.java
java Client

C’est tout! (Thats all). Your java-based client-server hessian binary protocol web service system is up and running. Wow!

Hessian in Ruby

After download and unpacking hessian library for ruby it only takes three lines of code to connect to our java web service

require "lib/hessian.rb"
client = Hessian::HessianClient.new('http://localhost:8080/basic')
print client.hello

It seems that you can also easily create hessian-based services via ruby, but i didn’t dig into it.

Hessian in PHP
Download, unpack and make accessible via apache the php library of hessian. There is a minor glitch in Hessian PHP in which the DateTime class conflicts with Php 5.2 pre-defined DateTime class. Simply re-touch the library code and rename that class.

php_hessian_client.php


include_once 'HessianClient.php';
$proxy = &new HessianClient('http://localhost:8080/basic');
echo $proxy->hello(); 
?>

You can also write a simple hessian web service api provider …
php_hessian_service.php


class Math{    
  function add($n1,$n2) {        
    return $n1+$n2;    
  }    
  function sub($n1,$n2) {        
    return $n1-$n2;    
  }    
  function mul($n1,$n2) {        
    return $n1*$n2;    
  }    
  function div($n1,$n2) {        
    return $n1/$n2;    
  }
}
include_once 'HessianService.php';
$wrapper = &new HessianService();
$wrapper->registerObject(new Math);
$wrapper->service();
?>

More!
Wait, there is more!

Lanuages Support Hessian is supported on Grails via the remoting plugin, I didn’t try the rest of the languages supported by hessian yet, but it looks that they would be fine.
Authentication and Http Proxy
You can also make use of Http Authentication to add a security layer on top of your api’s, and proxy-by-pass in case there is a proxy in the way.
Additional Services built on top of Hessian
There are also two interesting technologies by Caucho built on top of hessian, viz BAM and comet .
Performance benchmarks
This is an interesting benchmark, demonstrating how hessian perform against classical text and binary protocols.

Gotcha’s
I can see a couple of minor gotcha’s in Hessian library that can be addressed …

A. The language-support projects seem not to be updated for a long time, some more than a year. Those projects only support hessian protocol version 1.0.x and don’t support the latest hessian 2 protocol.

B. The thing I really missed is a JavaScript library that connects me to a hessian service directly. That alone will immediately offer a great value to AJAX applications. I don’t see that far from possible, given the fact that there is already an ActionScript implementation for Flash. I hope someone will dedicate the effort to make that a reality.

Conclusion
The Internet is coming back to its senses , using Binary-based communication protocols might sound 30-year old concept, but it brings a lot on the table that current text-based human-readable protocols don’t.
I am all forward for making use of such protocols in SaaS / SOA setups. Simply Binary Protocols such as hessian, could provide an alternative communication option for today’s SOAP/XML-RPC/JSON ones.

Predictable Binary Representation (PBR)

Kefah Issa — Mon, 01 Sep 2008 10:30:56 +0000

XML is nice, YAML and JSON are cool, proprietary formats for binary encapsulation are not good; those are all facts that many people agree to.

But they all the good solutions remain sub-optimal when it comes to network bandwidth overhead and cpu usage needed to parse the blob every time.

This might have, and should have been considered long time ago. I didn’t find any open format to cover it however, hence I’m suggesting one…

Features

The following needs are not addressed by those data representation formats, but are by PBR :

1. Supporting Binary content. You need to revert to Base64 or the like to do this. but its not natively supported.
2. Completly Predictable (so no guess work in parsing). I don’t want to waste cpu cycles and logic to parse the content in an unpredicable manner. I want to be able to exactly tell what the next step a head and how much data I need to manage.
3. No escaping. I really don’t like escaping. I want to be able to put my content AS IS ™.
4. Reliable : Checksum. Thats a cool addition that will make me confident of my data.

Here I outline the details of PBR (pronoucde Pe.be.r) along with reference implementation (TBD) :

The data is represented in a message.

Each message is made of envelope header and body.

The Data elements (Entries) are organized in Entry-Name/Entry-Value pairs.

The body is simple a list of Entries (aka root node).

Supported Data Types

Just like JSON PBR does support the basic and most used data types that cover most of today’s modern needs

Boolean
String (UTF-8)
Binary
Integer
Double
Date
Map (List is just a map with unnamed entries)

- Depth or number of entries is unlimited.
- Content-size limit it 2^31 (2GB).

PBR is not human readable, but using a binary editor or in the future a simple PBR reader would allow to easily read and manually manipulate the data.

Envelope Header

PBR Version (2 Bytes, signed short)
MD5 Checksum of the body (16 Bytes)
Total Message Size exclusive of the envelope header in Bytes(4 Bytes, signed long)
Number of Level-One Entries (4 Bytes, signed long)

Total Envelop Header size is 26 bytes

The Message Body is a list of data entries. The number of those data entries (1st-level) is as defined in the header above.

Data Entry

Entry Type (1 Byte, signed byte) : The type id of the entry, 1..7 as per the types list above.
Entry Name Size (1 Byte, signed byte) : The Size of the Name of the entry. can be set to 0.
Entry Name Value (0..127 Bytes) : The entry name in UTF-8.
Number of Children (4 Bytes, signed long)
Value Size : (4 Bytes, signed long) : The size in bytes of the value of this entry.
Value : ( 1 .. 2^31)

Any entry can have children, just like XML node.

However it can only either have children or a value (i.e. Number of Children ==0).

If Number of Children > 0, then the value contains an aggregation of a list of other entries that need to be read.

Groovy with SQLite

Kefah Issa — Tue, 15 Jul 2008 21:45:12 +0000

SQLite is a very interesting database engine. Its performance, simplicity and that fact it runs as a library (not a server) make it the perfect candidate for small project with few users.

Today I experimented with accessing SQLite database from within groovy.

I tried the SQLite JDBC libraries and all went fine. SQLite JDBC jar file, magically contains both Native and Pure java versions, and it automatically chooses the native one when running on Linux, Mac and Windows.

If you want to try the following snippets on groovy, make sure to copy sqlitejdbc-v052.jar to your ~/.groovy/lib.

Here is a one-liner on creating the GSQL object of a sqlite database. One nice thing to note is that you don’t have to have the test.db file created. if its not there it will be automatically created for you.

sql = groovy.sql.Sql.newInstance("jdbc:sqlite:/home/kefah/test.db","org.sqlite.JDBC")

Creating schema, insert and query

sql.execute("create table students(name, age)")
sql.execute("insert into students(name, age) values( 'Ali Baba', 20)")
sql.eachRow("select rowid,name,age from students;") {
     println "${it.rowid}: ${it.name} ${it.age}"}

… a more elaborated DDL

sql.execute('''
create table teachers( login primary key, firstname, lastname);
create unique index teachers_name on teachers(firstname, lastname);
''')

Datasets are another nifty way to access the data

students = sql.dataSet('students') 
students.add(name:"Abu Mohammed", age:35)
students.each {println " ${it.name}, ${it.age}"}

Note that sqlite datatypes are automatically induced from the data you insert into the table, or you can specify them at DDL creation time. aka Optional Typing, just like groovy

Further more, you can create both inmemory and persistent (on harddisk) sqlite databases.

sql = groovy.sql.Sql.newInstance("jdbc:sqlite::memory:", "org.sqlite.JDBC")

so all in all its a perfect fit for groovy and (once working for grails too).

[Update] A reader mentions below that he could successfully get sqlite running on grails too. Which is great news.

QT for GNOME

Kefah Issa — Tue, 15 Jul 2008 21:23:34 +0000

I feel very strongly about the historical opportunity for the GNOME community to switch their tool kit over to QT 4.x. GNOME was originally a fork of effort from KDE back in the old days when QT was not GPL-enabled.

Now it is — and so for many years — I can see no reason why GNOME can’t do the switch.

This will be a major effort of course, and there will be two types of opponents in the GNOME community :
A. C-Lovers : Those who like C-language (not C++) as GTK and GNOME in general is more C-Lang than C++.
B. Mono-lovers : Those who are after mono, which is not a very successful imitation for Microsot .NET.

Lets put that a side for a minute and lets give it a hard look, GNOME development has been stalled due to many technology limitation. Even with the latest GUADEC and talk about tab-enabling (which i still think is a joke).

So, despite our love and hate, at the end of the day QT is THE most mature toolkit in the FLOSS world. It deserves all the blessings it can get … and very well deserves to be considered as an excellent candidate for the GNOME project, especially after what happened with KDE4 and their move into directions that are far from the users and community. The failure in KDE4 was a result of the people who assumed its leader ship in the last two years, and its not in any way related to QT.

Weaving Groovy Threads

Kefah Issa — Sat, 12 Jul 2008 08:57:36 +0000

Could writing threads be easier than this? I wonder.

class Storage {
	List stack = []
 
	synchronized void leftShift (value) {
		stack &lt;&lt; value
		println "Push : $value"
		notifyAll()
	}
 
	synchronized Object pop() {
		while(stack.isEmpty()) {
			try { wait() } catch (e) {}
		}
 
		def value = stack.pop()
		println "Pop  : $value"
		return value
	}
}
 
storage = new Storage()
 
Thread.start {
	10.times {
		storage &lt;&lt; it
		sleep 100
	}
}
 
Thread.start {
	10.times {
		sleep 200
		value = storage.pop()
	}
}

Groovy Introspection, know what you have

Kefah Issa — Sat, 12 Jul 2008 06:31:59 +0000

Lots of fun with Groovy introspection. Java already provides something similar but in Groovy it has completely different taste and use.

I actually use introspection often from within groovysh to investigate on what a class provides, just like auto-complete in modern IDE’s

// Whats is your class?
 
a = 5
b = "Hello"
 
println "Class of a : ${a.class} nClass of b : ${b.class}"
 
 
// Introspection, know all the details about classes :
// List all constructors of a class
String.constructors.each{println it}
 
// List all interfaces implemented by a class
String.interfaces.each{println it}
 
// List all methods offered by a class
String.methods.each{println it}
 
// Just list the methods names
String.methods.name
 
// Get the fields of an object (with their values)
d = new Date()
d.properties.each{println it}
 
// Not much related, but interesting : Dynamic Method calling
class Greeting{
  def sayHello(){
    println "Hello, Stranger"
  }
  def sayHello(String name){
    println "Hello, ${name}"
  }
}
 
g = new Greeting()
s = "sayHello"
g."${s}" ("Ali Baba")

Databases with Groovy

Kefah Issa — Sun, 06 Jul 2008 23:37:09 +0000

GORM is cool, but groovy Sql is for the simpler cases were you just need to interact with the database.

groovy.sql.Sql is just an amazing Groovy class. See this link for a mind-opener level of ease when dealing with databases and this is an interesting article from IBM Developer works : Practically Groovy: JDBC programming with Groovy

Watch :

Define your database sql object (aka database swiss-nife)
With Oracle

sql = groovy.sql.Sql.newInstance("jdbc:oracle:thin:@myoraclehost:1521:mydbinstance", 
                        "myuser", "mypassword", "oracle.jdbc.driver.OracleDriver")

With MySql

sql = groovy.sql.Sql.newInstance("jdbc:mysql://localhost:3306/mydb", "user", "pswd", 
          "com.mysql.jdbc.Driver")

and voala, you’ve got a database connection that you use to conduct most needed db operations.

Remember to place your Oracle JDBC driver (in my case ojdbc14.jar) and/or your mysql JDBC driver (mysql-connector-java-5.1.6-bin.jar) into ~/.groovy/lib

Did I mention that you can easily call Oracle Stored procedure?
Three input parameters, two output parameters, and one single line of code

import groovy.sql.Sql
sql.call ("{ call MY_SP ( 'My in param', ${Sql.inout(Sql.INTEGER(context))}, 'my in param2', 'myin params3', ${Sql.inout(Sql.VARCHAR(result))}) }")  {context,result -> println "$context and $result" }

Groovy Simple Templates

Kefah Issa — Sun, 06 Jul 2008 23:28:54 +0000

Dynamic text templates are joy to do in groovy.

I came across the need of such functionality many times during my past projects, and now with the new one.

Not only can I place my bound variables and reuse them in the template, but I can also run legal groovy code.

 
text = '''
 Dear "$firstname $lastname",
 So nice to meet you in <% print city %>.
 See you in ${month},
 ${signed} 
 ${10.times{println it}}
 '''
params = [firstname:"Ali", lastname:"Baba",city:"Baghdad", month:"June", 
              signed:"Cool-guy"]
template = new groovy.text.SimpleTemplateEngine().createTemplate(text).make(params)

For this particular here-document example, note the single-quotes on the text variable, as double-quotes will cause the string to be treated as GString and hence resolve our bound variables earlier than needed.

Another way to do even simpler templates :

messageTemplate = ' "Let today ${new Date()} be a new start" '
message = evaluate(messageTemplate)

Bear in mind that the examples above are ment to cover the case where the template string comes from else where (text file, user input) and has to be processed. otherwise the evaluate example would sound useless, because one can just run the line “Let today ${new Date()} be a new start” without evaluate.

Here is a wider coverage for the topic

The wars are over, let the era of peace and prosperty begin!

Kefah Issa — Sat, 05 Jul 2008 08:50:08 +0000

In the computer industry, the pendulum of debate, innovation, and building infrastructure at one end vs building up complete and ready solutions on the other end keeps swinging every 20 years (more or less).

So here it comes, to the rest of the thinkers and planners and to the delight of the builders and engineers; the era of FLOSS

In this blog, I might sound biased or short-sighted. Its really just an opinion based on my day to day findings. Please don’t be harsh on me, if you want to comment, take me completely out of the picture and focus on the ideas and let them debate in a professional fashion.

In the beginning there was the operating system

In my professional view, GNU/Linux (and FLOSS) is the clear winner (over MacOs and Windows) …
GNU/Linux is not a prospect, or a great idea any more. its a solid fact on the ground. that is being used millions of people in mission critical systems addressing real life needs, both at home and at work. with an ever increasing adoption rate, the whole FLOSS era has certainly passed its childhood as being opted by hopiests and enthusiasts into being used in real life by real people wither individuals or organizations.

In a very ironic and unexpected fashion, Windows Vista is a great failure. It took too long to come up with, and when it came it was a disaster on two important aspects : performance, hence requiring considerably more hardware power to run, and stability.

This very incident is what probably gave GNU/Linux the time to get a head of Windows.

On the server-side

The FLOSS has the lead in adoption and innovation, this wasn’t the case few years ago.

Java et al has become fully open source; Groovy and Grails is second to none when it comes to agile web-development, Ruby on Rails started the new era of web 2.0 and RAD web development, Php is the people’s scripting language, Apache is the leading web server, MySQL and PostgreSQL have the full horse power to compete with the big boys and so forth.

The road a head is so clear to the point where there is no need to make any case for FLOSS on the server side. FLOSS offers a wide variety of options covering most of today’s needs.
No need for me, as a technology consultant, to ever think twice about choosing FLOSS vs Proprietary.

What about Open Solaris? That will surely continue to be the big brother covering up for GNU/Linux for even more critical situation. The relation between Open Solaris and GNU/Linux is not a competition, its rather complementary.

On the desktop/client-side

Within GNU/Linux there has been another war, the War of the Desktop Environments (DE) and the war of toolkits …
On the Desktop Environment side, I believe its time to declare that there has been no winner!
Not KDE nor GNOME.
KDE went into a very unpleasant direction with KDE4, its becoming more like the fantasy of its developers as opposed to being practical and usable. With the huge effort and long time (2years plus now) put on those fantasies as opposed to just upgrading its core tool kit from Qt 3.x to Qt 4.x means its not expected that KDE4 steers back to doing just that. KDE 3.x series was the best ever released Desktop environment on Linux platform.
GNOME has caught the infection, actually even before KDE 4 started. With the completely unjustified adoration to Microsoft … comes the Mono project. Which is – with all respect to the hard working people who made it happen – a shame. Most of the FLOSS working class who create software have realized that following on the heels of someone else is a never ending story, and will get us no where. FLOSS project leaders need to have independent thinking and a clear vision. Let alone the ugly heaviness of the Mono project and its apps, compared to plain gtk.

For my day to day use, I am relying on XFCE is my DE of choice, as it covers all my needs, and does a great job in letting me focus on the apps rather than DE. ( I used to be a die-hard KDE users for the past seven years)

XFCE is so close to becoming a winner and surpassing KDE and GNOME with bounds and leaps, when it comes to simplicity, and performance.

One important good thing that has been going on for the last few years, is freedesktop.org doing a great job in standardizing the desktop operation regardless of the running environment. All distros have also adopted dbus as their core inter-process communication engine.
Minimizing the importance the importance of KDE or GNOME and maximizing the importance of standardization. This is why XFCE was able to fit so easily.

Back to the basics, XFCE (or the like of a lightweight DE) along with Gtk/Qt only apps seem to be the natural direction. Given the fact that Gtk and Qt app run on the other platforms without much of a hassle. Application developer from the two camps (kde and gnome) need now to steer away from DE and back into being Toolkit centric; or at least offer that option.

Both Qt and Gtk only apps are fast and snappy and don’t require lots of depdency. Unlike DE Apps, which would require the whole underlying libraries and subsystems of the respective DE.

If I like konqueror why should I live with the kde dinosaur?!

As with the Gtk case, more and more Qt-only apps are showing (e.g. Speedcrunch, Aurora), some KDE apps are also supporting Qt-only mode (kchmviewer).

I tried those types of apps on GNOME or XFCE only environment and they are a breeze to run. No performance overhead, despite the fact they need to load Qt libraries, but this happens only once and doesn’t eat much memory.

In the debate between Qt and Gtk, and despite all the nice things Gtk offers. Qt is the clear winner.
Qt 4.4 is becoming the jewel of the crown in the FLOSS world, Qt 4.5 is expected to shine even more.

Last but not least, Qt being GPL’ed on all platforms eliminates the last obstacle of adoption. Remember, this was the very reason why GNOME started off from KDE.

I predict that Qt Apps will have a huge edge, presenting cross-platform open-source alternatives, every overtaking existing big names such as firefox and Openoffice.

Web-kit based Web browser
Phonon based player
Office suite that natively supports ODF
Simplified Desktop environment that is xfce-like, that runs on all platforms
… and so forth

The very notion of becoming cross-platform is really important and intriguing; no more do you as an application developer limit your user with their choice of platform. hence giving your app a far wider base of audience.
Look at what OpenOffice and Firefox did. They are almost every where.

Same token applies on embedded systems, wither mobiles, sub-notebooks, modems and routers, media centres and so forth.

Conclusion

The important and strategic point to bear in mind is the peace of mind and durability of the software. All FLOSS software is being built to live far longer than its counter part. No fear of vendor locking or platform dying out. Being cross platform means both developers and users will feel better.

This year, 2008, FLOSS community has completed laying down the technology foundations for many years to come. The pillars and infrastructure is there, its now the time to reap the advantage and develop even more mature applications.

Investing in learning those technologies is a guaranteed one, and could only mean having the advantage.

That shift of mentality and focus is needed to make the next wave of change.

Does that mean innovation on those areas has reached its limit? no. but it means the pendulum is now shifting to building up applications as the infrastructure and its related thinking process is completed.

The road for the next years is clear for FLOSS to become the leader in the computer software industry. I am very optimistic on where FLOSS stands now and where its heading, having great confident that the best is yet to come.

GEdit with Groovy

Kefah Issa — Sat, 14 Jun 2008 07:22:26 +0000

Need a cool development setup for Groovy and Grails on Linux?

No I don’t mean Eclipse nor IntelliJ, and Yes, I’m smart enough for that I’m dumping the autocompletion and autoerror detection; at least I know i’m smarter than the current plugins for those two.

Searching for a good development setup for my groovy and grails projects, i tried IntelliJ and Eclipse along with their groovy and grails plugins. I wasn’t impressed, more so because they fail to properly understand things and give you errors where there are none.

So, I eneded up using GEdit which is a very nice piece of software. I whished Geany had groovy syntax highlight support, but it doesn’t, further more, Geany doesn’t do a good job when dealing with Arabic text inside the code; while GEdit has a fairly good support for arabic.

GEdit doesn’t come with groovy support out of the box, after a short search I found this article :
http://www.sudovi.com/blog/show/teach_gedit_grails
That worked for me.

Here is how it looks like :

I then compiled all the steps needed to enable groovy on gedit in one handy bashscript file for Fedora 9:

 
cat > groovy-gsp-mime.xml << EOF


 
	
		
		Groovy Source File
		
	
 
	
		
		Grails GSP File
		
	
 

EOF
 
cat > groovy.lang << EOF


  
    text/x-groovy
    *.groovy
    //
    /*
    */