Yuri E wrote:
2012/12/7 André Warnier <a...@ice-sa.com>
Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
André,
On 12/7/12 1:55 PM, André Warnier wrote:
I am relatively familiar with tomcat under Windows, and if your
explanations of what works and what doesn't above are exact, then
I don't know either.
One possibility: during the installation, the user chose to bind only
to localhost instead of 0.0.0.0.
Aaaah. Yes, and that choice probably only exists in the Service installer.
That would fit.
And he would see that with netstat.
"netstat -abn" results:
--
running Tomcat on console:
TCP 0.0.0.0:8009 0.0.0.0:0 LISTENING 3844
[java.exe]
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 3844
[java.exe]
TCP 127.0.0.1:8005 0.0.0.0:0 LISTENING 3844
[java.exe]
--
running Tomcat as Service:
TCP 0.0.0.0:8009 0.0.0.0:0 LISTENING 488
[Tomcat7.exe]
TCP 0.0.0.0:8080 0.0.0.0:0 LISTENING 488
[Tomcat7.exe]
TCP 127.0.0.1:8005 0.0.0.0:0 LISTENING 488
[Tomcat7.exe]
Well, Chris, that was a worthy guess, but apparently it is not the reason here.
Didactic section :
In both cases above (running in a console window and running as a Service), we have Tomcat
listening :
- on port 8080, all interfaces, all IP addresses. That's the HTTP Connector
(see in server.xml)
- on port 8009, all interfaces, all IP addresses. That's the AJP Connector
(see in server.xml) (and maybe you don't need that one, and can comment it
out)
- on port 8005, only on the "localhost" address. That is the "shutdown port", which is
limited to listening for calls originating from the same physical host, for security
reasons (so that nobody can shut down your Tomcat from the internet e.g.)
And the reason why in one case the process is "Tomcat7.exe" and in the other case it is
"java.exe" :
- when Tomcat runs as a Service, there is a "service wrapper" involved, which "wraps
around" the java process (and Tomcat in it), and which provides the special functions that
Windows Services must provide for Windows (like listening to Windows "star/stop service"
messages etc..). This wrapper is a copy of the procrun.exe program, renamed to
"tomcat7.exe" for convenience.
So when you run Tomcat as a Service, Windows really starts "tomcat7.exe", and tomcat7.exe
runs java.exe which runs tomcat.
-- end of didactic section --
To summarise what is happening now :
1) Tomcat running in a console window :
a) can be accessed from a browser running on the same machine
b) can be accessed from a browser running on another machine
2) Tomcat running as a Windows Service :
a) can be accessed from a browser running on the same machine
b) but cannot be accessed from a browser running on another machine
while in both cases it is listening to 0.0.0.0:8080
It it was a DNS issue, then both 1-b and 2-b wouldn't work. But only 2-b
doesn't work.
If it was a firewall issue or similar, we'd have the same.
If it was an issue of the java parameters or others used when starting tomcat as a
service, then both 2-a and 2-b would not work. But 2-a works.
Some weird MS security rule, applying to services but not to regular processes ?
Yuri, can you repeat for us which exact URL's you are using to access Tomcat, in each of
the cases above ?
1-a :
1-b :
2-a :
2-b :
and how the problem shows up, when "it does not work" ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
