Recognizing Certificate Updates

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Recognizing Certificate Updates

Jerry Malcolm
We have a production environment where we rarely reboot Tomcat.
LetsEncrypt auto-updates the certificates every couple of months. But
the new certificates are not loaded into Tomcat.  So when the original
expiration date of the certs arrives, users get "certificate expired"
even though new certs exist.  A simple reboot to load the new certs
fixes it.  But we want to avoid reboots.  Are there any config
parameters that tell TC to check for cert updates and reload the new
certs?  Thx


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

John Larsen
This is why we set up SSL through the web server instead of tomcat.
Apache webserver -> SSL -> Mod_jk <-> Tomcat

John Larsen



On Sat, Dec 26, 2020 at 10:43 AM Jerry Malcolm <[hidden email]>
wrote:

> We have a production environment where we rarely reboot Tomcat.
> LetsEncrypt auto-updates the certificates every couple of months. But
> the new certificates are not loaded into Tomcat.  So when the original
> expiration date of the certs arrives, users get "certificate expired"
> even though new certs exist.  A simple reboot to load the new certs
> fixes it.  But we want to avoid reboots.  Are there any config
> parameters that tell TC to check for cert updates and reload the new
> certs?  Thx
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

Mladen Adamović
In reply to this post by Jerry Malcolm
If you set up tomcat manager up, you can reload certificate with something
like
Stop Connector – curl http://localhost:8080/manager/jmxproxy?invoke=Catalina
%3Atype%3DConnector%2Cport%3D8443&op=stop
Start Connector – curl http://localhost:8080/manager/jmxproxy?invoke=Catalina
%3Atype%3DConnector%2Cport%3D8443&op=start
(source:
http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%20Apache%20Tomcat.pdf
 )

This is probably faster than reboot the whole tomcat, I haven't tried it.
This looks imperfect as hell.

Honestly, I thought that reloadAfterNDays param to server.xml would be
better, but admins didn't have an understanding on this topic.




On Sat, Dec 26, 2020 at 6:49 PM Jerry Malcolm <[hidden email]>
wrote:

> We have a production environment where we rarely reboot Tomcat.
> LetsEncrypt auto-updates the certificates every couple of months. But
> the new certificates are not loaded into Tomcat.  So when the original
> expiration date of the certs arrives, users get "certificate expired"
> even though new certs exist.  A simple reboot to load the new certs
> fixes it.  But we want to avoid reboots.  Are there any config
> parameters that tell TC to check for cert updates and reload the new
> certs?  Thx
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

Mladen Adamović
In reply to this post by John Larsen
On Sat, Dec 26, 2020 at 6:46 PM John Larsen <[hidden email]>
wrote:

> This is why we set up SSL through the web server instead of tomcat.
> Apache webserver -> SSL -> Mod_jk <-> Tomcat
>

It might be easier to install but performance-wise it doesn't make sense.
If you care about performances, I think you should make Tomcat only server
(to avoid pipelining through sockets).



>
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

logo
In reply to this post by Jerry Malcolm
Jerry,

Try this after regenerating the LE certs

curl -u <user> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfigs“

for all domains or

curl -u <user> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfig&ps=<domain to reload>“

for just the needed domain.

Adjust the port to your SSL-Connector.

Add a <user> to tomcat-users.xml
    <user username="<user>" password="<passwd>" roles="manager-jmx"/>

Beware not to open the Manager App to the public - just localhost.

HTH

Peter


> Am 26.12.2020 um 18:42 schrieb Jerry Malcolm <[hidden email]>:
>
> We have a production environment where we rarely reboot Tomcat. LetsEncrypt auto-updates the certificates every couple of months. But the new certificates are not loaded into Tomcat.  So when the original expiration date of the certs arrives, users get "certificate expired" even though new certs exist.  A simple reboot to load the new certs fixes it.  But we want to avoid reboots.  Are there any config parameters that tell TC to check for cert updates and reload the new certs?  Thx
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

logo
Jerry,

the quotes were messed up.

See the correct command below inline.

> Am 28.12.2020 um 11:10 schrieb logo <[hidden email]>:
>
> Jerry,
>
> Try this after regenerating the LE certs
>
> curl -u <user> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfigs <https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfigs>"
>
> for all domains or
>
> curl -u <user> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfig&ps=<domain to reload>"
>
> for just the needed domain.
>
> Adjust the port to your SSL-Connector.
>
> Add a <user> to tomcat-users.xml
>    <user username="<user>" password="<passwd>" roles="manager-jmx"/>
>
> Beware not to open the Manager App to the public - just localhost.
>
> HTH
>
> Peter
>
>
>> Am 26.12.2020 um 18:42 schrieb Jerry Malcolm <[hidden email]>:
>>
>> We have a production environment where we rarely reboot Tomcat. LetsEncrypt auto-updates the certificates every couple of months. But the new certificates are not loaded into Tomcat.  So when the original expiration date of the certs arrives, users get "certificate expired" even though new certs exist.  A simple reboot to load the new certs fixes it.  But we want to avoid reboots.  Are there any config parameters that tell TC to check for cert updates and reload the new certs?  Thx
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

Jerry Malcolm
Thanks for the info.  I'll try to figure out a way to integrate this. 
The problem is that I don't really know when the certs get regen'd.  I
have a daily cron job that calls certbot to renew. But it only renews
when it decides it's time to renew.  TC is so good about monitoring
other folders for changes such as war files, jar files, etc and
automatically refreshing when it detects a file update.  I was just
hoping that there was something buried inside TC that I had missed that
tells TC to monitor the certs and refresh if the certs are updated.

On 12/28/2020 4:12 AM, logo wrote:

> Jerry,
>
> the quotes were messed up.
>
> See the correct command below inline.
>
>> Am 28.12.2020 um 11:10 schrieb logo <[hidden email]>:
>>
>> Jerry,
>>
>> Try this after regenerating the LE certs
>>
>> curl -u <user> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfigs <https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfigs>"
>>
>> for all domains or
>>
>> curl -u <user> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfig&ps=<domain to reload>"
>>
>> for just the needed domain.
>>
>> Adjust the port to your SSL-Connector.
>>
>> Add a <user> to tomcat-users.xml
>>     <user username="<user>" password="<passwd>" roles="manager-jmx"/>
>>
>> Beware not to open the Manager App to the public - just localhost.
>>
>> HTH
>>
>> Peter
>>
>>
>>> Am 26.12.2020 um 18:42 schrieb Jerry Malcolm <[hidden email]>:
>>>
>>> We have a production environment where we rarely reboot Tomcat. LetsEncrypt auto-updates the certificates every couple of months. But the new certificates are not loaded into Tomcat.  So when the original expiration date of the certs arrives, users get "certificate expired" even though new certs exist.  A simple reboot to load the new certs fixes it.  But we want to avoid reboots.  Are there any config parameters that tell TC to check for cert updates and reload the new certs?  Thx
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

Christopher Schultz-2
In reply to this post by Mladen Adamović
Mladen,

On 12/26/20 13:25, Mladen Adamović wrote:

> If you set up tomcat manager up, you can reload certificate with something
> like
> Stop Connector – curl http://localhost:8080/manager/jmxproxy?invoke=Catalina
> %3Atype%3DConnector%2Cport%3D8443&op=stop
> Start Connector – curl http://localhost:8080/manager/jmxproxy?invoke=Catalina
> %3Atype%3DConnector%2Cport%3D8443&op=start
> (source:
> http://people.apache.org/~schultz/ApacheCon%20NA%202017/Let's%20Encrypt%20Apache%20Tomcat.pdf
>   )
>
> This is probably faster than reboot the whole tomcat, I haven't tried it.

It's very much faster than "rebooting" whether you mean rebooting the
whole server or just restarting the Tomcat service. Not only that, but
no in-flight requests or even those queued in the TCP/IP stack's backlog
will be dropped. It really is a zero-downtime solution.

> This looks imperfect as hell.

What is imperfect about it? Sure, it's not 100% automatic, but at least
it's possible. Even Apache httpd can't do what we are doing.

> Honestly, I thought that reloadAfterNDays param to server.xml would be
> better, but admins didn't have an understanding on this topic.

Don't be a jerk. We understand it. We are just saying that we want it
built in stages. If you want radical changes, you'll need to work on a
server without a decades-long history of being stable and reliable.

Thanks,
-chris

> On Sat, Dec 26, 2020 at 6:49 PM Jerry Malcolm <[hidden email]>
> wrote:
>
>> We have a production environment where we rarely reboot Tomcat.
>> LetsEncrypt auto-updates the certificates every couple of months. But
>> the new certificates are not loaded into Tomcat.  So when the original
>> expiration date of the certs arrives, users get "certificate expired"
>> even though new certs exist.  A simple reboot to load the new certs
>> fixes it.  But we want to avoid reboots.  Are there any config
>> parameters that tell TC to check for cert updates and reload the new
>> certs?  Thx
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

Christopher Schultz-2
In reply to this post by Jerry Malcolm
Jerry,

On 12/28/20 13:56, Jerry Malcolm wrote:
> Thanks for the info.  I'll try to figure out a way to integrate this.
> The problem is that I don't really know when the certs get regen'd.  I
> have a daily cron job that calls certbot to renew. But it only renews
> when it decides it's time to renew.  TC is so good about monitoring
> other folders for changes such as war files, jar files, etc and
> automatically refreshing when it detects a file update.  I was just
> hoping that there was something buried inside TC that I had missed that
> tells TC to monitor the certs and refresh if the certs are updated.

Check out this presentation which includes scripts for this kind of
thing. It shows how to detect that the LE key+cert have been actually
updated. It also shows how to re-package those PEM files as a PKCS12
keystore (or JKS if you like that kind of thing) and how to trigger a
reload of the TLS configuration (including the keys + certificates).

https://tomcat.apache.org/presentations.html#latest-lets-encrypt

-chris

> On 12/28/2020 4:12 AM, logo wrote:
>> Jerry,
>>
>> the quotes were messed up.
>>
>> See the correct command below inline.
>>
>>> Am 28.12.2020 um 11:10 schrieb logo <[hidden email]>:
>>>
>>> Jerry,
>>>
>>> Try this after regenerating the LE certs
>>>
>>> curl -u <user>
>>> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfigs 
>>> <https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfigs>"
>>>
>>>
>>> for all domains or
>>>
>>> curl -u <user>
>>> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfig&ps=<domain
>>> to reload>"
>>>
>>> for just the needed domain.
>>>
>>> Adjust the port to your SSL-Connector.
>>>
>>> Add a <user> to tomcat-users.xml
>>>     <user username="<user>" password="<passwd>" roles="manager-jmx"/>
>>>
>>> Beware not to open the Manager App to the public - just localhost.
>>>
>>> HTH
>>>
>>> Peter
>>>
>>>
>>>> Am 26.12.2020 um 18:42 schrieb Jerry Malcolm <[hidden email]>:
>>>>
>>>> We have a production environment where we rarely reboot Tomcat.
>>>> LetsEncrypt auto-updates the certificates every couple of months.
>>>> But the new certificates are not loaded into Tomcat.  So when the
>>>> original expiration date of the certs arrives, users get
>>>> "certificate expired" even though new certs exist.  A simple reboot
>>>> to load the new certs fixes it.  But we want to avoid reboots.  Are
>>>> there any config parameters that tell TC to check for cert updates
>>>> and reload the new certs?  Thx
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

Mladen Adamović
In reply to this post by Christopher Schultz-2
On Tue, Dec 29, 2020 at 3:18 AM Christopher Schultz <
[hidden email]> wrote:

> > Honestly, I thought that reloadAfterNDays param to server.xml would be
> > better, but admins didn't have an understanding on this topic.
>
> Don't be a jerk. We understand it. We are just saying that we want it
> built in stages. If you want radical changes, you'll need to work on a
> server without a decades-long history of being stable and reliable.
>

Well, one thing is certainly correct here - that Tomcat at least in 2016
wasn't working properly on my server, Numbeo.com. The problem was noticed
in the past few months and the update to 9.0.47 solved the issue, so indeed
Tomcat doesn't have a stable and reliable history. I haven't complained
about it although.

Regarding me being the jerk, I haven't seen regarding reloadAfterNDays
param that any project maintainer said something like: "I think that's a
good idea. If you create that code, I'll review it".

So from my point of view, there wasn't understanding.

It looked that Romain and you want a full ACME client without dependencies
so that Tomcat could run in containers with SSL, while it's a valid idea,
it seems I wouldn't be the one building that.

There are a few reasons, i.e. I have "newbie Tomcat devs problems",  and
I'm not so motivated to work on a feature that makes more sense for big
corporations rather than a single small developers.

To note even my question to explain to add Class javadoc
for LifecycleMBeanBase stayed unanswered so far in dev list, to my surprise.

Back in 2007, I was good enough so that Google picked me to develop the
software for them, I left to start my own business two years later, but I
have a history of not being a good team player, seeing the same things
differently than other people, and also I don't have a history of
contributing to open-source projects (unless started by myself), so
perhaps, at the end of the day, I'm not the good fit for Tomcat dev.
Anyway, as it looks now, I'll unsubscribe soon from the Tomcat dev email
list as it looks to me that I didn't fit.




>
> Thanks,
> -chris
>
> > On Sat, Dec 26, 2020 at 6:49 PM Jerry Malcolm <[hidden email]>
> > wrote:
> >
> >> We have a production environment where we rarely reboot Tomcat.
> >> LetsEncrypt auto-updates the certificates every couple of months. But
> >> the new certificates are not loaded into Tomcat.  So when the original
> >> expiration date of the certs arrives, users get "certificate expired"
> >> even though new certs exist.  A simple reboot to load the new certs
> >> fixes it.  But we want to avoid reboots.  Are there any config
> >> parameters that tell TC to check for cert updates and reload the new
> >> certs?  Thx
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

Christopher Schultz-2
Mladen,

On 12/29/20 03:46, Mladen Adamović wrote:

> On Tue, Dec 29, 2020 at 3:18 AM Christopher Schultz <
> [hidden email]> wrote:
>
>>> Honestly, I thought that reloadAfterNDays param to server.xml would be
>>> better, but admins didn't have an understanding on this topic.
>>
>> Don't be a jerk. We understand it. We are just saying that we want it
>> built in stages. If you want radical changes, you'll need to work on a
>> server without a decades-long history of being stable and reliable.
>>
>
> Well, one thing is certainly correct here - that Tomcat at least in 2016
> wasn't working properly on my server, Numbeo.com. The problem was noticed
> in the past few months and the update to 9.0.47 solved the issue, so indeed
> Tomcat doesn't have a stable and reliable history. I haven't complained
> about it although.
>
> Regarding me being the jerk, I haven't seen regarding reloadAfterNDays
> param that any project maintainer said something like: "I think that's a
> good idea. If you create that code, I'll review it".

We said "write it as a Valve and we'll review it." Maybe not word for
word, but I've tried to be encouraging about you going in that
direction. Everyone else seems to be ignoring you thus far. If you
continue to be an ass, I'll ignore you, too.

> So from my point of view, there wasn't understanding.
>
> It looked that Romain and you want a full ACME client without dependencies
> so that Tomcat could run in containers with SSL, while it's a valid idea,
> it seems I wouldn't be the one building that.
>
> There are a few reasons, i.e. I have "newbie Tomcat devs problems",  and
> I'm not so motivated to work on a feature that makes more sense for big
> corporations rather than a single small developers.
>
> To note even my question to explain to add Class javadoc
> for LifecycleMBeanBase stayed unanswered so far in dev list, to my surprise.

You posted that on December 27th at 02:45am in my time zone. I wasn't
exactly looking at email around then. Or at all on Sunday. OR really
much yesterday, the 28th. I'm on holiday, like a LOT of other people
right now.

Something that may seem like an emergency to you just ... is not so in
the eyes of all the *unpaid volunteers* who work on this project.

FTR, that's a base class for implementations of Lifecycle that also adds
useful methods for any class which needs to implement both Lifecycle and
also be an MBean. It it were to have class-level javadoc it would be
something like "utility methods for things that subclass this class".
So... not terribly helpful to someone who doesn't know what it was,
originally. But it's also difficult to explain in clas-level javadoc
*why* someone would want to extend that particular class.

> Back in 2007, I was good enough so that Google picked me to develop the
> software for them, I left to start my own business two years later, but I
> have a history of not being a good team player, seeing the same things
> differently than other people, and also I don't have a history of
> contributing to open-source projects (unless started by myself), so
> perhaps, at the end of the day, I'm not the good fit for Tomcat dev.
> Anyway, as it looks now, I'll unsubscribe soon from the Tomcat dev email
> list as it looks to me that I didn't fit.

You can certainly take your ball and go home, but then everyone loses,
right?

If you are motivated to work on this, we are happy to help you.

If you are instead motivated to insult everyone, complain that nobody is
paying attention to your pet project, and refuse to accept the help and
direction provided, then we aren't very interested.

-chris

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Recognizing Certificate Updates

Mladen Adamović
Hi Christopher,

if I manage to write a code that I think would help others regarding
Letsencrypt/SSL issues, I'll send it to you.

In the meantime these instructions sent by Peter sounds good enough:
curl -u <user> "
https://localhost:8443/manager/jmxproxy?invoke=Catalina:type=ProtocolHandler,port=8443&op=reloadSslHostConfigs


Add a <user> to tomcat-users.xml
    <user username="<user>" password="<passwd>" roles="manager-jmx"/>

Beware not to open the Manager App to the public - just localhost.

Thank you,
Mladen


On Tue, Dec 29, 2020 at 3:42 PM Christopher Schultz <
[hidden email]> wrote:

> Mladen,
>
> On 12/29/20 03:46, Mladen Adamović wrote:
> > On Tue, Dec 29, 2020 at 3:18 AM Christopher Schultz <
> > [hidden email]> wrote:
> >
> >>> Honestly, I thought that reloadAfterNDays param to server.xml would be
> >>> better, but admins didn't have an understanding on this topic.
> >>
> >> Don't be a jerk. We understand it. We are just saying that we want it
> >> built in stages. If you want radical changes, you'll need to work on a
> >> server without a decades-long history of being stable and reliable.
> >>
> >
> > Well, one thing is certainly correct here - that Tomcat at least in 2016
> > wasn't working properly on my server, Numbeo.com. The problem was noticed
> > in the past few months and the update to 9.0.47 solved the issue, so
> indeed
> > Tomcat doesn't have a stable and reliable history. I haven't complained
> > about it although.
> >
> > Regarding me being the jerk, I haven't seen regarding reloadAfterNDays
> > param that any project maintainer said something like: "I think that's a
> > good idea. If you create that code, I'll review it".
>
> We said "write it as a Valve and we'll review it." Maybe not word for
> word, but I've tried to be encouraging about you going in that
> direction. Everyone else seems to be ignoring you thus far. If you
> continue to be an ass, I'll ignore you, too.
>
> > So from my point of view, there wasn't understanding.
> >
> > It looked that Romain and you want a full ACME client without
> dependencies
> > so that Tomcat could run in containers with SSL, while it's a valid idea,
> > it seems I wouldn't be the one building that.
> >
> > There are a few reasons, i.e. I have "newbie Tomcat devs problems",  and
> > I'm not so motivated to work on a feature that makes more sense for big
> > corporations rather than a single small developers.
> >
> > To note even my question to explain to add Class javadoc
> > for LifecycleMBeanBase stayed unanswered so far in dev list, to my
> surprise.
>
> You posted that on December 27th at 02:45am in my time zone. I wasn't
> exactly looking at email around then. Or at all on Sunday. OR really
> much yesterday, the 28th. I'm on holiday, like a LOT of other people
> right now.
>
> Something that may seem like an emergency to you just ... is not so in
> the eyes of all the *unpaid volunteers* who work on this project.
>
> FTR, that's a base class for implementations of Lifecycle that also adds
> useful methods for any class which needs to implement both Lifecycle and
> also be an MBean. It it were to have class-level javadoc it would be
> something like "utility methods for things that subclass this class".
> So... not terribly helpful to someone who doesn't know what it was,
> originally. But it's also difficult to explain in clas-level javadoc
> *why* someone would want to extend that particular class.
>
> > Back in 2007, I was good enough so that Google picked me to develop the
> > software for them, I left to start my own business two years later, but I
> > have a history of not being a good team player, seeing the same things
> > differently than other people, and also I don't have a history of
> > contributing to open-source projects (unless started by myself), so
> > perhaps, at the end of the day, I'm not the good fit for Tomcat dev.
> > Anyway, as it looks now, I'll unsubscribe soon from the Tomcat dev email
> > list as it looks to me that I didn't fit.
>
> You can certainly take your ball and go home, but then everyone loses,
> right?
>
> If you are motivated to work on this, we are happy to help you.
>
> If you are instead motivated to insult everyone, complain that nobody is
> paying attention to your pet project, and refuse to accept the help and
> direction provided, then we aren't very interested.
>
> -chris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>