From users-return-267407-archive-asf-public=cust-asf.ponee.io@tomcat.apache.org Fri Apr 19 23:04:36 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id B137E180627 for ; Sat, 20 Apr 2019 01:04:35 +0200 (CEST) Received: (qmail 62040 invoked by uid 500); 19 Apr 2019 23:04:31 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 62030 invoked by uid 99); 19 Apr 2019 23:04:31 -0000 Received: from Unknown (HELO mailrelay2-lw-us.apache.org) (10.10.3.159) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Apr 2019 23:04:31 +0000 Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 5D58935B7 for ; Fri, 19 Apr 2019 23:04:30 +0000 (UTC) Received: by mail-io1-f43.google.com with SMTP id a23so1705322iot.4 for ; Fri, 19 Apr 2019 16:04:30 -0700 (PDT) X-Gm-Message-State: APjAAAU4SLZ5hsucYQCNiXON6Vrh7WGtahwrd0PSo/T9FwnKaxAzdC52 qUDc0mkMrIt15/BpebYcXP4qQi7iDXp/y426BfM= X-Google-Smtp-Source: APXvYqxbM3/SrUka9gUZMTAjps9YLL6VPg7iERAnSWRX2WDfscClNyaOLR2CEmAMeLKXmouc/X9PXESkg6SqcQObvr0= X-Received: by 2002:a6b:3106:: with SMTP id j6mr4878480ioa.147.1555715069870; Fri, 19 Apr 2019 16:04:29 -0700 (PDT) MIME-Version: 1.0 References: <41653da6-0df5-5d62-8b9a-ea537287f2ee@globalmentor.com> In-Reply-To: <41653da6-0df5-5d62-8b9a-ea537287f2ee@globalmentor.com> From: =?UTF-8?Q?R=C3=A9my_Maucherat?= Date: Sat, 20 Apr 2019 01:04:18 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: unable to serve static files with embedded Tomcat To: Tomcat Users List Content-Type: multipart/alternative; boundary="0000000000001c886f0586ea243c" --0000000000001c886f0586ea243c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 19, 2019 at 11:14 PM Garret Wilson wrote: > On 4/19/2019 3:24 PM, R=C3=A9my Maucherat wrote: > > On Fri, Apr 19, 2019 at 7:46 PM Woonsan Ko wrote: > > > >> I found this before from > >> > https://stackoverflow.com/questions/48998387/code-works-with-embedded-apa= che-tomcat-8-but-not-with-9-whats-changed/49011424 > >> > >> // Note: make sure that tomcat creates the default connector.= .. > >> tomcat.getConnector(); > >> > >> Worth trying... > > > Yes, that fixed it, Woonsan! Thank you so much! > > > > That looks correct, and it's easy to spot with the logging (the connect= or > > logs that it's starting if it's there). I removed the magic creation of > the > > connector because it was causing far more hacks (where the magic > connector > > had to be removed after its startup). It seemed more normal to have to > > explicitly create a connector. > > > > R=C3=A9my > > I don't know the history of this, but I have a couple of doubts on the > face of it. > > First, the impression I get from reading _Apache Tomcat 7_ (Apress) is > that I can create a server piecing together the components (Server, > Service, Connector, Engine, Host, Context) if I want, but the whole > point of the `Tomcat` class is to be a helper for doing all this > automatically. So it seems a bit countertuitive that the `Tomcat` class > is now making me do some of this wiring automatically. Why then would I > use the `Tomcat` class? Why don't I just wire it all together from > scratch? And why did we arbitrarily pick `Connector` for this "magic" > creation? Why don't we have to call `Tomcat.getHost()` to make sure the > host gets built, for instance? > > Secondly, calling a getter method in order to invoke some secret magic > creation sauce behind the scenes reeks of a kludge. (Nothing personal; > I'm just commenting on the design.) This is not "normal". It's not at > all obvious that there is this magic step required before the thing will > work. For example, when you see the following code, without some blatant > comment it's easy to think that this is a no-op call that should be > removed: > > tomcat.setPort(8080); > tomcat.getConnector(); //"It doesn't look like this does anything; > maybe it we should remove it=E2=80=A6 " > tomcat.setBaseDir("/foo/bar"); > > If I'm forced to create a connector, I would at least like the option to > do something normal and expected, such as: > > tomcat.getService().addConnector(tomcat.createDefaultConnector()); > > I _could_ create a default connector manually, but I'd have to be > copying more of the source code (along with "magic" identifiers such as > "HTTP/1.1"). So returning to the first doubt above: why am I using the > `Tomcat` class if it doesn't do the default things for me automatically? > Sorry, but the SpringBoot use case is more important [they want to be able to create a Tomcat without a connector], so that's the way it is now. tomcat.getService().addConnector(new Connector()); works very well, etc, just look at what getConnector() does, it's very simple. The Tomcat class is not supposed to help much in this area, but rather on setting up the Tomcat instance right, creating contexts right, etc. You can look at the code and you'll see what the more complex parts are. Adding a connector isn't one of them. You can also use a server.xml (and some other important config files like web.xml) for your embedded now, you can look at Tomcat.main(...) (it is used by the Tomcat container image example). If your configuration becomes complex, it could be better than using Java to configure Tomcat. R=C3=A9my --0000000000001c886f0586ea243c--