My IT-blog » tutorial

Change folders for Synology media server

Wim — Fri, 01 Jan 2010 22:07:17 +0000

When you enable the Synology Media Server on your NAS, there are 3 directories added to your file-system (video, music and photo) which will be used for the DLNA/UPnP media server to play the corresponding files.

I wasn’t very happy with these 3 directories because I wanted to categorize my media in other directories. In this post, I will post how I’ve resolved this problem.

First, enable SSH access to the NAS and log in.

My first idea to tackle this issue was to use of symbolic links

ln -s /volume1/MyMusicDirectory /volume1/music

I’ve re-indexed my files on the NAS and everything worked instantly. All the files in MyMusicDirectory where indexed so I was very happy…but not for long.
I noticed quickly that the new files I’ve placed in MyMusicDirectory weren’t auto-indexed by the NAS. I always had to re-index through the webinterface which can take hours when there is a lot of data to index so that was a big issue.
I figured out what the problem was: symbolic links will be considered as files and not as directories so the autoindexer wouldn’t follow the symbolic link.

Up to idea 2: mount –bind
I used mount –bind to create an unbreakable link which normally would be used as a directory by the NAS so the contents could be auto-indexed.

mount --bind /volume1/MyMusicDirectory /volume1/music

It worked!! YES!!
Till I’ve rebooted the NAS. The mount was gone and I had to manually add it again. Not something I want to do at every reboot.

Up to idea 3: changing fstab
The file /etc/fstab will be loaded at startup to mount the filesystem so I’ve added the following rule in the file:

/volume1/MyMusicDirectory /volume1/music bind defaults,bind 0 0

I saved the file and rebooted and it didn’t worked. The fstab file will be overridden at startup with Synology’s default fstab-file so the rule I’ve entered before was deleted.

And then idea 3: The solution
Create a file rc.local

touch /etc/rc.local

open the file and add the following line:

mount --bind /volume1/MyMusicDirectory /volume1/music

Now restart the NAS and you’re done.
The files in MyMusicDirectory will be auto-indexed by the media server.

The lifecycle of a Spring bean

Wim — Thu, 12 Nov 2009 17:30:42 +0000

In this blogpost, I’ll talk and give a few examples of the lifecycle of a bean in a Spring container.
The examples are tested with Spring 3.0RC1 but should work with Spring 2.5+

Xml Attributes

In this first example, I’ll show you how the lifecycle of a bean happens within the xml-configfile.

In the xml-file, we can define an init- and destroy-method to the bean, which will be called automatically by Spring.
Config.xml

Main program
In this case, I’ll use AbstractApplicationContext because this Context has a function to destroy the Context which a normal ApplicationContext doesn’t have.

package a;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class XmlAttributesTest {
    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test =  ctx.getBean("attributesTest",Test.class);
    }
}

Test.java

package a;

public class Test{

    public Test(){
        System.out.println("We are in the constructor of Test");
    }

    public void initMethod(){
        System.out.println("We are in initMethod of Test");
    }

    public void destroyMethod(){
        System.out.println("We are in destroyMethod of Test");
    }

}

The output will be:

We are in the constructor of Test
We are in initMethod of Test
We are in destroyMethod of Test

It’s also possible to declare default init- and destroy-methods in the xml-file. This is done in the beans-tag:

...

LifeCycles with interfaces

It’s possible to call the lifecyclemethods by implemnting a Spring interface.
It’s very easy to do but I don’t recommend this because when you use the interfaces, your code will be highly coupled to the Spring Framework which isn’t always a good case.
Config.xml
You don’t have to set an init and destroy method in the xml-file

Main program
This is always the same…

package b;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class InterfaceTest {

    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test =  ctx.getBean("interfacesTest",Test.class);
    }
}

Test.java
We have to implement InitializingBean for init-methods and DisposableBean for destroy-methods

package b;

import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class Test implements InitializingBean, DisposableBean {

    public Test(){
        System.out.println("We are in the constructor of Test");
    }

    public void afterPropertiesSet() throws Exception {
        System.out.println("We are in afterPropertiesSet of Test");
    }

    public void destroy() throws Exception {
        System.out.println("We are in destroy of Test");
    }
}

Lifecycle with annotations

Config.xml
Don’t forget to include to enable annotations with the Contextparameters in the xml-file

Main program
Still the same…

package c;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class AnnotationsTest {

    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test = ctx.getBean("annotationsTest", Test.class);
    }
}

Test.java
We can use the lifecyclemethods with the annotations @PostConstruct for init-methods and @PostDestroy for destroy-methods.

package c;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;

public class Test {

    public Test() {
        System.out.println("We are in the constructor of Test");
    }

    @PostConstruct
    public void start(){
        System.out.println("We are in the start-method of Test");
    }

    @PreDestroy
    public void stop(){
        System.out.println("We are in the stop-method of Test");
    }
}

Putting them all together

It’s possible to use the 3 methods all together
Config.xml

Main program

package d;

import org.springframework.context.support.AbstractApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class AllTogetherTest {

    public static void main(String[] args) {
        AbstractApplicationContext ctx = new ClassPathXmlApplicationContext("Config.xml");
        ctx.registerShutdownHook();
        Test test = ctx.getBean("allTogether", Test.class);
    }
}

Test.java
We are using interfaces AND annotations.
It’s even possible to use multiple times the same annotation:

package d;

import javax.annotation.PostConstruct;
import javax.annotation.PreDestroy;
import org.springframework.beans.factory.DisposableBean;
import org.springframework.beans.factory.InitializingBean;

public class Test implements DisposableBean,InitializingBean {

    public void destroy() throws Exception {
        System.out.println("DisposableBean-Interface");
    }

    public void afterPropertiesSet() throws Exception {
        System.out.println("InitializingBean-Interface");
    }

    @PostConstruct
    public void start(){
        System.out.println("First PostConstruct");
    }

    @PostConstruct
    public void start2(){
        System.out.println("Second PostConstruct");
    }

    @PostConstruct
    public void start3(){
        System.out.println("Third PostConstruct");
    }

    @PreDestroy
    public void stop(){
        System.out.println("PreDestroy");
    }

    public void initMethod(){
        System.out.println("initMethod");
    }

    public void destroyMethod(){
        System.out.println("destroyMethod");
    }
}

The output is:

Third PostConstruct
Second PostConstruct
First PostConstruct
InitializingBean-Interface
initMethod
PreDestroy
DisposableBean-Interface
destroyMethod

So we can conclude that the annotations are processed first, followed by the interfaces and at last the methods from the xml-file.

PHP – An introduction

Wim — Wed, 11 Nov 2009 13:06:08 +0000

I had to give a presentation about PHP at my work earlier this year.
It was a quick and simple introduction about PHP and his features.
If you want to use this presentation by yourself, please leave me a comment.
odp-file
ppt-file
pptx-file
pdf-file

servletconfig vs servletcontext

Wim — Thu, 15 Oct 2009 20:15:58 +0000

In this little blogpost, I’ll try to explain the differences between ServletConfig and ServletContext and when you can use them into a Java Web Application.

ServletConfig	ServletContext
Access deploy-time servlet parameters	Access web application parameters
One per servlet	One per web application

ServletConfig

ServletConfig is actually very simple. Like stated above, you can retrieve parameters for the servlet which are set at deployment time.
I’ll explain this with a very simple example.

If you have created a servlet with the name “MyServlet” you can add the following 2 variables into the servlet:

    
         MyServlet
         servlets.MyServlet
         
             variable1
             I'm var1
         
         
             variable2
             I'm var2
         
     
     
         MyServlet
         /MyServlet

You can retrieve variable2 with the following code:

getServletConfig().getInitParameter("variable2");

Retrieve all the variables of the servlet and loop over them:

Enumeration allvars = getServletConfig().getInitParameterNames();
while (allvars.hasMoreElements()) {
     String next = (String) allvars.nextElement();
     out.println(next + " has the value " + getServletConfig().getInitParameter(next));
}

It’s also possible to retrieve the servlets name through getServletconfig

out.println("The name of the servlet is: " + getServletConfig().getServletName());

ServletContext

ServletContext can be used to retrieve application-wide parameters, get serverparameters and store/retrieve/remove application-wide attributes.

It is possible to call the ServletContext right on or through the ServletConfig. Both are the same so you can choose between them.

if (getServletContext().equals(getServletConfig().getServletContext())) {
       out.println("both calls retrieve the same Context");
}

Just like with ServletConfig, you can set parameters in the Deployment Descriptor. They are initialized on compile time. It’s not possible to remove or add them on runtime.


        variable3
        Im var 3

And call them in your servlet just like the ServletConfig parameters:

getServletContext().getInitParameter("variable3")

Unlike ServletConfig, ServletContext can work with attributes. These are parameters or objects which you can set into the servlet and retrieve in every other servlet of your Web Application:

getServletContext().setAttribute("test", "I'm an application-wide String");
..
out.println(getServletContext().getAttribute("test"));
..
getServletContext().removeAttribute("test");

I’ll end this little short tutorial with an example of how you can retrieve serversettings through the Context:

out.println(getServletContext().getContextPath());
out.println(getServletContext().getMajorVersion());
out.println(getServletContext().getRealPath(""));
out.println(getServletContext().getServerInfo());

If there are any more questions, just shoot them

Dependency Injection with Google Guice by example

Wim — Tue, 29 Sep 2009 19:22:20 +0000

In this blogpost, I’ll explain Dependency Injection with Google Guice through a lot of examples. Hope you like it.

Annotation based DI
It’s possible in Guice to inject a class with the help of annotations. In this example, I create a mainclass which creates an order. Inside the order there will be a payment done. There are 2 types of payments (by card or cash) and they will be injected by Guice.
Payment

public interface Payment {
    public void pay();
}

PaymentCash

public class PaymentCashImpl implements Payment {
    public void pay() {
        System.out.println("I'll pay just plain cash");
    }
}

PaymentCard

public class PaymentCardImpl implements Payment{
    public void pay() {
        System.out.println("I'll pay with a credit card");
    }
}

Order

public class Order {

    private Payment payment;

    public Payment getPayment() {
        return payment;
    }

    public void setPayment(Payment payment) {
        this.payment = payment;
    }

    public void finishOrder(){
        this.payment.pay();
    }
}

Main

public class Main {
    public static void main(String[] args) {
        Order order = new Order();
        Payment payment = new PaymentCardImpl();
        order.setPayment(payment);
        order.finishOrder();
    }
}

There isn’t any Dependency injection in the code above. All the classes are highly coupled into each other. So it’s time to do some magic:
Payment
You can tell through the use of annotations which Payment type is the default implemented class

@ImplementedBy(PaymentCardImpl.class)
public interface Payment {
    public void pay();
}

Order
Inject the payment type in the order. What we here say is: Inject the default paymentimplementation, which is set by the @implementedby annotation, into the payment field.

public class Order {
    @Inject
    private Payment payment;
....

Main
Lastly, we have to rewrite the main class. In this example, we get an order which uses the PaymentCard as payment type

public class Main {
    public static void main(String[] args) {
       Injector injector = Guice.createInjector();
        Order order = injector.getInstance(Order.class);
        order.finishOrder();
    }
}

You can run this code. The output should be -I’ll pay with a credit card-. This code is so cool because if we want to switch to payment with cash at a later point, we just have to change the @implementedBy annotation in the interface and we are done.

Injection types
Guice knows different types of injection. The 3 most used are constructor, field and method injection (Examples are based on the above example)
Constructor injection

import com.google.inject.Inject;

public class Order {
    private Payment payment;

    @Inject
    public Order(Payment payment){
        this.payment=payment;
    }
   ...
}

Method injection

import com.google.inject.Inject;

public class Order {
    private Payment payment;

    @Inject
    public void setPayment(Payment payment) {
        this.payment = payment;
    }
   ...
}

Field injection

public class Order {
    @Inject
    private Payment payment;
   ...
}

Module based DI
It’s also possible to use Modules for injecting data. It’s maybe a little more work but I like it because all the configuration is in the same file. You can compare this with the xml-file in Spring applications.
Payment
Remove the @ImplementedBy annotation in the paymentinterface

public interface Payment {
    public void pay();
}

MyModule
Next, create the Module class. It has to implement Module, which has one method: configure.
The code speaks for its self. You say nothing more than bind Payment to PaymentCard.

public class MyModule implements Module {
    public void configure(Binder arg0) {
        arg0.bind(Payment.class).to(PaymentCardImpl.class);
    }
}

Instead of implementing Module, you can also extend AbstractModule. It’s just a matter of choice.

public class MyModule extends AbstractModule {
    public void configure() {
        bind(Payment.class).to(PaymentCardImpl.class);
    }
}

Main
Lastly, we have to put the module into our injector and we are done.

public class Main {
    public static void main(String[] args) {
        MyModule module = new MyModule();
        Injector injector = Guice.createInjector(module);
        Order order = injector.getInstance(Order.class);
        order.finishOrder();
    }
}

The 4 lines in the main class can be written into 1 single line:

public class Main {
    public static void main(String[] args) {
        Guice.createInjector(new MyModule()).getInstance(Order.class).finishOrder();
    }
}

Subclassing
In Guice, it’s easy to subclass an implementation.
Payment

public interface Payment {
    public void pay();
}

PaymentCardImpl

public class PaymentCardImpl implements Payment{
    public void pay() {
        System.out.println("I'll pay with a credit card");
    }
}

PaymentVisaCard
extend payment card with paymentvisacard

public class PaymentVisaCard extends PaymentCardImpl {
    public void pay() {
        System.out.println("I'll pay with a card from Visa");
    }
}

Nothing special in the Main class
Main

public class Main {
    public static void main(String[] args) {
        Guice.createInjector(new MyModule()).getInstance(Payment.class).pay();
    }
}

MyModule
You can specify the hierarchy in the moduleclass

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(Payment.class).to(PaymentCardImpl.class);
        bind(PaymentCardImpl.class).to(PaymentVisaCard.class);
    }
}

If you run this code, the Visa Card will be used.
Annotationbindings
It’s also possible to use annotations for injection
Payment
There’s nothing special in the interface and implementations:

public interface Payment {
    public void pay();
}

PaymentCardImpl

public class PaymentCardImpl implements PaymentCashImpl{
    public void pay() {
        System.out.println("I pay with a card");
    }
}

PaymentCashImpl

public class PaymentCashImpl implements Payment {
    public void pay() {
        System.out.println("I pay cash");
    }
}

Next, we have to created the annotations @cash and @Card
Cash

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

import com.google.inject.BindingAnnotation;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Cash { }

Card

import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

import com.google.inject.BindingAnnotation;

@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Card { }

Main

public class Main {
    public static void main(String[] args) {
        Guice.createInjector(new PayModule()).getInstance(Order.class).finishOrder();
    }
}

Module
You have to specify which annotations refers to which implementation in the moduleclass

public class PayModule extends AbstractModule{
    @Override
    protected void configure() {
        bind(Payment.class).annotatedWith(Cash.class).to(PaymentCashImpl.class);
        bind(Payment.class).annotatedWith(Card.class).to(PaymentCardImpl.class);
    }
}

Order
Now you can use the annotation in your code to inject the right class

public class Order {

    @Inject
    private @Card Payment payment;
   ...

If you want to chane Cardpayments to Cashpayments, just change the @Card annotation to @Cash

Namedannotationbindings
You can also use named annotations. This is a Guice annotation where the value is specified inside the moduleclass.
The paymentinterface, the Main and the Cash and Card implementations are the same as the previous example.
Module
Give the annotations a name (“Cash” and “Card”)

public class PayModule extends AbstractModule{
    @Override
    protected void configure() {
        bind(Payment.class).annotatedWith(Names.named("Cash")).to(CashPayment.class);
        bind(Payment.class).annotatedWith(Names.named("Card")).to(CardPayment.class);
    }
}

Main

 * @author wim
 */
public class Main {
    public static void main(String[] args) {
        Injector inj = Guice.createInjector(new PayModule());
        Order order = inj.getInstance(Order.class);
        order.getPaymentCard().pay();

        Guice.createInjector(new PayModule()).getInstance(Order.class).getPaymentCash().pay();
    }
}

Order
Now you can use them in your order

public class Order {

    private Payment paymentCash;
    private Payment paymentCard;

    @Inject
    public void setPaymentCash(@Named("Cash") Payment payment){
        this.paymentCash=payment;
    }

    public Payment getPaymentCash(){
        return paymentCash;
    }

    @Inject
    public void setPaymentCard(@Named("Card") Payment payment){
        this.paymentCard=payment;
    }

    public Payment getPaymentCard(){
        return paymentCard;
    }
}

These annotations are very simple but I don’t recommend them. Guice doesn’t check them on spelling or validity so they are kinda error prone.
Instancebinding
With instancebinding, you can easily give a value to an instance
Module
Give a value to a name inside the module

public class MyModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(String.class)
        .annotatedWith(Names.named("PaymentType"))
        .toInstance("...I'm a Visa Card...");
    }
}

Main

public class Main {
    public static void main(String[] args) {
        String text = Guice.createInjector(new MyModule()).getInstance(Order.class).getText();
        System.out.println(text);
    }
}

Order
Use the annotation. The String text will be injected with “…I’m a Visa Card…”.

public class Order {

    @Named("PaymentType")
    @Inject
    private String text;

    public String getText(){
        return text;
    }
}

Providers
The last example is with the use of providers.
A provider can be used when you have to craete an object. You have to annotate it with the @Provides annotation and the return type is the bound type.
Payment

public interface Payment {
    void pay();
    int getAmount();
}

CashPayment

public class CashPayment implements Payment{

    private int amount;

    public void pay() {
        System.out.println("Inside cashpayment");
    }

    public void setAmount(int amount){
        this.amount=amount;
    }

    public int getAmount(){
        return amount;
    }
}

Main

public class Main {
    public static void main(String[] args) {
        Payment payment = Guice.createInjector(new MyModule()).getInstance(Payment.class);
        payment.pay();
        System.out.println(payment.getAmount());
    }
}

MyModule
Inside the module class, we can construct the class and set the amount of payment.

public class MyModule extends AbstractModule{

    @Override
    protected void configure() {
    }

    @Provides
    Payment providePayment(){
        CashPayment pay = new CashPayment();
        pay.setAmount(100);
        return pay;
    }
}

Conclusion
You can do more with Guice than described above but that’s up to you to find out.
I love Guice!! It’s pretty simple and works very good. You don’t have to use XML to bind your classes and it’s very lightweight. If you just wan’t to use Dependency Injection, Guice is in my opinion the number 1.

How to flush the contents of Memcached

Wim — Mon, 21 Sep 2009 12:48:58 +0000

I often see people using telnet to flush the entire contents of their Memcached instance.
They use the following commands:

$ telnet localhost 11211
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
flush_all
OK
quit
Connection to localhost closed by foreign host.
$

You have to log in into the appropriate memcached host and port with telnet. After logged in, you have to use the flush_all command. If this command responses with OK, everything went fine and you can log out of your memcached server using the command quit.

The above command works fine but is a pain in the ass if you have to flush a lot and wants to use your console for other things.
If this is the case, you can run a flush_all in 1 command

echo 'flush_all' | nc localhost 11211

By default, nc (or netcat) creates a TCP socket either in listening mode (server socket) or a socket that is used in order to connect to a server (client mode). Actually, netcat does not care whether the socket is meant to be a server or a client. All it does is to take the data from stdin and transfer it to the other end across the network.