Update "javalin on not-jetty" tutorial

[zugazagoitia]

The tutorial is outdated and it's been discussed on discord to remove it. However it could be updated for javalin/javalin#1795.

Related: javalin/javalin#1793
Posible implementation: javalin/javalin#1825

[gkresic]

Author of javalin/javalin#1793 here.

I've created simplest possible example of my use case for Javalin, you can find it here:

https://github.com/gkresic/javalin-jetty-embed-example

In this configuration, I'm constructing Jetty myself (loading config from XML file) and configuring Javalin servlet using ServletContextListener. It includes mitigation for javalin/javalin#1793 by using "pseudo-root" EndpointGroup.

Value of this approach is that it allows me to fine-tune Jetty in much more details then I would be able to do using Javalin and I can reuse that same Jetty for other purposes, too.

If you agree, I can contribute a tutorial for a website based on that example. I'm planning to continue using Javalin in this mode, so I can maintain that tutorial in case you change how Javalin in standalone mode works.

[zugazagoitia]

Value of this approach is that it allows me to fine-tune Jetty in much more details then I would be able to do using Javalin and I can reuse that same Jetty for other purposes, too.

Could you elaborate on how would this allow you to configure jetty in more detail? You can already provide a custom jetty server and there are many configuration options for it. What's missing for your use case?

[gkresic]

Providing my own Jetty server covers many use cases, but not all. For example, if used this way, Javalin insists on mounting its handler to the root of the context:

https://github.com/javalin/javalin/blob/master/javalin/src/main/java/io/javalin/jetty/JettyServer.kt#L62

preventing me from reusing this server instance for handling non-Javalin requests.

But, configuration aside, the way Javalin handles either own or external Jetty instance looks like a leaky abstraction. Don't get me wrong, Javalin is masterpiece and there is a reason I choose it over other libs, but I would rather see it independent of servlet container, and that is what my example demonstrates.

If related, I offered my help in splitting Javalin from its Jetty integration (javalin/javalin#1795) it it ever comes back into focus.

[zugazagoitia]

There's a key point in this discussion that @tipsy and I already talked in discord and it is: "What is javalin?" Is it a microframework? Is it an abstraction over Jetty? Do we want to simplify? Does it want to be high performance?

It definitely serves many use cases rn, but in my opinion a clear purpose should be defined in order to guide development forward. Right now it is indeed pretty coupled to Jetty, but that might not be a concern for 99.5% of users. (source: i made it up)

[gkresic]

Current users :)

I'm thinking if there may be (many?) others that decided not to use Javalin just because of its strong coupling with Jetty?

[zugazagoitia]

Could be, but we shouldn't persue every use case, that's why I believe there's a need for focusing on something.

Jack of all trades, master of none.