]
Hontvári József commented on HHH-722:
-------------------------------------
I receive such a warning and error every 10 seconds (duplicate key exceptions, we have
about 2 million users, of course they often try to register on an existing name). And I
can of course supress any JDBCExceptionReporter but it is not really comfortable to
disable something which I cannot know when and where will be used. Likely this class
shoud log on debug level, not on error and warning.
JDBCExceptionReporter should use different logger for warnings
--------------------------------------------------------------
Key: HHH-722
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-722
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.0 alpha, 3.0 beta 1, 3.0 beta 2, 3.0 beta 3, 3.0 beta 4, 3.0 rc 1,
3.0 final, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5
Environment: All
Reporter: Martin Bromley
Priority: Minor
The org.hibernate.util.JDBCExceptionReporter class currently logs both SQLExceptions and
SQLWarnings. These should use separate loggers for the following reasons:
- SQLExceptions are rethrown after they have been logged by JDBCExceptionReporter.
- Code using Hibernate may log the SQLExceptions itself, and so may want to disable
Hibernate's logging of them to avoid duplication. This would most easily be achieved
by setting JDBCExceptionReporter log level to fatal or off.
- There are legitimate reasons why SQLExceptions could be thrown in normal operation of
an application (e.g. trying to insert a unique email address when somebody has already
registered it - detecting a duplicate by catching an exception may be preferable to doing
an explicit find before insert). In many circumstances the application would want to
handle such an exception, and decide whether or not it should be logged, and at what
level.
- SQLWarnings are logged at warn level (appropriately), so disabling Hibernate's
logging of SQLExceptions also disables the logging of SQLWarnings.
- An application may want to know about SQLWarnings (i.e. would want them to be logged),
whereas for the reasons described above, may not want Hibernate to log SQLExceptions.
Refactoring JDBCExceptionReporter into JDBCExceptionReporter and JDBCWarningReporter
might be the simplest and neatest solution to this. Then the logging configuration can
easily be configured to disable Hibernate's JDBCException logging without preventing
SQLWarnings from being logged.
Alternatively the JDBCExceptionReporter could contain another logger with the name
JDBCExceptionReporter.class.getName() + ".warnings", so that any existing log
configurations that disable both wouldn't be affected (or any non-Hibernate code that
uses JDBCExceptionReporter for some strange reason...).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: