I've recently run across a couple of issues where a proxy'ed class (using Javassist from Hibernate) has messed up Wicket. When a class is proxy'ed by Javassist, the class you have (say, Person) isn't really a Person class but something like Person_$$_Javassist_48.
I had registered a converter with my Wicket app to provide a string representation of a Person object. I then had a datatable of Accounts where one of the columns was a Person object (account.person). When the table displayed, the Person was correctly displayed using the converter. However, when I edited an account row (using a ModalWindow on the same page via) and then re-added the datatable to the panel to the target, the Person converter was not called; instead, the toString() method on the Person object was called because Wicket was using the default converter (toString()). Looking more into the issue, the problem was that my LDM for the account was only fetching the account data and the person data was marked as being fetched lazily. In my LDM, I did call account.getPerson() to force Hibernate to load the association. The Person object was populated but the type of the object was still something like Person_$$_Javassist_48. The fix was to change the query that loaded the account row to also load the person data. Doing this, the person object was not proxied and Wicket used the correct converter. Otherwise, Wicket looks up the class Person_$$_Javassist_48 and doesn't find a custom converter. My question is: should Wicket have realized that the proxy'ed Person object was actually a Person class and called the appropriate converter? Looking at this -- http://stackoverflow.com/questions/1139611/loading-javassist-ed-hibernate-entity -- it looks like there is not a generic way of handling this, without explicitly checking for something like a HibernateProxy. Perhaps the answer is simply: make sure that proxies don't end up in the UI layer? Andrew
