|[ Team LiB ]|
Running WebLogic Server 8.1 in a Development Environment
If a developer wants to run WebLogic Server 8.1 as a local install, the machine should meet or exceed the minimum requirements discussed in Chapter 2, "Installing WebLogic Server." Development can slow to a crawl if the machine does not have enough processing power, memory, or even hard disk space to accommodate WebLogic Server. Besides WebLogic Server, most applications require database access. Databases that run locally can really tax the machine. Developers sometimes choose to run smaller or light versions of a testing database filled with a small subset of data or simply run a database on another machine.
In larger environments, WebLogic Server will run on its own machine and the developer will upload builds or changes during development and testing. Depending on the landscape, three or more servers could be required. A large-scale project requires at least a test system, and can contain a development system, integration system, and even a consolidation system. Most often each of these systems requires its own databases in addition to the WebLogic Server install. The development process for deployment is discussed later in the chapter in the "Packaging and Deploying Software" section.
Whichever way your specific environment is set up, it's crucial that the developer has hardware that allows the flexibility to run debuggers, compilers, IDEs, and other components easily without long waits because of insufficient memory. A significant amount of time can be wasted waiting for slow hardware to catch up with the software compilation and testing process. This is especially evident when debugging software is needed. The time wasted waiting usually far outweighs the cost of upgrading development hardware.
To compile Java software into compatible byte code class files that WebLogic Server 8.1 can read, a Java compiler is required. There are many Java compilers available, but BEA strongly suggests using one of the compilers included in the Java Software Development Kits (SDK) that come with WebLogic Server 8.1 for Windows and Linux. The two SDKs are
The SDK by Sun is the standard compiler used in Java applications. The new JRockit SDK is developed by BEA and is written to optimize server-side applications. This product is fully certified and complies with Sun's Java 2 Standard Edition (J2SE) version 1.4.1.
For the compiler to work, it must be placed in your path statement or directly referenced every time it's used. This procedure varies depending on the operating system being used. If you're using an IDE to compile your applications, set the correct compiler settings within the IDE.
JRockit and the Standard Sun JDK use the same names for their compilers. Remember to reference the correct one when compiling.
The classpath is the most important environment variable needed to compile and run files in Java. Countless errors can be avoided by setting up the classpath correctly in any development environment. All classes needed for compilation must be referenced in the classpath. If the classes aren't in the classpath, an error will be thrown at compile time. There are four ways to set this up in a system:
Setting system variables in each operating system varies, so check your documentation or contact a system administrator. To set the classpath in a batch file or at the command prompt, use the javac program parameter -classpath. A developer will normally use a batch file to set up these variables or use an integrated development environment (IDE) to save project files. The following is a sample batch file used to compile several files on Windows 2000:
This classpath contains the minimal classes to compile a J2EE application for WebLogic Server. The most important JAR file is weblogic.jar. This file contains all the J2EE-specific classes for servlets, EJBs, and so forth. The tools.jar file contains the standard Java classes and libraries.
When a WebLogic Server 8.1 service pack is installed, the service pack JAR needs to precede the weblogic.jar in the classpath.
To write the actual Java code, all that's needed is a text editor, but it's a good idea to use an IDE. These programs can significantly reduce development time by generating skeleton code, arranging all your files into projects, allowing one-button compilation, providing support for debugging mechanisms, enabling rapid graphical user interface (GUI) design capabilities, and much more. BEA has introduced the WebLogic Workshop development environment, which is included with the WebLogic platform.
This tool enables a developer to quickly add components such as database access, hiding the complexity and tediousness of the actual code. You can view the source code and write special conditions, but the overhead of setting up the initial call is already taken care of. Other IDEs include IBM's WSAD, Borland's JBuilder, Oracle's JDeveloper, Eclipse, and NetBeans.
Each of these products offers slightly different benefits and continues to improve. NetBeans is open source and provides many updateable modules including modules for JSPs, Struts, and modeling, and also has links to third-party modules that aren't free. Borland is partnering with BEA and provides a WebLogic edition of JBuilder. This enables the programmer to develop, build, and deploy applications to WebLogic Server 8.1 right from the IDE without having to transfer files directly to the server. Some other popular IDEs include the Eclipse platform. This gives developers the ability to quickly integrate plug-ins to a standard GUI environment. It's open source and comes with a basic Java IDE with no Web application support. Borland, IBM, and Oracle are the leaders in the IDE market. There are other products that work well for J2SE and J2EE development and new versions come out constantly (about every 6 months). It's a good idea to download the trial versions of other software as they come out to see the benefits. Each company usually allows you to try out its development environment for 30 days before you have to buy it, giving you time to learn how to use it effectively.
Here is one of the arguments against using an IDE. People opposed to using an IDE say that instead of learning the how the software runs, a developer simply learns how to use his IDE more effectively. In turn, this renders him useless when he switches to a different IDE or doesn't have access to one. I believe it's the developer's responsibility to learn what the IDE is helping him do so that he fully understands the software code that's been generated. This enables the developer to not only use the time-saving shortcuts provided by the IDE, but also recognize problems with what he's trying to do and what was generated. The IDE then enables the developer to spend his time solving hard problems and not writing generic code that's more of a rote task especially error detection and correction features that save hours of debugging and produce code that can be compiled much sooner. Also beneficial is the ability to package and deploy the application from your IDE right to WebLogic.
Developers and Web designers should test the software as it's written in unit tests, and it should be tested in the functional tests by a third person who did not write the software. This will help alleviate most of the bugs before an end user views the software.
|[ Team LiB ]|