April 4, 2014

Differences between WLS 11g and 12c (12.1.2)

Filed under: WebServer — vaishalipavashe @ 2:55 pm

Here is a summary of changes and new features added in WLS 12c (12.1.2). Seems there are many config, install, diagnostic and JMX level changes as compared to 11g version.

Source Link:

Component Sub-comp. WLS 11g WLS 12c (12.1.2)
Supported configuration Check: Oracle Fusion Middleware 11g Release 1 Certifications ( Check: Oracle Fusion Middleware 12c Certifications
– 12.1.x (
Installer Platform specific installers are avialable From 12.1.2, there is only generic installer available
JDK JDK 6 and 7 supported JDK  7 supported
JDK bundled with 32bit installers JDK needs to be installed specifically
Web server Plugin Webserver plugin is bundled with WLS installer Plugins need to be downloaded from Oracle support
Patching bsu/smart update to apply patches java-based utility Opatch is introduced
Upgrade Features Domain upgrade wizard or rolling upgrade is used Reconfiguration Wizard is newly introduced
Domains on remote machines can be upgraded using the WLST writeTemplate command
New Configuration Features Configuration Wizard Configuration wizard has same features in all 11g versions Support has been added for configuring OHS
 A Template Categories drop-down list has been added
 Node Manager configuration options have been changed and expanded
A Server Groups column has been added to the Managed Servers screen
A Clone function has been added to the Managed Servers screen
 The Cluster messaging mode, Multicast address, and Multicast port columns have been removed
Template Location WL_HOME/common/templates/applications andWL_HOME/common/templates/domains WL_HOME/common/templates/wls
Quick Start Configuration Wizard same config wizard is used new utility called the Quick Start Configuration Wizard
Node Manager Configuration Multiple domains in same machine can share same NM process Domain specific NM is created
Cluster Dynamic Clusters Static clusters Dynamic clusters allow you to easily scale up the number of server instances
Cluster Targeted JMS Servers  – Targeting JMS Servers and persistent stores directly to a cluster
Oracle Database 12c Integration ONS list is required With WLS 12.1.2 one does not require the ONS Listener list as part of an Active GridLink datasource configuration
Additional Component-Level Features and Changes Deployment  – An application’s deployment plan can be staged independently of the application archive, allowing you to stage a deployment plan when the application is not staged
JDBC Data Sources  – Oracle Data Base Testing Using PINGDATABASE
Pinned-to-thread Support for GridLink Data Sources
Using GridLink Data Sources without Fan Notification
Set Identity and/or Client Identifier as WebLogic User
Connection Testing Improvements
JavaDB Support
Maintenance Timer Improvements
pack and unpack Utilities All domain data is included in template Persistent file stores are no longer included in a packed domain
No node manager configuration preserved Node Manager configuration is preserved by pack and unpack
Security SSL Implementation Versions prior to 10.3.4 support certicom whereas later versions support both certicom and JSSE Only JSSE will be supported
Oracle OPSS Keystore Service Support JKS supported OPSS Keystore Service provides an alternate mechanism to manage keys and certificates
Location of demo identity WL_HOME/server/lib DOMAIN_HOME/security
WebLogic Diagnostic Framework Built-in System Diagnostic Modules No built-in modules WLDF adds a set of built-in system diagnostic modules
Targeting Multiple Diagnostic Modules to a Server or Cluster target only one diagnostic system module to a server or cluster target multiple diagnostic system modules to a server or cluster
Dynamic Activation/Deactivation of Diagnostic System Modules No dynamic activation available The ability to dynamically activate and deactivate diagnostic system modules that are defined in the domain configuration
The ability to create and activate a diagnostic system module on-the-fly that is not defined in the domain configuration
New Diagnostics WLST Commands listSystemResourceControls(), enableSystemResource(), disableSystemResource(), createSystemResourceControl(), destroySystemResourceControl(),dumpDiagnosticData()
WLST WLST commands are same across all minor versions Various WLST commands are newly added for eg:
readDomainForUpgrade opens an existing domain for reconfiguration.
 getNodeManagerHome returns the path of the Node Manager home directory.
getNodeManagerType returns the Node Manger type.
clone clones an existing Managed Server to create a new Managed Server.
 listSystemResourceControls()lists all available diagnostic system modules.
enableSystemResource() activates a diagnostic system module.
disableSystemResource() deactivates a diagnostic system module.
createSystemResourceControl() creates a diagnostics system module on-the-fly using a specified descriptor file.
destroySystemResourceControl() destroys a diagnostics system module previously created on-the-fly.
dumpDiagnosticData() dumps the diagnostics data from a harvester to a local file.
Deprecated Functionality The use of “BEA” as the naming prefix in error messages and log messages. and is deprecated in WLS 12c
Writing of datasource diagnostic data to the WLDF event archive The weblogic-maven-plugin plug-in delivered in WebLogic Server 11g Release 1 is deprecated in this release
Oracle WebLogic Server 11gR1 on JRockit Virtual Edition XSLT JSP tags and the WebLogic XSLT JSP Tag Library have been deprecated

October 9, 2012

HALF_OPEN_SOCKET_RETRY exception in proxy logs

Filed under: Weblogic — vaishalipavashe @ 7:36 pm


In iPlanet proxy logs multiple occurances of HALF_OPEN_SOCKET_RETRY exception, WRITE_ERROR_TO_SERVER exceptions and READ_ERROR_FROM_SERVER were observed while using iPlanet front end server with Plugin 1.0 and backend as Wenlogic 10.3.0:

Thu Aug  2 14:46:55 2012 <2214913439332152499747> *******Exception type [HALF_OPEN_SOCKET_RETRY] (Unexpected EOF reading HTTP status – request retry) raised at line 860 of URL.cpp
Thu Aug  2 14:46:55 2012 <2214913439332152499747> got HALF_OPEN_SOCKET_RETRY exception in sendRequest phase at line 1366; Msg: HALF_OPEN_SOCKET_RETRY: [os error=0, line 860 of URL.cpp]: Unexpected EOF reading HTTP status – request retry

Wed Aug  8 11:48:23 2012 <107031344440903338902> *******Exception type [WRITE_ERROR_TO_SERVER] raised at line 745 of URL.cpp
Wed Aug  8 11:48:23 2012 <107031344440903338902> failure on sendRequest() w/ recycled connection to 127.x.x.x:8003, numfailures=1
Wed Aug  8 11:48:23 2012 <107031344440903338902> Marking 127.x.x.x:8xxx as bad


It was observed that the connections made to an application running on WebLogic Server through OHS/WLS plug-in, were not getting processed intermittently throwing below errors in proxy logs. Below is the detailed explanation of the error messages received:

The proxy was using a recycled socket and that socket has already been closed by the backend server. The request will be retried on the same host with a new connection.

A socket write error occurred while sending HTTP headers to a backend server. The application server may be down or unable to accept requests.

The proxy was unable to process all of data returned by the backend server due to an NSAPI error or a socket read failure. The application server may be down.

To analyze further mentoring bug 14491247  was raised and it was observed to be a plugin 1.0 issue which was fixed in plugin 1.1 via OHS Bug request Bug 14012227.


It was observed that the plug-in pools free connections so that it can be used at a later point of time. In this case, the chosen pooled connection was closed by the remote system, but plug-in did not detect the same. It went ahead and detects it when trying to read from the socket. The fix is to check if the connection is reset by peer before reusing the pooled connection.

Backport Bug 14551369 and Bug 14547217 were raised to get this fix in Plugin 1.0 for Linux and Solaris platforms respectively and Issue got resolved after applying these new patched plugins.

August 29, 2012

EM console fails to load when weblogic is configured as windows service

Filed under: WebServer — vaishalipavashe @ 10:36 pm

Its been found that EM console fails to load when weblogic is configured as windows service. When we install weblogic as service only commEnv.cmd file is called which is not sufficient to set EM environment so to make EM console work, follow below work-around:

1. Edit installSvc.cmd file to add setDomainEnv.cmd instaed of commEnv.cmd:
call “%WL_HOME%\common\bin\commEnv.cmd”

call “%DOMAIN_HOME%\bin\setDomainEnv.cmd”

2. The setDomainEnv.cmd script will correctly setup up the classpath, so comment out or remove the following line:


3. Now re-install weblogic service and start it

4. Access EM console on admin IP:Port and it will load properly

August 16, 2012

Configure Log4j logging for weblogic server log

Filed under: WebServer — vaishalipavashe @ 3:46 pm

Follow below procedure to configure log4j logging with weblogic server:

1. Create a weblogic server domain and start Admin server

2. Copy below jars in $DOMAIN_HOME/lib folder:

a. wllog4j.jar (Available in $WL_HOME/lib
b. log4j-x.x.x.jar (Download latest log4j.jar from link: )

3. Login to Admin console, click on Admin server name and navigate to Logging -> Advanced

4. Select Log Implementation from default JDK to log4j logging. Save this and activate changes. Before we restart server complete below step

5. Navigate to $DOMAIN_HOME on physical box and cretae a file called log4j.xml in domain home. Copy below content in it:

<?xml version=”1.0″ encoding=”UTF-8″ ?><!DOCTYPE log4j:configuration SYSTEM “log4j.dtd”>
<appender name=”CONSOLE”>
<param name=”ConversionPattern”
value=”%d [%t] %-5p %c – %m%n”/>
<appender name=”FILE”>
<param name=”File” value=”/<Log4j Logging location>/Log4j.log”/>
<param name=”Append” value=”true”/>
<param name=”ConversionPattern” value=”%d{ISO8601} %-5p {%t}[%c] – %m%n”/>
<logger name=”org.apache”>
<level value=”WARN”/>
<logger name=”org.springframework”>
<level value=”WARN”/>
<level value=”DEBUG”/>
<appender-ref ref=”FILE”/>
<appender-ref ref=”CONSOLE”/>

6. Before saving, change location of Log4j.log as per your environment

7. Now navigate to $DOMAIN_HOME/bin folder and edit file:

Locate below 2 lines in script:

if NOT “%LOG4J_CONFIG_FILE%”==”” (

Above them add below line:


8. Save this file and restart server. Check at command prompt you will be able to see log4 logging

9. Also you can check log4j log cretaed in mentioned location in log4j.xml. Content of the log would be something link below:

2012-08-14 20:16:39,220 DEBUG {[ACTIVE] ExecuteThread: ‘0’ for queue: ‘weblogic.kernel.Default (self-tuning)’}[com.bea.console.utils.ResourceBundleCache] – findBundle bundle baseName[global] locale language[en]
2012-08-14 20:16:44,993 DEBUG {[ACTIVE] ExecuteThread: ‘0’ for queue: ‘weblogic.kernel.Default (self-tuning)’}[com.bea.console.utils.MBeanUtils] – Getting connection with, Host = localhost @ port = 8001

This logging format is based on the configuration we have mentioned in log4j.xml:

<param name=”ConversionPattern” value=”%d{ISO8601} %-5p {%t}[%c] – %m%n”/>

10. If you want to change this logging format you can refer below link and confiure accordingly:

Note: You can configure log4j using log4j.xml or configuration files.

June 1, 2012

Configure Weblogic SQL authentication provider and create users programatically via WLST

Filed under: WebServer — vaishalipavashe @ 6:43 pm

We can use Admin console to create users in DB using SQL authenticator which will encrpt passwords and store in DB tables but when customer needs to add hundreads of users in DB whose passwords should be stored in encrypted form, we can use WLST script to perform the same as given below:

Follow below steps to configure SQL authenticator and execute WLST script:

A. Configure SQL authenticator:

  1. Start Oracle XE DB and open SQL propmt to execute below commands:
  3. Generally customers can add users directly in DB with help below commands:

    insert into USERS (U_NAME,U_PASSWORD,U_DESCRIPTION) values('system','weblogic','admin user');
    insert into GROUPS (G_NAME,G_DESCRIPTION) values('Administrators','Administrators');
    insert into GROUPMEMBERS (G_NAME,G_MEMBER) values('Administrators','system');

But in this case password is not encrypted so either you can add users via console or via WLST script to store them in encrypted form.

We had executed above commands just to verify user which is directly stored in DB gets authenticated properly or not from SQL authenticator configured as below

  1. Now start weblogic admin server and access console to create Data source by navigating Services ->JDBC -> Data sources
  2. Create Data source named SqlDS

    JNDI: SqlDS

    DB type: Oracle

    DB Driver: Oracle Thin XA driver

    DB name: XE

    DB host: <hostname>

    Port: 1521

    DB user: <username>

    DB password: <password>

  1. Keep rest of the configuration same and click on test Configuration. If its successful click on next and target it to “AdminServer”
  2. Click on Finish and activate chnages
  3. Now navigate to Security Realms -> myrealm -> Providers
  4. Click on New and provide Name as SqlAuthenticator and select Type as SQLAuthenticator
  5. Now click on newly created provider and make Control Flag as “Sufficient”
  6. Navigate to provider specific page:

    1. Check on Plaintext Passwords Enabled.

    2. Provide Data source Name: SqlDS

  7. Keep rest of the parameters as it is and Save this configuration. It will ask you to restart Admin server.
  8. Now again navigate Security Realms -> myrealm -> Users & groups

    Check user which was created directly in DB is listed in table with SqlAuthenticator, Once its listed go ahead and add users as below

B. Cretae users using Admin console:

  1. Login to Admin console
  2. Navigate to Security Realms -> myrealm -> Users & groups
  3. Click on users tab and try creating new user

    User name: <user name>

    Select Authentication provider: SqlAuthenticator

    User Password: <password>

  4. Once user is created check DB table, this user musted be added with encypted password

C. Create multiple users using WLST script:

  1. Navigave to $DOMAIN_HOME/bin folder and execute setDomainEnv file as below:

    Unix: . ./ (Do not forget to put two dots before / )

    Windows: setDomainEnv.cmd

  2. Now change below script as per your environment and execute as suggested in step 3:



NOTE: – Change user,password and ADMIN_URL in 1st line.

– Replace domain name ” base_domain’ with your domain name in line no: 5

– Chnage SQL authenticator name in line no: 6 as per your authenticator name

– Next lines create users. You need to add however users you need to create programatically.

– Syntax : cmo.createUser(‘user_name’,’user_password’,’user_description’)

  1. Now save these commands in a file with extention .py and execute as below:

# java weblogic.WLST

  1. If your script fails the try executing each command separately. For this start WLST session as below:

# java weblogic.WLST

Now execute commands specified in above script. You will be able to debug if anything went wrong while executing script.

April 23, 2012

Weblogic warning message BEA-149515 with Informix database

Filed under: WebServer — vaishalipavashe @ 10:57 pm

Weblogic server using Informix database version 11 gives below warning messages:
<Apr 23, 2012 10:49:50 AM EDT> <Warning> <JMX> <BEA-149515> <An error was encountered getting the attribute DriverVersion on the MBean com.bea:ServerRuntime=MS2,Name=AbcDS,Type=JDBCDataSourceRuntime during a call to getAttributes>
<Apr 23, 2012 10:49:50 AM EDT> <Warning> <JMX> <BEA-149515> <An error was encountered getting the attribute DriverName on the MBean com.bea:ServerRuntime=MS2,Name=AbcDS,Type=JDBCDataSourceRuntime during a call to getAttributes>
<Apr 23, 2012 10:49:50 AM EDT> <Warning> <JMX> <BEA-149515> <An error was encountered getting the attribute DatabaseProductVersion on the MBean com.bea:ServerRuntime=MS2,Name=AbcDS,Type=JDBCDataSourceRuntime during a call to getAttributes>

It seems DB dependent features will not be available at weblogic for few DBs listed below as per below certification matrix.

For these databases below, WebLogic Server supports application data access only, and does not support WebLogic Server database dependent features.
Ÿ DB2 v9.1 for z/OS
Ÿ Informix 11.0, Informix 11.5+
So either we can ignore this warning messages or we can supress them from coming into server logs with help of log filters as below:

  1. Configure a log filter first.
    1. Click on <domain-name> in the left pane. In the right pane, under Configuration –> Log filters, create a new log filter.
    2. Click on the newly created log filter and click on ‘Add Expression.’
    3. For the Expression, specify the following:
      Message Attribute: MSGID
      Operator: =
      Value: complete MessageId (for example: BEA-149515)
    4. Click on finish.
  2. Now select the expression, and click on the “Negate” button to include the “NOT” condition. Now the condition looks like this:
    NOT(MSGID = 'BEA-149515')
  3. Save and activate the changes.
  4. Now assign this filter to all servers.
    1. Click on the server to which this has to be configured.
    2. Go to Logging –> Advanced section.
    3. In the log file section, select the filter that is newly created.
    4. If the stout redirection is enabled, then specify the filter for stdout also.
  5. Restart the server.

April 22, 2012

Weblogic: Failure in heartbeat trigger for RJVM causing

Filed under: WebServer — vaishalipavashe @ 10:38 am

If you get failure in heartbeat trigger for RJVM messages in server log:

####<Mar 12, 2012 11:50:26 PM EDT> <Info> <RJVM> <abc> <TIG-1> <[ACTIVE] ExecuteThread: ‘8’ for queue: ‘weblogic.kernel.Default (self-tuning)’> <<WLS Kernel>> <> <> <1331610626152> <BEA-000513> <Failure in heartbeat trigger for RJVM: -545576065545537728C:, The connection manager to ConnectionManager for: ‘weblogic.rjvm.RJVMImpl@1217978 – id: ‘-545576065545537728C:,

TIGPROD:TIG-1’ connect time: ‘Mon Mar 12 22:31:35 EDT 2012” has already been shut down. The connection manager to ConnectionManager for: ‘weblogic.rjvm.RJVMImpl@1217978 – id: ‘-545576065545537728C:,

TIGPROD:TIG-1’ connect time: ‘Mon Mar 12 22:31:35 EDT 2012” has already been shut down


There is a possibility that a heartbeat trigger attempts to send a heartbeat message through a dead connection just before it is canceled by RJVM. Then the IOException can be logged. These are just info messages which were observed in WLS 10.3.0 which can be ignored but if customer wants to supress them apply patch provided in Internal Bug8247720 referred in main Bug 13651241. This chnage is added in WLS 10.3.1 and later versions.

To supress Failure in heartbeat trigger for RJVM messages apply patch provided in Bug8247720. Contact Oracle support to get official patch.

Weblogic server losses servlet mapping with SAS application

Filed under: WebServer — vaishalipavashe @ 10:29 am

Weblogic server with Sun JDK version lower than 1.6.0_27 have issues with SAS application where it looses servlet mapping. Application works for sometime and then at runtime it losses servlet mapping and starts giving 404 error. Below is a Weblogic server log and access log snippet taken before and after the issue occurred with Http and URLResolution debugs enabled:

Debug Http message shows runtime change as relUri gets chnaged from /remote/ to /SASWorkflowServices/remote/

Access Log: – – [03/Nov/2011:10:42:59 -0400] “POST /SASWIPServices/remote/urlGenerator HTTP/1.1” 200 325

Server Log:

####<Nov 1, 2011 2:23:12 PM EDT> <Debug> <URLResolution> <> <SASServer1> <ExecuteThread: ‘2’ for queue: ‘weblogic.socket.Muxer’> <> <> <> <1320171792869> <BEA-000000> <ServletContext@1814900662[app:sas.workflow9.3.ear module:/SASWorkflowServices path:/SASWorkflowServices spec-version:null]: resolving request with relUri: /remote/>

Access Log: – – [03/Nov/2011:10:43:02 -0400] “POST /SASWIPServices/remote/urlGenerator HTTP/1.1” 404 1214

Server Log:
####<Nov 1, 2011 2:23:12 PM EDT> <Debug> <URLResolution> <> <SASServer1> <ExecuteThread: ‘2’ for queue: ‘weblogic.socket.Muxer’> <> <> <> <1320171792909> <BEA-000000> <ServletContext@1814900662[app:sas.workflow9.3.ear module:/SASWorkflowServices path:/SASWorkflowServices spec-version:null]: resolving request with relUri: /SASWorkflowServices/remote/>

This is not WLS issue, its caused by JIT in java in all versions lower than 1.6.0_27.  This issue can be resolved in below 2 ways:

1. If you want to continue using same JDK, please apply this flag in JAVA_OPTIONS and it should resolve the issue:


2. Upgrade JDK to the version higher than 1.6.0_27. As its resolved in higher JDKs.

WLS10.3: Plugin1.1: SSL Handshake Fails With AES Cipher suites

Filed under: WebServer — vaishalipavashe @ 10:26 am

Weblogic server using Plugin 1.1 with below AES cipher suites in weblogic configuration gets below SSL handshake failed exception:



 Exception found in plugin log:

mod_weblogic(ssl): Connection mod_wl SSL handshake failed (28860)
mod_weblogic(ssl): SSL Handshake failed
wl_ssl_open failed. failed to initialize a secure connection
*******Exception type [SSL_INIT_ERROR] (wl_ssl_open failed. failed to initialize a secure connection) raised at line 1981 of ../nsapi/URL.cpp
and you should see the following in the weblogic stdout ssl debug, as the proxy fails to find a suitable ciphersuite for the ssl handshake with the server. (debug messages have been cut down for clarity)
&amp;amp;lt;HANDSHAKEMESSAGE: ClientKeyExchange RSA&amp;amp;gt;
&amp;amp;lt;28679195 received CHANGE_CIPHER_SPEC&amp;amp;gt;
&amp;amp;lt;HANDSHAKEMESSAGE: Finished&amp;amp;gt;
&amp;amp;lt;write CHANGE_CIPHER_SPEC, offset = 0, length = 1&amp;amp;gt; # my interpretation is, this is WLS telling the proxy to use one of the AES ciphers that it allows

It’s a bug with Plugin 1.1 and we need to apply a patch mentioned in below bug. Contact Oracle support to get official patch.

Bug: 12395815

For Solaris x86-64 platform:ARU13779576

For Solaris Sparc platform: ARU13779581

This patch will be officially added to FMW release 11gPS5, prior to this version we need to apply this patch to use above AES algorithms in Weblogic server configuration with plugin 1.1





Unbale to stop Weblogic Servers with https protocol in ADMIN_URL in stop scripts

Filed under: WebServer — vaishalipavashe @ 7:00 am

If we try stoping weblogic servers with t3s/https protocol in ADMIN_URL in stop scripts it gives below error when ONLY SSL ports are enabled:

<May 18, 2012 5:50:12 PM UTC> <Info> <Security> <BEA-090906> <Changing the default Random Number Generator in RSA CryptoJ from ECDRBG to FIPS186PRNG. To disable this change, specify>
This Exception occurred at Fri May 18 17:50:12 UTC 2012.
javax.naming.CommunicationException [Root exception is t3s:// Destination unreachable; nested exception is: General SSLEngine problem; No available router to destination]
at weblogic.jndi.internal.ExceptionTranslator.toNamingException(
at weblogic.jndi.WLInitialContextFactoryDelegate.toNamingException(
at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(
at weblogic.jndi.Environment.getContext(

As by default weblogic stop sripts creates at runtime uses t3/t3s protocols,  it fails with http/https protocol untill we enabling tunneling for weblogic servers.

echo “import os” >””
echo “if os.environ.has_key(‘wlsUserID’):” >>””
echo ”    wlsUserID = os.environ[‘wlsUserID’]” >>””
echo “if os.environ.has_key(‘wlsPassword’):” >>””
echo ”    wlsPassword = os.environ[‘wlsPassword’]” >>””
echo “connect(${userID} ${password} url=’${ADMIN_URL}’, adminServerName=’${SERVER_NAME}’)” >>””
echo “shutdown(‘${SERVER_NAME}’,’Server’)” >>””
echo “exit()” >>””

echo “Stopping Weblogic Server…”

${JAVA_HOME}/bin/java -classpath ${FMWCONFIG_CLASSPATH} ${MEM_ARGS} ${JVM_D64} ${JAVA_OPTIONS} weblogic.WLST  2>&1

echo “Done”


Please follow below procedure:

1. Replace t3 protocol with t3s/https in ADMIN_URL in both stop scripts as below:


if [ “$1” = “” ] ; then
if [ “${ADMIN_URL}” = “” ] ; then
export ADMIN_URL


if [ “$1” != “” ] ; then
if [ “${ADMIN_URL}” = “” ] ; then

2. Save these files and start Admin server

3. Start managed servers by giving t3s/https in ADMIN_URL in command line

4. Now login to Admin console and enable tunneling by navigating Environment -> servers. Click on server name and go to Protocols tab. Check in box associated with “Enable Tunneling” . Save this settings

5. Repeat step 4 for admin and managed servers. Save and activate changes

6. We need to add trust keystore related parameters in two scripts as given below: a) b) Please change them as per your environment. We need to add them in so that they will be available with all servers started via command line. We also need to add them in as we use WLST shutdown command to stop admin/managed servers, so this trust store is necessary to make connection and then shutting down servers:\wls103\user_projects\domains\cert\selfcerts\trust.jks %JAVA_OPTIONS%

7. Import CA root certificate to cacerts available in $WL_HOME/server/lib folder as cacerts is referred in So if you dont import it you will find managed server is unable to connect with Admin server when only SSL is enabled:

# keytool -import -alias rootcert -trustcacerts -file <location of root cert> -keystore cacerts -storepass changeit

6. Now try to stop managed server and Admin server

Next Page »

Blog at