Java

Talk On Tech now Molindo Techblog

Talk On Tech (talk-on-tech.blogspot.com – the tech blog you truly love, don’t you?) was our nice, green home since August 2007. Now, after 1.5 years it was time to move on … Well, okay, we just want to consolidate all our blogs on a single self-hosted platform. In the course of doing that, we also changed the name from Talk on Tech (Let’s create a blog! How do we name it? What about “Talk on Tech”? Yeah, that name is free!) to Molindo Techblog (where Molindo is the name of our very own startup).

If it comes to new posts, We have a lot of ideas but not enough time to elaborate them all. Some ideas are:
Read the rest of this entry »


Wicket: A Neat Url Encoding Strategy and some basic SEO

After a year of working extensively with Apache Wicket I want to share some stuff I’ve been using over and over again and might be useful for you as well. In this first post it’s a custom URL Encoding Strategy and some related basic SEO.

Pages often depend on entities – e.g. a Customer or a product and as those pages should be bookmarkable as well, there has to be a unique way to tell the page which entity to use. As entities either don’t have unique names or one wants to avoid having an (database) index over the name column, the index-ID is for most applications the way to go. As it’s usually undesireable to expose the database ID of an entity in the URL, it has to be encoded and decoded somehow to get from myshop.com/customer/12 to myshop.com/customer/ea34cff … or something like that.
Read the rest of this entry »


Java: Map sorted by value

Today, I wanted to solve a – at first sight – rather simple problem in Java. I wanted to iterate over the keys and values of a Map in an order given by its values. E.g.

Map m = new ...
m.put("foo", 47);
m.put("bar", 11);
m.put("baz", 11);
m.put("qux", 100);
// {bar=11, baz=11, foo=47, qux=100}
System.out.println(m);
 
m.put("foo", 101);
// {bar=11, baz=11, qux=100, foo=101}
System.out.println(m);

Read the rest of this entry »


Spotting duplicate classes in Jar files

After more than a month it’s time for another post. Sorry to all of you for keeping you waiting … well, honestly I don’t think somebody even noticed :)

Today, I stumbled upon a classpath related problem – once again. As I doubt that I am the only one to ever face this problem, I want to share a short shell script that came to the rescue.

But first, what was the problem? After adding some additional dependencies to our POM – quite carelessly I have to admit – our application started sending mails without subject, sender address and messed up special characters. Interestingly enough, I didn’t touch the mail part at all. I added Apache CXF dependencies, i.e. web service stuff. So what was wrong?
Read the rest of this entry »


Wicket: Loose Coupling of Componens for Ajax Updates

While developing Wicket applications, one often has to write a simple input form (e.g. a search box) that updates the content of another panel (e.g. a search result panel). And of course, we all use Wicket’s AJAX support to search as it is so damn cool and easy to use.

Normally, you do this by either putting everything on one panel or by passing a reference of the list panel to the form panel.

public SearchBoxPanel(String id, SearchResultPanel results) {
_results = results;
// snip
}
 
public void onSubmit(AjaxRequestTarget target) {
_results.setQuery(getQuery()); // or use the same model ;)
target.add(_results);
}

Read the rest of this entry »


Wicket Interface Speed-Up: Merging Resources for Fewer HTTP Requests

This entry is part of my “Wicket Interface Speed-Up” series.

Now that I spent some time on configuring client-side caching and resource versioning for aggressive caching, I am going to finalize this series with an article on merging of resources and some code that you can easily use right away to speed-up your own applications in minutes.
Read the rest of this entry »


Wicket Interface Speed-Up: Caching Resources Forever

This entry is part of my “Wicket Interface Speed-Up” series.

In my last post, I explained how to change (i.e. increase) the time a client should cache resources like JavaScript and CSS files served by a Wicket application. In this post, I’ll show you how to cache resources for a year. Caching for a year is close enough to forever and a recommendation by W3C:

“To mark a response as “never expires,” an origin server sends an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in the future.”

Read the rest of this entry »


Wicket Interface Speed-Up: Modifying Expires and Cache-Control Headers

This entry is part of my “Wicket Interface Speed-Up” series.

Let’s start with a short introduction before we talk about setting Expires and Cache-Control HTTP-Headers:

By default, all WebResources are cacheable for one hour, which is defined by WebResource.getCacheDuration():
Read the rest of this entry »


Wicket Interface Speed-Up

After reading Matt Raible’s thoughts on [OSCON 2008] Even Faster Web Sites by Steve Souders I decided to look into the topic myself. I knew that one bigger project built with Wicket was reported to be slow. However, I always made the mistake to look into server-side performance as client-side performance never was an obvious problem – well, estimating client-side performance on my Quadcore/4G RAM/Ubuntu workstation with broadband connection admittedly wasn’t very representative ;)

According to Souders, “80-90% of the end-user response time is spent on the frontend”. This obviously makes potential performance improvements of (quite insane) 20% on the server a drop in a bucket. Therefore, I decided to make interface performance tuning a top priority in my work queue and looked thoroughly into it.
Read the rest of this entry »


A Custom reuseable LoadableDetachableModel for Spring/Hibernate

the annoyance


org.hibernate.LazyInitializationException - could not initialize proxy - the owning Session was closed
org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed

the problem

Generally, detached objects in Hibernate are a bad thing when it comes to reusing objects between web-requests. Detached objects are objects that have been persistent but are not attached to a Hibernate session. They’re easily produced but can be a mess if it comes to Lazy-Loading or updating them. Just consider the following case


Foo foo = _myDAO.getFoo(); // attached object

add(new Link("fooLink", new Model(foo)) {

  protected void onClick() {
    Foo foo = (Foo) getModelObject(); // now it's detached as this is called in the next request
    Bar bar = foo.getBar(); // possible lazy-loading exception if bar gets loaded lazily

  }
}

the solution

First be sure to use the OpenSessionInViewFilter sothat a new hibernate session is opened when the request gets attached and closed when it gets detached.

Then the solution of course is a to use a LoadableDetachableModel that gets a fresh instance from the persistence-layer on each request. Could look like that:


IModel fooModel = new LoadableDetachableModel() {

  protected Object load() {
    return _myDAO.getFoo();
  }
}

add(new Link("fooLink", fooModel) {

  protected void onClick() {
    Foo foo = (Foo) getModelObject(); // attached as LDM has loaded a fresh instance
    Bar bar = foo.getBar(); // no lazy loading exception as still attached

  }
}

the improvement

LoadableDetachableModels are a nice thing but it’s quite a lot of work to inject your DAO (or service) and then create a new LDM for each of your objects in each and every one of your panels. so we came up with a more generic version of the LoadableDetachableModel. First, let your model-objects implement an Interface, say IPersistentObject with the single method


  Serializable getId();

As your object are likely to have a primary key named id it’ll be no problem anyway. Then create the following class:


public class PersistentObjectModel extends LoadableDetachableModel {

  private static final long serialVersionUID = 1L;

  private final Class _clazz;

  private final Serializable _id;

  @SpringBean(name = "myDao")
  private IMyDao _myDao;

  @SuppressWarnings("unchecked")
  public PersistentObjectModel(final T object) {
    super(object);

// object may be a hibernate proxy, so get the actual class
    if (object instanceof HibernateProxy) {
      _clazz = (Class) ((HibernateProxy) object).getHibernateLazyInitializer()
.getImplementation().getClass();
    } else {
      _clazz = (Class) object.getClass();
    }
    _id = object.getId();
    // inject the bean
    InjectorHolder.getInjector().inject(this);
  }

  public PersistentObjectModel(final Class clazz, final Serializable id) {
    clazz = clazz;
    _id = id;
    // inject the bean
    InjectorHolder.getInjector().inject(this);
  }

  @Override
  protected T load() {
    // the DAO then simply passes the params to hibernate (or spring's hibernatetemplate
    return _myDao.getById(_clazz, _id);
  }

  @SuppressWarnings("unchecked")
  @Override
  public T getObject() {
    return (T) super.getObject();
  }

}

This makes working with hibernate objects really easy. There are two options:

  1. Use the object e.g.

    setModel(new PersistentObjectModel(foo));

  2. Use only class and id.

    This might happen e.g. if you pass your id using PageParameters (but better encrypt it ;-) )
    setModel(new PersistentObjectModel(Foo.class, 1));

Hope that saved you some time writing boilerplate code ;-) have fun