running perl scripts

[klutus]

I have been searching for ways to make PERL work JBOSS/Jetty 3.2.1.

After 2 hours of searching, not finding a single description of how to make perl work within Jetty...I tried.

...and it WORKED without any particular settings...

Just wanted to tell somebody else looking...

[klutus]

I'm an idiot!

It did not work at all...so I'd really need some help.

[jonlee]

You can modify the jbossweb-jetty.sar/META-INF/jboss-service.xml and add a proprietary element:

/cgi-bin/*
/my/cgi-bin/

Common Gateway Interface
/
org.mortbay.servlet.CGI
<!-- Set initParams for CGI -->
/bin:/usr/bin:/usr/local/bin
perl



It tends to be slow since it doesn't cache Perl in-line like Apache. So every invocation involves a new invocation of Perl.

This information is from the Jetty guys. There is also an alternative configuration on a per web-app basis.

[klutus]

Thank you jonlee,

unfortunately this does not solve my problem,

I'm running Jboss3.2.1/Jetty/WinXP.

I have several virtual hosts defined in jetty-web.xml files located in different WAR files.

Some of the virtual hosts have several WAR associated with them, to acomplish this - I have put multiple WAR's in one ear.

Going about to create a CGI servlet in a WAR, but not in all WARs i tried putting this into a jetty-web.xml files under WEB-INF in a WAR:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure 1.2//EN" "http://jetty.mortbay.org/configure_1_2.dtd">



www.eldenmalm.com<!-- this adds a virtual host mapping to this Application Context -->

<!-- the below setting does not work, due to the lack of an addContext method in org.jboss.jetty.JBossWebApplicationContext-->

/mod_perl/*<!- What does this argument actually do?? -->
/mod_perl <!-- Does this limit the perl scripts to stay in one predefined directory?? -->

Common Gateway Interface
*.pl
org.mortbay.servlet.CGI

commandPrefix
c:/perl/bin/perl.exe




###########################

As I marked above this does not work, nor is it possible to move the out side th e <Configure class="org.jboss.jetty.... tags.

I have read quite some posts in many places and some things have crossed my mind...

From a purely theoretical perspective, the parameters to the CGI servlet in configuration would atleast be:
what urls maping to involke the servlet on
Example: <url-mapping>*.pl</url-mapping>

Also that very same servlet, in windows environmants would need to have the interpretor path defined
somthing like:
<init-param name="Interpretor path">c:/somthing/dir/perl/bin/perl.exe</ init-param>

These are the only two parameters needed... from a theoretical persective that is.

################################

To my question... how should this be done in practice?

(I'm amazed that this can be so complicated)


// Jan

[jonlee]

The recommendation on a per web-app basis is to create in the web.xml a mapping for the CGI extension like this:

<servlet-name>CGI</servlet-name>
<servlet-class>org.mortbay.servlet.CGI</servlet-class>
<init-param>
<param-name>cgibinResourceBase</param-name>
<param-value>/some/cgi-bin</param-value>
</init-param>
<init-param>
<param-name>commandPrefix</param-name>
<param-value>/my/bin/perl.exe</param-value>
</init-param>

<servlet-mapping>
<servlet-name>CGI</servlet-name>
<url-pattern>/*.pl</url-pattern>
</servlet-mapping>

You'd have to get on the Jetty mailing list or forums to ask your specific questions. The command prefix AFAIK, says that this is the executor and the specified script is an argument then in the formed command line started by the CGI servlet. It gives you the option that the specified mapping is directly executed if you don't provide a command prefix. If you provide a prefix, the prefix will provide the start of the command line.

So you'd get /usr/bin/perl myScript.pl, executing with the specified context as the directory of execution (so you could have your config scripts for your perl in that directory as well, for example).

Again from my understanding, the context tells which directory to find perl scripts in - which is then a very general execution area.

Again, this information has been supplied by the Jetty guys and I haven't necessarily delved too deeply into it. I escaped from the Apache/Perl world so it is not something I have particularly revisited unless there is an absolute need. ;)

[klutus]

Thank you,

making the following statements in web.xml of WAR actually made it work ...slightly ...that is in one WAR it worked, but in the other I get a 500 CGI execution error. Application exit with (255)


<servlet-name>PerlCGI</servlet-name>
<servlet-class>org.mortbay.servlet.CGI</servlet-class>
<init-param>
<param-name>commandPrefix</param-name>
<param-value>c:/Perl/bin/perl.exe</param-value>
</init-param>

<servlet-mapping>

<servlet-name>PerlCGI</servlet-name>
<url-pattern>*.pl</url-pattern>
</servlet-mapping>

##########################

The difference to your example is the:
<init-param>
<param-name>cgibinResourceBase</param-name>
<param-value>/some/cgi-bin</param-value>
</init-param>

I expect this to have to to with the context of "where" the script is run, defining for example where to find files with relative path.

What I don't get is what to set this value to?

Should it be the root context of my WAR ? or does the CGI stuff demand that the scripts, asuming they need access to files with relative filepaths, are all located in one directory the "//server/some/cgi-bin" in your example above?

any way once I get this working, I'd like to publish my findings somewhwere in a how to repository.... which could spare many loads of hours I guess....

// Jan

[klutus]

These were the errors I got:

In page:
HTTP ERROR: 500 Failed to exec CGI

In log:
14:01:44,421 WARN [jbossweb] WARNING: Non-zero exit status (255) from CGI program: C:\Jboss\jboss-3.2.1\server\default\deploy\intranet.ear\root.war\loganaly
zer\cgi-bin\awstats.pl


I also noticed that the servlet mapping was important...

<servlet-mapping>
<servlet-name>PerlCGI</servlet-name>
<url-pattern>*.pl</url-pattern>
</servlet-mapping>

this URL mapping traps the request and executes the servlet with the error above.

<url-pattern>/*.pl</url-pattern><!-- note slash -->

this url mapping does not execute the servlet, but renders the source of the script.

In a different topic, somebody told me that Jasper (the JSP parser) does not like contexts without the "/" except in the welcome file list case .... where I guess there is some sort of built in servlet handling file.

[jonlee]

Actually, it doesn't like an unspecified context path for jsp-file tag. But yes, servlet pattern mapping also does not like unspecified context paths. My typo there.

The error is being thrown it seems because the perl script is not returning 0 as an exit code. Is there a reason that this might be the case? I would also try a simple perl script that returns 0 as an exit code to see that you are executing with the perl interpreter properly.

[klutus]

Target: Make PERL scripts execute in Jboss3.2.1/Jetty bundle for winXP.

How to:
When you want to enable Perl scripts in a WAR, you do that by deploying a servlet that is shipped with the standard distribution. The following code is needed in the web.xml of the WAR:


<servlet-name>PerlCGI</servlet-name>
<!-- the name of the servlet -->
<servlet-class>org.mortbay.servlet.CGI</servlet-class>
<!-- the servlet class i.e the "wrapper" that calls the perl interpretor --->
<init-param>
<!-- the servlet container is platform independent, thus it is not (yet) aware of where and how the perl interpretor exists, it is necessary to define this at least on windows systems. CommandPrefex inserts the parameter value in the command line used by the servlet to execute the script. -->
<param-name>commandPrefix</param-name>
<param-value>c:/Perl/bin/perl.exe</param-value>
</init-param>



<servlet-mapping>
<servlet-name>PerlCGI</servlet-name>
<url-pattern>*.pl</url-pattern>
<!-- the url pattern is used just like url patterns are in other servlets, pls note that "/*.pl" does not work and will render you only the source code of your perl script.-->
</servlet-mapping>

What is mssing now is an explanation of the:
<init-param>
<param-name>cgibinResourceBase</param-name>
<param-value>/some/cgi-bin</param-value>
</init-param>

What does it do?, why is it here?, when is it needed?.
I have noticed that I can change the error message from my script by defining it, and also get some more errors in the log... :-)

But I will try to understand the rest of my problematics at the jetty forum, and also ask the distributor of my script...

With the above set up I managed to run scripts correctly....

[klutus]

Some more anecdotes around this strange issue...

On my particular WinXP system, I can run perlscripts with the extension ".pl" without without any prefix:

awstats.pl
works as well as

perl awstats.pl

With this in mind I tried removing the comandlinePrefix init parameter with the result that I get "nothing" in my browser .... not a 404 neither a 500.

in the log I find this though:
21:27:36,343 WARN [jbossweb] WARNING: GET /loganalyzer/cgi-bin/awstats.pl?config=amazingports HTTP/1.1
java.io.IOException: CreateProcess: C:\Jboss\jboss-3.2.1\server\default\deploy\intranet.ear\root.war\loganalyzer\cgi-bin\awstats.pl error=193
at java.lang.Win32Process.create(Native Method)
at java.lang.Win32Process.(Win32Process.java:63)
at java.lang.Runtime.execInternal(Native Method)
at java.lang.Runtime.exec(Runtime.java:550)
at java.lang.Runtime.exec(Runtime.java:416)
at org.mortbay.servlet.CGI.exec(CGI.java:237)
at org.mortbay.servlet.CGI.service(CGI.java:159)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
at org.mortbay.http.HttpServer.service(HttpServer.java:863)
at org.jboss.jetty.Jetty.service(Jetty.java:460)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:775)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455)


an explanation of this behaviour would perhaps shed some light on this issue.

// Jan

[jonlee]

In order to go someway to answer the following, although the Jetty group should hopefully clarify this:

As I understand it, the resource base is an equivalent to the "start in" for Windows (look at shortcut definitions). The reason you need it is so that execution is performed as though in that directory/path. This is useful if your script expects certain resources to be at that execution point. This is similar to double clicking a Windows program and that program not finding configuration files because the execution is not performed from the directory in which the .exe is located.

Windows defines an association between the .pl and perl.exe. These associations are OS specific. Since Java is as OS neutral as possible, it probably does not employ or inherit such associations. Unix has no concept of file associations. When Java performs the invocation it merely tries to execute the provided command line. This should bypass the Windows association processing I expect. This will lead to the error because the script is not something that is understood by Windows to be a .bat script or an executable.