On Wed, Dec 23, 2020 at 9:13 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> I am for it, dependency free is key as soon as you modify tomcat/lib - and > since it is a transversal extension it will often be there. > Aha, you are for writing Tomcat specific ACME library without dependencies. First, I have never used Tomcat without Tomcat Native in production. I don't know if Tomcat without Native is currently feasible in production for SSL connector (what is the performance overhead?) I will try tomorrow to see on removing jose4j and bouncycastle dependencies from acme4j. > Regarding writing Valve, this would probably mean in any case most likely > > providing a different ServletContext, right? > > The valve does not need another context which enables to match the > letsencript challenge whatever is deployed as app. > I don't understand this from the code. Pipeline has its order so it's important that this Valve is put in the right position? On Host level, Netbeans didn't show me how setConfigClass is used. I think I should take a rest and tomorrow install IntelliJ and Eclipse as it seems Netbeans not working for Tomcat source for me properly. > > > On Wed, Dec 23, 2020 at 7:02 PM Christopher Schultz < > > ch...@christopherschultz.net> wrote: > > > > > Mladen, > > > > > > On 12/23/20 11:24, Mladen Adamović wrote: > > > > On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau < > > > rmannibu...@gmail.com> > > > > wrote: > > > > > > > >> 1. Usage, typically if you run in kubernetes or any managed instance > > env > > > >> then you don't care and will restart the instance (with graceful > > > shutdown) > > > >> when needed > > > >> > > > > > > > > This is outside of my scope. > > > > > > > > > > > >> 2. There are several tomcat instances out there using certbot (my > blog > > > is a > > > >> tomee with certbot on for example) so can also be a lack of > > > doc/knowledge > > > >> > > > > > > > > That's well known before in the conversation, i.e. I'm running Tomcat > > > with > > > > SSL on numbeo.com as documented here: > > > > > > > > > > https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/ > > > > > > That guide does way more than necessary. Try reading this: > > > http://tomcat.apache.org/presentations.html#latest-lets-encrypt > > > > > > (Again, if necessary.) > > > > > > certbot + script = working > > > > > > >> 3. I agree a built in module enables an easier deployment (just a > > valve > > > to > > > >> configure with a few attributes) and everything else works OOTB but > > you > > > >> don't need any modification in tomcat distribution to do that - was > my > > > main > > > >> point, all can be done in a new module without modifying tomcat > > > internals > > > >> for a particular deployment > > > > > > > > But adding a Valve or a Servlet would mean modifying Tomcat > internals? > > > > > > No. Writing a Valve does not change any code that ships with Tomcat. > > > > > > Steps: > > > > > > 1. Write Valve, compile + package to JAR > > > 2. Drop JAR in lib/ directory > > > 3. Add <Valve /> to conf/server.xml > > > > > > No where in there is editing of any Tomcat Java source required. > > > > > > >> 4. In several cases tomcat will not have the SSL config but a > frontend > > > >> (httpd, nginx, ...) will do it so tomcat integration will not help > > there > > > >> > > > > > > > > Those suckers ;-) > > > > > > I know you are kidding, but if you want load-balancing and fail-over, > > > you have to front Tomcat with *something*. And if you are fronting > > > Tomcat, you really should be terminating TLS there as well. At which > > > point, ACME-in-Tomcat is really unnecessary. > > > > > > That's one of the reasons we are all a little skeptical about this: > most > > > Tomcat installations are not one-node wonders and already have all this > > > other infrastructure available. So doing ACME elsewhere is simply > > > "easier" than doing it at the Tomcat level. > > > > > > -chris > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > >
