Skip Headers
Oracle® Fusion Middleware Quick Start Guide for Oracle WebLogic Portal
10g Release 3 (10.3.4)

Part Number E14246-02
Go to Documentation Home
Home
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

10 Developer Productivity

This chapter includes the following tips to increase developer productivity:

10.1 Use the Team Plug-in

See Section 4.1, "Team Plug-ins."

10.2 Use JRockit

Based on the test described in the next paragraph with a basic portal application, the JRockit JVM is faster than the Hotspot JVM for iterative development.

Using a scenario that is based on a typical developer's tasks—starting a server, deploying an application, then redeploying the application ten times—JRockit saves several minutes of wait time on a reasonably fast Linux machine. You'll save even more time on a slower computer.

For more information about using JRockit, see:

10.3 Run Without Debug when Possible

Running the Debug Server slows down both JRockit and the Sun JVM. In the developer's scenario described in the previous section, running debug add several minutes of wait time.

Obviously, using debugging will save you much more time in productivity when you need it compared to sprinkling your code with printlns. However, if you are not going to use debug, start the server without it.

For additional information, see:

10.4 Make Sure You Have Enough Heap

As your portal gets larger, you may need to increase the heap (-Xmx) and initial heap sizes (-Xms). It is generally best to make the initial and maximum heap sizes equal.

For more information, see:

10.5 Prefer Quicker Redeploys

Because of the size of a portal EAR, redeployment of a portal application can be slow—several minutes, depending on the machine. However, you can organize your work to spend less time waiting and avoid slow redeployment in the following ways:

10.5.1 Some Resources Do Not Need to Redeploy

JSPs, .portal files, and similar objects do not need to redeploy. For example, if you change a JSP and then republish in Oracle Enterprise Pack for Eclipse, basically nothing happens. Use coding in a JSP for light investigation or testing.

For information about using Oracle Enterprise Pack for Eclipse for JSP development, see Oracle Workshop for WebLogic for JSP (Oracle Enterprise Pack for Eclipse document).

10.5.2 Web Applications Redeploy Faster than their Enclosing EARs

The redeployment of a web application, including a portal web application, is significantly faster than deploying the entire EAR.

If your only change a web application, Oracle Enterprise Pack for Eclipse republishes only that web application. Therefore, it is faster to code in a web application as classes in the web project's Java Resources/src folder. They deploy in the web application's WEB-INF/classes, and Oracle Enterprise Pack for Eclipse directs the server redeploy only the WAR (unless you change something that requires the application to redeploy).

For additional information, see Streamlining Deployment/Testing (Oracle Enterprise Pack for Eclipse document).

10.5.3 EJB Projects in a Sub-classloader Deploy Faster

Because the majority of application redeployment time is spent processing resources like portal EJBs, you can save time by avoiding redeployment of these resources. For instance, if you have code that is application-scoped, such as EJBs, you may be able to deploy the code in a submodule. However, use of this method is limited, due to the ClassLoader arrangement that it requires. This technique will not work if the application calls code in the EJB project, such as implementing a content management SPI or registering P13n EventListeners and UUP.

To make an EJB project a submodule of the EAR, add a classloader-structure stanza to your EAR's weblogic-application.xml file. This allows the EJB and WAR projects to redeploy without redeploying the EAR.

To add a classloader-structure stanza to your EAR's weblogic-application.xml file:

  1. Create an EJB project, as discussed in Section 3.6, "EJB Projects," and associate that EJB project with your application project.

  2. In the Projects view, open the WebLogic Deployment Descriptor for the EAR, and select the Source view.

  3. Add a stanza like this, changing the module-uri names to those of your project:

    <wls:classloader-structure>
       <wls:classloader-structure>
          <wls:module-ref>
            <wls:module-uri>projectXejb.jar</wls:module-uri>
          </wls:module-ref>
          <wls:classloader-structure>
             <wls:module-ref>
                <wls:module-uri>projectX.war</wls:module-uri>
             </wls:module-ref>
          </wls:classloader-structure>
       </wls:classloader-structure>
    </wls:classloader-structure>
    

Because this stanza makes your EJB project (projectXejb) a submodule of the EAR, it allows WebLogic Server to redeploy the EJB JAR without requiring the entire EAR to redeploy. Notice that the WAR project (projectX) is made a child of the EJB, which allows the code in the WAR to access the code in the EJB project.

For more information, see: