Showing posts with label WEBLOGIC. Show all posts
Showing posts with label WEBLOGIC. Show all posts

Monday, August 21, 2023

Failed hostname verification check when using SSL Certificates with Wildcards in WebLogic Server (Doc ID 1377479.1)

 

SYMPTOMS

 When using SSL Certificates with Wild Cards in WebLogic Server from weblogic 9.2 to 10.3.5. as below

CN=*.<Fully-Qualified-Domain-Name>

you can see the following error:

Caused by: javax.net.ssl.SSLKeyException: [Security:090504]Certificate chain received from <HOSTNAME> - <IP> failed hostname verification check. Certificate contained *.domain but check expected <HOSTNAME>

 

 

CHANGES

 

CAUSE

This issue is caused due to Default BEA hostname verifier is configured with WLS. Weblogic does not handle/support wildcard certificates out of the box. When weblogic initiates a connection over SSL, it makes a call to the HostnameVerifier. The default BEA hostname verifier matches the hostname you are connecting to and the CN of the certificate.

SOLUTION

To fix this issue there are three solutions:

1. Disable the Default BEA hostname verifier in WLS.

2. Write a custom hostname verifier and configure it with WLS.

3. For some WLS versions there is also patch for Bug 10215257 available for download.

 

Disable the Default BEA hostname verifier in WLS

Login to Admin console --> Click on servers --> SSL --> Advanced --> from the dropdown menu next to Hostname verification select --> None

Alternatively, you can add to JAVA_OPTIONS -Dweblogic.security.SSL.ignoreHostnameVerification=true to achieve the same.

If you are using Node Manager, please check this document:

 

WebLogic Server: Procedure for configuring Node Manager with SSL. (Doc ID 1142995.1)

 

Write a custom hostname verifier and configure it with WLS

This is described in Oracle Documentation:

Configure a custom host name verifier
Using a Custom Hostname Verifier


Hostname Verifier Sample Code Fragment
:


package examples.security.sslclient;

import java.io.ByteArrayInputStream;
import java.security.cert.Certificate;
import java.security.cert.CertificateFactory;
import java.security.cert.X509Certificate;
import java.util.logging.Logger;
import java.util.regex.Matcher;
import java.util.regex.Pattern;

import javax.net.ssl.SSLSession;

public class TestHostnameVerifier implements weblogic.security.SSL.HostnameVerifier {

    private final static Logger log = Logger.getLogger(TestHostnameVerifier.class.getCanonicalName());

    @Override
    public boolean verify(String hostname, SSLSession session) {


        try {
            Certificate cert = session.getPeerCertificates()[0];

            byte[] encoded = cert.getEncoded();

            CertificateFactory cf = CertificateFactory.getInstance("X.509");
            ByteArrayInputStream bais = new ByteArrayInputStream(encoded);

            X509Certificate xcert = (X509Certificate) cf.generateCertificate(bais);

            String cn = getCanonicalName(xcert.getSubjectDN().getName());

            log.info("CN: '" + cn + "'" + " HOSTNAME: '" + hostname + "'");

           
            // If CN is equals to Hostname then it is approved
            if (cn.equals(hostname)) {
                return true;
            }

            // Compile regular expression
            // here we set the wildcard and the rest of the URL inside, could be more generic too.
            
            cn = cn.replace(".", "\\.");
            cn = cn.replace("-", "\\-");
            cn = cn.replace("*", "[-.*aA-zZ0-9]+");
           
            Pattern pattern = Pattern.compile(cn);
           
            // Determine if there is an exact match
            CharSequence inputStr = hostname;
            Matcher matcher = pattern.matcher(inputStr);
            boolean matchFound = matcher.matches();
           
            if (matchFound==false) {
                log.info("pattern doesn't match hostname");
            }
           
            //return boolean value
            return matchFound;       

        } catch (Exception e) {
            e.printStackTrace();
        }

        return true;
    }

    /**
     * Returns just the canonical name from the distinguishedName on the cert.
     *
     *
     */
    private String getCanonicalName(String subjectDN) {

        Pattern pattern = Pattern.compile("CN=([-.*aA-zZ0-9]*)");
        Matcher matcher = pattern.matcher(subjectDN);

        if (matcher.find()) {
            return matcher.group(1);
        }

        log.info("Couldn't find match for CN in subject");
        return subjectDN;

    }

}

To compile and package into a jar file

i. Navigate to <WLS_HOME>/user_projects/domains/<DOMAINNAME>/bin
ii. Set up an environment by executing: $ . ./setDomainEnv.sh This will include weblogic.jar into classpath, in order to use any of the libraries included under package weblogic.*
iii. Compile the class by copying the content of the code above and naming the file as:


TestHostnameVerifier.java


iv. Run javac to compile the class.


$javac TestHostnameVerifier.java

v. Package the compiled class into a jar file by executing:


$jar cvf TestHostnameVerifier.jar TestHostnameVerifier.class


Expected output is:


stnameVerifier.class
added manifest
adding:TestHostnameVerifier.class(in = 363) (out= 363)(stored 0%)



vi. This will produce a file called:

TestHostnameVerifier.jar

 

When attempting to use the Custom Hostname Verifier, you might experience the following error:

<Error> <WebLogicServer> <AdminServer> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <ECID> <BEA-000297> <Inconsistent security configuration, weblogic.utils.NestedRuntimeException: [Security:090563]Cannot create instance of Hostname Verifier WildcardHostnameVerifier.WildcardHostnameVerifier.>
<Emergency> <Security> <AdminServer> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <ECID> <BEA-090034> <Not listening for SSL, java.io.IOException: [Security:090563]Cannot create instance of Hostname Verifier WildcardHostnameVerifier.WildcardHostnameVerifier..>

The issue is caused by Custom Hostname Verifier is not in the classpath.

To fix this issue:

i. Modify setDomainEnv.cmd/setDomainEnv.sh adding:

set CLASSPATH=%CUSTOMHOSTNAMEVERIFIERCLASSPATH%;%CLASSPATH%

ii. Restart WebLogic Server and re test the issue.  

For some WLS versions there is also patch for Bug 10215257 available for download

Patch 10215257  is available to enhance the existing default BEA hostname verifier. This means that you do not need to turn off Hostname verification OR write a custom hostname verifier to use Wildcard certificates from WLS. Once the patch is applied wildcard certificates are accepted by WLS.

This patch extends the "default" hostname verifier (SSLWLSHostnameVerifier) to support a certificate's Subject Alternative Name (SAN) field, DNS Name type only.  As an example, please go to this URL: 

https://www.digicert.com/subject-alternative-name.htm

 and view the certificate using your browser, select the Subject Alternative Name field, to view a list of domains secured by a single SSL certificate.  List provided here for convenience (DNS Name=www.digicert.com, DNS Name=www.origin.digicert.com, DNS Name=content.digicert.com, DNS Name=digicert.com).  SANs cannot be wildcarded because the standards that define SAN functionality do not support wildcarded values.
 
Additionally, a new custom hostname verifier (SSLWLSWildcardHostnameVerifier) was implemented, derived from the default hostname verifier, so that it supports everything the default hostname verifier does, including SANs.   You must  configure your WebLogic server to use this custom hostname verifier if support for wildcard certificates is required during SSL handshake.  One option is to use the following WebLogic property: 

-Dweblogic.security.SSL.hostnameVerifier=weblogic.security.utils.SSLWLSWildcardHostnameVerifier

Additional information can be found in Oracle Documentation:
 http://download.oracle.com/docs/cd/E21764_01/web.1111/e13711/ssl_client.htm#i1029782

 

Patches are available for Bug 10215257:

PATCH INFORMATION
WLS VersionPatch Number
10.3Patch: 10215257
10.3.2Patch: 10215257
10.3.4Patch: 10215257
10.3.5Patch: 10215257

 This issue is fixed in 10.3.6.

To apply one of these patches, download the patch from My Oracle Support by searching for the patch number for your WLS version: for detailed instructions, please see Primary Note: How to Locate and Download Patches for WebLogic Server Using My Oracle Support Note:1302053.1. For instructions on how to apply these patches to your system, please see How to Apply WebLogic Server (WLS) Patches Using Smart Update Note:876004.1. For other issues relating to Smart Update, please see Primary Note on Troubleshooting Smart Update Issues Note:1230725.1

Patches are specifically tied to a particular release and maintenance pack of WebLogic Server (WLS). A patch for WLS 10.3.6, for example, very likely would not work on WLS 10.3.5. In a few cases, patches are also specific to particular operating systems. If you think you are experiencing the problem outlined in this note, and you are running a WLS version which is eligible for error correction (see Note:950131.1; for more about the Oracle Error Correction Policy), but your WLS version is not included in the list of patches provided here, please contact support and ask for a version of the patch appropriate for you. Please reference this note as well as this bug number to help speed our service for you.

 

REFERENCES

http://download.oracle.com/docs/cd/E21764_01/web.1111/e13711/ssl_client.htm#i1029782
NOTE:1142995.1 - WebLogic Server: Procedure for Configuring Node Manager with SSL
http://docs.oracle.com/cd/E21764_01/web.1111/e13711/ssl_client.htm#i1029782
http://docs.oracle.com/cd/E21764_01/apirefs.1111/e13952/taskhelp/security/ConfigureACustomHostNameVerifier.html



Wednesday, September 28, 2022

Delete a node from application Tier in Oracle Apps R12.2

 

Delete a node from application Tier in Oracle Apps R12.2 in shared application file system.


.4 Deleting an Application Tier Node


Note: These steps are ONLY for deletion of secondary application tier nodes. The primary application tier node cannot be deleted using these steps.

The following steps should be performed to delete a secondary application tier node from an existing Oracle E-Business Suite Release 12.2 multi-node instance. The steps described in this section are applicable to secondary application tier nodes with shared and non-shared file systems.

Note: In case OHS is enabled only on the secondary node being deleted, OHS needs to first be enabled on some other node before starting with deletion of the node.

Before performing the following steps, ensure that the WebLogic administration server is running from both the Run and Patch Edition File Systems of the primary application tier node.

Note: Do not perform a 'delete node' operation when a patching cycle is active.
  1. Delete the run file system and patch file system configuration of the secondary application tier node.


    Note: Deletion of nodes may need to be performed in two scenarios - when the node is still accessible (users are able to login to the node) and in the remote case when the node is not accessible due to some issues ( the node may not be physically present and/or login to the node is not possible).

    In the first scenario, all information related to the node has to be cleaned up altogether (including removal of references from the WebLogic domain and EBS topology as well as removal of the file system and inventory references). Case 1 describes the steps to be performed in this scenario.

    In the second scenario, references to the node can be cleaned up only from the WebLogic domain and the EBS topology. The steps for deletion of secondary nodes in this scenario are described in Case 2 below. Please note that this option has been introduced in R12.TXK.C.DELTA.6 and is not available in the earlier releases.

    In order to keep the E-Business Suite instance in a consistent state, steps should be followed strictly based on the scenario.


    Case 1: If the secondary node to be deleted is accessible, run the following steps:

    1. Login to the secondary node to be deleted.

    2. Source the run file system.

    3. Ensure that all application tier services from the run and patch file system for the node to be deleted are shut down.

    4. Run the ebs-delete-node option of the adProvisionEBS.pl script as follows:
      $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-delete-node \
      -contextfile=<CONTEXT_FILE> -logfile=<LOG_FILE>
      This will delete the managed servers, OHS instances and Node Manager on the current node from the run file system WebLogic domain.

    5. If the node is a non-shared node, verify and remove the following Oracle Home entries of both the Run and Patch file systems from the Oracle Inventory:

      • <FMW_HOME>/webtier
      • <FMW_HOME>/oracle_common
      • <FMW_HOME>/Oracle_EBS-app1

      If any of the above Oracle Home entries are already registered in Oracle Inventory, you can run the following command to de-register or detach that Oracle Home:
      $ cd <Oracle Home>/oui/bin
      $ ./runInstaller -detachhome ORACLE_HOME=<Oracle Home Location>
       [-invPtrLoc <s_invPtrLoc>]
      Here,
      -invPtrLoc 
      argument needs to be specified only if the 'EBS installation central' inventory is being used.
      s_invPtrLoc is the context variable that stores the inventory pointer location.

      For example:
      $ cd /u02/r122/fs1/FMW_Home/oracle_common/oui/bin
      $ ./runInstaller -detachhome \
      ORACLE_HOME=/u02/r122/fs1/FMW_Home/oracle_common -silent
      Note: The Oracle Home <FMW_HOME>/webtier should be de-registered from the Oracle Inventory before trying to remove the Oracle Home <FMW_HOME>/oracle_common.

    6. If the node is a non-shared node, verify and remove the following Oracle Home entry from the Oracle Inventory:

      <OracleAS Tools 10.1.2 ORACLE_HOME>


      If the above Oracle Home entry is registered in Oracle Inventory, you can run the following command to de-register the Oracle Home:
      $ ./runInstaller -removeHome ORACLE_HOME=<s_tools_oh> -silent
      Here,
      -invPtrLoc 
      argument needs to be specified only if the 'EBS installation central' inventory is being used.
      s_invPtrLoc is the context variable that stores the inventory pointer location.

      For example:
      $ cd /u02/r122/fs1/EBSapps/10.1.2/oui/bin
      $ ./runInstaller -removeHome \
      ORACLE_HOME=/u02/r122/fs1/EBSapps/10.1.2 -silent


    Case 2: If the secondary node to be deleted is not accessible, run the following steps to remove the node from the FND topology and the EBS domain:

    1. Login to the primary node.

    2. Source the run file system.

    3. Run the ebs-delete-node option of the adProvisionEBS.pl script as follows:
      $ perl <AD_TOP>/patch/115/bin/adProvisionEBS.pl ebs-delete-node \
      -contextfile=<CONTEXT_FILE> -hostname=<HOSTNAME OF NODE TO BE DELETED> -logfile=<LOG_FILE>
      This will delete all information corresponding to the specified node from the Weblogic domain like the managed servers, OHS instances and Node Manager of the specified node from both the run and patch file system WebLogic domain. In addition, it will also remove the node from the list of active nodes registered in the topology.


      Note: Since the steps mentioned in Case 2 take care of only partial cleanup of the node, these steps should be performed only in case the node to be deleted is not accessible due to some issues. In all other scenarios, the nodes should be deleted by following steps mentioned in Case1. Otherwise, this may lead to the E-Business Suite instance being in an inconsistent state.


  2. Sync the OHS configuration on the other nodes to remove references of the deleted node.

    Perform the following steps on the other nodes:
    1. Source the run file system.

    2. If any of the managed servers from the deleted node are part of the cluster configuration defined on the current node, run the following command to delete details of these managed servers from the OHS configuration files mod_wl_ohs.conf and apps.conf on the current node:
      $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl \
        -contextfile=<CONTEXT_FILE> \
        -configoption=removeMS \
        -oacore=<host>.<domain>:<port> \
        -oafm=<host>.<domain>:<port> \
        -forms=<host>.<domain>:<port> \
        -formsc4ws=<host>.<domain>:<port> \
        -ekanban=<host>.<domain>:<port> \ 
        -accessgate=<host>.<domain>:<port> \
        -yms=<host>.<domain>:<port>
      where
      • The argument contextfile accepts the complete path to the context file.
      • The arguments oacore, oafm, forms, formsc4ws, ekanban, accessgate and yms accept a comma-separated list of managed server details in the following format:
        <host>.<domain>:<port>
        • host, domain and port are the hostname, domain and port of the managed server whose reference is to be deleted.

      For example, if the deleted node was on host 'testserver1' and domain 'example.com' and it contained managed servers oacore_server3 and oafm_server3 with ports 7205 and 7605 respectively, the following command should be run to remove references to these managed servers:
      $ perl <FND_TOP>/patch/115/bin/txkSetAppsConf.pl -contextfile=<CONTEXT_FILE>
      -configoption=removeMS -oacore=testserver1.example.com:7205 -oafm=testserver1.example.com:7605
  3. Review and update the value of the context variable 's_shared_file_system' on the primary node (required only while deleting a shared file system node).

    If the deleted node was the only node sharing the file system with a primary application tier node, run the following steps on the primary node:

    1. Set the value of the context variable 's_shared_file_system' in the run context file of the primary node to 'false' via the Oracle Applications Manager.

    2. Login to the primary node.

    3. Source the run file system.

    4. Run AutoConfig as follows:

      On UNIX:

      $ sh <ADMIN_SCRIPTS_HOME>/adautocfg.sh
      On Windows:

      C:\> <ADMIN_SCRIPTS_HOME>\adautocfg.cmd

  4. Run AutoConfig on the database tier.

    1. Log in to the database tier node.

    2. Run AutoConfig on the database tier by running the following command:

      For UNIX:
      $ <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/adautocfg.sh
      For Windows:
      C:>\ <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\adautocfg.cmd
      This step is required to sync-up the tcp.invited_nodes attribute in sqlnet.ora to remove the deleted node from the value of this attribute.
       
    3. Restart the database listener by running the following command:
       
      For UNIX:
      $ sh <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/addlnctl.sh stop <ORACLE_SID>
      $ sh <RDBMS_OH>/appsutil/scripts/<CONTEXT_NAME>/addlnctl.sh start <ORACLE_SID>
      For Windows:
      C:\> <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\addlnctl.cmd stop <ORACLE_SID>
      C:\> <RDBMS_OH>\appsutil\scripts\<CONTEXT_NAME>\addlnctl.cmd start <ORACLE_SID>
Notes:
  • Using the ebs-delete-node option as mentioned above will not delete the contents of the file system. This has to be done manually by the customer once the above steps to delete the node are completed successfully.

    For non-shared node, the following directories can be deleted:

    • <NE_BASE>
    • <RUN_BASE>
    • <PATCH_BASE>
    • EBSapps.env

    For a shared file system node, only the <INST_TOP> directory of the Run Edition File System and the Patch Edition File System should be deleted.

  • On all OHS enabled nodes, patch file system OHS configuration will automatically be synced up during next adop prepare phase.


Cloning Oracle E-Business Suite Release 12.2 with Rapid Clone (Doc ID 1383621.1)

Thursday, September 17, 2020

 We installed a Fusion Middleware report and Forms 12.2.1.2.0 on a Linux Server.

This was a single node Reports and Forms servers.
After disabling the Non SSL Listen Port, we get below error in logs while starting the Managed Server with only SSL ports enabled.

####<Oct 27, 2017, 2:38:23,265 PM CEST> <Info> <Deployer> <host01.example.com> <WLS_FORMS> <[ACTIVE] ExecuteThread: '1' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <728708fe-00a1-4078-bb31-f12fb2c6beae-00000030> <1509107903265> <[severity-value: 64] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-149060> <Module dms.war of application DMS Application [Version=12.2.1.1.0] successfully transitioned from STATE_ACTIVE to STATE_ADMIN on server WLS_FORMS.>
####<Oct 27, 2017, 2:38:23,765 PM CEST> <Critical> <WebLogicServer> <host01.example.com> <WLS_FORMS> <main> <<WLS Kernel>> <> <728708fe-00a1-4078-bb31-f12fb2c6beae-00000031> <1509107903765> <[severity-value: 4] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000386> <Server subsystem failed. Reason: A MultiException has 4 exceptions. They are:
1. java.lang.AssertionError: No replication server channel for WLS_FORMS
2. java.lang.IllegalStateException: Unable to perform operation: post construct on weblogic.cluster.replication.ReplicationService
3. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.cluster.singleton.SingletonServicesBatchManager errors were found
4. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.cluster.singleton.SingletonServicesBatchManager
 
A MultiException has 4 exceptions. They are:
1. java.lang.AssertionError: No replication server channel for WLS_FORMS
2. java.lang.IllegalStateException: Unable to perform operation: post construct on weblogic.cluster.replication.ReplicationService
3. java.lang.IllegalArgumentException: While attempting to resolve the dependencies of weblogic.cluster.singleton.SingletonServicesBatchManager errors were found
4. java.lang.IllegalStateException: Unable to perform operation: resolve on weblogic.cluster.singleton.SingletonServicesBatchManager
at org.jvnet.hk2.internal.Collector.throwIfErrors(Collector.java:89)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:249)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1213)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1144)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:666)
at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:640)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:406)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)
Caused By: java.lang.AssertionError: No replication server channel for WLS_FORMS
at weblogic.cluster.replication.ReplicationManagerServerRef.initialize(ReplicationManagerServerRef.java:128)
at weblogic.cluster.replication.ReplicationManagerServerRef.<clinit>(ReplicationManagerServerRef.java:84)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at weblogic.rmi.internal.BasicRuntimeDescriptor.getServerReferenceClass(BasicRuntimeDescriptor.java:496)
at weblogic.rmi.internal.BasicRuntimeDescriptor.createServerReference(BasicRuntimeDescriptor.java:452)
at weblogic.rmi.internal.OIDManager.makeServerReference(OIDManager.java:193)
at weblogic.rmi.internal.OIDManager.getReplacement(OIDManager.java:173)
at weblogic.rmi.utils.io.RemoteObjectReplacer.replaceRemote(RemoteObjectReplacer.java:107)
at weblogic.rmi.utils.io.RemoteObjectReplacer.replaceObject(RemoteObjectReplacer.java:90)
at weblogic.rmi.extensions.server.ServerHelper.exportObject(ServerHelper.java:252)
at weblogic.cluster.replication.ReplicationServicesImplBase.exportSelf(ReplicationServicesImplBase.java:17)
at weblogic.cluster.replication.ReplicationManager.startService(ReplicationManager.java:305)
at weblogic.cluster.replication.ReplicationService.start(ReplicationService.java:46)
at weblogic.server.AbstractServerService.postConstruct(AbstractServerService.java:76)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.glassfish.hk2.utilities.reflection.ReflectionHelper.invoke(ReflectionHelper.java:1262)
at org.jvnet.hk2.internal.ClazzCreator.postConstructMe(ClazzCreator.java:332)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:374)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceLocatorImpl.getService(ServiceLocatorImpl.java:693)
at org.jvnet.hk2.internal.ThreeThirtyResolver.resolve(ThreeThirtyResolver.java:78)
at org.jvnet.hk2.internal.ClazzCreator.resolve(ClazzCreator.java:211)
at org.jvnet.hk2.internal.ClazzCreator.resolveAllDependencies(ClazzCreator.java:234)
at org.jvnet.hk2.internal.ClazzCreator.create(ClazzCreator.java:357)
at org.jvnet.hk2.internal.SystemDescriptor.create(SystemDescriptor.java:471)
at org.glassfish.hk2.runlevel.internal.AsyncRunLevelContext.findOrCreate(AsyncRunLevelContext.java:232)
at org.glassfish.hk2.runlevel.RunLevelContext.findOrCreate(RunLevelContext.java:85)
at org.jvnet.hk2.internal.Utilities.createService(Utilities.java:2020)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:114)
at org.jvnet.hk2.internal.ServiceHandleImpl.getService(ServiceHandleImpl.java:88)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.oneJob(CurrentTaskFuture.java:1213)
at org.glassfish.hk2.runlevel.internal.CurrentTaskFuture$QueueRunner.run(CurrentTaskFuture.java:1144)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:666)
at weblogic.invocation.ComponentInvocationContextManager._runAs(ComponentInvocationContextManager.java:348)
at weblogic.invocation.ComponentInvocationContextManager.runAs(ComponentInvocationContextManager.java:333)
at weblogic.work.LivePartitionUtility.doRunWorkUnderContext(LivePartitionUtility.java:54)
at weblogic.work.PartitionUtility.runWorkUnderContext(PartitionUtility.java:41)
at weblogic.work.SelfTuningWorkManagerImpl.runWorkUnderContext(SelfTuningWorkManagerImpl.java:640)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:406)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:346)
>
####<Oct 27, 2017, 2:38:23,815 PM CEST> <Notice> <WebLogicServer> <host01.example.com> <WLS_FORMS> <main> <<WLS Kernel>> <> <728708fe-00a1-4078-bb31-f12fb2c6beae-00000031> <1509107903815> <[severity-value: 32] [rid: 0] [partition-id: 0] [partition-name: DOMAIN] > <BEA-000365> <Server state changed to FAILED.>

Even if no cluster is used, the default Reports and Forms domain configuration creates a WebLogic Cluster.

To solve “Servers do not have a common channel to communicate over” errors do the following steps as administrator

  1. Login into the Administration Console
  2. Expand the Environment tab and navigate to Clusters
  3. Select the and click ‘Replication’ subtab in the Configuration TAB
  4. Find Replication Channel, check box beside “Secure Replication Enabled” (to set it as true)
  5. Save
  6. Rerun the steps 2 to 5 for all clusters
  7. Activate the changes
  8. Restart the full WebLogic domain

or in WLST:
Start wlst.sh and connect to the WebLogic Domain

connect('user','password','t3s://host01.example.com:7002')
 
startEdit()
 
cd('/Clusters/cluster_forms')
cmo.setClusterType('none')
cmo.setPersistSessionsOnShutdown(false)
cmo.setReplicationChannel('ReplicationChannel')
cmo.setSecureReplicationEnabled(true)
 
save()
activate()

Rerun the same for the reports_cluster

Once done restart the full WebLogic Domain


https://blog.dbi-services.com/new-installed-fusion-middleware-12c-reports-or-forms-weblogic-servers-fails-to-start-after-configuring-ssl/

Oracle E-Business Suite Release 12.2 System Schema Migration

In This Document Section 1: Overview of the EBS System Schema Section 2: Requirements for Using the EBS System Schema Section 3: Migrating t...