Unfortunately, I don't think it's possible to see the full query from Hibernate - I believe you have to log at the database or driver level.
You might try P6Spy: http://www.p6spy.com/ Matt On 12/11/07, Rob Hills <[EMAIL PROTECTED]> wrote: > Hi All, > > Rob Hills wrote: > > Dale Newfield wrote: > >> Matt Raible wrote: > >>> log4j.properties is AppFuse 1.9.x specific. In 2.0, it's > >>> src/main/resources/log4j.xml. > >> So while it couldn't hurt, apparently it won't help, either. > >> > >> Not sure why your changes to log4j.xml are not working. Are your > >> changes making into your deployed app in the right place? > > Yes, they are. I initially tried editing them within the deployed > > application (running Tomcat so I'd restart it after making an edit). > > I can turn SQL logging on and off with the org.hibernate.SQL logger > > setting, but I can't get parameter values to appear. > This gets weirder. I've tried turning up logging for all of Hibernate via: > > <logger name="org.hibernate"> > <level value="DEBUG"/> > </logger> > > With this set, the volume of my logging goes up enormously, but I STILL > don't get any SQL parameter values. > > I've been through the the log4j.xml file with a fine-tooth comb to make > sure I'm not setting the same thing in two different places, but nothing > there. > > Is there somewhere else in my project (AppFuse 2.0 + Hibernate + > Struts2) that I could be somehow overriding this setting? I've not > hard-coded anything and my hibernate.cfg.xml file is clean, so those two > possibilities that I'm aware seem to be out of the picture. There's > only one copy of log4j.xml in my deployed app and I've even looked > inside the log4j jar file - no settings in there that I could find (but > if there were, that would be affecting everybody). > > I have "hibernate.show_sql" set to true in my profile, but I wouldn't > have thought that would make any difference. To be honest, I'm not sure > why the "hibernate.show_sql" setting doesn't control both the sql and > the parameter values. To me it seems logical to group those two > together (or at least provide another pom-level configuration parameter > to control display of parameter values). > > This is very frustrating - I have a problem with a query based on dates > that I think is a timezone issue, but I can't confirm it because I can't > see what's being fed to the db :-( > > Cheers, > > Rob Hills > Waikiki, Western Australia > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
