This article will explain the BEA WebLogic 9.x server platform. In particular, it focuses on the new features, configuration tips for cluster enabled applications, tips on starting multiple instances of the WebLogic servers from within the development environment, and other configuration and maintenance gems that are very practical for development and setup. In addition, it will cover some of the differences between WebLogic 9.x and 8.x servers.
New Features at a Glance
WebLogic 9.x introduces a lot of evolutionary changes on both the back end and front end. On the back-end, WebLogic Server 9.0 is now fully compliant with the J2EE 1.4 Specification, and runs on JVM 1.5. In addition to the J2EE update, the 9.x release also implements other latest J2EE standards: Enterprise Web Services 1.1, JMS 1.1, JMX 1.2, JDBC 3.0, Connector Architecture 1.5, EJB 2.1., and so forth.
WebLogic 9.x offers improved speed, especially for the JMS messaging. BEA greatly optimized algorithms for reading messages from the JMS queues and topics. BEA also improved server performance with the self-tuning capabilities; for instance, the server thread pool is now self tuning, and cannot be adjusted manually. Out-of-the-box support for WAN and MAN failover, including cross-cluster failover, also is improved. The new overload features protect a server from out-of-memory exceptions and execute queue overloads.
On the front end, BEA revamped the administration console with a new, sleek-looking web application. The old java-applet-tree of the server components and resources is gone, and the new interface features enhanced concurrent change management (with lock and edit) for managing changes to the domain's configuration, centralized diagnostics service, and new deployment capabilities. Most of the console features are similar to the previous release, except for the new Work Managers to manage work performed by WebLogic Servers, and ability to extend the console with the plug-ins.
Gem: An example of the console extension is the project tomcat-management: in WL9 console. It allows users to interface and administer Tomcat servers from the new WebLogic console.
On the down side, the new web console is a lot heavier then the previous one, requires a lot more memory, and takes much longer to start. I also encountered issues running the console in the Firefox browser, and some minor interface bugs in general. Nevertheless, this new web app is a big step toward better configuration console architecture for the BEA WebLogic server.
Another great new feature is the command line scripting tool, called WLST (Weblogic Scripting Tool). Developers or administrators can do almost all that can be done from the web console, and in some cases even more, through the WLST, including deployment, changes to the servers, changes to the domain's configuration, performance tuning, monitoring, and so on. The changes can be scripted and saved to re-use in the future. The domain configurations changes can be performed in parallel, from the WLST and the web console, due to the greater control over how the changes occur and better lock management in the 9.x version.
New Deployment Features
The new "deployment plan" feature and side-by-side deployment (versioned deployment) are a welcome additions to the WebLogic server. The deployment plan lets an administrator define specific features for a deployment in an XML file, and re-use them for different deployment types. For example, a production environment may have specific database data source configurations that are different from the test or development environments. The master deployment plan for production will override or take precedence over application settings for development environment when deployed with it. This is very helpful when administrators want to quickly deploy the same application to test (qa) and production without any changes to the app.
The side-by-side deployment or versioned deployment is an extremely useful feature for updating production applications that are live. It lets you specify a version (unique version string entry in an Enterprise Application MANIFEST.MF file) for an application and WebLogic will recognize that it needs to deploy an additional application instead of replacing the active one. This is most useful as a production redeployment strategy; new incoming requests will be directed to the new application version, and as soon as all of the old sessions expire, the old application (version) will be retired and deactivated. I have provided a sample, MANIFEST.MF, and sample VersionedApp.war in the download section.
Gem: You can use the WLST tool to deploy, and you can specify the new version as one of the new parameters to the deploy command. If you are using the web console, the version needs to be in the MANIFEST.MF file inside of the WAR for WebLogic server to pick it up.
Configuring the WebLogic Server Development Environment
WebLogic Server 9.x easily can be configured for development in different third-party tools. For instance, Eclipse plug-ins, Oracle JDeveloper, or Borland JBuilder can start/stop server instances and deploy, redeploy, or un-deploy applications right from the IDE, via runtime configurations with the VM parameters required to interact with the WebLogic server.
The main difference between configurations of runtime parameters of WebLogic 8.x to 9.x is the strict enforcement of the admin server concept in the WebLogic 9.x. If, before and IDE such as JBuilder (or any other) could start multiple instances of WebLogic servers as admin servers, now multiple instances can only be started as managed servers.
Gem: Note that by default JBuilder creates a runtime configuration to start WebLogic server instance as an admin server, and it was ok with the 8.x version. With the version 9.x, if you want to start many servers at the same time, you need to specify an extra parameter (-Dweblogic.management.server=...) to the VM, indicating to start 9.x server as managed server. The admin server also needs to be started separately. Otherwise no domain configuration changes (such as new deployment) will take effect.
Here are the start commands and their differences:
Start command for WL9
-Xms256m -Xmx256m -XX:PermSize=32m -XX:MaxPermSize=128m -Djava.library.path="C:/bea9/weblogic91/server/bin;C:/bea9/ weblogic91/server/native/win/32" -Dwls.home="C:/bea9/weblogic91/server/" -Dweblogic.management.discover=false -Dweblogic.ProductionModeEnabled=false -Dweblogic.security.SSL.ignoreHostnameVerify=false -Dweblogic.Name=mtnserver -Djava.security.policy=="C:/bea9/weblogic91/server/lib/ weblogic.policy" -Dbea.home=C:/bea9 -Dweblogic.management.password=weblogic -Dweblogic.management.username=weblogic -Dweblogic.management.server=t3://localhost:7001
Start command for WL8
-ms64m -mx64m -Djava.library.path="/bea/weblogic81/server/bin" -Dbea.home="C:/bea" -Dweblogic.Name=myserver -Djava.security.policy=="/bea/weblogic81/server/lib/weblogic.policy" -Dweblogic.management.discover=false -Dweblogic.ProductionModeEnabled=false -Dweblogic.management.password=weblogic -Dweblogic.management.username=weblogic -weblogic.management.server=t3://localhost:7001
JBuilder configuration screen shot: