使用ORM從您的特定數據庫中提取數據，并讓它創建和發布您必須親自編寫的所有SQL語句似乎很方便。 這就是使ORM解決方案受歡迎的原因。

但是它也有一個缺點：由于ORM為您做了很多工作，因此您在某種程度上失去了對生成的SQL的控制，您不得不依靠ORM為您創建高性能的語句。 但是有可能發生的是，ORM生成的SQL可能不是您手工編寫的，并期望ORM為您完成。 在這種情況下，您必須恢復對SQL的控制，然后再次使用代碼。

在大型應用程序中，此任務并非那么瑣碎，因為可能有數百條語句發布到數據庫，這些語句源于數百行Java代碼，這些代碼大量使用了JPA功能。 跟蹤數據庫分析工具已確定為有問題的SQL語句，直到實際的代碼行變得乏味。

我們知道我們可以在persistence.xml中使用以下兩行來為Hibernate啟用SQL語句日志記錄：

<property name="hibernate.show_sql" value="true"/> <property name="hibernate.format_sql" value="true"/>

但是，這只會輸出已經生成的SQL。 實際的Java代碼行仍然不可見。 對于較小的應用程序，將調試器附加到應用程序服務器并通過代碼進行調試，直到找到記錄有問題的SQL語句的行，這可能是可行的，但是對于較大的應用程序，這很費時間。

由于Hibernate本身不提供任何攔截日志記錄的方法，并提供了更多信息來增強日志記錄，因此我們將不得不自行完成此操作。 JBoss 文檔指出可以編寫自己的自定義日志記錄處理程序。 由于此日志記錄處理程序接收到所有日志記錄消息，并且消息還包含啟用了SQL日志記錄的Hibernate生成的消息，因此我們可以嘗試找到我們要查找的行，然后將堆棧跟蹤輸出到我們自己的日志文件中。

編寫自定義日志記錄處理程序非常簡單。 您所要做的就是設置一個小項目，該類帶有一個類，該類擴展了JDK包java.util.logging中的Handler類：

package mypackage;import java.util.logging.Handler; import java.util.logging.LogRecord;public class MyJBossLogger extends Handler {@Overridepublic void publish(LogRecord record) {}@Overridepublic void flush() {}@Overridepublic void close() throws SecurityException {} }

publish（）方法以LogRecord實例的形式接收所有日志記錄輸出。 它的方法getMessage（）使我們可以直接訪問輸出。 因此，我們可以將此消息與從某些配置文件中加載的某些關鍵字進行匹配：

@Override public void publish(LogRecord record) {String message = record.getMessage();buffer.add(message + "\n");if (keywords == null) {keywords = loadKeywords();}if (matches(message, keywords)) {String stacktrace = "\nStacktrace:\n";StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();for (StackTraceElement element : stackTrace) {stacktrace += element.toString() + "\n";}buffer.add(stacktrace);flush();} }

這里的Buffer是一些簡單的數據結構（例如guava的EvictingQueue ），用于緩沖最后幾行，因為對輸出的每一行（！）都會調用publish（）方法。 由于一條完整的SQL語句跨越多行，因此我們必須記住其中的幾條。 在緩沖行和當前行旁邊，我們還輸出當前堆棧跟蹤的字符串表示形式。 稍后，這將在日志文件中告訴我們調用該文件的位置以及項目中哪一行Java代碼導致當前語句。

編譯完項目后，我們可以將生成的jar文件復制到新創建的文件夾結構下：$ JBOSS_HOME / modules / system / layers / base / com / mydomain / mymodule / main（對于JBoss AS 7.2）。 為了向JBoss AS告知我們的新模塊，我們必須創建一個名為module.xml的XML文件，其內容如下：

<?xml version="1.0" encoding="UTF-8"?> <module xmlns="urn:jboss:module:1.1" name="com.mydomain.mymodule"><resources><resource-root path="MyJBossLogger-0.0.1-SNAPSHOT.jar"/></resources> </module>

模塊的名稱與JBoss modules文件夾中的路徑相對應。 它還將在配置文件中用于配置我們的自定義日志記錄處理程序：

... <subsystem xmlns="urn:jboss:domain:logging:1.2"><custom-handler name="CUSTOM" module="com.mydomain.mymodule" class="com.mydomain.mymodule.MyJBossLogger"><level name="DEBUG"/></custom-handler>...

當我們實現日志記錄處理程序的flush（）方法以將輸出寫入某些日志文件時，我們將看到類似以下內容（當然是壓縮形式）：

Hibernate: select ... from customer ... Stacktrace: java.lang.Thread.getStackTrace(Thread.java:1568) com.mydomain.mymodule.MyJBossLogger.publish(MyJBossLogger.java:20) org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:292) org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:300) org.jboss.logmanager.Logger.logRaw(Logger.java:721) org.jboss.logmanager.Logger.log(Logger.java:506) ... com.mydomain.myapp.ArticleEntity.getCustomers(ArticleRepository.java:234) ...

在這里，我們可以清楚地看到哪個OneToMany關系導致了我們正在尋找的有問題的選擇語句。

結論

當您想在源代碼中找到發出具體查詢的確切位置時，使用自定義日志記錄處理程序將當前堆棧跟蹤注入到SQL語句的日志記錄中可能會有所幫助。 事實證明，為JBoss AS編寫自己的自定義日志記錄處理程序也是一項直接的任務。

翻譯自: https://www.javacodegeeks.com/2014/07/tracing-sql-statements-in-jboss-as-7-using-a-custom-logging-handler.html

總結

以上是生活随笔為你收集整理的使用自定义日志记录处理程序在JBoss AS 7中跟踪SQL语句的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。