BaseListLoadResult is not a bean and cannot be used together with hibernate4gwt!
BaseListLoadResult is not a bean and cannot be used together with hibernate4gwt!
Hi,
according to the main developper of hibernate4gwt (see below) the class BaseListLoadResult can not be used as the class does not behave like a bean. It is missign a setData - funktion (public or private).
Darell, is it possible to get a gxt release that adds a public or private set-function?
Best regards,
Donald,
By: noon (bmarchesson) - 2008-07-23 11:17
Hi Donald,
I've got 2 news :
- the good one is that I reproduced your issue and understand what happens. It comes from the BaseListLoadResult class which *dot not provide* a setter method for the 'data' member, so Beanlib cannot populate this field (the clone algorithm is based on setter methods) !
- the bad one now : without the appropriate setter (even a private one should be sufficient), hibernate4gwt cannot clone BaseListLoadResult instances properly. Worse, the 1.0.4 release won't help you more. In this case, it lets the BaseListLoadResult instance untouched, but if it contains Hibernate entities partially loaded as data, its serialization throught RPC will fail...
IMHO, you should ask GXT team to add a private setData method to solve your issue.
I am the author of hibernate4gwt.
I read the roadmap for release 1.1 and it does not seem to solve Donald's issue.
As mentioned in my post on h4gwt forum, the problem comes from the BaseListLoadResult class (from GXT) and not the application beans (that must already be Java beans to work propertly with hibernate4gwt). So adding Java bean support won't help if the BaseListLoadResult class does not provide a 'setData' method.
First, congratulations for your job on hibernate4gwt. Personally, I have not used it yet, but surely it will come and at least I know there is a solution for Hibernate<->GWT issues.
Actually, you're right, JavaBeans support has nothing to do with your issue, I was probably tired when writing the post... However, adding an unused private or public setter method looks more like a workaround than a clean solution. It leads me to two questions : do you really HAVE to clone the object and do you really NEED a setter method in addition to the field (I don't know the context) ?
Anayway, I'm not a GXT developer, it is just a personal opinion Darell, your opinion might be interesting.
Hi all,
I've a problem that maybe is linked to this post.
I've a service that extends HibernateRemoteService and the method is:
public PagingLoadResult<UtenteTable> getPosts(final PagingLoadConfig config) {
try {
System.out.println("Siamo prima del load");
loadPosts(config);
System.out.println("Siamo dopo del load");
BasePagingLoadResult bp = new BasePagingLoadResult(posts, config.getOffset(), (int) UtenteDAO.loadUsersCount());
System.out.println("Siamo prima del return");
return bp;
} catch (Exception e) {
System.out.println("Siamo nell'eccezione RPC");
e.printStackTrace();
return null;
}
}
this method works fine if the service doesn't extends HibernateRemoteService but extends RemoteServiceServlet. In the first case I've not error on compilation o exception during the executions but the table that is waiting for data doesn't display anything, just display the waiting image.
@drenda : yes, your issue is the same as encountered by Donald :-(
@zaccret : unfortunately, the BaseListLoadResult needs to be cloned because it contains persistent beans. As explained in response to Donald, if the BaseListLoadResult is sent untouched, the contained Hibernate beans will lead the RPC serializer to fail.
I just ask GXT team (Darrell ?) to transform the BaseListLoadResult into a regular bean (with appropriate getters and setters), which can be helpful to many people, including hibernate4gwt users (since there is no possible workaround for it !).
I do not know why there is no 'setData' method and if it is voluntary or not. That's why I suggested to turn the 'setData' member into private if GXT developpers do not want their users to call it at runtime.