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 <st...@hibernate.org> > > http://hibernate.org > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev --- Steve Ebersole <st...@hibernate.org> http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
