There are 2 types of Extended discovery approaches available for this product. Extended discovery of WebLogic and WebLogic Extended J2EE Discovery using configuration file parsing .
Oracle WebLogic Server is an enterprise-class J2EE Application server. Oracle WebLogic Server is a part of the BEA WebLogic platform and supports Oracle, IBM DB2, Microsoft SQL Server, MySQL and other JDBC-compliant databases.
A domain is the basic administration unit for WebLogic Server. It consists of one or more WebLogic Server instances, and logically related resources and services that are managed, collectively, as one unit.
The WebLogic Server is shipped in all the bundles listed below. Each bundle is defined by licensing or extra features.
The platform enables full support for WebLogic Server Premium (including WebLogic Workshop), WebLogic Portal, and WebLogic Integration functionality.
The server enables full support for WebLogic Server functionality including the core Java 2 Enterprise Edition (J2EE) features, and WebLogic Workshop. WebLogic Server Premium Edition provides premium clustering, caching, and messaging.
Weblogic Workshop provides a complete development framework for easily building web services applications that automatically leverage the power, reliability, and scalability of WebLogic Server.
The portal enables full support for WebLogic Portal functionality, which provides a framework for building enterprise portals leveraging campaign, commerce, and personalization services. Includes WebLogic Server Premium.
Further information with regards the identification of Weblogic Portal is provided later in this document.
WebLogic Express offers many services and APIs available with WebLogic Server, including WebLogic JDBC features, JavaServer Pages (JSP), servlets, Remote Method Invocation (RMI), and Web server functionality. WebLogic Express differs from WebLogic Server in that WebLogic Express does not provide Enterprise JavaBeans (EJB), Java Message Services (JMS), J2EE CA, WebLogic Workshop, or the two-phase commit protocol for transactions.
The Premium Edition enables basic WebLogic Express functionality as described above and includes premium clustering support.
WebLogic Server is installed as part of a Aqualogic Service Bus deployment, Aqualogic makes use of the Weblogic platform to provide its functionality.
Further information with regards the identification of AquaLogic Service Bus is provided later in this document.
Note
BEA was acquired by Oracle in 2008 and the first release of the product using Oracle naming scheme is 11g Release 1.
Product Component | OS Type | Versioning | Pattern Depth |
---|---|---|---|
Application Server | Unix/Windows | Command (Active), Path, Package | Instance-based or Grouped (data dependent) |
WebLogicCluster | Unix/Windows | SoftwareInstance | Instance-based |
The pattern supports both the Windows and UNIX platforms.
Pattern | Trigger Node | OS Type | Attribute | Condition | Argument |
---|---|---|---|---|---|
ServerWindows | DiscoveredProcess | Windows | cmd | matches | \bjava\.exe$ |
args | regex 'weblogic\.Server' | ||||
Windows (run as service) | cmd | matches | (?i)beasvc(?:X64)?\.exe$ | ||
ApplicationServer | Unix | cmd | matches | regex'\bjava$' | |
args | matches | regex'-Dweblogic\.Name=' | |||
or | |||||
regex'-DWLS_INST_NAME' | |||||
or | |||||
regex'-Dweblogic\.management\.server=' | |||||
or | |||||
regex'-Dweblogic\.RootDirectory=' | |||||
or | |||||
regex'weblogic\.Server$' | |||||
WebLogicCluster | SoftwareInstance | Unix/Windows | cluster_messaging_mode | = | 'multicast' |
cluster_communication_socket | matches | "." | |||
or | |||||
cluster_name | matches | "." | |||
domain | matches | "." | |||
and | |||||
type | in | ['Oracle WebLogic Server', 'BEA WebLogic Application Server'] |
The patterns in this module will set the following attributes:
Pattern Name | SI type |
---|---|
ApplicationServer | Oracle WebLogic Server |
BEA WebLogic Application Server | |
ServerWindows | Oracle WebLogic Server |
BEA WebLogic Application Server |
Note
Software Instance type is set to 'Oracle WebLogic Server' for versions equal or newer than 11g Release 1 (10.3.1) and 'BEA WebLogic Application Server' for older ones. If the pattern cannot identify a version it assumes the product as "Oracle WebLogic Server".
Pattern name | SC type |
---|---|
WebLogicCluster | BEA WebLogic Application Server Cluster |
Oracle WebLogic Server Cluster |
The following components are identified using simple identity mappings. Note that the component is identified by arguments and not by process name.
Name | cmd matches | args matches |
---|---|---|
Oracle WebLogic Server | regex'\bweblogic\.Server$' | |
Oracle WebLogic Nodemanager | regex'\bweblogic\.NodeManager$' | |
regex'\bweblogic\.nodemanager\.NodeManager$' | ||
Oracle WebLogic Server | java.exe | regex 'weblogic\.Server' |
javaw.exe | regex 'weblogic\.Server' | |
BEA WebLogic Windows Service | regex '(?i)beasvc(?:X64)?\.exe$' | |
Oracle WebLogic Windows Service | regex '(?i)wlsvc(?:X64)?\.exe$' |
WebLogic server name is a required argument for any Weblogic process and thus can easily be extracted from trigger process command line via the following regular expression:
The WebLogic server name can additionally be obtained from WLS_INST_NAME, a custom command line argument which we have seen in some environments:
We obtain the domain name from one of the following arguments in the trigger process:
Argument | Platform | Notes |
---|---|---|
-Dweblogic.Name | UNIX, Windows | |
-DWLS_INST_NAME | UNIX | |
-Dweblogic.Domain | UNIX | |
-Ddomain.home | UNIX, Windows | the name of the leaf directory, e.g. -Ddomain.home=/products/my_app/my_domain means a domain of my_domain |
-DWLS_DOMAIN | UNIX, Windows | |
-D_<domain><servername> | UNIX, Windows | an argument of -D_MyDomainNode2 means a domain of MyDomain |
Install root is obtained from the trigger process arguments on the UNIX platform or Windows platform (when not running as a Windows service) using the following regular expressions:
(?i)-D(?:wls|weblogic)\.home=(\S+)/server
(?i)-Djava\.security\.policy==?(/.*?)(?:/server)?/lib/weblogic\.policy
(?i)-Dplatform\.home=(\S+)
(?i)-Dem\.oracle\.home=(\S+)
When the WebLogic Server is running as a Windows service, the pattern first determines the process arguments by:
Obtaining the WebLogic Server arguments using the following registry query: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service_name>\\Parameters\\CmdLine
The result is then parsed using the following regular expression: (?i)-Dplatform\.home=(\S+)
The pattern finds wls_home from one of the following arguments in the trigger java process:
The pattern finds bea_home from the -Dbea.home argument in the trigger java process. If they does not exist it assumes bea_home is one directory up from wls_home (e.g. if wls_home is c:\foo\WebLogic then bea_home is c:\foo).
Active versioning is performed by looking for and parsing a file called registry.xml which contains version information. It is stored in a directory defined in the variable BEA_HOME. The pattern has a privileged command execution for BEA_HOME extraction if the primary method fails. The command is as follows:
The BEA_HOME variable is obtained by one of the following methods:
Running grep "BEA_HOME=" <install_root>/common/bin/commEnv.sh
and parsing the output
Parsing the trigger process arguments with regular expression (?i)-Dbea\.home=(\S+)
Parsing the trigger process arguments with regular expression (?i)-Djava\.security\.policy==?(.*)/server/lib/weblogic\.policy
and then checking a registry.xml file exists in the extracted directory
Parsing the trigger process command with regular expression (?:^|\s|:|=)(/[^ :]*?/bea)/
Note
The registry.xml or domain-registry.xml file is normally obtained using an unprivileged account. It is possible for ADDM to retrieve it using privilege escalation, if privilege command execution is enabled.
Starting from TKU February 2015, privilege command execution configuration using the pattern configuration block is not supported. Please use BMC Atrium Discovery platform configuration instead.
Config.xml file is very important source of information for each WebLogic Server instance. In fact almost all information populated in WebLogic SI except version sometimes and server name is based on this file. That's why the pattern employs many methods in order to get this file. Each method used returns filename candidates which are added to candidates list to be verified afterwards.
Usually WebLogic admin server started by startWebLogic.sh (or startWebLogic.cmd on Windows). If the pattern gets the directory from which that script was launched it will be possible to construct the path to config.xml file.
That's why firstly the pattern tries to get parent process node for trigger process. If this was successful it tries to parse it's command line using the following regular expressions:
(/[^ ]*)/bin
- UNIX platforms
(?i)"?(\w:[\\|/](?:[\w\\/])*?)(?:[\\/]bin)?[\\/][^\\/]*\.(?:cmd|bat)"?
- Windows platform
If this wasn't successful, the pattern for UNIX platform tries (if it's permitted in the pattern's configuration section) to use elevated privileges in order to use one of the following active commands (dependent on the type of OS, adding 'pargs' and/or 'ps' to your sudo configuration file as required) for obtaining "PWD" environment variable which usually holds the path to domain directory:
Operating System | Active Command Requiring Elevated Privileges (where %parent.pid% is the PID of the parent process) |
---|---|
Solaris | pargs -e %parent.pid%| grep -v "OLDPWD"| grep "PWD" |
Linux | ps xew | grep "\s*%parent.pid%" |
AIX | ps axew | grep "\s*%parent.pid%" |
Please note that enablement of elevated privileges usage can help the pattern to find needed info on this step.
In the end if one of those methods was successful, the pattern will add file paths: "<dir>/config.xml" and "<dir>/config/config.xml" to candidates list, where <dir> is the directory path returned by regexp or via environment variable.
If BEA_HOME was found the pattern tries to read a file called 'domain-registry.xml' which is present in BEA_HOME on WebLogic setups starting from version 10. This file contains the list of installed domains. It is a very good spot for constructing config.xml candidates paths. Domain directories are obtained from <BEA_HOME>/domain-registry.xml file via the following XPath query running against DOM object constructed from domain-registry.xml contents:
If the trigger process arguments reference -Ddomain.home, we check the path referenced there for config.xml.
In rare cases, WebLogic Server is started with -Dweblogic.Domain argument which tells the name of WebLogic Domain. Using this information, if the pattern knows possible directory name relatively to BEA_HOME where domain could be located, it would be possible to find needed config.xml. That's why there are Configuration options called "domain_locations_unix" and "domain_locations_windows" which can be used for setting paths for directories where all domains are located.
If the pattern found domain name and BEA_HOME is know it will add file paths: "<BEA_HOME>/<dir>/config.xml" and "BEA_HOME>/<dir>/config/config.xml" to candidates list for each <dir> from Configuration option.
Root Directory (-Dweblogic.RootDirectory) is another argument which not always found in WebLogic command line, despite the fact it could be very helpful for config.xml obtaining. If the Root directory specified then we can try to find a copy of config.xml right in it or in it's /config/ sub-directory as for admin server it is the same as config dir by default. For managed servers config.xml can be located in the following places:
That's why the pattern firstly fires the following regular expressions against the trigger process command line: -Dconfig\.root\.dir="?(/[^\s"]+) -Dweblogic\.RootDirectory="?(/[^\s"]+)
If they successfully return non-empty value, the pattern will add all candidates described above to the candidates list.
If previous methods failed, the pattern will try the "last resort" method of parsing the command line of trigger WebLogic Server process by the following regular expression:
(?i)(/\S+?/(?:user_projects/)?domains/\w+)
This method based on assumption that config file may be in dir mentioned somewhere in args which contains '/user_projects/domains/' or '/domains/' directory names. Of course, the WebLogic setup can use another directory names so this method is not very accurate.
This is the last method and it used only in cases all other methods failed because of unusual WebLogic setups or lack of important arguments in the command line. This method usually provides very good results because it uses paths that a user inputs manually in the Configuration section.
There are several Configuration options related to this method:
For each fully-qualified absolute path in provided list the pattern will add file paths: "<dir>/config.xml" and "<dir>/config/config.xml" to candidates list for each fully-qualified absolute path <dir> in provided list.
In case paths with masks were added the pattern will extend such paths substituting the following masks:
Note
The registry.xml file is normally obtained using an unprivileged account. It is possible for BMC Discovery to retrieve it using privilege escalation, if privilege command execution is enabled.
Starting from TKU February 2015, privilege command execution configuration using the pattern configuration block is not supported. Please, use BMC Atrium Discovery platform configuration instead.
Version information for the product is currently collected using one of four possible methods.
The methods are tried in an order of precedence based on likely success and/or accuracy of the information that can be gathered. Once a result is obtained, the methods lower in precedence are not attempted. In order of precedence the methods are:
The pattern parses the file <bea_home>/registry.xml for WebLogic versions below 12c with the following xpath:
/bea-product-information/host/product[@name='WebLogic Platform' or @name='WebLogic Portal']/release/component[@name='WebLogic Server']/@version
or with another xpath expression using the file <bea_home>/inventory/registry.xml for versions 12.2 and above:
/registry/distributions/distribution[@status="installed" and @name="WebLogic Server" or @name="WebLogic Server for FMW"]/@version or /registry/distributions/distribution[@status="installed"]/features/feature/components/component[@status="installed" and @name="oracle.wls.weblogic.sca"]/@version
If registry.xml cannot be found in <bea_home> or <bea_home>/inventory, the pattern checks in <bea_home>/../ and <bea_home>/../inventory
Alternatively, the version may be obtained from the result of opatch lsinventory command. If you have Oracle Installer file in a custom location you would need to add it to the list of custom locations, that is available in configuration options.
There is a possibility that more than one version of WebLogic is installed under the same $BEA_HOME. We therefore firstly try to find WebLogic Server with install dir which the pattern obtained earlier (if it was able to do this) and get the version from that node. After this the pattern try to ensure that the installation directory parsed from the registry.xml can be matched with part of the server command-line. If this succeeds, the version (if it wasn't found in previous attempt) is looked up in registry.xml.
If the port information wasn't obtained using previous methods and config.xml config file was found, the version is parsed out from its content using the following XPath query:
This method is actual for WebLogic versions starting from 9 (due to the format of the configuration file).
The pattern parses the process arguments with the following regular expressions to obtain path versioning
On UNIX:
/oracle/product/fmw/(\d+(?:\.\d+)*)/
(?:/bea|weblogic|wls|wlserver)[/_\.]?(\d+(?:\.\d+)*(?:[/_]?sp\d+)?)'
/(\d+(?:\.\d+)*)[^/]/weblogic
/products/oracle/wl(\d+)
On Windows
The pattern also checks the following special cases on UNIX platforms:
This method works exclusively on Unix Platforms. Furthermore, it is only attempted if both active versioning and path regex methods fail.
The package names in the package manager have a number of regexes (i.e. "wls451", "wls452", "WLS51", "wls510", "wls600", "wls610") applied to them and the version information extracted from any that match. If two or more packages match, a Package Preference Algorithm is applied which seeks to discover the package with the lowest preference; the version of the "most trusted" package is returned.
This method has occasionally worked only in some environments and with old versions of WebLogic Server.
Pattern will also try to set the version based on obtained PSU patch information if available.
It is possible to run multiple instances of Weblogic on a single host. Instances are typically identified through the process argument list as each server is named in the command-line arguments or the process arguments obtained from the Windows Service via registry query and extracted using the following regular expressions:
-Dweblogic\.Name=(\S+)
- UNIX platforms
-Dweblogic\.Name="?(\S+)"?
- Windows platforms
Multiple WebLogic Managed Servers can be linked within a cluster. In this case they will have cluster name set for their configuration in config.xml file. Each cluster should have its own unique communication socket (either unicast or multicast).
The trigger process used by the ApplicationServer and ServerWindows patterns in the creation of Oracle WebLogic Server Software Instances (SI) is the Java VM process with 'weblogic.Name', 'WLS_INST_NAME', 'weblogic.management.server', 'weblogic.RootDirectory' or 'weblogic.Server' in its argument list or one of the Windows services, beasvc.exe or beasvcx64.exe.
WebLogicCluster pattern uses an Oracle WebLogic Server software instance (or BEA equivalent) as a trigger. This software instance must have a cluster_communication_socket or cluster_name attribute with domain name set.
By default the ApplicationServer and ServerWindows patterns produce a Deep (Instance Based) Software Instance for Oracle WebLogic Server. Each WebLogic Server instance that can be uniquely identified will generate a Software Instance in Discovery model.
The WebLogic Server instance name is used as part of the key to generating a Software Instance and is also stored as the 'server_name' attribute on the SI node.
If value of BEA_HOME was found it is used for creation of the SI key (path is combined with installation path and shortened using an MD5 hash), in conjunction with the application server instance name.
Alternatively, if the value of BEA_HOME is not found, but the installation path has been, the SI key is created using this installation path (shortened using an MD5 hash) in conjunction with the application server instance name.
If those parameters were not found, 'grouped' Software Instance is generated with the key group being made from the following possibilities:
WebLogicCluster pattern creates an instance-based SoftwareCluster instance which key is based on one of the following:
In all cases the key also contains the SoftwareCluster type
In order to get information described below the pattern needs to get config.xml file and create a DOM object from it's contents in order to run Xpath quieries against it.
The pattern attempts to add domain, cluster, listen address, listen port, ssl listen port, channels, default protocol and default secure protocol information to the Software Instance.
Domain is ascertained by executing the first, and if unsuccessful, the second xpath command below:
Weblogic can be configured as virtual-host-based setup. Virtual Hosts can be configured in two ways: by specifying server name or server's cluster name as a target. So pattern checks virtual-host deployment targeted to server using xpath below:
Cluster name is ascertained by executing the first, and if unsuccessful, the second xpath command below:
Listen address is ascertained by executing the first, and if unsuccessful, the second xpath command below:
Default protocol is ascertained by executing the first, and if unsuccessful, the second xpath command below:
If unknown, this attribute defaults to 't3'.
Default secure protocol is ascertained by executing the first, and if unsuccessful, the second xpath command below:
If unknown, this attribute defaults to 't3s'.
Listen port is ascertained by executing the first, and if unsuccessful, the second xpath command below:
If unknown, this attribute defaults to '7001' but can be user-defined via the default_listen_port option in the configuration section.
SSL listen port is ascertained by executing the first, and if unsuccessful, the second xpath command below:
If unknown, this attribute defaults to '7002' but can be user-defined via the default_ssl_listen_port option in the configuration section.
If listen port or secure listen port attributes are extracted they are populated within listening_ports attribute.
If listening_ports and listen address are set the pattern combines all pairs of address and ports into listen_tcp_sockets attribute.
The channel names are ascertained by executing the first, and if unsuccessful, the second xpath command below:
Having obtained a list of channel names, additional information for each channel is obtained via a number of further xpath calls:
The protocol used by the channel is ascertained by executing the first, and if unsuccessful, the second xpath command below:
If unknown, this attribute defaults to 't3'.
The address the channel is listening on is ascertained by executing the first, and if unsuccessful, the second xpath command below:
The port the channel is listening on is ascertained by executing the first, and if unsuccessful, the second xpath command below:
All extracted Channel details are then populated into Channel Detail which is linked to host WebLogic SI.
The cluster messaging mode - either "multicast" or "unicast" (for Oracle WebLogic 10.x+) is obtained via Xpath query executed against XML contents:
where %cluster% here and in examples below is a cluster name obtained earlier
The multicast address is obtained using the following Xpath queries:
/domain/cluster[name="%cluster%"]/multicast-address/text()
/Domain/Cluster[@Name="%cluster%"]/@MulticastAddress
The multicast port is obtained using the following Xpath queries:
/domain/cluster[name="%cluster"]/multicast-port/text()
/Domain/Cluster[@Name="%cluster%"]/@MulticastPort
Cluster communication address and port are populated as cluster_communication_socket attribute of the SI. Note that if unicast messaging mode is used the pattern obtains the socket details from the related Channel Detail which is used for the communication by the current WebLogic Cluster.
Note
Please note that starting from BMC Discovery v 11.x JMX support is not available any more.
Pattern aims to determine whether the discovered Application Server is an Administration server in order to populate JMX port information which can then be used for extended discovery of WebLogic.
The first method of obtaining JMX port value is to parse trigger process arguments with the following regular expression:
This value will be used in conjunction with the confirmation that this server is admin server for domain. This confirmation is obtained via config.xml file.
This is performed by analyzing config.xml file from config directory obtained in Protocol and Port Information. The algorithm is as follows - the server is Admin Server when:
In case the pattern confirms that this instance is Admin Server for domain, it populates the jmx_enabled (with Boolean "true" value) and jmx_port (only if it wasn't not found in the previous step, in this case JMX port will be set the same as "listen_port") attributes.
In order to find the value of heap_min_size and heap_max_size attributes pattern parses the trigger process arguments with the following regular expressions:
In BMC Discovery (prior to v11.0) populated JMX attributes (in particular: jmx_enabled and jmx_port) are used for Weblogic Extended discovery . Starting from BMC Discovery 11.0 JMX attributes are just populated but aren't used for Extended Discovery any more. The extended J2EE discovery functionality includes approach which uses the WebLogic configuration file - config.xml and by analyzing it models J2EE Applications, Domains, JDBC, Mail and JMS Resources. This config-file-based method is fully described here.
The pattern checks for the Oracle Jolt Connection Pool information present in the config.xml file. The following Xpath query is used for extracting the information about the Jolt Connection Pool: /Domain/JoltConnectionPool/@PrimaryAddresses /Domain/JoltConnectionPool/@FailoverAddresses
For all the hosts mentioned in the XML, the pattern will search for the "Oracle Jolt Server" Software Instance present on the host and if found create a communication relationship between that SI and the WebLogic SI.
As mentioned above, WebLogic Server is shipped in a number of different editions. Many components of WebLogic Server are licensable. Editions in essence govern the functionality that has been enabled through licensing. Components may be licensed for different periods of time. If the license expires on certain components, WebLogic Server edition changes and this typically degrades some of its functionality.
ADDM attempts to determine the product edition by parsing the license file of the WebLogic installation. The license file is called 'license.bea' and it is located in the same directory as registry.xml (i.e. BEA_HOME).
Note
The license file is normally obtained using an unprivileged account. It is possible for ADDM to retrieve it using privilege escalation, if privilege command execution is enabled.
Starting from TKU February 2015, privilege command execution configuration using the pattern configuration block is not supported. Please, use BMC Atrium Discovery platform configuration instead.
The license file is parsed using the following approach:
In addition to this, the 'WebLogic' component entry is parsed in detail to determine:
The information obtained from the WebLogic component is displayed on a "License Detail" detail node, attached to the WebLogic Server Software Instance.
ADDM currently identifies the following editions:
These product editions are common between WebLogic Server versions 8.1, 9.0, 9.2, 10.0, 10.1, 10.2.
Product editions such as Server Process (WebLogic 8.1, 9.0, 9.2), Integration and WebLogic Platform (WebLogic 8.1) are currently identified as Premium edition which they are supersets of.
WebLogic Platform edition (called SDK in WebLogic 9 and 10) can be however deduced from the 'license_type' attribute which will be set to 'SDK'.
Note
As of WebLogic Server 10.3 the product licensing is no longer controlled by the 'license.bea' file and Oracle has released the product for download without any restrictions for non-production use. The pattern will therefore not be able to gather license information for versions 10.3 and above.
To get the date from the host we run a command that is dependant on the host operating system, this is required for working out whether license expired:
Unix date command: date '+%Y-%m-%d'
Windows date command: date /T
Note
The date returned by Unix is consistent across platforms and locales, the Windows command returns a date specific to the language and locale. We have to perform additional checks on the output returned by Windows to ensure we check the date in the correct format.
The three possible formats that we have identified are US style (mm-dd-yyyy) with day name at the beginning, EU style (dd-mm-yyyy) and other (yyyy-mm-dd).
After reviewing all possible locales on a standard Windows XP system we identified that by looking for each of these styles we would cover ~97% of all possibilities.
The following Regular expressions extract the specific date formats:
US date regex: \w{3}\s+(\d+)[/\.-](\d+)[/\.-](\d+)
EU date regex: (\d{4})[/\.-](\d{2})[/\.-](\d{2})Other date regex: (\d+)[/\.-](\d+)[/\.-](\d+)
WebLogic Portal is installed on top of WebLogic Server (Premium Edition) and provides a framework for building enterprise portals.
As it is not a different product per-se but a framework layer on top of WebLogic Server, the current ADDM functionality allows us to detect its installation but not whether the Portal is actually running.
Portal installation is detected through parsing of registry.xml file for a particular WebLogic Server installation.
Note
The requirement for detection of "WebLogic Portal" installation is that the pattern is able to locate "BEA_HOME" and access "registry.xml" file.
There are therefore three possible outcomes when attempting to detect WebLogic Portal installation:
In a similar manner to the WebLogic Portal detection, the pattern tries to determine whether AquaLogic is also installed on the platform. It does so by parsing the registry.xml file, residing in the bea_home directory. The pattern will therefore be able to parse the xml file only when it can identify the bea_home directory.
There are therefore three possible outcomes in the identifying of an AquaLogic installation.
Finally, the pattern checks for the AquaLogic license in the license.bea file. In the event that the license expired, the pattern sets the aqualogic attribute to false.
In a similar manner to the WebLogic Portal detection, the pattern tries to determine whether Workshop is also installed on the platform. It does so by parsing the registry.xml file, residing in the bea_home directory. The pattern will therefore be able to parse the xml file only when it can identify the bea_home directory.
There are therefore three possible outcomes in the identifying of a Workshop installation.
Initial information on detection of WebLogic Portal installations and determining WebLogic editions was provided by Andy Key (JPMC).
We tested the pattern for Oracle WebLogic Server using ADDM record data from Unix hosts (Solaris, Linux) as well as with actual installations (8.1, 9.2, 10.0, 10gR3, 11gR1, 12c) running on Solaris, Linux and Windows.
N/A
Created By: Nikola Vukovljak (10 January 2008)
Updated By: Nikola Vukovljak (23 January 2012)
Updated By: Chris Blake (29 February 2012)
Updated By: Viktor Moyseyenko (18 May 2012)
Updated By: Viktor Moyseyenko (20 July 2012)
Reviewed By: Chris Blake (20 July 2012)
Updated By: Viktor Moyseyenko (12 Oct 2012)
Updated By: Viktor Moyseyenko (12 Oct 2012)
Updated By: Viktor Moyseyenko (29 May 2013)
Updated By: Rebecca Shalfield (21 Nov 2013)
Updated By: Dmytro Ostapchuk (31 Jan 2014)
Updated By: Olexandr Kashkevich (25 Mar 2016)
Updated By: Olexandr Kashkevich (04 Oct 2016)