Domino & Spring Boot: How does it work

The example Spring Boot Plugin I have published two days ago is a full working example to run Spring Boot applications directly in the Domino HTTP task. It is designed as an OSGi plugin and runs inside the servlet container, which means that the „normal“ features of the Domino HTTP task are available at runtime, for example the existing the user session is accessible via the ContextInfo object.

To complile and deploy the plugin, you first have to install the XPages SDK and create the missing feature project and update site project as described in one of my older posts.
After importing the plugin in the UpdateSite and restarting the HTTP task, the Spring Boot application is ready and will flood the console with a lot of debugging informations when the first request hits the application:

While the example is a really basic one I am using the same approach for years in production environment. The reason is that it was fundamental for the customer (which has abandoned Domino years ago) to have a modern and industry-wide standard framework: The application is now a Spring Boot application which has a NoSQL backend – the decision makers had some buzzwords, the term „Domino“ is no longer used and all participants are happy now.

How does it work?

First it is required that the main configuration is still in the web.xml file. This is required because of the old servlet container which is still only available in version 2.5; I was not successfull to implement the latest Spring Boot version 5, because it seems that a servlet container version 3.0 is required.

In the web.xml file, the servlet mapping is defined:

<servlet>
   <servlet-name>dominoSpringBootServlet</servlet-name>
   <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
   <load-on-startup>1</load-on-startup>
</servlet>

An additional configuration file dominoSpringBootServlet.xml contains the servlet specific configuration; both (the servlet name and the XML configuration) must have the same name, otherwise Spring Boot will not find the configuration file.

In this configuration file, the base package is defined, which tells the framework where to scan for Java classes and annotations:

<context:component-scan base-package="domino.springboot.plugin" />

The following line enables Spring Boot’s annotations:

<mvc:annotation-driven />

Now, the package domino.springboot is scanned for controllers and configuration classes, which I will describe in the next post.

 

Veröffentlicht unter Java, OSGi, Server, Spring, Web | Verschlagwortet mit , , | 3 Kommentare

Domino & Spring Boot: An example project

I have uploaded an example for running Spring Boot applications on top of Domino. You can find it here:
https://github.com/hasselbach/domino-springboot

This solution is running for years in productive environments.

Hopefully I will find some time to explain how it works.

Veröffentlicht unter Java, OSGi, REST, Spring, Web | Verschlagwortet mit , , , | 4 Kommentare

Domino & Spring Boot: ScheduledTasks

When developing Spring Boot applications running on Domino, there is a feature which runs out of the box and makes developers happy: ScheduledTasks.

These are the equivalent for agents, but they are running directly in the HTTP task (which allows to access the complete Spring Application at runtime) and can be scheduled exactly to the milisecond.

To enable a scheduled task, you first have to add the @EnableScheduling annotation in your Application class:

package domino_spring.plugin;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.scheduling.annotation.EnableScheduling;

@SpringBootApplication
@EnableScheduling
public class Application extends org.springframework.boot.web.support.SpringBootServletInitializer {

   public static void main(String[] args) {
      SpringApplication.run(Application.class, args);
   }

}

Next step is to declare the TaskScheduler used. Just add a bean to your Application class:

@Bean
 public TaskScheduler taskScheduler() {
      return new ConcurrentTaskScheduler();
 }

After completing the setup you can define your scheduled task:

package domino_spring.plugin;

import java.text.SimpleDateFormat;
import java.util.Date;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;

@Component
public class ScheduledTasks {

   private static final Logger log = LoggerFactory.getLogger(ScheduledTasks.class);

   private static final SimpleDateFormat dateFormat = new SimpleDateFormat("HH:mm:ss");

   @Scheduled(fixedRate = 5000)
   public void reportCurrentTime() {
      log.info("The time is now {}", dateFormat.format(new Date()));
   }
 
}

When the Sprint Boot application is now started, the current time is  printed to the logs every 5 seconds.

Veröffentlicht unter Agenten, Java, Server, Spring, Web | Verschlagwortet mit , , , , , | 4 Kommentare

java.security.AccessControlException kills productivity

Dear IBM, can you please remove the totally useless java policy restrictions? Especially for agents running on the server?

I can’t imagine how much life time and customers money was spent during the last decades just to find a workaround for these limitations. The Q&A sites are full of questions about problems with this topic, and I never met someone who found the restriction usefull.

It’s 2018, and writing something in Lotus Script just to „solve“ this issue makes absolutly no sense. The whole „Let’s restrict Java as much as we can“ is pita – everyone knows how to ship around these restrictions. The „bad guys“ are not stopped, only the „good developers“ will be limited.

By the way: Are these limitations planned for notes.js integration? If so, please drop it immediatly.

Veröffentlicht unter Java, Security | Verschlagwortet mit , , | Schreib einen Kommentar

The anatomy of a LTPA token

LTPA Token

LTPA token are widely used in the IBM world for authentication between different physical machines, also known as WebSSO. There are two three types available, LTPA1, LTPA2 and a Domino format.

LTPA1 and LTPA2 are commonly used with WebSphere, and Domino can import the keys to work with this kind of token. The Domino version of LTPA is normally used in the Domino world, and that’s the token I will write about.

First, what is a Domino LTPA token in general? It is a BASE64 encoded String containing the information about the user, including some timestamps. To avoid a security problem, the token is hashed and then encrypted (see here: LTPA versions and token formats).

So let’s look into a real world example. Here is a LTPA Domino token from my server*:

77+9AQIDNUFCMTJBNjk1QUIxMzg3OUNOPVN2ZW4gSGFzc2VsYmFjaC9PPUhhc3NlbGJhL089Q0gwezcFKix7Fy00cg==

Now here comes the BASE64 decoded version:

As you can see, there is my username insinde of the token. And at this point I am a little bit confused, because the IBM writes in the linked article above:

Domino uses a shared key and SHA-1 to calculate a MAC over the content. After the MAC is attached, the user data and MAC are encrypted with a 3DES key obtained from the LTPA key file.

Maybe it is because I have super powers which allow me to decrypt the 3DES encrypted userdata in my brain. But I think it is just a wrong information, and the userdata are not encrypted with 3DES.

This does not make the LTPA token unsafe, there is still a SHA-1 hash which protects the userdata from beeing changed in a text editor. Let’s look how the token is build up:

Anatomy of LTPA Domino Token

Byte 0-3 4-11 12-19 20 – ? ? – ? + 20
Content Header Creation Expiration Username Hash

Header (4 Bytes)

Byte 01 02 03 04
Value 0 1 2 3

Creation & Expiration (each 8 Bytes)

These values are Java Dates stored as Long value.

Username (Length different)

A string containing the abbreviated form of the current username. The length varies.

Hash (20 Bytes)

A SHA-1 hash, 160 Bits long. The hash is generated by adding the LTPA secret at the end of the userdata; the result is added to the end of the LTPA token.

The Problem

The problem with LTPA Domino token is the use of an insecure hash algorithm. We had to change all SSL certificates because of it, the NIST has deprecated it in 2011. And the 3DES encryption is a myth.

But we are still protecting our infrastructure with this weak algorithm…

*: no, it’s not 😉

Veröffentlicht unter Security, Server | Verschlagwortet mit , , , | Ein Kommentar

Quick-n-Dirty: Hotfix for DateTimeHelper

This weekend I stumbled over a bug of the DateTimeHelper: If the value of the field is empty, no actions and/or action listeners connected with a managed bean will be executed anymore.

Here is an example of a small XPage to illustrate the problem:

<?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?>
<xp:view xmlns:xp="http://www.ibm.com/xsp/core">
 
    <xp:label 
        value="#{javascript:java.lang.System.currentTimeMillis()}" id="labelNow" />

     <xp:inputText id="inputTextDT" value="#{myBean.valueDT}">
         <xp:this.converter>
             <xp:convertDateTime type="date" />
         </xp:this.converter>
         <xp:dateTimeHelper />
     </xp:inputText>

    <xp:button id="button" value="OK">
        <xp:eventHandler
            event="onclick"
            submit="true"
            refreshMode="partial"
            refreshId="labelNow"
            actionListener="#{myBean.action}" />
     </xp:button>

</xp:view>

It does not matter if you set the disableValidators property for the text field to true, even an immediate=true won’t help here. The reason for the problem is that the renderer of the dateTimeHelper always uses the attached converter and fails with a null pointer exception if the value is empty (this infringes the JSF specification, but IBM has implemented it this way).

The workaround for this problem is to overwrite the existing renderer class and handle the NPE by yourself:

package ch.hasselba.xpages.renderer;

import javax.faces.component.UIComponent;
import javax.faces.context.FacesContext;
import javax.faces.convert.ConverterException;
public class DateTimeHelperRenderer
    extends com.ibm.xsp.renderkit.dojo.DateTimeHelperRenderer{

    public Object getConvertedValue(FacesContext fc, UIComponent uiComponent, Object obj)
        throws ConverterException  {

          Object result = super.getConvertedValue(fc, uiComponent, obj);

          if( result == null )
            return new Object();

          return result;
    }
}

The renderer must now be registered in faces-config.xml:

<?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="UTF-8"?>
<faces-config>
  <render-kit>
    <renderer>
      <component-family>javax.faces.Input</component-family>
      <renderer-type>com.ibm.xsp.DateTimeHelper</renderer-type>
      <renderer-class>ch.hasselba.xpages.renderer.DateTimeHelperRenderer</renderer-class>
    </renderer>
  </render-kit>
</faces-config>

Now the problem is solved, the managed bean’s action get executed even if the value is empty.

Veröffentlicht unter Java, JSF, XPages | Verschlagwortet mit , , , , , | Ein Kommentar

Re: Domino REST performance analysis

I have created a Quick-n-Dirty performance test for Csaba’s „10K record test“:

Loading time 200 ms overall, 60 ms TTFB.

Do you want to know how this works? Feel free to come to SNoUG next week or to Rudi’s EntwicklerCamp and join my sessions about „High Performance REST Applications“.

Veröffentlicht unter REST | Verschlagwortet mit , , , | 6 Kommentare

Domino & Java 1.8: Thank you, IBM!

For years it was a lot of pain when developing for the Domino platform using Java 1.6 only. But now, Java 1.8 is available, and this allows to use the latest versions for a lot of libraries and development tools.

After installing FP8 to the Client, Eclipse allowes to use the Domino JRE in a JavaSE-1.8 environment:

This gives access to the latest M2Eclipse plugin (1.7.0). The old version problem when running with JRE 1.6…

… is solved:

Eclipse Updates? No problem, just do it!

Latest Java features like switch statement with Strings? Here we go:

String token = "FOO";
switch(token) {
    case "FOO": return (T) Foo.class;
    case "BAR": return (T) Bar.class;
}

Third party libraries like Jackson 2.8.0? Works like a charm!

Thank you, IBM!

Veröffentlicht unter Java | Verschlagwortet mit , , , , | Schreib einen Kommentar

Domino & REST: Debug your Plugin

When developing OSGi Plugins, you should have your own development server running on your local machine. Not only because of the faster deployment of changes (a new version of a plugin must always deployed with a HTTP restart), but because of the Java debugging posibilities: Only one Eclipse instance can connect to the JVM, and every request processed by the server will start the debugger. If multiple users a accessing the server while you are debugging, your Eclipse will try to debug every incoming request, and this can lead into a confusing situation for all.

To enable debugging, you first have to add two parameters to the notes.ini:

JavaEnableDebug=1
JavaDebugOptions=transport=dt_socket,server=y,suspend=n,address=8000

This starts the debugging on port 8000. Feel free to change the value to every port you want. Because of security reasons you should not start debugging on a productive machine.

After restarting the domino server, you can connect to the JVM in your Eclipse IDE by creating a new JVM remote debugging session. Create a new debug configuration…

… choose (1) „Remote Java Application„, (2) give a name to it, (3) select the plugin project, (4) enter the port the server listens, and click on (5) „Apply„.

If you want to connect to your server, you need to start debugging by clicking on the project:

After setting a breakpoint and sending a request to the servlet, Eclipse switches to the Debug perspective where you can look what happens with your servlet.

Sometimes you are connecting to the „wrong“ JVM, because a Java agent is running and/or a DOTS task does it’s job. It’s better to disable these tasks on your development server.

During debugging you are able to hotswap your code, but keep in mind that after a restart of the HTTP JVM all your changes are no longer „installed“. You have to build a new plugin or replace your code during runtime again.

In the next blog post, let’s talk about our development tools.

Veröffentlicht unter Jackson, Java, JEE, OSGi, REST | Verschlagwortet mit , , , , , , | Schreib einen Kommentar

Domino & REST: More about Jackson

When creating a REST API servlet, Jackson provides a huge list of possibilities to manipulate the JSON data, mostly using annotations.

Let’s demonstrate some of them with this little class, which has only two properties:

public class Demo {

    private String foo;
    private String bar;

    public String getFoo() { 
        return foo;
    }
    public void setFoo(String foo) {
        this.foo = foo;
    }

    public String getBar() { 
        return bar;
    }

    public void setBar(String bar) {
        this.bar = bar;
    }
}

The playground converts the content string to a POJO and back to a string:

String content = "{ \"foo\": \"bar\" }";
 
 // init the ObjectMapper
 ObjectMapper mapper = new ObjectMapper();
 
 // build the Object
 Demo test = null;
 try {
     test = mapper.readValue(content, Demo.class);
 } catch (Exception e) {
     e.printStackTrace();
 }

 // and now convert it back to a String
 String data = null;
 try {
     data = mapper.writerWithDefaultPrettyPrinter().writeValueAsString(test);
 } catch (Exception e) {
     e.printStackTrace();
 }

 System.out.println( data );

If we run this code, the result is not really spectacular:

{
 "foo" : "bar",
 "bar" : null
}

So let’s ignore the property foo by adding the annotation @JsonIgnoreProperties to the Demo class:

@JsonIgnoreProperties({"foo"})
public class Demo { ... }

Now, foo is no longer in our resulting JSON:

{
    "bar" : null
}

The property bar is null, and we don’t like nulled properties in our JSON. That’s why we add another annotation, @JsonInclude:

@JsonInclude(JsonInclude.Include.NON_EMPTY)
public class Demo { ... }

After removing the previously added @JsonIgnoreProperties annotation, our result looks like this (the empty property bar was skipped):

{
    "foo" : "bar"
}

What happens if we change our content string, and add an unknown property?

String content = "{ \"foo\": \"bar\", \"undefined\": \"property\" }";

An error occurs because Jackson does not know how to handle the new property:

com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field "undefined" (class ch.hasselba.JacksonPlayground.Demo), not marked as ignorable (2 known properties: "foo", "bar"])
 at [Source: { "foo": "bar", "undefined": "property" }; line: 1, column: 31] (through reference chain: ch.hasselba.JacksonPlayground.Demo["undefined"])
 at com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException.from(UnrecognizedPropertyException.java:51)
 at com.fasterxml.jackson.databind.DeserializationContext.reportUnknownProperty(DeserializationContext.java:817)
 at com.fasterxml.jackson.databind.deser.std.StdDeserializer.handleUnknownProperty(StdDeserializer.java:954)
 at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownProperty(BeanDeserializerBase.java:1315)
 at com.fasterxml.jackson.databind.deser.BeanDeserializerBase.handleUnknownVanilla(BeanDeserializerBase.java:1293)
 at com.fasterxml.jackson.databind.deser.BeanDeserializer.vanillaDeserialize(BeanDeserializer.java:249)
 at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:136)
 at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3560)
 at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2576)
 at ch.hasselba.JacksonPlayground.App.main(App.java:24)
null

But there are two annotations to the rescue, @JsonAnyGetter@JsonAnySetter. By changing our Demo class and adding the following lines of code…

private Map<String, Object> others = new ConcurrentHashMap<String, Object>();

@JsonAnyGetter
public Map<String, Object> getOthers() {
    return this.others;
}

@JsonAnySetter
public void addOther(final String name, final Object value) {
    this.others.put(name, value);
}

… Jackson now puts all the unknown/undefined properties in the others map (uses the method defined by @JsonSetter). And then it uses the method with the @JsonGetter annotation when producing the JSON from the Demo instance.

{
  "foo" : "bar",
  "bar" : null,
  "undefined" : "property"
}

What if we want to handle multiple „Demo“ objects in a JSON Array?

String content = "[ { \"foo\": \"bar\" }, {\"foo\": \"bar2\" } ]";

In this case we change our reading routine to work with lists:

// build the Object
List<Demo> test = null;
try {
    test = mapper.readValue(content, mapper.getTypeFactory()
            .constructCollectionType(List.class, Demo.class));
} catch (Exception e) {
    e.printStackTrace();
}

In the result all entries are now contained in the list of Demo objects:

[ {
 "foo" : "bar",
 "bar" : null
}, {
 "foo" : "bar2",
 "bar" : null
} ]

Back to our RestApiApplication, have a look at this line:

objMapper.setSerializationInclusion(Include.NON_EMPTY);

This removes all empty properties globally from the generated output of our the servlet. So there is no need to add the @JsonIgnore annotation to any class. You can modifiy the globally used ObjectMapper in your servlet with multiple option, more will follow in another blog post.

Veröffentlicht unter Apache Wink, Jackson, JEE, REST | Verschlagwortet mit , , , , | Schreib einen Kommentar