LifecycleMBeanBase doesn't have class explanation in the source
Hi guys, LifecycleMBeanBase doesn't have a class javadoc. Could someone suggest what would be class explanation and add it in the code? Thanks
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Wed, Dec 23, 2020 at 9:13 PM Romain Manni-Bucau 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 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 > > > > > > > > >
Re: feature request: reload SSL certificate automatically after X days (configuration option)
Christopher, thank you, now I think I understand better the situation. You were right that I was anxious about this. Let me try to summarize: - there is a consensus that this could be implemented through a Valve - there are two options for this to work: either with the full ACME client or with the certbot (to note that Letsencrypt recommends users to use certbot). - Tomcat devs don't want additional dependencies towards a ACME client (this one: https://github.com/shred/acme4j/blob/master/README.md has additional dependencies), I understand this point - Writing Tomcat's own ACME client probably shall not happen for various reasons (i.e. not so many users as many users have legitimate reasons to run Tomcat behind a proxy, except those 'suckers' who run it for the sole purpose to have Letsencrypt/SSL with it). Two options for a Valve: - simple responding to ACME challenge (this could go into Tomcat source code eventually) - dependency on Java ACME client (probably would stay separate) Regarding writing Valve, this would probably mean in any case most likely providing a different ServletContext, right? 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 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 > >
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Wed, Dec 23, 2020 at 4:44 PM Romain Manni-Bucau
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/
> 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?
> 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 ;-)
>
> This is why, for me, a tomcat-letsencrypt module is the most relevant
> solution.
> If owned by Tomcat project perfect (this is the best IMHO), if not it will
> still cover the same features so still good.
>
> Hope it makes sense.
>
>
> >
> >
> >
> >
> > > Do you see anything else which would need to change? The reloadSSL
> method
> > > was added for letsencrypt already so guess this adjustment work is
> > already
> > > done.
> >
> >
> > There are currently two options, through manager or through service
> > restart. It seems that there is no consensus here to add the 3th option.
> >
> >
> >
> >
> >
> >
> >
> > >
> > > >
> > > >
> > > > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com>
> > > > wrote:
> > > >
> > > > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> > > mladen.adamo...@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I don't think so, this connector auth is only used in very
> > > particular
> > > > > > cases
> > > > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much.
> It
> > > is
> > > > > > also a
> > > > > > > kind of automatic authorization - no password or so - so will
> > pass
> > > > and
> > > > > > not
> > > > > > > fail.
> > > > > > >
> > > > > >
> > > > > > That sounds very strange, as I have seen in the code:
> > > > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > > > ...
> > > > > > } else if (!(authenticator instanceof
> > > > > AuthenticatorBase)) {
> > > > > >...
> > > > > > }
> > > > > >
> > > > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > > > >
> > > > > >
> > > > > Sure but check what makes remoteUserNeedsAuthorization true (http2
> > and
> > > > ajp)
> > > > > and what does the block when true (authenticate(username), no
> > password
> > > or
> > > > > so).
> > > > > So not an issue IMHO.
> > > > >
> > > > >
> > > > > >
> > > > > > My point was if you have some security contraint (JWT, basic,
> > etc...)
> > > > on
> > > > > > > /*, then your servlet will not be called for letsencrypt call
> > > whereas
> > > > > if
> > > > > > > you have a valve you can still handle it properly since you
> > didn't
> > > > > enter
> > > > > > > the secured chain - a valve is before filter chain and can be
> > > before
> > > > > > > authenticators in valve chain since authenticators -
> > > > AuthenticatorBase
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Wed, Dec 23, 2020 at 3:17 PM Romain Manni-Bucau
wrote:
> I'm tempted to say either provide a default tomcat-letsencrypt module
> "ready to activate" - and I would support you in that work - or nothing
> since tomcat is letsencryts friendly thanks its pluggable design IMHO
>
I'm not sure what you mean by tomcat-letsencrypt module, as tomcat doesn't
have "Module" neither Letsencrypt according to Google search.
Tomcat is not user friendly for Letsencrypt enough according to people who
are posting problems on Letsencrypt forums:
https://community.letsencrypt.org/search?q=tomcat%20order%3Alatest
you can see many people experiencing problems.
Situation in Payara is better with this script:
https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
(hopefully, I didn't try).
> Do you see anything else which would need to change? The reloadSSL method
> was added for letsencrypt already so guess this adjustment work is already
> done.
There are currently two options, through manager or through service
restart. It seems that there is no consensus here to add the 3th option.
>
> >
> >
> > On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Le mer. 23 déc. 2020 à 12:50, Mladen Adamović <
> mladen.adamo...@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> > > rmannibu...@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > I don't think so, this connector auth is only used in very
> particular
> > > > cases
> > > > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It
> is
> > > > also a
> > > > > kind of automatic authorization - no password or so - so will pass
> > and
> > > > not
> > > > > fail.
> > > > >
> > > >
> > > > That sounds very strange, as I have seen in the code:
> > > > if (req.getRemoteUserNeedsAuthorization()) {
> > > > ...
> > > > } else if (!(authenticator instanceof
> > > AuthenticatorBase)) {
> > > >...
> > > > }
> > > >
> > > > public class SSLAuthenticator extends AuthenticatorBase {
> > > >
> > > >
> > > Sure but check what makes remoteUserNeedsAuthorization true (http2 and
> > ajp)
> > > and what does the block when true (authenticate(username), no password
> or
> > > so).
> > > So not an issue IMHO.
> > >
> > >
> > > >
> > > > My point was if you have some security contraint (JWT, basic, etc...)
> > on
> > > > > /*, then your servlet will not be called for letsencrypt call
> whereas
> > > if
> > > > > you have a valve you can still handle it properly since you didn't
> > > enter
> > > > > the secured chain - a valve is before filter chain and can be
> before
> > > > > authenticators in valve chain since authenticators -
> > AuthenticatorBase
> > > -
> > > > > are valves.
> > > > >
> > > >
> > > > Authenticator Valve's seems to me to have a different treatment than
> > > other
> > > > Valves which are accessed through Pipeline.
> > > >
> > >
> > > This is true since it can be obtained from the context and its call can
> > be
> > > forced, but here again the question is when.
> > > If you check callers then it shouldn't be the case until you add
> another
> > > valve doing it and if so you can still set the LetsEncryptValve before
> > and
> > > bypass it - can even be set on the host and not the context.
> > >
> > >
> > > >
> > > >
> > > >
> > > > > In other words: no code change required in tomcat internals.
> > > > >
> > > >
> > > > I don't understand this yet. If the implementation would use
> > serverl.xml
> > > to
> > > > change StandardContextValve to something else?
> > > >
> > >
> > > No, change nothing, just add a valve on the host for example through
> > > > className /> tag.
> > >
> > >
> > > >
> > > > I've tried to figure out what are you doing in meecrowave and my IDE
> > > > (Netbeans) shows me Usage of Lets
Re: feature request: reload SSL certificate automatically after X days (configuration option)
hmmm.. at least for us, Certbot fetches acme-challenge on HTTP connector.
According to
https://github.com/payara/Payara/blob/master/appserver/packager/appserver-core/src/main/resources/bin/letsencrypt.py
an app most likely should have a HTTP connector for Letsencrypt.
Then it really doesn't matter AFAIK, if Servet is used or a Valve for most
cases. Whatever dev thinks fits more in the nature of the system.
I know this can be implemented outside of Tomcat (as we have that
implementation through Servlet), I'm discussing what could be done in
Tomcat to simplify Letsencrypt integration.
On Wed, Dec 23, 2020 at 2:01 PM Romain Manni-Bucau
wrote:
> Le mer. 23 déc. 2020 à 12:50, Mladen Adamović
> a
> écrit :
>
> > On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau <
> rmannibu...@gmail.com
> > >
> > wrote:
> >
> > > I don't think so, this connector auth is only used in very particular
> > cases
> > > (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is
> > also a
> > > kind of automatic authorization - no password or so - so will pass and
> > not
> > > fail.
> > >
> >
> > That sounds very strange, as I have seen in the code:
> > if (req.getRemoteUserNeedsAuthorization()) {
> > ...
> > } else if (!(authenticator instanceof
> AuthenticatorBase)) {
> >...
> > }
> >
> > public class SSLAuthenticator extends AuthenticatorBase {
> >
> >
> Sure but check what makes remoteUserNeedsAuthorization true (http2 and ajp)
> and what does the block when true (authenticate(username), no password or
> so).
> So not an issue IMHO.
>
>
> >
> > My point was if you have some security contraint (JWT, basic, etc...) on
> > > /*, then your servlet will not be called for letsencrypt call whereas
> if
> > > you have a valve you can still handle it properly since you didn't
> enter
> > > the secured chain - a valve is before filter chain and can be before
> > > authenticators in valve chain since authenticators - AuthenticatorBase
> -
> > > are valves.
> > >
> >
> > Authenticator Valve's seems to me to have a different treatment than
> other
> > Valves which are accessed through Pipeline.
> >
>
> This is true since it can be obtained from the context and its call can be
> forced, but here again the question is when.
> If you check callers then it shouldn't be the case until you add another
> valve doing it and if so you can still set the LetsEncryptValve before and
> bypass it - can even be set on the host and not the context.
>
>
> >
> >
> >
> > > In other words: no code change required in tomcat internals.
> > >
> >
> > I don't understand this yet. If the implementation would use serverl.xml
> to
> > change StandardContextValve to something else?
> >
>
> No, change nothing, just add a valve on the host for example through className /> tag.
>
>
> >
> > I've tried to figure out what are you doing in meecrowave and my IDE
> > (Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
> >
>
> Maybe use another IDE ;) (joking ;)):
>
> https://github.com/apache/openwebbeans-meecrowave/blob/433a691b246f9eeda2273e794ddbb7970691cc5f/meecrowave-letsencrypt/src/main/java/org/apache/meecrowave/letencrypt/LetsEncryptSetup.java#L44
> The MeecrowaveAwareInstanceCustomizer instance enables to "code" the
> server.xml but it is equivalent to previous proposal ().
>
>
> >
> > How this LetsEncryptValve is actually "injected" into meecrowave
> Pipeline ?
> > Or how it is used internally?
> > I didn't see any Reflection code on Valves or Valve base by searching
> > source code.
> >
> >
> >
> >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 23 déc. 2020 à 11:23, Mladen Adamović <
> mladen.adamo...@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > Thank you Romain, do you then think the place to check for ACME Valve
> > (if
> > > > that would the be a
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Wed, Dec 23, 2020 at 12:12 PM Romain Manni-Bucau
wrote:
> I don't think so, this connector auth is only used in very particular cases
> (= never ;)): HTTP2 - we don't care, AJP - we don't care much. It is also a
> kind of automatic authorization - no password or so - so will pass and not
> fail.
>
That sounds very strange, as I have seen in the code:
if (req.getRemoteUserNeedsAuthorization()) {
...
} else if (!(authenticator instanceof AuthenticatorBase)) {
...
}
public class SSLAuthenticator extends AuthenticatorBase {
My point was if you have some security contraint (JWT, basic, etc...) on
> /*, then your servlet will not be called for letsencrypt call whereas if
> you have a valve you can still handle it properly since you didn't enter
> the secured chain - a valve is before filter chain and can be before
> authenticators in valve chain since authenticators - AuthenticatorBase -
> are valves.
>
Authenticator Valve's seems to me to have a different treatment than other
Valves which are accessed through Pipeline.
> In other words: no code change required in tomcat internals.
>
I don't understand this yet. If the implementation would use serverl.xml to
change StandardContextValve to something else?
I've tried to figure out what are you doing in meecrowave and my IDE
(Netbeans) shows me Usage of LetsEncryptValve [no occurrences]
How this LetsEncryptValve is actually "injected" into meecrowave Pipeline ?
Or how it is used internally?
I didn't see any Reflection code on Valves or Valve base by searching
source code.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>
>
> Le mer. 23 déc. 2020 à 11:23, Mladen Adamović
> a
> écrit :
>
> > Thank you Romain, do you then think the place to check for ACME Valve (if
> > that would the be appropriate naming) would be in
> > CoyoteAdapter.postParseRequest line 814
> > before doConnectorAuthenticationAuthorization(...) ?
> >
> >
> > On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau <
> rmannibu...@gmail.com>
> > wrote:
> >
> > > Side note: using a servlet generally does not work if you have any
> > security
> > > on the webapp + requires a webapp whereas using a valve solves these
> two
> > > issues.
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://rmannibucau.metawerx.net/> | Old Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > > <
> > >
> >
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> > > >
> > >
> > >
> > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović <
> mladen.adamo...@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > As I haven't received more replies on this topic, I'm guessing
> project
> > > > maintainers are not interested in reviewing and including the code
> for
> > > > simpler Letsencrypt integration and discussing the mentioned SSL
> > > > documentation improvements?
> > > >
> > > > Enabling AMCE response servlet (good idea by default) would be a good
> > > step
> > > > in my opinion?
> > > >
> > > > My procedure is explained here:
> > > >
> > > >
> > >
> >
> https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/
> > > > and the step "Configure HTTP redirect application with support to
> ACME
> > > > challenge" could be integrated into Tomcat easily.
> > > >
> > > > In the case that is integrated, I can write a new improved
> > > > tutorial/process.
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović <
> > > > mladen.adamo...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com>
> > > > > wrote:
> > > > >
&g
Re: feature request: reload SSL certificate automatically after X days (configuration option)
Thank you Romain, do you then think the place to check for ACME Valve (if that would the be appropriate naming) would be in CoyoteAdapter.postParseRequest line 814 before doConnectorAuthenticationAuthorization(...) ? On Wed, Dec 23, 2020 at 9:22 AM Romain Manni-Bucau wrote: > Side note: using a servlet generally does not work if you have any security > on the webapp + requires a webapp whereas using a valve solves these two > issues. > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > Le mer. 23 déc. 2020 à 09:15, Mladen Adamović > a > écrit : > > > As I haven't received more replies on this topic, I'm guessing project > > maintainers are not interested in reviewing and including the code for > > simpler Letsencrypt integration and discussing the mentioned SSL > > documentation improvements? > > > > Enabling AMCE response servlet (good idea by default) would be a good > step > > in my opinion? > > > > My procedure is explained here: > > > > > https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/ > > and the step "Configure HTTP redirect application with support to ACME > > challenge" could be integrated into Tomcat easily. > > > > In the case that is integrated, I can write a new improved > > tutorial/process. > > > > > > > > > > On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović < > > mladen.adamo...@gmail.com> > > wrote: > > > > > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau < > > rmannibu...@gmail.com> > > > wrote: > > > > > >> It moves the problem elsewhere, how would the CLI communicate with > > tomcat? > > >> JMX, HTTP uses a port, a file based communication would be probably > > worse > > >> because of perms and other admin issues (and just not working in k8s). > > >> > > > > > > I don't see other sane ways actually. So it seems a web-based manager > > with > > > curl is there to stay (for the time being at least). > > > > > > To Chris: It's somewhat weird that the user needs a web manager just > for > > > curl-ing certification renewal. > > > > > > To everyone: > > > I have a suggestion on improving Documentation regarding SSL. > > > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html > > > Currently, it states > > > Configuration > > > Prepare the Certificate Keystore > > > Tomcat currently operates only on JKS, PKCS11 or PKCS12 format > keystores. > > > > > > ... > > > > > > > > > I think it should start with > > > Configuration > > > Option 1) Use Tomcat Native > > > which would showcase a path to something like: > > > > > > > > > > > protocol="org.apache.coyote.http11.Http11NioProtocol" > > > port="8443" > > > maxThreads="150" > > > SSLEnabled="true" > > > > > > > > > certificateKeyFile="conf/localhost-rsa-key.pem" > > > certificateFile="conf/localhost-rsa-cert.pem" > > > certificateChainFile="conf/localhost-rsa-chain.pem" > > > type="RSA" > > > /> > > > > > > > > > > > > Option 2) Without Tomcat Native > > > > > > > > > ... > > > > > > > > > > > > I don't know what is the formal process for improving the documentation > > > here? > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > >> > > > > > >> > > > > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović < > > >> > > mladen.adamo...@gmail.com > > >> > > > > > > >> > > > > a > > >> > > > > écrit : > > >> > > > > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz < > > >> > > > > > ch...@c
Re: feature request: reload SSL certificate automatically after X days (configuration option)
As I haven't received more replies on this topic, I'm guessing project maintainers are not interested in reviewing and including the code for simpler Letsencrypt integration and discussing the mentioned SSL documentation improvements? Enabling AMCE response servlet (good idea by default) would be a good step in my opinion? My procedure is explained here: https://mladenadamovic.wordpress.com/2016/09/06/configure-tomcat-with-ssl-on-ubuntu-minimal/ and the step "Configure HTTP redirect application with support to ACME challenge" could be integrated into Tomcat easily. In the case that is integrated, I can write a new improved tutorial/process. On Sat, Dec 19, 2020 at 11:09 PM Mladen Adamović wrote: > On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau > wrote: > >> It moves the problem elsewhere, how would the CLI communicate with tomcat? >> JMX, HTTP uses a port, a file based communication would be probably worse >> because of perms and other admin issues (and just not working in k8s). >> > > I don't see other sane ways actually. So it seems a web-based manager with > curl is there to stay (for the time being at least). > > To Chris: It's somewhat weird that the user needs a web manager just for > curl-ing certification renewal. > > To everyone: > I have a suggestion on improving Documentation regarding SSL. > https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html > Currently, it states > Configuration > Prepare the Certificate Keystore > Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores. > > ... > > > I think it should start with > Configuration > Option 1) Use Tomcat Native > which would showcase a path to something like: > > > protocol="org.apache.coyote.http11.Http11NioProtocol" > port="8443" > maxThreads="150" > SSLEnabled="true" > > > certificateKeyFile="conf/localhost-rsa-key.pem" > certificateFile="conf/localhost-rsa-cert.pem" > certificateChainFile="conf/localhost-rsa-chain.pem" > type="RSA" > /> > > > > Option 2) Without Tomcat Native > > > ... > > > > I don't know what is the formal process for improving the documentation > here? > > > > > > > > > >> > > > >> > > > >> > > > > >> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović < >> > > mladen.adamo...@gmail.com >> > > > > >> > > > > a >> > > > > écrit : >> > > > > >> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz < >> > > > > > ch...@christopherschultz.net> wrote: >> > > > > > >> > > > > > > Why not use cron? You can do this with a single "curl" command >> > and >> > > > the >> > > > > > > Manager+JMXProxyServlet. >> > > > > > > >> > > > > > >> > > > > > We are not using Tomcat manager app. >> > > > > > >> > > > > > Why someone should be forced to use Manager, to read/setup the >> > > > > > documentation regarding JMXProxyServlet, create an additional >> > > > > > servlet (where does it have dependency on?) only to reload >> > > > automatically >> > > > > > certificates? >> > > > > > >> > > > > > I'm proposing a solution with the simple SSLHostConfig >> parameter. >> > > It's >> > > > a >> > > > > > user friendly. Simple, intuitive. >> > > > > > No need for using manager, no need to create a specific servlet >> > > > somewhere >> > > > > > in your code. Just a single server.xml argument. >> > > > > > >> > > > > > Also, *another idea*, I'm contributing this code (see below) we >> are >> > > > using >> > > > > > for Letsencrypt ACME challenge. >> > > > > > Tomcat could also have an option, i.e. in web.xml to >> automatically >> > > > > support >> > > > > > Letsencrypt ACME challenge. >> > > > > > Idea for web.xml >> > > > > > >> > > > > > Letsencrypt-acme >> > > > > > >> > > > > > >> > > > > > >>
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Sat, Dec 19, 2020 at 6:30 PM Romain Manni-Bucau
wrote:
> It moves the problem elsewhere, how would the CLI communicate with tomcat?
> JMX, HTTP uses a port, a file based communication would be probably worse
> because of perms and other admin issues (and just not working in k8s).
>
I don't see other sane ways actually. So it seems a web-based manager with
curl is there to stay (for the time being at least).
To Chris: It's somewhat weird that the user needs a web manager just for
curl-ing certification renewal.
To everyone:
I have a suggestion on improving Documentation regarding SSL.
https://tomcat.apache.org/tomcat-10.0-doc/ssl-howto.html
Currently, it states
Configuration
Prepare the Certificate Keystore
Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores.
...
I think it should start with
Configuration
Option 1) Use Tomcat Native
which would showcase a path to something like:
Option 2) Without Tomcat Native
...
I don't know what is the formal process for improving the documentation
here?
> > >
> > > >
> > > >
> > > > >
> > > > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> > > mladen.adamo...@gmail.com
> > > > >
> > > > > a
> > > > > écrit :
> > > > >
> > > > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > > > ch...@christopherschultz.net> wrote:
> > > > > >
> > > > > > > Why not use cron? You can do this with a single "curl" command
> > and
> > > > the
> > > > > > > Manager+JMXProxyServlet.
> > > > > > >
> > > > > >
> > > > > > We are not using Tomcat manager app.
> > > > > >
> > > > > > Why someone should be forced to use Manager, to read/setup the
> > > > > > documentation regarding JMXProxyServlet, create an additional
> > > > > > servlet (where does it have dependency on?) only to reload
> > > > automatically
> > > > > > certificates?
> > > > > >
> > > > > > I'm proposing a solution with the simple SSLHostConfig parameter.
> > > It's
> > > > a
> > > > > > user friendly. Simple, intuitive.
> > > > > > No need for using manager, no need to create a specific servlet
> > > > somewhere
> > > > > > in your code. Just a single server.xml argument.
> > > > > >
> > > > > > Also, *another idea*, I'm contributing this code (see below) we
> are
> > > > using
> > > > > > for Letsencrypt ACME challenge.
> > > > > > Tomcat could also have an option, i.e. in web.xml to
> automatically
> > > > > support
> > > > > > Letsencrypt ACME challenge.
> > > > > > Idea for web.xml
> > > > > >
> > > > > > Letsencrypt-acme
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
> > > > > >
> > > > > > etc.
> > > > > >
> > > > > >
> > > > > >
> > > > > > We are using
> > > > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > > > > {"/.well-known/acme-challenge/*"})
> > > > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > > > > >
> > > > > > /**
> > > > > >* Processes requests for both HTTP GET and
> > > > > > POST methods.
> > > > > >*
> > > > > >* @param request servlet request
> > > > > >* @param response servlet response
> > > > > >* @throws ServletException if a servlet-specific error occurs
> > > > > >* @throws IOException if an I/O error occurs
> > > > > >*/
> > > > > > protected void processRequest(HttpServletRequest request,
> > > > > > HttpServletResponse response)
> > > > > > throws ServletException, IOException {
> > > > > > String requestUrl = request.getRequestURL().toString();
> > > > > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > > > > > int i
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Sat, Dec 19, 2020 at 5:06 PM Romain Manni-Bucau
wrote:
> Code can likely be simplified but high level it is just about enabling
> letsencrypt http dance thanks a valve and reloading the cert on update.
>
> Note that acme client is easy to recode to avoid any licensing work so it
> vould be a tomcat-letsencrypt module easily IMHO.
>
Thinking more about this problem... instead of this reload SSL
configuration feature, we need fully integrated support for Letsencrypt.
On a side note, Tomcat might be lacking a command line manager utility,
having manager running on a port sounds... like we are people who avoid a
command line, no?
Although I managed my own way of integration, and wrote my own ACME client,
I don't know yet what Tomcat needs to do to be fully Letsencrypt
integrated.
Are there someone currently working on easy letsencrypt integration?
If not, Romain (or others who are reading this thread), are there existing
devs who want to do it?
I'm ready to join, if someone wants the assistance, but it would probably
be helpful not to duplicate efforts.
The question to project maintainers: would be interested in reviewing that
code for inclusion in the codebase?
(I'm not sure yet how it goes, I'm new here. Certainly, the fact that I
never contributed code to the open-source project which wasn't started by
me doesn't help).
>
>
> > Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a
> > fully
> > supported server.
> >
> >
> >
> >
> >
> >
> > >
> > > Le sam. 19 déc. 2020 à 15:24, Mladen Adamović <
> mladen.adamo...@gmail.com
> > >
> > > a
> > > écrit :
> > >
> > > > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > > > ch...@christopherschultz.net> wrote:
> > > >
> > > > > Why not use cron? You can do this with a single "curl" command and
> > the
> > > > > Manager+JMXProxyServlet.
> > > > >
> > > >
> > > > We are not using Tomcat manager app.
> > > >
> > > > Why someone should be forced to use Manager, to read/setup the
> > > > documentation regarding JMXProxyServlet, create an additional
> > > > servlet (where does it have dependency on?) only to reload
> > automatically
> > > > certificates?
> > > >
> > > > I'm proposing a solution with the simple SSLHostConfig parameter.
> It's
> > a
> > > > user friendly. Simple, intuitive.
> > > > No need for using manager, no need to create a specific servlet
> > somewhere
> > > > in your code. Just a single server.xml argument.
> > > >
> > > > Also, *another idea*, I'm contributing this code (see below) we are
> > using
> > > > for Letsencrypt ACME challenge.
> > > > Tomcat could also have an option, i.e. in web.xml to automatically
> > > support
> > > > Letsencrypt ACME challenge.
> > > > Idea for web.xml
> > > >
> > > > Letsencrypt-acme
> > > >
> > > >
> > > >
> > >
> >
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
> > > >
> > > > etc.
> > > >
> > > >
> > > >
> > > > We are using
> > > > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > > > {"/.well-known/acme-challenge/*"})
> > > > public class LetsencryptAcmeChallenge extends HttpServlet {
> > > >
> > > > /**
> > > >* Processes requests for both HTTP GET and
> > > > POST methods.
> > > >*
> > > >* @param request servlet request
> > > >* @param response servlet response
> > > >* @throws ServletException if a servlet-specific error occurs
> > > >* @throws IOException if an I/O error occurs
> > > >*/
> > > > protected void processRequest(HttpServletRequest request,
> > > > HttpServletResponse response)
> > > > throws ServletException, IOException {
> > > > String requestUrl = request.getRequestURL().toString();
> > > > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > > > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > > > boolean wasError = true;
> > > > if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> > > > String filename = requestUrl.substring(indexFilename);
> > > >
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Sat, Dec 19, 2020 at 4:25 PM Romain Manni-Bucau
wrote:
> It sounds saner than a random reload N days since it can reload when the
> cert changes.
>
Hi Romain,
BTW, Letsencrypt always creates a new file:
i.e.
lrwxrwxrwx 1 root root 35 Dec 1 01:05 cert.pem -> ../../archive/
numbeo.com/cert53.pem
so random reloads should be fine AFAIK.
However, if it's possible to have even more nature and easier integration
with Letsencrypt that would be even nicer.
I did go briefly through your code, there are many places I currently don't
understand.
Ideally, users want Tomcat listed here: https://certbot.eff.org/ as a fully
supported server.
>
> Le sam. 19 déc. 2020 à 15:24, Mladen Adamović
> a
> écrit :
>
> > On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> > > Why not use cron? You can do this with a single "curl" command and the
> > > Manager+JMXProxyServlet.
> > >
> >
> > We are not using Tomcat manager app.
> >
> > Why someone should be forced to use Manager, to read/setup the
> > documentation regarding JMXProxyServlet, create an additional
> > servlet (where does it have dependency on?) only to reload automatically
> > certificates?
> >
> > I'm proposing a solution with the simple SSLHostConfig parameter. It's a
> > user friendly. Simple, intuitive.
> > No need for using manager, no need to create a specific servlet somewhere
> > in your code. Just a single server.xml argument.
> >
> > Also, *another idea*, I'm contributing this code (see below) we are using
> > for Letsencrypt ACME challenge.
> > Tomcat could also have an option, i.e. in web.xml to automatically
> support
> > Letsencrypt ACME challenge.
> > Idea for web.xml
> >
> > Letsencrypt-acme
> >
> >
> >
> org.apache.catalina.servlets.LetsencryptAcmeChallenge
> >
> > etc.
> >
> >
> >
> > We are using
> > @WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
> > {"/.well-known/acme-challenge/*"})
> > public class LetsencryptAcmeChallenge extends HttpServlet {
> >
> > /**
> >* Processes requests for both HTTP GET and
> > POST methods.
> >*
> >* @param request servlet request
> >* @param response servlet response
> >* @throws ServletException if a servlet-specific error occurs
> >* @throws IOException if an I/O error occurs
> >*/
> > protected void processRequest(HttpServletRequest request,
> > HttpServletResponse response)
> > throws ServletException, IOException {
> > String requestUrl = request.getRequestURL().toString();
> > if (requestUrl.contains(".well-known/acme-challenge/")) {
> > int indexFilename = requestUrl.lastIndexOf("/") + 1;
> > boolean wasError = true;
> > if (indexFilename > 0 && indexFilename < requestUrl.length()) {
> > String filename = requestUrl.substring(indexFilename);
> > File existingFile = new
> > File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
> > filename);
> > if (existingFile.exists()) {
> > response.setContentType("text/plain");
> > OutputStream out = response.getOutputStream();
> > FileInputStream in = new FileInputStream(existingFile);
> > FilesOperations.inputStreamToOutputStream(in, out);
> > wasError = false;
> > }
> > }
> > if (wasError) {
> > throw new ServletException("invalid requestUrl " + requestUrl);
> > }
> > }
> >
> > from FilesOperations:
> > public static void inputStreamToOutputStream(InputStream in,
> > OutputStream out) throws IOException {
> > try {
> > byte[ ] buf = new byte[32 * 1024]; // 32K buffer
> > int bytesRead;
> > while ((bytesRead = in.read(buf)) != -1) {
> > out.write(buf, 0, bytesRead);
> > }
> > } finally {
> > if (in != null) {
> > in.close();
> > out.close();
> > }
> > }
> > }
> >
> >
> >
> >
> >
> >
> >
> >
> > > > *Long*:
> > > > SSL certificates have a period of expiration and in the case of
> > > > Letsencrypt, it's set to 3 months as they think everyone should have
> > the
> > > > renewal
Re: feature request: reload SSL certificate automatically after X days (configuration option)
On Sat, Dec 19, 2020 at 2:29 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:
> Why not use cron? You can do this with a single "curl" command and the
> Manager+JMXProxyServlet.
>
We are not using Tomcat manager app.
Why someone should be forced to use Manager, to read/setup the
documentation regarding JMXProxyServlet, create an additional
servlet (where does it have dependency on?) only to reload automatically
certificates?
I'm proposing a solution with the simple SSLHostConfig parameter. It's a
user friendly. Simple, intuitive.
No need for using manager, no need to create a specific servlet somewhere
in your code. Just a single server.xml argument.
Also, *another idea*, I'm contributing this code (see below) we are using
for Letsencrypt ACME challenge.
Tomcat could also have an option, i.e. in web.xml to automatically support
Letsencrypt ACME challenge.
Idea for web.xml
Letsencrypt-acme
org.apache.catalina.servlets.LetsencryptAcmeChallenge
etc.
We are using
@WebServlet(name = "LetsencryptAcmeChallenge", urlPatterns =
{"/.well-known/acme-challenge/*"})
public class LetsencryptAcmeChallenge extends HttpServlet {
/**
* Processes requests for both HTTP GET and
POST methods.
*
* @param request servlet request
* @param response servlet response
* @throws ServletException if a servlet-specific error occurs
* @throws IOException if an I/O error occurs
*/
protected void processRequest(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
String requestUrl = request.getRequestURL().toString();
if (requestUrl.contains(".well-known/acme-challenge/")) {
int indexFilename = requestUrl.lastIndexOf("/") + 1;
boolean wasError = true;
if (indexFilename > 0 && indexFilename < requestUrl.length()) {
String filename = requestUrl.substring(indexFilename);
File existingFile = new
File("/tmp/letsencrypt/public_html/.well-known/acme-challenge/" +
filename);
if (existingFile.exists()) {
response.setContentType("text/plain");
OutputStream out = response.getOutputStream();
FileInputStream in = new FileInputStream(existingFile);
FilesOperations.inputStreamToOutputStream(in, out);
wasError = false;
}
}
if (wasError) {
throw new ServletException("invalid requestUrl " + requestUrl);
}
}
from FilesOperations:
public static void inputStreamToOutputStream(InputStream in,
OutputStream out) throws IOException {
try {
byte[ ] buf = new byte[32 * 1024]; // 32K buffer
int bytesRead;
while ((bytesRead = in.read(buf)) != -1) {
out.write(buf, 0, bytesRead);
}
} finally {
if (in != null) {
in.close();
out.close();
}
}
}
> > *Long*:
> > SSL certificates have a period of expiration and in the case of
> > Letsencrypt, it's set to 3 months as they think everyone should have the
> > renewal mechanism automatically.
> >
> > As the Letsencrypt is the most popular SSL issuing authority (source:
> > https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should
> have
> > an integration with Letsencrypt working flawlessly.
> >
> > We are currently using the script to renew the certificate (I can share
> our
> > integration details with whoever is interested, please email me if you
> are
> > interested), but it's restarting Tomcat.
> >
> > As Tomcat shall not be restarted ever (ideally), I think Tomcat should
> have
> > an option to reload certificate, without a dependency to Tomcat source
> code
> > and "hacks" like some available on StackOverflow:
> >
> https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates
> ).
> > Those hacks are no good as:
> > 1) code to reload certificate should not run inside Java code, as
> > letsencrypt is invoked through Linux
> > 2) each application uses that Stackoverflow hack have additional compile
> > and run dependency set to Tomcat (which is very bad).
> >
> > I have a proposal on how this should be fixed: Tomcat should have a
> > server.xml options something like certificateReloadAfterDays or
> > reloadAfterDays
> >
> > I see this is moved to SSLHostConfig, we are still using old params.
> >
> > Do you agree on this feature?
> >
> > If so... I'm not lazy to try to do it myself, but as I haven't ever
> written
> > Tomcat code neither know procedures (I have been coding professionally
> > since 2006, but I never committed to Maven or Git project before, lol),
> is
> > there someone else who is keen on doing this feature?
>
> Have a look at this:
> http://tomcat.apache.org/presentations.html#latest-lets-encrypt
>
> -chris
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional
feature request: reload SSL certificate automatically after X days (configuration option)
Hi guys, *Shortly*: Tomcat should have either Connector or SSLHostConfig option to automatically reload certificate from the same file after X days, i.e. reloadAfterDays=10 to force Tomcat to reload the certificate automatically after 10 days. *Long*: SSL certificates have a period of expiration and in the case of Letsencrypt, it's set to 3 months as they think everyone should have the renewal mechanism automatically. As the Letsencrypt is the most popular SSL issuing authority (source: https://trends.builtwith.com/ssl/LetsEncrypt ), I think Tomcat should have an integration with Letsencrypt working flawlessly. We are currently using the script to renew the certificate (I can share our integration details with whoever is interested, please email me if you are interested), but it's restarting Tomcat. As Tomcat shall not be restarted ever (ideally), I think Tomcat should have an option to reload certificate, without a dependency to Tomcat source code and "hacks" like some available on StackOverflow: https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates). Those hacks are no good as: 1) code to reload certificate should not run inside Java code, as letsencrypt is invoked through Linux 2) each application uses that Stackoverflow hack have additional compile and run dependency set to Tomcat (which is very bad). I have a proposal on how this should be fixed: Tomcat should have a server.xml options something like certificateReloadAfterDays or reloadAfterDays I see this is moved to SSLHostConfig, we are still using old params. Do you agree on this feature? If so... I'm not lazy to try to do it myself, but as I haven't ever written Tomcat code neither know procedures (I have been coding professionally since 2006, but I never committed to Maven or Git project before, lol), is there someone else who is keen on doing this feature?
Re: Objection to the deprecation of the tomcat-native/APR connector
Perhaps for some users APR is significantly faster than NIO or NIO2, but Graham Leggett didn't bring some examples like: - company ZZZ reports 39% of higher CPU usage with APR for their project - company XXX which is an Apache gold sponsor reports 43% of higher CPU usage for APR for their project Lulu. If the reason to keep it is that users need to change one line in the server.xml is to keep it up, it could probably be done in the code automatically switch to NIO if APR config is given. (sounds like an if-else statement in the code). On Thu, Dec 17, 2020 at 1:20 PM Rémy Maucherat wrote: > On Thu, Dec 17, 2020 at 12:12 PM Mladen Adamović < > mladen.adamo...@gmail.com> > wrote: > > > But what I have discovered from migrating from APR to Nio2 that our > > processor usage went down. We never tried Nio2, I have setup APR back in > > 2014 as I've read it has a better performance. > > > > I would still say the APR connector is faster, just like the java.io > connector was the fastest overall. But it can depend on what you are doing, > maybe if your use case uses the poller more, then it could be significantly > less efficient. The main problems are that it is crash prone (and it's > expensive and complex to make it safe), and it doesn't have feature parity > with NIO. > > About NIO2, Oracle has started updating and fixing NIO again. NIO2 is now > lagging a bit in features (no inherited channel, no UDP - NIO just got > fully rewritten support -, and now no domain socket support). The IO API > war is not over yet though. > > Rémy > > > > > > So I don't see a reason why APR should stay as users can easily migrate > to > > NIO2... > > > > > > > > On Thu, Dec 17, 2020 at 11:41 AM Michael Osipov > > wrote: > > > > > Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg: > > > > Le 11/12/2020 à 17:56, Michael Osipov a écrit : > > > > > > > >> Well, isn't that really a OS vendor problem not ours? We can provide > > > >> grace periods, but that's pretty much it. They need to solve that, > not > > > >> us on a volunteer basis. > > > > > > > > Note that (most) Debian Developers are volunteers too. > > > > > > This makes siauation even worse to sit on old version and continue back > > > porting for downstream. > > > > > > >> FreeBSD's port of libtcnative is uptodate. I provide patches on > > regular > > > >> basis. Vendors like Debian or Red Hat lag years behind. > > > > > > > > I don't know the state in Red Hat, but in Debian tomcat-native is > > > > up-to-date [1]. For the stable release there are backports with more > > > > recent versions available. > > > > > > Thanks for the info, wasn't aware of that. Guess it takes the > maintainer > > > do that otherwise it will stick to very old versions. > > > > > > I am horribly surprised for RHEL 7: > > > > $ yum info tomcat-native 2>&- | grep Version > > > > Version: 1.2.23 > > > > > > in contrast: > > > > $ yum info curl 2>&- | grep Version > > > > Version: 7.29.0 > > > > > > This is unusable. > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > > > > > > > >
Re: Objection to the deprecation of the tomcat-native/APR connector
Hi everyone, TLTR: after switching from APR to Nio2 our processor usage went down. Longer version: Recently we had a production problem which was noticeable years ago, but it became a real problem recently. In our tests 0.75% of connection requests weren't served. I have recently posted in Tomcat-Users email list thread "native connector, server problems with "No data received" after migrating from APR to Nio2 connector, the problem was still there. It turned out that the upgrade from 8.5.5 to 9.0.41 solved the f..ine issue (!), it is a pitty that bug existed in Tomcat for years even in 2014. But what I have discovered from migrating from APR to Nio2 that our processor usage went down. We never tried Nio2, I have setup APR back in 2014 as I've read it has a better performance. So I don't see a reason why APR should stay as users can easily migrate to NIO2... On Thu, Dec 17, 2020 at 11:41 AM Michael Osipov wrote: > Am 2020-12-16 um 16:38 schrieb Emmanuel Bourg: > > Le 11/12/2020 à 17:56, Michael Osipov a écrit : > > > >> Well, isn't that really a OS vendor problem not ours? We can provide > >> grace periods, but that's pretty much it. They need to solve that, not > >> us on a volunteer basis. > > > > Note that (most) Debian Developers are volunteers too. > > This makes siauation even worse to sit on old version and continue back > porting for downstream. > > >> FreeBSD's port of libtcnative is uptodate. I provide patches on regular > >> basis. Vendors like Debian or Red Hat lag years behind. > > > > I don't know the state in Red Hat, but in Debian tomcat-native is > > up-to-date [1]. For the stable release there are backports with more > > recent versions available. > > Thanks for the info, wasn't aware of that. Guess it takes the maintainer > do that otherwise it will stick to very old versions. > > I am horribly surprised for RHEL 7: > > $ yum info tomcat-native 2>&- | grep Version > > Version: 1.2.23 > > in contrast: > > $ yum info curl 2>&- | grep Version > > Version: 7.29.0 > > This is unusable. > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
