Choosing Development Tools


At this point you have development hardware, software, WebLogic Server domains, a working directory structure, and a basic build process. Next comes the interesting and often difficult choice of development tool or integrated development environment (IDE) appropriate for your project. Let s face it: Every developer has his or her favorite tool, whether it s a full-blown IDE such as WebLogic Workshop or JBuilder, or a minimalist approach using emacs, TextPad, or some similar editor. There are pros and cons for each, and there is no right answer for all projects.

Rather than wading into the debate by advocating a particular choice, we ll identify and discuss some of the key features of these tools and IDEs and rate the relative importance of a particular feature in a WebLogic Server development effort. Use this discussion to decide which features are important to you, and then choose the development tool for your project accordingly .

Powerful Java-Aware Editing

The most important feature is the support for the core development process itself: Writing Java code one keystroke or mouse click at a time. Despite years of effort to create the perfect visual programming environment and alleviate the need for development at the source-code level, the reality is that programming is still based primarily on source files. The development tool must therefore provide a fast, efficient editing environment for the source-code components and other text files in the application. Typical requirements for a good editor include the following:

  • Syntax highlighting for Java, XML, HTML, JSP, and any other languages present in your application

  • Code completion, automatic indentation, and brace matching

  • Javadoc creation and browsing

  • Macros, keyboard shortcuts, class and code-block templates, and abbreviation support

  • Code refactoring and usage searching

The environment should be fast and easy to use. The goal is to improve the productivity of the developers and the quality of their code. Make sure that the wealth of features present in the editor help the developers rather than slow them down. For example, nothing is more annoying to a fast typer than a slow code-completion feature than cannot be configured out of the way. The editor should allow features to be customized and configured by developers to accommodate the wide variance in skill and experience levels. Developers will spend 90 to 95 percent of their time writing and modifying code in the editor; make sure that time is spent as efficiently as possible.

Best Practice  

Ensure that the development tool s code editor meets the needs of the developers and provides a fast and efficient environment for source-code creation and editing.

GUI Interface and Environment

While not strictly a feature, the overall organization of the user interface and programming environment is perhaps the second most important aspect of a good IDE. When a developer begins using a new IDE he or she must rapidly learn the terminology, organization, and idiosyncrasies of the new environment. Good IDEs are picked up fast because they use standard terminology and organize activities in an intuitive way.

Many features and requirements fall into this category. Developers must be able to control the layout of the environment to make the best use of the limited screen real estate. They should be able to find the option or feature they want without hunting through dozens of menu options and dialogs. Wizards should provide real value and create useful code. Good cross-directory search-and-replace capabilities are a must, as are file-comparison and merging abilities .

Don t sacrifice the usability and quality of the overall environment to gain fancy features and capabilities, such as the advanced features discussed later in this chapter. It s not worth it. The developers need a well-organized, well-designed environment more than they need features like one-click application deployment or round-trip UML generation. Focus on the tasks performed tens or hundreds of times a day, and make sure the environment does them well. Don t sweat the tasks developers perform once or twice a day.

Best Practice  

Focus on the usability and quality of the overall development environment. Make sure that developers can learn the tool quickly and customize it to meet their needs. The wealth of features shouldn t get in the way of everyday work.

Integration with Source-Code Management System

One task performed many times each day is the interaction with the shared application components in the source-code management (SCM) system. Developers should be able to perform all of the standard SCM functions (check out, check in, add file, remove file, etc.) without leaving the IDE, preferably using keyboard shortcuts. Be sure that the IDE provides good integration to the SCM you ve chosen for the project. Support for some SCM products is spotty.

Developers often need to compare and merge their local version of a source file with a version in the SCM system. Good IDE environments provide this level of integration.

Although it is possible to forgo integration with the SCM and use the tools and interfaces provided by the SCM product whenever these functions are required, this compromise will hurt developer productivity. Insist on good SCM integration in the IDE product.

Best Practice  

Insist on good SCM integration in the IDE product. All commonly used features of the SCM system should be available without leaving the IDE, including file comparison and merging. Make sure the IDE works well with your chosen SCM product.

Project and Build Processing Features

The final task you can be sure developers will perform many times each day is the execution of the build process. As recently as three or four years ago, the build process was usually performed by the IDE itself using scripts and configuration information placed in the project used by the IDE to organize the application components. Many IDEs still provide these IDE-specific build capabilities, but the industry has begun to standardize on using Ant for builds, and most IDE vendors now include support for Ant in their products.

Throughout this book we ve advocated the use of Ant to create a cross-platform, generic build process that is not dependent on IDE build facilities. Choose an IDE that understands Ant build.xml files and can execute targets in build files using keyboard shortcuts or other simple operations in the environment. The output of the build process should be available in the environment, and the IDE should be able to parse the Ant output and automatically open the source file and locate the offending line of code corresponding to a compile error.

One final advantage of Ant is the ability to support multiple IDE products in the same development team. If IDE-specific features are used for building applications it may be difficult to keep all dependencies, steps, and outputs consistent across multiple IDE products. As long as every IDE integrates with Ant and uses the shared build.xml file, the build process will always be consistent.

Best Practice  

Use Ant to implement the compile and build process for your application. Make sure the IDE has strong Ant integration, including the ability to edit and execute build targets and parse the Ant output to facilitate fixing compile errors.

Debugging Features

The next feature present in most modern Java IDE products is an integrated debugger. Debuggers come in two flavors: in-process and remote . In-process debuggers allow developers to set breakpoints, watch variables , and step through application code running in the IDE. Assuming that your IDE supports the required JDK version, it is possible to run WebLogic Server inside the debugger and debug applications this way. Products like JBuilder SE that do not support remote debugging will support this type of server-side debugging.

Remote debuggers provide a mechanism to debug code running in a remote virtual machine. Remote debuggers allow developers to set breakpoints, watch variables, and step through application code running in a remote WebLogic Server instance. They can be very useful when an application problem is difficult to diagnose and an inspection of key variables during execution will shed light on the error. Products that support this type of remote debugging have historically been much more expensive that ones that don t. A new set of lower-priced or free IDEs is emerging that support remote debugging; these include WebLogic Workshop, IntelliJ IDEA, and Eclipse.

While developers should know their code well, a good debugger can save you significant amounts of time over the old print statement style of debugging. If you are leaning toward an IDE as your development tool for J2EE projects, we recommend that you make sure that the debugger integrates well with your application server and understands J2EE applications.

Best Practice  

When making a development tool decision, debugging support should be a consideration. Even though we believe that most developers will know their code well enough to avoid using a debugger every day, having a good debugger integrated with the IDE can save significant amounts of time when the need for more complex debugging arises.

Remote debugging a WebLogic Server application is actually very simple with modern IDE products. Three steps are required:

  1. Compile the Java components with debugging information included in the class file.

  2. Start WebLogic Server with debug options set in the Java command line used to start the server instance.

  3. Configure the IDE to connect to the WebLogic Server instance using remote debugging and attach to the running instance.

Compiling the Java Components

To compile Java components with debugging information included in the class file, use the -g option on the javac command line or modify the compile target in the build.xml file to include the debug attribute in the javac task.

 <target name="compile">   <mkdir dir="${build}"/>   <javac classpathref="dev.classpath" destdir="${build}"          srcdir="${srcjava}"  debug="on"  >     <include name="com/**/*.java"/>   </javac> </target> 

If you need the ejbc -generated class files to include debug information as well, include the -g argument in the invocation of weblogic.appc (if using that technique) or in the weblogic element in the ejbjar optional Ant task, as shown here:

 <target name="ejbjar" depends="compile">   <ejbjar srcdir="${build}"     ...     <weblogic destdir="${basedir}" rebuild="false"  args="-g"  />     ...   </ejbjar>   ... </target> 

The new wlappc Ant task also provides a debug attribute used to include debug information in the generated classes. Don t forget to delete all existing class files and rerun the compile and ejbjar tasks to create new versions of the class files with debugging information before deploying the application to WebLogic Server.

Starting WebLogic Server in Debug Mode

Next, WebLogic Server must be started with the Java Platform Debugging Architecture (JPDA) remote-debugging capability enabled. This capability is defined by the Java platform itself and allows any JPDA-compliant debugger to debug any Java application running in this mode. More information on JPDA is available at http://java.sun.com/products/jpda/ if you are interested in the details.

Starting WebLogic Server in debug mode requires a change to the start script used to boot the server. Enable debugging by including a -Xdebug option, and specify the technique used to connect to the running application from the debugger using a -Xrunjdwp: < ... > option. The current Java implementation supports socket-based communication on both Windows and Sun platforms and a faster shared- memory-based communication on Windows only.

To enable debugging using sockets, modify the JAVA_OPTIONS variable in startWebLogic to add the following options (all on one line):

 set JAVA_OPTIONS=-Xdebug -Xrunjdwp:transport=dt_socket,server=y, address=5000,suspend=n %JAVA_OPTIONS% 

On Windows platforms use the faster shared-memory communication when the debugger and the running application are located on the same machine:

 set JAVA_OPTIONS=-Xdebug -Xrunjdwp:transport=dt_shmem,server=y, address=javadebug,suspend=n %JAVA_OPTIONS% 

The WebLogic Server instance will boot up and wait for a debugger to connect to the running application at the port specified or via shared memory. You may notice an increase in server boot time when running in debug mode and a significant slowing of the application when a debugger is attached to the server instance.

Best Practice  

Use the shared-memory communication technique for remote debugging when the debugger and running application are located on the same machine.

Configuring Remote Debugging

Finally, configure your IDE to connect to the running application at this location through the IDE-specific configuration screens. The IntelliJ IDEA product, for example, provides the dialog shown in Figure 13.4 in which the communication type, port, and other debug features are chosen.

click to expand
Figure 13.4:  Configuring IntelliJ IDEA for remote debugging.

Note that you want to Attach to the running application rather than Launch the application in the IDE virtual-machine environment. Be sure your IDE is configured appropriately.

Now instruct the IDE to debug the application, and it will attach to the running server instance and be ready to go. You will be able to set breakpoints, step through code, and examine variables in the WebLogic Server instance. Use a separate browser window to access Web pages for debugging purposes or invoke appropriate unit tests that you may have created.

One problem to watch out for: If you set a breakpoint inside transactional code such as an EJB component or presentation- tier component with a user-defined transaction, the WebLogic Server transaction manager will time out the transaction after a fairly short period of time by default (30 seconds). You should increase the time-out value to at least 600 seconds to give yourself enough time to examine variables, step through EJB code, and perform other debugging tasks without having the operation time out and roll back.

Best Practice  

Increase the Java Transaction API (JTA) time-out value in the domain to at least 600 seconds to provide enough time to step through transactional code and examine variables in the debugger without causing transaction time-outs.

Setting breakpoints in JSP components can be problematic . We hope that you ve chosen to use a model-view-controller architecture with servlets or Struts-based action classes encapsulating most presentation-tier business logic, so there should be little need to debug JSP pages. If you have this need, don t despair: Most IDEs deal with the problem of JSP-to-servlet conversion in one way or another and should provide you with a technique to set a breakpoint on a line in the JSP page and have the page stop at that point in the generated servlet.

In summary, remote debugging is fairly easy to configure and use with modern IDE products and will save you time when you need to debug your application. Our recommendation is to include the debugger in your overall development tool decision but realize that you probably won t use it every day, unlike some of the other features we have discussed so far.

Best Practice  

You will need to provide at least some sort of remote debugging capability to your developers. Remember to emphasize well-written and well-instrumented code rather than simply allowing your developers to rely on debuggers to overcome bad code.

Integration with Unit-Testing Packages

The eXtreme Programming (XP) movement has made unit testing a critical part of many development efforts, and it is helpful if the IDE supports the creation, management, and running of unit tests. Some IDEs have built-in test runners and include wizards for creating test cases, fixtures, and suites of tests. If unit testing is important in your development effort, examine the associated capabilities of your candidate IDE products.

Application-Server Deployment Features

Many IDE products boast of tight integration with application-server vendors and provide features in the IDE to package and deploy applications directly to a running server instance. We recommend that you avoid these features and rely on an Ant build script to perform all necessary packaging and deployment steps. Too many developers expect the IDE to do all of the work for them and lack the understanding and appreciation of the process that comes from building and deploying the applications manually.

Closely related to this feature is the EJB Wizard feature available in many IDE products. This feature typically provides a set of screens allowing the definition of EJB components, attributes, and configuration parameters. There is something to be said for a GUI-based technique for building EJB components when a developer is just starting out with EJB technology, but these wizards can become a crutch. One basic problem is that IDE products rarely keep pace with the new features in application servers, thereby limiting you to EJB capabilities available in the release supported by the wizard.

We advocated the use of EJBGen in Chapters 6 and 7 for the creation of EJB components and descriptor files, and we reiterate that recommendation here. The EJBGen utility combines many of the work-saving features of an EJB Wizard with the advantages of a file-based approach. It is also supported directly by BEA, ensuring that new WebLogic Server features are rapidly integrated into the code-generation process. We feel this approach is better than relying on wizards or other IDE-based techniques.

Best Practice  

Don t worry about application-server integration or EJB Wizards when selecting an IDE product. Application packaging and deployment are best accomplished through the Ant build scripts, and the EJBGen utility provides a better long- term solution for EJB creation than EJB Wizards.

Object Modeling Support

The fact that object-modeling support and related features has not been mentioned yet in this discussion should give you an idea where we feel these topics fall in the IDE-selection process: near the bottom. Good UML support and object-modeling features are important in the selection of a modeling tool, not the IDE, in our opinion.

Some IDE products include the ability to create application components from design models and reverse-engineer design models from application code. These features demo very well but have limited value in a realistic development effort. For example, in our experience the code-generation process works best for simple classes and interactions, but these simple components represent a very small part of the development effort on a typical J2EE project. And the reverse-engineering process acts more like an after-the-fact documentation tool than a true process enhancer . Design should come before construction! Don t fall into the designed as implemented trap by starting construction and allowing the design to fall out.

You may decide to build the entire development process around a fully integrated modeling and IDE product such as Borland Together or Rational XDE. We feel, however, that this decision should reflect your chosen development methodology and the importance you place on design artifacts rather than emphasizing developer productivity through the choice of IDE product. Developer productivity is our focus in this section, and that s why we feel UML support and related features are much less important than the topics covered earlier.

Best Practice  

Consider an integrated object-modeling and IDE product if your development methodology emphasizes design deliverables and reverse-engineering capabilities.

Web Services Support

A final consideration during IDE selection is the need for automatic generation of Web services for appropriate EJB components in your application. WebLogic Workshop provides a powerful environment for the creation of Web services, as do a number of newer IDE products. If your application requires Web services, this feature may be important in the IDE-selection process. Base your evaluation of its importance on your current project, upcoming projects, and your company s long-term direction. If Web services are not important in your near-term projects, we recommend placing less emphasis on this because the Web services support in the IDEs will likely have changed by the time you need these features.

With the selection and installation of a suitable IDE product, your development environment is complete. Be sure to document the configuration settings and installation specifics for everything in the environment to help the next person understand what you did and why. Conduct formal training sessions with new developers to explain the chosen directory structures and build process, and don t forget to allocate some time for training and ramp-up with the chosen IDE product.




Mastering BEA WebLogic Server. Best Practices for Building and Deploying J2EE Applications
Mastering BEA WebLogic Server: Best Practices for Building and Deploying J2EE Applications
ISBN: 047128128X
EAN: 2147483647
Year: 2003
Pages: 125

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net