So I am working with the Weblog example from the docs. Let's say I want a blog without its blog items. If you set lazy=true in Blog.hbm.xml, that avoids the query for looking up the BlogItems. So my code looks like this:

Session session = sesFac.openSession();
session.load(blog,blog.getId());
session.close();
return blog;

So then elsewhere in my application when I try to use this Blog instance, if I call and methods in the items property, I get a LazyInitializationException. I assume this is because hibernate is setting the items property of the Blog to an implementation of List that does that. If I change my code to do this:

Session session = sesFac.openSession();
session.load(blog,blog.getId());
blog.setItems(new ArrayList());
session.close();
return blog;

Blog.items works like normal, for example if I call size() it returns 0 instead of throwing an exception. Is there better way in hibernate to accomplish this? I guess what I want is "no initialization".

Lazy initialized objects need opened Hibernate session, to initialize all dependent objects on demand.

For many web applications, the best approach seems to have the Hibernate session & transaction handling done by a ServletFilter.

This way, your session if opened until the HTTP request is actually completed. Same for the transaction management.

Use this together with the ThreadLocal pattern to store a reference to the Hibernate session your filter has opened.

What if its inside an EJB container with a fat-client? I'm currently running a test with this configuration and I need to close my session (in a SLSB) after performing a query and load it to some course grain (non-hibernate) class. This will raise a lazy exception.

Thanks.

Then you query and fetch all objects needed before closing the Session. Random lazy loading is not what you want.

It must be better to use hibernate directly in fat client without any EJB,
SLSB has no value in this case any way and this RMI wrapper causes more problems than doe's something usefull.

Oops, and what about container managed transactions (I mean all those required, requires-new, mandatory) and declarative security (even if you don't need that "static" security, container authentication is very helpful). To use or not to use SLSB depends on a lot requirements, baliukas, I think you are not too correct.

--
Leonid

SLSB do not maintain state and there is no transaction and security context propagation. SLSB is nothing more than trivial RMI wrapper (a few lines of custom and more portable code)

This is not true, there is of course a transaction and security context. Juzoas, you tend to simplify a lot in the last couple of weeks and tell everyone that they should just throw away all they have and start with some better approach. While you are sometimes right, it doesn't really help anyone. Maybe you should go on vacation for some days? :)

Yes, there is context per method call, is it usefull ?
BTW that is vacation ?

One of ways is to run container on client, if you must to use EJB use local interface without LazyInitializationException and TDO stuff, Spring is a good alternatyve if you do not like home made solutions too, it just works better.

I tried using Jakarta Collections or BeanUtils copyProperties, it works if its not in an EJB container since its written in EJB spec that reflections dont work (?). I could do a copy attribute per attribute but its a little tiring.