Head in the Web™

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.

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

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

In WLP 10.3.2, the datasync web application has been deprecated. This makes sense if you consider the recommended approach is to test all of your Datasync Project work in DEV mode and then propagate up once you have everything the way you want. However, if you are upgrading or have a development process where this is not the easiest policy to implement, you may wish to bring back the datasync.war. If that is you, fear not! Blogging to the rescue!

While in previous versions of WLP it was automatically added to a portal EAR project, in 10.3.2 you must manually add the dataync.war.

The documented  approach (How To Import and Add the Deprecated ‘Datasync.war’ to the WebLogic Portal Application (Doc ID 1268447.1)) to add it is to use OEPE, right-click on the EAR project, select Import War, and import [WLP_HOME]\p13n\deprecated\lib\datasync.war. Doing so creates a datasync project in your workspace.

The documentation goes on to describe an edit to the MANIFEST.MF to include the classes from ImportedClasses on the classpath. When I tried it, I could get to the data sync application index page, but would get a 500 error past that.

Digging through the logs, I found class not found exceptions. I eventually fixed this by moving the jsp folder under/datasync/ImportedClasses/WEB-INF/classes/com/bea/p13n/management/data to /datasync/ImportedClasses/com/bea/p13n/management/data, re-building and re-deploying.

I had a problem the other day where a user that was logged out still had their name showing on the screen. I thought the session wasn’t being invalidated, but it was actually a case of the browser caching the page. Digging around, I found a solution that, when added to a backing file for the desktop to run during pre-render did the trick:

import com.bea.netuix.servlets.controls.content.backing
               .JspBacking;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class NoCacheBacking implements JspBacking

{
   public void dispose(){}
   public boolean handlePostbackData(HttpServletRequest request,
      HttpServletResponse response)
   {

      return false;
   }

   public void init(HttpServletRequest request,
      HttpServletResponse response){}
   public boolean preRender(HttpServletRequest request,
      HttpServletResponse response)
   {
      response.setHeader("Cache-Control" ,
                   "no-cache, must-revalidate");
      response.setHeader("Pragma", "no-cache");
      response.setHeader("Cache-Control","no-store");
      response.setDateHeader ("Expires", 0);

      return false;
   }
}