Very large organizations know the value of spending a little (or a lot of) extra money to be in total control of the information. The rest of us have probably run into situations where the server version in production may or may not be exactly the same as the one in the QA section and would most certainly run at different log and debug settings from the server developers are working with. This article will cover the common ways to check basic WebLogic information, including versions and log locations. Knowing exactly what you run will also allow you to speed up that inescapable initial exchange of information with your BEA support engineer and allow him or her to get past configuration and into the technical depth of the actual issue.

Versions, Service Packs, and Rolling Patches
The official numbering for the BEA WebLogic product family is MajorVersion.MinorVersion.ServicePack.RollingPatch. Usually, you'll only hear about MajorVersion.MinorVersion in the press releases (e.g., 5.1, 6.0, 6.1, 7.0, and 8.1 for the WebLogic Server), but of course it is the ServicePack that gets the most workout in day-to-day server maintenance and administration.

Some confusion was introduced by BEA's new policy of Weblogic Platform releases in parallel with the stand-alone BEA WebLogic Server releases. Specifically, BEA WebLogic Platform 8.1 is actually built on the WebLogic Server 8.1sp1 and all the components are versioned at 8.1.1.0.

On the other hand, the rolling-patch was last seen at the time of WebLogic 6.0 and let us hope that was the last time.

In addition to the official numbering, there are also one-off (temporary) patches. Any number of them may be applied at the same time since they don't influence the version number, but sometimes it is very important to know exactly which patches are applied.

One important thing to remember about temporary patches (CRxxxx_spX.jar) is that they are specific to the release/service pack version. Trying to use a patch from an older service pack in the newer one can have disastrous effects - some more obvious than others. Listing 1 is an example of applying a WebLogic Server 7.0sp1 patch on the WebLogic Server 7.0sp2 version.

No problems, right? No problems in the server log version either. Then why does WebLogic Server recompile the JSPs that were already precompiled by the same version of WebLogic? The answer is in the console's version information (see Figure 1).

 

Notice that the Server Release Build value is suddenly transposed into 7.0.1.0 (WebLogic Server 7.0sp1). This is what the JSP compiler checks to determine the need to recompile the JSPs and it is a direct effect of an incorrect patch.

How to Skin a Cat (or Checking Version Numbers)
So, how many approaches are there to check for version number? Let us count the ways.

Remotely
Both of the following methods are good for system administrators who have access to and are comfortable with the WebLogic Server, but don't necessarily have access to the machine on which the WebLogic Server runs. After all, with Node Manager and the admin console, it's easy enough to install the server once and throw away the key (account password, that is).

WebLogic Console
This is the easiest and most complete method of getting the versions. You can find it in the Weblogic Console under Console/[Versions] tab. Figure 2 is the screenshot for the WebLogic Server 8.1sp1 (Platform install).

 

As you can see, the versioning information is very complete. It may also be slightly confusing with multiple components installed. The important thing to remember here is that unless you explicitly expect otherwise, the version numbers for all components should match.

weblogic.Admin VERSION
For those of you who like command lines, weblogic.Admin command provides a VERSION option that will return the equivalent of the last entry set in the console display (see Listing 2).

Onsite
The previous section was good for remote administration. What if you're already on the system and working with the files? Perhaps your WebLogic instance is down or you are support personnel and are actually working with somebody else's files. What options do you have then? Quite a few actually.

Server Log
A lot of the information may be found in the server log files, the version strings section being one of them. You can find the section (message BEA-000214 for WebLogic Server 8.1) near the beginning of the run's log, It looks similar to Listing 3.

Notice that as in our previous example of the bad patch, there is no information provided about the version the patches were for. You can, however, extract that information later in the log by looking at the java.class.path in the logged system properties (WebLogic Server 8.1 Message ID: BEA-141034). All the valid BEA patches will have server version information as part of the patch name (e.g., CR123103_81sp1.jar). All of the third-party or invalid patches will, hopefully, stand out exactly because they are missing that information and naming convention.

Odd Places
If you don't have the administrative access to the WebLogic Server, or all the server log files for the last run start have rolled over and were deleted/archived away, you can get a rough idea of what you are up against from various places in your installation.

From the start scripts, you can often tell a general version of WebLogic (based on WL_HOME) and the patches applied (look for CLASSPATH and PRE_CLASSPATH).

Starting with WebLogic 7, the config.xml may contain a ConfigurationVersion attribute in the Domain tag and a ServerVersion attribute in the Server tag. Both attributes, however, are used more for compatibility indication, so use them as an indication of what the server version is not. For example, if you see

<Domain ConfigurationVersion="7.0.2.0" Name="managedDom">

chances are very high that you are running a WebLogic 7 SP2 or higher. It could, of course, still be WebLogic 8.1 in a compatibility mode, so take this value with a grain of salt.

The last odd place to cover is the new domain-info.xml file that WebLogic 8 installs in the domain directory when configured from templates (e.g., WebLogic Configuration Wizard). The file contains the list of base templates and extensions installed over the domain's lifetime. Again, this is more curiosity than a real information source (but don't say we haven't tried to cover for the difficult cases).

Log File Names and Locations
A running WebLogic instance will generate many log files. Table 1 is a list of the core log files. Each extension (Integration, Portal, Workshop, etc.) will also have its own list of logs and should be covered separately (see Table 1).

 

The interesting thing about a server log (and probably BEA products in general) is that in the chase for ever better and ever more useful functionality, the formats and locations of log files keep changing. This especially hits hard those people who are used to running on one version of WebLogic and then upgrading to the latest release. I'm not even going to mention the plight of us - the BEA support personnel - who support at least four versions of WebLogic (5.1 onwards) on top of template and customers variations.

Following is a quick list of server log-related quirks that may have wasted your time in multiversion environments.

• The default location of the server log file is in <domain>/<servername> for WebLogic Server 5.1, 7.0, and 8.1, but <domain>/logs for WebLogic Server 6.1. To add to the confusion, WebLogic Server 7.0 may have a zero-sized weblogic.log file in the <domain>/logs that is actually a dummy and will never be written to.
• With WebLogic 8.1 in a development mode, a log file will be automatically rolled over at server startup regardless of the current file size. This and other differences between production and development mode are described at http://e-docs.bea.com/platform/docs81/confgwiz/newdom.html#devprod.
• When the log file is rolled over, the archived file will change its extension to .logXXXXX (e.g., myserver.log00001), even while transaction logs (for example) will use the more appropriate myserver.XXXX.tlog. This is especially challenging to the Windows administrators, where the file extension mappings are very important.
• To find the beginning of the log (e.g., to check the version info), the best line to search for in WebLogic Server 5.1 through WebLogic Server 7.0 is "FileLogger". As in:

  ####<29/10/2003 7:53:49> <Info> <Logging> <arafalov01> <myserver>
  <main> <> <> <000000> <FileLogger Opened.>

• WebLogic 8.1 has improved its internationalization and it is now unwise to rely on the text message itself. The message ID is a better reference. BEA-170019 is WebLogic 8.1's equivalent to the FileLogger and will usually read as shown in Listing 4.