BEA released the latest version (v9.0) of their flagship application server, WebLogic in early August. I have been playing with the latest release of WLS to see what’s new, what’s cool and what are the features that will make me push to upgrade ASAP.

In addition to J2SE 1.5 or Java SE 5.0 support, WLS 9.0 is also fully compliant with the J2EE 1.4 Specification and is fully buzzword compliant. This release includes support for EJB 2.1, Web Services 1.1, JMS 1.1, JMX 1.2, JDBC 3.0, WS-Security, SAML 1.1, Profile 1.0, WS-Policy, WS-Reliable Messaging and WS-Addressing among others. The specification notably missing is EJB 3.0 – WLS 9.0 does not support EJB 3.0 and will support it as a service-pack, when EJB 3.0 JSR finally gets approved. This was kind of disappointing as WebLogic has always been on leading/bleeding edge in terms of specifications. I know I would have used the built-in support for the 3.0 spec, knowing full well that things may change and break with service-packs. The reality is that we won’t be pushing apps in production under 9.0 till SP1 is out and we’ve truly gone through and understood all the changes from 8.1 and their impact to our applications and processes. (More information of all the API alphabet soup is available here here).

One of the newest and biggest additions to WebLogic is the new functionality called ‘Production Deployment’ or ‘side-by-side deployment’. This new feature allows you to redeploy a new, updated version of a production application without affecting existing clients of the application that have valid sessions, and without interrupting the availability of the application to new client requests. So all the old users continue to use the old version of the application and any new users get directed to the new application. As old sessions timeout and/or users log out, the old application is retired. This also works in a clustered environment where you may have many WebLogic instances. The one thing I haven’t tested yet is whether in-memory (session) replication still works as before. The scenario I hope to test soon is where Server A and Server B participate in a cluster. User 1 comes in and logs into Server A – in-memory replication will replicate User 1’s session over to Server B. While User 1 is still active, I deploy a new version of the application to the cluster. Once the application is deployed, I kill Server A and then have User 1 attempt to use the application. Will the old version of the application still be there on Server B even though it didn’t have any users using it?

WLS 9.0 also includes a completely new administration console built on top of the WebLogic Portal framework as a set of JSP’s with Struts and Beehive. This allows you to extend the console and add your own custom admin screens. I think this is a pretty useful concept as developers can add custom JMX hooks in their applications and then surface that data via the custom admin console interface. I’ve always built custom admin-consoles for applications to turn on/off things, resources inside the applications or failover, etc. Being able to add that functionality inside the console gives you the additional authentication and authorization capabilities to your custom admin screen. WLS supports JMX 1.2 and JMX Remote API 1.0 (JSR-160) in this release, which deprecates BEA’s proprietary API for remote JMX access, MbeanHome.

One of the nicest new features is the ability to create 1 log file for 1 day. This was always a missing feature that annoyed me to no end as you could rotate logs based by time but it was always elapsed time and so you couldn’t create 1 log file for 1 day that automatically rotates to a new log file at midnight. That is now enabled and all I can say is that it’s about time.

Another great enhancement is the use of DataSources instead of connection pools by default. Instead of configuring a JDBC connection pool and then configuring a data source to point to the connection pool and binding to the JNDI tree, you configure a data source that encompasses a connection pool. Before JDBC 2.0 and the concept of DataSource, people created a connection-pool and then used the pool driver (JDBC) to get a connection. But now everything is in the context of a DataSource and so you have to create a DataSource to create the underlying connection pool and that will force people to rewrite their legacy code that gets a connection from the pool directly. It’s a good thing, as it will make their code more portable.

There are quite a lot of simple enhancements that I find useful. For example, hitting CTRL-C to interrupt a running server that you were running inside a DOS window or UNIX shell used to just kill the server. Now the start script catches the interrupt and calls the WLS shutdown hook. Another minor but useful thing is that the auto-generated start scripts have support for JPDA (Java Platform Debugger Architecture). The command line includes all the parameters needed to fire up the debug listener on port 8453 but it’s configurable at each startup script level.

I know I’ve only scratched the surface with WebLogic 9.0 in the weeks of playing. I’ll continue to blog about anything that’s interesting or cool or broken.

Links of Interest:

• WebLogic 9.0 Release Notes
• What’s new in WebLogic 9.0
• Upgrading Applications for 9.0
• WebLogic 9.0 documentation
• WebLogic Server blogs on dev2dev

WebLogic, WLS, WebLogic 9, WLS 9.0, BEA, J2EE