Starting WebLogic Server (10.3/11gR1) in debug mode

This is a mere note.
When starting WebLogic Server using the startWebLogic script, the JDWP options for starting the server can be enabled, by setting the 'debugFlag' environment variable to true.

The startWebLogic script examines the value of this environment variable to add the remote debugging flags to the JVM that it initializes.

Resolving the warning "Incorrect @Resource annotation class definition - missing lookup attribute" thrown by embedded Glassfish 3.1

Running code in embedded Glassfish, where one uses the @Resource annotation, is quite a roller coaster. It is very typical to find the messages like the following, in the embedded Glassfish logs on running unit-tests deployed onto the embedded container from Glassfish: The solution to this is rather straightforward: one would need to add the Java EE 6 version of the @Resource annotation, instead of relying on the Java SE 6 provided class. Java EE 6 added the lookup attribute to the annotation. Quite obviously, annotation processing performed during execution of unit-tests in Java SE 6 would fail for this particular attribute, as the JDK simply lacks this new class. If you are running your tests using the Surefire plugin, you will need to configure the plugin to add the Java EE 6 jar containing the new class as an endorsed directory. Apparently, this is the approach adopted by Glassfish, where in the modules/endorsed directory under the Glassfish install root, is added as a Java endorsed library directory at startup. The same configuration, can be carried over to Surefire in the following manner: The org.glassfish:javax.annotation:3.1 dependency is from Glassfish 3.1.1 (build 12), and contains the Java EE 6 version of the Resource annotation. You may need to modify the version of this dependency, to suit your environment. Note, that the directory containing the dependency is located in the local Maven repository. Also, you could perform similar changes to other Maven plugins that require the location of the JAR as a Java endorsed library directory, during JVM startup.

Starting Glassfish 3.1 in debug mode using the Glassfish Maven plugin

I am documenting this for the sake of posterity. The Maven Glassfish plugin allows for starting and stopping Glassfish domains using Maven goals, apart from allowing for deployment, re-deployment and undeployment of applications.

Until now, I never found the need to start Glassfish in the debug mode, thanks to the unit tests that I've been writing. However there are those times where remote debugging does help. Starting Glassfish in the debug mode using the Maven plugin is quite easy, especially if one has already created a domain. All one needs to do is to create a separate Maven profile to start Glassfish in the debug mode; specifying the debug parameter in the start-domain goal is sufficient to start Glassfish in the debug mode, for Glassfish enables JDWP using the options specified in the Glassfish domain configuration file.

My Glassfish domain configuration file had the following debug-options attribute to enable remote debugging, and to allow for remote debuggers to connect onto port 9009:



Getting Glassfish to start in the debug mode from the maven plugin required passing in the true parameter, which automatically resulted in the debug options being used to start Glassfish. Under the hood, the asadmin start-domain command is executed with the --debug=true option which eventually results in Glassfish starting in the debug mode. Following is the snippet from my Maven POM file, containing the relevant configuration:



Note line 28 which triggers the debug mode and gets Glassfish to use the JDWP options. Apparently, the Maven Glassfish plugin also supports this curiously named "jvmOptions" parameter. This parameter is ignored for all practical purposes when starting a domain. In reality, it is used in the limited scenario of creating a new domain; the Maven Glassfish plugin uses the jvmOptions parameter to create a jvmOption for a domain in domain.xml; under the hood, the plugin executes the "asadmin create-jvm-options ..." command with the parameters to the create-jvm-options command being constructed from the jvmOptions parameter in the Maven POM.

Using the previously created Maven profile to start Glassfish is quite easy:



will do the needful activity of using the defined Maven profile.

Configure Hibernate logging on Glassfish with SLF4J

Glassfish 3.1 ships with EclipseLink as the default JPA provider. One can, however, install Hibernate 3.5 using the Glassfish Update Tool, which is the easiest means of installing Hibernate on Glassfish. The installation also installs the SLF4J-JDK14 wrapper, that will enable all SLF4J logging calls to be redirected to the java.util.logging logging implementation used by Glassfish. One would, therefore, find that SLF4J calls would be transparently redirected to the Glassfish domain log, without a lot of configuration.

In order to configure logging for Hibernate on Glassfish, the JDK logger configuration in the logging.properties file of the Glassfish domain must be modified, to include any desired configuration changes. Simply put, one need not install log4j and the slf4j-log4j12 module in Glassfish and also provide log4j.properties to get Hibernate logging to work.

The following lines were added in the logging.properties file of the Glassfish domain (usually located in $GLASSFISH_DOMAIN/config) to enable various loggers created by to provide a more verbose output:



To understand how those entries work, it is sufficient to understand that Hibernate uses SLF4J as a logging facade, delegating the actual writing of the log records to an underlying logger like log4j, logback or the JDK logger. Glassfish uses the JDK logger as the logging implementation, and to enable the calls on the SLF4J logger, to create entries in the Glassfish domain logs, one must have the SLF4J-JDK14 module (slf4j-jdk14-x.y.z.jar) installed in the classpath. The SLF4J-JDK14 module serves to adapt all SLF4J method calls to the JDK Logger interface, allowing any application (in this case, Hibernate) using SLF4J to have the log records written by the JDK logger. The adapter transforms the levels used by SLF4J to the ones known to the JDK logger as follows:

SLF4J Level	JDK Logger Level
TRACE	FINEST
DEBUG	FINE
INFO	INFO
WARN	WARNING
ERROR	SEVERE

By inference, an invocation within Hibernate using Logger.trace() would be logged only if the JDK logger was configured to log messages at the FINEST level.