Wlst.cmd

[Imelda Matchett]

Iam trying to setup weblogic server 12.2.1.3.0 on windows 10. I run fmw_12.2.1.3.0_wls.jar successfully. But when I try to create domain using config.cmd file, configuration wizard wasn't opened. I repatedly did deinstall/unstall weblogic but problem wasn't solved.

UPDATE: this problem still exists but I learned that domains are also created by WLST scripts. Using below commands in order:1. cd WLS_HOME\OracleCommon\common\bin\2. setWLSTEnv.cmd3. wlst.cmd

WLST scripting Shell is opened in command prompt. Then we copy the contents of WLS_HOME\inventory\Templates\wlserver\common\templates\scripts\wlst\basicWLSDomain.py file. Beore doing that please enterthe admin password in the file.

For system operators, WLST is easier to work with than Java code. For Java code you need to supply all dependencies in the classpath and updating code requires recompilation. Also Java code can be a bit verbose compared to WLST code and requires (for most developers) more time to write. With a WLST script you do not need to provide dependencies since they are already present in the classpath set by the wlst.sh (of wlst.cmd) command used to start WLST scripts and you can more easily update the scripts without need for recompilation.

In this example I wanted to create a script which undeployed composites which where not the default revision (are not called by default). Also I wanted to look at the instances. I did not want to undeploy composites which had running instances (long running instances like BPM and ACM). WLST provides some nifty features to undeploy composites; -reference-soa/custom_soa.htm#SOACR2689 for example the sca_undeployComposite command. I did however not see WLST commands I could use to query instances.

I started out with a piece of Java code shown below. In order to make the required classes available in your project, you need to import Weblogic Remote Client, JRF API and SOA Runtime (see here for a more elaborate example of using the Java API). With the Locator class you can find your composites and instances. By calling the MBean oracle.soa.config:Application=soa-infra,j2eeType=CompositeLifecycleConfig,name=soa-infra method removeCompositeForLabel you can undeploy composites from Java. This is based on what I found at

There are some other differences between Java and WLST. WLST determines its types by introspection and does not require explicit declarations or casts. Calling a constructor for example looks in Java like:

Converting Python arrays to Java arrays such as String[] and Object[] can be done with the jarray module array function. Be careful when also using a different function which is called array. You have to import one of the methods under a different name as I have done with the array from jarray which is imported as jarray_c below.

Maarten is a Software Architect at AMIS Conclusion. Over the past years he has worked for numerous customers in the Netherlands in developer, analyst and architect roles on topics like software delivery, performance, security and other integration related challenges. Maarten is passionate about his job and likes to share his knowledge through publications, frequent blogging and presentations.

Starting in Fusion Middleware (FMW) 12.2.1, Oracle has made changes to the WebLogic Scripting Tool (WLST) to simplify its usage. With these changes, it becomes easier to write provisioning scripts in environments where multiple FMW products are in use. This article tries to capture some of the more important changes for WLST users to understand.

Starting in FMW 12.2.1, Oracle has unified WLST so that there is a single version of WLST that automatically loads the necessary environment for all products installed in the Oracle Home from which WLST was invoked. The new unified version of WLST is accessed by running $ORACLE_HOME/oracle_common/common/bin/wlst.sh. There are a number of changes that were made to support this, each of which I will discuss in the subsequent sections.

Starting in 12.2.1, you will notice that the common/wlst directories no longer contain the PY scripts that were there in previous releases. Instead, these PY files are now packaged inside of JAR files. For example, the wlstModule.py and wlstModule_core.py files that previously existed in the $ORACLE_HOME/wlserver/common/wlst/modules/ directory are no longer in the file system in WLS 12.2.1 (they are packaged and loaded from inside one of the base WLST JAR files). By packaging them inside the core WLST JAR, WLST ensures that these PY files are available prior to loading any WLST extension containing PY files that might depend on wlstModule.py or wlstModule_core.py.

Starting in FMW 12.2.1, WLST now uses a plugin model to load a single, Oracle Home-wide WLST environment. It does this through a plugin model and scanning the Oracle Home for all WLST plugins. What exactly is a WLST plugin?

Starting with WLST in FMW 12.2.1, WLST uses a custom ClassLoader to load the WLST plugin JARs. It is important to understand how this works to prevent typical classloading errors that can occur. During the WLST startup process, WLST creates the following ClassLoader hierarchy:3

The WLS Descriptor ClassLoader is not new. For those of you who have written custom WLS Security providers, this classloader is the secret sauce behind the semantics of the $ORACLE_HOME/wlserver/server/lib/mbeantypes directory. It loads all of the security provider JARs in this location. I mention it here only because it now sits between the Java System ClassLoader and the WLST Plugin ClassLoader in the classloading hierarchy.

Should you run into problems with this new plugin model, or just happen to be curious, you can turn on WLST initialization debugging. Setting the wlst.debug.init Java System property to true will cause WLST to spit out a lot of debug-level information during startup. Inside this information, you can see the JARs it finds with wlstScriptDir entries and the order in which they are being loaded. To enable this output with the WLST shell script, simply do the following:

The wlst.sh (and wlst.cmd) shell scripts are the easiest way to use WLST. As discussed earlier, previous releases of FMW products had multiple WLST shell scripts, each of which created a customized environment for that product. Those scripts lived inside the various product directories at common/bin/wlst.sh (and wlst.cmd); for example, $ORACLE_HOME/soa/common/bin/wlst.sh. In 12.2.1, those scripts have been deprecated. The scripts that exist in those locations now print out a deprecation message and call the WLST script in $ORACLE_HOME/oracle_common/common/bin.

Another visible change to the WLST shell scripts is that they no longer use the value of the CLASSPATH environment variable coming from the environment used to execute them. The reason for this is simply to try to prevent accidentally adding unintended classes to the Java CLASSPATH, which has the potential to introduce insidious classloading issues due to the new WLST Plugin model and its classloader hierarchy. If you really want to modify the Java CLASSPATH being used to run WLST, simply set the WLST_EXT_CLASSPATH environment variable prior to invoking the shell script and its value will be prepended to the Java CLASSPATH used to start WLST.

As in previous releases, the WLST shell scripts honor the WLST_PROPERTIES environment variable as a mechanism to add other arguments (e.g., Java System Property definitions) to the Java command-line used to start WLST.

Embedded WLST is an API that allows users to create a WLST interpreter inside their own Java program and send commands to it to execute Jython code. Changes in 12.2.1 make this task much easier than in previous releases by:

To run your Java program using embedded WLST, you only need to emulate the environment created by the WLST shell script. For example, the following is an excerpt from a script that should provide a fully functional WLST environment for your custom Java application.

Starting in WebLogic Server 12.1.2, Oracle has provided a WebLogic Server Maven plugin that works the way Maven users would expect (e.g., uses Maven dependency management, provides POMs for WebLogic Server, etc.).4 This plugin has support for running WLST scripts from a Maven build. Current versions of the plugin provide two WLST-related goals:

The wlst-client goal was introduced in WLS 12.1.3 as an alternative way to invoke WLST scripts from Maven. The primary advantage of this goal was that it did not require a locally-installed Oracle Home to execute WLST online scripts. That means that Maven builds could run WLST scripts against a remote server installation without having WebLogic Server installed on the local machine.

WLST offline scripts still required a local Oracle Home. However, when you think about it, that is not really a limitation since WLST offline scripts, by definition, execute on a locally-available domain directory. Since every domain directory depends on a locally-available Oracle Home, there is little reason to try to support WLST offline operations without a locally-available Oracle Home.

Starting in 12.2.1, the wlst-client goal fully supports both online and offline scripts for all products. The execution of offline commands requires setting the middlewareHome configuration parameter to point to the locally-available Oracle Home. If it is not set and an offline command is encountered, the goal will fail with an error stating that offline commands are not supported (due to the lack of a known location for a locally-available Oracle Home).

Historically, WLST has gone out of its way to make it easy to use WebLogic Server Java classes by scanning a set of WebLogic Server JARs at WLST startup. Doing this allows WLST users to write scripts that reference the scanned classes without importing them. For example, one could write the following script to get information about the WLS installation without explicitly importing any Java classes.

3a8082e126