Re: Tomcat 9 won't start according to Eclipse

[Roparzh Hemon]

On Wed, Aug 2, 2017 at 2:30 PM, Konstantin Kolinko
 wrote:
> 2017-07-28 20:51 GMT+03:00 Roparzh Hemon :
>> On Fri, Jul 28, 2017 at 6:18 PM, Konstantin Kolinko
>>  wrote:
>>>
>>> Double click on the server (in "Servers" view) -> set "[x] Publish
>>> module context to separate XML files".
>>  When I right-click on "Servers" in Project Explorer, I do not see
>> any "Publish module"
>> item. I also found a "Server" item in Preferences, which has a
>> "Audio/Launching/Overlays/Profilers/Runtime environments" submenu.
>
>
> http://help.eclipse.org/neon/topic/org.eclipse.platform.doc.user/concepts/concepts-5.htm
> Help > Workbench User Guide > Concepts > Views
>
> To open the "Servers" view go to menu "Window" > "Show View" > "Other..."
>
> A dialog named "Show View" opens.
> Type "ser" in the filter box at the top of the dialog.
> Choose "Server" > "Servers", click OK.

  This simply sends me back to the Server component in Project
Explorer (which I could attain by simply clicking on it instead of
doing the more complicated sequence of operations you describe). I
repeat, I do not see any "Publish module" item anywhere. All I see is,
for each server, a list consisting of the following files :
catalina.policy, catalina.properties, context.xml, server.out.xml,
server.xml, tomcat-users.xml, web.xml.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: This is weird: can't bind to 443

[Caldarale, Charles R]

> From: Igal @ Lucee.org [mailto:i...@lucee.org] 
> Subject: Re: This is weird: can't bind to 443

> I agree about the "one more thing to go wrong", but fronting Tomcat with 
> a Web Server gives a performance hit?  I mean, sure, now requests for 
> Tomcat have another step to go through, but all of the static resources 
> (assuming there are static resources) will supposedly be handled more 
> efficiently by a web server, no?

Um, no.  A lot of work has gone into improving Tomcat performance over the
past few years, to the point where it's largely on par with httpd.  Put both
in the mix (assuming you're not using httpd for other reasons), and what
you've mostly done is add latency.

> The added layer usually provides more security as well, provided that the 
> web server doesn't add new vulnerabilities, of course.

Pretty much all components have (undiscovered) vulnerabilities, so having
more components actually increases the attack surface.

> I personally use nginx for SSL termination, which I find easier than 
> Tomcat, though it's been many years since I last tried to setup Tomcat 
> with https.

Now that Tomcat can use OpenSSL directly, it's easier than it used to be.
That said, if you do have a front end to Tomcat, might as well do the SSL
termination there to simplify things.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.



smime.p7s
Description: S/MIME cryptographic signature

Re: This is weird: can't bind to 443

[Igal @ Lucee.org]

Chris,

On 8/2/2017 3:10 PM, Christopher Schultz wrote:

On 8/2/17 3:13 PM, Igal @ Lucee.org wrote:

On 8/2/2017 11:48 AM, Caldarale, Charles R wrote:
I recommend fronting Tomcat with a web server like nginx or httpd,

This is an okay solution but it requires another component to be
installed/configured. Looks like James already has httpd installed, so
it's just a bit more configuration. It's one more thing to get wrong,
though, and it gives you a small performance hit.
I missed the part about having httpd already installed, you're right, 
but that whould only make it easier to set it up as a reverse proxy.


I agree about the "one more thing to go wrong", but fronting Tomcat with 
a Web Server gives a performance hit?  I mean, sure, now requests for 
Tomcat have another step to go through, but all of the static resources 
(assuming there are static resources) will supposedly be handled more 
efficiently by a web server, no?  The added layer usually provides more 
security as well, provided that the web server doesn't add new 
vulnerabilities, of course.


I personally use nginx for SSL termination, which I find easier than 
Tomcat, though it's been many years since I last tried to setup Tomcat 
with https.



but see also two solutions from
http://georgik.rocks/tomcat-7-listen-on-port-80-linux-debian/

1) have Tomcat listen on a higher port and redirect traffic from
port 80 to the higher port in iptables

This is an okay solution but it's ugly(ish) and highly undiscoverable.
I can't remember the last time I did a netstat and immediately thought
"hey, I wonder if any of those bound ports are being redirected by
iptables?"
Agreed, but I saw it in a couple of places when I googled "linux run 
tomcat on port 80" after James asked for elaboration.  I'm much more 
familiar with Windows than Linux (though am making the migration and 
actually setting up my first CentOS  production server), hence my 
original reply on this thread was short and with no details.



2) set `AUTHBIND=yes` om /etc/defaults/tomcat7

That needs to be /etc/default/tomcat[version]
I actually thought of editing that before posting, but since the OP 
mentioned tomcat 7 I decided not to do so.



I did a little digging into how this works because I was curious.
Obviously, it uses authbind. But that script automatically adds the
following file to /etc/authbind/byuid/[tomcat-uid]:

0.0.0.0/0:1,1023
::/0,1-1023

This allows the tomcat user to bind to ports between 1 and 1023 on
IPv4 and IPv6 addresses.

I would personally lock this down even further and enumerate the ports
you expect to use, but it's possible that the service runner (systemd
in this case) may clobber the permissions at some future point.
I was also wondering how it works, but was too busy to look it up. 
Thanks for sharing your findings.



Igal

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: This is weird: can't bind to 443

[James H. H. Lampert]

With a little futzing around, setting up 443 as an authbind-able port, 
and (as Christopher noted) correcting the spelling in the pathname, the 
AUTHBIND option worked perfectly.


Thanks for pointing me in the right direction. Now that I think about 
it, I don't think any of the Linux installations I'd previously done of 
Tomcat were on Port 443.


--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: This is weird: can't bind to 443

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Igal,

On 8/2/17 3:13 PM, Igal @ Lucee.org wrote:
> On 8/2/2017 11:48 AM, Caldarale, Charles R wrote:
>>> From: James H. H. Lampert [mailto:jam...@touchtonecorp.com] 
>>> Subject: Re: This is weird: can't bind to 443
 Binding on ports < 1024 on Linux require elevated
 permissions, no?
>>> If so, somebody please elaborate.
>> That's a Linux restriction/feature - must be superuser to use the
>> low port numbers.
> 
> I recommend fronting Tomcat with a web server like nginx or httpd,

This is an okay solution but it requires another component to be
installed/configured. Looks like James already has httpd installed, so
it's just a bit more configuration. It's one more thing to get wrong,
though, and it gives you a small performance hit.

> but see also two solutions from 
> http://georgik.rocks/tomcat-7-listen-on-port-80-linux-debian/
> 
> 1) have Tomcat listen on a higher port and redirect traffic from
> port 80 to the higher port in iptables

This is an okay solution but it's ugly(ish) and highly undiscoverable.
I can't remember the last time I did a netstat and immediately thought
"hey, I wonder if any of those bound ports are being redirected by
iptables?"

> 2) set `AUTHBIND=yes` om /etc/defaults/tomcat7

That needs to be /etc/default/tomcat[version]

I did a little digging into how this works because I was curious.
Obviously, it uses authbind. But that script automatically adds the
following file to /etc/authbind/byuid/[tomcat-uid]:

0.0.0.0/0:1,1023
::/0,1-1023

This allows the tomcat user to bind to ports between 1 and 1023 on
IPv4 and IPv6 addresses.

I would personally lock this down even further and enumerate the ports
you expect to use, but it's possible that the service runner (systemd
in this case) may clobber the permissions at some future point.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZgk3JAAoJEBzwKT+lPKRYCAkQALfann5v+fOaXbHq6qCb2PXK
nXvvN8hte8f95Yd10G8J839VaI/3qoOH+vA3Y9aYUQJN8K4S0LNMwGove3zhnEvC
PAhEma+NB+Amh+MoWpzWrQ8DfdzGyiWa4HbV5PH+EkCp/GBXLjkP3eFYuw3KaSW8
BNG5ZjcoWmLZ2GbF/DtpzsZ+Lkw8cC1gj3t8cYIhCh3aMI7Tlz83MGiTt+7us2Wk
qttomqmfNloD5oMIBGu0ibNVYIbNArYW0NWxT1ro7lZqKcsLpC8Vk3iw31tvKwMw
idcJS5b1FGkR2uXwVBAQMJcpiko7YOIclL6gfv8mdHaZeP5iQwmf+mGveeDnhwu4
beUz/MGEUV/+A72wO3PTz98E53lzUskYCH10qUpUIjgEDTOI16njRQYdpx5tYT62
3igYDRMDO3djZGT9+NFthuD/9VbEVSjRMBLXnCpeRbtH/iKOaFP9gpgJYzuvw+dp
te/RJe1istOrz+vxRb5HTNCjTT2qzDd4QL3Wi/zaG/Jpqx+OCOvLH1AsXG8t9ulx
S02HXT/b13ltMbTbv3yDCVGgsOuPMonj5ViEx3fBei1idTscZcgZopEPibdM7is1
M/lHw395xfzkRfuA6nL54wPI5SFT/xlPLjmFmgoL6++jG7KetxlHrKIlBH3pmKwz
nUJv8g5LlqQjzzDdEiKO
=lU+b
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: This is weird: can't bind to 443

[Igal @ Lucee.org]

On 8/2/2017 11:48 AM, Caldarale, Charles R wrote:

From: James H. H. Lampert [mailto:jam...@touchtonecorp.com]
Subject: Re: This is weird: can't bind to 443

Binding on ports < 1024 on Linux require elevated permissions, no?

If so, somebody please elaborate.

That's a Linux restriction/feature - must be superuser to use the low port
numbers.


I recommend fronting Tomcat with a web server like nginx or httpd, but 
see also two solutions from 
http://georgik.rocks/tomcat-7-listen-on-port-80-linux-debian/


1) have Tomcat listen on a higher port and redirect traffic from port 80 
to the higher port in iptables

2) set `AUTHBIND=yes` om /etc/defaults/tomcat7


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: This is weird: can't bind to 443

[Caldarale, Charles R]

> From: James H. H. Lampert [mailto:jam...@touchtonecorp.com] 
> Subject: Re: This is weird: can't bind to 443

> > Binding on ports < 1024 on Linux require elevated permissions, no?

> If so, somebody please elaborate.

That's a Linux restriction/feature - must be superuser to use the low port
numbers.

> It currently seems to be running under a user called "tomcat7."

That's good.

> By contrast, the one we've got running on a local CentOS box runs under
root.

That's bad.

> The installation on the Google Debian instance was via an apt-get, and it
put 
> things in places other than where I was expecting them to be

That's a problem with all the 3rd-party repackaged versions of Tomcat.  Best
to use a real one from tomcat.apache.org.

> Any suggestions on what to do about it?

You should never run Tomcat under root - that means the webapps have full
control of the system.  Any webapp bugs open it up to hackers.  Take a look
at the FAQ for how to avoid that problem:

https://wiki.apache.org/tomcat/HowTo#How_to_run_Tomcat_without_root_privileg
es.3F

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.


-Original Message-


--
JHHL

--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



smime.p7s
Description: S/MIME cryptographic signature

Re: This is weird: can't bind to 443

[James H. H. Lampert]

On 8/2/17, 11:26 AM, Igal @ Lucee.org wrote:

On 8/2/2017 11:13 AM, James H. H. Lampert wrote:

I've just got finished moving a Tomcat instance's HTTPS connector from
8443 to 443, on a Google Compute Engine Debian instance (from
Bitnami's canned Trac image). Something I've done literally dozens of
times on AS/400s, along with the occasional WinDoze and Linux box.
Always without incident. Until now. I move it, do a "service tomcat7
restart," and the port doesn't open.

I already moved the Apache 2 server's HTTPS port to a different port
number, where it's working perfectly. There is nothing else listening
on 443, and Apache 2 and Tomcat are operating independently of each
other.


Binding on ports < 1024 on Linux require elevated permissions, no?


If so, somebody please elaborate.

It currently seems to be running under a user called "tomcat7." By 
contrast, the one we've got running on a local CentOS box runs under 
root. (The installation on the Google Debian instance was via an 
apt-get, and it put things in places other than where I was expecting 
them to be, so why should I be surprised that it runs under a different 
user than I was expecting?)


Any suggestions on what to do about it?

--
JHHL

--
JHHL

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: This is weird: can't bind to 443

[Igal @ Lucee.org]

On 8/2/2017 11:13 AM, James H. H. Lampert wrote:
I've just got finished moving a Tomcat instance's HTTPS connector from 
8443 to 443, on a Google Compute Engine Debian instance (from 
Bitnami's canned Trac image). Something I've done literally dozens of 
times on AS/400s, along with the occasional WinDoze and Linux box. 
Always without incident. Until now. I move it, do a "service tomcat7 
restart," and the port doesn't open.


I already moved the Apache 2 server's HTTPS port to a different port 
number, where it's working perfectly. There is nothing else listening 
on 443, and Apache 2 and Tomcat are operating independently of each 
other.


Binding on ports < 1024 on Linux require elevated permissions, no?

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

This is weird: can't bind to 443

[James H. H. Lampert]

I've just got finished moving a Tomcat instance's HTTPS connector from 
8443 to 443, on a Google Compute Engine Debian instance (from Bitnami's 
canned Trac image). Something I've done literally dozens of times on 
AS/400s, along with the occasional WinDoze and Linux box. Always without 
incident. Until now. I move it, do a "service tomcat7 restart," and the 
port doesn't open.


I already moved the Apache 2 server's HTTPS port to a different port 
number, where it's working perfectly. There is nothing else listening on 
443, and Apache 2 and Tomcat are operating independently of each other.


In catalina.out, I'm getting:

Aug 02, 2017 5:57:40 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-443"]
Aug 02, 2017 5:57:40 PM org.apache.coyote.AbstractProtocol init
SEVERE: Failed to initialize end point associated with ProtocolHandler 
["http-bio-443"]
java.net.BindException: Permission denied (Bind failed) :443
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:411)
at 
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:646)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:434)
at 
org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:119)
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:978)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:559)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:821)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.startup.Catalina.load(Catalina.java:638)
at org.apache.catalina.startup.Catalina.load(Catalina.java:663)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:280)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:454)
Caused by: java.net.BindException: Permission denied (Bind failed)
at java.net.PlainSocketImpl.socketBind(Native Method)
at 
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:376)
at java.net.ServerSocket.bind(ServerSocket.java:376)
at java.net.ServerSocket.(ServerSocket.java:237)
at java.net.ServerSocket.(ServerSocket.java:181)
at javax.net.ssl.SSLServerSocket.(SSLServerSocket.java:136)
at 
sun.security.ssl.SSLServerSocketImpl.(SSLServerSocketImpl.java:107)
at 
sun.security.ssl.SSLServerSocketFactoryImpl.createServerSocket(SSLServerSocketFactoryImpl.java:84)
at 
org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:188)
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:398)
... 17 more


followed by

Aug 02, 2017 5:57:40 PM org.apache.catalina.core.StandardService initInternal
SEVERE: Failed to initialize connector [Connector[HTTP/1.1-443]]
org.apache.catalina.LifecycleException: Failed to initialize component 
[Connector[HTTP/1.1-443]]
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:106)
at 
org.apache.catalina.core.StandardService.initInternal(StandardService.java:559)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at 
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:821)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
at org.apache.catalina.startup.Catalina.load(Catalina.java:638)
at org.apache.catalina.startup.Catalina.load(Catalina.java:663)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:280)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:454)
Caused by: org.apache.catalina.LifecycleException: Protocol handler 
initialization failed
at 
org.apache.catalina.connector.Connector.initInternal(Connector.java:980)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
... 12 more
Caused by: java.net.BindException: Permission denied (Bind failed) :443
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:411)
at 

Re: [OT] question regarding Apache mailservers

[Mark Thomas]

On 02/08/17 16:07, André Warnier (tomcat) wrote:
> Hi.
> Sorry to post this here, but I don't seem to find the right contact
> address through the website nor received emails, so if someone could
> point me to the right thing..
> 
> I am being bombarded by some scammers, through my Tomcat committer email
> address, no doubt scraped from some page here.
> Does anyone know the right place to send a question about that ?

us...@infra.apache.org

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

[OT] question regarding Apache mailservers

[tomcat]

Hi.
Sorry to post this here, but I don't seem to find the right contact address through the 
website nor received emails, so if someone could point me to the right thing..


I am being bombarded by some scammers, through my Tomcat committer email address, no doubt 
scraped from some page here.

Does anyone know the right place to send a question about that ?

Thanks


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8 slow shutdown on Windows 10

[Mark Thomas]

On 02/08/17 14:57, Christopher Schultz wrote:
> Mark,
> 
> On 8/1/17 4:17 PM, Mark Thomas wrote:
 Yes. To unlock the *acceptor thread(s)*.
>>>
>>> (Emphasis mine)
>>>
>>> I understand, now. Thanks.
> 
>> The acceptor is also unlocked when a Connector is paused (i.e. when
>> the server socket is NOT closed but it stops accepting new
>> connections).
> 
>>> Will a Thread.interrupt() not work?
> 
>> For APR probably not. It might work for NIO but reading the Javadoc
>> for accept() suggests an interrupt would close the connection (not
>> what we want)
> 
>>> What about calling socket.close() from the shutdown thread? That 
>>> should cause a SocketException to be thrown by accept()[1].
>>>
>>> If it's an NIO SocketChannel, then we can close the channel
>>> itself and cause an I/O interrupt.[2]
> 
>> We need to be able to do this without closing the socket. It is
>> that requirement that makes this 'interesting'.
> 
> Is this because of the use-case above when we are merely "pausing" the
> connector? Or is this because, even when shutting-down, we don't want
> to close the socket and terminate any in-flight requests?

Bit of both. We want to stop any new requests while allowing in-flight
requests to continue (for whatever the allowed perios is - 10s I think).

> When playing-around with JMX and the connectors, I found sending a
> "stop" request to the connector immediately kills all in-flight
> connections. Is there an operation that is not available through JMX
> that is being called here? Like "shutdown"?

I'd expect the in-flight requests to complete and then close but idle
keep-alive connections to close pretty much immediately.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8 slow shutdown on Windows 10

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/1/17 4:17 PM, Mark Thomas wrote:
>>> Yes. To unlock the *acceptor thread(s)*.
>> 
>> (Emphasis mine)
>> 
>> I understand, now. Thanks.
> 
> The acceptor is also unlocked when a Connector is paused (i.e. when
> the server socket is NOT closed but it stops accepting new
> connections).
> 
>> Will a Thread.interrupt() not work?
> 
> For APR probably not. It might work for NIO but reading the Javadoc
> for accept() suggests an interrupt would close the connection (not
> what we want)
> 
>> What about calling socket.close() from the shutdown thread? That 
>> should cause a SocketException to be thrown by accept()[1].
>> 
>> If it's an NIO SocketChannel, then we can close the channel
>> itself and cause an I/O interrupt.[2]
> 
> We need to be able to do this without closing the socket. It is
> that requirement that makes this 'interesting'.

Is this because of the use-case above when we are merely "pausing" the
connector? Or is this because, even when shutting-down, we don't want
to close the socket and terminate any in-flight requests?

When playing-around with JMX and the connectors, I found sending a
"stop" request to the connector immediately kills all in-flight
connections. Is there an operation that is not available through JMX
that is being called here? Like "shutdown"?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJZgdo3AAoJEBzwKT+lPKRYBbkP/2JpQj5ajEAH0m7efIaz5wRb
MDM5q5nMqNDeVu4gykhrd4V8qR7MucAubKfvqbo2W1wB7dTCaWFQ8GQD/5wG2QT/
5x5MkjrITq1Uw0DHKUGmXtRAb9oE/44jdBj+MjIkq0oRRF9/Vrk1fMczVKs05vXT
xoY2yVwgRGAv1pD2QkIDgUYt1l/PegLO4UFZzY9F2vF8P1gaEOmpjFgOwAf1T75u
ZMBpk8KSOiWcV493eqad4GV2pSISTIFNuqeV3XzVlowRooUj3DxvzzOJnOlaKPG9
r/Q9TC8tRi/h2j2sGlrJazvlZHpfmGy/l4PZpsTfaHgJHn/Go9f909cqjWLL8796
LouEM7eQYYx6wv+DnDSshgincptFUxll8iw+c6QKJ5d0r6IOwdczXI1vRtDn4VOr
swatboD3s2XSVCSzdfRA5ZO84/qxFURJQKOD88UYIbh7XmVCZ+V8bQwOvueRCvkj
JCoX2piMdW8LZhUH675CjJWnJcqMk6lck76J3FFfziDtD3t7pin5hSGT2XrJGR4E
QcN7O8IGPk9T4Q/adhWP88aIOyE8+/HuF4jCYXRHB2lP3xDBQLezUslziy59u8gi
XwSjMw0Cz/G9KMPht0jAvQQoWWllZbqoOW4B7CjF69sN8czfdP9hHBgbIHT4pkIc
+tx4Xk7rkUC6P/cVZgZm
=+ZCw
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9 won't start according to Eclipse

[Konstantin Kolinko]

2017-07-28 20:51 GMT+03:00 Roparzh Hemon :
> On Fri, Jul 28, 2017 at 6:18 PM, Konstantin Kolinko
>  wrote:
>>
>> Eclipse by default places  element for web application into
>> Tomcat's server.xml file.
>> This is a discouraged practice. A result of such configuration is that
>> when the application fails to start (due to its own misconfiguration)
>> this failure is fatal for Tomcat as well.
>
>   Which makes people mistake non-Tomcat issues for Tomcat issues, as
> happened to me here.
>
> On Fri, Jul 28, 2017 at 6:18 PM, Konstantin Kolinko
>  wrote:
>>
>> Double click on the server (in "Servers" view) -> set "[x] Publish
>> module context to separate XML files".
>>
>
>  When I right-click on "Servers" in Project Explorer, I do not see
> any "Publish module"
> item. I also found a "Server" item in Preferences, which has a
> "Audio/Launching/Overlays/Profilers/Runtime environments" submenu.


http://help.eclipse.org/neon/topic/org.eclipse.platform.doc.user/concepts/concepts-5.htm
Help > Workbench User Guide > Concepts > Views

To open the "Servers" view go to menu "Window" > "Show View" > "Other..."

A dialog named "Show View" opens.
Type "ser" in the filter box at the top of the dialog.
Choose "Server" > "Servers", click OK.


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org