Month: January 2009

LotusScript.doc v2 – an update on the progress

Besides working way too much I have spent a good part of my Holidays working on LotusScript.doc version 2 and I’m happy to say that it is very close to completion. I have spent a great deal of time finalizing the logging framework and building the Notes/Java bridge to allow you to run LotusScript.doc from a Notes database instead of as a command line program. I also needed to weed out some issues in this regard which is why I have been blogging issues such as configuring the java.policy file and the maximum Java heap size.

To clarify…

LotusScript.doc v2 is out in a very, very limited prebeta 1 with one person besides me to try and weed out the most serious issues before releasing a beta. Again a beta, at least the first, will only go out to a select number of people to try and keep track of who has what release.

The goals for the functionality of LotusScript.doc v2 are very big but for starters I’m going for feature parity with LotusScript v1. Then once the new technology is out there I’m going to start enabling the new and advanced features.

Thank you for your patience.

LotusScript.doc v2 – required Java heap changes

Strong: Just to clarify – LotusScript.doc v2 isn’t out yet. It is out in a very, very limited prebeta 1 (one person besides me) in preparation for a more general beta process hopefully in the very near future. See this post for a clarification on the progress.

As you might know LotusScript.doc v2 is written in Java instead of LotusScript. This means that you have to make some minor changes to your Notes client to make it work. One of the settings you need to change is the size of the Java heap that is the amount of memory allocated to Java objects.

To change that you need to set the JavaMaxHeapSize notes.ini parameter as described in the Lotus Notes and Domino wiki. Although the wiki describes the setting as only being applicable to Domino servers it works just as fine for my test Notes client (8.0.2 Standard in this case). To change the setting add the following to your notes.ini (do check whether it is already set):

JavaMaxHeapSize=384MB

LotusScript.doc v2 – java.policy changes required

Strong: Just to clarify – LotusScript.doc v2 isn’t out yet. It is out in a very, very limited prebeta 1 (one person besides me) in preparation for a more general beta process hopefully in the very near future. See this post for a clarification on the progress.

LotusScript.doc v2 uses java.util.logging as its underlying logging framework. To spice things up a little it also uses some internal magic to ease troubleshooting and provide easy debugging. One of these tricks is to print out the XPath expression of the element being processed in the log. More on this another time.

In order to use java.util.logging and set custom Handlers and Formatters you need to tweek the java.policy a little bit. It’s quite easy as the only thing you have to add to your <Notes binary directory</jvm/lib/security/java.policy file is the following in the first “grant” section:

permission java.util.logging.LoggingPermission "control";

Here is a link to a default java.policy file and a changed java.policy file.

I’m trying to create script libraries using DXL – possible?

I have spent a little time this weekend trying to create Java script libraries (that is script libraries with Java code and not “JavaScript” libraries) from scratch using DXL. Exporting the DXL of a script library with a jar-file imported into it yields some base64 in a <javaarchive /> tag. The base64 data is however not decodable as it’s not valid base64. Base on prior experiences with this kind of stuff I tried decoding the bytes but without success.

The header in base64 is (or at leas to a multiple of 4 characters) is “UEsDBBQACAAIAKyEATkAAAAAAAAAAAAAAAAUAAAA”. I guess the beginning is probably a CDFILEHEADER struct (based on prior help) but I’m unable to decode it… 🙁

The struct should start with a DSIG struct (16 bit unsigned integer and a 32 bit unsigned integer) but I’m unable to get anything that makes sense. I end up with 20555 for the first WORD but that doesn’t “compute”. Bummer!

If you’ve done any work on this and is willing to share please drop me a comment. Thanks.

JarPlug Eclipse plug-in

The extensible nature of Eclipse is simply amazing. I needed a way to look inside a jar-file which is isn’t on the build path in Eclipse which isn’t “natively” possible with Eclipse. What did I do? I did a quick Google search and 5 minutes later I had JarPlug installed and working. Then after opening this viewpart when selecting any jar-file in the workspace the contents is shown. How nice is that! 🙂