[hibernate-dev] nested ServiceRegistry ?

[Steve Ebersole]

On Wednesday, March 23, 2011, at 03:23 pm, Adam Warski wrote:
> I think it's quite reasonable to have both app-wide and session
> factory-wide services. Or you can call them "scopes", just like in a
> webapp you have request, session and app-scoped beans, here you can have
> app and session-scoped services. Or even maybe (Hibernate) session-scoped
> ones? Although I'm not sure if they would be useful anywhere ;)

I had thought of that tbh and it could be quite useful.  For example having 
the ability to open a session with different set of even listeners than those 
attached to the factory.  Looking at you envers ;)


> 
> Adam
> 
> On Mar 22, 2011, at 3:27 PM, Steve Ebersole wrote:
> > ServiceRegistry itself has worked out great imo, but I am starting to run
> > into difficulties in migrating certain things to be services. 
> > Specifically I had issues with both event listeners and Statistics.  In
> > each case the issue was slightly different, but both were solveable by
> > having a notion of the ServiceRegistry being scoped by the
> > SessionFactory.  That is not the ideal general solution though since
> > many services do not care about or need the SessionFactory.  The only
> > real solution I have thought of is to have the concept of a set of
> > nested registries.  In the simpliest case, I think 2.. a basic service
> > registry and a session factory scoped one where the session factory
> > scoped one knows about the basic one (typical parent delegation).
> > 
> > But I am looking for any other suggestions.
> > 
> > Another option is that maybe listeners and stats are just not services in
> > the ServiceRegistry sense.
> > 
> > So what were the specific problems?  I guess that is useful to formulate
> > suggestions ;)
> > 
> > In the case of statistics, its merely a case that it needs a reference to
> > the SessionFactory to be able to answer questions like "getEntityNames,
> > "getCollectionRoleNames", etc.
> > 
> > In the case of listeners it is not a simple explanation.  It really comes
> > down to scoping of the listeners and timing in regards to how stuff
> > happens at the moment because of the "freeness" of Configuration.  The
> > end result was different for each listener set.  jpa, envers, bean
> > validation, search each had unique set of problems; even the default
> > listeners had issues.
> > 
> > ---
> > Steve Ebersole <steve at hibernate.org>
> > http://hibernate.org
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

---
Steve Ebersole <steve at hibernate.org>
http://hibernate.org