A few weeks ago I attended the Sun Tech Days in Sydney. I was pretty impressed with the breakfast they provided. In fact, all the food was great. The whole place had a really geeky feel to it, and I really liked that too. However, the presentations left me feeling that the whole thing was a waste of time. To be fair, some of the presentations were good. It was excellent to hear James Gosling. But the majority of the presentations I went to were terrible.

I don't think my standards are too high in having this gripe, at one level, Sun provided me with free food and a day where I could mix with like minded people, I shouldn't be complaining. But it just frustrated me so much because Sun could have done so much more for not only me, but also themselves at this event. The whole event is one gigantic sales pitch, and I'm ok with that. I want Sun to get me excited about their products, I want Sun to get me excited about Java development, I want Sun to pitch their best sales pitch at me, do their best to make me want to drop everything that is not Sun, and follow them. Not that I would necessarily do that, but I at least want Sun to sell themselves to me if I go to an event like this. But I think they failed to do that. I'm going to use one particular session, the session on JPA, as an example of how they missed the mark, but most of the sessions I felt were the same.

My expectations from the JPA session were that Sun would sell me JPA. I love Hibernate, I use it for all my database access, I know how it works intimately, and I am very quick to recommend it as the best tool for ORM to every man and his dog. The big problem for me is that part of my reason for loving it is based in my ignorance, I've only briefly touched JPA, and I've never used Toplink or JDO, they could all be miles ahead of Hibernate, but I wouldn't know. This is why I went to JPA session. I wanted to be given reasons why I should try it, I wanted to be given insights into the future of JPA that will make it the best ORM API to use. So when the session ended up being JPA101 - This is how to map an entity with annotations, this is how to do inheritance, this is how to write a query in JPAQL, you can imagine my disappointment.

I'm not sure who Sun is expecting to come to their tech days. But I'll take a guess at the sort of people that do come. For a start, they are people that take an interest in modern Java frameworks, if they weren't, they wouldn't be at the days. They are developers, if they aren't developers then they definitely wouldn't be interested in JPA101 anyway. And they're people that take the initiative to do research and learn about new technologies themselves, otherwise they wouldn't have found out about the tech days to start with. So, I would expect the people described above to have all had experience with at least one of the leading ORM tools. A JPA101 would have been way too simple for almost the entire audience.

In want of more meat on JPA, I asked a question about the future of JPA. "Is it likely that in the future JPA will support collections of basic types, eg Strings, Integers, Dates?". I was shocked by the presenters response. It wasn't that he didn't know the answer to the question, he didn't understand the question. After asking me to repeat the question, he said "well, it does support it". I said no it doesn't, and someone else in the audience piped up and agreed with me, adding that you could map collections of basic types using TopLink or Hibernate extensions. To which the presenter replied "there's your answer". The presenter had no idea. Anyone with real world experience in an ORM tool would have encountered a time when they would have wanted a collection of basic types, and an expert in JPA would know that JPA doesn't support this. I wanted to know why it doesn't support it, maybe there's a good reason, maybe they felt there were difficulties in how to specify it and so left it for the next release. This guy clearly was not an expert in JPA, and clearly had never used JPA in the real world. I doubt if he had any experience beyond learning enough to give the presentation, it's likely that someone else wrote the presentation and he just went off that persons notes.

So I was very disappointed overall with the Sun Tech Days. It was marketed at professionals, but most of the sessions were targeted at newbies. I hope there's someone at Sun that understands JPA, if they can't get that person to give a presentation, maybe they should look into getting local respected industry professionals to give the presentations, that would be a lot more helpful. Until Sun does that, I don't think I'll return.

If you're a web developer who likes writing practical, quick, and simple utility applications for yourself and others to use, then Facebook is the dream platform. You don't have to write any user management, sign in, password change pages etc, it comes complete with advanced user management, including friends lists. There's a high chance that your target users already use it, which makes them more likely to adopt your application because they don't need to go and create yet another username/password on yet another website. It already has a theme and style sheets, and will present your application surrounded in menus and title bars. And it provides a large number of ways to publish content and send notifications when events occur. All these features mean that you, the developer, can spend more time doing what you wanted to do, that is, writing your application.

If Java is your chosen platform however, you may encounter some difficulties. Java developers tend to like following well established design patterns. We like to think of things as beans that have distinct purposes. We like to use frameworks such as Spring to manage the beans that contain logic, to glue our application together. We like our data to be stored in beans, and we access that data using getters and setters. The Facebook client API makes this difficult, for the following reasons:

1. Its instantiation is dependent on parameters in an HTTP request. This means we can't use it as a typical Spring bean.
2. Depending on which flavour you of client you use, it returns JSON objects, or DOM documents, not the Java beans we like to use.

This article will address the first issue, and in doing so make the second issue less of a worry.

Instantiation of the client

Our first task is to gracefully handle the instantiation of the Facebook client. This will usually be required by most requests, hence, it is an ideal opportunity to use a ServletFilter. The guys at TheLiveWeb have already provided a very good article on how to do this, so I won't go into too much detail. The servlet filter basically intercepts every request, checks to see if there is already a client in the session, and if not, uses the fb_session parameter if it's an embedded fbml app, or auth_token parameter if it's not an fbml app, to instantiate the client. If neither of those parameters exist, it redirects the user to the login page. The ServletFilter I've written is very different to theirs, but both follow the same concept and achieve the same goal.

Using a ThreadLocal to access the client

Our next task is to make the client available to the backend service beans that have no knowledge of the HTTP session. We do this using a ThreadLocal. We start by creating a wrapper class, UserClientBean, to wrap all calls to the client. The client itself is stored in a private static ThreadLocal field:

public class UserClientBean
{
    public static void setClient(FacebookXmlRestClient aClient)
    {
        client.set(aClient);
    }
    public static void remove()
    {
        client.remove();
    }
    private static final ThreadLocal client
        = new ThreadLocal();
    ...
}

So calling UserClientBean.set() will bind a facebook client to the current thread, and UserClientBean.remove() will remove it. We make these calls from the servlet filter:

public void doFilter(ServletRequest aRequest, ServletResponse aResponse,
        FilterChain aChain) throws IOException, ServletException
{
    if (aRequest instanceof HttpServletRequest)
    {
        HttpServletRequest request = (HttpServletRequest) aRequest;
        HttpServletResponse response = (HttpServletResponse) aResponse;
        HttpSession session = request.getSession();
        FacebookXmlRestClient client = (FacebookXmlRestClient) session
                    .getAttribute("facebookClient");
        if (client == null)
        {
            String sessionKey = request
                    .getParameter(FacebookParam.SESSION_KEY.toString());
            String authToken = request.getParameter("auth_token");
            if (sessionKey == null && authToken == null)
            {
                response.sendRedirect(loginPage);
                return;
            }
            else
            {
                try
                {
                    if (sessionKey != null)
                    {
                        client = new FacebookXmlRestClient(apiKey, secret,
                                sessionKey);
                    }
                    else
                    {
                        client = new FacebookXmlRestClient(apiKey, secret);
                        client.auth_getSession(authToken);
                    }
                    client.setIsDesktop(false);
                    session.setAttribute("facebookClient", client);
                }
                catch (FacebookException fe)
                {
                    log.error("Unable to log into facebook", fe);
                }
            }
        }
        // Store the client in the thread
        UserClientBean.setClient(client);
    }
    aChain.doFilter(aRequest, aResponse);
    // Remove the client from the thread
    UserClientBean.remove();
}

If you've never come across ThreadLocal's before, a ThreadLocal is a class that binds the object passed to its set() method to the current thread. Calling the get() method will retrieve that object from the current thread, if it exists. ThreadLocal's are usually declared as static final, so that they can be accessed statically from anywhere in the application.

Using the client

Now that we can access the client as a service, we can add calls as desired to UserClientBean to run on the FaceBookRestClient, and extract the data out in a way that's nice to return to our application. For example:

public List getAppFriends()
{
    List result = new ArrayList();
    try
    {
        Document d = client.get().friends_getAppUsers();
        Node n = d.getFirstChild();
        while (n != null)
        {
            result.add(Long.parseLong(n.getTextContent()));
            n = n.getNextSibling();
        }
    }
    catch (Exception e)
    {
        log.error("Error retrieving logged in facebook user", e);
    }
    return result;
}

public boolean isFriend(long aFriendId)
{
    try
    {
        FacebookXmlRestClient c = client.get();
        long user = c.users_getLoggedInUser();
        if (user == aFriendId)
        {
            return true;
        }
        else
        {
            Document d = c.friends_areFriends((int) user, (int) aFriendId);
            Node n = d.getElementsByTagName("are_friends").item(0);
            if (n.getTextContent().equals("1"))
            {
                return true;
            }
        }
        return false;
    }
    catch (Exception e)
    {
        log.error("Error determining if users are friends", e);
        return false;
    }
}

As you may have noticed, the FaceBookRestClient uses ints, while Facebook recommends user ids being stored as longs. Not very smart huh? At least using this client, our apps will be ready for that bug fix.

Welcome to my new blog. This blog is going to contain everything from personal posts about my life (which probably won't interest many people) to technical articles about Java, and related Java frameworks.

My trip is now starting to come to an end. After my last blog entry, I spent a night in Mai Sai, took a bus to Chiang Rai, and then stayed there the night. Chiang Rai was kinda boring, I got a 2 hour massage, and then wandered around for a while. The night markets were good though, I bought a few last pressies for various people. One big thing I've noticed is the further north you go in Thailand, the less and less English you see. In Bangkok, everything's in English and Thai. But, there were hardly any English signs in Chiang Rai or Mai Sai. There is also a much larger population of Chinese in the north, a lot of the markets have chinese food in them, and a lot of the restaurants, particularly the more western ones, are owned by Chinese.

The next day we took the bus to Chiang Mai, where I had one last walk around, had lunch, and sat in a cafe reading the paper, before we took the overnight train to Bangkok. There were hardly any people on the train, compared to our first train ride which was full. So, there was nothing really much to do and I got an early night at 7pm. The train arrived in Bangkok at 6am, where I took a taxi back to the Khao San Road, and checked into a hotel. So now I'm here, and I'm waiting for everything to open before I go out and explore. I think I'll take a river boat ride again, seeing as I missed out on my last one.

Tomorrow I'll be departing from the new international airport in Bangkok. It is said to have the largest terminal in the world, and once all its extensions are finished, will be the biggest airport in the world, handling 100 million passengers a year. There have been big problems with its opening 2 days ago though. People were waiting for hours for their baggage, and apparently 200 items got sent to the wrong destination. The problem was due to the fact that they didn't transfer enough baggage wagons from the old airport to the new. There were also computer problems for Thai Airways, but seeing as I'm traveling with British Airways, that won't be a problem.

Haven't seen any tanks, or any soldiers for that matter, since coming into Bangkok. Maybe, just as the coup appeared overnight when I was on the train to Chiang May, disappeared overnight on the way to Bangkok. Or maybe it just never happened. Hopefully I can find some tanks today to have my picture taken with.

One of the best experiences I've had so far on this trip was doing a Thai cooking course. No one from my tour wanted to do it, instead I ended up doing it with an Intrepid group, there were 6 of us in all. We started off by going to the markets and buying most of the ingredients needed for what we were cooking. Our instructor explained to us what the different spices were, and showed us different vegies, and taught us how to recognise which ones were good and which weren't. We also saw them make coconut cream and coconut milk fresh for us.

At the cooking course, I made pad thai, thai spicy soup, green curry, and banana in coconut milk. The food was amazing, best Thai food I've had in Thailand! It was also incredibly quick to cook, I never realised it was so quick to make Thai food properly. When I get back to Australia I am definitely seeking out all the ingredients to make the food, it's almost as quick as unfreezing the frozen meals I usually make.