tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Dynamic reloading of SSL certificates
Date Sat, 30 Jun 2018 15:27:37 GMT

On 6/29/18 5:06 PM, Mark Thomas wrote:
> On 29/06/18 21:58, Christopher Schultz wrote:
>> On 6/27/18 4:59 PM, Mark Thomas wrote:
>>> On 27/06/18 17:21, Christopher Schultz wrote:
> <snip/>
>>>> any objection to taking this code and putting it into the
>>>> Connector under the public method reloadSSLHostConfig to make it (a)
>>>> accessible via JMX and (b) easy to access?
>>> Yes.
>>> The operations are already accessible via JMX on the ProtocolHandlers.
>>> As the refactoring has progressed there has been a steady shift away
>>> from duplicating attributes and methods between the Connector, Protocol
>>> and endpoint. I think there will always need to be some duplication but
>>> it has been trending downwards.
>> The (somewhat related) operations I see on the ProtocolHandler are:
>> findSslHostConfigs
>> addSslHostConfig
>> Let's say I want to trigger a CRL or keystore reload via the
>> JMXProxyServlet. How would I go about doing that using the above
>> methods? Or am I missing something?
> AbstractHttp11Protocol.reloadSslHostConfigs()
> AbstractHttp11Protocol.reloadSslHostConfig(String)
> Ah! Those are only in 9.0.x. Are you looking at 8.5.x? It looks like a
> back-port is required.

Yes, sorry, I am indeed looking at 8.5.x. Back-ports would be greatly

As for the methods in Protocol + Connector, I'm okay keeping them in the
ProtocolHandler classes for the reasons you mention. The only problem is
that nobody will ever guess to look there, so we have to find a way to
document that in a way that will direct people to look there for the
appropriate runtime-related methods.

I'll take a look at the users guide as I prep for my Let's Encrypt
presentation for ApacheCon and hopefully make some improvements.


View raw message