interesting issues with Wicket and Javassist

[Andrew Geery <an...@gmail.com>]

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

Re: interesting issues with Wicket and Javassist

[Carl-Eric Menzel <cm...@wicketbuch.de>]

On Fri, 22 Jun 2012 11:36:51 -0400
Andrew Geery <an...@gmail.com> wrote:
> 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?

That would certainly be the cleanest solution.

Otherwise the converter lookup mechanism would have to be adjusted. That
might be a rather expensive operation - it's a simple map lookup right
now so it's very fast but doesn't work with subclasses. Long ago I wrote
my own string conversion classes for an application I was working on. It
used a chain-of-responsibility pattern, where a number of converters
would try converting the value one after another until one succeeded.
It worked well and it could probably be adapted. Two things make me
wary of this approach though:
 - it'd be a major API break
 - we'd have to look at performance very closely.

Carl-Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

Re: interesting issues with Wicket and Javassist

[Martin Grigorov <mg...@apache.org>]

Hi,

On Fri, Jun 22, 2012 at 6:36 PM, Andrew Geery <an...@gmail.com> wrote:
> 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

Apache Camel project provides a ConverterRegistry which claims to
support lookups by super classes and interfaces.
I haven't used it so I cannot say whether it will work for Wicket or
not but I think we should investigate this.

> 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



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org