>The best thing is probably to entirely remove the message from the >exception/logs and replace it with a text that explains how to find the >conflict information (i.e. in the transient space).
Not sure if that is always possible easily. As at times there are multiple layers involved and a user does not have access to the actual session. If the information is somehow available via logs it is far more accessible. So would turn it to a debug level log. regards Chetan Chetan Mehrotra On Thu, Sep 12, 2013 at 1:01 PM, Marcel Reutegger <[email protected]> wrote: > Hi, > > I would turn the log into a debug message, because it can be very confusing. > conflicts happen during regular repository usage and shouldn't log warnings. > if needed one could still enable debug logging to get more information on > what happens during a conflict. > > regards > marcel > >> -----Original Message----- >> From: Michael Dürig [mailto:[email protected]] >> Sent: Donnerstag, 12. September 2013 09:15 >> To: [email protected] >> Subject: Re: Providing details with CommitFailedException and security >> considerations >> >> >> Hi Chetan, >> >> The best thing is probably to entirely remove the message from the >> exception/logs and replace it with a text that explains how to find the >> conflict information (i.e. in the transient space). >> >> Michael >> >> On 12.9.13 6:56 , Chetan Mehrotra wrote: >> > Hi, >> > >> > As part of OAK-943 I had updated the ConflictValidator [1] to more >> > more details around Commit Failure. However exposing such details as >> > part of exception was considered risky from security aspect and it was >> > decided to log a warning instead. >> > >> > Now in some cases the upper layer do expect a CommitFailedException >> > have required logic to retry the commit in case of failure. In such >> > cases these warning logs cause confusion. >> > >> > So not sure what is the best thing to do. Should I turn the log to >> > debug level or make details part of exception message? >> > >> > Making it part of warn level would cause issue as such situations a >> > not very repetative and users typically run system at INFO level. >> > >> > If I make it part of exception message is then max it would expose >> > presence of some property names (not there values). And in most cases >> > the exception is not exposed to end user and is logged to system logs. >> > So probably we can make it part of exception message itself >> > >> > >> > [1] https://github.com/apache/jackrabbit-oak/blob/trunk/oak- >> core/src/main/java/org/apache/jackrabbit/oak/plugins/commit/ConflictValid >> ator.java#L90 >> > >> > Chetan Mehrotra >> > >
