Setting org.hibernate.type logging to debug produces no logging
Description
Activity
Vlad MihalceaOctober 10, 2016 at 8:47 AM
No longer relevant since the latest User Guide covers this topic.
Steve EbersoleOctober 28, 2015 at 3:24 AM
As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.
Steve EbersoleOctober 27, 2015 at 7:15 PM
This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.
For details, see http://in.relation.to/2015/10/27/great-jira-cleanup-2015/
E McLainMay 14, 2009 at 10:06 PM
> 1. Put something into the debug log at the time this decision is made, perhaps:
It occurs to me that since the application hasn't configured its log yet, this might get lost. It should probably go to stdout or stderr as well.
E McLainMay 14, 2009 at 9:51 PM
The likely problem is that the code Steve refers to above is executed only when the NullableType class is initialized (which happens as soon as Hibernate is configured). If the application hasn't configured its log by the time that happens, there are no further opportunities to do so, and NullableType will ignore any changes to log configuration after that.
I am most interested in bind parameters when debugging unit test failures. I was able to have them logged by putting this in the base test case class:
static {
// initialize log4j with the test params
PropertyConfigurator.configure("/path/to/log4j.properties");
}
This isn't a great user experience. I think the Hibernate maintainers should:
1. Put something into the debug log at the time this decision is made, perhaps:
"DEBUG [main] org.hibernate.type (NullableType.java:59) - Tracing of bind parameters and selected values will be DISABLED based on the current value of getLogger("org.hibernate.type").isTraceEnabled()."
2. Consider delaying this read until it is actually needed... perhaps the first time a session is opened, or something like that.
According to the online documentation (labeled as version 3.2.2 at this moment), Table 3.9 "Hibernate Log Categories", as viewed here today:
http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configuration.html#configuration-logging
Setting the log4j category "org.hibernate.type" to debug should "Log all JDBC parameters". However, it produces no output at all.
When I go on to set "org.hibernate" to debug, I get output like this:
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
DEBUG: org.hibernate.SQL - select count from album where genreID=?
DEBUG: org.hibernate.loader.Loader - bindNamedParameters() 126 -> genreId [1]
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open ResultSet (open ResultSets: 0, globally: 0)
DEBUG: org.hibernate.loader.Loader - result row:
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close ResultSet (open ResultSets: 1, globally: 1)
DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
Note that the JDBC parameters are logged under org.hibernate.loader but nothing appears under org.hibernate.type. FYI, genreId is, in this case, a Long.
Perhaps this is expected/desired when using annotations? If so, then please update the documentation. If not, please restore the logging.