SpringData MongoDB: Beware Of @Id Annotated Fields Of Type BigInteger

Hi recently discovered that a field annotated with @Id behaves differently if it is of type String or BigInteger. Full details here: https://jira.spring.io/browse/DATAMONGO-1445

Edizione Corso Test Driven Development Presso Azienda Settore Finance

Lo Studio Ingegneria Demichelis ha completato l’erogazione di un’altra edizione del corso TDD presso un’importante azienda operante nel settore finance. I numerosi partecipanti hanno dato vita ad un’edizione del corso molto attiva dove con svariati esempi sono stati trasmessi i fondamenti di Test Driven Development con Java.

Corso Test Driven Development Settembre / Ottobre 2015
Corso Test Driven Development Settembre / Ottobre 2015

Spring Framework Resources

Intersting articles about the Spring Framework.

Logback, encoders instead of patterns.

If you are looking for an example about how to configure logback.xml you may have stumbled upon http://www.mkyong.com/logging/logback-xml-example/ . The post describe a configuration using the “Pattern” tag.

  1. <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
  2.   <layout class="ch.qos.logback.classic.PatternLayout">
  3.     <pattern>
  4.       %d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} – %msg%n
  5.     </pattern>
  6.   </layout>
  7. </appender>;

However this configuration has been deprecated in recent logback version, as you can check from the log produced by an application using the latest logback.

10:18:01,156 |-WARN in ch.qos.logback.core.ConsoleAppender[STDOUT] - This appender no longer admits a layout as a sub-component, set an encoder instead.
10:18:01,156 |-WARN in ch.qos.logback.core.ConsoleAppender[STDOUT] - To ensure compatibility, wrapping your layout in LayoutWrappingEncoder.
10:18:01,156 |-WARN in ch.qos.logback.core.ConsoleAppender[STDOUT] - See also http://logback.qos.ch/codes.html#layoutInsteadOfEncoder for details

As the log clearly states, http://logback.qos.ch/codes.html#layoutInsteadOfEncoder gives a quick explanation about how the log should be configured instead.

  1. <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
  2.   <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
  3.     <pattern>%d{yyyy-MM-dd HH:mm:ss} [%thread] %-5level %logger{36} – %msg%n</pattern>
  4.   </encoder>
  5. </appender>

CoreOS playground through PXE – Network Set Up [2/5]

In the prvious installment we depicted the idea of setting up a PXE server to boot CoreOS. In this post, I’ll show you how to set up the networking on the PXE server.

Playground Virtual Machine Set Up

Create a new machine in Virtual Box with two network card: one of type NAT, the other as a Internal Network called “coreosnet”. The first will provide Internet access to the Playground server, the latter will be the one the CoreOS machine will be connected to.

Lubuntu Installation

Download the Lubuntu ISO from https://help.ubuntu.com/community/Lubuntu/GetLubuntu, and use it to install the OS on the “playground” machine.

Virtual Box Guest Addition

It’s always nice to be able to copy and paste code snippets back and forth between the guest and the host, so it’s better to install the Virtual Box Guest Additions. Start the PXE Server, open a terminal and install all the latest updates and dkms.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install dkms

After that you can install the VBox Guest Additions through the virtual machine’s “Insert Guest Addition” menu and reboot the system. After the reboot log in and double check that the clipboard settings are enabled. You should now be ready to enjoy a completely usable Lubuntu virtual machine.

Programs And Services

Let’s install some tools that will be needed to set up and test the PXE server.

sudo apt-get install tftpd-hpa tftp-hpa isc-dhcp-server apache2 curl
  • tftpd-hpa: the tftp damon, needed to provide the boot files to the CoreOS nodes, to LAN boot them;
  • tftp-hpa: a tftp client, used to check if the tftp daemon has been correctly set up;
  • isc-dhcp-server: DHCP server to let the CoreOS nodes configure their NICs;
  • apache2: to provide the config file through HTTP;
  • curl: to run a check on the config file being published.

Network Configuration

First of all let’s check both network cards. The “ip” command shows the list of existing interface cards. In this case lo, eth0 and eth1.

$ ip link list
 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
 link/ether 08:00:27:a9:87:6d brd ff:ff:ff:ff:ff:ff
 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
 link/ether 08:00:27:44:04:9f brd ff:ff:ff:ff:ff:ff

With “ip” is also possible to discover which interface cards are properly configured

$ ip -4 address list
 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0
 valid_lft 85461sec preferred_lft 85461sec

It is straightforward to understand that eth1 does not have any IP address associated. Is then the network card connected to the internal network. We need to assign a static address to this network card.

cat > /tmp/interfaces <<END
 # loopback
 auto lo
 iface lo inet loopback
 # eth1
 auto eth1
 iface eth1 inet static
 address 192.168.77.1
 # no gateway for eth1 because it does not fwd packets outside the network
 netmask 255.255.255.0
 network 192.168.77.0
 broadcast 192.168.77.255
 END
 sudo cp /etc/network/interfaces /etc/network/interfaces.$(date --iso-8601=seconds)
 sudo mv /tmp/interfaces /etc/network/interfaces
 sudo /etc/init.d/networking restart

To check if the network card correctly obtained an IP just execute again the ip command, it should now show the IP for eth1 too.

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
 inet 127.0.0.1/8 scope host lo
 valid_lft forever preferred_lft forever
 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic eth0
 valid_lft 84732sec preferred_lft 84732sec
 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
 inet 192.168.0.1/16 brd 192.168.255.255 scope global eth1
 valid_lft forever preferred_lft forever

It’s time now to enable port forwarding to enable internet access from the coreos network.

sudo cp /etc/sysctl.conf /etc/sysctl.conf.$(date --iso-8601=seconds)
sudo cp /etc/sysctl.conf /tmp/sysctl.conf
echo 'net.ipv4.ip_forward=1' >> /tmp/sysctl.conf
sudo cp /tmp/sysctl.conf /etc/sysctl.conf

Finally, to enable NAT

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
sudo iptables -t filter -L
sudo iptables -t nat -L
sudo iptables -t mangle -L

This should be enough to enable the PXE server to provide internet access to the CoreOS nodes we will boot on the dedicated network.

Stay tuned for the next episode, we’ll set up all the services needed to provide booting through PXE.

CoreOS Playground With PXE – Part 1