Thursday, February 05, 2009
How to get Hibernate parameter bindings and ONLY parameter bindings
Let me preface this by saying that Hibernate is a gimpy pile of steaming mule shit.
With that out of the way, if you search around with Google and look for information on how to get the parameter bindings for SQL statements executed by Hibernate (which brilliantly are not given if you turn on SQL logging; see also: "mule shit"), you'll see a lot of smartass answers like setting
While that configuration change does include the parameter bindings, it also includes a giant shit-pile (mule) of extra data that you probably couldn't possibly care less about, including every time Hibernate binds a return value to a type. These different messages cannot be immediately differentiated by severity or by type (see also: "gimpy").
There is a mostly-workable solution, provided Hibernate has implemented/continues to implement their debugging messages in a consistent fashion:
This filters the log4j output of org.hibernate.type.*, including only the lines that contain the text " to parameter: ". This will of course also include constants coming back from your database that include the phrase " to parameter: ", but chances are this will usually be good enough, unless or until Hibernate pries its overinflated head out of its ass.
With that out of the way, if you search around with Google and look for information on how to get the parameter bindings for SQL statements executed by Hibernate (which brilliantly are not given if you turn on SQL logging; see also: "mule shit"), you'll see a lot of smartass answers like setting
org.hibernate.types=debug in your log4j configuration.While that configuration change does include the parameter bindings, it also includes a giant shit-pile (mule) of extra data that you probably couldn't possibly care less about, including every time Hibernate binds a return value to a type. These different messages cannot be immediately differentiated by severity or by type (see also: "gimpy").
There is a mostly-workable solution, provided Hibernate has implemented/continues to implement their debugging messages in a consistent fashion:
<appender name="SQLparams" class="org.apache.log4j.ConsoleAppender">
<param name="Target" value="System.out"/>
<param name="Threshold" value="TRACE"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p [%c] - %m%n"/>
</layout>
<filter class="org.apache.log4j.varia.StringMatchFilter">
<param name="StringToMatch" value=" to parameter: " />
<param name="AcceptOnMatch" value="true" />
</filter>
<filter class="org.apache.log4j.varia.DenyAllFilter" />
</appender>
<category name="org.hibernate.type">
<priority value="TRACE"/>
<appender-ref ref="SQLparams" />
</category>
This filters the log4j output of org.hibernate.type.*, including only the lines that contain the text " to parameter: ". This will of course also include constants coming back from your database that include the phrase " to parameter: ", but chances are this will usually be good enough, unless or until Hibernate pries its overinflated head out of its ass.
Labels: hate, log4j, open source, shitware
Thursday, April 26, 2007
Missing Logging in Wicket
Last night, the first early release of Tally-Ho hit morons.org. As one might expect, a few small problems turned up at the last minute, and most of these have been worked through. One of them was a strange Internal Error message, but there was no exception in my log file. It was getting late, and I was getting tired, so I fired off a message to the Wicket-Users list to see if anybody had advice.
The problem turned out to be that although my development container is Tomcat, which uses log4j for its logging and consequently configures a log4j root logger and appender, my deployment container is Resin Opensource, which does not.
The answer was to create a log4j.properties file in src/main/resources (so it is automatically included in the .war by Maven 2) with this in it:
Now my logging goes to stdout and is happily recorded by Resin.
Now if I could just get somewhere with WICKET-506.
The problem turned out to be that although my development container is Tomcat, which uses log4j for its logging and consequently configures a log4j root logger and appender, my deployment container is Resin Opensource, which does not.
The answer was to create a log4j.properties file in src/main/resources (so it is automatically included in the .war by Maven 2) with this in it:
log4j.rootLogger=WARN, stdout
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c - %m%n
log4j.category.wicket=INFO
log4j.category.resource=INFO
log4j.category.wicket.protocol.http.RequestLogger=INFO
log4j.category.wicket.protocol.http.WicketServlet=INFO
Now my logging goes to stdout and is happily recorded by Resin.
Now if I could just get somewhere with WICKET-506.
Labels: log4j, resin, software, wicket
Subscribe to Posts [Atom]
