One of my interviews....
Interviewer: Do you know the welknown hack that increases the speed of embedded tomcat two times than default??
Me: what?? it even exists???
interviewer: yes... it exists... I know it... normally I share the answers with the interviewees... are you interested to hear the hack???
Me: Hell yeah...
Interviewer: ohh no... I will not share with you...
me: whyyy???
interviewer: I don't like your current boss...
Me: Fuck my life(inaudible)... facepalm..

TIL you can crash a Tomcat request processing if the app reads request bodies using a reader() and you feed it a json body with an innocent nbsp :) the whole request processing just goes *pooooft*

reminds me of an ios bug which could brick the phone if it received an sms with weird chars.

These lynch-pin-bugs where a single byte/char in the right place at the right time can tear things down, are so subtle and fascinate me for some reason :)

How fitting because that just happened today: MOTHERF*CKING Tomcat.

TL;DR:
Tomcat sucks with client side routing (e.g. in angular2).

How hard can it be to provide a web/application server which is properly configurable?
I lost a whole day by trying to get an angular2 project deployed in Tomcat.
It's not that I could not manage to deploy it. But that you need to put all the files in the ROOT folder if Tomcat so that your JavaScript files can be found is the first dumb part.
But that's not enough.

There seems to be no way in Tomcat, short of writing to XML config files and including one jar library, to disable routing go a webapp. And you need to do this when you have a single page application with client side routing.

But yeah, dear boss, I get the part where Tomcat is lightweight, easy to use and does most of the work for you: when you do not use it.

As a side note, so that nobody thinks I have a grudge against the Apache guys: I see the advantages of a Tomcat if you have multiple webapplications written in Java which you need to manage our if you use it as an embedded application server.
But there are just some occasions where a plain old Apache Webserver is better suited.

Another side note: if I just embarrassed myself because those are settings which can be easily applied feel free to tell me 😉

My work product: Or why I learned to get twitchy around Java...

I maintain a Java based test system, that tests a raster image processor. The client is a Java swing project that contains CORBA bindings to the internal API of the raster image processor. It also has custom written UI elements and duplicated functionality that became available in later versions of Java, but because some of the third party tools we use don't work with later versions of Java for some reason, it's not possible to upgrade Java to gain things as simple as recursive directory deletion, yes the version of Java we have to use does not support something as simple as that and custom code had to be written to support it.

Because of the requirement to build the API bindings along with the client the whole application must be built with the raster image processor build chain, which is a heavily customised jam build system. So an ant task calls out to execute a jam task and jam does about 90% of the heavy lifting.

In addition to the Java code there's code for interpreting PostScript files, as these can be used to alter the behaviour of the raster image processor during testing.

As if that weren't enough, there's a beanshell interface to allow users to script the test system, but none of the users know Java well enough to feel confident writing interpreted Java scripts (and that's too close to JavaScript for my comfort). I once tried swapping this out for the Rhino JavaScript interpreter and got all the verbal support in the world but no developer time to design an API that'd work for all the departments.

The server isn't much better though. It's a tomcat based application that was written by someone who had never built a tomcat application before, or any web application for that matter and uses raw SQL strings instead of an orm, it doesn't use MVC in any way, and insane amount of functionality is dumped into the jsp files.

It too interacts with a raster image processor to create difference masks of the output, running PostScript as needed. It spawns off multiple threads and can spend days processing hundreds of gigabytes of image output (depending on the size of the tests).

We're stuck on Tomcat seven because we can't upgrade beyond Java 6, which brings a whole manner of security issues, but that eager little Java updated will break the tool chain if it gets its way.

Between these two components we have the Java RMI server (sometimes) working to help generate image data on the client side before all images are pulled across a UNC network path onto the server that processes test jobs (in PDF format), by reading into the xref table of said PDF, finding the embedded image data (for our server consumed test files are just flate encoded TIFF files wrapped around just enough PDF to make them valid) and uses a tool to create a difference mask of two images.

This tool is very error prone, it can't difference images of different sizes, colour spaces, orientations or pixel depths, but it's the best we have.

The tool is installed in both the client and server if the client can generate images it'll query from the server which ones it needs to and if it can't the server will use the tool itself.

Our shells have custom profiles for linking to a whole manner of third party tools and libraries, including a link to visual studio 2005 (more indirectly related build dependencies), the whole profile has to ensure that absolutely no operating system pollution gets into the shell, most of our apps are installed in our home directories and we have to ensure our paths are correct for every single application we add.

And... Fucking and!

Most of the tools are stored as source bundles in a version control system... Not got or mercurial, not perforce or svn, not even CVS... They use a custom built version control system that is built on top of RCS, it keeps a central database of locked files (using soft and hard locks along with write protecting the files in the file system) to ensure users can't get merge conflicts by preventing other users from writing to the files at all.

Branching is heavy weight and can take the best part of a day to create a new branch and populate the history.

Gathering the tools alone to build the Dev environment to build my project takes the best part of a week.

What should be a joy come hardware refresh year becomes a curse ("Well fuck, now I loose a week spending it setting up the Dev environment on ANOTHER machine").

Needless to say, I enjoy NOT working with Java. A lot of this isn't Javas fault, but there's a lot of things that Java (specifically the Java 6 version we're stuck on) does not make easy.

This is why I prefer to build my web apps in python or node, hell, I'd even take Lua... Just... Compiling web pages into executable Java classes, why? I mean I understand the implementation of how this happens, but why did my predecessor have to choose this? Why?

Saw this huge signage using windows embedded and apache tomcat.

Sorry for my noob question. Too scared to post in stackoverflow.
I have a domain for my website from namecheap.my website is made with springboot and hosted on my homeserver port 80
I pointed my domain to publicip:80.never works fine except when i put my domain name in the address bar it redirected to my ip and shows the ip in the address bar.
Am I missing any steps?do i need to do something in my embedded tomcat server?

For some reason properly starting an embedded tomcat and deploying a war is the fucking bane of my existence. Came back to work today from being off for the weekend and all of the sudden my webapp wont deploy. Tomcat just spinsup the app manager and intellij doesnt deploy the war...

Now that im typing this I bet that the context.xml is missing the docbase attr... gunna vpn in and check... literally ran the app fine friday night so not sure why this would have changed now. Will report back.