possible to initially disable JPAContainer?

Flow
1

Hi,

I’ve been playing with JPAContainer and found it really useful for binding lookup tables to combo boxes etc. It’s also really useful when I want to display all instances of a particular entity.

Now, is there a way to make a JPAContainer bound Table to:

  1. initially display nothing? Then,
  2. have it display only a subset of the entities, when a row is selected on another table? (which provides the ID to filter on)

I know (2) can be done using filters, but what about (1)?

Currently, I can only think of a hack, where I initially set the Table to an empty BeanItemContainer for the same entity, then switch it to a filtered JPAContainer when the table needs to display a subset of data.

This looks ugly though, so is there a better way?

thanks a lot, regards.

2

Just an intuition - how about handling the case 1 also with filter with an id that do not match? This would be logical as you are always showing all matching ids.

On the other hand - it might be faster to just bind an empty indexed or bean item container to the table.

3

OK, just testing out this method now.

I’m getting a Lazy loading exception however:
org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: org.test.domain.Animal.observations

This happens when I set the table with a JPAContainer. The Animal.observations collection is configured with lazy loading via JPA. However, I’m using the following code to remove that property from the table columns:

      animalList.setContainerDataSource(getAnimalContainer());
      // ANIMAL_LIST_FIELDS is a String[] and does not contain "observations"
      animalList.setVisibleColumns(ANIMAL_LIST_FIELDS);
      animalList.setColumnHeaders(ANIMAL_LIST_LABELS);

So theoretically, that lazy-loaded property shouldn’t be accessed at all by the table. But it appears it is.

Any idea what I’ve missed?

Thanks again.

4

Nope… Anyone else have an idea?

5

Hi,

Sorry, as this answer is probably too late to the game.

LazyLoading in JPAContainer 1.x with Hibernate does not work very well. You can get it sort-of working by calling setEntitiesDetached(false) on the EntityProvider you use, but this will cause (quite possibly very bad) problems with Hibernate Sessions. The other way is to use EclipseLink, where lazy loading automatically works.

If you want to use Hibernate with JPAContainer 1.x I recommend that you annotate all your associations with FetchType.EAGER.

However, using the new 2.0.0-RC1 of JPAContainer lazy loading can be made to work with Hibernate as well. http://dev.vaadin.com/browser/svn/addons/JPAContainer/trunk/jpacontainer-itest/src/main/java/com/vaadin/addon/jpacontainer/itest/lazyhibernate contains a small (and unfortunately still ugly) example of how to get lazy loading working correctly with Hibernate in JPAContainer 2.0.0-RC1

HTH,
/Jonatan

6

As far as I understand the problem might be

  • in application architecture - after transaction has been executed your code is still trying to call uninitialized bean. To avoid this you should initialize all lazy initialized beans before transaction has finished either by accessing bean within transaction(it will be initialized automatically) or use join fetch construction in you JPA queries.
  • if application architecture looks fine you should sometimes when needed to use join fetch construction to avoid exception
  • the last variant when it is too late to change anything you can create DeproxyUtil class that will explicitly re-associate lazy initialized bean with persistent context and deproxy it.

While developing
Lexaden Administration
 (demo/demo) we instructed Spring to create transactions on the view layer(not web) where we build up and initialize UI components.