That's just the price you pay for lazy loading. That's why the option is there. For the views which require the list, just call the method to initialize. It sounds silly to me to add this "new feature" when the solution just boils down to deciding which fetch strategy works for your use case.
I think we could be able to find a solution for it. Using eager loading is one of them, though, I see three drawbacks:
1) you have to know what the view requests from your entities - in our theoretical case where the view and the backing bean author are different persons you might not be able to know this ...
2) you have to pollute your backing bean with database system code.
We access the database through DAO classes, now, the same method to retrieve a list of entities has to be duplicated just to have once lazy loading or in the other case eager loading
3) the ORM mapper looses some of its transparency
I don't know whats "silly" on my post or my proposed solution which is just a start of a discussion.
At least my solution keeps the ORM transparency and you have to do NOTHING in your backing bean, DAO or somewhere else in your code.
I am sure tons of developers out there do not even know what it means having an open Connection laying around, in the worst case until the conversation times out.
With multiple conversations (say 2 per user) and say 50 user you might end with 100 active Connections (in the worst case for sure).
Ok, looks like I found another solution/workaround.
I provide my own Hibernate ConnectionProvider (by decorating the original one). This provider hands out so called "DisconnectableConnections" and keeps track of all borrowed/released connections.
In a ServletFilter (at the end of the response) all not release connections will be "disconnected".
Notice, Hibernate still holds the DisconnectableConnection and thinks everything is fine.
One the next access via such a connection (which is "discconnected") it will be automatically reconnected.
"disconnected" in this context simply means it has been passed back to the connection pool.
Instead of using a ConnectionProvider one might simply decorate the connection pool itself ... but this is another story, though, it should work with any orm mapper then.