Archive for the ‘Bug’ Category

Happy New Year 2013! Y2k13 bug time…

Thursday, January 3rd, 2013

From your friends at Integryst, Happy New Year!

It’s been a while since I last posted, and thought an appropriate way to kick off the new year was to share a Y2k13 bug in WebCenter Interaction. Well, it’s not a bug per se, but way back in the augts, 2013 seemed a long way away. So the wise developers at Plumtree, when faced with choosing a date infathomably far in the future, chose January 1, 2013 as the hard-coded expiration time for Automation Server Jobs:

This means two things: First, when creating jobs on your ancient WebCenter Interaction/Aqualogic User Interaction/Plumtree portal, you’ll have a couple more clicks to set the “Do Not Run After” value sufficiently far in the future, or you’ll get an error saving the job because the expiration time is in the past. (2015 is plenty far, right? If you’re not feeling that lucky, I suggest 2099 so your grandkids can worry about the Y3k bug).

The second thing it means is that many of your jobs probably stopped running three days ago, because when you created them you probably left the default value in there for the expiration time. There’s no quick fix for this, but after the break I’ll share some tips on how you can reschedule these jobs. (more…)

Bug Blog 13: Fix Broken File Downloads in 10gR3 (Part Quatre)

Tuesday, October 25th, 2011

When WebCenter Interaction 10gR3 was released, it was a complete train wreck for documents in the Knowledge Directory – the content headers were wrong, docs wouldn’t download in Internet Explorer due to the comical back-asswards Javascript file open mechanism, and links couldn’t be copied or viewed because the anchor tags were malformed.

In our last post in this painful series, I shared some code that will resolve the ALUI / WCI Knowledge Directory links so that users can right-click and copy the links, and the files open as expected when clicked.

Since then, I’ve found that when an admin is in EDIT mode in the Knowledge Directory, the link calamity continues, and a completely different and incomprehensible linking mechanism is used. So for your reading pleasure today, I’ll update that post to handle edit mode as well as browse mode. Again, just add the following HTML to the footer used in your Knowledge Directory (depending on Experience Definition, there may be more than one):

Bug Blog 12: ALUI Publisher Doesn’t Work in IE9

Wednesday, June 1st, 2011

Now that we’ve picked on Plumtree Studio for a while, let’s direct our attention back to WCI Publisher for a moment, shall we?

If you are one of the 2.9% of the general population (as of April, IE9’s first full month on the market) that use Internet Explorer 9, and also use AquaLogic Publisher – a product that dates back to the Plumtree days and is in dire need of another upgrade – you’ve no doubt noticed it no longer works in IE9:

HTTP Status 404 – /ptcs/
type Status report
message /ptcs/
description The requested resource (/ptcs/) is not available.
Apache Tomcat/5.0.30

Why? Hell if I know. Seriously, I have no idea. Publisher’s Javascript code is some of the most convoluted I’ve seen in a while.

But, all is not lost! I spent (way) too much time with Internet Explorer’s Developer Tools, comparing IE8 and IE9 URLs and stepping through Javascript on each to tease out what the difference was between the two of them. I found that when IE9 breaks, the URL doesn’t have a CID – it shows something like: site/integryst.i/gateway /PTARGS_0_200_347_0_0_43 /http%3B/localhost%3B7087 /ptcs/navigate.jsp

… instead of: site/integryst.i/gateway /PTARGS_0_200_347_0_0_43 /http%3B/localhost%3B7087 /ptcs/navigate.jsp? cid=e35977c1-2df0-417d-abd9-3c3f5f56657b&fbr=1306030533426

But, the problem seems to occur in JavaScript way before the URL is actually generated in Javascript. Specifically, I kept seeing this exception when stepping through the Publisher script:

While I don’t profess to have delved into the depths that is Publisher Javascript insanity, it was clear that this line caused the page to mis-fire and show the above error.

The fix? Open up \imageserver\imageserver\plumtree\content\private\js\hablador.js and change this:

SessionVars.prototype.toString = function() {
	return this.staticVars.toString();

… to this:

SessionVars.prototype.toString = function() {
	try {
		return this.staticVars.toString();
	catch (err) {}

That way, whatever crazy error it is that happens in this third level of hell doesn’t burn the rest of the code that generates the proper URL. Net result: Plumtree Publisher lives for another day in Internet Explorer 9.

Bug Blog 11: Analytics doesn’t export Document Details

Thursday, April 7th, 2011

We’ve discussed WCI Analytics many times in these posts, and have covered quite a few bugs and patches. This post has all of that drama; so join me! You’ll laugh, you’ll cry. You’ll buy the book.

Every now and then, products in the WebCenter Interaction stack have a bug. And occasionally, Oracle releases a fix for said bug, and things are right with the universe again. But, once in a blue moon, that patch disappears when then the next version of the product is introduced. Such is the case with the “WebCenter Analytics Documents Report Export May Return Different Report [ID 783591.1]” issue.  The patch addresses this problem:

If you choose to “Export User Detail” for the “Other Metrics” section, “Documents” tab report, the results from a different report will be exported.

Or, more succinctly: if you export the User Detail report in Analytics for Collab Documents, it will not actually include document details.  The feature worked in the Aqualogic days, so what’s the deal now?  Well, the story is that you used to be able to export that report properly, then it was broken in ALI Analytics 2.5.  Oracle released a hotfix in 2.5 to repair the issue last year, and their release notes for the patch say to install patch 8198674, or upgrade to Analytics 10.3.

Problem is: the patch that worked for Analytics 2.5 isn’t applicable to 10.3, and 10.3 doesn’t include the patch.

Solution?  I’ll spare you the details of this pretty complicated trick, but at a high level, you need to:

  1. Download this fixed version of BaseCollabServerDataProvider.class, add it to analytics-webui.jar, and put that back into analytics.war.
  2. Add this line to the ptanalytics\10.3.0\settings\config\wrapper.conf file:

  3. Reinstall the service (see the patch release notes)

As shown in this source code diff, this class just defines the original “dimensions” in Analytics that include the document details:

This will cause your “export user details” report to change from this:

… to this:

Release notes for the patch after the break…

Java 1.6.0_24 Breaks Collaboration Server Bulk Upload

Thursday, March 24th, 2011

If you, like me, were foolish enough to upgrade your Java Runtime Environment to 1.6.0_24 (I mean, REALLY, who DOES THAT!?), then you’ve likely found that Bulk Upload (and possibly WebEdit) no longer work in WCI Collaboration Server.

Why?  This post by gimble2 about sums it up:

Java is under new management. Sun was very strict in keeping backwards compatibility; I wouldn’t be surprised if Oracle takes the policy of security first, compatibility second.

Indeed, this is a big problem because Java 1.6.0_24 lies to users:

Unrestricted Access, huh? Bullsh*t.

You can confirm this by viewing the Java Console when trying to run Bulk Upload:

There you’ll likely see an exception like this:

Java Plug-in 1.6.0_24
Using JRE version 1.6.0_24-b07 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\Administrator
Exception in thread “Basic L&F File Loading Thread” access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
Exception occurred during event dispatching: access denied ( C:\Documents and Settings\Administrator\My Documents read)
at Source)
at bulkupload.BulkUploadApplet. chooseFiles(
at bulkupload.BulkUploadApplet. access$100(
at bulkupload.BulkUploadApplet$ (

at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$000(Unknown Source)
at java.awt.EventQueue$ Source)
at java.awt.EventQueue$ Source)
at Method)
at$1. doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at Source)


Bug Blog 10: NTCWS doesn’t work with .NET 2.0

Tuesday, March 22nd, 2011

Today’s post is a quicky:  if you are installing WebCenter Interaction NTCWS (NT Crawler Web Service), you can test the service by navigating to http://NTCWSSERVER/ntcws/ContainerProviderSoapBinding.asmx, and you should see something like this:

If you get something like this, though:

Server Error in ‘/ntcws’ Application.
Configuration Error
Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.
Parser Error Message: The configuration section cannot contain a CDATA or text element.
Source Error:
Line 37: <appSettings>
Line 38: <!– 4.5WS Portal or not? Effects clickthrough and admin preferences. Acceptable values are 1 and 0. 0 implies a 5.0+ portal. –>
Line 39: 0

… you’re likely running the service with .NET 2.0 instead of 1.0.  The simple fix is to update ntcws\10.3.0\webapp\ntcws\web.config and change:

<add key="Is45Portal" value="@IS_45WS_PORTAL@">0</add>


<add key="Is45Portal" value="0"/>

Happy crawling!

A fix for WCI Collaboration WebEdit using Office 2010

Tuesday, March 15th, 2011

As we saw a couple days ago, WebCenter Collaboration Server doesn’t work with Office 2010. The problem is rooted in the fact that WebDAV calls to Collab from Office 2010 aren’t strictly RFC-compliant because they’re missing a Content-Length header, and Tomcat rejects them because of that – even before Collab gets the HTTP requests.

Which got me to thinking: what if we could create an intermediate server that would add this header for us?   Then Tomcat would accept the connection and we’d be able to tell if Collab was able to “do its thing”. I started down the path of creating an Apache ProxyPass to do just this, when a friend and fellow Hak’er (Brian Hak) – who has been fighting his own fires with Collab these days – suggested that I try AJP. Even better, he pointed out, Collab’s default configuration settings allow you to turn this on by just flipping a switch; with it, we could then use mod_headers to add the Content-Length header.

Tip o’ the the hat to Brian for the AJP idea – it turns out that if Apache and AJP are handling the HTTP requests rather than Tomcat and its embedded web server, we don’t even need to muck with HTTP headers, as the request does NOT get blocked:

… and WebEdit (mostly) works in Office 2010!

I should warn you before proceeding: While I can absolutely say that WebEdit works in my test environment with Office 2010, .NET WCI Portal 10.3.0, on IIS 6, your mileage may vary, and I can’t guarantee this will work. I’ve found that Office 2007 has its own quirks – it works with the Collab Office Tools plugin in the ribbon bar, but not the out-of-the-box “save” implementation using Office’s own WebDAV calls. Perhaps that’s a post for another day, but early results show that while this hack doesn’t hurt Office 2007 support, it doesn’t seem to help either. Obviously, do extensive testing before even considering moving to a production environment.  Stay tuned for the next update in these pages, as there’s yet another database hack needed to make it fully functional.

Disclaimers out of the way, let’s dig in. Basically, what we’re going to do is:

  1. Install Apache Web Server on the Collab Machine, with the AJP plugin
  2. Configure Collab to accept AJP calls
  3. Configure the portal to send requests to Apache instead of directly to Collab (Tomcat)


WCI Collaboration Server Not Working in Office 2010

Tuesday, March 15th, 2011

I’ve blogged a LOT about Collaboration Server, and have spent countless hours fighting with the WebEdit features – it’s the “bane of my existence“, a term I used because I thought “crime against humanity” was a little too strong.  More often than not I’ve thrown up my hands and said “sorry, fella, nothing to see here – it just plain don’t work”.  The problem is there are a near-infinite number of combinations, between the different versions of:

  • Plumtree / ALUI / WebCenter Interaction Portal (6.1, 6.5, 10.3.0,, 10.3/Neo)
  • Collaboration Server (4.2, 4.5, 10.3.0,, 10.3/Neo)
  • Windows (XP, Vista, 7), plus various patches
  • Office (2003, 2007, 2010), plus various patches
  • Application Servers (IIS, WebLogic, Tomcat)
  • Web Browsers (IE7 and IE8 – good luck if you have IE9, FireFox or Chrome)

Officially, Oracle only supports the following for WebEdit with version – the latest publicly available version: MS Office 2003 on Windows XP SP2; MS Office 2007 on Windows XP SP2. No Office 2010, no Windows 7. Even Office 2007 is patchy at best.

I’d heard enough complaints, and decided to dig in and try to figure out why one very specific combination doesn’t work: Office 2010 running on Windows 7 against an IIS 6 .NET portal running WebCenter Collaboration 10.3.0.  Here’s what the out-of-the-box install shows when trying to save a file opened through WebDAV:

Your changes were saved but could not be uploaded because of an error.  You may be able to upload this file using the server Web page.

Having not accepted that it was impossible to get WebDAV working in Office 2010, I’ve spent countless hours reverse-engineering Office’s WebDAV protocol, WebCenter Interaction gateway calls, Apache Tomcat protocol handling, and everything in between.

Based on my research, this hack may be helpful for other versions of Office, Windows, and Collab, but I can’t even guarantee the hack I’ll discuss in the next couple of days is perfect, even with these very specific versions.  Proceed at your own risk, and drop me a line if you’d like to discuss your specific situation.


WCI Community Cache-building woes: Give Everyone access to your headers

Sunday, March 6th, 2011

A year ago (wow – time flies!) I promised to elaborate on some other causes of the “Error displaying Dropdown menu tabs” error in WebCenter Interaction headers (which didn’t seem to affect the Plumtree or ALUI versions that predated it).

Well, it’s time to do some more ‘splaining: In most cases I’ve seen, this has to do with the fact that the current user (guest or authenticated) doesn’t have at least SELECT access to the header portlet.  So, if you’re just looking for the executive summary of this post, the first thing to check is whether EVERYONE has at least SELECT access to the header portlet.

Ms. Cooper (my made-up 8th grade algebra teacher) always told me: “Show your work“.  Hell, even if I got the right answer the old bag would still dock me points if I didn’t.  [Before you get offended, note that I can say that because Ms. Cooper is a figment of my imagination – I have great respect for the entire teaching profession and especially every teacher I’ve ever had that wasn’t made up.  I would never refer to any of them as an “old bag”.]

So, let’s show the work:

Bug Blog 9: WebCenter Analytics Timeouts

Wednesday, January 26th, 2011

In our last post, we touched on the unusual nature of BEA’s acquisition of Plumtree, and how BEA largely kept the portal product lines separate with ALUI and WLP.  But that’s not a completely fair assertion: BEA did have a longer-term goal, integrating the two portal “front-ends” through various back-end tricks (such as Ensemble and WSRP).  Similarly, while you may have read that post as a somewhat bleak assessment that my opinion is WCI is dying a slow, painful death, in reality Oracle has stated plans to provide integration services between the products through similar means.  So you could use a WCI front-end with integration through Ensemble and WSRP to other WebCenter Services such as Blogs and Wikis.

The reality, though, is that these types integrations take time – and sometimes, lots of it.  As evidence of this, look no further than Aqualogic Analytics.  When BEA acquired Plumtree, one of the gaping holes in WLP was Analytics, or usage reporting of the product.  Plumtree Analytics was becoming a solid product, but it was very tightly integrated into the Plumtree portal.  So the decision was made to try and abstract some of the major pieces out, with the thinking that these abstractions could be useful elsewhere.  For example, the ill-fated Security Services (once used by the also ill-fated PEP line and now just built into Analytics) and the existing Directory Services came of this integration attempt.  The idea was that by abstracting out security and user management:

  1. These services would be available to other applications that were developed down the line
  2. Analytics would be more compatible with WebLogic Portal, which also had an LDAP repository to access user and group information

While I think that if more time had been available for the integration to become more seamless, the problem is that no one won in this attempt because it was aborted too early.  I have no idea whether WLP still supports Analytics integration, the old Security Services are now just built into the product as a phenomenally complicated set of DB tables that make little sense, and Directory Services are a dramatically inefficient way to access user and group information.

Case in point – I’ve had a couple of clients report Analytics timeouts for some users, but other users were seeing the proper report:

How does this relate to the whole Plumtree/BEA/Oracle integration saga? The old Plumtree Analytics application used a SQL query called something like QUERY_USER_FLATTENED_GROUPS.  Basically, this was a Plumtree Portal-specific SQL query that, given a user ID, would spit out all nested groups that that user was a member of.  So if a user was a member group A, and Group A was a member of Group B, the query would return both Group A and B.

The ALUI version of Analytics, though, utilized Directory Services so that group membership didn’t need to come from PT-specific SQL queries.  It could come from generic LDAP queries.  The problem is, LDAP doesn’t have a mechanism like QUERY_USER_FLATTENED_GROUPS, so for any given user, Analytics needs to query LDAP for the groups a user is in.  And then, Analytics needs to check to see which groups THOSE groups are a member of.  And so on, and so on.  You’d be surprised – through inheritance, you may be a member of thousands of groups, and rather than a single SQL query, you’re now dealing with tens of thousands of LDAP calls.

Bottom line:  Integrations and product convergence can work, but they’re phenomenally complicated, because every piece of abstraction added can cause unanticipated side effects.  Which is probably why Oracle is taking this whole process pretty slowly.

Full Bug Report after the break for your convenience. (more…)