This is mentioned... https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc#transactions
Its not just org.hibernate.transaction.CMTTransactionFactory that was removed; all of the TransactionFactory classes were removed. Actually I think we should add them as resolvable names: * org.hibernate.transaction.CMTTransactionFactory -> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl * org.hibernate.transaction.JTATransactionFactory -> org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorBuilderImpl * org.hibernate.transaction.JDBCTransactionFactory -> org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorBuilderImpl Add a Jira if you'd like to see them mapped. On Mon, Nov 2, 2015 at 9:51 AM Scott Marlow <smar...@redhat.com> wrote: > Should the ORM 5 migration documentation [3] mention that > "hibernate.transaction.factory_class" can no longer be set to > "org.hibernate.transaction.CMTTransactionFactory"? I think that > CMTTransactionFactory is deleted in 5.0. > > Scott > > [3] > https://github.com/hibernate/hibernate-orm/blob/master/migration-guide.adoc > > > On 08/13/2015 08:38 AM, Steve Ebersole wrote: > > For a lot of your questions, I'd highly suggest reading [1] and [2]. > They > > are mostly the same content (asciidoc versus docbook). > > > > [1] - > > > http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html > > [2] - > > > http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#bootstrap-native > > > > > > > > > > On Wed, Aug 12, 2015 at 11:58 PM Koen Serneels <k...@error.be> wrote: > > > >> Hi Steve, > >> > >> > >> > >> Let me clarify the first two questions: > >> > >> > >> > >> I’m looking for an entry point/hook in H5 for altering existing class > >> mappings. For example; some of our entities are supposed to be > immutable, > >> but only in production mode. > >> > >> When running our tests we are using that same model to setup data in an > >> in-memory database. If the entities would be hardcoded immutable then we > >> would be problematic to use them fully for manipulating setup data in > our > >> tests. So, in test mode we actually need the entities to be mutable > instead. > >> > >> To accomplish this we are retrieving the classMappings from the > >> Configuration which gives us the PersistentClass meta-data. On this > which > >> we can then toggle the mutable flag depending. > >> > >> Since that functionality has now been refactored, I thought that > >> MetadataContributor was the way to go in H5 as it lets me access > >> InFlightMetadataCollector which gives access to getEntityBindingMap > which > >> allows to retrieved the PersistentClasses. > >> > >> > >> > >> However, from the source code I understand that the MetadataContributor > >> can only be configured using ServiceLoader. This means it will not be so > >> straightforward/clean to enable or disable that said MetadataContributor > >> dynamically. Now you suggest: *But if a piece of code is able to > >> determine whether or not to register a MetadataContributor, it could > simply > >> contribute said metadata, no?* yes, but this is probably where my > >> understanding is falling short; I was under the impression that the > >> MetadataContributor is **the** new way for contributing changes or > >> additions to existing meta-data. If there is another (programmatic) way > >> without having to register MetadataContributor, then by all means, but > >> how/where? > >> > >> > >> > >> On the JTA question: > >> > >> > >> > >> My question has been answered, thanks, but just to clarify: when using > >> JTA, we can configure the shorthand alias ‘jta’ for the coordinator as > you > >> state. > >> > >> With the second part I meant; what if we are _*not*_ using JTA but are > in > >> local transaction mode, should we then also explicitly configure the > >> coordinator (with short name ‘jdbc’ in that case) or will it be the > >> default? Again you confirm that ‘jdbc’ is the default so when not using > JTA > >> no coordinator setting is required > >> > >> > >> > >> For the last question: > >> > >> > >> > >> Ok thanks for pointing that out. Is there an easy way to get hold of the > >> org.hibernate.boot.Metadata which I need to pass to > >> SchemaCreator/SchemaDropper? > >> > >> I could also use SchemaExport directly from within code, but afaik it > will > >> rebuild the metadata which will probably take longer… > >> > >> > >> > >> To give some background how I’m using this: in some types of test we > >> actually commit data to our in-memory database. In order to clear the > >> database between tests, we simply drop and recreate the entire schema > based > >> on the DDL. This was the fastest solution with the least amount of > impact. > >> For the record: I’m aware there are other solutions for this, but not > all > >> of them are feasible. I’m leaving out the details here as it would go > off > >> topic – at the moment I’m just looking for a way to migrate it to H5 > >> keeping the same functionality we have been using (extract the > create/drop > >> DDL from a live SF as fast as possible) > >> > >> > >> > >> Thanks, > >> > >> > >> > >> Koen. > >> > >> > >> > >> *From:* Steve Ebersole [mailto:st...@hibernate.org] > >> *Sent:* donderdag 13 augustus 2015 4:24 > >> *To:* Koen Serneels; hibernate-dev@lists.jboss.org > >> *Subject:* Re: [hibernate-dev] Hibernate5 migration > >> > >> > >> > >> There is a migration guide: > >> > https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migration-guide.md > . > >> It is still a work in progress as in its is not "prettified" yet (as > 5.0 is > >> not final yet. If things are missing please let us know. > >> > >> > >> > >> Some answers inline... > >> > >> > >> > >> > >> > >> - In Hibernate4 we modified mappings on-the-fly by overriding Spring's > >> LocalSessionFactoryBean#buildSessionFactory. > >> > >> > >> Doing so we could first access the getClassMapping on > >> org.hibernate.cfg.Configuration before letting the SF actually build. > >> > >> However, in Hibernate5 the metadata access has been refactored and is no > >> longer part of the Configuration. Should we use MetadataContributor > instead > >> for these purposes? > >> > >> > >> > >> > >> > >> Depends what you are trying to achieve specifically. What do you mean > by > >> "modify"? Do you mean literally that you want to modify (alter) the > >> existing "class mappings", or do you really mean that you want to add > >> additional mappings? > >> > >> > >> > >> > >> > >> - Is there a way to register MetadataContributor dynamically? I see > that it > >> is being loaded using Java's ServiceLoader. > >> > >> However, I need some programmatic API access to enable or disable the > >> Contributor (for example based on Spring profiles). > >> > >> > >> > >> No there is not a way to register a MetadataContributor programatically. > >> I really do not see the benefit of having that as a feature. Maybe you > >> need to explain better? But if a piece of code is able to determine > >> whether or not to register a MetadataContributor, it could simply > >> contribute said metadata, no? > >> > >> > >> > >> > >> > >> - For JTA integration we were using > >> org.hibernate.engine.transaction.internal.jta.CMTTransactionFactory, but > >> this class is no longer present. > >> > >> Also in org.hibernate.cfg.AvailableSettings the key that was used > >> (hibernate.transaction.factory_class) to configure the factory is also > >> removed. > >> > >> Is hibernate.transaction.coordinator_class the new key we should be > using > >> instead with > >> > >> > org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordi > >> natorImpl as value for JTA? > >> > >> > >> > >> Yes, but I would highly recommend using the short-name config values, > e.g.: > >> > >> > >> > >> hibernate.transaction.coordinator_class=jta > >> > >> > >> > >> rather than: > >> > >> > >> > >> > >> > hibernate.transaction.coordinator_class=org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl > >> > >> > >> > >> Both do the same thing, the first form is just better (for many > reasons). > >> > >> > >> > >> > >> > >> Do we need to configure anything special in case of resource local TX > or is > >> JdbcResourceLocalTransactionCoordinatorImpl the default? > >> > >> > >> > >> I'm confused with this last piece in combination with the rest of the > >> questions here. The rest of the block discusses JTA, but then here you > are > >> asking about JDBC-based transactions. Regardless, the default > >> TransactionCoordinator is in fact the JDBC one. > >> > >> > >> > >> > >> > >> - generateDropSchemaScript and generateSchemaCreationScript have been > >> removed from Configuration. Is there a way to access this in another > way? > >> > >> > >> > >> Again, depends on exactly what you hope to accomplish here. Your main > >> options will be either: > >> 1) grab the org.hibernate.tool.schema.spi.SchemaManagementTool from the > >> StandardServiceRegistry and use it to obtain the SchemaCreator > >> and SchemaDropper, passing them the Metadata. > >> > >> 2) Use the org.hibernate.tool.hbm2ddl.SchemaExport class > >> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
