Archive for the ‘Collaboration Server’ Category

Replace Collab’s horribly broken file uploader

Sunday, September 27th, 2015

While the entire WebCenter Interaction stack is now dead, there are still some of you out there using the legacy code because it “just works”.

As technology evolves, though, more and more pieces of the stack have started to crumble – including Collaboration Server’s multi-file upload. We’ve talked about issues with it in the past and hacked it more than once, but it pretty much just worked in IE7-9, and wasn’t even available in other browsers like Chrome.

So, enough was enough: in search of a better solution, I came across the awesome FineUploader product, which does an incredible job of allowing multiple uploads with virtually any browser (degrading properly based on available features of each browser), and doesn’t rely on any crap technology like Flash or Java.

Rather than completely re-inventing the wheel, I just cracked open the collab.war file and replaced the old crap code with new code leveraging fineuploader.com; uploads themselves are still processed the exact same way that the old java app used to use, so nothing is compromised in terms of features or security. It was really only a few files that needed to be changed, which alters the upload form that used to look like this:
collab-file-upload-java
… to now look like this:
fine-uploader-collab-upload
(more…)

Using Collaboration Server with Internet Explorer 11

Friday, April 3rd, 2015

Webcenter Collaboration 10gR4 was released in May 2013. Internet Explorer 11 was officially released in October/November of that year. Why is this a problem? Because, since Oracle has killed the entire product line, users are left high and dry with compatibility issues, getting a degraded version of Collab Explorer that’s missing key features like Bulk Upload:
collab-ie-11

Why is this? Because the abomination known as Internet Explorer threw developers yet another curveball in IE11: they changed the user agent string to one that doesn’t contain the characters “MSIE”. Sure, Oracle can be faulted for not following best practices on browser detection, but we’ve thrown enough angst Oracle’s way in this blog; it’s Microsoft’s turn today. I mean, they’ve used MSIE in their user agent strings for literally TWENTY YEARS; of course they should change it now to:

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko

The solution is yet another Collab Hack requiring you to decompile code. Specifically, in collab-core.jar, we need to update com.plumtree.util.http.BrowserUtil.java. There are two places in the code that need to be updated; you’ll note I didn’t even attempt to implement a generic solution, but am specifically looking for this IE11 user agent string. That, of course, is not completely future-proofed, but since WCI is basically dead, and IE is getting killed off, I’m not too worried. The updated code will look something like this:

    private static float parseVersion(HttpServletRequest request, String searchPattern)
    {
        String userAgent;
        userAgent = request.getHeader("User-Agent");

	if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
		return 11.0F;
	......

… and:

    public static String GetBrowser(HttpServletRequest request)
    {
        if(InStr(request.getHeader("User-Agent"), "MSIE"))
            return "IE";
        else {
	        if(InStr(request.getHeader("User-Agent"), "rv:11.0"))
				return "IE";
			else
	            return "NS";
		}
    }

(more…)

The Dreaded Collaboration Search Index Rebuild

Wednesday, March 18th, 2015

Does the following screen shot fill you with dread?
collab-search-rebuild

If so, you’ve likely one of us who have had the dubious displeasure of having to work with the terribly bad “Collab Reindexing” functionality, where you ask Collab to rebuild the contents of the search index – usually after a migration or upgrade. The problem is that Collab can store hundreds of thousands of documents, and this process tends to fail, fill up disk space, or do various other terrible things like kidnapping your hamster and holding it for ransom. When any of those things happens, you have to just start over from scratch and pray harder next time.

I recently did a WebCenter 10gR4 migration/upgrade because Windows Server 2003 is approaching end of life in July, and we wanted to upgrade to Windows Server 2008 without jumping through any crazy hoops that Oracle wouldn’t support in 10gR3. The 10gR4 support matrix indicates Windows 2008 (x86 and x64) support for WCI 10.3.3, Collab 10.3.3, and Analytics 10.3.0.2 (don’t ask why the versions aren’t the same, or why Publisher is now technically unsupported for those upgrading to 10gR4). I won’t even rant here about how terrible the installation process was, resolving error after error and manually installing services and deploying web apps, but the Collab Search rebuild deserves a special place in hell.

First, let’s get the “good news” out of the way since there isn’t much of it: in Collaboration Server 10gR4, there’s now an option to re-index only the documents that haven’t been submitted to search yet because the process just exploded. Which is super. While I’d prefer the process not “explode” all the time, I’ll take what I can get: restarting the process at document 110,000 out of 230,000 is much better than restarting at document 1.

The bad news is that the process still fails all the time, despite claims of fixes and notes of “re-breakings” (Oracle bug – login required). The logging is terrible (hint: you can tweak some log settings by cracking open the Collab .war file and changing log parameters there, and you can turn on the following in PTSpy – in addition to “Collab” and “SearchService” – to get a more accurate picture of this bizarrely convoluted process: ALUIRemoting, Remoting, dummy, Configuration. When the search rebuild process fails, you can no longer access Collab Administration (because it seems the first thing it tries to do is connect to the Search Service, and that’s dead now). And the errors that show up aren’t even consistent over time. You’re likely to see a ton of different errors after a period of time, usually with the remoting process:
jms-connection-failed
This error seems to be quite common though:

javax.jms.JMSException: Exceeded max capacity of 50

What can you do about this? I changed the transport protocol for the Collab Search Service from TCP to HTTP and it cleared up the problem, although for the life of me I can’t tell you why. Read on for details of how to do this yourself… (more…)

Do you use WebCenter Interaction Wikis or Blogs?

Wednesday, April 10th, 2013

Those of us who go way back with Plumtree remember PEP (Pages, Ensemble, Pathways), which were pretty much futile attempts to break into more “modern” technologies like Blogs, Wikis, RSS, and other buzzword-worthy tech after “The Portal” had been conquered. It didn’t go well, but we won’t dwell on that. We all make mistakes.

I had planned on doing a review of WebCenter Interaction Collaboration Server in Neo, a.k.a. 10gR4. But honestly, there’s not much you need to know, and most of you have moved on anyway. There is now some UCM integration (which, of course, is already re-branded) and what looks like some Excel functionality that honestly I haven’t even looked at but probably fixes some issues with the late-90′s era Excel Portlet.

Oh, and it looks like they re-signed those WebEdit and Upload controls:
webcenter-collab-signed

But what frankly came off as almost insulting was the “Blog” and “Wiki” functionality that’s now included. I’ll just drop two hints: Atlassian Confluence and WordPress. Don’t waste your time with Collab.

For the morbidly curious, I’ve included some screen shots after the break.
(more…)

Rebuilding WebCenter Collaboration Index By Project

Thursday, April 4th, 2013

Another tip of the hat to Brian Hak for this pretty awesome Hak (see what I did there?).

Last year, Brian was faced with a problem: Some documents in WebCenter Interaction Collaboration Server weren’t properly indexed, and his only option was the rebuild the ENTIRE index (a pain we’re all pretty familiar with). With many thousands of documents, the job would never finish, and end users would be frustrated with incomplete results while the job toiled away after wiping everything out.
collab-search-service

So he took it upon himself to write CollabSearchRebuilder. CollabSearchRebuilder allows you to rebuild specific subsets of documents without having to wipe out the whole index and start all over again.

Feel free to download the source and build files and check it out!
(more…)

Turn WebEdit OFF in IIS for WebCenter Interaction Collaboration Server

Monday, March 25th, 2013

We’ve had a good run with WebEdit functionality in the old Plumtree / ALUI / WebCenter Collaboration Server. There comes a time, though, when the pain/cost is increasing and the benefit/payback of fixing the issues is decreasing.

Such was the case at a client was getting this security prompt every time they tried to open an Office document that had been uploaded to Collaboration server through WCI:
office-security-prompt

It turns out that when Office 2010 opens a document from a web page, the first thing it tries to do after downloading the document is execute a WebDAV request (PROPFIND) to that server:
propfind
This makes all kinds of sense from Microsoft’s perspective – if a Word document is opened from a web site, first check to see if it’s a SHAREPOINT site, right? That way Office can enable all those neat WebEdit/WebDAV features automatically.

The problem was that IIS was choking on this request because Windows Integrated Authentication was prompting for the user’s domain credentials – and even if the proper user/pass was supplied to IIS, the portal still had no idea what to do with those WebDAV verbs.

The solution: just kill off WebDAV entirely in this portal instance. You do this by changing the verbs for the portal virtual directory (.pt extension) to only accept the verbs “GET,HEAD,POST”:

iis-verbs

This way, even if Office does try to check the WebDAV verbs, IIS is going to deny those requests before even letting them through to the portal, which probably wouldn’t know what to do with them anyway.

New Collaboration Server Fix: WebCenter Patch Process?

Sunday, May 13th, 2012

I got a tip a couple months ago (thanks Brian Hak!) about a new Collab patch that “fixes the bulk upload” issue, and yes, it’s taken me this long to actually dig in a bit.

At first, I thought this was the same one I wrote about in February of last year – the IE8 Critical Fix. But, it turns out that this patch was released in May in 2011.

From the release notes in the patch called “Patch 12423316: WLS1034: UNDER JROCKIT, COLLABORATION PROJECT ACCESS FAILS WITH TREEUNMARSHALL“, these are the issues resolved. With the exception of the first one, everything else is the same as the February patch:

  • Using JRockit with Weblogic Server 10.3.4 collaboration project access throws a TreeUnmrashall exception (12423316).
  • WebEdit does not work on IE8. (9723488)
  • Error in task submenu in IE8 (9712774)
  • Cannot upload multiple files in Collab (9274372)
  • Bulk upload JRE updated to 1.6 in order to support IE8 (8760280)
  • Notifications should be sent from a fixed address for creation and deletion (9647426) This fix involves updates to both collab and notification components.
  • Subscription to project overview causes conflicts with Immedate Subscriptions (8759642)
  • Non gatewayed webedit does not work (9434805)
  • File leak in Search Service during search index rebuild (11726008)
  • Webcenter Collaboration notifications to large numbers of recipients fail (9484113)

So, sure, this patch from May of last year supersedes that one from February. What’s strange, though, is that the link I provided in the post last year no longer works. Shouldn’t it have a message that says “this is no longer the latest patch version”, or “click here to see a list of all critical fixes released for this product”? In fact, where IS the definitely list of all of Oracle’s critical fixes? Seriously, does ANYONE know?

Don’t get me started on Oracle’s BS monthly email about all their “critical patches”. In fact, maybe you should, ’cause I’m this close to writing a Wall of Shame Rant about that ridiculousness. I mean, really, WHO is possibly helped by this?

Either way, stay tuned here for some reviews of the new Collab 10gR4 version, which presumably contains these patches (although, not totally guaranteed given the strange release history).

There’s a WCI App For That 8: SMTP2Collab

Tuesday, June 7th, 2011

WebCenter Collaboration Server has a decent feature that allows end users to email documents directly to Collaboration Server by using a dedicated SMTP address for each folder:

Properly configured, attachments (but not message text) on any email coming in to that address are created as documents in the Collab Folder. But what if you want to capture the text of that email? And what if the user doesn’t have an account in Collab? Also, wouldn’t it be nice if inbound documents to the few folders you care about allowing (possibly anonymous) document submissions could have “vanity email addresses” like rrrgm8ty@mycompany.com for the pirates in your organization?

That’s exactly what SMTP2Collab does. Like Collab, it sets up an inbound SMTP server. Any mail delivered to it – whether the user has an account in the portal or not – gets created as a document in the specified folder, and a linked discussion is also created containing the text of the email. Oh, and you can create any vanity aliases you want for the folders:

Wanna see it in action? You know the drill.

100% CPU in Collaboration Server on Solaris?

Tuesday, May 10th, 2011

Today’s post comes from a Rock Star Consultant in the WebCenter Consulting space.  It has to do with WCI Collaboration Server consuming 100% CPU on Solaris, but might be relevant to those Windows users out there.  While I personally haven’t experienced this particular issue at client sites (virtually all of them Windows), it sounds like if you’re running Collab in Unix, it might be worth upgrading your JVM.

Problem:

Collab periodically starts chewing up CPU until it maxes out the box and ultimately dies.

Details:

This looks to ultimately be a problem at the JDK level.  Out of the box, the Tomcat Collab is deployed to uses JDK 1.5.  There’s a bug in JDK 1.5 that causes the NIO connector in tomcat to sometimes freak out, resulting in Collab spinning out of control and eating all the server CPU.  For details, see this thread:

http://www.mail-archive.com/users@tomcat.apache.org/msg36900.html

Diagnosis:
Here’s the rundown on the diagnosis we did (Collab on Solaris)

Symptom:
Collab is eating up a huge amount of CPU minimal user load(80%+ on a server where it usually uses ~10%).

Troubleshooting performed:
1) Generated a stack trace for Collab
2) Run prstat -Lp <Collab Pid>.  This shows us how much CPU each thread in Collab is taking. Note that the top three threads in the attachment are taking up 22% of the CPU each.  Also note that those threads have used a huge amount of CPU time: 3-4 hours each).

3) Note the LWPID of each of the busy threads:  6248, 3413, 8198.
4) Now convert those numbers to Hex:
6248 -> 1868
3413 -> d55
8198 -> 2006
5) Now look for those hex thread ids in the thread dump.  You’ll see they all have the same stack (for example: nid=0xd55).  Specifically:

—————————

“http-7127-exec-23″ daemon prio=10 tid=0x00000001008ee360
nid=0xd55 runnable [0xfffffffeff0fa000..0xfffffffeff0ff728]
at org.apache.coyote.http11. InternalNioOutputBuffer.addToBB(InternalNioOutputBuffer.java:610)
- waiting to lock <0xffffffff40927c48> (a org.apache.coyote.http11.InternalNioOutputBuffer)
at org.apache.coyote.http11. InternalNioOutputBuffer.access$000(InternalNioOutputBuffer.java:44)
at org.apache.coyote.http11. InternalNioOutputBuffer$SocketOutputBuffer.
doWrite(InternalNioOutputBuffer.java:794)
at org.apache.coyote.http11. filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:126)
SNIP

Again, note that all the stack traces are the same and they appear to be trying to flush/close and output stream, but it looks like they’re blocked.

Fix:
Update the Collab JVM to a recent release of the 1.6 JDK (1.6u23 for example).  Restart Collab

Results:
Prior to change, Collab was crashing multiple times a day and using at least 20% of the CPU on a beefy Solaris box.  Post change, no Collab crashes, and Collab is pretty consistently using about 4% of CPU on the server.

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” java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\Administrator\My Documents read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
(snip)
Exception occurred during event dispatching:
java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\Administrator\My Documents read)
at java.security.AccessControlContext.checkPermission(Unknown Source)
(snip)
at com.plumtree.collaboration.app. bulkupload.BulkUploadApplet. chooseFiles(BulkUploadApplet.java:191)
at com.plumtree.collaboration.app. bulkupload.BulkUploadApplet. access$100(BulkUploadApplet.java:15)
at com.plumtree.collaboration.app. bulkupload.BulkUploadApplet$ 1FileChooserDisplayer.run (BulkUploadApplet.java:329)

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$1.run(Unknown Source)
at java.awt.EventQueue$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$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 java.awt.EventDispatchThread.run(Unknown Source)

(more…)