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