We have seen a few cases when customers reported that Portal users could no longer create new pages all of a sudden. This used to work before and had recently stopped working. In the "Manage Pages" portlet, after the user clicks the button "New Page" to create a new page, instead of seeing the Page Properties being loaded, the user gets an exception:
"EJPAS0012E: The Properties page has been launched with no context information"
This issue is usually seen in environment where the "Page Properties" is using a custom theme, either via explicit theme assignment to the page or via inheritance.
The Portal logs do not record much detailed information about this exception. It's generally helpful to get a full export of the Portal configuration for review.
Administration portlets depend on services provided by the Portal theme. If those services are not available to the administrative portlets, exception EJPAS0012E will be thrown. The "Page Properties" page requires the use of the adminNavHelper JSP tag, which must be present in the Default.jsp. If the assigned custom theme is lacking this tag, this issue will occur.
For this scenario, there are two possible solutions for the problem:
+ Solution 1: Assigning the out-of-the-box "Portal" theme for the 'Page Properties" page so that the required services are available.
+ Solution 2: Modify the custom theme and add the <portal:adminNavHelper/> JSP tag to the Default.jsp.
This scenario and details about the solutions are described in IBM Technote # 1395801.
There is also a specific scenario when this issue may occur in older versions of Portal, even though the "Page Properties" page is using the out-of-the-box Portal theme, no custom theme involved. In this case, the issue occurs if there exists a friendly URL called "pageproperies" for the "Page Properties" page.
Support has tested and verified that this issue occurred in Portal 126.96.36.199 but is indirectly fixed in Portal 188.8.131.52 and later versions.
The solution in this scenario is removing the offending friendly URL using XMLAccess (because, due to this issue, the user is unable to launch the "Page Properies" page via the Portal Administration UI to delete the friendly URL).
A sample XMLAccess input script is something similar to:
<?xml version="1.0" encoding="UTF-8"?>
<!-- IBM WebSphere Portal/184.108.40.206 build wp6101_115_01 exported on Wed Oct 05 08:48:05 EDT 2011 from MyPortal6101/127.0.0.1 -->
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" build="wp6101_115_01" type="update" version="220.127.116.11" xsi:noNamespaceSchemaLocation="PortalConfig_6.1.0.xsd">
<content-node action="locate" domain="rel" objectid="6_000000000000000000000000A0" uniquename="wps.content.root"/>
<content-node action="update" content-parentref="6_000000000000000000000000A0" create-type="explicit" domain="rel" objectid="6_CGAH47L008DF802B56IQ0D0G94" preserve-old-layout="true" type="page" uniquename="ibm.portal.Page Properties">
<parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>
<parameter name="com.ibm.portal.ThemePolicy" type="string" update="set"><![CDATA[theme/SingleTopNav]]></parameter>
<parameter name="com.ibm.portal.bookmarkable" type="string" update="set"><![CDATA[No]]></parameter>
<parameter name="com.ibm.portal.friendly.name" type="string" update="remove"><![CDATA[pageproperties]]></parameter>
<parameter name="com.ibm.portal.remote-cache-expiry" type="string" update="set"><![CDATA]></parameter>
<parameter name="com.ibm.portal.remote-cache-scope" type="string" update="set"><![CDATA[NON-SHARED]]></parameter>
New to Websphere Portal Performance? Need to better review and understand all aspects of a javacore? Want to have meaningful discussions with L2 support on performance issues based on javacore and data collected?
IBM Research has created a new tool to enable you to review , troubleshoot and analyze performance issues regardless of expertise.
IBM Whole-system Analysis of Idle Time (WAIT) is a lightweight and powerful tool that can be used in almost any Portal or other Java environment. The tool is graphical and can be used by anyone, newbies and experts alike. You can determine the source of performance issueS, easily review call stacks and determine who wrote any piece of code in a portal call stack(WebSphere , Portal , WCM other IBM product or other third party entities)
There is an upcoming demo and discussion of the WAIT tool for Websphere Portal Customers on November 10, 2011
See the following document for more information on the event .
Customer Open Mic: The WAIT tool - Portal Performance Diagnosis and Beyond http://www-01.ibm.com/support/docview.wss?uid=swg27023208
You can review the tool at the following locations
Sneak previews here: http://snappy.watson.ibm.com/wait
External Site http://wait.researchlabs.ibm.com
I would like to take a high level overview of the various programming entry points that WebSphere Portal provides to allow you access into the internals of the Portal to both make changes as well as request information about various aspects of the Portal.
The first thing to understand is that you will almost always have to get a home object which represents the starting point for interactions in that package. Such that if you wanted information on access control you would use a JNDI lookup to retrieve AccessControlHome, or for PumaHome if you want to get information on the Portal User interface. Once you have the Home you will need to get either the Model or the Provider object depending on the needs of the code. Next we will look at the most common packages and their uses.
This package will contain information regarding access control information on various resources. You can check the ACL data on any item that supports the Identifiable interface(which is most everything in portal). So this would include Pages, Portlets, Containers, whatever you might have. you can pass in and either get the entire role data set or check to see if certain users have a specific permission, or if the current user has a specific permission. You could use this to customize visible data in your portlets, and on your pages depending on what was needed for the environment.
This next package is useful for customizing the Portal login/logout mechanism. These will only be triggered when you try to access a Portal protected resources. This replaces the customization that used to be made in the LoginUserAuth classes by now adding them to the Portal login filter chain. One thing to be aware of is the difference between implicit and explicit login/logout. The Implicit login is where a user us already authenticated to WebSphere AppServer but then attempts to reach a portal resource. They will then go through the Portal implicit login chain.
This package has many providers that will see some of the most use out of the other ones. With this package you can retrieve a list of languages the Portal supports, the markup that the Portal supports, information about the navigation, content, navigation selection, portlets, themes, skins and helpers to localize resources when presenting them to users. All of these models will be read only while the subpackage com.ibm.portal.model.controller will give you write access to all of these. All of these will be scoped to the user making the request. With the controller package you can create pages, add portlets to the page and remove them, set skins on the page, alter properties about all of these including ordinality. A developerworks article is in the plan for this from support to show examples of the most common questions using the controller SPI
The providers in this package will allow you to traverse the tree for navigation of the current user. they can be useful in creating breadcrumbs and creating your own custom navigation portlets. These along with the com.ibm.portal.state package can be used to create links to do a grand variety of actions within portal. Please see Advanced URL helpers for a detailed sample on using the state package to create links to various Portal resources.
com.ibm.portal.portlet and com.ibm.portal.portletmodel
These two packages provide a lot of information concerning the various layers of portlets they can be used to make changes to the portlet configuration and also can retrieve preferences layers for review.
Also known as PUMA this is the usermanagment part of the SPI, with it you can do user management, and queries. For more on PUMA please see PUMA whitepaper
This covers the majority of the SPIs that customers use, and can do 90% of what you need to do in your custom Portal environment for management and administration.
Ordinarily at server startup portal server plays back recovery logs and attempts to reconcile transactions activity information before the prior shutdown.If , for whatever reason, the server was brought down abruptly, an existing or in route transactions may not have either completed successfully or completely rolled back. The net effect is transactions are left in in detreminate state and may prevent full functionality of the server. While not necessarily the only sign of such problem the following stack is typical..
XARminst E WTRN0037W: The
transaction service encountered an error on an xa_recover operation. The
resource was com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl@21c121c1. The
error code was XAER_RMERR. The exception stack trace follows:
To resolve you may need to completely delete the problem transactions. Here is the sample process
Remove the contents of the /tranlog and /partnerlog subdirectories which
are located under the <profile_name>\tranlog\cell_name\node_name\server_name\transaction . Occasionally you may need to go as far as removing all the contents(including contained directories
After that restart server and server should ordinarily startup without any problems
Needless to say the ideal scenario is a graceful shutdown
When a problem occurs the most important step in resolving the issue is providing IBM Portal L2 Support with a complete set of diagnostic data including traces and logs. The task of doing this manually involves enabling tracing, recreating the issue, manually packaging files, and uploading them to support. In the past we have recommended ISALite, which is a tool available for download, that automates the process of selecting a problem type, recreating the issue, collecting the needed logs and files, and uploading them to support. We are currently in the process of moving to a web based tool called IBM Support Assistant Data Collector (ISADC). When available, the ISADC will not require the end user to download and install a collection tool, however it will still provide the same benefits as ISALite. ISADC will have the following advantages over the existing ISALite tool...
- You will not have to download and install an application.
- Since ISADC is client-server based, you will always be using the latest scripts.
- When opening electronic problem tickets with IBM via SR you will be able to start a data collection and provide the initial logs and files to Portal L2 Support.
- When an automated data collection is provided at PMR creation the problem investigation and determination is expedited.
The ISADC for WebSphere Portal will be released as a Tech Preview very soon. More functionality will be released in the coming months. Stay tuned to the blog for additional details and watch for the ISADC link in the SR tool. We welcome any feedback or suggestions regarding ISADC or automated data collection in general.
Websphere Portal L2 support
Here it is, the new white paper showing how to clone an installation of IBM WebSphere Portal version 7.0 that has been configured for specific deployment needs:
I have been testing the document myself and have come up with a number of observations:
1. The steps have been vastly simplified since the Portal 6.1.x instructions came out. Also there have been some improvements which allow for more flexibility if the new node is on the same LAN, unlike previous versions.
2. These steps are only usable if your OS to OS is comparable -- i.e. Windows 32-bit to Windows 32-bit, or RHEL 32 bit to RHEL 32 bit, etc.
3. Certain 64 bit OS versions will not support the GUI. My first attempt was with RHEL 64 bit in which the exceedingly more complicated ifcli.sh|bat must be run instead of the ifgui.sh|bat which is much simpler to use. At the very least I would suggest that one's initial test should be using the GUI version shown in the white paper.
4. I'm still playing around with but I have noticed that on certain target systems there have been some apparent port conflict problems. I'm still working on what may have caused this as it's not very clear how this occurred.
A new tool has been published to the Portal wiki to help users easily edit the Portal v8 xml response files:
This can be very useful if you do not have a GUI environment to record your own response file with.
Creating a new theme in WebDAV:
Portal v7, themes are broken apart into static template files and
dynamic files. The static template files are stored in WebDAV and use
dynamic content spots to reference JSPs or other dynamic resources.
The dynamic resources are stored in a WAR file. WebDAV directories
include files for the following theme functionality: theme, skin and
steps will create a new theme in portal using WebDAV.
- Using a WebDAV client Connect to http://<server>:10039/wps/mycontenthandler/dav/themelist/
- Copy the csa2.theme to your
- Rename the csa2.theme
folder on your local system to sample.theme
- Update the
metadata\localized_en.properties to reflect the new title. You would
need to modify each localized properties file for each languange.
Modify the theme_en.html file so that you can verify the correct
theme is applied. This file is found in the nls directory
<body class="lotusui tundra locale_en"
- Copy the sample.theme
folder to the themelist entry point using the web dav client.
- In portal create a new page
named Sample Theme and apply the Sample Theme theme using the admin
portlet, best practice is to create the page using the edit mode of
the theme, however creating it through the admin portlet will reveal
some differences in page types in 7.0, and a common customer
Render the page and verify that your theme_en.html is being
rendered. You should see the text ?Sample Theme? rendered on the
Modify your theme_en.html to the following:
class="lotusui tundra locale_en" >
Sample Theme Modified<br>
Copy the modified theme_en.html back to the server using the
themelist entry point
Do you see the update?
By default the WebDAV files are cached for 24 hours. You will need
to change the cache values during theme development in order to see
the changes immediately.
Open the WSAS admin console and go to the WP_ConfigService
Resource Evironment Provider (REP) Resources ->Resource
Environment ? Resource Environment providers
In the custom
properties you will see several entries like the following:
Please see the following section in the infoCenter for more
details about this caching:
Change all of the following entries to a value of 1 and
restart the server. This will reduce the caching for the WebDAV
files to 1 second.
Render the page again and you should see the modified output
from the theme_en.html
note: best practice is to use the fs-type1 entry point for
modifying the files and not the themelist entry point. The themelist
entry point is an admin entry point and is used for altering theme
metadata including the titles. Please note the cache above will only
effect the themelist entry point not the fs-type1. As an additional
exercise reset the caching to default values, restart the server, and
then make a change via the fs-type1 entry point and see that your
changes are immediately visible.
Now that the new theme is created
lets take a few minutes to understand what happened by generating a
complete xmlAccess export of the server using the following technote:
Note that you will be using this XMLAccess export in a future
You should now see a theme defined
like the following (the objectid may be different):
<theme action="update" active="false"
The newly created sample theme is using the PageBuilder2 war file.
This can be seen from the context-root and resourceroot attributes.
There are also several parameters defined for the theme. If present,
parameter is used as the display name for the theme in the themelist
webDAV entry point. This should be a unique value in the system but
this is not enforced. If the ?com.ibm.portal.friendly.name?
parameter is not
available then the uniquename of the theme is used as the display
name. If neither the ?com.ibm.portal.friendly.name
? or the uniquename are
defined for the theme then the theme's OID will be used as the
The themelist webdav entry point mirrors the fs-type1 entry point.
Since the themelist uses the ?com.ibm.portal.friendly.name
as the display name it has to be unique. If there are two themes that
have the same value, only one will be displayed.
When our sample theme is rendered the default.jsp of the PageBuilder2
WAR is the main entry point. The default.jsp will then call the
correct theme.html file to execute. It determines the correct path by
using the com.ibm.portal.theme.template.ref parameter.
Creating a new theme WAR file
The theme WAR file will contain the
dynamic resources. As stated in the previous section the default.jsp
PageBuilder2 theme is used when our
sample theme renders. If you want to modify the default.jsp or any of
the dynamic resources you should create a new WAR to contain them.
- Copy the following WAR into
a temporary working directory:
- In Rational Application
Developer (RAD) or Eclipse, create a new Dynamic Web Application
titled PageBuilder2 theme from the temporary working directory you
created above for the new WAR.
I created a new project then pasted the contents of the war
directory into the web content directory
Open up the web.xml and change the display name to ?SampleTheme?
Under the themes\html directory your will see a folder named
PageBuilder2. Rename this directory to SampleTheme. This directory
name will be used as the resourceroot in a later step so if you name
it something different you will need to update the resourceroot
We will also add some content to the Default.jsp so that we can
verify the correct theme is being picked up.
default.jsp and add the following code right after the include to
the bootstrap.jspf:(this default.jsp will be in the root html
directory not in the theme directory
Export the WAR from RAD
Import the WAR into the WSAS admin console.
the theme use ?/sampletheme? as the context root for the theme. This
will be used in a later step for the ?context-root? in the xmlAccess
file. If you name this differently you will also have to change the
context-root value in later steps.
Start the application in the WSAS admin console
- We will use the xmlAccess
export from a previous step to change the context-root and
resourceroot of the sample theme to point to the newly created WAR
Note: Please refer back to step 4 and step 7 if the values for
context-root and resourceroot are not clear.
<theme action="update" active="false"
Note: You will need to use the information from your export
since the OIDs will be different. You cannot use the xml above.
Import the modified xml file using xmlAccess. You can do this by
simply navigating to the Portal Administration Console and choosing
the import XML option and then pointing to the updated xml file for
Now render the page again and you should the following:
Now modify the bannerNav.jsp
to add some additional markup.
Sample Theme bannerNav.jsp<br
Renders the links in the banner (Home, Admin,
etc.) server side --%>
Rebuild the WAR and then update it in the WSAS admin console.
Refresh the page, do you see
the updated markup you added in the bannerNav.jsp?
see your changes in the
The default.jsp of the Sample
Theme is used when rendering the page with the theme applied. However
as stated previously the default.jsp will call the static theme
template that is defined in the themes metadata. For the sample theme
uses the following:
If you inspect the
theme_en.html file you see the following dynamic-content-spot that is
used to render the bannerNav.
<!-- responsible for the top most navigation links
(horizontal list) -->
<a rel="dynamic-content" href="dyn-cs:id:bannerNav@tl:oid:csa2.theme"></a>
This markup will inform the
static page parser in WebSphere Portal to look for
dynamic-content-spot with an id of bannerNav. You will also notice that the href
This instructs the static page
parser to look in the theme with a uniquename of csa2.theme for any
All this means is that your
theme is still using the bannerNav.jsp from the PageBuilder2 WAR file
and not from your custom SampleTheme WAR.
If you want it to your content spots
to pull from your custom war you would need to change them to
reference your custom war.
You have three options:
Please see the following section of
the InfoCenter for more details
- Defining a custom content
spot via the resource environment provider
- adding an override to the
- changing the href to be a
Since we moved to our cumulative fix strategy, we've received several PMRs where our users install one cumulative fix, uninstall it, then reinstall a different cumulative fix. More often than not, the user hits this failure:
"Profile version is not as same as portal binary version before updating portal binary: wp_profile, update aborts!"
This happens because of a commonly overlooked step during a cumulative fix uninstall. During installation, the Portal binaries and profile are updated at the same time. Or rather, the Portal Update Installer (PUI) applies the cumulative fix to the Portal binaries and runs a ConfigEngine script to update the profile for you automatically.
During uninstallation though, that is not the case. PUI uninstalls the cumulative fix from the binaries, but it does NOT uninstall the CF from the profile! That is where the failure comes from....
A second step is needed to uninstall the CF from the profile. From the CF readme
(7001 for example):
c. Run the following command:
- z/OS: <wp_profile_root>/PortalServer/bin/UpdateProfile.sh uninstall CF skipPreCheckProfile
- All other platforms: To downgrade a profile after an
uninstall, the following command can be used to downgrade all profiles
(including the primary profiles). See the following link for multiple
profiles Supporting multiple profiles: wp7.
<wp_profile_root>/PortalServer/bin/UpdateProfile.bat|.sh uninstall CF
If you uninstall a CF yourself, make sure you don't skip that step!
When troubleshooting Portal issues, traces are certainly helpful, but sometimes you just want a quick dump of specific information without having to dig through traces. Other times, you may want to quickly implement a proof of concept idea via some quick code, but don't want to deal with the hassle of creating the portlet, deploying it, and redeploying .... every ... single ... time ... you ... want ... to ... make ... a ... small ... change ... to ... your ... code.
A quicker solution to this would be to place the same code in a JSP file, upload the JSP file to your Portal server, and then have the JSP execute. This won't expose all of the available functionality that JSR168/286 portlets would normally offer, but, offers the benefit of quickly testing out your code. WebSphere Portal 6.0, 6.1 and 7.0 all ship with a portlet called the Blurb portlet which can read your JSP and execute the contents within it. Normally, the Blub portlet is utilized to display a welcome message when you login to the Portal, but, given it can read any JSP file you configure it to utilize, we can modify its intended purpose slightly to debug our Portal.
Simple Test Case
Let's take a simple Hello World test case.
1) Open up your favorite text editor (no need for an IDE!)
2) Copy and paste the following into the text editor:
3) Save the file as helloworld.jsp.
4) Copy the helloworld.jsp file to the following location on your Portal server:
On my AIX system, the full path is:
5) Open up a web browser. Login to the Portal server as an administrator. Navigate to the Administration section.
6) In the Manage Pages section, Go to Content Root > Home label and create a new page, call it "helloworldtest".
7) Still in manage pages, on the right-hand side of the "helloworldtest" page, click on the Pencil icon for "Edit Page Layout"
8) Click the + sign to add portlet, search for "Welcome". Click the checkbox next to the"Welcome to WebSphere Portal", and click OK to add it to the page. Click Done to complete the procedure.
9) Navigate to the newly created "helloworldtest" under the "Home" label. You'll observe the portlet is not yet configured. Let's go ahead and do that now.
10) Click the drop-down arrow in the top-right corner, then click "Edit Shared Settings"
11) Update the path to show
12) Click Save. Observe the results of your code in the JSP file!
PUMA API Sample Code
Hello World! gives us an introduction to invoking code with the JSP. Let's try something more interesting ... say using the PUMA API to get all users and groups.
1) Create a new page named pumaapitest
2) Create a new file named pumaapitest.jsp with following code and upload to the Portal server in same folder:
<%@ page import="com.ibm.portal.um.*" %>
<%@ page import="javax.naming.*"%>
<%@ page import="java.util.*"%>
final String BR = "<br><br>";
out.print("Starting to gathering info"); out.print(BR);
Context ctx = null;
PumaHome pumaHome = null;
PumaProfile pumaProfile = null;
PumaProfile pumaProfileForContext = null;
PumaLocator pumaLocator = null;
PumaController pumaController = null;
ctx = new InitialContext();
pumaHome = (PumaHome)ctx.lookup(PumaHome.JNDI_NAME);
pumaProfile = pumaHome.getProfile();
pumaController = pumaHome.getController();
pumaLocator = pumaHome.getLocator();
List userList = new ArrayList();
List myList = new ArrayList();
userList = pumaLocator.findUsersByAttribute("uid","*");
if (userList.size() == 0)
out.print("No users found from search!"); out.print(BR);
out.print("Found a total number of users " + userList.size()); out.print(BR);
for (int i = 0; i < userList.size(); i++)
out.print("User number " + (i+1) + " has the following attributes " + pumaProfile.getAttributes((User)userList.get(i), myList)); out.print("<br>");
List groupList = new ArrayList();
myList = new ArrayList();
groupList = pumaLocator.findGroupsByAttribute("cn","*");
if (groupList.size() == 0)
out.print("No groups found from search!"); out.print(BR);
out.print("Found a number of groups " + groupList.size()); out.print(BR);
for (int i = 0; i < groupList.size(); i++)
out.print("Group number " + (i+1) + " has the following attributes " + pumaProfile.getAttributes((Group)groupList.get(i), myList)); out.print(BR);
out.print("Exception occured!!! " + e); out.print(BR);
3) Add the "Welcome" portlet to the page, configure the portlet to point to /jsp/pumaapitest.jsp
4) Observe results and notes from author of this blog entry:
- My test Portal only has the
default / out of the box user and group. In a larger Portal connected
to an LDAP, this sample could would query for uid=* and cn=* for users
and groups respectively. On the sample code, formatting could probably
use some improvements, as could error catching and handling, but, the
proof of concept was implemented fairly quickly.
- Also, should
your code fail to compile (missing semicolons for instance), you will
observe an HTTP 500 error on the page with debug output of where the
compile error is in the code. Upload the corrected version of the code,
reload the page, no more HTTP 500.
- In a production system, it is
NOT recommended to use the Blurb portlet for this purpose. However,
for testing purposes, this offers a quicker means to potentially try out
some new options within the Portal that would have otherwise been
difficult to allocate the time to code via a portlet. Future blog
postings will cover some more advanced uses of this debugging technique,
including pulling information from the portlet request, dumping browser
cookies, session information, rememberme, etc. Stay tuned!
LDAP users must be defined by Distinguished Name in a group
In some LDAP servers, it is possible to set up a group whose members are not defined by DN as in this example:
Even if the groupConfiguration in wimconfig.xml is correctly defined with the appropriate objectClass and scope, this arrangement will cause VMM to treat the name identifier (here shown as memberUid) as a standard attribute and not a membership attribute.
Rather than returning all members by name, which VMM expects, the identifier will be returned followed by the members as a simple list of values:
DN: cn=group,o=ibm,c=com ... Type: Group
memberuid=memberUid: bob, mary, jim, alice;
VMM determines the group has no members.
To correct the configuration, ensure that all group members are defined with a fully qualified Distinguished Name:
So here is a simple scenario. User consistently sees that a named collection index directory exists when trying to create a new one . This is even after the following has been done
1. No collections exists in the Manage Search collections listings
2. The collections name is not listed in the PSE Sources within the Resource Permissions Portlet (Portal Administration > Resource Permissions)
3. The directory in <wp_profile>/collections folder
4. The "faulty collections" link does not show up meaning the server does not necessarily see a corrupted search index
To resolve issues with reappearing "deleted" indexes there are a couple of items to check in to the above items
A. Check the settings in the SearchService properties
- If this is the default out of the box portal collection , make sure the "PortalCollectionForceCreate" is set to "off". Otherwise it will be recreated at startup
- Make sure that if RECOVERY_BACKUP_LOCATION is set, then the named collections folder structure within that location must also be deleted. Otherwise on startup the server will seethe backup information and restore the directory even though there is no specified collection. This is a feature intended to help recover otherwise corrupt collections instead of intentionally deleted ones.
B. Check for and delete the named index listing the PSE_DESC table (in the RELEASE SCHEMA).
While a rare scenario, allowing the history log for wcm content items could cause problems in saving the item and or the log itself. This happen if grows past the internal default size.. typical errors will look similar to this
Error rendering content: com.ibm.workplace.wcm.api.exceptions.DocumentSaveException:
Message: Could not save object in repository., Cause: com.ibm.workplace. wcm.services.repository.RepositoryException: Message:
PrivilegedActionException caught, Cause: javax.jcr.nodetype.ConstraintViolationException: NT6577E: The value for the binary
property ibmcontentwcm:historyLogEntries on node/XXXXXXXXXXXXXXXXXXXXXXXXXXXXX/jcr:versionedNode/icm:
copiedValues exceeds its max length. The max length is 5000000 while the value is of length 5000679 (Message: Could not save object in repository., Cause: com.ibm.workplace.wcm.services.repository.RepositoryException: Message: PrivilegedActionException caught, Cause:javax.jcr.nodetype.ConstraintViolationException: NT6577E: The value for the binary property ibmcontentwcm:historyLogEntries on node /XXXXXXXXXXXXXXXXXXXXXXXXXXXX/jcr:versionedNode/icm:copiedValues exceeds its max length. The max length is 5000000 while the value is of length 5000679)
As part of routine maintenance you may consider truncating the history log
Ordinarily all cache tuning information are found in the Portal tuning guides below at the bottom of the page . The documentation usually contain the recommended cache sizes and lifetime as well as how/where to set. WSSECUREMAP is not one of them . There is the description but not how to set it even though it must be stated you probably may not need to tune this cache often
Here is how and where to tune it
WSSecureMap is the DynaCache used for Security Attribute Propagation. This cache should be created with DynaCache default size of 2000.
The DynaCache default could be changed but that would affect all caches created with the DynaCache default.
1. If you wish to change only the size of WSSecureMap, you can use following 2 custom properties:
com.ibm.ws.security.WSSecureMapSize=X (X = desired size - positive integer more than 100)
Note that the specified size is used ONLY if the ...InitAtStartup property is also configured and set to true.
To set the property from administrative console page,
Click Security > Global security > Custom properties
Click New to add new custom properties and associated values as mentioned.
2. The lifetime of entries cannot be configured. Entries in this cache remain valid until the Subject contained in the entry is no longer
valid. This is usually the LTPA timeout which defaults to 2 hours. If you have any problem ( Ex: WSSecureMap is not working as expected)
If you have any issues with this cache, Open a support pmr with the Security Mustgather http://www-01.ibm.com/support/docview.wss?uid=swg21470063
Portal Caches information [http://www-10.lotus.com/ldd/portalwiki.nsf/dx/WebSphere_Portal_caches_%28Tuning_Guide_6.1.x%29]
Portal 7 tuning guide [http://www-10.lotus.com/ldd/portalwiki.nsf/dx/WebSphere_Portal_Tun]
If you upgraded to WAS 18.104.22.168 , regardless of your Portal version, you may notice a lot of otherwise innocuous alarm monitor threads warning along with various call stack such as below
AlarmThreadMo W UTLS0008W: The return of alarm thread "Non-deferrable
Alarm : 1" (0000001f) to the alarm thread pool has been delayed for
40968 milliseconds. This may be preventing normal alarm function within
the application server. The alarm listener stack trace is as follows:
WebSphere Application Server 22.214.171.124 introduced new serviceability
feature to enhance the monitoring/configurability of Alarm threads.
However the various settings introduced have default values that are
rather low and too low for Portal operations . One of the parameters is
which determines how long an alarm thread runs before the warning
is issued. So, for example, if the default settings value of
com.ibm.websphere.alarmthreadmonitor.threshold.millis is used then the
warning and possible stack traces are generated if the alarm threads
runs for more than 40 secs
The default is 40 secs which is very low for most of the portal activities.
There has been a recent documentation change on how to filter search results based on Authoring templates
Prior documentation had indicated using the + character when specifying the authoring template within the scope document
It should be ^ character instead . So specifying search results on authoring template TEMP-Article will be accurately represented as follows
There is a new technote available with frequently asked question on WebSphere Portal API, WebSphere Portlet Factory and Mashups. You can access the FAQ here:
In some cases, when you attempt to create a URL mapping and use certain label name (for example, "pw"), you get an exception such as: "EJPEC0910E: AbstractMappingURLCommand: label pw is invalid."
As documented in the section "The administrative model of URL Mapping" of the IBM Websphere Portal v7 wiki, a label must not have the same name as the URL codecs that are used in Portal because that would introduce an ambiguity when parsing the complete URL.
The reserved names are mentioned in the IBM Websphere Portal v7 wiki on this page:
The list contains these reserved names:
base64xml, b0, b0_1, b0_2, b0_3, b1, b2, b3, c0, c0_1, c0_2, c1, c2, c3, c4, c4_1, c4_2, c4_3, c5, c6, c7, cxml, cxmld, cxml_1, cxml_2, d0, d1, d2, d3, d4, d5, delta, dl2, dl3, dl4, kcxml, nm1, nm2, nm3, nm4, pw, resource, sel, vp, wml
If you are having the same issue with some label names not in this list, please report them to IBM Websphere Portal support via a PMR for further investigation.
Many login performance issues turn out to be delays in resolving group membership. WebSphere Portal attempts to resolve group membership at each login. There are a few things a Portal administrator can do to make the process of resolving group membership as efficient as possible. Reducing the load on the LDAP is a bonus.
1. If your LDAP supports it, implement a membership attribute
. Set the scope as broadly as your LDAP supports. Hopefully, the LDAP's membership attribute lists all of a user's group memberships (direct, nested, and dynamic).
Note: Be sure that any groups returned by the membership attribute can be resolved within the realm defined in VMM. Failures will occur if the membership attribute returns a group DN that VMM cannot look up.
2. Unless your application requires them, avoid using dynamic groups since resolving their membership exacts a high cost. If you need dynamic groups in your application, consider keeping them locally with this alternative
4. Configure a federated repository so that VMM resolves group membership during the WAS login process. Then configure Portal to reuse WAS group information
(user management only, to maximize performance).
Note: You can reuse WAS group information even in a standalone LDAP configuration - I just like the VMM functionality for resolving group membership better.
There are some additional tweaks you can make with PAC caches, VMM caches, and context pooling, but these four items should help a great deal in resolving any performance delays in resolving group membership during Portal login.
WebSphere Portal relies on setting certain cookies to enforce its security controls. As an administrator, you should carefully consider how to protect these cookies in your environment. Unauthorized parties could circumvent WebSphere Portal's security controls given access to:
LTPAToken2 (and LTPAToken, if Interoperability Mode is enabled): Lightweight Third-Party Authentication: WebSphere Application Server relies on this cookie for Single Sign-On. WebSphere Application Server considers a client to be authenticated if it presents a valid LTPAToken2.
JSESSIONID: from the Java Servlet specification: WebSphere Portal's session management uses this cookie.
1. To guard against network eavesdropping, enable SSL for all communications between the browser and the web server. Without an HTTPS pipe, you are relying on the security of the network (which could be a valid option in intranet or VPN environments). If you cannot guarantee network security, it is essential that these cookies be transmitted only within an HTTPS pipe.
2. Define these cookies' domains as narrowly as possible. If a cookie's domain is left unset, the browser should present it to only the server that set the cookie.
3. In conjunction with (1) and (2), consider setting the secure attribute on these cookies. For example, a browser accesses https://portal1.ibm.com/wps/myportal, authenticates, and LTPAToken2 is set with domain=ibm.com. When the browser later requests http://server2.ibm.com, it presents LTPAToken2 over HTTP because of the domain. Setting the secure attribute tells the browser to present the cookie only over HTTPS, regardless of domain.
4. Set HTTPOnly to guard against cross-site scripting (XSS). When HTTPOnly is set for a cookie, the browser should not allow scripts to access the cookie. Of these several recommendations, this is the most highly reliant upon browser implementation. HTTPOnly is a useful tool, but application developers should be vigilant in guarding against XSS regardless of HTTPOnly.
5. Consider your securtiy requirements when configuring LTPA token expiration and session timeouts. Expiration is actually encoded into an LTPA token's value. Simply restricting access to the server long enough for all issued LTPA tokens to expire would mitigate a known breach.
Note: If WebSphere Portal is integrated with an external security manager (ESM) in your environment, you might also need to consider the ESM's cookies. For example, given a valid ESM cookie, a trust association interceptor could instruct WebSphere Application Server to issue a new LTPAToken2.
For more information on these and other WebSphere Portal security topics, refer to:http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Web_security_concepts_and_considerations_for_IBM_WebSphere_Portal_administrators