Tag: sametime

Writing log messages in Sametime 7.5 plugins

Unfortunately the Sametime 7.5 SDK doesn’t contain any information that I can find on how to use log and debug messages in custom plugins. Furthermore all the Sametime 7.5 articles on developerWorks I have seen use System.out which is really a no, no. This post contain some information on logging that I have found out myself – partly through looking around in the Sametime 7.5 Connect client installation and partly by trial-and-error.

FYI: I’m doing a fair bit of Sametime 7.5 plugin development at the moment. For one because it’s fun and second because I’m writing an article for THE VIEW (slated for the March/April issue) on Sametime 7.5 development.

Introduction

Logging is at the heart of any development project whether that be a Notes database or a Java application. You can of cause resort to using System.out / System.err for logging but that’s clearly a no, no! If you are in doubt why I suggest you start here. Once you come to the conclusion that you really should be using a logging framework there basically is two options:

  • java.util.logging (available directly in the JDK since JDK 1.4)
  • Apache log4j

Many libraries will furthermore use Jakarta Commons Logging to isolate themselves from the underlying logging technology. In part because they cannot tell which logging framework will be used by clients and because it affords the client the choice.

However in the case of the Sametime 7.5 Connect client the choice has been made for you since Sametime 7.5 uses java.util.logging. You can choose to use Commons Logging but then the logging levels will not fit the ones used in Sametime.

I would suggest you stay with java.util.logging.

Please note: The way logging works while developing plugins in Eclipse is very much different from how it works in the *real* client. When developing all logging, incl. System.out, goes to the console.

Using java.util.logging

Obtaining a java.util.logging.Logger instance is easy:

Logger log = Logger.getLogger(this.getClass().getName());

I suggest you follow the above example and use the class name as the logger name which is also a best practice and the way that IBM does it.

Once you have the Logger-instance you can use it to log information using the different logging Levels (see the Javadoc for more information on java.util.logging).

Configuring logging in Sametime 7.5

The logs written are placed in the Sametime-directory under your using profile hereafter called the log-directory. On my Windows laptop this is “C:Documents and Settingslekkim.HQApplication DataSametime”. The logging itself is configured from the sametime.properties file in the Sametime 7.5 Connect client directory (again on my Windows laptop this is “C:Program FilesIBMSametime 7.5”).

The top of my default sametime.properties looks like this:

## G11N DNT
## Logging properties
.level=INFO
logger.filename=sametime.log
logger.includeClassInfo=true
logger.toConsole=true
logger.level=ALL
logger.limit=20000000
logger.count=7
org.apache.axis.level=INFO
redirectSystemOutput=true

## app properties
...
...

By default log-messages goes to sametime.log.0 in the log-directory with the maximum level of INFO (top bold line). To diagnose issues increase the log level to FINE, FINER, ALL etc. Be aware that the finer levels will produce *lots* of output. Note that messages written to System.out is directed to System.err by default (the second line in bold). To get this information change the redirectSystemOutput to false.

Doing this will cause output to be written to sametime.log in the log-directory instead. Restarting the Sametime 7.5 client while redirectSystemOutput is false will rotate the previous sametime.log to sametime.log.previous.

The nitty-gritty details

It appears that most of the java.util.logging configuration is done through the rcpinstall.properties file in /plugins/com.ibm.rcp.base_6.1.0.0-20060714/config/muservice. Although I wouldn’t suggest changing the file itself it may be beneficially to peruse the file to see how it’s done.

If you really want to know that is… 😉

Conclusion

It appears that Sametime uses java.util.logging and that is is quite straight forward to use – once you know how… Logging levels are easily controlled from sametime.properties and extending the logging framework to do central logging should be easily accomplished.

Happy logging…

Sametime 7.5 client language when doing plugin development


If you are doing any Sametime 7.5 plugin development you might have noticed that the client always starts up in your local language – Danish in my case. If your native language isn’t English and you’re developing international plugins you might want to run the Sametime client in English instead which you can do by adding a command line parameter in your launch configuration.

To do this open your launch configuration, go to the Arguments-tab and add “-nl <locale>” (without the quotes) in the “Program arguments” field. The specified locale can be any valid Java Locale such as US, DK or DE.

Re:Removing the slash screen from Sametime 7.5

As mentioned in my SnTT post on 5 October 2006 (post) you can remove the splash screen from Sametime 7.5 by hacking the config.ini file in the configuration-directory. A by far easier way is simply to add -noSplash as a command line argument to sametime.exe in your Windows shortcut or to the sametime executable on Linux.

A little easier… 😉

Central repository of known locations for Sametime 7.5

If you have Sametime 7.5 installed and use the location awareness you’ll have a file called locprofile-config.xml holding the locations you have configured so far (mine is in C:Documents and Settingslekkim.HQApplication DataSametime.metadata.pluginscom.ibm.collaboration.realtime.location).

The locations are identified by the network you are connected to and is identified by the current IP-subnet and the MAC address of the default gateway.

<?xml version="1.0" encoding="UTF-8"?>
<locprofconfig>
   <locprofiles>
      <locprofile profilename="192.168.1.0 00:09:7C:2B:74:88       ">
         <locations>
            <locip>192.168.1.0</locip>
            <macaddr>00:09:7C:2B:74:88</macaddr>
         </locations>
         <personalloc>it-inspiration hq</personalloc>
         <city>københavn k</city>
         <country>DK</country>
         <postalcode>1058</postalcode>
         <primphone>70223141</primphone>
         <shareloc>true</shareloc>
         <timezone>Central European Time (GMT +1)</timezone>
      </locprofile>
      <locprofile>
         ...
      </locprofile>
      <locprofile>
         ...
      </locprofile>
   </locprofiles>
</locprofconfig>

At present the file is person dependent but since it is part of a plugin but I think it would be really cool if parts of the file could be populated from a central repository via an extension point. This way the Sametime Connect client would automatically display the correct location of the user throughout the company without each user having to update the file themselves. It would also mean that the information could be entered and displayed in a consistent manner.

Of cause the user would still have to specify the location details for custom locations such as hotels, home work stations etc. but I think it would make life easier for the majority of users.

Just an idea…

Sametime 7.5 business voes – why doesn’t the picture update?

At the office we are using the business card feature of Sametime 7.5 and up to now it has been working fine since we got past our initial problems with the UserInfoServlet (which made me reverse engineer it). A problem is now appearing though. The problem is that once users update their business card picture in the Domino Directory (we simply populated the field with a “standard” image to begin with) the picture doesn’t update in the Sametime Connect clients. Right-clicking the user in Sametime Connect and selected “Refresh Person Info” doesn’t help either.

Poking around the Sametime folders I found where the cache is kept (“C:Documents and Settingslekkim.HQApplication DataSametime.metadata.pluginscom.ibm.collaboration.realtime.peoplePersonCache” on my computer). In this directory there is a folder per community you have configured in your client. In the folder for our internal community there is a XML-file and an image file per user – the XML file holds the information fetched from the UserInfoServlet-servlet and the image is the business card image.

I thought it was so simple that I could simply modify that last updated timestamp in the XML-file, delete the image file or delete both the XML-file and image file to make Sametime refresh the information. Not so however… 🙁 Exiting the client, manually updating the image and/or modifying the XML-file makes the new information appear when starting the client again.

Looks like the client is caching the information which is all well and good but shouldn’t it update at some point?

I guess that the caching/refreshing is governed by some other setting – maybe in the buddylist. Unfortunately I can’t find any information about this subject. All information is related to initially configuring the stuff.

Show ‘n Tell Thursday: Removing the slash screen from Sametime 7.5 (5 October 2006)


Since Sametime 7.5 is built upon the Eclipse Rich Client Platform (RCP) you can hack it as such. In Eclipse RCP programs the slash screen is a configurable component which led me to believe it could be removed. And I was right. The below guidelines are for Windows but should be applicable to other platforms as well.

To not display the slash screen at startup do as follows:

  • Open your Windows Explorer and navigate to your Sametime 7.5 installation directory (C:Program FilesIBMSametime 7.5)
  • Open the “configuration” directory
  • Open the config.ini file in your favorite editor
  • Remove the second line of the file (the one starting with “osgi.splashPath”) or comment it out by inserting a #-character at the start of the line
  • Save and close the file

When restarting Sametime the slash screen should be gone.

Happy days! Please note that this approach probably isn’t supported but hey – shouldn’t it be a configurable option in the first place? 😉

Re: What’s up with Sametime 7.5 spellchecking?

I was made aware by a coworker that the UI language and the spellchecking language doesn’t go together as started previously. The only available spellchecking language in Sametime 7.5 is English. The dictionary for the spellchecking is located together with the IBM “langware”-plugin (see the “pluginscom.ibm.langware.v5.dic.en_US_5.3.1.9-20060714” directory) in the Sametime 7.5 install directory.

I wasn’t able to find any additional dictionaries but found a post in the Sametime forum on LDD requesting the same thing. I do not however think I would be well of by finding additional dictionaries since there is no way to specify the spellchecking language in the Sametime client UI.

What’s up with Sametime 7.5 spellchecking?

We have been running the new Sametime 7.5 at the office since its release and I must say that I’m impressed. The UI is slick and the new features have made it an up2date IM client. The small issues we had getting the server installed was, I guess, minor and could be expected. I have blogged about a couple of the issues previously.

I have an issue with the real-time spellchecking though. The feature is nice but apparently the spellcheck language follows the UI language which means that I cannot run the UI in English and have the spellcheck in Danish which is my native language. Separate options for UI language and spellcheck language would be nice. If IBM decides to do this I also think that they should consider letting the user set the spellcheck language from the button bar of the IM window for easy on-the-fly switching.