Posts Tagged ‘Studio’

Fix WebCenter Studio Server for IE11

Thursday, September 24th, 2015

IE11 has caused all sorts of problems in the WebCenter Interaction stack thanks to its new new User-Agent header that these legacy products can’t parse.

Today’s issue is how to fix Studio Server. If you’re seeing this exception in your logs, it’s because Studio can’t parse the user-agent string:

StandardWrapperValve[gatewayservlet]: Servlet.service()
for servlet gatewayservlet threw exception
java.lang.StringIndexOutOfBoundsException:
String index out of range: -1
at java.lang.String.substring(Unknown Source)
at com.plumtree.studio.util.BrowserInfo.parse(BrowserInfo.java:334)
at com.plumtree.studio.util.BrowserInfo.(BrowserInfo.java:137)

You could just use Compatibility View, but that’s not always an option when you have a ton of end-users. Instead, I opened up the studio.war file and recompiled in a fix that wraps a try-catch block around this bad code, and simply says “if I can’t figure out what browser is being used, assume it’s legacy IE.”. The class file is at com.plumtree.studio.util.BrowserInfo:

try {
  .... regular legacy browser parsing ...
}
catch (Exception e) {
   browserName = "MSIE";
   browserVersion = 6F;
   browserPlatform = "Windows";
   jsControlsOK = true;
}

Drop me a line if you’d like the replacement class file to use in your version of studio.war.

Change the Unchangeable in AquaLogic Studio

Monday, October 31st, 2011

I don’t think Oracle even bothered renaming Aqualogic Studio to WebCenter Studio – hell, even BEA never touched Studio after it acquired Plumtree – so whatever you call it, Studio is dead and has long been abandoned. I made a case to Oracle once it should just be open-sourced, and was laughed out of the (virtual) room….

Today’s post is about this long-dead product that a surprising number of Plumtree customers just can’t seem to shake – it provides just enough functionality to be functional for end users.

First of all: Migrate to Frevvo. Even if you don’t use Integryst’s Frevvo integration, Frevvo is how form building and workflows should have been implemented. Maybe Studio would have become this if it hadn’t been abandoned so many years ago, but really, if you have serious electronic forms and workflow needs you shouldn’t be using Plumtree Studio any more.

BUT, if you absolutely INSIST on clinging to Studio, let’s take a trip down memory lane. My very first blog post discussed an Easter Egg in Studio, but it’s worth mentioning that this Easter Egg isn’t just for playing Tetris.

Let’s say you want to change the text of a button to a different language. When you’re editing any Studio portlet, hit CTRL-ALT-? (Or, CTRL-ALT-SHIFT-/. You’ll figure it out.) to bring up the popup:

From here, click “Edit XML”, find the text of the button you want to change and update it:

Now no text in your form is out of reach. The above warning is pretty clear about being careful here, but editing the text is pretty straight-forward.

Parlez-Vous Fran├žais?

Cool Tools 19: Frevvo Live Forms (with WCI Integration!)

Friday, May 27th, 2011

We’ve spent some time recently talking about AquaLogic Studio Server, and even got a tip from our buddy Geoff Garcia about the date Oracle officially stopped supporting it (November 2010).

So now what? You still have requirements to easily build forms and workflows and reports, but aren’t planning on a full move to another platform in the short term. Well, at a recent project where we’ve deployed Atlassian’s Confluence (also integrated with WCI), we came across this great form-builder plugin called Frevvo Live Forms.

In a word, it’s awesome – check out this quick demo (more videos here):

That got us thinking: what about using Frevvo as a replacement for Studio? We could develop the integration so that forms could be added as portlets and administered just like Studio. It’d do everything Studio can (integrate with portal security settings, custom-define forms and fields), have great new features (new data types, drag-and-drop form building, workflows), and, well, it wouldn’t suck like Studio.

So, that’s exactly what we did:

Interested in how to dump Studio and move on to a more powerful form-builder with workflows and much cooler reports? Contact us.

Increasing the Character Limit for ALI Studio in SQL Server

Sunday, May 22nd, 2011

By now you’re aware of our stated problem – we need to increase the size of text fields in Aqualogic Studio. We’ve already found the file used for the JavaScript, and used a new Cool Tool (HxD) to assist in the recompile, but there’s still a problem: when Studio creates new forms, it also creates a separate table in MS SQL Server. And the size of text fields in those tables that already exist is still 1,000. So if we just update the Javascript, our existing forms aren’t going to have the proper error checking, because our JavaScript is preventing field sizes of, say, 10,000 characters, but at the database layer, the size of those fields is still 1,000 characters. Even worse, if you try to increase the size of the table in the code to >4,000 characters, SQL Server will reject it because the regular nvarchar data type doesn’t go over that limit:

2011-04-21 14:54:54,819 ERROR [rocessor25] AppDesignerHandler: Error processing wizard form post
Error creating new user database ‘Survey Database’.
– [XNRC39]The size (10000) given to the column ‘test_10000’ exceeds the maximum allowed for any data type (8000).
at com.plumtree. studio.model.data. access.TableDAOSQLServer.create (TableDAOSQLServer.java:220)
at com.plumtree. studio.model.app. Table._create (Table.java:585)
at com.plumtree. studio.model.app. Table.save (Table.java:618)

So, we have two problems: first, we need to tell Studio to create these fields with a type of NVARCHAR(MAX) rather than NVARCHAR(10000), and second, we need to update all existing tables.

The first problems is pretty straightforward – we just need to update the TableDAOSQLServer.java file (or, if you’re on Oracle, TableDAOOracle.java). Change:

      sqlBuffer.append(this.mUserColumnType).append("(").append(this.mUserColumnWidth).append(") ");

…to:

      sqlBuffer.append(this.mUserColumnType).append("(MAX) ");

… and recompile as mentioned in the last post.

The second problem requires some SQL Server voodoo – we need to write a SQL Script that generates a SQL Script. So, if you run this script as your studiodbuser:

SELECT 'ALTER TABLE ' +  syo.name 
    + ' ALTER COLUMN ' + syc.name + ' NVARCHAR(MAX);'
   FROM sysobjects syo
   JOIN syscolumns syc ON
     syc.id = syo.id
   JOIN systypes syt ON
     syt.xtype = syc.xtype
   WHERE 
     syt.name = 'nvarchar' 
    and syo.xtype='U'

… it will produce a SQL Script that looks like this:

ALTER TABLE PTU_SHPR2_Progress_Revi ALTER COLUMN Additional_Comments NVARCHAR(MAX);
ALTER TABLE PTU_SHPR2_Progress_Revi ALTER COLUMN U__Is_the_work_proceeding_i NVARCHAR(MAX);
ALTER TABLE PTU_SHPR2_Progress_Revi ALTER COLUMN U__Is_progress_towards_the_ NVARCHAR(MAX);

So basically, you’re using s script to find all the existing text fields, and creating a new one to actually increase the size limits on those fields.

Cool? Cool.

Cool Tools 18: HxD Hex Editor

Thursday, May 19th, 2011

Continuing our journey on increasing ALI Studio’s character limit, we’ve now identified the code that needs to change – it’s in com.plumtree. studio.model. data.access.TableDAO.java.

The problem is, Studio is ancient, so while we can easily update the following code:

  protected int mUserColumnWidth = 1000;
  protected int mUserColumnWidthChars = 1000;

… we can’t just recompile the file using the latest JDK without expecting problems.

So, we need to figure out what Java version was originally used to compile this file. To do this, we need today’s Cool Tool: HxD Hex Editor. Why? Because all Java .class files have the same set of bytes at the beginning identifying them as Java files, along with the JDK version used to compile.

HxD allows us to view the actual bytes, and and it does it well. Opening the TableDAO.class file in HxD, we see:

Bytes 6 and 7 are “00 2E”, which represent JDK 1.2.

Once we’ve made our changes and have the correct JDK downloaded, we rebuild the file, making sure to include the proper .jars in the CLASSPATH:

set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\log4j-1.2.8.jar
set CLASSPATH= %CLASSPATH%; C:\code\studio\ WEB-INF\lib\jakartaRegexp1dot2.jar

C:\jdk1.2.2\bin\javac -classpath %CLASSPATH% com\plumtree\ studio\model\ data\access\ TableDAO.java

Take the TableDAO.class file, jam it back into your studio.war file, and you’re good to go – assuming you haven’t increased that value over 4,000 characters! There’s still one more glitch in this journey

Increase Plumtree Studio Character Limit

Monday, May 16th, 2011

We don’t write much about Aqualogic Interaction Studio ’round these here parts anymore. That’s because Studio has long since been end-of-life’d (by BEA, even before the Oracle acquisition!). But, that doesn’t mean it isn’t alive and gasping its last breath in many of your portal sites. Sure, it’s an over-the-hill product but it does serve a functional need: the ability to easily create forms, polls, and other data entry forms.

So, it’s with reluctant enthusiasm that I start the first of a three-part series on “How to increase the 1,000 character limit in Plumtree Studio”. Even if you don’t actually use Studio, hopefully you’ll find the journey interesting and informative for your other portal diagnostic needs. I’ll walk you through the process of identifying the code here, recompiling and reintegrating in Part dos, then some SQL Server diagnostics in Part tres.

The problem, as recently presented by a client, was that Studio has a 1,000 character limit on text fields. If an end user tries to type more than 1,000 characters, they get this lovely message:

But, we needed to increase that value. While it would be really nice if there was just some configuration file somewhere, sadly, the 1,000 character limit is hard-coded. So we first need to find the file that’s producing this alert. (more…)