This topic presents best practice recommendations for using WebLogic Workshop build tools efficiently. These recommendations help you optimize the build process and save valuable time during iterative development cycles. This topic divides these recommendations into the following sections:
You can modify and test changes to web service (JWS), Java Page Flow (JPF), JSP, and JPD files without having to compile an entire project. To do this:
When you run a single file, WebLogic Server compiles only the file to be run and any dependent files. Pressing the Run button starts the compilation process in WebLogic Server. The file to be executed is parsed to gather a list of the dependencies. Dependent files are then scanned for their dependencies. This process continues until all the dependencies are resolved. The list of dependencies is compiled and deployed onto the server. The IDE then prepares the debugger and opens a test browser so that you can begin testing.
You cannot test all file types using this approach. For example, to modify and test changes to Java control file, you must first build the entire control project.
If your application contains multiple projects, you can choose to build only the project you are working on to save time. To build a single project, simply right-click on the project folder and then click Build <ProjectName>. If you are building a Control project or a Java project, building the project will compile all classes, place the classes with in a jar, and copy that jar to the APP-INF lib directory to be available to the rest of the application.
Keep in mind that if you are working in a Web Service project, a Web project, or a WebLogic Integration Process project, you do not need to build the entire project in order to test your work during iterative development. You can run and debug a specific .jws, .jsp, .jpf, or .jpd file directly, as described in the previous section.
Note that the Build button located in the WebLogic Workshop IDE toolbar always builds the entire application. You should build the entire application only if you are changing files across multiple projects, especially if there may be dependencies between them. And you should always build the application when you are ready for system-wide testing and debugging, and prior to deploying it to a production environment. Depending on the size of the application, the Application Build process can take a long time.
You can specify that WebLogic Workshop should build your Web and Web Service projects incrementally, rather than cleaning all project build artifacts each time you build. The incremental build process builds only files and dependencies that have changed since your last build. Using incremental build can speed up your build process during iterative development.
To build your project incrementally:
By default this property is set to false, and your project will be cleaned each time you build.
If you are building one or more projects incrementally, you can also specify that the EAR file be built incrementally by selecting Build Ear (Incremental) from the Build menu, or using the -incremental flag with the wlwBuild command from the command line. This command checks each Web and Web Service project to see if the project's properties specify that it should be built incrementally by checking whether the Use Incremental Build property is set.
If the Use Incremental Build property is set for a Web or Web Service project, then that project will be built incrementally when you build the EAR file incrementally. Any project for which the property is not set will be cleaned before it is built.
If no project in the application has the Use Incremental Build property set, or if there are no Web or Web Service projects in the application, then the Build EAR (Incremental) command is disabled.
As of Service Pack 4, WebLogic Workshop will build EJBs for controls referenced from JSPs or JPFs only on an as-needed basis for your Web projects and Web Service projects, as long as pre-compilation of JSPs has not been disabled. When you open your WebLogic Workshop application in WebLogic Workshop Service Pack 4 or later, you'll be prompted to update the libraries in the WEB-INF/lib directory. Updating these libraries may result in a substantial performance improvement, as WebLogic Workshop will no longer build all controls referenced on the classpath.
In previous versions, you could achieve this effect by modifying the <web-tier-controls> element in the wlw-config.xml configuration file. If you choose not to update these libraries when prompted, WebLogic Workshop will continue to build these controls as specified in wlw-config.xml, or to build all controls on the classpath if the <web-tier-controls> element is not specified. If you disable JSP pre-compilation, Workshop will build EJBs for all controls on the classpath unless you specify referenced controls in the <web-tier-controls> element in the wlw-config.xml configuration file.
WebLogic Workshop automatically pre-compiles JSP pages in a web project. This enhances server-side execution of those pages when users request them in a production environment. However, this enhanced run-time execution can translate into slower performance during development. When you change any file in a web project, and then build, WebLogic Workshop compiles every JSP file in that project. If you want to improve performance at development time, you can disable this behavior. The server will then build a JSP file at run-time only when a client requests that page.
To disable pre-compilation of JSP files for a Web Project:
If you choose to pre-compile JSP pages, you can still avoid compiling all of the JSP files in a project by running the JSP file without explicitly building the project.
WebLogic Workshop automatically builds a schema project any time you import a new schema to the project or modify the contents of an existing schema within the project. To disable automatic building of schema projects:
As of Service Pack 4, WebLogic Workshop now checks to see whether the JAR file generated by a Java project or a Control project is up-to-date in relation to the project source. If the JAR file is up-to-date, the build process will not re-build the JAR file.
If you have exported a build.xml file for your project in a previous version of WebLogic Workshop, you can add the up-to-date check to your build.xml file. The XML that you should add is as follows:
<target name="check-jar"> <uptodate property="isUpToDate" targetfile="${output.directory}/${output.filename}"> <srcfiles dir="${src.path}" /> </uptodate> <condition property="isUpToDateMsg" value="${output.filename} is up-to-date. Skipping build"> <and> <equals arg1="${isUpToDate}" arg2="true" /> </and> </condition> <condition property="isUpToDateMsg" value="${output.filename} is not up-to-date. Running build"> <not> <equals arg1="${isUpToDate}" arg2="true" /> </not> </condition> <echo message="${isUpToDateMsg}" /> </target>
If you are building a control that is used by a single web service, web application, portal, or integration project, you can embed the control directly within the project that is using it, rather than creating a separate Control project or Java project. Embedding the control where it is used reduces the amount of scanning the compiler needs to do to make the control classes available, shortening IDE startup time and project build time.
If you are including a class library that is used by only one project, place the class library directly into the project's WEB-INF/lib directory instead of the APP_INF/lib directory. This reduces the amount of scanning the compiler does to make the class available for code completion, and shortens IDE startup time and build time.
To reduce startup time for Weblogic Server, be sure to include in your domain only the platform components that are necessary for your application. For example, if you are developing a WebLogic Portal application, you don't need to configure your domain to include WebLogic Integration.
Increasing the amount of memory available to WebLogic Workshop and ensuring that all unused memory is available for re-allocation are two ways to ensure that your development environment performs optimally. The following sections describe how to manage memory for maximum performance.
You can monitor the amount of memory used by WebLogic Workshop using the memory monitor located in the lower-right corner of the WebLogic Workshop IDE. The following figure illustrates the memory monitor:
The number on the left side of this monitor indicates memory being used by WebLogic Workshop. The number on the right side is the amount of memory currently available to WebLogic Workshop. Note that WebLogic Workshop is automatically configured to use a maximum of 256 Megabytes of memory by default. If you have additional memory to spare, you can increase this amount by opening the <BEA_HOME>/<WEBLOGIC_HOME>/workshop.cfg file (workshop.sh for Linux machines) and editing the portion of that file represented as red text below:
C:\bea\weblogic81\workshop C:\bea\jdk142_04\jre\bin\javaw.exe -XX:-UseThreadPriorities -Xmx256m -Xms64m -Xss256k -client -Dprerelease=true -Dsun.io.useCanonCaches=false -Dsun.java2d.noddraw=true -Dsun.java2d.d3d=false -Djava.system.class.loader="workshop.core.AppClassLoader" -cp "C:\bea\weblogic81\workshop\wlw-ide.jar" workshop.core.Workshop
As you build and run applications, WebLogic Workshop allocates memory that it later reclaims during a process called garbage collection. You can force WebLogic Workshop to reclaim that memory immediately by clicking on the memory monitor in the lower-right corner of the WebLogic Workshop IDE. When you click this monitor, all unused memory becomes available for building and running your applications.