Messages posted by: jbuddysupport

During a recent connection attempt to sametime.lotus.com, the Sametime 80000200 error appeared with the message "incorrect version number". What was odd is that the connection attempt was leveraging the IBM provided STComm.jar (the underlying SDK used by JBuddy for Sametime connectivity). This had worked in the past and was now failing.

The solution was to update the STComm.jar library to the latest version available (ST 8.5.2) and reattempt. With the new STComm.jar in place, the connection was successful.

Based on this, we have updated all of the JBuddy products that support connectivity to Sametime to use the latest STComm.jar. If you are still running an older version of Sametime, you may need to experiment to see which STComm.jar your environment will permit. The newer STComm.jar should be backwards compatible however.

In order to submit a bug report for JBuddy Messenger follow the instructions below.

Windows:
Open a Command window, cd into the lib folder under JBuddy Messenger

Linux:
Open a shell window, then cd into the lib folder under JBuddy Messenger

Mac OS X:
Open Terminal App, then cd into the lib folder under JBuddy Messenger

Next, launch JBuddy Messenger with this command:
java -Djbuddy.logLevel=1024 -Djbuddy.logFile=debug.log -jar JBuddyMessenger.jar

That will create a file called debug.log and hopefully will capture an Error or Exception that is causing JBuddy Messenger to misbehave or crash.

Email messenger-support at zion dot com and include in your email, a description of the environment (including OS version & bits, Java version and bits), version of JBuddy Messenger, and what action triggers the bug / crash, and attach the debug.log file with the misbehavior or crash.

This was finally fixed in v3.2.111216

This forum post explains the various techniques that can be used to identify the JBuddy SDK version and build number you may be using. This may be simplified in a future version.

1. If you have the installer jar used to install the JBuddy Developer Tools, the filename is based on the version and build:
JBuddyDeveloperTools-6.3.120209.jar -- version 6.3 build #120209. In most cases, the build number also represents when this installer jar was created: Typically YYMMDD (the year, month, and day). If for some reason the installer file name does not identify the version.build, then launch the installer (double click the jar or launch with java -jar installer.jar and notice say "Welcome to the installation of JBuddy Developer Tools X.Y.YYMMDD" - this is the version.build

2. If you do not have the installer, but just the JBuddy folder created by the installer, try these methods:

If you installed the JBuddy SDK Docs, check the docs/ReleaseNotes.html. The top of the release file should contain the version and build number similar to:
Release 6.3
Build 100815 August 15, 2010
<p>
If you don't have the installer and did not install the docs, it will take a little more work to dig up the version and build number. Follow these steps. Cd to JBuddySDK\demos\java\CmdLineClientDemo and edit the src\CmdLineClientDemo.java and add the else if block of code below before the last else block at the bottom of the run() method, then save the modification and recompile. A similar technique can be used for JBuddy for COM and .NET.

Code:

                 else if(cmd.equals("info")) {
                     IClientFactory.showLicenseInfo();
                 }

Then launch CmdLineClientDemo in a command window or linux shell and type 'info' after you receive the CmdLineClientDemo prompt. An example is shown below:
Code:

 Enter cmd >info
  build 6.3.100815
 
 Serial Number:AA0001
 License Owner: -
 License Type: Demo
 Host ID: AA0000
 Module Name                        Mode  Exp Date
 ---------------------------------  ----  ----------

This example shows the free/demo license and the version number for this JBuddy SDK.

Note:
JBuddy SDK version 6.3.120123 altered this behavior and needs a slight change to get at the version and build number. If the lib\JBuddy.properties has the following property set:
jbuddy.gui.use_registration=false (default), change this value to:
jbuddy.gui.use_registration=true

Then using the same source code change mentioned above to CmdLineClientDemo.java, re-launch CmdLineClientDemo and type info. This time, a graphical License Dialog will popup and in the License window title, the build (version.build) will be displayed. This method only works on computers with a graphical display (i.e.: not on a headless linux computer).

Again, this may be changed in a future version of JBuddy to simplify the process to identify the version and build number.

IM rich formatting has always been a challenge especially if you wanted to build a multi-protocol bot or solution. AIM uses something like HTML, Yahoo uses RTF and ANSI Control Codes, and possibly some HTML (I forget), and MSN uses MIME with some mix of other markup. Anyway, you get the point. Enter RichContent. You build your message with RichContent and when you send it, the protocol-specific decoder will emit the correct rich content for that protocol.

As for fixed width, I believe that depends on the font set which RichContent supports. Bear in mind that some IM clients allow the user to override the font and size within their IM client. Lastly, please note that RichContent does not support anything that the protocols don't support. In other words, if a protocol does not support mixed fonts, or mixing bold + plain, etc, then you will only be able to create a rich content as allowed. MSN comes to mind.

In order to work as designed, JBuddy needs a license key or license file. Thile topic discusses the process JBuddy uses to locate a valid license file. The file is typically named jbuddy.lic and is usually found within the lib folder of the JBuddy SDK. Although the file is plain text, it contains a checksum signature to prevent tampering.

JBuddy will search for the jbuddy.lic license file as follows. It expects jbuddy.home to be set and it can be set within JBuddy.properties (the locating of JBuddy.properties is described below).

${jbuddy.home}/jbuddy.lic ?

${jbuddy.home}/lib/jbuddy.lic ?

last check attempt:
Code:

ClassLoader cl = Thread.currentThread().getContextClassLoader();
 is = cl.getResourceAsStream("jbuddy.lic");

Here is the description of the process to locate the JBuddy properties files:

If jbuddy.home System property is defined, search "jbuddy.home"/lib/filename

If jbuddy.home is not defined (early enough in the process), it will search the java.class.path system property for "JBuddy.jar" and then search the directory where JBuddy.jar is found for the filename.

if not found, search "user.home"/.zionsoftware/JBuddy/fileName

if not found, search in the same directory as this class is found for fileName
[list]last attempt, search using this.class.getResourceAsStream(/ + fileName)
[/list]
NOTE: JBuddy uses this same process to locate protocol specific properties files...

what is the code that you used to create these formatted messages? Are you using the com.zion.jbuddy.richcontent.RichContent API? If not, please try with that. If you are, please show the code here that is failing on AIM.

JBuddy Messenger supports working on computers supporting multiple monitors. There is scenario where you can find the JBuddy Messenger buddylist window missing. This occasionally happens when the computer is operated without the second monitor or attached to a smaller monitor (such as might be common with a laptop working at home and work).

Upon launching JBuddy Messenger no buddylist is visible. To correct this problem, find the application icon in the application dock / taskbar, right click the icon and select Maximize. You should now see the buddylist. At this point quit the application. Now, restart the application and you should be able to resize the buddylist from a maximum size to something reasonable.

UsersGuide.pdf states in 10.1 that all features available in a bot definition XML are available dynamically, including target and menu references. Looking at the bot framework source code it looks like the xml document returned is first validated as an xml document using the schema. Then parsed according to the element name.

Here is a list from the dynamic parsing routine:

action

content

file

menu

message

target

setStatus

setPermitMode

addBuddy

removeBuddy

addDeny

removeDeny

addPermit

removePermit

looks like we may need to offer an option for running completely in the background. Currently the code is expecting a Stdin and running with nohup is killing stdin. Here is an example of redirecting stdout, stdin, and stderr...

Code:

nohup ./myapp.sh > nohup.out 2> nohup.err < nohup.in

unfortunately, the bot framework will process the nohup.in until it reaches the end of the file, then will terminate gracefully...so we need to offer a flag to just process completely in the background without and stdin.

TrivialAppSend is a java demo in the JBuddySDK/demos/java/ folder. If that doesn't work, please leave a PM and we'll try to help.

-you need a delay after signon before attempting to send an IM and a delay after sending before disconnected or your message will never get delivered.

I took liberty to edit your code above to reflect this requirement.

Also take a look at TrivialAppSend example

Also, you should try removing @yahoo.com from the username.

Facebook chat is based on xmpp. With such a vast network, it seems a great opportunity for IM bots. One idea i had was Customer Service for companies with Facebook presence. What are you thoughts/ideas?

Sorry for delay in reply. Holidays, busy, etc. Let's see if we can figure out why JBuddy is choosing your host: _kerberos._tcp.dc._msdcs.gblxint.com

Can you provide any details on the DNS SRV records for gblxint.com and up the subnet chain? Also, could you please provide the options used on the CmdLineClientDemo (you can use *** for username and password). Feel free to use a private message if you wish.