Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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:
Memory Considerations
Gem: Note the big difference in the memory requirements between 8.x and 9.x servers. If you want to decrease the memory for the admin server running the web configuration console, you need to change the mem_args parameter to the VM, in the shell script.
mem_args for WL9 in the startWeblogic script (or remote params for admin server in the web console)
set MEM_ARGS=-Xms64M
-Xmx256M
-XX:CompileThreshold=8000
-XX:PermSize=48M
-XX:MaxPermSize=128M
By default, the settings go up to 512mb—a bit large just to run one web app console.
Cluster configuration tips
WebLogic 9.x offers some of the best features for application clustering and failover among other application servers in the industry. The distributed WebLogic Server instances are controlled with the Node Manager utility. The Node Manager is an independent process, not associated with a specific WebLogic domain instance, but with a machine.
The node manager in WebLogic Server 9.x now can start, monitor, and restart Administration Servers. And, you can now use WLST commands to access Node Manager and to start, stop, and suspend server instances remotely or locally; obtain server status; and retrieve the contents of the server output log, without requiring the presence of a running Administration Server. In addition, you can configure the machine on which WLST is running to be monitored by the Node Manager.
If you are running a cluster or want to run one, the configuration is much easier with 9.x than with 8.x. Here is the example of how a cluster domain should look.
On the application level, you need to add a <distributable/> tag in the generic web.xml, and of course make sure all of your objects associated with user sessions are serializable.
Here is an example of Web.xml:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC
"-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
"http://java.sun.com/dtd/web-app_2_3.dtd">
<web-app>
<display-name>WebAppWeb</display-name>
<distributable/>
<servlet>
<servlet-name>search</servlet-name>
<display-name>Search Servlet</display-name>
<servlet-class>com.someapp.MyServlet</servlet-class>
</servlet>
*****
</web-app>
Also, at the application level, you can indicate a replication parameter for cluster environment in the WebLogic’s specific configuration file. The PersistentStoreType sets the persistent store method to one of the following options:
- memory: Disables persistent session storage.
- file: Uses file-based persistence (see PersistentStoreDir, above).
- jdbc: Uses a database to store persistent sessions (see PersistentStorePool, above).
- replicated: Same as memory, but session data is replicated across the clustered servers.
- cookie: All session data is stored in a cookie in the user’s browser.
- replicated_if_clustered: If the Web application is deployed on a clustered server, the in-effect PersistentStoreType will be replicated. Otherwise, memory is the default.
Here is a sample of Weblogic.xml with this parameter:
<?xml version="1.0"?>
<!DOCTYPE weblogic-web-app
PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN"
"http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">
<weblogic-web-app>
<session-descriptor>
<session-param>
<param-name>PersistentStoreType</param-name>
<param-value>replicated</param-value>
</session-param>
</session-descriptor>
<context-root>app_name</context-root>
</weblogic-web-app>
Conclusion
This article talked about some of the configuration gems for the latest BEA WebLogic Sever 9.x that I personally found very useful. It discussed some of the most important new features and presented configuration gems on application, IDE, and the cluster level. The WebLogic 9.x includes a lot of evolutionally enhancements, in its architecture, web console, and overall structure that make it a very capable application server. It will be very interesting to see what BEA will introduce in the future releases.
Downloads
References
- Production-time Redeployment of Applications in WebLogic Server 9.0:http://dev2dev.bea.com/pub/a/2005/09/production_reployment.html
- Deploying Clusters: http://edocs.bea.com/wlp/docs40/deploygd/cluster.htm
- Deploying Applications to WebLogic Server: http://e-docs.bea.com/wls/docs90/deployment/index.html
- Updating Applications in a Production Environment: http://e-docs.bea.com/wls/docs90/deployment/redeploy.html
- Using Node Manager to Control Servers: http://e-docs.bea.com/wls/docs90/server_start/nodemgr.html
About the Author
Vlad Kofman works on enterprise-scale projects for major Wall Street firms. He also has worked on the defense contracts for the U.S. government. His main interests are object-oriented programming methodologies, UI, and the design patterns.
