Java 9 adds Yet Another Logging framework (YAL)

Java 9 and JEP 264 addresses a gaping whole in the Java ecosystem: the lack of logging frameworks and abstractions. Finally there is a logging API built into the platform for those who don’t like the other logging API already built into the platform!

The java.util.logging option is commonly referred to as JUL. Why not call the new one YAL?

Most Java EE applications these days ship with third-party components that use JUL, SLF4J, commons.logging, Log4j and quite probably several additional frameworks for good measure. Unified logging is by no means trivial. It is a mess and with YAL we have one more framework and probably several additional adapters.

I can see the need to isolate the core classes from JUL, but I’m still not convinced that this is what Java needs. Why not spend more time on my pet feature, value types, instead?

Enable JCA resource adapter statistics in JBoss EAP 6

Performance tuning is guesswork without good instrumentation. Knowing the bottleneck is at least half the battle. Thus it is always nice to graph connection pool statistics for databases and resource adapters. With EAP 6, statistics can be enabled in the connection-definition element, for example:

<connection-definition
      class-name="org.apache.activemq.ra.ActiveMQManagedConnectionFactory"
      jndi-name="java:/QCF" enabled="true" pool-name="QCF"
      statistics-enabled="true"
      >

Unfortunately it doesn’t work, most metrics (such as InUseCount) are reported as 0. Why? Apparently this is a bug that has been fixed in EAP 7. However, for 6.4.8+ statistics can be enabled by setting the system property -Dorg.jboss.as.connector.deployers.ra.enablePoolStatistics=true. Do it now…

Read the Oracle alert log using SQL

In 11g (yes, that was ages ago) Oracle added x$dbgalertext, making it possible to query the alert log using SQL. For people like me who work close to the database, but often without true DBA access and seldom with access to the physical servers, that is a godsend. Being able to see the alerts without asking really helps. For example, to get all the reported ORA errors for the last hour:

select originating_timestamp, message_text
  from x$dbgalertext
  where originating_timestamp > sysdate - 1/24
  and message_text like '%ORA-%'
  order by originating_timestamp desc;

Talking a DBA into granting select is much easier than getting access to the server.