Archive for the ‘Publisher’ Category

Using WebCenter Publisher with Internet Explorer 11

Tuesday, May 26th, 2015

The release of Internet Explorer 11 has caused a unique set of issues for WebCenter Interaction. We’ve covered some WCI portal hacks and Collaboration server hacks to work around some of these challenges; today’s post is about Publisher.

First off, you’ve probably noticed that Publisher doesn’t work with IE11:
publisher-ie-5.5
The solution to this problem is simple: Go to Tools: Compatibility View Settings, and add your portal site to the list:
compatibility_list_ie11

This will enable “Compatibility Mode” for IE, which means that (among other things) the user agent string will contain “MSIE”, which lets Publisher use its antiquated user agent sniffing to enable Publisher Explorer:
publisher-explorer
The next one after the break isn’t quite so simple. (more…)

Installing (unsupported) Publisher 6.5 in WCI 10gR4 environment

Wednesday, April 15th, 2015

Installing WebCenter Interaction 10gR4 is no treat, especially given that supplemental products like Publisher or Studio are not supported in Windows Server 2008, and that’s likely the exact reason why you’re upgrading – to get to Windows Server 2008 (you’re not doing it for the “features”, are you?).

Many of the installers fail for crazy reasons, and I’ve found myself having to do quite a few hacks to get everything up and running. One error that’s a particular nuisance is that services often fail to install, throwing an error in the installation process like this:

BUILD FAILED
D:\bea\alui\uninstall\ptcs\6.5\register\register.xml:574: The following error occurred while executing this line:
D:\bea\alui\uninstall\ptcs\6.5\register\macrodefs\wrapper.xml:92: D:\bea\alui\ptcs\6.5/bin/service.bat is not a valid file. This parameter must point to the batch or shell script that launches the wrapper service.

The good news is that usually these installation errors happen after all files have been copied, and there’s often a batch file in the \bin folder for your particular application to handle service creationg. So, for the above example where the Publisher installer has failed, the steps to complete the installation are simple:

  1. Open a command prompt as administrator (click start, type cmd, right-click command prompt and pick “Run as Administrator”)
  2. Cd to d:\bea\alui\ptcs\6.5\bin\
  3. Type “service install”

Fix WCI Publisher Search with a simple tweak

Saturday, October 11th, 2014

Ever seen this error in WebCenter Publisher when using Friendly URLs?

INFO | ERROR java.lang.StringIndexOutOfBoundsException: String index out of range: -1
INFO | ERROR at java.lang.String.substring(String.java:1768)
INFO | ERROR at org.apache.jsp.published_005ftools.search_jsp._jspService(search_jsp.java:101)
INFO | ERROR at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:94)
INFO | ERROR at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
INFO | ERROR at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:324)

Yeah, it’s not the first time that Friendly URLs breaks existing functionality, and like that Excel issue, fortunately the fix is pretty easy. Basically, you’ll need to open up the ptcs.war file and edit the /published_tools/search.jsp file in there. Specifically, there’s a section that looks like this:

       String baseURL = (cspRequest.getReturnURI().toString());

       //SE-VV: 57027 - With the recent portal code changes in Merced, the string "gateway"
       //is not present in the baseURL anymore. As a workaround, we instead look for "?" so that index is a 
       //non-negative integer. Now, when we search for a CI from within a news portlet, it'll take us to
       //the correct search results page instead of throwing an error.
       int index = baseURL.indexOf("gateway");
       if(index < 0){
              index = baseURL.indexOf("?") + 1;
       }
              baseURL = baseURL.substring(0, index - 1);

(more…)

Publisher Settings Gone But Not Forgotten

Tuesday, May 1st, 2012

Even though ALUI Publisher didn’t get a refresh with WebCenter Interaction 10gR4 and is still at version 6.5, that doesn’t mean it’s not still a large part of your (aging) portal infrastructure.

Hat tip to Andrew Foster for this one – it seems that some of the pre-6.5 Publisher settings still work in Publisher 6.5. Specifically, if you’re having problems getting Publisher to load your custom styles from community-themes.txt when you create a new header portlet, or you see an error like the one below in Publisher Diagnostics, then you can use the old setting CommunityStyleSheetListURL to get Publisher to properly load it.

In other words, if you’re getting this:

… then you should create a line in content.properties to fix that error:

CommunityStyleSheetListURL= http://machine_name /imageserver/plumtree/common/public/css/community-themes.txt

… and your custom styles will then be available when creating Header portlets in WCI:

Add SSL Certificate to Plumtree Publisher JRE

Tuesday, November 15th, 2011

Publisher has a configuration setting in content.properties that allows it to connect directly to the imageserver. Why? Well, the comment in the file describes it appropriately enough:


# JSComponents need to directly access the imageserver from the Publisher
# machine in order to obtain some configuration information. By default it uses
# the image server URL which is provided by the portal for portal end-users,
# but you may also specify an alternate image server URL to be tried first instead,
# such as in the case where the system topography prevents the Publisher
# from accessing that end-user URL.
#JSComponents.AlternateImageServerUrl=http://machinehost:port/imageserver

Problem is, it doesn’t seem to work for the diagnostic tool, and may not work when Publisher needs to load community-themes.txt (which it needs in order to provide the style sheet drop-down for header portlets). So Publisher still needs to connect to the image server – but if the image server is configured to only use SSL, you’re likely going to see an error like this:



Exception Message: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

The solution – import the SSL certificate from the imageserver – is after the break.
(more…)

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:

http://portal.integryst.com/ site/integryst.i/gateway /PTARGS_0_200_347_0_0_43 /http%3B/localhost%3B7087 /ptcs/navigate.jsp

… instead of:

http://portal.integryst.com/ 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.

Configure Publisher To Use A Network Share

Thursday, January 6th, 2011

In many larger Plumtree / WCI Publisher installations, you will have 1 “full” instance of Publisher used for authoring content, and one or more “zombie” (really, that’s what they call it in the configs!) instances serving up that content. 

See Bill Benac’s excellent diagram on this type of configuration.  Often, you’d have the publishing component of Publisher write to a network share, then use the zombie instances to proxy the content itself, or have the zombie instances redirect to a different web server configured to serve up the files.  Why two different approaches?  See this article I wrote back in ’08 for why proxying isn’t always ideal after an upgrade.

Anyway, in some instances, even with just one Publisher instance, you may want to publish to a network share, and don’t want to bother with configuring an additional Web Server to serve up that content.  In those cases, you can easily change Publisher’s own embedded Web Server (technically, it’s JBoss) to serve up this content.  Just perform the following steps:

  1. Set the Publisher Service to run as a user that has full access to the network share.
  2. Update your Publishing and Browsing targets in Publisher Explorer to use the correct paths.
  3. Update the %ALUI_HOME%\ptcs\6.5\container\deploy\jbossweb-tomcat50.sar\server.xml file, specifying your network share here:

That way, when the portal attempts to load published content via http://wci-publisher:7087/publishedcontent/, the portal will be connecting to the JBoss instance running Publisher, but the files will be coming from the network share.

Sorting News Articles in ALUI Publisher

Thursday, October 14th, 2010

Out of the box, WebCenter Interaction Publisher has a News portlet template that allows Content Managers to create News Articles, and display them in a summary portlet with a link to see the entire list of articles.  The articles themselves are:

  1. stored as Content Items under the -article_path-/ Articles folder,
  2. created based on the templates in /Portlet Templates/ _NEWS/ en/, and
  3. rendered by the “Main Page” (the portlet itself showing the top n articles) and “Index” (the list of all news articles when the user clicks “more”) Presentation Templates.

The problem is, the articles are listed based on when they were published, not when they were created or modified.  Which doesn’t make sense all the time – what if someone goes in and publishes the entire folder?  You’d end up with all news items showing up on the same day.  The fix here is to update the two Presentation Templates mentioned above to sort and display on when the “article” Content Items were modified, not published.

What you may not know is that when a user creates a portlet from a Publisher template (such as the one in /Portlet Templates/ _NEWS/ en/), Publisher creates a COPY of ALL OBJECTS into the new Publisher folder the Content Manager specifies when creating it.  The implication here is that you not only need to apply these fixes to the Content Item TEMPLATES in Publisher, but also each individual News Portlet independently.  (Or, you could use something like PublisherManager, but that’s another story entirely).

However you do it, the changes that need to be made can be found after the break. (more…)

Cool Tools 10: Base64 Decoder

Thursday, September 16th, 2010

Generally, my Cool Tools articles feature tools that are novel, unique, or otherwise helpful when managing WebCenter Interaction portals, or other applications that can help augment (or – dare I say, replace?) it.  Today’s Cool Tool is in a category where apps are a dime a dozen.  So, let’s call, uh, Webnet77.com’s Base64 Decoder a Cool Tool:

Why highlight a dime-a-dozen online app that’s pretty much just a free online tool?  Because today I’m going to explain a bit about how Basic Authentication works between the portal and remote tier, and show you a trick to answer a question that you may have come across during your portal administration:  what password has been configured for the “authenticationid” in the portal for ALUI Publisher Remote Server (or Collaboration Server, for that matter)?  In the process (after the break), hopefully you’ll get a little insight into why it’s not all that secure in and of itself. (more…)

Bug Blog 7: ALUI Publisher Port already in use?

Sunday, September 12th, 2010

This (configuration) bug has been around in Publisher for a while, and I’ve always fixed it the “wrong” way. Occasionally, you may have seen the following error crop up in %PT_HOME%\ptcs\6.x\logs\service.log when starting ALI Publisher, and Publisher fails to start:

INFO | jvm 1 | 2010/07/20 16:59:07 | 16:59:07,450 ERROR Starting failed jboss:service=Naming
INFO | jvm 1 | 2010/07/20 16:59:07 | java.rmi.server.ExportException: Port already in use: 1098; nested exception is:
INFO | jvm 1 | 2010/07/20 16:59:07 | java.net.BindException: Address already in use: JVM_Bind

Why? Well, Publisher uses some internal JNDI services to communicate between components (I think; honestly I have no idea what this port is actually for), and if it can’t grab the port at startup, it can’t start up. Wonderful. This port has always been specified in %PT_HOME%\ptcs\6.x\settings\config\container.conf:

## [JBOSS] JNDI SERVICE
plumtree.container.jboss.jndi.port=10099
plumtree.container.jboss.jndi.rmi.port=1098

… and I’ve always fixed this problem by changing that port number and re-starting (as I write this blog, the WebCenter Interaction portal you’re reading this site on has a value of 1097 in there, indicating that at some point long ago I had this problem and fixed it this way).

Recently, though, I got a great explanation from Naman Shah at PPC: this has to do with Ephemeral Ports in Windows. The description in that article says it all:

What is not immediately evident is that when a connection is established that the client side of the connection uses a port number. Unless a client program explicitly requests a specific port number, the port number used is an ephemeral port number. Ephemeral ports are temporary ports assigned by a machine’s IP stack, and are assigned from a designated range of ports for this purpose.

In other words, Publisher can’t start because Windows is already using that port for one reason or another. So, now I know the “right” way to fix this issue: rather than playing whack-a-mole changing Publisher’s port every time the problem occurs, you should simply tell Windows not to use that port.

How? In the registry, navigate to HKLM\ SYSTEM\ CurrentControlSet\ Services\ Tcpip\ Parameters\, and add or change a line to the Multi-String value called ReservedPorts. Add in 1098-1098 on its own line, and Windows will stop using that port in the future, allowing Publisher to keep doin’ what it’s doin’.