If you learned something
today, please
1x

Fixing component Load failed with IOException Error when Configuring OHS with OEM

December 30th, 2011
No Gravatar

I ran across this today. It took me a long time to find the right solution, so I thought I would post it here.

The error message I was getting was:

Failed to invoke operation load on MBean oracle.as.management.
mbeans.register:type=component,name=ohs1,instance=asinst_1,
Location=AdminServer
Load failed with IOException

The logs further showed the following:

OHS-2079 nzos handshake error, nzos_Handshake returned
28860(server obscured.server.com:9999, client 111.127.66.159)
OHS-2171 NZ Library Error: SSL fatal alert

The fix I found towards the end of a thread at https://forums.oracle.com/forums/thread.jspa?threadID=1054032:

ORACLE_HOME\opmn\bin\upgradenonj2eeapp.bat
-oracleInstance Instance_Home_Location
-adminHost WebLogic_Server_Host_Name
-adminPort administration_server_port_number
-adminUsername administration_server_user

Change it to .sh for Linux/Unix. I found I only had to run this on the first server in the farm rather than all of them as one might expect. Your mileage may vary.

WLS 10.3.x Silent Install Gotcha

December 27th, 2011
No Gravatar

I ran into an issue where I couldn’t figure out why I was getting the following error when running a WebLogic Server 10.3.2 upgrade in silent mode pert the documentation:

C:\temp\ten_two_domain1>java weblogic.Upgrade -mode silent
-type domain Calling Wizard framework for upgrade: args2:
[-mode=silent,-file=wcf/plugin_silent_wizard.xml,
-p:plugin:plugin.silent.response.file=weblog
ic-upgrade-domain-responses.xml,
-log=stdout,-p:plugin:plugin.executionPlan.file=weblogic/
upgrade/domain/execplan.xml,-p:plugin:I18N_PLUGI N=weblogic/
upgrade/i18n_upgrade,
-p:plugin:TARGET_VERSION=10.3.2.0] 2011-05-03 12:12:25,926
ERROR [inputAdapter_silent] com.bea.plateng.wizard.
WizardController - Uncaught Exception java.lang.
ArrayIndexOutOfBoundsException: 0 at weblogic.upgrade.domain.
directoryselection.SelectWebLogicVersionPlugIn.
validateInputAdapter(SelectWebLogicVersionPlugIn.java:50) at
com.bea.plateng.wizard.plugin.silent.tasks.
InputAdapterSilentTask.execute(InputAdapterSilentTask.java:178)
at com.bea.plateng.wizard.silent.tasks.AbstractSilentTask.
run(AbstractSilentTask.java:28) at java.lang.Thread.run(
Thread.java:619) A fatal error has occurred. This application
will terminate.

I thought I had followed the example from http://docs.oracle.com/cd/E15523_01/web.1111/e13754/xml_ref.htm#g1066162 perfectly:

<?xml version="1.0" encoding="UTF-8"?>

<plugin-silent-responses>
</plugin-silent-responses>

<!-- SAMPLE BELOW -->
<!--
<plugin-silent-responses>
  <group name="DomainSelectionGroup">
    <plugin name="SelectWebLogicVersionPlugIn">
      <input-adapter name="ChoiceIA">
        <bind-property name="selectedChoiceIds">
          <value>__WEBLOGIC_VERSION__</value>
        </bind-property>
      </input-adapter>
    </plugin>
    <plugin name="DomainDirectorySelectionPlugIn">
      <input-adapter name="IA">
        <bind-property name="selectedFile">
          <value>__DOMAIN_DIR__</value>
        </bind-property>
      </input-adapter>
    </plugin>
  </group>
  <group name="PostDirSelectionGroup">
    <plugin name="AdminServerSelectionPlugIn">
      <input-adapter name="IA">
        <bind-property name="selectedChoiceIds">
          <value>__ADMIN_SERVER_NAME__</value>
        </bind-property>
      </input-adapter>
    </plugin>
    <plugin name="NodeManagerCredentialsPlugIn">
      <input-adapter name="UsernameIA">
        <bind-property name="value">
          <value>__NODE_MANAGER_USERNAME__</value>
        </bind-property>
      </input-adapter>
      <input-adapter name="PasswordIA">
        <bind-property name="value">
          <value>__NODE_MANAGER_PASSWORD__</value>
        </bind-property>
      </input-adapter>
      <input-adapter name="PasswordConfirmIA">
        <bind-property name="value">
          <value>__NODE_MANAGER_PASSWORD__</value>
        </bind-property>
      </input-adapter>
    </plugin>
    <plugin name="OptionalGroupsSelectionPlugIn">
      <input-adapter name="IA">
        <bind-property name="selectedChoiceIds">
          <value>__OPTIONAL_ACTION_1__</value>
          <value> . . . </value>
        </bind-property>
      </input-adapter>
    </plugin>
  </group>
  <group name="PostDirSelectionPost81Group">
    <plugin name="AdminServerSelectionPlugIn">
      <input-adapter name="IA">
        <bind-property name="selectedChoiceIds">
          <value>__ADMIN_SERVER_NAME__</value>
        </bind-property>
      </input-adapter>
    </plugin>
    <plugin name="OptionalGroupsSelectionPlugIn">
      <input-adapter name="IA">
        <bind-property name="selectedChoiceIds">
          <value>__OPTIONAL_ACTION_1__</value>
          <value> . . . </value>
        </bind-property>
      </input-adapter>
    </plugin>
  </group>
  <group name="DomainBackupGroup">
    <plugin name="DomainDirectoryBackupPlugIn">
      <input-adapter name="FileSelectionIA">
        <bind-property name="selectedFileNames">
          <value>__BACKUP_DIR__</value>
        </bind-property>
      </input-adapter>
      <input-adapter name="TextIA">
        <bind-property name="value">
          <value>___BACKUP_FILE_NAME__</value>
        </bind-property>
      </input-adapter>
    </plugin>
  </group>
</plugin-silent-responses>

-->

But, as it turns out, where I wanted to be literal on the  SelectWebLogicVersionPlugIn value with 10.2, the correct format is to be a bit broader, with:

    <plugin name="SelectWebLogicVersionPlugIn">
      <input-adapter name="ChoiceIA">
        <bind-property name="selectedChoiceIds">
          <value>9.0 or higher</value>
        </bind-property>
      </input-adapter>
    </plugin>

Note the value 9.0 or higher

I hope this saves some folks the time I spent figuring it out :)

Peak at PEAF Performance

October 7th, 2011
No Gravatar

Love alliteration. Love money more :)

PEAF Simplifies the Rocket Surgery of Enterprise Architecture

My Take on Sparx Enterprise Architect

September 15th, 2011
No Gravatar

As told for the almighty dollar at http://www.devx.com/enterprise/Article/47286

Needs No Introduction

September 13th, 2011
No Gravatar

Dilbert.com

Everything Your Mother Didn’t Tell You About SVN and Eclipse

August 17th, 2011
No Gravatar

My latest copyright forfeit to DevX is Eclipse and Subversion: Project Source Control From Within the IDE

Excellent WLS LDAP Tuning Post

August 16th, 2011
No Gravatar

http://fusionsecurity.blogspot.com/2011/08/tuning-weblogic-ldap-authentication.html

Programmatically Managing WLP Enterprise Scope Roles

August 15th, 2011
No Gravatar

Recently I was working on code to manage roles in WLP. WLP roles can be at the global, enterprise application, or web application scope and I needed it at the enterprise application scope because these roles were for use with the content repository.  However, I could only find examples for the web application scope, which generally looked like this:

RolePolicyManager rpm = new RolePolicyManager();
RolePolicyItem rpi = new RolePolicyItem();
rpi.setEntAppName("testTT");
rpi.setWebAppName("ProducerWEB");
rpi.setResourceScope(
   EntitlementConstants.WEBAPP_ROLE_INHERITANCE);
rpi.setPolicyName("myTestPolicy");
ArrayList a = new ArrayList();
a.add("testUser");
rpi.setUserList(a);
rpm.createRolePolicy(rpi);

From that example, I would assume that changing

rpi.setResourceScope(
   EntitlementConstants.WEBAPP_ROLE_INHERITANCE);

to

rpi.setResourceScope(
   EntitlementConstants.ENT_APP_ROLE_INHERITANCE);

would be sufficient. Alas, it wasn’t. The role was still created at the web application level. So, being clever, I removed

rpi.setWebAppName("ProducerWEB");

which had an interesting result. The role was created at the Enterprise Application scope, but only in the RDBMS, not in LDAP and, consequently, not in the Portal Admin Console. For someone in a hurry this might be acceptable as the role could be managed from code. And, while in a hurry, I had the long view that these roles would also need to be managed from Portal Admin Console, so don’t ask me if the role actually worked for entitling when out of sync as I never tested it.

To make a long story short (probably too late for some), I contacted support, who in turn opened a bug. The response from engineering was that the WebAppName had to remain, and that one more piece was required:

rpi.setPolicyUser(
   EntitlementConstants.P13N_APPLICATION_POLICY);

And that did the trick. I looked up the documentation for com.bea.p13n.entitlements.policy.RolePolicyItem and found the setPolicyUser method listed in the parent class, though found no reference as to its value, nor did I find a getter for the attribute, so I don’t believe it was something I missed, just one of those undocumented features that are handy to know about.

Using the XIP Tool with WLP 10.3.2

July 19th, 2011
No Gravatar

The 10.3.2 release of WebLogic Portal included changes to the file structure of the installation and packaging of the libraries. One impact to this is the need to manually update some of the legacy tools that are still included with the install but have not been updated for you. In this case, the XIP tool.

There is a support document that describes changes necessary to get the XIP tool working with 10.3.2, but it is not complete. Rather than making this entry longer and more confusing, I will ignore that article and simply list what I did to get it working.

The zip tools are located at [BEA_HOME]\wlportal_10.3\propagation\bin\xip. This is where the tool is run from and where the changes to make it work are done. All of changes are to the build.xml file. It starts with replacing the first block of two property declarations with a set of 5. For simplicity’s sake I hard-code the key definition though it is better to set this in a property file or pass it as an argument. The orginal block is:

<property name="wlserver.dir" value="@WL_HOME" />
<property name="wlportal.dir" value="@WLPORTAL_HOME" />

And the new block is:

<property name="bea.dir"
          value="C:\bea1032" />
<property name="wlserver.dir"
          value="${bea.dir}\wlserver_10.3" />
<property name="wlportal.dir"
          value="${bea.dir}\wlportal_10.3" />
<property name="workshop.dir"
          value="${bea.dir}\wlportal_10.3\workshop"/>
<property name="modules.dir"
          value="${bea.dir}\modules\com.bea.p13n_10.3.2.0"/>

Next, under

<!-- Library locations, should not need to modify -->

We will make some major modifications. So much so that I will simply list the completed updates:

<property name="wls.classpath"
          value="${wlserver.dir}/server/lib/wlclient.jar"/>
<property name="wlp.classpath"
          value="${wlportal.dir}/light-portal/lib/system/
netuix_system.jar;${wlportal.dir}/p13n/lib/system/
p13n_system.jar"/>
<property name="wlp-library-dir"
          value="${wlportal.dir}/portal/lib/j2ee-modules"/>
<property name="p13n-library-dir"
          value="${wlportal.dir}/p13n/lib/j2ee-modules"/>
<property name="common-library-dir"
          value="${workshop.dir}/common/deployable-libraries"/>
<property name="modules-library-dir"
          value="${modules.dir}"/>
<property name="netuix-lib-app"
          value="${wlportal.dir}/propagation/bin/xip/applib"/>

<target name="init.app.libs">
  <libclasspath basedir="${netuix-lib-app}"
                 tmpdir="${templibdir}"
                  classpathproperty="libraries.classpath">
    <librarydir dir="${wlp-library-dir}"/>
    <librarydir dir="${p13n-library-dir}"/>
    <librarydir dir="${common-library-dir}"/>
    <librarydir dir="${modules-library-dir}"/>
  </libclasspath>
</target>

If you have used the XIP tool before, once you have made the changes above, run the setDomainEnv script from a working WLP domain, then CD to the XIP path. From there, edit the xip.properties file to your needs and then run ant. The properties file is mostly self-explanatory, except that terms Import and Export are from the perspective of the database rather than where the script is being executed from. This means that if you want to get a .portal file from a running portal you would set the following in the xip.properties:

xip.command=export

Propagation Scope Example

June 21st, 2011
No Gravatar

Following my previous post on propagation, I found that the depth of the parent tree was hard to follow for many (myself included). This example helps illustrate it more clearly:

The importance of following the node tree up to remove an item from scope is best illustrated with an example. The BO InfoView iFrame portlet contains an environment-specific URL that should not be propagated. This portlet is listed in a scope file[1] as:

scope_1492=Application\:portalservices\:f1portal.WebApp\:f1.Portal\:default.Desktop\:default.DefaultDesktop\:default_portal_book_main.MainBook\:default_portal_book_reports.BookMember\:default_portal_book_reports.Book\:default_portal_page_boReports1.BookMember\:default_portal_page_boReports1.Page\:boInfoViewIframe_1.PageMember\:boInfoViewIframe_1.PortletInst

To remove this item from scope, all of the following parent nodes must be also be removed:

scope_1487=Application\:portalservices\:f1portal.WebApp\:f1.Portal\:default.Desktop\:default.DefaultDesktop\:default_portal_book_main.MainBook\:default_portal_book_reports.BookMember

scope_1488=Application\:portalservices\:f1portal.WebApp\:f1.Portal\:default.Desktop\:default.DefaultDesktop\:default_portal_book_main.MainBook\:default_portal_book_reports.BookMember\:default_portal_book_reports.Book

scope_1489=Application\:portalservices\:f1portal.WebApp\:f1.Portal\:default.Desktop\:default.DefaultDesktop\:default_portal_book_main.MainBook\:default_portal_book_reports.BookMember\:default_portal_book_reports.Book\:default_portal_page_boReports1.BookMember

scope_1490=Application\:portalservices\:f1portal.WebApp\:f1.Portal\:default.Desktop\:default.DefaultDesktop\:default_portal_book_main.MainBook\:default_portal_book_reports.BookMember\:default_portal_book_reports.Book\:default_portal_page_boReports1.BookMember\:default_portal_page_boReports1.Page

scope_1491=Application\:portalservices\:f1portal.WebApp\:f1.Portal\:default.Desktop\:default.DefaultDesktop\:default_portal_book_main.MainBook\:default_portal_book_reports.BookMember\:default_portal_book_reports.Book\:default_portal_page_boReports1.BookMember\:default_portal_page_boReports1.Page\:boInfoViewIframe_1.PageMember

While the above list contains the immediate parent nodes, the parents of those nodes must also be removed to prevent propagating the portlet, so the following also must be removed:

scope_0=Application

scope_139=Application\:portalservices

scope_140=Application\:portalservices\:f1portal.WebApp

scope_1321=Application\:portalservices\:f1portal.WebApp\:f1.Portal

scope_1322=Application\:portalservices\:f1portal.WebApp\:f1.Portal\:default.Desktop

scope_1323=Application\:portalservices\:f1portal.WebApp\:f1.Portal\:default.Desktop\:default.DefaultDesktop

scope_1324=Application\:portalservices\:f1portal.WebApp\:f1.Portal\:default.Desktop\:default.DefaultDesktop\:default_portal_book_main.MainBook

In addition, any child nodes should be removed to prevent possible errors:

scope_1241=Application\:portalservices\:f1portal.WebApp\:f1portal.Library\:default_portal_book_reports.Book\:default_portal_page_boReports1.BookMember\:default_portal_page_boReports1.Page\:boInfoViewIframe_1.PageMember\:boInfoViewIframe_1.PortletInst\:boInfoViewIframe_1.Localization


[1] It is important to note that the scope file changes on every propagation run, and must be re-created for each run.