Victory!
I have found the solution!!!

1/ Edit "httpd.conf"
2/ Add the following line:

SetEnv CLASSPATH "C:/Program Files/Java/jdk/lib/tools.jar; etc"

Only one line but so much work behind!

--
Léa Massiot

How Apache interacts with your system, is mostly configurable.
On Linux systems, it runs as a background process, under a certain user, often in a so-called chroot environment (a secured environment).
Since Apache is normally started at boot, it doesn't use the environment of any particular user, but it rather uses it's own environment or
a more general system environment.

On Windows, however, as is the case for you, I don't really know how it runs (I have never actually installed it under Windows).
However, my first guess would be that it runs as a background Service (configurable under "Config Panel" -> Admin tools -> Services).
There you can configure the user it runs as (and thus the user environment that is used). Most likely, it will run under a general system user and
thus uses a general system environment (not your user's environment).
However, if you say that you launch Apache via a shortcut under your desktop, than this probably means that it's not a service (yet) or
that it's a service that is manually started (in the same "Services" configuration window, you can make the services start automatically
at each boot of the computer or manually).

To have an operational website (ie viewable from the entire internet/your network), the webserver must probably listen to port 80, which is a
privileged communication port. To use this port in any way, the program must run under a user with sufficient privileges (ie an "Administrator" account).

So, what I propose to you is that you:
-read the documentation of Apache to know how it's run
-have a look at the shortcut on your desktop (the easyPhP) and the program it launches
-via your Task Manager, you can see if easyPhp/Apache is running under your user or not
-check out the Services configuration window I mentionned above, and see if you can find anything related to Apache or a "web server".

The mechanism (steps 1-6) you describe is pretty accurate. I just have a few comments:
1/ The HTTP page contains a "HTML form". It isn't "reduced" to one.
When you submit the form, probably by clicking on some button, then you send the form's content to the web server
(Apache) in a certain way, using the standard HTTP protocol.
2/ "Action" indeed defines which program is launched to handle the form's contents. "Method", either "post" or "get", defines the HTTP
method that is used. (HTTP Get usually implies that you have the parameters in the URL of the page, HTTP Post works slightly differently.)
3/ The "cgi-script" actually receives the CGI (Common Gateway Interface) parameters, either via the HTTP Get or via the HTTP Post commands and
is supposed to perform some action, depending on the CGI parameter values.
4/, 5/ & 6/ In your case, the cgi-script indeed is supposed to launch a Java program. What the Java program itself does, is rather unimportant
for the web server. The only important thing that your Java program needs to know is that, if it wants to send something back to the
browser of the webpage (as response to the form submission), then it must send the output using the standard HTTP protocol. This protocol
implies that your output must start with a HTTP header (the "content-type" stuff), which ends with the \n\n, followed by whatever you're
trying to send (a HTML page, an image, etc - depending on the content-type you've chosen).
To accomplish this, the web server (Apache) actually captures the "standard output" (stdout) of your cgi-script and forwards that to the
browser. If the output doesn't comply to the HTTP protocol, or if your cgi-script fails, then you get an error message, most likely the
"internal server error" that you've seen already.

So, what the web server does, behind the scene, is:
-Listen to port 80 (or some other port) for any HTTP commands. These HTTP commands can either request some HTML page or other file (via a URL),
or submit some form information, in the CGI format.
-Depending on the HTTP command received, it either responds by giving the requested page (if the client has sufficient permission to view it
and if the requested file can be found) or it calls the cgi-script that is supposed to handle the submitted information.
In the case of a cgi-script, the web server:
-passes the form information to that script, in a specific format, via the standard input.
-then waits for the script to finish. The web server will catch any output from the script and -as said- transmits it back to the browser
(for display), if it's properly formatted (ie if it is sent using the HTTP protocol).
-if the web server detects that the script has terminated unappropriately (ie return code not equal to 0 - the script stops on an error),
then the web server sends the "internal server error" page to the browser.

Hi Timmeke,
Hope you had nice holidays & week-end.

Timmeke & others:

1/ How to start Apache as a service under Windows

o As you regularly speak about running "Apache" as a daemon,
I have found a command line under "MSDOS" to start "EasyPHP"
(including "Apache") at boot time:
(Do not forget the space after the "=" and before the option ("binPath", "start") value )

o As you said henceforth "EasyPHP" appears in:

o As for "users" under Windows, I haven't yet understood (nor worked for understanding )
how to manage them: it is such a mess! One day I guess I'll know .

2/ "Apache varenvs" versus "OS varenvs"

(varenv = environment variable)

Yes, Apache has his own "varenvs" he knows (like "SERVER_NAME", "SERVER_PORT", etc.)
any other "varenv" has to be set in "httpd.conf" (see my previous post).

3/ "Windows", users and "Apache"
There is no option concerning users for the "sc" command.

But there is the "obj=" option which default value is "LocalSystem".

4/ Answers to Timmeke

Yes you are right .
And I click a button to submit the form .

I use the "POST" method.

5/ "Apache varenvs" versus "OS varenvs" (bis)

Actually it is important .
For example:
If the "java" program uses "JDBC" to connect to a "MySQL" database,
it has to know where to find the "MySQL Connector/J" class to perform
that connection. To be able to do so "Apache" needs to know the
OS "varenv" "CLASSPATH" value.

6/ "Apache" stdout

If the "java" program produces no "standard output" (meaning it can output things
in a file but not on the usual "stdout" (Console, browser)), I have no (Apache) "Internal Server Error".
This is the reason why I force "fop" to be "quiet", "mute"
(see one of my previous posts).

Ok...

Thanks for your precious remarks,
good day.

The "sc" command probably does nothing else than registering a background service for your program.
(all background services are configured via the Windows registry, hence the term "registered").
Note also that most Windows functionality can be reproduced via DOS commands. However, most of them are unknown
to users (very little documentation indeed). I recommend http://www.jsifaq.com as starting point for Windows problems.
Microsoft's support may be interesting as well http://support.microsoft.com.

sc create easyphp binPath= "C:\Program Files\EasyPHP1-8\EasyPHP.exe" start= "auto"
"create": will register and create the background service. Afterwards, you'll be able to configure it via the Config Panel.
"binPath=path\to\your_program": this specifies the full path and the name of the executable (program) that you want to run
in the background (ie as a service). In your case, the program is called "EasyPHP.exe".
"start=auto": means that you will want to restart the service automatically at each reboot. This can also be accomplished
via the Config Panel.

It is indeed a real mess, if you're not a certified M$ expert

Be careful here. There is often a difference between configuration variables and environment variables.
When I talk about "environment variables", I'm referring to the varenvs of your system (OS). These can be divided into 2
parts: the system's "varenvs" (defined when Windows is started) and the user's
(loaded when you're loading your personal settings - ie after login).
Check out Config Panel -> System -> Advanced tab -> Environment variables
to see the difference.
Apache of course, can have it's own variables, in addition to those of the underlying OS (the "environment").
Maybe Apache has direct access to the OS's, but more probably, you'll need some command to get them.

To make it all even more confusing, in some cases, you can access certain parameters from the client, like the type of
browser he/she is using, via so-called SSIs (Server Side Includes). These too are available as variables, but they
have yet another origin.

Haven't checked that, but I'm pretty sure you can configure any service to run under a non-standard user (ie your user)
via the Config Panel. However, I don't really recommend that. Sticking with the system user is probably a better choice,
in this case.
However, you can modify the OS's environment vars via the JSI trick I posted earlier.

This may be a reference to your local system account. Not sure though.

Have you checked out:
http://www.apachefreaks.com/apache2/env.html
Especially take a look at the "PassEnv" command.
It is supposed to pass environment values of the shell (in your case, Windows) to your Apache environment so that you
can use them in CGI-scripts and stuff.
There are some useful notes on how to run apache under Windows too (follow the link "Apache Windows notes" in the menu on the left).

o I haven't used "PassEnv", I have used "SetEnv" (Post #31).

o Well well well...
I afraid the
sc create easyphp binPath= "C:\Program Files\EasyPHP1-8\EasyPHP.exe" start= "auto"
doesn't work as expected...
Don't understand why...

=> It still works when I launch EasyPHP manually...
=> but it doesn't work when it is launched automatically...
To me, it is mysterious !!!!

Is it ?
Could it be because "EasyPHP" starts both "Apache" and "MySQL"
and because I haven't told "sc create" that "easyphp" depended on "Apache" and "MySQL". There is the "sc create" option "depend"... maybe it could solve the problem?

I've tried:

It is worse: doesn't work at all.

Well, I'm going to uninstall "EasyPHP" and install separately "Apache" and "MySQL".
Anyway, my client doesn't use "EasyPHP" so it is not a loss of time.
Thanks for reading.

Well, it seems logical to not use a PhP tool (easyPhP) if you're not going to use it.

Next, I would like to point out that the "create" of "sc" may not be enough. That may just register the new background service and configure it so that it is started the next time you reboot your machine. However, to make it work immediately, you'll probably need to start the service (via the Config Panel - or is there a "start" option to "sc"?).

Apache and MySql are 2 typical examples of programs that use daemons in Linux, so they should have corresponding background services under Windows. If you install them, they should be able to install the services for you as well.

As on the site I shown you "SetEnv" and "PassEnv" simply don't do the same thing. The first sets the value of an Apache variable, the other passes the value of an OS environment variable to your script (as if you asked the OS to return the value of that variable).

Hi,

Timmeke:

PassEnv, SetEnv

I do not understand why you suggest me using "PassEnv" rather than "SetEnv" .
I admit that maybe none of these two directives fit in my case but...

I have followed the link (http://www.apachefreaks.com/apache2/...v.html#passenv)
you posted yesterday, it says:

Passenv: "Specifies one or more environment variables
to pass to CGI scripts and SSI pages from the environment
of the shell which invoked the httpd process." (sic)

But "httpd" is not invoked by any shell...

SetEnv: "Sets an environment variable, which is then passed
on to CGI scripts and SSI pages." (sic)

I think that one fits better, no?

sc

Let us forget about "sc".
I have uninstalled "EasyPHP" and installed "Apache" and "MySQL"
separately. Now, both "Apache" and "MySQL" are started automatically.
Yet, I think the "sc" is "ok" as I wrote it previously.

Thanks for helping,

The site indeed refers to a "shell", which is a typical term in the Linux/Unix world. On Windows however, the notion
of a "shell" isn't so clear to most users. However, Windows does have a shell - a graphical one - called "explorer.exe"
(not to be confused by your Windows Explorer that you can use to browse on your hard disk for instance, which has the
same name).

But whether or not they use the term "shell" or not, is relatively unimportant. What counts here is that "PassEnv" can
be used to get parameters from your OS environment (which is the underlying "parent" program that runs httpd) to your CGI
script. So, to make it more practical, it will allow you to retrieve the parameters that you can see in Config Panel ->
System -> Advanced -> Environment variables.
Once you've retrieved them, I suppose you can also assign them to variables in Apache (httpd), which is referred to as
the "Apache environment" on the site.

You'll need SetEnv to set (ie change) the values of parameters (in Apache environment, not OS environment) that you
can then pass along to CGI and SSI pages, who will typically interpret certain parameters to display the page differently.

I think an example can clarify some things:
the PATH variable, a well known OS environment variable, tells Windows where to look for programs that are called (if no path is
given and the program isn't found in the current directory).
This variable is system-wide in the sense that it used for many programs.

Once you call a program, the program will have a copy of all the environment variables of the parent program (= the program that
called it) in it's own memory structure (At least, that is the case for Linux. I don't suppose Windows is much different in this
respect).
So, when you launch a program on your desktop, your environment settings (divided by the Windows people into the "system variables"
- the variables that apply to all users - and the "user variables" - the ones that only apply when you have logged on) are copied
to the memory structure of the program. So, the program will have the knowledge of the values of those parameters and can use
that if it wants (it's just a matter of retrieving the values from it's own memory structure).
Likewise, it can change the values in it's own memory structure (called the program's environment), but cannot alter those
of the parent. When the program stops, the parent continues using it's own values, disregarding any changes that the program
has accomplished in it's own environment (the changes are not copied back to the parent).

A similar explanation goes for httpd.
When your system boots, but before you login, Windows will start the background service "httpd" (if it is set to "Automatic"),
under a user that you choose (as discussed earlier). In most cases, this will not be a "physical" user, like yourself, but rather
a system user. This means that, httpd, when it is launched, gets a copy of the environment variables (the system ones, not the ones
specific to your user, since httpd isn't running under your user).
However, Apache (httpd) from then on has it's own environment and can change/set any variables it likes.
The actual internal mechanism may be quite a bit more complicated than this, but I hope you see that the "OS environment",
or the environment of the "parent" (the program that called httpd - in this case your OS) passes along it's environment to
Apache. "PassEnv" can be used to retrieve any of the values that have been passed in this way.

"SetEnv" on the other hand, changes values in the Apache environment. This may include overwriting values passed in from the OS,
but the OS (parent) will never see those changes. Or Apache can set it's own variables, like SERVER_NAME and stuff.
Some of these variables (Apache environment) will be automatically set by Apache itself when it is started (like SERVER_NAME
for instance), but your programs may add a few too.
If you use SetEnv to set/change the value of a certain variable in the Apache environment, any CGI-scripts called afterwards
will get a copy of this new/changed variable and can thus use it.

So, to summarize:
OS/parent:
has it's own PATH variable
passes all it's environment variables to Apache (httpd) when it calls Apache (in other words, when Apache is started by the
system).
Apache:
-gets a copy of the parent's environment in it's own environment
-sets up some additional, Apache specific, variables like SERVER_NAME and stuff
-allows you to:
* query any variables passed by the OS via PassEnv
* set/change any variables in it's own environment via SetEnv.
So, you can use PassEnv to get the value of PATH (from the parent), alter it, and then use
SetEnv to store it in Apache's environment. Any CGI-scripts/programs called by Apache will get a
copy of Apache's environment, so including all variables copied from the OS as well as any SetEnv-changes you made.

Windows "shell"

o Indeed, if you execute the "explorer.exe" program,
it launches a graphical interface which name is "Windows Explorer" - as we certainly
commonly name it. In this interface and using your mouse and your keyboard,
you can execute programs, edit/remove files, etc.

o As for me, besides "Windows Explorer" I use the "cmd.exe"
program which launches an interface which is - I think I can say it - an equivalent of
a *nix shell. I send you a snapshot of the kind of interface "cmd.exe" launches:
http://www.bournemouth.ac.uk/resnet/...20ipconfig.gif

o Far from wanting to contradict you I think that, for instance, it is not possible
to add an environment variable in the "Windows Explorer" interface... I might be
mistaken....

PassEnv, SetEnv

(varenv = environment variable)

o "PassEnv" doesn't "pass" correctly OS "varenvs" to "httpd".
If you do: "PassEnv CLASSPATH", it doesn't work...
"PassEnv" would probably be adapted in the case in which the
c-cgi-program - which is a c program - is executed directly in
the "cmd.exe" interface (~Windows shell), don't you think?

o All that you explain about processes and child processes is quite
familiar to me. Under Windows it is probably rather similar
although I do not know how it works yet precisely. The problem
is - as I said in the Post #4 - that only the four following OS
varenvs: "ComSpec", "Path", "SystemRoot" and "windir"
are "inherited" by the "httpd" process. I do not know which process is the httpd's
father process nor if it inherits all its father's environment variables. If so,
httpd's father process would only possess the four previous varenvs...
Maybe "httpd" inherits only those four varenvs for security reasons. Don't know...


o Are you suggesting that "httpd" actually inherits all the possible present
OS varenvs but does not allow access to them systematically, that
we must configure it in such a way all the varenvs can be available?

Honestly, I've tried "PassEnv CLASSPATH" (in httpd.conf) and my "CLASSPATH"
value is "null" in my c-cgi-script.

o The point is that:

1/ I do not know who is httpd's father process ;
Pff, under *nix it is easy to know that with the "ps" command.
What do you mean by "my OS"?

2/ This implies that I do not know either which OS varenvs it actually inherits.
Under *nix - as you reminded me - a given process inherits all its father's varenvs.

How?
Doing that?:
I'm sceptical

Problem

You know that I launch the "java Foo" command where "Foo" is a "java"
class with "CreateProcess" in the c-cgi-script?

Problem: If I do not specify entirely the path of the "java" program,
the c-cgi-script fails with error "ERROR_FILE_NOT_FOUND".

I basically have to write
CreateProcess(..., " C:\Program Files\Java\jdk\bin\java Foo", ...) (in the c-cgi-script).

I do not understand why... Moreover as I told you, "httpd" seems to inherit the "PATH" OS varenv.

Notice that in "httpd.conf" I do:
SetEnv CLASSPATH ...

Adding "SetEnv JAVA_HOME" solves nothing.
And "PATH" has a value I can print in the c-cgi-script...




Hey comrade, I'll look for all that, do not worry too much .
Thanks a lot for helping and everything. I'll keep you informed .
Maybe I would be interested if you could answer the things I have put in green...
Thanks. Sorry for writing such large posts...

I'm not talking about the Windows Explorer program that has a panel on the left to go to directories on your disks, to network drives and alike and a panel on the right that shows you the contents of those directories (the files and subdirs), which also allows you to execute programs by double-clicking them.
I was referring to the more basic explorer.exe that governs for instance the toolbar with the Start button. If you would kill all the "explorer.exe"'s you can find in your Task Manager, then you will see that one of them actually gets restarted automatically (when you kill it, your Start menu will be gone briefly).

cmd.exe is and always has been the command to launch a new DOS shell (indeed pretty similar to a *Nix terminal window where you can type in the commands you need). This interface, to which you refer to, is commonly called a "DOS box" or "DOS window".
In general, all DOS programs get executed automatically in such a window. So, unless you've compiled your C program to be a Win32 utility, it will open a DOS box when you launch it.
(cfr in Visual C/C++, you can compile your programs to be Win32 apps or normal apps - ie DOS apps).
If your program just opens such a box to display it's output (ie it's not a Win32 app), it'll
inherit the environment of it's parent.
If you however explicitly call cmd.exe, then you may get a different environment.
For instance, I know that there used to be a different autoexec.bat and config.sys files in the C:\ that contained different settings for DOS boxes than for Windows. (Think of the autoexec.bat and config.sys files as the Win equivalents of your .profile and .bashrc files in *Nix). I think they used to be called autoexec.dos and config.dos, but in recent Windows versions (XP, 2000), a different mechanism may be used (ie registry keys for instance).
If you want to know what goes on, try searching for answers on microsoft's support website or
the jsifaq pages.

Depends on which "explorer" you're talking about. If it's the graphical explorer window to browse your disk, then you're right. If you're talking about the more general explorer.exe that governs your task bar (with the Start menu on it), I think that's the basic Windows shell that is the parent of all the Windows system programs (like *Nix init process (PID 1)), but I could be mistaken.

As I said earlier, if the DOS box is a result of your app being a normal (non-Win32) app, then it should inherit the parent's (= httpd's) environment. If you explicitly call cmd.exe in your code, then you may be stuck with a slightly different environment.
Another issue might be that you -accidentally- set the "CLASSPATH" as one of your OS's user environment variables. This would mean that CLASSPATH only gets set for processes that you run after you login into Windows. httpd, if it is run automatically, may run under a different user (ie the system user I talked about) and hence may not have your CLASSPATH settings.
To demonstrate my point: as you've said, importing the value of %Path% varenv is possible and %Path% is a system wide variable (not a user related one).
To check out if this is the case, have a look at the environment variables in
Config Panel -> System -> Advanced -> Environment variables and look for the 2 different lists (the system varenvs and the user varenvs). If CLASSPATH is in the user varenvs list, then it is likely that httpd won't inherit it from it's parent, simply because the parent doesn't have it either.
Another way to test it is to add a test variable to the system variables via the Config Panel and then try using PassEnv to get it's value.

Indeed, security may be intervening as well. However, I doubt that is the case.
But with Windows you never know for sure
Sorry to remind you of something you already knew. I didn't quite realise how experienced you really are in process management, so I had to make sure...

No. httpd can never account for all the possible varenvs that you can set up, so it won't have for instance a configurable list of variables that you want to import.
PassEnv will allow access to all inherited varenvs, probably.

As I said, many things can cause this. It's just a matter of reviewing your environment configuration (not the httpd config).

Indeed, it's not so easy to find that out.
However, you could try downloading and installing the following freeware program:
http://www.sysinternals.com/Utilitie...sExplorer.html
I've used this in the past and it clearly indicates the parent-child relationship between all the running processes.

By "my OS", I meant the Windows shell (parent process) that launched httpd, probably. I commonly call this "the Operating System (OS)", since it's most likely a part of the internal kitchen of the OS (ie like the "init" process in Linux, which is inherent to the *Nix system).

The exact syntax can be found on the website that showed you the difference between PassEnv and SetEnv (see earlier posts).

If you had used the code
PassEnv PATH
SetEnv PATH foo
then you would have overwritten your %PATH% variable. But I don't suppose you've committed that mistake.
However, think of this:
there may be 2 different %PATH% variables. One system-wide (applying to all users) and one for your user only (again, look at Config Panel -> System -> Adv -> Env vars to make sure).
If your %PATH% has the additional path of your Java installation and the other one does not, then httpd - assuming it is launched automatically at reboot and that it thus runs under a system account, not your account, which is probably the case - won't inherit your %PATH% but just the system's %PATH%. So it won't have a clue as to where to find your Java installation.

JAVA_HOME only is important for the Java programs themselves. For you c-cgi-script to find and execute the "java" program itself (to run your Java app/class), it will need to find it first, using your %PATH%, not %JAVA_HOME%.

You're welcome.
I simply want to help you find the answer you need. So don't worry about me.
And don't worry about the long posts. Mine are long too...
It's just a complicated story, that's all.

Hi Tim,

"Process Explorer" is a real nice tool. Thanks a lot!

---- Observations (with "Process Explorer"):
(varenv = environment variable)

o There is the "Apache.exe" process running.
- Its "father" is "services.exe".
- Visibly, "Apache.exe" has inherited the "CLASSPATH" varenv.

o If I add a "while(1);" instruction in my c-cgi-script ("prog.cgi")
(only to have time to observe it), I can observe that:
- "prog.cgi"'s father is "Apache.exe",
- "prog.cgi" has inherited the "CLASSPATH" varenv.

o Let us say the c-cgi-script contains the following instruction (more or less):
"CreateProcess(..., "java Foo", ...)"
If I remove the "while" instruction from the c-cgi-script and put it in "Foo.java" (then compile it to get "Foo")
I observe that:
- "Foo"'s "father" is "prog.cgi",
- "Foo" has inherited the "CLASSPATH" varenv.

I really do not understand... everything seems to be ok.

---- Yet, to make it work, I must:

1/ In httpd.conf:

Add the following lines:

"CLASSPATH" to know where "java" classes are stored.
"LOCALCLASSPATH" which "fop" needs.

2/ In the c-cgi-script:

I must explicitly tell the c-cgi-script where the "java" program is:
I have to recognize that I'm a bit discouraged .
Regards,

This so true...
Or maybe it is just because we are really bad .

Hey thanks for being so available and kind!

So the "CLASSPATH" is inherited just fine.
This means that you must have defined it in such a way that the "services.exe" knows it.

If Apache knows your CLASSPATH, why would you need SetEnv to alter it's value?
Can't you use PassEnv to get it's value into your script?
It is possible that your c-cgi-script has it's own values and doesn't use the environment values. In this case, you'll need to "pass" the inherited CLASSPATH into the environment of your script - ie use PassEnv.

For the LOCALCLASSPATH, that's application specific. You could add it to your general CLASSPATH (the one that services.exe knows and passes on to it's descendants).
But you don't have to. I would indeed recommend to:
-either use a different variable, like the LOCALCLASSPATH, for your app.
-or get the CLASSPATH and append the strings from LOCALCLASSPATH.

As for 2/, that may be normal. CLASSPATH doesn't have any influence on that. PATH does.
Have you checked the values for PATH that are inherited?
Does it include the path:
C:\Program Files\Java\jdk\bin\ ?

Don't be discouraged, leamassiot. I have a feeling that we're approaching the solution.

Thanks to you to for putting the effort into trying out my suggestions (that may or may not work).