Loading Sametime Proxy Scripts

More useful insight on integrating sametime dojo widgets into a web application - this entry explains how scripts are loaded.

Why can't I find these scripts?

Inspecting the example HTML provided with the ST proxy, one can identify some scripts such as:

<script type="text/javascript" src="http://<YourServer>:9081/stwebclient/dojo_1.2.3/dojo/dojo.js"></script>
<script type="text/javascript" src="http://<YourServer>:9081/stbaseapi/baseComps.js"></script>
<script type="text/javascript" src="http://<YourServer>:9081/stwebclient/livename.js"></script>

but don't go looking for them in your filesystem because you won't find them. The HTTP requests are intercepted by a servlet that maps the filename in the URL to a physical filename in the stproxyweb.war. For example in the above case the request for livename.js is redirected to the physical file /dojo_1.2.3/sametime/LiveNameAll.js. This little bit of knowledge is very useful when debugging because many of the javascript files are also uncompressed, and loading that version makes life much easier.

So, we can replace our above example with this:

<script type="text/javascript" src="http://<YourServer>:9081/stwebclient/dojo_1.2.3/dojo/dojo.js"></script>
<script type="text/javascript" src="http://<YourServer>:9081/stbaseapi/baseComps.js"></script>
<script type="text/javascript" src="http://<YourServer>:9081/stwebclient/dojo_1.2.3/sametime/LiveNameAll.js.uncompressed.js"></script>

And now we can read the original code in firebug, enabling us to insert appropriate breakpoints.

Servlet mapping list

widgetsPart1.js >> stproxyWidgetsAllFirst.js
widgetsPart2.js >> stproxyWidgetsAllSecond.js
chatPart1.js >> stproxyChatAllFirst.js
chatPart2.js >> stproxyChatAllSecond.js
adderLoader.js >> stproxyAdder.js
meetingLoader.js >> stproxyMeeting.js
announcementLoader.js >> stproxyAnnouncement.js
widgets.js >> stproxyWidgetsAll.js
widgetsLight.js >> stproxyWidgetsAllNoDojo.js
livename.js >> LiveNameAll.js
livenameLight.js >>LiveNameAllNoDojo.js

Command Recall on AIX

One of the most frustrating things about working with unix is the lack of a user interface, everything is command line. Try explaining stuff like awk, grep, vi and ls to new users and the complaints start to roll in. What tops the list has to be the lack of command recall using the arrow keys. We've all been conditioned that pressing up-arrow will bring back the previous command so we can make edits instead of typing the whole thing over again.

No more. Below is a short series of commands that can be added to a .profile that will enable the arrow keys to behave in unix like they do in DOS:

set -o emacs
alias __A='^P'
alias __B='^N'
alias __C='^F'
alias __D='^B' 

Note that ^P refers to the keysequence control-p while editing the file using vi, so actually typing in the characters probably won't work.

Debugging Dojo with Firebug

I've spent the last few weeks trying to integrate sametime dojo widgets into a portal theme and I used firebug extensively to debug my code. Dojo is difficult to debug because of the way it injects code using the requires function, everything shows up as an eval.

Firebug Extensions

I didn't know this, but there are quite a few firebug extensions out there, though none really for dojo. IBM has developed a dojo extension for use in their rational developer products, but since I use eclipse I was out of luck. Thankfully IBM has a history of participating in the open source community and appears to have contributed their code to the firebug community.

The code can be found at http://code.google.com/p/fbug/source/browse/#svn%2Fextensions%2Fdojofirebugextension

I downloaded from their SVN server and executed the build.xml, drag/dropped the resulting dojofirebugextension-1.0a6.xpi into firefox and now I have a nice dojo interface for firebug.

Thanks to Patricio Reyna Almandos and Fernando Gomez (IBM Argentina) for putting this together.

Vague Error Message with Sametime Proxy

More insight related to my work with the integration of sametime into a portal theme. If anyone runs into this error:

SystemOut.log:[3/7/11 12:41:01:852 EST] 00000022 STLoginServle W com.ibm.rtc.stproxy.servlet.STLoginServlet loginbyToken  CLFRX0055E: unable to retrieve login credentials

the message is a little misleading. Yes, it cannot retrieve the login credentials, but why exactly? The proxy will produce this error if it cannot find at least one of the following in the request:

• password
• LtpaToken
• LtpaToken2
• SametimeToken

 In my case I was using SSO through a Webseal reverse proxy and I failed to qualify my junction as an LTPA junction. Webseal wasn't sending the token causing the above error.

Race Condition with Sametime Proxy Server

I've spent the last few weeks integrating a web based sametime chat client into websphere portal and ran into a curious problem. It seemed that on occasion the buddy list would not populate, all I'd get is a dojo busy indicator, but if I refreshed the page everything would be fine.

Time to open up firebug.

I have to admit that dojo isn't the easiest javascript to debug, they've really stretched the capabilities of the language, but I finally tracked it down to a piece of code during the execution of:

ST_Client = new sametime.WebClient({}, "STClient");

At some point it tests if it should display the buddy list right away or add the task to a queue for later execution, and in this case it was adding to the queue. So who is supposed to deal with the queue, and why wasn't it being done? Turns out that there's some code executed in the login

stproxy.login.loginByPassword()

that iterates through the queue and displays the buddy list. I was running into a race condition because I was trying to log in to the samtime server before showing the buddy list, but in some cases the login was finishing before the call to create the WebClient was done.

The Fix?

Ensure that the code creates the WebClient before it tries to login. Go figure.

Running WPF Designer with Java 6

Today I encountered a perplexing error in the portlet factory designer:

(com/ibm/workplace/wcm/api/Workspace) bad major version at offset=6
Cannot instantiate Class Name: com.dsixe.wcm.Content - java.lang.UnsupportedClassVersionError: (com/ibm/workplace/wcm/api/Workspace) bad major version at offset=6

Now I've seen this type of error before, all it requires is a tweak to the project properties, change the runtime to the appropriate version - in this case it seemed to be 6. But the error would not go away.

The source of the problem was a linked java object builder pointing to a class which contained a reference to a class requiring java 6. When a classname is defined in the builder, I assume it must attempt to introspect the class to determine its methods, and I guess it was unable to instantiate it. So the problem seemed to be that the designer (eclipse) needed to execute in java 6 environment.

Switching to JRE 6

Eclipse start parameters can be defined in a configuration file named C:\IBM\Portlet Factory\Eclipse\eclipse.ini. One of those parameters tells it which JDK to use, so I added the following to the top of the file

-vm
C:\Program Files (x86)\Java\jre6\bin

Then I restarted eclipse. Problem gone.

EDIT 02/05/2013:

Using IBM's J9 JRE
Developers using the publish to websphere portal feature in the WEF designer will need to run the J9 version of java. This can be downloaded from http://www.ibm.com/developerworks/java/jdk/eclipse/ , ensure that you pick the 32 bit version and unzip (I put it in C:\IBM where WEF is installed). For some reason the install of WEF on windows uses 32 bit version of eclipse. Edit the eclipse.ini to use this:

-vm
C:\IBM\IBM_DevelopmentPackage_for_Eclipse_Win_X86_32_4.0.0\eclipseDevelopmentPackage\ibm_sdk70\jre\bin\javaw.exe

JNDI Datasource Names in WPF Designer

A common problem when working with data sources configured in the application server and the sql call builder is tying the two together. The builder provides a dropdown list of JNDI names that it thinks are
defined, but sometimes the name that you're looking for isn't there.


Ensure that your project is deployed

A typical scenario is starting a new project which contains a service provider model that retrieves data from a data source. You figure you've done this before so you know what you're doing, but somehow the JNDI name just isn't there.

Here's the problem - the designer needs to communicate with the server to retrieve the list of JNDI names, and it does this by issuing an http call to a model on the server from within the eclipse tool. So if the project hasn't been deployed or the server is not running, then the names cannot be retrieved.


Digging deeper

So you're sure that the project has been deployed and the server is running because you successfully executed another model in your project, but still no JNDI name. Here's where we can open up the hood and take a look at what's really going on. Navigate to \WebContent\WEB-INF\models\factory\core\db_utils.model, don't look for it in the \model folder because it's been hidden from view by the designer. Open the model and find a method builder called getDataSourceNames:

The coordinator for the sql call builder attempts to invoke this model at design time to retrieve the JNDI names, so any debugging is easily pinpointed here. It appears that the developers of WPF were kind enough to add some debugging logic in their code, try changing the debug value to true and watch for output in the server's system out log.