Log queries with 5.0.0

[natros]

With querydsl-sql 4.4.0 I was using <logger name="com.querydsl" level="DEBUG"/> in logback.xml to log the queries. This is not working with 5.0.0. What am i missing?.

[natros]

After some search, I came up with this dependency org.slf4j:jul-to-slf4j:1.7.32

I add a contextListener to logback.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true">
  <contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
    <resetJUL>true</resetJUL>
  </contextListener>
...

and to my main class

  static {
    SLF4JBridgeHandler.removeHandlersForRootLogger();
    SLF4JBridgeHandler.install();
  }

If there is a better way, I would like to know.

[jwgmeligmeyling]

Yes, this is the appropriate solution.

A very common community request was to not rely on any third party dependencies. So besides Guava, Jsr305, Joda, that also meant Slf4j.

Jul can easily be bridged to Slf4j using the mentioned method. When deploying to an application server, these bridges are likely already in place (for example jboss logging).

Also, JPA users are likely to prefer the ORM log statements over the one from Querydsl.

[natros]

Too bad slf4j was removed. I agree with the other dependencies removed, but not with slf4j.

As I said at the beginning, I use querysl-sql and not querydsl-jpa. Also, I don't use any application server.

I need to log the queries during the development to copy the SQL and test the query in the database to get the execution plan and make adjustments.

According to jul-to-slf4j

j.u.l. to SLF4J translation can seriously increase the cost of disabled logging statements (60 fold or 6000%) and measurably impact the performance of enabled log statements (20% overall increase)

but as I don't use it in production, it won't be a problem.

[jwgmeligmeyling]

I doubt logging a single line for each executed query poses any significant performance impact over the query execution plan 😉

Slf4j provides a more fluent API for creating parameterized log statements (which are also relatively fast). Whenever parameterization is not used heavily, the performance gain is marginal, at the cost of adding a dependency and potential version conflicts with other dependencies or the final application. Its just not really justifyable for the amount of logging we do.

[hostalp]

Reviving an older thread.

I find the use of JUL quite unfortunate.
Application servers such as WebSphere use JUL themselves for their own logging purposes. When one wants to use a completely separate application logging, there are issues due to the fact that JUL is configured JVM-wide. Messing with it at the application level would affect the server logging as well, which is undesired.

With just 1 application you can try to add your own JUL handler and then use it with some filter to separate events coming from some classes/packages (loggers), but add more applications (running in the same JVM) to the mix and the problem can easily become pretty much impossible to solve effectively.

With more advanced logging frameworks you can at least have a classloader separation. Not here. :-(

[jwgmeligmeyling]

Going from our issue tracker, people running multiple application in a single JVM these days are outnumbered by the folks liking a dependency on SLF4J forced on to them.

[hostalp]

Well, multiple applications are just one scenario. It's problem even with just 1 application - the only difference here is that it could be partially worked around with a filter.