"Alias folder SecureMode does not exist at path /SecurityConfiguration" error when discovering domain in WLS 12.1.3 version

[anatoliatanasov]

Trying to discover WLS 12.1.3 domain of which SOA Studio 12.1.3 integrated WebLogic Server is part of with the command:

./bin/discoverDomain.sh -oracle_home /opt/Applications/Oracle/soa_studio_1213 -skip_archive -model_file ./model.yaml -domain_home /opt/Applications/Oracle/soa_studio_1213/user_projects/domains/base_domain

raises the following error:

./bin/discoverDomain.sh -oracle_home /opt/Applications/Oracle/soa_studio_1213 -skip_archive -model_file ./model.yaml -domain_home /opt/Applications/Oracle/soa_studio_1213/user_projects/domains/base_domain


JDK version is 1.8.0_301-b09
JAVA_HOME = /opt/jdk1.8.0_301.jdk/Contents/Home
WLST_EXT_CLASSPATH = /opt/Applications/Oracle/weblogic-deploy/lib/weblogic-deploy-core.jar
CLASSPATH = /opt/Applications/Oracle/weblogic-deploy/lib/weblogic-deploy-core.jar
WLST_PROPERTIES = -Dcom.oracle.cie.script.throwException=true -Djava.util.logging.config.class=oracle.weblogic.deploy.logging.WLSDeployLoggingConfig 
/opt/Applications/Oracle/soa_studio_1213/oracle_common/common/bin/wlst.sh /opt/Applications/Oracle/weblogic-deploy/lib/python/discover.py -oracle_home /opt/Applications/Oracle/soa_studio_1213 -skip_archive -model_file ./model.yaml -domain_home /opt/Applications/Oracle/soa_studio_1213/user_projects/domains/base_domain

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

####<Jun 14, 2023 8:27:29 PM> <INFO> <WebLogicDeployToolingVersion> <logVersionInfo> <WLSDPLY-01750> <The WebLogic Deploy Tooling discoverDomain version is 3.2.0:.3f64264:May 11, 2023 00:30 UTC>
####<Jun 14, 2023 8:27:29 PM> <INFO> <WLSDeployLoggingConfig> <logLoggingDirectory> <WLSDPLY-01755> <The discoverDomain program will write its log to directory /opt/Applications/Oracle/weblogic-deploy/logs>
####<Jun 14, 2023 8:27:30 PM> <INFO> <ModelContext> <__copy_from_args> <WLSDPLY-01050> <WebLogic version for aliases is 12.1.3.0.0>
####<Jun 14, 2023 8:27:30 PM> <INFO> <discover> <main> <WLSDPLY-06024> <No variable file provided. Model passwords will contain the token '-- FIX ME --'>
####<Jun 14, 2023 8:27:45 PM> <INFO> <discover> <_get_domain_name> <WLSDPLY-06022> <Discover domain base_domain>
####<Jun 14, 2023 8:27:46 PM> <SEVERE> <discover> <main> <WLSDPLY-06011> <discoverDomain failed to discover domain base_domain at /opt/Applications/Oracle/soa_studio_1213/user_projects/domains/base_domain : Failed to get the WLST list path for location (model_folders = ['SecurityConfiguration', 'SecureMode'],  'name_tokens' = {'SECURITYCONFIGURATION': 'base_domain','DOMAIN': 'base_domain'}): Alias folder SecureMode does not exist at path /SecurityConfiguration>

Issue Log for discoverDomain version 3.2.0 running WebLogic version 12.1.3.0.0 offline mode:

SEVERE Messages:

        1. WLSDPLY-06011: discoverDomain failed to discover domain base_domain at /opt/Applications/Oracle/soa_studio_1213/user_projects/domains/base_domain : Failed to get the WLST list path for location (model_folders = ['SecurityConfiguration', 'SecureMode'],  'name_tokens' = {'SECURITYCONFIGURATION': 'base_domain','DOMAIN': 'base_domain'}): Alias folder SecureMode does not exist at path /SecurityConfiguration

Total:   SEVERE :    1  WARNING :    0

discoverDomain.sh failed (exit code = 2)

The command is run against WLDT vanilla installation where the ${WLDT_HOME}/lib/typedefs/WLS.json is changed to:

{
    "copyright": "Copyright (c) 2017, 2019, Oracle Corporation and/or its affiliates.  All rights reserved.",
    "license": "Licensed under the Universal Permissive License v 1.0 as shown at https://oss.oracle.com/licenses/upl",
    "name": "WLS",
    "description": "WLS type domain definitions",
    "versions": {
        "10.3.6": "WLS_11G",
        "12.1.1": "WLS_11G",
        "12.1.2": "WLS_12CR1",
        "12.1.3": "WLS_12CR1",
        "12.2.1": "WLS_12CR2",
        "12.2.1.3": "WLS_12CR2",
        "12.2.1.4": "WLS_12CR2",
        "14.1":     "WLS_14"
    },
    "definitions": {
        "WLS_11G": {
            "baseTemplate": "@@WL_HOME@@/common/templates/domains/wls.jar",
            "extensionTemplates": [ ],
            "customExtensionTemplates": [ ],
            "serverGroupsToTarget": [ ],
            "rcuSchemas": [ ]
        },
        "WLS_12CR1": {
            "baseTemplate": "Basic WebLogic Server Domain",
            "extensionTemplates": [ ],
            "customExtensionTemplates": [ ],
            "serverGroupsToTarget": [ ],
            "rcuSchemas": [ ]
        },
        "WLS_12CR2": {
            "baseTemplate": "Basic WebLogic Server Domain",
            "extensionTemplates": [ ],
            "customExtensionTemplates": [ ],
            "serverGroupsToTarget": [ ],
            "rcuSchemas": [ ]
        },
        "WLS_14": {
            "baseTemplate": "Basic WebLogic Server Domain",
            "extensionTemplates": [ ],
            "customExtensionTemplates": [ ],
            "serverGroupsToTarget": [ ],
            "rcuSchemas": [ ]
        }
    }
}

I suppose the SecureModeMBean appears in newer version, but I cannot find a way to enforce older version of the config mbeans hierarchy.

[robertpatrick]

@anatoliatanasov Can you please provide the complete log file?

[robertpatrick]

I believe that this is all related to #1466. The SecureMode folder is already filtered out in versions prior to 12.2.1 so clearly, the version is not being set properly during tool initialization. This is just a side effect of the previous problem.

[anatoliatanasov]

@anatoliatanasov Can you please provide the complete log file?

Please, find the log file attached.

discoverDomain.log

[anatoliatanasov]

I believe that this is all related to #1466. The SecureMode folder is already filtered out in versions prior to 12.2.1 so clearly, the version is not being set properly during tool initialization. This is just a side effect of the previous problem.

From the analysis and debugging I did yesterday it seems that the version verification for the SecureMode model folder / mbean the version check says that it should not be processed, but the actual processing occurs, i.e. the VersionUtils functions work OK, but the result is not properly treated.

The problematic part is in the discover.py's _establish_secure_mode function.

[anatoliatanasov]

If interested I managed to work that problem around with this piece of code in discover.py's _establish_secure_mode function.
I replaced the code in lines 322 - 324, that is:

secure_mode_location.append_location(model_constants.SECURE_MODE)
secure_mode_path = aliases.get_wlst_list_path(secure_mode_location)
secure_mode_token = helper.get_singleton_name(secure_mode_path)

with

# Patched by anatoli.atanasov@expleo.pro
# For domains of WLS version 12.1.3 and earlier there is no SecureModeMBean/SecureModeEnabled causing
# runtime errors using the discoverDomain. 
# The SecureModeMBean/SecureModeEnabled attribute is examined and if missing, error is suppressed.
try:
    # Tries to get value of SecureModeMBean.isSecureModeEnabled() method
    helper.get(model_constants.SECURE_MODE_ENABLED)
    secure_mode_location.append_location(model_constants.SECURE_MODE)
    secure_mode_path = aliases.get_wlst_list_path(secure_mode_location)
    secure_mode_token = helper.get_singleton_name(secure_mode_path)
except DiscoverException, ex:
    e = ex
    while True:                
        if(not e.getCause() and isinstance(e, java.lang.NoSuchMethodException)):
            __logger.warning('#################### PATCHed logic by anatoli.atanasov@expleo.pro START ####################', class_name='discover-py', method_name=_method_name)
            __logger.warning(str(e.getMessage()), class_name='discover-py', method_name=_method_name)
            __logger.warning('#################### PATCHed logic by anatoli.atanasov@expleo.pro END ####################', class_name='discover-py', method_name=_method_name)
            secure_mode_token = None
            break

        e = e.getCause()

With this modification the discoverDomain.sh tool completes with a few warnings, but I don't think this is a sustainable solution.

[robertpatrick]

Yeah, that's not the right way to fix this but thanks for your effort. We will get both issues fixed as soon as possible and will cut a 3.2.1 release that resolves both issues.

[robertpatrick]

Fixed in release 3.2.1