-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Konstantin,

On 4/19/19 19:05, Konstantin Kolinko wrote:
> пт, 19 апр. 2019 г. в 19:29, Garret Wilson
> <gar...@globalmentor.com>:>
>> I'm wanting to embed Tomcat to only serve static files (for the
>> moment). That is, no JSP, etc. I also want to have the welcome
>> files completely customizable.
>> 
>> So instead of calling `tomcat.addWebapp()`, I go the completely 
>> programmable route and call `tomcat.addContext()`, 
>> `context.createWrapper()`, etc. This makes my bypass the 
>> `DefaultWebXmlListener`, which would have called 
>> `initWebappDefaults(Context ctx)` to set up the welcome files and
>> such myself.
>> 
>> But `initWebappDefaults()` also sets up the default MIME
>> mappings. And `Tomcat.DEFAULT_MIME_MAPPINGS` is private.
> 
> Also note that the value is not synch'ed with the default list in 
> conf/web.xml. E.g  the following entries from the top of the
> default list are missing
> 
> <mime-mapping> <extension>123</extension> 
> <mime-type>application/vnd.lotus-1-2-3</mime-type> </mime-mapping> 
> <mime-mapping> <extension>7z</extension> 
> <mime-type>application/x-7z-compressed</mime-type> </mime-mapping>
> 
> (and many others)
> 
> Some years ago the list in web.xml was synch'ed to the similar file
> in Apache HTTPD, but the list used by embedded Tomcat was not
> updated.
> 
> Previous discussion: http://markmail.org/message/gjkixk7wysopyztp
> 
>> So the situation seems to be that Tomcat forces me to choose
>> between creating a full-fledged JSP server, or setting up all the
>> MIME types with some list of my own. Maybe it would be good for
>> me to have my own list eventually, but for now this seems like an
>> artificial choice forced upon me.
>> 
>> Part of the problem seems to be that the (ancient?) code has the
>> MIME mappings as a string array!! Heaven knows we don't want to
>> expose that. It should really be turned into a read-only map and
>> then exposed so we can use it.
> 
> An array is a bad API, but generally it is faster to create an
> array. All the time used to create a map goes to waste if it is
> only accessed sequentially, like it is done here.
> 
> The only place where the values are used is
> 
> for (int i = 0; i < DEFAULT_MIME_MAPPINGS.length;) { 
> ctx.addMimeMapping(DEFAULT_MIME_MAPPINGS[i++], 
> DEFAULT_MIME_MAPPINGS[i++]); }
> 
> There are some people who ask for options to make Tomcat to start
> up faster (e.g. in a "serverless" environment when you start a
> process on demand and pay for execution time). Not being careful
> here may negatively affect the startup time. The current 
> 'DEFAULT_MIME_MAPPINGS' field is a static one and is always
> created when the class is loaded, regardless of whether it will be
> used or not.
> 
> 
>> Then of course I see the comment:
>> 
>>> TODO: would a properties resource be better ? Or just parsing
>> /etc/mime.types ?
>> 
>> To answer part of that question, we can't just parse
>> `/etc/mime.types` because the embedded server might not even have
>> an `/etc/mime.types` file. This should definitely be put into a
>> properties resource, I would think.
> 
> For reference, 
> https://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.type
s
>
> 
>> So I've probably answered my own question; this is an old TODO
>> that needs to be done, I suppose?

Maybe it makes sense to do the following:

1. Create a separate, simple file. No XML, etc.

2. Create a new method for loading the default mime types. It can be
called if/when necessary but is not always called.

3. Hook something into the build process for re-generating the
mime-mappings for the default conf/web.xml file so everything is
always in sync.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAly9xOgACgkQHPApP6U8
pFhIkQ//Qhps4Jglmk79vWMRaVnZtiWyh5aW7ST4Zy7lid2ZcOzJne1Aw/U24hCX
c9yzvsHVweqql5INZAx+ADDY+IiQU8xZlxbQ9F/2jocQP76NuldWw09DvEiCj44P
no570sr0vxM8PK7ZDNYOc03DfSFPVpXFNBeydPX1bcumtayGnykZoLmcKY6yXyAu
tl8fjDvkBb/zDrJE/amzb2sbUkP3RKrzMP58zeqPehVSH1lsLAOqALxE5BaQPREo
WISWb3XfMp5H7DwQLAfa/6NiDT6Zpqaafwe3MHwiUuVfE7MIfg5L3h2rPH2vPdVe
vTmStRhq9VPwX+I9zCVKMbwigTgxYXxHdpseoLeLz/RhZvny/gumiWNTvH4/u4yT
PY6Q+OxfznFSeixDmD9GF14ZFQb4eJtLFpR8bi53bZ5lb2utGThdzyL5iZ8WICKb
4AQtLY1uh3EkMdz79g5HZKWEcVK5Q0RAU1Wp0bBmtl59jWN2SuHxe/1pm5+PrHxT
TI/rJI3Zr/dGaAbwD3DbY2E5bbPGH0vD0E3k9h8cR5YY1TTnne6wTswNMOFaSMIQ
ewlgxSDBrnHeg2RY/fr+rVe9yA9h2BFS5JPwQxtX8dk4w4FptPanCEUrNb+Xdc4U
zz2bUsxELDctO9ElgmP+6xKMZTFGF5x9ZWAYPa9dAT3h+bxdvx4=
=AsuI
-----END PGP SIGNATURE-----

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

Reply via email to