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 »
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 »
org.hibernate.LazyInitializationException - could not initialize proxy - the owning Session was closed
org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed
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
}
}
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
}
}
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:
setModel(new PersistentObjectModel(foo));
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
iSport.eu is a simple but hopefully useful website for people like me who spend several hours a week to get the latest football (American readers: feel free to replace the word ‘football’ with ‘soccer’) news from the major European leagues. iSport.eu is kind of an RSS reader, that adds some nice features (well, at least I like them):
While this tool currently is focused on football news, it could be used for everything that comes with a news feed.
Depending on the feedback, future enhancements could include:
iSport.eu is built on Java, Wicket, Spring, Hibernate, Derby, Jetty, Commons-Digester and about 10 days of manpower.
Wicket‘s RepeatingView is a very handy component: You can add as many components as you want. As a result, the usage of this component differs from other, as you don’t add components using html tags with a wicket:id attribute. Instead, IDs are generated by incrementing a number and convert it to a string. The RepeatingView even offers a nice helper method to generate those IDs. Basically, this method does nothing else than
public String newChildId() {
return Integer.toString(childIdCounter++);
}
But the folks behind Wicket seem to work more carefully than I do:
/**
* Generates a unique id string. This makes it easy to add items to be rendered w/out having to
* worry about generating unique id strings in your code.
*
* @return unique child id
*/
public String newChildId()
{
childIdCounter++;
if (childIdCounter == Long.MAX_VALUE)
{
// mmm yeah...like this will ever happen
throw new RuntimeException("generateChildId() out of space.");
}
// We prepend the id's with the text 'id' so they will generate valid
// markup id's if needed.
return String.valueOf(childIdCounter);
}
But does it really make sense to check whether Long.MAX_VALUE (263-1 or 9,223,372,036,854,775,808) was reached? The developer doesn’t believe so, but seems to work carefully … or overcautious? … or just paranoid? Well, let’s do the maths:
As already an empty string object has 40 bytes (x86 processor, Sun JVM), creating this number of empty strings would require more than 325.000 petabytes of memory.
But even if the objects are left for garbage collection, calling this method Long.MAX_VALUE times takes ages. I tested the same method with Integer.MAX_VALUE (231-1 or 2,147,483,647) on my Pentium M 1.86GHz and it took 14 minutes to hit the RuntimeException. As It would take 232 times longer to reach Long.MAX_VALUE, it would approximately take 114,401 years. Quite a long time to construct a web page, eh?
The Java Management Extensions (JMX) is perfect to build manageable applications without the need to create any administration frontend. Managed Beans (MBeans) are similar to regular Java Beans. Hibernate offers an MBean-wrapper around its Statistics API which is really interesting to optimize caching. Therefore, I was looking for a simple way to use JMX with Wicket. Fortunately, Wicket can also be managed with JMX. All it needs is to drop the wicket-jmx JAR on the classpath – no configuration needed! It is therefore sufficient to add wicket-jmx to the POM:
<dependency>
<groupid>org.apache.wicket</groupid>
<artifactid>wicket-jmx</artifactid>
<version>1.3.0-SNAPSHOT</version>
</dependency>
But Wicket (more precisely Wicketstuff) also contains a simple JMX client called wicketstuff-jmx-panel. Using this client is as simple as adding a single component to whatever Wicket-page:
POM:
<repository>
<id>wicket-stuff-repository</id>
<name>Wicket-Stuff Repository</name>
<url>http://www.wicketstuff.org/maven/repository</url>
</repository>
<!-- SNIP -->
<dependency>
<groupid>org.wicketstuff</groupid>
<artifactid>wicketstuff-jmx-panel</artifactid>
<version>1.3.0-SNAPSHOT</version>
</dependency>
Java:
add(new JmxPanel("jmx"));
However, documentation on this JMX panel is sparse. It took me some time to figure out the following: This panel filters all MBeans that do not have the Wicket-application’s name in their domain. This behaviour may be changed using an annonymous inner class:
add(new JmxPanel("jmx") {
protected IDomainFilter getDomainFilter() {
return DOMAIN_FILTER;
}
});
private static final IDomainFilter DOMAIN_FILTER = new IDomainFilter() {
private static final long serialVersionUID = 1L;
public boolean accept(String domain) {
// your filter code
return true;
}
};
It does make sense to filter out some MBeans as there are already some by default, e.g. for java.util.logging which you probably don’t use at all.
Now it’s time to add Hibernate’s statistics MBean. This MBean is can be used per SessionFactory. I therefore decided to do registration and unregistration together with SessionFactory creation. As I am also using Spring, I went for my own SessionFactoryBean:
public class MBeanRegisteringLocalSessionFactoryBean extends
org.springframework.orm.hibernate3.LocalSessionFactoryBean {
private String _sessionFactoryName;
private ObjectName _objectName;
private MBeanServer _mbeanServer;
@Override
protected void afterSessionFactoryCreation() throws Exception {
super.afterSessionFactoryCreation();
try {
// register JMX MBean
_objectName = new ObjectName("Hibernate:type=statistics,application="
+ getSessionFactoryName());
_mbeanServer = getMBeanServer();
final StatisticsService mBean = new StatisticsService();
mBean.setSessionFactory(getSessionFactory());
_mbeanServer.registerMBean(mBean, _objectName);
} catch (final Throwable t) {
log.warn("failed to register MBean for SessionFactory: " + _objectName, t);
_objectName = null;
_mbeanServer = null;
}
// if _objectName != null --> MBean was registered
}
@Override
protected void beforeSessionFactoryDestruction() {
if (_objectName != null) {
try {
_mbeanServer.unregisterMBean(_objectName);
} catch (final Throwable t) {
log.warn("failed to unregister MBean for SessionFactory: "
+ _objectName.getDomain());
}
}
}
/* SNIP: getMBeanServer(), getSessionFactoryName(), setSessionFactoryName(String) */
}
I copied (sorry, there is no nicer way yet) the code for getMBeanServer() from wicket-jmx’s Initializer class (sorry, can’t find an online version – you can get the source using Maven) in order to get the exact same behaviour. Now you only need to replace LocalSessionFactoryBean with MBeanRegisteringLocalSessionFactoryBean in your beans.xml and you are set. In order to enable statistics by default, add these two lines to your hibernate properties:
hibernate.generate_statistics=true
hibernate.cache.use_structured_entries=true
That’s it! Hibernate statistics directly from your webapp:
I now got to the point where I wanted to put some i18n into my DropDownChoices. What I found out pretty soon was that you need an IChoiceRenderer to customise your DropDownChoices. If you don’t use one, you’ll get by default short values and toString display names. E.g. the enum
enum { JOHN, PAUL, GEORGE, RINGO }
produces an output like that
<select name="beatles">
<option value="0">JOHN</option>
<option value="1">PAUL</option>
<option value="2">GEORGE</option>
<option value="3">RINGO</option>
</select>
But what I want is “John” instead of JOHN or “John Lennon, Rhythm Guitar” or anything but JOHN. On the mailinglist and in the wiki I discovered some complicated, overhead solutions using helper objects, so I decided to implement my own reusable enum-renderer that reads the display values from a properties file. All you have to do is to pass the Component that is responsible for the properties file.
public class EnumChoiceRenderer implements IChoiceRenderer {
private static final long serialVersionUID = 1L;
private final Component _resourceProvider;
public EnumChoiceRenderer(final Component resourceProvider) {
_resourceProvider = resourceProvider;
}
public Object getDisplayValue(final Object object) {
final Enum<?> v = (Enum<?>) object;
return _resourceProvider.getString(v.name());
}
public String getIdValue(final Object object, final int index) {
return Integer.toString(index);
}
}
Yeah that was quite easy, but maybe saves some of you the burdon of using helper-classes
Oh yes, the properties file looks something like that:
JOHN=John Lennon, Rhythm Guitar
PAUL=Paul McCartney, Bass
GEORGE=George Harrison, Lead Guitar
RINGO=Ringo Starr, Drums
what then produces the desired output:
<select name="beatles">
<option value="0">John Lennon, Rhythm Guitar</option>
<option value="1">Paul McCartney, Bass</option>
<option value="2">George Harrison, Lead Guitar</option>
<option value="3">Ringo Starr, Drums</option>
</select>
I’ve been fiddling around with reverse-ajax (or comet or pushlets) these days/weeks. You know, that stuff where the webserver keeps an open connection to the client and pushes new events to the client with just the transportation-delay – but no client interference. As described in my recent posts, I decided to use Apache Wicket for my webapp, so I looked around if there’s something in the wicketstuff project that fits my needs. And yes, there is the wicketstuff-push project that offers different implementations of server pushes. Xavier Hanin, one of the men behind Ivy, and Vincent Demay did great effort there to implement a timerbased PushImplementation and also a Cometd-based implementation of a event subscribe/publish mechanism. The latter uses an implementation of the Bayeux-spec and the Dojo-library together with wicketstuff-dojo to subscribe to channels and to process the pushes on client side.
Yesterday I took the time to have a closer look on how the Java implementation of the Bayeux protocol works and found out that each new client that subscribes to a channel gets stored in the Bayeux’s client-HashMap … and stays there. So apparently it is up to the user to remove the clients from there. Otherwise the HashMap would grow towards an OutOfMemoryError, which needed some 400.000 clients on my machine.
So how to get them out? Well it ain’t just that easy to say “on session unbinding I simply remove the client with the corresponding session id” as the client id the Bayeux protocol uses isn’t the http-session id. The client id also changes more frequently, a simple reload of the page is enough to have a new client id. So for my application, I subclassed CometdServlet (over which all request and thus all subscriptions are processed) and made a http-session – bayeux-client-session mapping. This means that I always know which session has which client id, and if the client-id differs, it simply gets removed from the Bayeux-map.
Problem solved
P.S.: Bayeux does the same with channels, so be careful with the amount of channels in your webapp
P.P.S.: Wicket’s first release candidate for version 1.3 is out *thumbs-up*
I already mentioned Apache Wicket in my first post and immediately received advice to not gloss “over a great framework too quickly”. This advice came from a guy named jonathan … coincidentally one of Wicket’s most ambitioned developers is Jonathan Locke, who’s always present in discussions about Wicket … so there may be a connection to that guy who left a comment to my first post 
.
So I gave it a try. As the Wicket website suggests to use version 1.3.0beta, the first I did was to download it as maven dependency.
<groupId>org.apache.wicket</groupId>
<artifactId>wicket</artifactId>
<version>${wicket.version}</version>
</dependency>
<dependency>
<groupId>org.apache.wicket</groupId>
<artifactId>wicket-extensions</artifactId>
<version>${wicket.version}</version>
</dependency>
Then I took a look around to find some code snippets or examples that could give me a smooth start. The guestbook example on the website was the first a had a look at (well after the hello world, which doesn’t count ). The guestbook was easy to understand and ran without problems …
Wicket’s AJAX support was the next thing I had a look at. I found some nice examples in the Wicket Library and on wicketstuff.org (in fact the same on both websites). And yes, it was the guestbook with added ajax behaviour which I tried first. I adapted it a bit to my needs and tried to run it. It ended up by throwing a MarkupNotFoundException which suggested to
Enable debug messages for org.apache.wicket.util.resource to get a list of all filenames tried
as Guestbook.html could not be found. I enabled debug messages by adding the following line to my log4j.properties file.
log4j.category.org.apache.wicket.util.resource=debug
The debug message I got was
[DEBUG] ResourceStreamLocator Attempting to locate resource 'org/example/wicket/Guestbook.html' on path [folders = [], webapppaths: []]
I thought “uh, there aren’t any webapppaths or folders in wicket’s path, gotta add some”. I then entered the path in the web.xml file as property of the Wicket filter. Well, the path was then inside the brackets, but the exception still got thrown.
Eventually I saw the (my) mistake: there was a <wicket:extend> tag in the markup html, which was completely new to me. Having read the wiki article about markup inheritance and having removed the tag, the Guestbook ran without problems. Yepp it was my mistake to copy-paste the thing and to overlook the tag, but couldn’t the error message be a bit better/concise?
Alastair Maw’s BeanEditPanel reminded me a lot of Tapestry’s BeanEditForm, but of course doesn’t have all the BeanEditForm’s functionality (yet). But it was a great starting point for me to get a bit more into wicket … I already extended the BeanEditPanel a bit … yes, to be honest, the more I work with Wicket, the more I like it. The use of plain html and wicket IDs is a great concept and I also like the ease of adding AJAX behaviour. Just have a look at the ajax examples.
A nice summary of wicket’s features can be found in Peter Thomas’s Blog. I also recommend to read Karthik Gurumurthy’s introduction.
The only complaints I have so far are that I could not find the source code, which would be quite comfortable to have attached to the jar, as I sometimes like to see what’s going on behind the curtain… and no I don’t want to check it out from the SVN .
There’s also no link to the 1.3.0beta javadocs on the official website. I found the link in a newsgroup post.
What I’m going to find out next is how the Validators work in Wicket. In a example I found, a Validator was added to a text field for instance like that
TextField name = new TextField("name");
number.add(StringValidator.minimumLength(5));
But contrary to the javadocs, a method FormComponent.add(IValidator) is not available … which I found a bit strange …
That’s all for now, and comments, especially to the validator stuff, are always welcome