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-optionsattribute 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
parameter, which automatically resulted in the debug options being used to start Glassfish. Under the hood, the
asadmin start-domaincommand is executed with the
--debug=trueoption 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.