Quick tip: moving an Eclipse project to another folder

I am restructuring some projects on my local machine. Usually I don't want to touch a running project but since I have the opportunity to use an internal Bitbucket server now at my workplace I also want to have all my local project source files on one location.
So this is how I moved the project source files to another location on my local machine:

1. Open Eclipse and go to the Package Explorer view
   
2. Check your project folder locations
   
   So the project is located in the folder D:\sample\net.mruhnau.sample.hello
3. Right-click on the projec in the Package Explorer and choose Refactor --> Move...
   
4. In the following dialog, choose the new folder location for the project and click OK.
   

This is it, Eclipse moves the files to the specified location. The advantage is that using this procedure will retain your workingsets as well as project information, history etc. I think this is a very smooth way of reorganizing project files.

Image processing using JaxaXT in a Notes / Domino Agent

Today I stumbled across JavaXT. JavaXT is described as

a collection of Java libraries and utilities that provide a number of functions not available in the standard JDK. It is an extension of the Java core, written to simplify Java development.

I needed a library to resize images - from a good old java agent :-/  So far I used the Java Advanced Imaging API  but I had issues resizing some JPEG images. I was not able to find a correlation what caused the issues: And to be honest, my code was not very clean and neat so this was a good opportunity for improvements anyway. 
Using JavaXT I refactored my whole code to very few lines to do some resizing of images and save them in a NotesDatabase. 

This sample processes all Files in a given folder and resizes them to a fixed width of 200 pixel. 

import java.io.File;
import lotus.domino.*;

public class JavaAgent extends AgentBase {

  public void NotesMain() {

    try {
      Session session = getSession();
      AgentContext agentContext = session.getAgentContext();

      File[] files = new File("D:/tmp/pix/").listFiles();
      for (File file : files) {
        if (!file.isDirectory()) {
          String srcFileName = "D:/tmp/pix/" + file.getName();

          javaxt.io.Image image = new javaxt.io.Image(srcFileName);

          String destFileName = "D:/tmp/pix/resize/" + file.getName();
          image.setWidth(200);
          image.saveAs(destFileName);
          
        }
      }

    } catch(Exception e) {
      e.printStackTrace();
    }
  }
}

Job done! In a few lines of code :-)

Besides image processing JavaXT provides a lot more, I can only recommend to check it out. 
If you have suggestions , e. g. for a better approach  I am more than happy about your feedback.

Apply Java Permissions to Domino Agents at runtime - again ;-)

This post is supposed to be read by developers only. Admins, please move on ;-)

I have an agent which is used to make SFTP file transfers from Domino to our corporate SAP system. It's an interesting project and I am exploring new stuff on a daily basis :-)

One technical issue I had to solve was this:
The agent opens an SFTP session on a remote host. Unfortunately this is forbidden by Java Policies specified in the java.policy file of the JVM of the Domino server.
The error is
java.lang.SecurityException: not allowed to make a socket connection to MYHOST.MYDOMAIN.COM,-1

So I started to dig into java.policy and java.pol files. And to be honest I was not that much pleased about the whole thing. At first I started to grant ANY permissions in the global section of my policy file:

 grant {   
  ...  
  permission java.security.AllPermission;  
  ...  
 };   

This works but it goes a bit over the top for a productive environment... Therefore I started to tweak the policies to only allow one specific application the network operations required to do the job. Honestly, it's been painful... I think I got it more or less configured properly. But given the fact that we run the application in three different environments (DEV/TEST/PROD) on multiple servers I hardly could imagine a proper rollout scenario. I always thought one of the major strengths of domino and NSF was that usually the design and resides in a single database - and the configuration usually resides in the application, a few system databases (+ notes.ini).

There must be an easier way to grant my code the execution rights it needs.
I finally found a solution to grant my code the needed execution rights at runtime of the agent. There is a whole Java package for handling the permissions - and in my particular case I was looking for SocketPermissions. The code to grant a socket permission is pretty straight forward:

 String hostAndPort = "myhost.mydomain.com:22";   
 SocketPermission p = new SocketPermission(hostAndPort,  
       "accept,connect,resolve");  

This will allow my code to make a network connection to the specified host on the specified port. There might be neater solutions to that problem and not every admin would be happy about that. In my opinion it is not very consistent for what you need to grant permissions in policy files (like network connects) but on the other hand file handling can be allowed on the agent security (Allow restricted operations).

How to overcome Domino Webservice Timeout issues

Many of you might be aware of the restriction described here. I was not, and it caused me and my colleague quite some time to investigate, and fix this. Additionally, it caused us a lot of pain, because this issue increased the pressure on our project. So this might be relevant to some of you too...

So this is the story: We had a very annoying issue with a Domino WebService Consumer which was running in a timeout (almost all the time). As with many other projects the WebService was running fine in our Development environment. In both, our Integration as well as our Production Environment, the WebService always ran into the following error:

Error while reading data from server, Network operation did not complete 

in a reasonable amount of time; please retry

You have experienced this yourself too, don't you? Obviously, the amount of data in our development system was a lot smaller than in the integration and production environment. This is why the issue did not occur in our DEV system. But why the heck does the WebService stop at all??

After quite some research and opening a PMR we were pointed into te right direction:
The default Web Service Timeout is set to 60 seconds. It is a hard coded limitation, IBM seems not to be willing to fix this. To overcome the issue you have to be smarter than me and set the timeout on each WebService consumer individually at runtime. You can do this by calling the setTimeout() function of the WebService and pass the number of miliseconds.

More details can be  found in APAR LO48272: WEBSERIVCE CONSUMER BREAKS THE CONNECTION AFTER 60 SECONDS

DOTS: Logging to server console and log.nsf (part2)

In my previous blog post I showed how I implemented console logging in my DOTS projects. As I mentioned already yesterday, I prefer using logMessage respectively logException which are both implemented in the ServerConsole class of DOTS.
Both methods can easily be used directly inside your tasklet. When my first tasklet was growing, I started implmenting my own classes. Thereby I realised that logMessage and logException both are not available outside the tasklet class.

As these methods are implemented inside an own class "ServerConsole" I need an object of this class to use these methods. First I declare an object of type ServerConsole. In my case this object is in my class header and initialized in the class constructor. Thus I can use this object anywhere in my class - and even outside my class as it is declared as a public object.

In my DOTS projects I usually declare one ServerConsole object in one of my classes and use this object anywhere possible.

Beyond this approach I was pointed into two different directions today:

Rene Winkelmeyer mentioned another useful approach in a comment  here. If you want to log outside of the tasklet class you can easily use ServerTaskManager.getInstance().logMessageText("").

So if you only want to log messages, this might be the easiest solution for you. However, if you want to log messages and/or exceptions, the ServerConsole class is your friend...
OR you go down the road that Serdar suggested in his comment here. and use his Logger class.
He created an own TaskletLogger class which extends another Logger class. I haven't tried it out yet, but I am pretty sure it works great :)
Speaking of logger classes, I think I have to mention the XPages OpenLog Logger OpenNTF project by Paul Withers which can be used from OSGi extensions too.

To make a long story short: there are many options available - and while writing this update post I am realizing that this "blogging thing" revealed a lot of good new stuff to explore ;-)

DOTS: Logging to server console and log.nsf

In one of my current development projects I am developing a DOTS server task(let). One thing that I found very annoying is the logging part of DOTS. With logging, I essentially mean - at least in this post - an output to the server console and / or log.nsf. To achieve this, there are basically two different possibilities for logging in your DOTS projects.


Option 1:  System.out.println
As in other Java projects you can use System.out.println("your message") to print out message to the server console.

Running this little tasklet results in the following output on the server's console:

As you can see, the message is printed to the console. What you cannot see from here is that these messages are not save to log.nsf.

Option 2: logMessage
A way better logging is provided by a specific method logMessage("your message") which is part of the class com.ibm.dots.task.ServerConsole.
While your cord  resides inside the tasklet you can easily use this method instantly without any further declarations:

The output looks like that:

Using this method has several benefits:

• Messages logged using the logMessage method are saved to log.nsf. 
• You can see the date and time of the message.
• In addition, the message indicates that it comes from the DOTS Tasklet "Helloworld".

In my opinion this is the clean way to go for logging from a DOTS tasklet to the console respectively log.nsf.

Moreover, the ServerConsole class provides another very useful method "logException" which accepts a throwable Java Exception which then will be printed to the console. In other words: you can use this method in any catch statemen to handle error logging to the server console / log.nsf.

Domino OSGi Tasklet Services - some useful links

I am currently working on a DOTS project. Since I have started this project I benefited a lot from various community resources out there. First of all, thank you very much to the originating authors for sharing these resources with all of us! I was thinking that starting a link collection for DOTS might be a good idea for others who want dive deeper in this topic...

So this is a list of some valuable resources I used :

• Presentation from BLUG by Frank van der Linden:
  The power of DOTS
  This presentation is very useful if you want to get a comprehensive overview of DOTS and details on how to setup a development environment to get started!
• Various DOTS-related Blog Posts by Serdar Basegmez
• IBM Connect 2013 Session Slide by Bruce Elgort and Serdar Basegmez:
  BP207 - Meet the Java Application Server you already own - IBM Domino
• OpenNTF video by Niklas Heidloff:
  Extend Domino Servers via OSGi/Java
  This video also shows how to setup Eclipse as well as Domino and some samples.
• OpenNTF DOTS project page
• ICONUK presentation by Serdar Basegmez and Frank van der Linden:
  Background Tasks: An XPager's Guide to Process Server-Side Jobs on Domino
• NotesIn9 093: Introduction to DOTS by Serdar Basegmez
• Another helpful Blog Post by Rene Winkelmeyer with some interesting details you should not miss:
  DOTS - considerations about a real cool gem for IBM Domino

Feel free to add more links in the comments section :)