Debug JBoss with Eclipse

I found a need to debug JBoss with Eclipse. A search on google led me to ths page. I had to tweak a bit to get my local instance to work.

For example, I had to change the quote character from ” to “.

JAVA_OPTS="-Xdebug -Xnoagent
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n $JAVA_OPTS"

After that, JBOSS was able to load the new parameters correctly.

The post also have slightly different UI screen than what I see on my version of Eclipse. I did the following:

  1. Go to Run –> Debug Configurations … in the menu
  2. Rick click on Remote Java Application and choose New
  3. Choose the project of your choice. Change the address to 8787 to match the parameter specified for JBoss earlier. Change host name if necessary.
  4. Click Apply and then Debug

I was able to connect to the server and start debug the application. :)

A quick scan of “The Future of Programming Environments” article

Andreas Zeller‘s “The Future of Programming Environments”, provides an high level overview on the current trends of development tools. In this article, Zeller stated that development tools are evolving from extensible frameworks that supports integrated tools and their automation to “automated assistance in all development decisions”. Zeller further pointed out many known techniques that collects data about a piece of code in both static form and during run-time, then apply various automated analysis techniques that leads to visualization, statistics, data mining and machine learning to increase the productivity and code quality.

The paper serve more of a “review” or a “digest” of current trend of tools development than a “research” paper. Zeller certainly stated various recommendations that can serve as “best practices” for developers of tools. I would treat these recommendations as more of “common sense” than “design patterns”. This certainly is a good introductory paper with some interesting ideas and examples on what others have done in the tools space.

NetBeans 6 beta 1 is more JavaScript friendly than earlier releases

I’ve been using NetBeans 6 beta 1 for a while now. Today I just found out that if I am working on a static file such as a JavaScript file, all I need to do is to redeploy the project to the local server instance to see the changes. No need to rebuild or recompile. This is very cool. I don’t have to wait for the compilation of all that Java code in the same project to see changes in JavaScripts. This saves me a lot of time and I don’t have to go to a command line and do the copy myself. Again, very cool!

webtest and jWebUnit: first impression

I spent a little bit of time check out both webtest and jWebUnit. Here are my first impression:

webtest is declarative and XML configuration file driven. If you like configuration management more than programming, you might like this format. All you need is edit the test definition and hit the run command, no compilation necessary. If you have well formed HTML and working JavaScript, then you should not have too much trouble running this. My initial simple test case works once I commented out the non-working and irrelevant JavaScript reference in the HTML. I tried to take another mini-step forward by attempting to “configure” a click to select one of the link items in a JavaScript widget. Webtest has 3 ways to click on a link, by ID, label, or xPath. The widget’s link item doesn’t have an ID, so I can’t use that. I tried label and that didn’t work. Then I tried xPath and that didn’t work for me either. So, that second mini-step didn’t go very far for me. Any one know an open source xPath validation tool or web site?

jWebUnit is one of the many unit testing frameworks based on jUnit/HtmlUnit. The interesting aspect of this framework is that it supports both HtmlUnit and Selenium test cases. jWebUnit uses similar programmatic model as jUnit, so you can stay comfortable within your favorite IDE. I was able to create a new project in NetBeans and leverage it’s jUnit feature, by creating an unit test and rewrite that as a jWebUnit test case, while using NetBeans to drive the test execution. jWebUnit, or the underlying HtmlUnit engine appears more picky about JavaScript than Webtest, I had to start tweaking YUI libraries in an attempt to load a page, which shouldn’t be something that I supposed to be doing anyway. Perhaps YUI engineers use a different unit testing framework. The test page actually loads without a major issue in Firefox.

Both frameworks do share one thing in common, both do not use actual browser instances to drive the testing. And that explains why they don’t work as well as some of testing frameworks that built within or on the real browser instance because of behavior differences when processing JavaScript. At the same time, both may have one advantage over browser based testing framework, which is the ability for non-interactive testing through ant and is very useful for continuous integration servers such as CruiseControl. Again, I’ve only looked a few testing frameworks and let me know if you know a browser based unit testing framework that works with ant. Thanks.

A trick with dojo.editor in jMaki

When I tried to use jMaki’s dojo.editor, I first thought “Hay this is dojo, so I can just use it the way dojo related documentation stated it, right?” No. jMaki created a wrapper for dojo and the configuration argument doesn’t match 100%. So, After reading across several documentations, here is one trick for configure dojo.editor with medium pre-set tool bar. The default is small. Beyond that, there isn’t too much more you can configure. So, dojo.editor in jMaki isn’t as configurable as dojo.editor by itself. This simplification is fine if the presets are good enough for your needs.

<a:widget name="dojo.editor" value="edit me." args="{toolbar:\"medium\"}" />

Sources: Object Literal (for defining the parameters for args), jMaki’s dojo.editor documentation

Search and Replace using sed command

I found repeated need to search and replace a lot of known little text strings all over a text configuration file, for NetBeans. Since I expect to do this several times in the future, I used sed commands in a script do the trick. With examples on this page and a little bit of regular expression, I was able to create a simple script to do what I need for now.

How to manually migrate a NetBeans project to a different system?

NetBeans 5.5 hard-wire some of the environment information, such as where libraries are located on the file system. You can certainly right click on a project and choose “Resolve Reference Problems…”, however you will have to figure out where each library is located. Personally, I feel it is more painful than manually tweak [YOUR_NETBEANS_PROJECT_HOME]/nbproject/private/ file. So, I just replace the prefix to fit my local environment and NetBeans is happy again. :) You might want to make a backup copy in case you are working with a code versioning system, so that you can preserve your own configuration in case you did an update.

Maybe NetBeans 6.0 is smarter about this. Since all the jar files are in the same directory tree, the IDE should just figure out where all of its libraries are located using relative paths rather than absolute paths. Eclipse doesn’t have an issue with this. ;)

Belenix DVD — initial impression

Belenix “is an OpenSolaris Distribution with a Live CD (runs directly off the CD).” Just a couple days ago, Belenix DVD just released, which has NetBeans 5.5 and Glassfish. After downloaded the image off the net and burned onto a DVD, here are my initial observations on one system:

+ It recognizes ATI video chip and works with wide screen. This is pretty cool.
+ ACPI works out-of-box. I am impressed. Ubuntu 6.06 doesn’t work with this box. At least not yet.
- No sound. I can live with that on a development box.
- It can’t recognize the Ethernet out-of-box. That just kills my dream to play with Belenix on this box. Maybe I’ll try it on a slower/older machine.
+ NetBeans runs as advertised. No installation necessary. This is very cool.

I know that most of negative (-) points I made are addressable in OpenSolaris rather than in Belenix. So, I am still impressed at what folks at Belenix did. Keep up the good work.

First Impression: Reverse engineering with NetBeans Enterprise Pack 5.5 beta

I was looking at a blob of code that I don’t know where to start to get a handle on what it does. The code also didn’t come with documentation. So, I turned to NetBeans Enterprise Pack 5.5 beta. The feature that I wanted to try was it’s UML reverse engineering features. I downloaded it, installed it on top of NetBeans 5.5 rc1, and started NetBeans. Then I followed this tutorial to generate UML model from source code. The tutorial has some screen-casts that shows you step-by-step on how to use UML modeling features in NetBeans Enterprise Pack 5.5 beta. Finally, I started to generate some class diagrams. The diagrams certainly helped me to better understand which classes are related to which and helped me to conceptualize the blob of java code that I am trying to understand. I was able to export smaller diagrams to image files. Diagrams with larger number of classes didn’t export successfully. I hope it will be fixed by FCS. All in all, it’s a handy feature to keep in your toolbox. Don’t expect to throw away your whiteboard and dry erase markers, you may find them useful too.

At end of the session, I also used Dia to draw a variation of finite state machine to map out the flow of a piece of code.