Troubleshooting my Lotus Notes 8.5.2, Expeditor 6.2, and Eclipse 3.4 setup

SCHEDULED: 2010-07-21 Wed 08:00

To paraphrase Edison: I wasn’t failing, I was just figuring out a thousand ways that didn’t work. =)

—-

Summary of troubleshooting lessons learned for Lotus Notes 8.5.2, Expeditor 6.2, and Eclipse 3.4:

org.eclipse.equinox.common problems when installing Expeditor Make sure you have the version of Eclipse that matches your Expeditor’s system requirements (not a newer version, not an older version). For Expeditor 6.2, you’ll need Eclipse 3.4.

Problem occurred reading your Target. Ensure that your Target Platform’s Location is configured correctly. Set it to c:\notes\framework\rcp\eclipse, or wherever your rcp\eclipse directory is. If you still get the error, tinker around a little or wait a while. I don’t remember what I did to solve this.

Bundle com.ibm.jxesupport not found. Ignore that. You’re supposed to be able to correct that issue by right-clicking on the project, selecting Properties > Client Services, and clicking OK, but no luck. It doesn’t stop the system from moving forward, though.

com.ibm.rcp.platform.personality error or java.lang.SecurityException: Unable to locate a login configuration: *Enable all the features and be patient.

—-

I’ve been working on getting a Lotus Notes + Eclipse development environment so that I can make a Lotus Notes plugin for my community tools. There’s a lot of interest in the community metrics tool, for starters.

The challenge with setting up development environments is getting all the versions to line up with the tutorials on the Net. I came across a page that described how to set up Lotus Notes 8.5.1 with the Eclipse Plugin Development Environment (PDE). I was on a newer version of Eclipse, so I needed to figure out a couple of the steps, and I eventually ran into a security exception with login configurations.

Along the way, I came across Lotus Expeditor and decided I wanted to try that. I saw an old article that said Expeditor only works with Eclipse 3.2.2 and not the newer versions, so I installed that, but it had problems trying to find com.ibm.equinox.common. Then I found out that I had a newer version of Expeditor which requires Eclipse 4.0. When I installed that, Expeditor installed fine.

Lesson learned: Look up the version of the toolkit you’re using. Look up the specific software requirements for that version. Match it instead of using newer versions.

Hmm. New error: Problem occurred reading your Target. Ensure that your Target Platform’s Location is configured correctly. I have it set to c:\notes\framework\rcp\eclipse. It won’t accept c:\notes\framework\eclipse . Hmm. It works now. I don’t know what I did, though.

I’m running into the com.ibm.rcp.platform.personality error again. Let’s try reloading those. They show up in the plugin list for the run configuration, though. Ah. Selecting another plugin that depends on that plugin might’ve done the trick.

There’s a note about Bundle com.ibm.jxesupport not found. com.ibm.jxesupport was removed in Lotus Expeditor 6.2.0. You’re supposed to be able to correct that issue by right-clicking on the project, selecting Properties > Client Services, and clicking OK, but no luck. It doesn’t stop the system from moving forward, though.

… and we’re back at the java.lang.SecurityException: Unable to locate a login configuration which I encountered this morning.

Okay. What do I know about this error?

  • Maybe I’ve configured the wrong JVM.
  • Maybe the JVM can’t find lib/security/java.security .
  • Maybe there isn’t one by default in Notes, so I have to create it.
  • Maybe the classes aren’t in the classpath.

Aha! Found someone with the same error message, but in a different language. The person reported that checking all the boxes in the plugin tab helped. Let’s try running it with all the features enabled (oh my). Lots of warnings, but still going… And there’s the Lotus Notes login dialog, and the sample QuickNote plugin. I think we have it!

Useful links:

Setting up your Drupal development environment

People found the 7-minute impromptu braindump I gave at last night’s Drupal Toronto meetup useful enough to vote it the best talk, so I thought I’d write it up. =)

Development

  • Use source code control. No, seriously. Use it. Religiously. It’s going to save you someday. CVS is popular. Subversion is also easy to set up. It’s a must when you’re working with other people, but even if you’re on your own, it’s really handy to be able to go back to previous versions or to check your changes.
  • Get to know your integrated development environment (IDE). For example, I use Eclipse + PHP Development Toolkit (PDT) + Xdebug, and the keyboard shortcuts save me so much time and make it easier for me to think about my code instead of thinking about editing my code. F3 to jump to a function definition, Ctrl-Shift-R to open a file by typing part of the filename, Ctrl-space to complete text… I’ve also gotten XDebug integration to work, so I can step through code and examine variables without putting var_dump everywhere. Know your tools.
  • Add the XDebug extension to your PHP installation. Even if you don’t get XDebug integrated with Eclipse, you’ll like the new and improved var_dump and other debugging functions. I’ve heard good things about Zend Debugger, too.
  • Put your entire Drupal directory into your project in the IDE, not just your site-specific code. You can even check your entire Drupal directory into your source code control repository. This makes it easier to look up functions in Drupal core, not just your sites/all/modules directory. You _could_ version-control just your site-specific code (profiles/, sites/, etc.), but set-up becomes a little more complicated.
  • Use an installation profile to manage your configuration. Experiment with things using the administration interface, then create/update an installation profile that sets up a brand-new Drupal installation. This will save you lots of time and head-scratching when you need to reproduce your setup.
  • Make starting from scratch easier, and do it often. I have a Makefile that drops my database and recreates it, resets my settings.php, and even opens up a Firefox browser that uses my installation profile to set everything up from scratch. Drupal 5: Copy your settings.php to settings-default.php or something like that before you install your system, then copy settings-default.php over settings.php when you want to refresh your setup. Drupal 6: Delete settings.php when you want to refresh your setup.

Firefox

  • Use multiple profiles. You can start completely independent Firefox processes by using profiles. For example, you could have your default profile with all the bells and whistles, and a test profile with just FireBug. You can log in as different users, too. Use this command to start a new Firefox process: firefox -ProfileManager -no-remote
  • Install and use FireBug. Best web development extension ever. I use this to examine the document object model, debug my CSS rules, experiment with my CSS and HTML on the fly, and monitor the network requests.
  • Set up quick searches for drupal.org and php.net. You can define quick searches by creating bookmarks that use keywords and %s placeholders in Location:. Example: Do a quick Google-search of Drupal.org by adding a bookmark with Location: http://google.com/search?q=inurl:drupal.org+%s and Keyword: gd (short for Google Drupal). To use your new quick search, type Ctrl-L or Alt-D to get to the address bar, then type gd keywords. Set up ways to search php.net and drupal.org/project, too. =)

Multi-site / virtual hosts

  • Simplify switching between your computer and your remote server. If you’ve set up your local system for virtual hosts and you have a remote server for testing, you’ll want to be able to switch between testing locally and testing remotely. Set up your local system to respond to all the domain names for the site (ex: example.com, foo.example.com, bar.example.com) and a local subdomain (ex: local.example.com). Set up your remote server to respond to all the domain names for the site (example.com, foo.example.com, bar.example.com) and a remote subdomain (ex: test.example.com). Then set up your /etc/hosts (c:\windows\system32\drivers\etc\hosts on Microsoft Windows) to look like this:

    127.0.0.1 localhost local.example.com
    remote.server.ip.address test.example.com
    
    127.0.0.1 example.com foo.example.com bar.example.com
    #remote.server.ip.address example.com foo.example.com bar.example.com
    

    local.example.com will always resolve to your computer, test.example.com will always resolve to the other computer, and everything else depends on which line is active. # comments out a line. When you want to switch to testing on the remote server, add # to the beginning of the line for 127.0.0.1 example.com… and remove # from the line for your remote server. If you want to automate this even further, write a script that swaps different /etc/hosts files around.

Hope that helps! I’d love to find out what you’ve done to tweak your environment. Feel free to share your tips here!