Update "javalin on not-jetty" tutorial
Opened this issue · 6 comments
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
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.
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?
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:
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.
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)
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?
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.