Now that we have seen how to scale and optimize our application, let's take a look at some features of WebLogic Server that help the developer in his/her job of creating, delivering, and testing applications. More specifically, we're going to check:
- The different kinds of packaging, and how to benefit from them at development time
- How to optimize redeployment by enabling the FastSwap feature
- How to package modules (a JDBC data source, for instance) into an application
- How to troubleshoot classloader problems using WebLogic's Classloader Analysis Tool (CAT)
- How to monitor WebLogic resources using WebLogic's RESTful management service
There are different ways to package and deploy an application, and each one has a specific set of benefits and challenges. When using Eclipse to publish projects, as we have been doing here, the archived file model is the only format that can't be used by the IDE—we can choose either from the exploded archive directory or the split development directory (also known as a virtual application).
Let's check each available option and when they can be used.
This is the most common way of packaging one or more projects—just create a JAR, WAR, or EAR file with all application resources and compiled code inside, and deploy it to the server. From Eclipse, we can create a deployment unit by using the Export… context menu of a project.
This option is pretty close to the archived file one—the structure is basically the same, but instead of using a single packaged file, we use a folder with the same contents. The benefit of using it is that we have direct access to the files, and some of them can be changed directly without the packaging procedure. Static files such as images and web pages (the Store project's .xhtml files, for instance) can be changed without the need to redeploy the application; just save the file, and it's already available.
The downside of this approach while developing the application is that the IDE must duplicate all files and folder structures to make them available to WebLogic, and this step can take some time, depending on the size of the projects involved.
When you look up your application at WebLogic's administration console, there's no noticeable difference between this approach and an archived file—you need to check the Path field in the Overview tab of a specific deployment in order to know which one is being used. It would look something like the following screenshot:
The last option, also called split development directory, uses the same concept of the previous one, exploded archive directory, but doesn't have the copy operation overhead—the deployment creates a direct reference to the current development directories instead of creating a stage area. Direct updates to static files are also immediately available to the server.
This configuration is applied to a server, so it changes the way in which all Oracle Enterprise Pack for Eclipse (OEPE) projects are targeted to that specific server; these projects will be bundled as a single enterprise application (EAR) when deployed to WebLogic, hence the name virtual application. This rule applies to Java EE projects that aren't explicitly bound to EAR projects—in this case, the EARs are created and deployed as usual. The following screenshot shows how both projects, store and theater, are presented as a single deployment on WebLogic's administration console while using this strategy:
By default, OEPE uses the virtual application model. If you want to change it to use exploded archives, the following steps can be performed:
- Right-click on the server name in the Servers view and select the last entry, Properties.
- The configuration screen will show up. Expand the WebLogic entry on the left-hand side, and then click on Publishing.
- Select the appropriate option under the Publishing mode group on the top of the Publishing screen, and click on OK to close the window and redeploy the projects using the selected approach.