Well if you do, do you then use the new feature of Notes 8.0.2 / Notes 8.5 to show an alternate timezone in your calendar? I do and I find it very nice that it’s easier to see across the timezones.
To set it up open the preferences, navigate to “Calendar and To Do/Regional Settings” and specify the alternate timezone in the middle box (cleverly named Timezone). The change doesn’t require a restart of the Notes client. Below is my setup.
I blogged about the JavaCompilerTarget back in August last year when Notes 8 came out as you needed it to enable Java 5 in Domino Designer. Last week some nice new info on this notes.ini setting came my way in the Design Partner forum for Domino NEXT. If you’re doing Java development in Notes you would want to read on.
And yes – I did check with IBM whether it was okay to blog it. Since this info is on its way out in technote (technote 1320401) it was fine that I blogged it.
In Notes/Domino 8.5, you can set the JavaCompilerTarget INI variable to any value from 1.1 through 1.6. Here is a draft of the documentation (Note: In the following text, we refer to JDK 1.6, which is also known as JDK 1.6.0 and JDK 6.0.)
By default, Notes/Domino 8.5 utilizes JDK 1.6 to compile and run agents, but it limits language features to maintain backwards compatibility through JDK 1.2, to allow agents to run on earlier Notes/Domino installations (and, more generally, with any JVM version earlier than the target flag), regardless of whether the new language features are actually used in the agent’s code (e.g., setting JavaCompilerTarget=1.6 could introduce the possibility of having an agent recompiled and replicated to a V8.0 server, and then failing to run). Additionally, problems could arise editing and saving agents compiled in Notes/Domino installations that are not using the same INI setting.
Developers must override the default behavior if they wish to use features specific to different JDKs. The default behavior is equivalent to the setting
JavaCompilerTarget=1.2
In Notes/Domino V8.5, the developer may specify any JavaCompilerTarget from 1.1 to 1.6. (In each case, the -source flag is the latest source that can be specified with a particular -target flag.)
The developer may also specify
JavaCompilerTarget=CurrentJavaVersion
which means the target flag will be synced to the version in future Notes/Domino releases (e.g., if some future Notes/Domino version were to include JDK 1.9, then “JavaCompilerTarget=CurrentJavaVersion” would create “-target 1.9”).
| JavaCompilerTarget | Resulting compiler flags | Agent would run on Notes/Domino versions |
| 1.1 | -source 1.3 -target 1.1 |
V5.0 or later |
| 1.2 | -source 1.3 -target 1.2 |
V6.0 or later |
| 1.3 | -source 1.3 -target 1.3 |
V6.0 or later |
| 1.4 | -source 1.4 -target 1.4 |
V7.0 or later |
| 1.5 | -source 1.5 -target 1.5 |
V8.0 or later |
| 1.6 | -source 1.6 -target 1.6 |
V8.5 or later |
| CurrentJavaVersion | -source 1.6 -target 1.6 |
V8.5 or later |
Remember that these settings may prevent compiled agents from running on some earlier Notes/Domino installations. Therefore, it is suggested that organizations use a consistent setting across machines.
Developers who will not be using language features specific to recent JDKs are encouraged to keep the default Notes/Domino behavior to maximize backward compatibility.
As you might know the new XPages design element of Notes/Domino 8.5 is based on a Sun Java technology called Java Server Faces or JSF for short. As such many techniques from JSF development can be reused in XPage development why it might be beneficial for you to follow some of the JSF litterature as well.
As always the newsletters from Sun is a good place to start and just recently there was two articles on composite UI components in JSF. You can find part 1 and part 2 on the web.
Update (4 Dec 2008): Corrected typo from “Java Server Pages” to “Java Server Faces”.
So the new abbreviation you have to learn is SPNEGO. SPNEGO is a stadardized protocol for single-sign-on (SSO) between diverse systems. The purpose of the protocol is to provide SSO between the operating system and the services you use whether they be on the web or client applications. Basically it means that the credentials of your Windows logon is automatically used and you are logged transparently into any services that are SPNEGO aware (of cause there are provisions for mapping credentials between systems as well).
So what does this mean for you as a Lotus professional?
An easier life is what it will eventually mean. For now SPNEGO can be configured with Lotus Connections since it runs on Websphere Application Server. In fact there was an article on this just recently on developerWorks (SPNEGO TAI: Using single sign-on from Windows to WebSphere Application Server). In the near future you will start laughing as it will be the SSO protocol for Notes 8.5 and maybe even for the Domino HTTP server as well.
This will mean better ease-of-use for users and it will mean a dramatically lowered TCO for Lotus technology as all Lotus products will be able to use industry standard SSO technologies probably even without additional costly SSO software.
How do you like them apples? 🙂
Ahhh some of the fun stuff you see when running Notes 8.5 with the OSGi console showing… 🙂
<DWSystem> null [<DWSystem> 11:11:46:590] partial 0.000 - cumulative 0.000 - instantiate controller [<DWSystem> 11:11:48:545] partial 1.955 - cumulative 1.955 - instantiate action dispatcher [<DWSystem> 11:11:48:870] partial 0.325 - cumulative 2.28 - instantiate ComputeAttrs [<DWSystem> 11:11:48:880] partial 0.010 - cumulative 2.290 - instantiate AttrMap [<DWSystem> 11:11:48:910] partial 0.030 - cumulative 2.32 - instantiate distance function [<DWSystem> 11:11:49:855] partial 0.945 - cumulative 3.265 - set incremental augmentor to null [<DWSystem> 11:11:49:965] partial 0.110 - cumulative 3.375 - instantiate executor [<DWSystem> 11:11:50:906] partial 0.941 - cumulative 4.316 - instantiate displayer [<DWSystem> 11:11:50:971] partial 0.065 - cumulative 4.381 - instantiate treewalker [<DWSystem> 11:11:50:976] partial 0.0050 - cumulative 4.386 - instantiate the widget manager [<DWSystem> 11:11:51:106] partial 0.130 - cumulative 4.516 - instantiate instrumentation services [<DWSystem> 11:11:52:021] partial 0.915 - cumulative 5.431 - instantiate the abstraction module [<DWSystem> 11:11:52:351] partial 0.330 - cumulative 5.761 - instantiate the logical name translator factory class name com.ibm.pw.DocWizard.ExpeditorWidgets.ExpWidgetFactory Create ExpWidgetFactory factory class name com.ibm.pw.DocWizard.SWTWidgets.SWTWidgetFactory [<DWSystem> 11:12:01:577] partial 9.226 - cumulative 14.987 - instantiated the widget factory [<DWSystem> 11:12:02:009] partial 0.432 - cumulative 15.419 - instantiate step instantiator [<DWSystem> 11:12:02:597] partial 0.588 - cumulative 16.007 - instantiated the session trace [<DWSystem> 11:12:03:272] partial 0.675 - cumulative 16.682 - instantiated control loop - done initializing DWSystem View initialization done CLOSING SYSTEM
I haven’t done a SnTT in months (actually the last one was back on 24 May 2007) so I guess it’s about time. This week it’s about cross compiling sidebar plugins for Notes 8.5 and Notes 8.0.2. Enjoy…
Since installing Notes 8.5 I have had a lot of trouble developing in Eclipse 3.4 for Notes 8.5 and having the plugins work in Notes 8.0.x as well. The problem showed itself as a NullPointerException when trying to load the plugin Activator and a “Viewpart is null” message in the Notes UI. Looking at the log trace showed a class incompatibility message (“bad major version at offset=6”).
So far I have been screaming my lungs out, developing in Eclipse 3.4 and building the plugins in a virtual machine with Eclipse 3.2 as I couldn’t get plugins to work otherwise. Now I finally found a solution that lets me develop in Eclipse 3.4 and having the plugins work in Notes 8.0.x and Notes 8.5.
The issue is that Eclipse 3.4 configured with Notes 8.5 as a target platform is using Java 6 and that Notes 8.0.x is using Java 5 which causes class format problems. The solution is to set the required execution environment in Eclipse 3.4 which will cause Eclipse to build correctly. Setting the required execution environment (J2SE-1.5) is done in the “Overview”-tab of the MANIFEST.MF editor as shown below.
Using the GUI is of cause just a shorthand for editing the manifest manually. As an alternative you can edit your META-INF/MANIFEST.MF file directly and add the following line:
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Please note that this is not the default value when creating new plugins in Eclipse 3.4 so you’ll have to pay attention and make sure it’s set correctly. This is of cause only necessary if your plugins need to work on Notes 8.0.x as well as Notes 8.5.
Thanks to Pierre Carlson from IBM for pointers on this.
Prior to Notes 8.5 it wasn’t really an option to load many sidebar plugins as they, even when collapsed, would take up a great deal of screen real estate. From Notes 8.5 you can choose to minimize a sidebar plugin to an icon at the bottom of the sidebar panel which is really nice. You do this is in the part menu by selecting “Minimize to Icon”.
In my Notes 8.5 client I run the following 10 sidebar plugins:
The latter six I run minimized as I use them less often that the other four. Below is a screenshot of the minimized sidebar plugins.
You might say: “but what about performance when running so many sidebar plugins?” Well due to the way Eclipse is constructed no code from the the sidebar plugins will be loaded until you activate it so having many minimized plugins is without any performance penalty. All that is needed to show a minimized/collapsed sidebar plugin can be read from its plugin.xml file.
After getting my Eclipse IDE to work with Notes 8.5 I nailed why TwitNotes doesn’t work with Notes 8.5 beta yesterday. For long I was told that the main culprit was me using my own copy of org.apache.commons.httpclient but rather the version of org.apache.commons.lang that IBM supply as part of the platform was the problem.
To get TwitNotes working with Notes 8.5 I had to use both the IBM version of org.apache.commons.lang and org.apache.commons.httpclient and not my own versions. This is fine since they, among other things, provide transparent HTTP proxy support but my code wouldn’t compile using the IBM plugins. The IBM version of the org.apache.commons.lang plugin is wrongly packaged though which was the source of the problems. I actually had to repackage and replace the org.apache.commons.lang plugin supplied by IBM. When I say replace I mean actually deleting the IBM version and replacing it with my patched version.
I really hope that IBM will patch the plug-in before releasing Expeditor 6.2 and Notes 8.5.
Getting technical the problem is the Export-Package directive in the MANIFEST.MF of the org.apache.commons.lang plugin. The IBM-supplied version only export the root-package (org.apache.commons.lang) whereas they should export all the packages. This is a utility library after all.
The issue was easy to solve but unless the patched version makes it into the core platform it wont help me as I will be unable to supply a new version of a platform plugin with the same plugin version. Cross your fingers.
Oh and IBM does care – I have actually been talking to quite a lot of IBM’ers about this and only post here to Google’ize it in case others run into the same issue. Whether the patch makes it into Expeditor 6.2/Notes 8.5 still remains to be seen though…
Refreshed the design of a database modified using Domino Designer 8.5 (Eclipse version) in Notes 7.0.2 and discovered some of the new stuff now stored in the NSF. See screenshot below. Especially the WEB-INF/classes/plugin/Activator.class makes me wonder what kind of Java stuff is stored in there now…
Using the Eclipse configuration I posted earlier the plug-in with the setlogrlev OSGi console command wouldn’t launch. To solve this you can either manually to start the com.ibm.rcp.core.logger plug-in from the OSGi console or configure the config.ini file on the launch configuration. The former can be done with the below command. A description on how to do the latter has been added to the step-by-step instructions.
start com.ibm.rcp.core.logger