Menu

#5 Some bugs for version 1.1

open-accepted
POJO Store (1)
5
2008-08-11
2008-06-30
Richard Lee
No

First, thanks for such a great work, it really saves my time.

I spent the whole yesterday to take a quick look at the source code and did some testing, I'd like to donate 2 cents as I can to report some issues:

1. in ClassMapping, it may not be a good idea to call ClassLoader.getSystemResourceAsStream to read the javaassist external xml file located in hibernate4gwt.jar. As a matter of fact, it will fail in host debug mode, because usually we just include jar file in WEB-LIB/lib. Instead, call getResourceAsStream of context class loader in current thread probably is the solution.

2. in HibernateBeanManager, you have a logic that if pojo is not an ILazyPojo and store is not a stateful one, a exception will be thrown. We can not guarantee the client code always works with a proxy pojo that hibernate4gwt generates. A typical case is entity creation, the simplest way is just creating a domain entity in client side then sending it to server side by rpc. However, the exception above will prevent the entity from reaching bisiness implementation servlet. It doesn't make sense every time I have to get an empty domain instance from server side before creation just for getting an ILazyPojo object.

3. HibernateBeanManager._lazyKiller can not be accessed by subclass (private and no getter), in case when I want to extends HibernateBeanManager to override some methods.

4. in HibernateUtil.classCurrentSession, the code call session.close(), which really closes the door of the support to 'One Session Per Request' application. Suppose now I use stateless store, and the store restores the hibernate entity and merges the client pojo for me, then the store closes the session! So it's possible later if I want to access a lazy collection or a lazy associate a LazyInitializationException will come. At least we should have a configurable swith to control this close behavior, right?

Finally, a small suggestion, can we put more focus on stateless mode ? I believe more people will choose this mode than others, proxy mode now has some bugs and not flexible, stateful mode is a little bit difficult to manage the resource usage. Stateless mode is the ideal choice with low risk. Just my point, may not be right.

So far, that all. I hope it can help h4gwt to become more powerful and flexible.

Thanks for you great work again!

Discussion

  • Bruno Marchesson

    Logged In: YES
    user_id=1729528
    Originator: NO

    Hi Richard,

    Sorry for the late answer : the bug tracker did not send any e-mail notification, so I just discover your post today...
    Your remarks looks good and I will try to integrate these modifications in next days.

    Thanks for your interest.
    Bruno

     
  • Bruno Marchesson

    • assigned_to: nobody --> bmarchesson
     
  • Bruno Marchesson

    Logged In: YES
    user_id=1729528
    Originator: NO

    Here are some quick answers :

    1. Done in release 1.1b
    2. as mentioned in (updated) doc, you should use GWT.create() on client side when using dynamic proxy mode. Nevertheless, I think this limitation could be removed in future release...
    3. Fixed in SVN (branch '1.1') : all HibernateBeanManager have been changed to 'protected'
    4. The goal is to provide a merge detached entity, but indeed, the 'Open Session Per Request' option should remain open. I will try to implement this improvment for next release

    Finally, the stateless mode is already the default one.

    Thanks for your interest !
    Bruno

     
  • Bruno Marchesson

    • status: open --> open-accepted
     

Log in to post a comment.