This issue can't be edited
Because it belongs to an archived project. Jira admins can restore projects from the archive.
Use SessionFactoryServiceInitiator instead of sessionFactory.addObserver to inject SessionFactory in DatastoreProvider
Activity
Steve Ebersole July 24, 2013 at 3:08 PM
I guess that depends on what you mean by — type of "extension point". To me second level caching is a "type of extension point", so clearly that does not fit your mental model. What I think you are asking is whether you need to implement Integrator (and I assume you mean in the 5.0 code) for each place that extension points can get registered. If so, no, thats not what I was saying. Today there is an Integrator contract. It is what it is and does what it does. That won't change. In fact, what you ask (if I am right) is really the point of Contributors.
What I was saying is that, if I had a do-over I'd rename that Integrator contract to SessionFactoryServiceRegistryContributor and (re-)introduce Integrator as described in my comment above.
To avoid confusion here (I can feel it lets call this new unified, correct Integrator contract Integration. The idea was that OGM, for example, would supply just one Integration, which would in turn supply all the "contributions" on OGM's behalf. I think it might help you understand if you took a look at the existing contribution contracts. I listed some in passing in my initial comment, some of which exist already some of which do not. The ones that exist exist only on the ORM metamodel (5.0) branch. https://hibernate.atlassian.net/browse/HHH-7540#icft=HHH-7540 added the initial contributors. I just added a follow up to take this conversation (and ongoing 5.0-related conversations) into account in terms of adding missing contributors (the https://hibernate.atlassian.net/browse/HHH-8376#icft=HHH-8376 sub-task) and to allow a single unified resolution under Integration (the https://hibernate.atlassian.net/browse/HHH-8377#icft=HHH-8377 sub-task).
Hopefully this clarifies...
Gunnar Morling July 24, 2013 at 7:40 AM
If there are changes planned around the service registry for ORM 5.0 anyways, would it make sense to wait with https://hibernate.atlassian.net/browse/OGM-299#icft=OGM-299 for that then (assuming that there is no real problem with the current approach)?
@Steve Ebersole: Regarding integrators/contributors, does that mean the Integrator interface needs to be extended for each new type of "extension point" added? Couldn't there also be a more generic registry interface like this (similar to e.g. the OSGi service registry) which is called from within an integrator implementation:
<T> void register(Class<T> contributionType, T implementation) { ... }That way new kinds of extensions/contributions could be added without breaking existing integrator implementations.
Steve Ebersole July 23, 2013 at 7:13 PM
Found the Jira for that btw.. https://hibernate.atlassian.net/browse/HHH-7540#icft=HHH-7540
Steve Ebersole July 23, 2013 at 4:26 PM
Oops, hit submit too early
...
This was already all discussed in Stockholm and those outcomes planned for ORM 5.0. I am not sure how much effort we want to put into this in ORM 4.x. Thats my one concern.
Steve Ebersole July 23, 2013 at 4:25 PM
We did discuss (Stockholm) the potential for a "integration point singularity" for things like OGM, etc that had different types of integration points to override/supplement. I cannot remember if we named that concept or if we did what the name was; interestingly if I were starting this today, I'd call that contract Integrator and yes it would define methods for each of the different ways integrators (OGM, spatial, etc) supply things to the ORM engine. I do seem to recall that we wanted to name all the individual pieces "contributors". The idea being that an "integrator" would supply one or more "contributors" of various types (in a non-magic way, I agree); the point being that they are all defined in a single place for a given "integrator". E.g:
Integrator.java
public interface Integrator {
/**
* Obtain any delegates for contributing things (services/initiators generally speaking) to the
* BootstrapServiceRegistry, by way of the BootstrapServiceRegistryBuilder. Typical use cases
* include OSGi, WildFly, etc.
*/
public List<BootstrapServiceRegistryContributor> getBootstrapServiceRegistryContributors();
/**
* Obtain any delegates for contributing Type instances to the ...
*/
public List<TypeContributor> getTypeContributors();
public List<StandardServiceRegistryContributor> getStandardServiceRegistryContributors();
public List<SessionFactoryServiceRegistryContributor> getSessionFactoryServiceRegistryContributors();
...
}(and standard "abstract convenience" implementation).
This was already all discussed in Stockholm and those outcomes planned for ORM 5.0.
Details
Assignee
Davide D'AltoDavide D'AltoReporter
Emmanuel BernardEmmanuel BernardParticipants
Davide D'AltoEmmanuel BernardGunnar MorlingSteve EbersoleFix versions
Priority
Major
Details
Details
Assignee
Davide D'AltoReporter
Emmanuel BernardParticipants
Fix versions
Priority
Major
In Hibernate ORM, there is the notion of SessionFactory aware services (SessionFactoryServiceInitiator). We did not use it in OGM because we could not find a way to add new service initiators to the SessionFactoryServiceRegistry. Instead we used a SessionFactory observer to listen to the SessionFactory creation and use that hook to create these SF aware services.
There is a more standard way in Hibernate ORM. The trick is to override (in OgmIntegrator) SessionFactoryServiceRegistryFactoryInitiator like we do override others and change the list of services at will.
This approach will also be useful for the metamodel work.
Bonus point if we can devise an easier solution to register these SF aware ServiceInitiator. non SF aware service initiators can be registered by an Integrator implementing ServiceContributingIntegrator.
We could imagine a SessionFactoryServiceContributingIntegrator. any better solution? A potential complex point is to see if the Integrator is still around when the SesisonFactoryServiceRegistry is created.