I have implemented Hibernate in both a Struts interface, and also in stand alone applications. But what I am trying to do now is develop an application that is primarly a struts application but requires a XML-RPC interface (will be non-struts), a few command line utilities and also is tested with JUnit.

This doesn't seem hard, but I am stuck on how to initialize Hibernate in each of these environments. The HibernatePlugIn, on http://www.hibernate.org/105.html, is great but obviously will only work for Struts.

So all my DAO's extend BaseDAO which currently checks the ServletContext to get the stored session factory. This obviously does not work in stand alone apps, or my JUnit tests.

Can anyone offer any suggestions? Am I thinking wrong, or have my DAO's setup wrong?

Thanks,

Jeremy

SessionFactory factory = new Configuration().configure().buildSessionFactory().
Than use this factory in BaseDAO or whereever you ness Sessions

This should build a session factory from the hibernate.cfg.xml config file which should be in the classpath. I don't know where does HibernatePlugin look for config data but it should have some hibernate.cfg.xml or hibernate.properties file in the classpath.

It's a bit of a pickle really.

Referencing visual and controller code in the DAO layer is bad practice (as you are now experiencing) because it creates a reverse dependancy that violates the MVC concept. Your persistence (DAO) code should not know anything about the layers above, i.e. it should be able to stand alone.

On the other hand, neither HibernatePlugin or the Session-in-View filter are ideal because the typed Hibernate session factory is created in the view tier. In a proper MVC implementation, view should know nothing about the model/persistence layer (the controller should stand as an intermediary).

However, in reality, I've found that the session-in-view servlet filter is an acceptable compromise and actually works very well with Hibernate session lifespan management. And, since it is implemented as a "transparent" filter, it turns out to be not that bad of an MVC violation after all. The key here is to give your BaseDAO a constuctor that accepts a pre-built Hibernate session (created either by the filter or by your stand-alone app). You could also have a no-argument constructor that tells the BaseDAO to create a session factory and session on its own. If you do this, make the session factory static (because it is expensive to create), and wrap it with singleton code. But be very careful with your implementaion - don't use lazy initialization via double-checked locking - pre-initialize the static instead!

Hope this helps,
Scott

Another basic problem in the same direction. However this problem is not directly related to Hibernate.

I'm working an application that uses DAO's and hibernate. It also uses another common package with its own DAO's and tables.

How does this common package accesses the db? Should it use its own SessionFactory and its own connections to the db or should it somehow receive the necessary Sessions from the 'main' application. If so, how can this know which are the classes that must be loaded in the configuration?

Bart.

Scott,

you mentioned "session-in-view servlet filter" a couple of times - sorry, I am not familiar with this pattern. Care to elaborate or point to some material on that?

so are you saying that the servlet context is considered the visual and/or controller tier?

i would like to implement various DAO's for CRUD's on users and blog entries but with this new insight of yours it seems that i am wrong in storing a SessionFactory in a servlet context. how else can one create/store the SessionFactory and make it accessible to the various DAOs? maybe im not thinking about this correctly

Sorry to take so long to reply - my darned spam filter killed a bunch of reply notifications.

Jimpo, Open Session In View = http://www.hibernate.org/43.html

But I've come to determine since July that Spring http://www.springframework.org is better at managing Hibernate sessions (not that it does it better, it's that IMHO it does it a little more transparently). Spring is also much better at helping you get to declarative transactions and has a host of other benefits. Google for Matt Raible's Spring Live chapter (#2) available for free download. Does an awesome job explaining it.

Bennini, yes, the servlet context is part of the presentation tier since it wouldn't be part of the business services below it that handle not only Http requests, but possibly also those from SOAP, RMI, EJB, etc. In my view, Struts actions ride the fence between the presentation and controller layers - it glues them together. But your business services shouldn't know squat about Http (don't make lower layers depend on upper ones). If you split your code up like this, you'll not only go a long way towards SOA, but will also be setting yourself up for transactions...

Storing a Hibernate SessionFactory (or Session) in the servlet context isn't the best idea - it's better to use a Servlet Filter to bind a Session (from a SessionFactory that's available JVM-wide) to the ThreadLocal, i.e. to the user's request object's thread. In fact, that's what OpenSessionInViewFilter does, both when implemented directly or when done through Spring's support. This binds the livespan of the SessionFactory to the JVM, and the Session to the user's request/response cycle without it creating a code dependancy in nearly every contemporary meaning of the concept (i.e. there is a dependancy there, but it's very minor and for the most part academic).

I'll be glad to explain this if you have follow-up questions, but I'd urge you to read the references above first. Really, Spring is the way to go for Hibernate session management and declarative transactions - you can leave all the rest of its features aside and still gain a lot from it.

Scott