вс, 16 сент. 2018 г. в 23:20, Christopher Schultz
<ch...@christopherschultz.net>:
>
> On 9/14/18 05:21, Mark Thomas wrote:
> > On 14/09/18 10:07, Rémy Maucherat wrote:
> >> On Fri, Sep 14, 2018 at 10:41 AM <ma...@apache.org> wrote:
> >>
> >>> Author: markt Date: Fri Sep 14 08:41:02 2018 New Revision:
> >>> 1840901
> >>>
> >>> URL: http://svn.apache.org/viewvc?rev=1840901&view=rev Log:
> >>> Review thread-safety Document locking strategy Fix a few
> >>> issues: - Iterators could throw
> >>> ConcurrentModificationException - Syncs on open/save didn't
> >>> lock roles Map Update with a view to supporting runtime
> >>> reloading (BZ 58590)
> >>>
> >>
> >> This user db stuff was introduced in 4.1 and was never really
> >> updated since, nor were other implementations done. It survived
> >> because of the manager/jmx management it had. Do you think it
> >> would be useful to take it somewhere now, or is this only for
> >> 58590 ?
> >
> > My primary motivation is 58590. I've lost track of the number of
> > times I've started Tomcat do test something, only to have to
> > restart it to pickup changes to tomcat-users.xml. Of course, fixing
> > that means reloading has to be enabled by default. I think that is
> > OK but what does everyone else think?
>
> Having to bounce the app server to adjust the authentication database
> is really bad IMHO. Auto-reload isn't necessary, but the fact that a
> reload is POSSIBLE is nice. Triggering re-loading via JMX would be
> sufficient for me.

Implementing auto-reloading has a caveat: there is a race condition
between an editor (that is used to update the file) and Tomcat. It may
be that Tomcat will try to read an incompletely written file.

Also using a SAX parser + Digester, it does not check whether the XML
file is well-formed beforehand. It stops on the first encountered
error, but side effect from whatever methods it has called thus far
will be visible.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to