Sunday Apr 17, 2005

Remote Debugging from NetBeans IDE 4.1 to JBoss

Yes, NetBeans IDE can follow you everywhere. The only thing it can't do is your laundry (believe me, I've tried). So even though you've deployed to servers that the IDE doesn't "officially" support, such as JBoss (or Tomcat 4 or JRun4), not only can you start them, stop them, and deploy to them from within the IDE (as explained in previous blog entries), but you can also use the NetBeans IDE debugger to step through the source code on the server.

Here's what I did to get it all working:

  1. Create a target to build the application to the server's deployment directory. (One disadvantage of an IDE is that when you're just using menu items to do things like 'Build', you don't need to know what's really going on. Now, with Ant, you have to know, because otherwise you can't tell Ant what you want it to do.) This is the script that I've been using:

     <target name="aaa_Build-To-JBoss" description="Build to JBoss">
    
         <mkdir dir="${build.dir.jboss}/WEB-INF/classes"/>
         <javac srcdir="${src.root}"
                   destdir="${build.dir.jboss}/WEB-INF/classes"
                   debug="on"
                   deprecation="${compile.deprecation}"
                   optimize="${compile.optimize}">
             <classpath>
                <path path="C:\\nb41\\netbeans\\enterprise1\\jakarta-tomcat-5.5.7\\common\\lib\\servlet-api.jar"/>
             </classpath>
         </javac>
    
         <copy  todir="${build.dir.jboss}/WEB-INF/classes">
          <fileset dir="${src.root}" excludes="${build.classes.excludes.jboss}"/>
         </copy>
     
         <copy todir="${build.web.dir.jboss}">
            <fileset dir="${web.root}" excludes="${build.web.excludes.jboss}" />
         </copy>
    
     </target>

    (You will need to copy more <filesets> if you have a more complex application with libraries, web services, etc. However, note that I've discovered a much more efficient way of doing this. Click here for details.)

    Note: What's very very very important in the target above is the debug setting. Without it, debug information is not generated and, even though the NetBeans IDE debugger will be happily attached to the server, it will not be able to do anything with your Java code. (I've hard-coded it above, but will change it to a property later.)

    Here are the properties referenced above:

    build.dir.jboss=C:/jboss/jboss-4.0.1sp1/server/default/deploy/${ant.project.name}.war
    build.classes.dir.jboss=${build.dir.jboss}/WEB-INF/classes
    build.classes.excludes.jboss=\*\*/\*.java,\*\*/\*.form
    build.web.dir.jboss=${build.dir.jboss}
    build.web.excludes.jboss=${build.classes.excludes.jboss}
    build.lib.dir.jboss=${build.dir.jboss}/WEB-INF/lib
    src.root=src/java
    web.root=web
    compile.deprecation="off"
    compile.optimize="on"

    Note: Make sure that you specify a ".war" extension for the build.dir.jboss property, as specified above. Without it (or, I guess, an extension such as ".ear"), JBoss doesn't deploy the application.

    To round off this step, go to JBoss's deployment directory (see build.dir.jboss above) and make sure that your application is really there (you could, of course, simply have copied your application to a directory with the project's name, suffixed with .war, within the deployment directory, but if you create a target to do it all for you, together with a menu item to invoke the target, all that manual copying and pasting becomes obsolete and you can rely on the security of knowing you're deploying correctly every time):

    If your application's there (also check that your compiled classes are there), you're good to go, because the server automatically deploys your application for you.

  2. Make sure that you like JBoss's port number. The default port number is 8080. This may conflict with other port numbers (especially if you have been playing with multiple servers). Therefore, go here in the JBoss installation directory and take a look:

    C:\\jboss\\jboss-4.0.1sp1\\server\\default\\deploy\\jbossweb-tomcat50.sar\\server.xml

    Just search for "8080" in the file and change it to something else. (Mine is set to 8090.)

  3. Now create a script to start JBoss in debug mode:

      <target name="RunJBoss-Debug-Mode">
        <exec executable="C:\\jboss\\jboss-4.0.1sp1\\bin\\run.bat">
          <env key="JAVA_OPTS" value="-Xrunjdwp:transport=dt_socket,server=y,address=12999,suspend=n" />
        </exec>
      </target>

    (If you don't know what's going on with the value of JAVA_OPTS above, you need to read up about the Java Platform Debugger Architecture - JPDA Connection and Invocation.)

    But don't stop there! Add a menu item (explained in previous blog entries) so that you can truly integrate JBoss into the IDE:

    When you run this target, you'll see this line near the top of the Output window:

    JAVA_OPTS: -Xrunjdwp:transport=dt_socket,server=y,address=12999,suspend=n -Dprogram.name=run.bat -Xms128m -Xmx512m
    Much further down, you'll see the server's port number:

    14:47:41,375 INFO  [Http11Protocol] Initializing Coyote HTTP/1.1 on http-0.0.0.0-8090
  4. Deploy the application, using the target below. All that this really means is that the IDE opens a browser, finds the port number, and displays the application called ${ant.project.name}, which is the IDE project's name in the project.xml file.

      <target name="aaa_Deploy-To-JBoss" description="Deploy to JBoss">
        <nbbrowse url="http://localhost:8090/${ant.project.name}"/>
      </target>
  5. In the IDE, choose Run > Attach Debugger. Set the following values:

    Click OK. You should now see the following in the IDE's Debugger Console:

    Attaching to localhost:12999
    User program running
  6. Set breakpoints in, for example, a Java class.
  7. Take a deep breath -- this is where it all comes together! Go back to the browser, refresh it, and do something to access the class. For example, I've been using a very simple test application that you can create using instructions provided here. When you build this application to the JBoss deployment directory, set breakpoints in NameHandler.java, and then click OK in the deployed index.jsp, you access response.jsp, which in turn makes use of NameHandler.java. When you access this file, or any file where the breakpoints have been set, the NetBeans IDE icon at the bottom of the screen will begin flashing (at least, this is true on Windows XP) and, when you go back to the IDE, you will see a green line on your breakpoint. Now use the debugger as you would do with any other application -- step into, over, set watches, etc. Click here for a nice introduction to the NetBeans IDE debugger.

The above instructions should be equally applicable to other servers, of course, such as Tomcat 4 and JRun4. You will need to tweak a few things here and there (such as specifying the deployment directory for the server of your choice and starting up the server correctly in debug mode), but everything here should basically work anywhere else too.

Deploy to JBoss4, Tomcat 4, JRun4... Debug from NetBeans IDE 4.1!

Yes, NetBeans IDE can follow you everywhere. The only thing it can't do is your laundry (believe me, I've tried). So even though you've deployed to servers that the IDE doesn't "officially" support (such as JBoss4, Tomcat 4 and JRun4), not only can you deploy to them from within the IDE (as explained in previous blog entries), but you can also use the NetBeans IDE debugger to step through the source code on the server.

Here's what I did to get it all working:

  1. Build the application to the server's deployment directory. (One disadvantage of an IDE is that when you're just using menu items to do things like 'Build', you don't need to know what's really going on. As a result, you don't know. Now, with Ant, you have to know, because otherwise you can't tell Ant what you want it to do.) This is the script that I've been using:
     <target name="aaa_Build-To-JBoss" description="Build to JBoss">
         <mkdir dir="${build.dir.jboss}/WEB-INF/classes"/>
         <javac srcdir="${src.root}"
                   destdir="${build.dir.jboss}/WEB-INF/classes"
                   debug="on"
                   deprecation="${compile.deprecation}"
                   optimize="${compile.optimize}">
             <classpath>
                <path path="C:\\nb41\\netbeans\\enterprise1\\jakarta-tomcat-5.5.7\\common\\lib\\servlet-api.jar"/>
             </classpath>
         </javac>
    
         <copy  todir="${build.dir.jboss}/WEB-INF/classes">
          <fileset dir="${src.root}" excludes="${build.classes.excludes.jboss}"/>
         </copy>
     
         <copy todir="${build.web.dir.jboss}">
            <fileset dir="${web.root}" excludes="${build.web.excludes.jboss}" />
         </copy>
     </target>

    What's very important is the debug setting. Without it, debug information is not generated and, even though the NetBeans IDE debugger will be happily attached to the server, it will not be able to do anything with your code. (I've hard-coded it above, but will change it to a property later.)

    Here are the properties referenced above:

    build.dir.jboss=C:/jboss/jboss-4.0.1sp1/server/default/deploy/${ant.project.name}
    build.classes.dir.jboss=${build.dir.jboss}/WEB-INF/classes
    build.classes.excludes.jboss=\*\*/\*.java,\*\*/\*.form
    build.web.dir.jboss=${build.dir.jboss}
    build.web.excludes.jboss=${build.classes.excludes.jboss}
    build.lib.dir.jboss=${build.dir.jboss}/WEB-INF/lib
    src.root=src/java web.root=web compile.deprecation="off" compile.optimize="on"

    To round off this step, go to JBoss's deployment directory and make sure that your application is really there. (If it's there, it's good to go, because the server automatically deploys it for you.

About

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.

Search

Archives
« April 2005 »
SunMonTueWedThuFriSat
     
1
2
8
9
10
14
16
18
22
23
29
       
Today