In my career as a Domino developer I have been playing with various Source Control Managent solutions already. I used TeamStudio Ciao! for many many years and this tool proved to be a life saver in many occasions already. So I owe some drinks to the guys from TeamStudio... (don't tell them!!)
Since IBM started opening Domino Designer in Release 8.5.3 (was it 8.5.2 ???) towards the "standard" SCM systems (Git, SVN, Mercurial) I have been playing with these options a lot. There was quite some pain involved, I lost source code, my repositories
lost the link to the NSF/ODP, etc... No pain, no gain! The good news for me: Today I have a
working environment which fits my needs :-)
My first steps were with SVN, but I admit that I was not able to get this setup running properly. Additionally, I was not too happy about the centralized approach. That said I started using Mercurial. Finally I ended up using Git, first the implementation in Domino Designer and nowadays using SourceTree. This setup provides me with such a high flexibility with regards to my work-related projects as well with my pet-projects.
The last missing bit so far was a proper SCM system. I have been looking around for a while and playing with various systems. As I am a corporate developer, using a hosted environment was not an option at all. So I was looking for a solution to run my self-hosted SCM server for my code coming from both, work-related projects as well as pet-projects. Finally, I think my journey has ended successfully (or at least I have reached an intermediate stop). I have played with GitLabHQ for a a while now and it looks very promising to me. I got it up and running relatively painless on a local Ubuntu VM. If you are looking for a self-hosted SCM server, I can highly recommend looking into GitLab (it is very focussed on SCM though).
There is a lot of useful information available in- and outside the XPages community. In the upcoming weeks I will describe my environment and approaches and specifically GitLab a little more in detail and hopefully add some more useful bits. So stay tuned!
Thursday, 16 January 2014
Wednesday, 8 January 2014
Today I learned how to override session authentication using a web site rule
Did you know that you can override session based authentication
based on URL patterns? Yes? Lucky you, I didn`t. I honestly admit it: I am more a developer
than an admin ;-). The feature dates back to R7.0.2 so I must have been missed something at that time...
In one of my
projects domino provides a web service which can be consumed by a
3rd-party-system. All sites on that server (R8.5) are configured to use
session-based authentication. Since web services cannot authenticate
via basic authentication (at least I did not get it working) I was
looking for a way to work around session based authentication. An
additional web site involves a lot of effort and patience in this environment as
there are quite a few people involved.
Finally
I got the right hint from the developer who consumes the web service.
There is a web site rule for that! And I just did not know about it:-o
The
setup is quite straight forward. Open an Internet Site document and click on Web Site - Create Rule and select "Override Session Authentication" as type of rule.
You can specify a URL pattern for
which domino overrides session based authentication. On the one hand
this provides a lot of flexibility. On the other hand, the pattern
should be chosen with care. Wildcards (*) can be applied too.
So, this is it, my lesson learned today.
Thursday, 28 November 2013
Domino Web Services SSL Error - Keyring file not found
Today I came across a strange behaviour on our Domino (R9.0.1) server.
We have a database with a web service consumer. This Web Service consumer is used by a schedules background agent. The Web Service makes calls to a third party system using https.
The Domino Web Server is configured using Internet Site documents. All https traffic and calls to the server worked perfectly fine from the evry beginning.
Whenever the web service is called, the following error is thrown on the server console:
Error 4746 Web Service XXXXXXXX method XXXXX error
Error connecting to 'xxxxx.xxxxx' on Keyring file not found
So there seems to be something wrong with SSL certificates. After some time of trial and error with some more HTTP server restarts I found two helpful ressources on Google:
IBM Technote LO47722: "SSL ERROR: KEYRING FILE ACCESS ERROR" ON WEBSERVICE CONSUMER US ING INTERNET SITE DOCUMENTS
and a thread in the good, oldnotes.net IBM DeveloperWorks forum:
HTTPS Web Service - SSL Error: Keyring file not found
Both describe the exactly same scenario as used here. The solution is that in both places, the Internet Site as well as the Server document the specified SSL certificate must match. In general I think this makes perfectly sense. However, as soon as you enable "Load Internet configurations from Server\Internet Sites documents"
in the server document, you cannot specify the SSL certificate in the server doc anymore. What I had to do is temporarily turn this setting off, specify the correct SSL certificate and turn it on again. This is the bit that confused me here. The setting in the server document seems to be used for requests issued by the server itself (i. e. web service consumers).
To make a long story short:
Make sure you have the same SSL certificates specified both in the server doc and the Internet site document.
We have a database with a web service consumer. This Web Service consumer is used by a schedules background agent. The Web Service makes calls to a third party system using https.
The Domino Web Server is configured using Internet Site documents. All https traffic and calls to the server worked perfectly fine from the evry beginning.
Whenever the web service is called, the following error is thrown on the server console:
Error 4746 Web Service XXXXXXXX method XXXXX error
Error connecting to 'xxxxx.xxxxx' on Keyring file not found
So there seems to be something wrong with SSL certificates. After some time of trial and error with some more HTTP server restarts I found two helpful ressources on Google:
IBM Technote LO47722: "SSL ERROR: KEYRING FILE ACCESS ERROR" ON WEBSERVICE CONSUMER US ING INTERNET SITE DOCUMENTS
and a thread in the good, old
HTTPS Web Service - SSL Error: Keyring file not found
Both describe the exactly same scenario as used here. The solution is that in both places, the Internet Site as well as the Server document the specified SSL certificate must match. In general I think this makes perfectly sense. However, as soon as you enable "Load Internet configurations from Server\Internet Sites documents"
in the server document, you cannot specify the SSL certificate in the server doc anymore. What I had to do is temporarily turn this setting off, specify the correct SSL certificate and turn it on again. This is the bit that confused me here. The setting in the server document seems to be used for requests issued by the server itself (i. e. web service consumers).
To make a long story short:
Make sure you have the same SSL certificates specified both in the server doc and the Internet site document.
Tuesday, 19 November 2013
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 ;-)
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 ;-)
Monday, 18 November 2013
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:
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.
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.
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:
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".
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.
Subscribe to:
Posts (Atom)