Hi all, did anyone played with hibernate and pico? Any experiences to share with community?

I started to emply pico in my development, and it looks really impressive ( well, project looks less imprtessive because I'm removing tons of code formerly used to configure and glue components together... )

Refactoring my DAOs for pico will be next step.

So far I identified natural candidates for picofication:

1. Component providing Configuration ( maybe Configuration itself.
Maybe inherited from it, to configure using properties via constructor )

Several instances for diferent hibernate datastores possible in container.

2. SessionFactory provider ( maybe SessionFactory itself, has to be instantiated via constructor accepting Configuration. It couls also
configure mappings...

3. SessionManager ( from SessionFactory ) - plugable strategy for session management - like thread local, servlet request, whatever else...

4. DAO itself ( shall get session manager )



flamewar welcome :)

I would go for:


HibernateSessionFactory component
HibernateSession component
CustomerDao component


which is I think about the same....

I remember a discussion in the early ages of pico about the non picoification or pico-friendlyness of Hibernate. I think it was Aslak.

PS: How do you deal with session lifetime and dao lifetime.

Well, in moment ( for me, personally ) hibernate is not very pico friendly - though emplying pico would make my project more friendly to me ( a lot of config / glue stuff would just dissapear without a trace -
like in other parts )

Session lifetime is not very clear, so there will be need of some kind of "session provider" - it has to have session factory (because session factory can be obtained through configuration only, there will be need in some adapter. Pretty trivial though)

The this session profived component shall provide methods:
- to obtain session ( maybe already used session , cache it, use thread local)
- to give session back ( without closing it )
- to give botched session back and destroy it ( after exception , maybe provide rollback )
- ( possible ) explicit transaction demarcation

DAO shall eat this session provider, and be really simple in the init
( mine are already ) to be constructed effectively and just disposed.

If DAO itself is threadsafe, it could live as application scopre component, where session provider is request scope...

Note that it would be very nice if Hibernate would be internally architected around IoC principles. This is not possible, however, since dependency injection basically assumes that objects can be initialized immediately, whereas some central Hibernate objects (eg the ClassPersisters) have complex multi-phase initialization cycles. Very difficult and nasty.

Dependency injection is great for simple business logic, but I think it starts to fall over where you have more complex stuff like this.

Indeed, it would be very nice. But even as is it can be used in IoC
manner.

SessionFactory provider can be initialized in IoC manner.
Since configuration can be subclassed, I would go for "typesafe"
Configuration ( configuration subclass feed with generic (say) properties, and filled with persistent classes ) then this generic
copnfiguration cabn also build session factory.

Typesafety will help to distinguish different kinds of such configurations in container ( if somebody needs several hibernate datastores )