The training lasted 4 days and it was really a full-day training: we started at 9.00 and finished at 17.00 with a few short, coffee, breaks and one longer — for a lunch. You can view the syllabus on this site, but mainly, the course focused on the core of Spring Framework, so we’ve spent a lot of time discovering the dependency injection intricacies, bean factories, bean post processors, AOP (and how it is applied to the transactions, security and other cross-cutting concerns.) We’ve just scratched the surface of the Spring MVC, RMI, JMS and JMX.
All this material was presented in a form of an active lecture where the questions were widely accepted during the talk. We were provided with printed version of the slides, so it was easy to make notes directly on the slides.

After each of the sections, there was a lab exercise / exercises — a hands-on session with Spring Tool Suite. For those labs, we were also provided with the printed version of the appropriate tutorial. The tasks were pretty easy, as they based on just presented material. All the source code used in this sessions was provided on a SpringSource 4GB pen-drive that every attendant was given.

The class itself was rather small, as it consists of 6 attendants: 5 Poles and 1 Englishman (cheers Tom!) The lecturer, Tomas Lukosius put a lot of effort into passing the knowledge in easy and simple way – just as all good lecturers should do. The whole training was like “look how simple it is” or “it just another bean post processor” or things like that. It really showed how some complicated stuff like runtime aspects weaving, transactions or security constraints are organised under the hood. Not rarely it seemed quite simple and uncomplicated!
At the beginning of each day there was a revision, a sum-up of all the topics discussed day before. It helped to refresh your memory as well as organise the knowledge better.

My overall opinion about this training is very good. I can see a major improvement of my knowledge about how the core of the Spring Framework works. I’m sure that if you’d put some more effort, read a decent book like “Spring in Action” by Craig Walls and supplement your knowledge with Spring documentation, you’ll earn the same knowledge as in this training.
This will, however, take a lot more time and you’d need a lot of self-discipline. Nevertheless, it’s achievable as the knowledge passed during the training wasn’t any kind of black or secret magic.

One of the nice things about the training is that after it you earn a voucher for Spring Certified Professional exam. Although the passing score is fairly high (in comparison to the Oracle exams) I’ve heard that it’s enough just to re-read all the slides, notes and do once again all the labs. Hope to find some time to attempt to pass the exam soon!

PS. The beverages, snacks and lunch was provided by the company which held the training (Altkom Akademia.) Beverages and snacks were really nice but the lunches… well… just let’s say that I’ve eaten a lot of better things in my life ;-)

This will be very basic introduction, so I’m afraid that for those of you who know what DWR is and used it, this article won’t introduce nothing new.

XMLHttpRequest

Up to know I’ve always thought that if the JavaScript have its XMLHttpRequest object, it can send asynchronous requests to the server – so this is basically the AJAX. Who needs anything more?

Well, it seems that the XMLHttpRequest is quite low-level and as usual, more high-level tools and frameworks arose. DWR is one of such frameworks, but it goes even further. Not only you don’t have to deal with those low-level XMLHttpRequest objects, but you can use your Java objects directly in the JavaScript code.

DWR creates a JavaScript’s proxy for your Java methods and sends the request to invoke particular method asynchronously – expecting the result in the callback method. You can easily define what Java methods should be accessible from the JS using the dwr.xml configuration file you’ll see in a moment.

Server side

Take a look at this Java code – it’s just a regular class with two methods. Let’s pretend it’s a Dice Roller service, so it allows you to roll a dice (rollDice()) and to scream at the dealer if you’re not happy with the resulting pips (scream(String).)

package com.piotrnowicki.dwr;

import java.util.Random;
import java.util.logging.Level;
import java.util.logging.Logger;

/** Simulates a 6-sided dice roll. Also allows to scream if you're not
 * satisfied with the result.
 *
 * @author PiotrNowicki
 **/
 public class DiceRollService {

    private Logger log =
                    Logger.getLogger(DiceRollService.class.getName());

    /**
     * Just for inspection when the object is created.
     */
    public DiceRollService() {
        log.info("Constructing an object");
    }

    /**
     * Roll a 6-sided dice.
     *
     * @return rolled pips.
     */
    public Integer rollDice() {
        return new Random().nextInt(6) + 1;
    }

    /**
     * Scream (e.g. at the dealer) given sentence. Shows how you can
     * deal with parameters in DWR.
     *
     * @param msg
     *            what to be screamed.
     */
    public void scream(String msg) {
        log.log(Level.INFO, "Screaming: {0}", msg);
    }
}

This is a class which methods we want to be accessible directly from the JS (embedded on our user-interface HTML page). To achieve this, we need to inform the DWR about the existence of the DiceRollService class. We do this by creating a dwr.xml file in webapp/WEB-INF/ (just next to the web.xml):

<!DOCTYPE dwr
  PUBLIC "-//GetAhead Limited//DTD Direct Web Remoting 3.0//EN"
  "http://getahead.org/dwr/dwr30.dtd">
<dwr>
    <allow>
        <create creator="new"
                javascript="JSDiceRollService"
                scope="application">
            <param name="class"
                   value="com.piotrnowicki.dwr.DiceRollService" />
        </create>
    </allow>
</dwr>

The above excerpt tells DWR to create an instance of DiceRollService using the new Java operator (you can as well use static method to obtain your class instance, access bean registered in the Spring Framework and so on – read this page for more details.)

This newly created object will be named JSDiceRollService and it’ll be bound to the application scope (similarly as in Servlets, we have: application, session, page and request scope.)

The last thing we need is to create a DWR Servlet which will be responsible for registering our classes / methods. It will make them accessible for the DWR client or RESTful client. We do that by creating a web.xml that looks somewhat like this:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns="http://java.sun.com/xml/ns/javaee"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
         http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         version="3.0">
    <servlet>
        <servlet-name>dwr-invoker</servlet-name>
        <servlet-class>
            org.directwebremoting.servlet.DwrServlet
        </servlet-class>
        <init-param>
            <param-name>jsonpEnabled</param-name>
            <param-value>true</param-value>
        </init-param>
        <init-param>
            <param-name>debug</param-name>
            <param-value>true</param-value>
        </init-param>
    </servlet>
    <servlet-mapping>
        <servlet-name>dwr-invoker</servlet-name>
        <url-pattern>/dwr/*</url-pattern>
    </servlet-mapping>
</web-app>

Notice the /dwr/* url-pattern has been bound to the DWR Servlet – this is the entry-point to the server-side DWR. You don’t really need the jsonpEnabled init-param, but in a moment I’ll show you why it can be useful.

The debug param allows you to see the test page when you enter the DWR Servlet URL, e.g.: http://localhost:8080/DWRTest/dwr (DWRTest is an application context.)

I’m not aware if this can be configured using the Servlets 3.0 @WebServlet annotation, but as I don’t see much added value using it here, I won’t even try digging it.

And that’s pretty much all there is – you’ve created your business logic class in pure Java, instructed DWR that it should create a JS proxy for your class and, finally, you’ve defined and configured the server-side DWR Servlet.

Now it’s time to go to the client layer.

Client Side

First thing you can check after you run your application, is to enter the already mentioned DWR test page (e.g. http://localhost:8080/DWRTest/dwr) and see if you can access your Java methods from it. You can observe that your Java object will be created as many times as appropriate, depending on your scope attribute value in dwr.xml. Every object instantiation is logged, so you can inspect your server logs if you want to check it.

However, let’s go to some more interesting stuff – accessing your Java objects from an arbitrary JavaScript code. Take a look at the code below (it’s called index.jsp and it’s located directly in the webapp/ directory):

<!DOCTYPE html
  PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
  <html>
    <head>
      <title>DWR Test</title>
    </head>
    <body>
      <script type="text/javascript"
              src="dwr/engine.js"></script>
      <script type="text/javascript"
              src="dwr/interface/JSDiceRollService.js"></script>
      <input type="button" value="Roll a dice" onclick="clicked()" />
      <div id="diceRes"></div> 

      <script type="text/javascript">
        function clicked() {
          JSDiceRollService.rollDice({ callback : function(str) {
            document.getElementById("diceRes").innerHTML = str;
          } });
        } 

        // Taken from kdenney's post:
        //        http://stackoverflow.com/a/155265/920607
        function keyPressed(e) {
          if (typeof e == 'undefined' && window.event) {
            e = window.event;
          } 

          if (e.keyCode == 13) {
            JSDiceRollService.scream(
                 document.getElementById("shoutField").value, {
                   callback : function(str) {
                     alert("Check your Java server logs");
                   }
                 }
            );
          }
        }

      </script>
      <br /> <br />
      Type any text to shout in Java System.out.println
      (ENTER sends the request):
      <input id="shoutField"
             type="text"
             value="You bastard!"
             onkeypress="keyPressed(event)" />
    </body>
  </html>

It’s not the most elegant and prettiest HTML + JavaScript code in the world, but for this exemplary purpose — it does it work. I’m not sure if it will even pass the W3C validator, but that’s not the point now.

Take a look at the <script> imports at the beginning of the <body>. It’s value refers to our DWR Servlet URL, so those scripts are generated by DWR for you. Notice that you’ve also included a JavaScript code for DWR generated proxy – dwr/interface/JSDiceRollService.js.

Also, be very careful with the order of imports. The engine.js script import must occur before your JS proxy import.

This simple page shows you:

• a button which will invoke DiceRollService#rollDice() method and print the result in div with ID = diceRes,
• an input field that after you hit ENTER, will invoke DiceRollService#scream(msg) where the msg is text typed into the field.

That’s basically it – you should be able to successfully send an asynchronous HTTP request which will invoke one of your Java methods using XMLHttpRequest under the hood. Pretty neat, huh?

REST

One of the additional features of the DWR is the support for REST’style requests / responses. If you access the following URL: http://localhost:8080/DWRTest/dwr/jsonp/JSDiceRollService/rollDice (of course, substituting the appropriate parts like protocol, host, port and application context) you can access the DiceRollService#rollDice method as well. The response will be in the JSONP format and it should look something like this:

{ "reply":5}

Summary

I didn’t test any reverse Ajax support, as I think I’ll write a separate post about it – just when I’ll try to do some tests with Server Sent Events and Web Sockets — so stay tuned!

For the first time I think I understood what the DWR really does and how it can improve your development.

However, I’m curious what will happen if the boundary of the service layer is an EJB. The EJB container is responsible for creation of the EJB’s and the EJB support for DWR doesn’t seem to be stable yet.
What about the CDI and its scopes? Perhaps the @Produces CDI method and scope = static in DWR will do the work?

What is the place of DWR in JSF and managed beans world? What about the JSF managed beans scopes and DWR scopes – how do they comply?

There are a lot of questions I don’t know answer at this point. Nevertheless, I think it’s just a regular matter of picking the right tool to do the job.

Profiling, instrumentation or method measuring are great examples of cross-cutting concerns that might be nicely solved using AOP (Aspect Oriented Programming.) Basically, it allows you to invoke a certain action upon some defined conditions without the need for changing the instrumented code. The process of applying the aspects to your code is called weaving.
There are three types of weaving (not every AOP implementation must support all of them):

1. source code weaving (the aspect is applied to the inspected source code before the compilation),
2. byte code weaving (the aspect is applied to the compiled, .class file),
3. runtime weaving (the aspect is applied to the running, live application within the JVM).

As a side note, you can create your own simple runtime weaving AOP tool by using Java Agents that are invoked before any other written source code method (in the matter of fact, agent methods are invoked even before the static void main(String[] args) method of your Java class.)

Table of contents

1. What is the BTrace?
2. How Can I Use it?
3. Exemplary Source Code to be Instrumented
4. Why the WeakReference?
5. Exemplary BTrace Script
6. Ways of Getting the Results
7. Invoking the Script
8. JStat Counter Access
9. MBeans Access
10. Weak References and Garbage Collection
11. Strong References and Garbage Collection
12. Overhead
13. Summary

What is the BTrace?

One of the interesting tools for instrumenting your running applications is BTrace. It is a non-intrusive, read-only Java tool that allows you to create a script (compilable Java source code) that will be used to define probes and to monitor your running application (which I think is the same as the AOP runtime weaving).

The big advantage of runtime weaving is that you are not forced to recompile the source code you want to instrument nor to have to stop it. You can just plug into already executed application and start monitoring it right away.

How Can I Use it?

Firstly, you need to execute your Java application that you want to monitor (well, there is a way to start an application and tracing at the same time, but you’ll need to read details on the BTrace website.) BTrace can be used in one of three ways:

1. You can write the BTrace script and use btrace utility (it comes with the BTrace distribution) to apply your script to the running application,
2. You can write the BTrace script and compile it using BTrace provided compiler,
3. You can dynamically apply the BTrace script using the VisualVM.

I’ll focus on the third option, as in my opinion it seems to be the easiest and fastest. Nevertheless, one command that might be very useful for you despite the chosen method is the jps. It allows you to show what Java processes are currently running. The PID showed in the output will be useful in some of the further commands.

Exemplary Source Code to be Instrumented

At Github you can find an exemplary application that will be instrumented by the BTrace and discussed in the rest of this article. The source code should be pretty straightforward. The purpose of this application is very simple – it is supposed to simulate a cache access. The whole application consists of three classes:

• Data.java this is the data that will be stored in the cache; users will try to fetch it using the key which is a randomly generated integer number from range <0, 100):

• DataAccessor.java is the main logic of the application. It stores a cache (map of weak references to Data objects) and allows clients to access its getData(-) method.

If the requested data is in the cache, it is retrieved and returned to the caller.
If it’s not in the cache, a new data is created, stored in the cache and returned to the caller:

• Executor.java is the entry point for this application. It’s simulating a few hundreds data read access events, sleeping for a random time (0 – 1000 msec) between the requests:

Why the WeakReference?

Take a look at the DataAccessor‘s cache – it’s stored in:

Map<String, WeakReference<Data>> cache =
       new HashMap<String, WeakReference<Data>>();

The weak references are good for caching purposes as they are eligible for collecting by GC despite the fact they are still accessible from the map instance.
Note that the WeakHashMap wouldn’t be a good candidate for this purpose as it makes a weak references to the map keys, not values in which we’re interested in.

If you want to learn more about strong, soft, weak and phantom references please refer to Ethan Nicholas’s article.

Exemplary BTrace Script

Below you can find an exemplary BTrace script that will be used to instrument the previously presented source code / cache access. Some of the information is provided in the comments to the script code. You can create and edit the BTrace script in your IDE – just be sure that you have btrace-boot.jar on your classpath to be able to use the annotations like @OnMethod, @Property and so on.

Beware that you are not allowed to use any non-BTrace methods nor to create new objects within the BTrace methods. The point is to guarantee that the script is read-only and as non-intrusive as possible, therefore you are not allowed to do e.g. String concatenations. You must use only methods from the BTraceUtils class that can provide you e.g. mentioned string concatenation, comparisons, aggregation, parsing methods, etc.

All information about different probes locations as well as the requirements for the BTrace script methods and fields can be found here, so I won’t duplicate it.

However, I’ll try to explain what does the @OnMethod really do as it was quite unclear for me when I was writing the script.

Basically, all @OnMethod annotations define places where probes should be applied to the source code. The @Location allows you to further narrow the probe location. So:

@OnMethod(clazz = "com.piotrnowicki.btrace.DataAccessor",
          method = "getData",
          location = @Location(Kind.RETURN))
public static void addMethodDuration(@Duration long duration) {...}

means that when the control will return from the DataAccessor#getData(-) method’s body, the probe will be activated (body of the addMethodDuration method will be invoked.)
The Kind.Return is required when you want to use @Duration annotated argument. It’s quite reasonable – if you want to know how long did the method body take, you need to probe just before the return statement.

@OnMethod(clazz = "com.piotrnowicki.btrace.DataAccessor",
          method = "getData",
          location = @Location(value = Kind.CALL,
                               clazz = "java.lang.ref.WeakReference",
                               method = "get"))
public static void cacheCheckHit(
                @TargetMethodOrField(fqn = true) String method) {...}

means that we want to set a probe in DataAccessor#getData(-) method (clazz and method attributes) but we’re interested only in calls to the WeakReference#get(-) from within the DataAccessor#getData(-) method (location attribute). Only when such call is made, the probe will be activated.

@OnMethod(clazz = "com.piotrnowicki.btrace.DataAccessor",
          method = "/.*/",
          location = @Location(value = Kind.ENTRY))
public static void dataAccessorMethodEntry(
                             @ProbeClassName String className,
                             @ProbeMethodName String probeMethod,
                             AnyType[] args) {...}

means that we want to set a probe in any method within the DataAccessor class (clazz and method attributes) but we’re interested only in dependent methods entry events (location.)

@OnMethod(clazz = "com.piotrnowicki.btrace.DataAccessor",
          method = "getData",
          location = @Location(value = Kind.NEW,
                             clazz = "com.piotrnowicki.btrace.Data"))
public static void dataCreated() {...}

means that we want to set a probe in DataAccessor#getData(-) method (clazz and method attributes) but the probe will be activated only upon instantiation of the Data objects within this method (location.)

Ways of Getting the Results

There are a couple of ways to get the results back from your probes. You can either:

1. print it to the output using print(-) methods: println(Strings.strcat(“Entered method: “, probeMethod));

2. export the value to the jstat counter using @Export annotation on the field level: @Export private static long dataAccessed

3. export it to the MBeans server using @Property on the field level: @Property private static long dataCreated;

I personally like the third option the most because it allows me to easily view the value of the variable from the VisualVM as well as show plotted historical values of it.
The first option, however, is the fastest as you can see the results on your screen just after you hit the “Start” button.

Invoking the Script

If the application you will instrument is already running, you can run the VisualVM ($JAVA_HOME/bin/jvisualvm on the linux boxes) and find your application on the left hand side list. Double click it to inspect it (if you have never used the VisualVM – it’s a good time to see what information about running processes it provides.)
At this moment, the BTrace tab might not be visible as you probably need to install the appropriate plugin. Just go to Tools->Plugins->Available Plugins and install the BTrace one.

Now if you once again open your application in VisualVM, the BTrace tab might still not be visible. If so, then you need to RMB click the application on the left hand side list and select “Trace application…” option as shown below:

The BTrace tab should be shown – choose it and you can type your BTrace script directly on the shown form. Just hit “Start” and your script will be weaved into the selected application.
Personally, I’d advise you to use the Open... button and select the BTrace script on your disk. In this way, every time you’ll edit the script source file, click “Trace application…” and proceed to the BTrace tab, the actual version of your script will be loaded.

If you’ve selected my exemplary application to be instrument and the provided BTrace script provided, just hit the “Start” button and the monitoring will start. You should see a bunch of information in the output window (“entry points” and “cache hits” messages) as shown in the below screenshot:

Note that one of the probe actions gathers the duration of the method execution and aggregates it using Aggregation class. I’m using the aggregated values in a AVERAGE mode, so every 10 seconds, it’s printing the average method duration on the screen.

JStat Counter Access

Besides the console output, you can observe the probe results of three other variables. One of them, dataAccessed, is exported as a jstat counter and can be accessed from a command line. For the provided example, type jps and locate your monitored application PID. Then type:

jstat -J-Djstat.showUnsupported=true \
   -name btrace.com.piotrnowicki.btrace.MyClass.dataAccessed 14207

Of course replacing the 14207 with the PID you’ve read from the previous command. The -Djstat.showUnsupported=true is required to show your own defined counters.
Note that the name of the counter is not just the fully qualified name of the field – it’s prefixed with the btrace.

There is another way you can access the counter:

jstat -J-Djstat.showUnsupported=true -snap 1420

which will show you all counters for a given PID. You can further narrow the results using regular shell commands, e.g.:

jstat -J-Djstat.showUnsupported=true -snap 14207|grep dataAccessed

the result should recall something like this:

btrace.com.piotrnowicki.btrace.MyClass.dataAccessed=189

MBeans Access

There are also two fields that are accessible through the MBeans server. Simply click on the MBeans tab in the VisualVM and expand the com.piotrnowicki.btrace.MyClass. You should see two properties: dataCreated and cacheChecked. After double-clicking on the value you can see a timeline – a historical values of the counter value plotted on the graph.
If you’ve executed my source code and BTrace script, try to inspect the dataCreated value. You should see something like on the screen below:

Weak References and Garbage Collection

The above results actually depends on your JVM settings, but the point is: we create a random integer number from the range <0, 100) as a key for our cached data.
If this key exists in the cache, we retrieve the data it holds and return.
If this key doesn’t exist in the cache, we create the data, save it in cache and return it.

So, basically, the above counter is not measuring cache hits but cache misses (every cache miss is followed by instantiation of the Data object and its insertion to the cache.)
After some time, we should have more and more hits to the cache, therefore less data should be created. You might expect that the Y axis value will finally get to the 100 and stay there till the application ends.

It’s true, but only if we’d use strong references. In the exemplary code I’ve used WeakReferences as discussed before. This means that we can observe more than 100 objects created, because after some time, the GC decides to move in and clear some of all our Data instances. It happens because they’re referenced only from the single point of the process and this only reference is weak.
This is what you can observe on the following screenshot:

Notice the point where the value of dataCreated is fairly constant; it means that almost no new Data is created, so we have many cache hits. Take a look at the memory consumption at the same point of time.

When the GC is cleaning up the memory, Data instances are garbage collected and we need to refill our cache (so we need to create a new Data objects). At the same point of time, we’ve got huge increase of dataCreated value.
You don’t have to wait for automatic GC but you can try hitting the “Perform GC” button in the “Monitor” tab to send a request for GC to be executed.

Strong References and Garbage Collection

Now, if we try to change the WeakReference to the strong reference and adjust the code so it works on Data instead of WeakReference<data> the results will look like this:

Note that we’re trying to reach a 100 created Data objects and we’re not going any further than this number. We’ve got many cache hits and this time, we’re not affected by the Garbage Collector actions (but they do occur as you can see in the graph.)
Don’t take the cacheChecked value under consideration at this point. This property is probed only when weak references are used.

Overhead

The overhead of BTrace script should be minimal and that is one of the most important part of the project. It should be as non-intrusive and safe as possible. However, if you’re using e.g. the @Property annotation, you need to access the MBeans server so this is some additional overhead.

If you use massive print statements, string concatenations, aggregations in your probe actions – it also doesn’t come without a cost. Notice that there is also an “Unsafe” checkbox in the BTrace tab. If you check it, you’re all by yourself and there are many ways you can harm the performance and yourself.

Summary

The BTrace seems to be nice, fast and easy way to access and instrument your running Java application. It doesn’t require you to use any special tools — you can monitor every process on the JVM and thanks to the VisualVM plugin – you can change the script on-the-fly.
It’s not the ultimate tool for Java monitoring. You might as well use other solutions already built in in your servlet container (like psi-probe) or application server (like SpringSource Insight).
Nevertheless, it’s a nice, low-level solution for monitoring any running Java application and it doesn’t require your source code to be executed in any specialized environment.

“there is only one instance of servlet per application”.

Surely it gives you some information and knowing this will save you from a lot of strange, unexpected errors. However, the above statement is not very accurate and precise. It’s useful to know what is the actual contract between the web container and developer.
Moreover, a lot of questions arise because of the multi-threading issues, so let me sum this up backing my words with Servlet 3.0 Maintenance Release specification:

Assuming we’re working in a non-distributed environment, there is only one servlet instance per definition:

2.2 Number of Instances

For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration.

So, it’s not allowed for the container to pool servlet instances. There is a strict requirement that there is only one instance per definition. This per definition part is also important because if you define two servlets with different names but referring to the same class, you’ll end with different instances of this servlet:

<servlet>
    <servlet-name>servlet1</servlet-name>
    <servlet-class>com.myservlet.MyServlet</servlet-class>
</servlet>

<servlet>
    <servlet-name>servlet2</servlet-namesss>
    <servlet-class>com.myservlet.MyServlet</servlet-class>
</servlet>

However, the number of servlet instances can also be affected by implementing deprecated SingleThreadModel. This interface is supposed to ensure that only one Thread can access the Servlet at a given time. Therefore, it might do so by serializing requests or by pooling multiple servlet instances:

2.2 Number of Instances

However, for a servlet implementing the SingleThreadModel interface, the servlet container may instantiate multiple instances to handle a heavy request load and serialize requests to a particular instance.

Finally, if you mark your web application as a distributed application (<distributable /> sub-element of the <web-app> in web.xml) and you will implement depreciated SingleThreadModel than you can end with a pool of servlet instances per definition in each of the JVM of your distributed environment:

2.2 Number of Instances

However, if the servlet in a distributable application implements the SingleThreadModel interface, the container may instantiate multiple instances of that servlet in each JVM of the container.

As you can see the answer “there is only one servlet instance” is not very precise. It gives you an important information regarding multi-threading, but it’s not 100% complete and precise.

The solution is to disable hardware acceleration in Flash Player settings (RMB -> Settings) just as shown here:

After unchecking this option and refreshing the page all videos were back to normal:

I’m not sure if I even want to know why one update could mess up so bad with the Flash Player. In fact, I’m pretty sure that the Flash Player is one of the best way to crash your Ubuntu box. In fact on my Dell Vostro 3555 it randomly restarts the X Window Server… sigh.

Nevertheless, the world has been saved one more time.

So, some time ago I started to use a Hamcrest matcher library. It was a great progress, as I was able to move away from JUnit’s unintuitive: assertEquals(11.0, actual). I mean, if you try to read it out loud it doesn’t seem very logical:
“assert equals 11 is actual“,
“assert equals 11 as actual“?.

Moreover, the expected value is the first argument and the actual one is the latter which also makes it harder to understand.

And here comes the *Hamcrest* matcher which brings a fluent API consisting of a lot of useful methods. So, right now you can write: assertThat(actual, is(11.0)). This is much more readable as it stands for:
“Assert that actual is 11.0″.
No magic here, everything is understandable and you don’t have to think which parameter is the expected and which is the actual one.

FEST Fluent Assertions brings very similar features to the table but it takes quite different approach.
In Hamcrest you usually use the one-line per one assert approach. It means that if you want to check if myVal is in range between 4 and 6, you would need to write two assertions (sure, you can always write your own matcher that will do it in one line, but that’s not the point in this case):

assertThat(myVal, is(greaterThan(4));
assertThat(myVal, is(lessThan(6));

FEST Fluent Assertions uses the chain method invocation to do the same thing, so in FEST-like approach you’d rather write:

assertThat(myVal).isGreaterThan(4).isLessThan(6);

You can still read it very naturally and it saved some writing.

There are some more differences between Hamcrest and FEST Fluent Assertions. Some of them are more important, like differences in writing your own matchers and/or conditions.
Others are less important, like the number of static imports: lots in Hamcrest, only one in FEST Fluent Assertions. However, this Hamcrest‘s disadvantage, can be easily solved using type import static or using the Eclipse support as described in my previous post

There is no, obvious choice between Hamcrest and FEST Fluent Assertions. Both of them give you a very nice and elastic fluent assertions mechanism and which one you choose depends on team, your programming habits or some particular requirements. Either it will be Hamcrest or FEST Fluent Assertions, it will definitely be better than the assertions that come out-of-the-box with JUnit.

I think that the most important fact here is that you really should use easy to read matchers library. It makes not only the code more obvious for your team, easier to maintain (it’s worth emphasizing that your test code is also a part of your project – it needs to be maintained!) but in some situations it even allows you to show some test cases to the business people with the domain knowledge you need. It allows to reduce domain understanding problems.
Moving even further, if you plan to use Scala (or any other JVM language which allows you to omit spaces or parentheses in method invocations), your code can be much more like a DSL (Domain Specific Language): assertThat actual isEqualTo 11.0. It’s really worth trying it out.

You can read about differences between Hamcrest and FEST Fluent Assertions in more details on Sam Lewis’ blog.

So, instead you do a static import which is available since Java 5:

import static org.hamcrest.Matchers.*;

Ok, you needed to type it by yourself, but still, now you can use just hasEntry() and everything works smoothly! But then, after some time, you do the Organize import magic (ctrl + shift + o) which automatically replaces your wildcard import static with concrete import static members, so you end up with:

import static org.hamcrest.Matchers.hasEntry;

Later on, if you want to use another matcher, e.g. notNullValue() you need once again type the import statement by yourself. That’s ugly, time waste manufacture which we should get rid off!

Luckily, there is an Eclipse setting which allows you to add some specific static members or whole types into the regular content assist (ctrl + space) without writing any import statement by yourself.
To set this, just go to: Window -> Preferences and then under Java -> Editor -> Content Assist -> Favorites add a Type (all static members within the given type will be added) or Member (just the particular static will be added):

From now on, all defined members and types will be available when you hit the ctrl + space. Organize imports will never again be your enemy! ;-)

So, either you know nothing about Git or you already know something and just want to summarize your knowledge – I would highly recommend you to spend this 1,5 h on watching this video.

By the way, in this video Scott showed pretty nice feature of aliasing. Despite that sometimes it might be confusing for others what magic is your alias doing, it can be very helpful in some cases (e.g. to save you some time typing long commands):

git config --global alias.lol "log --oneline --graph --decorate"

This command creates a lol alias for git, so invoking git lol will invoke the above log ... command.

The Git learning curve is steep, but after working with it for just a few days – I already like it :-)

But, back to my point. Recently I’ve stumbled upon a problem with commiting an empty directory in Git. If the directory consists of some files and you stage those files, the directory will be commited automatically. However, if the directory is empty, you cannot commit it.

It’s very reasonable way of thinking, but it also creates a few problems e.g. with Eclipse which requires you to use some Maven defined directories (src/test, src/java, etc.). More precisely, if you don’t have e.g. src/test/resources directory, it will throw an ugly project-wide error at your face.

The solution, can be found on StackOverflow, so basically all you need to do is provide a .gitignore file which forbids content other than the .gitignore file itself. However, in my case I ended up with putting a README file which describes why it’s there and that it should be removed as first real resource will be uploaded.
I found it more informative for other team members than an empty .gitignore file.

The method …… must override a superclass method.

If this error is shown in the line when you have your interface method implementation with @Override annotation, it most probably means that you’re using JDK 5 instead of JDK 6.

In Java 5, the @Override annotation might be applied only to the methods overriding superclass ones. Since Java 6 you can use the @Override annotation also with the methods that implements the interface ones.

Therefore, if you see such error, either change the JDK to JDK 6 (i.e. check your Eclipse workspace or project preferences) or, if you need to be compatible with JDK 5, remove the @Override annotations from interface implementation methods.

Simple thing but it might make you swear ;-)