AW: cgi output processed by cocoon?

[Henning von Bargen <H....@Triestram-Partner.de>]

> -----Ursprüngliche Nachricht-----
> Von:	Paul Russell [SMTP:paul@luminas.co.uk]
> Gesendet am:	Freitag, 30. Juni 2000 17:49
> An:	cocoon-users@xml.apache.org
> Betreff:	Re: cgi output processed by cocoon?
> 
> On Fri, Jun 30, 2000 at 05:11:29PM +0200, Erikjan Rijkers wrote:
> > I have been trying (without success) to have cocoon catch
> > cgi-produced output.  Is it possible at all?
> 
> Not as far as I know, no. You could potentially write a custom
> producer which executed the CGI script in a CGI compatible
> environment, but that would be non-trivial in the extreme
> since as far as I know, Java has no concept of piped IO.
> Your best bet would be to re-write the CGI scripts as XSP
> pages, I suspect.
> 
> Sorry!
> -- 
> Paul Russell                               <pa...@luminas.co.uk>

Of course Java can do piped IO.
A CGI producer would probably be a clean solution.

An example how to access a programs input/output streams
can be found in the JDC tech tips.
I include the tip here.
It should be easy (for someone who knows how to write a Cocoon producer, at
least)
to adapt the given example program for a CGI producer.
Henning

---------------- from JDC Tech Tips, February 15, 2000
------------------------

 J  D  C    T  E  C  H    T  I  P  S
                      TIPS, TECHNIQUES, AND SAMPLE CODE

WELCOME to the Java Developer Connection(sm) (JDC) Tech Tips, 
February 15, 2000. This issue covers:

         * Manipulating Hierarchical Data with JTree
         * Invoking Programs from Java(tm) Applications
         
These tips were developed using Java(tm) 2 SDK, Standard Edition, 
v 1.2.2.

You can view this issue of the Tech Tips on the Web at 
http://developer.java.sun.com/developer/TechTips/2000/tt0209.html.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

......

INVOKING PROGRAMS FROM JAVA APPLICATIONS

The December 14, 1999 issue of the Tech Tips, see
(http://developer.java.sun.com/developer/TechTips/1999/tt1214.html)
discussed how RMI (Remote Method Invocation) can be used to
communicate between programs. Another technique for communication 
is the Runtime.exec method. You can use this method to invoke
a program from within a running Java application. Runtime.exec 
also allows you to perform operations related to the program, such 
as control the program's standard input and output, wait until it 
completes execution, and get its exit status. Here's a simple C 
application that illustrates these features:

    #include <stdio.h>

    int main() {
        printf("testing\n");
        return 0;
    }

This application writes a string "testing" to standard output, and
then terminates with an exit status of 0.

To execute this simple program within a Java application, compile
the C application:

    $ cc test.c -o test
    
(your C compiler might require different parameters) and then 
invoke the program using this Java code:

    import java.io.*;
    import java.util.ArrayList;
    
    public class ExecDemo {
        static public String[] runCommand(String cmd)
            throws IOException {
    
            // set up list to capture command output lines
    
            ArrayList list = new ArrayList();
    
            // start command running
   
            Process proc = Runtime.getRuntime().exec(cmd);
    
            // get command's output stream and
            // put a buffered reader input stream on it
    
            InputStream istr = proc.getInputStream();
            BufferedReader br =
                new BufferedReader(new InputStreamReader(istr));
    
            // read output lines from command
    
            String str;
            while ((str = br.readLine()) != null)
                list.add(str);
    
            // wait for command to terminate
    
            try {
                proc.waitFor();
            }
            catch (InterruptedException e) {
                System.err.println("process was interrupted");
            }
    
            // check its exit value
    
            if (proc.exitValue() != 0)
                System.err.println("exit value was non-zero");
    
            // close stream
    
            br.close();
    
            // return list of strings to caller
    
            return (String[])list.toArray(new String[0]);
        }
    
        public static void main(String args[]) throws IOException {
            try {
    
                // run a command
    
                String outlist[] = runCommand("test");
    
                // display its output
    
                for (int i = 0; i < outlist.length; i++)
                    System.out.println(outlist[i]);
            }
            catch (IOException e) {
                System.err.println(e);
            }
        }
    }

The demo calls a method runCommand to actually run the program.

     String outlist[] = runCommand("test");
               
This method hooks an input stream to the program's output stream, 
so that it can read the program's output, and save it into a list 
of strings. 

     InputStream istr = proc.getInputStream();
     BufferedReader br =
         new BufferedReader(new InputStreamReader(istr));  
                
     String str;
     while ((str = br.readLine()) != null)
         list.add(str);
    
After all the output has been read, waitFor is called to
wait on the program to terminate, and then exitValue is called to
get the exit value of the program. If you've done much systems
programming, for example with UNIX system calls, this approach 
will be a familiar one. (This example assumes that the current 
directory is in your shell search path; more on this subject 
below).

If you're on a UNIX system, you can replace:

    runCommand("test");

with:

    runCommand("ls -l");

to get a full (long) listing of files in the current directory. 
But getting a listing in this way highlights a fundamental 
weakness of using Runtime.exec -- the programs you invoke aren't 
necessarily portable. That is, Runtime.exec is portable, and 
exists across different Java implementations, but the invoked 
programs are not. There's no program named "ls" on Windows 
systems.

Suppose that you're running Windows NT and you decide to remedy 
this problem by saying:

    runCommand("dir");

where "dir" is the equivalent command to "ls". This doesn't work,
because "dir" is not an executable program. Instead it is
built into the shell (command interpreter) CMD.EXE. So you need 
to say:

    runCommand("cmd /c dir");

where "cmd /c command" says "invoke a shell and execute the single
specified command and then exit." Similarly, for a UNIX shell like
the Korn shell, you might say:

    runCommand("ksh -c alias");

where "alias" is a command built into the shell. The output in this
case is a list of all your shell aliases.

In the example above of obtaining a directory listing, you can use
portable Java facilities to achieve the same result. For example,
saying:

    import java.io.File;

    public class DumpFiles {
        public static void main(String args[]) {
            String list[] = new File(".").list();
            for (int i = 0; i < list.length; i++)
                System.out.println(list[i]);
        }
    }

gives you a list of all files and directories in the
current directory. So using ls/dir probably doesn't make sense in
most cases.

A situation where it makes sense to use Runtime.exec is one
in which you allow the user to specify an editor or word processor
(like Emacs or Vi or Word) to edit files. This is a common feature
in large applications. The application would have a configuration
file with the local path of the editor, and Runtime.exec would be
called with this path.

One tricky aspect of Runtime.exec is how it finds files. For
example, if you say:

    Runtime.exec("ls");

how is the "ls" program found? Experiments with JDK 1.2.2 indicate
that the PATH environment variable is searched. This is just like 
what happens when you execute commands with a shell. But the 
documentation doesn't address this point, so it pays to be careful. 
You can't assume that a search path has been set. It might make 
more sense to use Runtime.exec in a limited way as discussed above, 
with absolute paths specified.

There's also a variant of Runtime.exec that allows you to specify
environment strings.

.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .

- NOTE
The names on the JDC mailing list are used for internal Sun
Microsystems(tm) purposes only. To remove your name from the list,
see Subscribe/Unsubscribe below.


- FEEDBACK
Comments? Send your feedback on the JDC Tech Tips to:

jdc-webmaster@sun.com


- SUBSCRIBE/UNSUBSCRIBE
The JDC Tech Tips are sent to you because you elected to subscribe
when you registered as a JDC member. To unsubscribe from JDC email,
go to the following address and enter the email address you wish to
remove from the mailing list:

http://developer.java.sun.com/unsubscribe.html


To become a JDC member and subscribe to this newsletter go to:

http://java.sun.com/jdc/


- ARCHIVES
You'll find the JDC Tech Tips archives at:

http://developer.java.sun.com/developer/TechTips/index.html


- COPYRIGHT
Copyright 2000 Sun Microsystems, Inc. All rights reserved.
901 San Antonio Road, Palo Alto, California 94303 USA.

This document is protected by copyright. For more information, see:

http://developer.java.sun.com/developer/copyright.html


This issue of the JDC Tech Tips is written by Glen McCluskey.

JDC Tech Tips 
February 15, 2000