Technology insights, news and tips.

  • Sun
    July 15, 2008

Common Gateway Interface in GlassFish

Common Gateway Interface (CGI)
supports dynamic contents in web environment.
CGI programs are executable programs in the server platform with specific output.
It can be a Bourne shell script, Perl script or even a C binary executable.
It was very popular before the the appearance of Servlet, JSP and PHP.
The CGI code in GlassFish
workspace is based on Tomcat.
In GlassFish v3, CGI will be a supported feature.
Let us look at a very simple example.

Create a CGI script

In our example, we have a simple Perl program,
hello, to print a hello message and the timestamp
of the server.


    print "Content-type: text/html\n\n";

    print "Hello World: ";

    print scalar localtime;

    print "\n";

Enabling CGI processing and packaging the war file

The CGI processing can be enabled in a war file by adding
CGIServlet et al in web.xml as follows:











In this case, one need to package the hello
under the default cgiPathPrefix which is
For security, it is highly recommended that the contents / binaries of
CGI programs should be prohibited from direct viewing or download.

Alternatively, one can enable CGI by uncommenting the corresponding sections
in default-web.xml.

In our case, the CGI program can be
invoked through http://localhost:8080/YOUR_CONTEXT/cgi-bin/hello .

Configuration of CGIServlet

One can configure CGIServlet by specifying the init-param as follows:

cgiPathPrefixStringsubdirectory containing the cgi programsWEB-INF/cgi
debugintdebug level0 (no debug)
executableStringexecutable for running the CGI scriptperl
parameterEncodingStringencoding use for parameterSystem.getProperty("file.encoding", "UTF-8")
passShellEnvironmentbooleanwhether to pass environment properties to CGI programfalse

CGI with native executables

GlassFish v3 CGI can work with native executables as follows:

  • set the init-param with name executable to be the empty String in web.xml
  • has exploded directory structure for the war in a directory, say /export/cgitest
  • make sure those executables has the executable bits set correctly
  • deploy the "directory" (not the "war"), for instance
    asadmin deploy /export/cgitest

Note that one works with the exploded directory structure rather than war
file as the executable bits information is lost during the process of
jar and unjar.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.