tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rémy Maucherat <>
Subject Re: unable to serve static files with embedded Tomcat
Date Fri, 19 Apr 2019 23:04:18 GMT
On Fri, Apr 19, 2019 at 11:14 PM Garret Wilson <>

> On 4/19/2019 3:24 PM, Rémy Maucherat wrote:
> > On Fri, Apr 19, 2019 at 7:46 PM Woonsan Ko <> wrote:
> >
> >> I found this before from
> >>
> >>
> >>          // 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 connector
> > 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émy
> 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… "
>      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.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message