Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1

Steve, I think there is something fishy. I have created a branch with a blatant usage of a JDK 8 API in hibernate-core There is one commit above today’s master: protected EmptyInterceptor() { + final java.time.ZoneId id = java.time.ZoneId.systemDefault(); + System.out.println( id.getId() ); } https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer < https://github.com/emmanuelbernard/hibernate-orm/tree/animal-sniffer> And when I run ./gradlew clean build things do pass, i.e. Animal Sniffer is either not executed or it does not make the build fail. I did not see any Animal Sniffer reference in the console while it was running. Does it do the same for you if you clone my branch? Emmanuel PS: 18 mins here on a Mac + SSD. I guess Linux beats the crap out of Mac on FindBug executions ;) > On 01 Apr 2015, at 18:09, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > > I'm not going to argue with you man. AnimalSniffer *is* run. If you don't > believe that and don't want to verify it for yourself, oh well, nothing I > can do about that... > > On Wed, Apr 1, 2015 at 8:32 AM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > >> Hum, you are not April-fooling me, right ;) >> >> There is something Java-8-specific in already: the usage of >> ConcurrentHashMap#keySet() (in >> SessionFactoryImpl#iterateEntityNameResolvers()) which - when compiled on >> Java 8 - adds a reference to the Java-8-only type KeySetView to the class >> file of SessionFactoryImpl. That's the issue pointed out by Petar >> originally. >> >> But when running "./gradlew build" on the current master, the build >> passes. I would expect it to fail though, as AnimalSniffer should detect >> that usage of Java 8's KeySetView class. So I don't see that AS is executed >> actually? Or are you saying it is run but it's findings don't cause the >> build to fail? >> >> If I go back to the original approach of using AS (via git checkout >> 5f6d1~1), it behaves as I'd expect it: "./gradlew build" fails due to that >> reference from SessionFactoryImpl#iterateEntityNameResolvers(). >> >> Do you actually see the build on master fail due to that reference being >> discovered by AS? >> >> >> 2015-04-01 15:03 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> Gunnar, it is applied. Add something that is java 8 specific and see... >>> On Apr 1, 2015 7:59 AM, "Gunnar Morling" <gunnar(a)hibernate.org&gt; wrote: >>> >>>> I saw the plug-in, Steve. But how/when is it executed? >>>> >>>> Running "./gradlew build" used to execute AnimalSniffer and would have >>>> revealed that accidental usage of KeySetView. That's not the case anymore. >>>> It would be nice if that new plug-in could be applied automatically after >>>> compileJava as it used to be the case with the Ant-based approach. >>>> >>>> >>>> 2015-04-01 13:48 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> >>>>> Increase your Gradle-fu we must young apprentice :) >>>>> >>>>> AnimalSniffer is still run. I simply converted it to be a plugin. >>>>> Check out org.hibernate.build.animalsniffer.AnimalSnifferPlugin in ORM's >>>>> /buildSrc project >>>>> >>>>> AnimalSniffer will apparently not detect this :) >>>>> >>>>> On Wed, Apr 1, 2015 at 4:32 AM, Gunnar Morling <gunnar(a)hibernate.org > >>>>> wrote: >>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very category >>>>>> of error and I'm wondering why it didn't detect the "usage" of KeySetView. >>>>>> >>>>>> Looked at this a bit closer. Turns out, AnimalSniffer *will* detect >>>>>> this issue if it actually is run. The problem is that AS apparently is >>>>>> not executed by default anymore, due to the recent change to how AS is used >>>>>> [1]. >>>>>> >>>>>> Prior to that change, running AS was done automatically after the compileJava >>>>>> task and would have reported that usage of KeySetView: >>>>>> >>>>>> Undefined reference: >>>>>> java/util/concurrent/ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>> in >>>>>> [...]/hibernate-orm/hibernate-core/target/classes/main/org/hibernate/internal/SessionFactoryImpl.class >>>>>> >>>>>> Unfortunately my Gradle Foo is rather limited, so I'm not sure how to >>>>>> re-establish that behaviour with the new AS plug-in. >>>>>> >>>>>> --Gunnar >>>>>> >>>>>> [1] >>>>>> https://github.com/hibernate/hibernate-orm/commit/5f6d1d24f7945eb8a5acdb6... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org&gt;: >>>>>> >>>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>>>> >>>>>>>> Just to clarify... I *think* that as long as we run the build with >>>>>>>> Java 8 >>>>>>>> and set the bootclasspath to 6 or 7 we should be fine. >>>>>>>> >>>>>>> >>>>>>> Yes, setting the boot classpath to 6 (or 7) makes sure you only use >>>>>>> classes present in that JDK (be it explicitly or implicitly as in the >>>>>>> ConcurrentHashMap case), because it's that class library which will be used >>>>>>> for compilation then. It is cumbersome to use though as you need to specify >>>>>>> the location of a 6 or 7 JDK which makes the build less easily portable >>>>>>> between machines. >>>>>>> >>>>>>> Currently, AnimalSniffer is in place to prevent this very category of >>>>>>> error and I'm wondering why it didn't detect the "usage" of KeySetView. It >>>>>>> really should have detected it, assuming it analyses the byte code of >>>>>>> classes. But this makes me wonder now whether it only analyses the source >>>>>>> code actually. Then it wouldn't be usable to prevent this sort of issue. >>>>>>> >>>>>>> Coding against the ConcurrentMap interface is the best way to avoid >>>>>>> the issue. But of course there is no guarantee that it happens again, >>>>>>> unless e.g. having a build on CI which uses 6 or 7 on its boot classpath. >>>>>>> >>>>>>> >>>>>>>> On Tue, Mar 31, 2015 at 7:13 PM, Steve Ebersole < steve(a)hibernate.org&gt; >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Well the idea is to run the Gradle process with Java 8 (the build >>>>>>>> itself >>>>>>>>> is a Java process too don't forget). We pass in the older JDK >>>>>>>> specifically >>>>>>>>> to be able to set the bootclasspath for compilation and the >>>>>>>> executable for >>>>>>>>> running tests. That's the theory. >>>>>>>>> >>>>>>>>> Interestingly I developed a simplified project to test these >>>>>>>> theories: >>>>>>>>> https://github.com/sebersole/gradle-mixed-jdk And of course this >>>>>>>> all >>>>>>>>> works there. As you'd expect right? >>>>>>>>> >>>>>>>>> I think the JAXB thing comes into play here as well. Gradle does >>>>>>>> not have >>>>>>>>> any XJC support built in, so we have to make use of its Ant >>>>>>>> support to run >>>>>>>>> the XJC Ant tasks for JAXB model generation. The problem there is >>>>>>>> that, >>>>>>>>> afaik, there is no way to tell Gradle's AntBuilder to use a JDK >>>>>>>> other than >>>>>>>>> the one that launched Gradle. I think this is why we see a JAXB >>>>>>>> model >>>>>>>>> defined for Java 7, rather than Java 6, because we essentially run >>>>>>>> XJC with >>>>>>>>> Java 8. >>>>>>>>> >>>>>>>>> Anyway, this certainly makes the build more complex and we >>>>>>>> definitely have >>>>>>>>> to think through all these scenarios. In fact after Beta1, one of >>>>>>>> my todos >>>>>>>>> is to build up the build "from scratch" using that >>>>>>>> gradle-mixed-jdk project >>>>>>>>> as a basis. >>>>>>>>> >>>>>>>>> In general the plan though is to run all the tests (other than >>>>>>>>> hibernate-java8, obviously) with the "baseline JDK, whether that >>>>>>>> be Java 6 >>>>>>>>> or 7. >>>>>>>>> >>>>>>>>> On Tue, Mar 31, 2015 at 6:59 PM, Sanne Grinovero < >>>>>>>> sanne(a)hibernate.org&gt; >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> There are many similar issues discussed on the Lucene developer's >>>>>>>>>> mailing list, it's an interesting read: >>>>>>>>>> - >>>>>>>>>> >>>>>>>> http://mail-archives.apache.org/mod_mbox/lucene-dev/201503.mbox/%3C07c401... >>>>>>>>>> >>>>>>>>>> I see no alternative than to have those test jobs actually >>>>>>>> exercising >>>>>>>>>> ORM with JDK6, or maybe even compile it all with JDK6 except the >>>>>>>> Java8 >>>>>>>>>> additional module to be compiled with JDK8 ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 1 April 2015 at 00:36, Steve Ebersole <steve(a)hibernate.org&gt; >>>>>>>> wrote: >>>>>>>>>>> Ahh, seems this may be an option to work around it: >>>>>>>>>>> >>>>>>>>>>> <quote> >>>>>>>>>>> Using the general *Map* interface in place of the concrete >>>>>>>>>>> *ConcurrentHashMap* type here side-steps the coupling to the >>>>>>>> Java 8 >>>>>>>>>> return >>>>>>>>>>> type and will allow this code to be compiled with Java 8 and >>>>>>>> run on >>>>>>>>>> Java 7. >>>>>>>>>>> </quote> >>>>>>>>>>> >>>>>>>>>>> I had missed that part. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> When I say "internal" here, I mean internal to java classes. >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt; >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Nope. It just effects any code compiled with Java 8 even >>>>>>>> though the >>>>>>>>>>>>> change is internal. The problem is the generated bytecode >>>>>>>>>> incorporates >>>>>>>>>>>>> this change. Like I said, this should be compiled with 1.6 >>>>>>>>>> compatibility, >>>>>>>>>>>>> but that is apparently not working atm. I am having a >>>>>>>> struggle >>>>>>>>>> getting a >>>>>>>>>>>>> mixed JDK build working "just right". >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:28 PM, Petar Tahchiev < >>>>>>>>>> paranoiabla(a)gmail.com&gt; >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> According to this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://gist.github.com/AlainODea/1375759b8720a3f9f094 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a >>>>>>>> Set<K> >>>>>>>>>> while >>>>>>>>>>>>>> the 1.8*ConcurrentHashMap#keySet()* returns a >>>>>>>>>>>>>> ConcurrentHashMap.KeySetView<K,V>`. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think you're using some Java8 API. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev < >>>>>>>> paranoiabla(a)gmail.com&gt;: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ java -version >>>>>>>>>>>>>>> java version "1.7.0_71" >>>>>>>>>>>>>>> Java(TM) SE Runtime Environment (build 1.7.0_71-b14) >>>>>>>>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed >>>>>>>> mode) >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ uname -a >>>>>>>>>>>>>>> Linux petar-ThinkPad-X1-Carbon 3.16.0-33-generic #44-Ubuntu >>>>>>>> SMP Thu >>>>>>>>>> Mar >>>>>>>>>>>>>>> 12 12:19:35 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux >>>>>>>>>>>>>>> petar@petar-ThinkPad-X1-Carbon:~$ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> What JRE are you trying to use? This error: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: java.util.concurrent. >>>>>>>>>>>>>>>> ConcurrentHashMap.keySet()Ljava/util/concurrent/ >>>>>>>>>>>>>>>> ConcurrentHashMap$KeySetView; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> is indicative of an issue in cross-jre support due to a >>>>>>>> change >>>>>>>>>>>>>>>> internal to java classes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 6:03 PM, Petar Tahchiev < >>>>>>>>>> paranoiabla(a)gmail.com >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks Steve, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I managed to migrate my configuration to the new >>>>>>>>>>>>>>>>> MetamodelImplementor. Now when I run the scema export I >>>>>>>> get a lot >>>>>>>>>> of these >>>>>>>>>>>>>>>>> warning: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> INFO : HHH000400: Using dialect: >>>>>>>>>> org.hibernate.dialect.MySQL5Dialect >>>>>>>>>>>>>>>>> WARN : JDBC Driver reports it stores quoted identifiers >>>>>>>> in both >>>>>>>>>> mixed >>>>>>>>>>>>>>>>> and upper case >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>>> com.xxx.platform.core.model.cms.AbstractPageModel >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>>> >>>>>>>> com.xxx.platform.module.invoice.core.model.InvoicePageModel >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>>> >>>>>>>> com.xxx.platform.core.model.batch.BatchStepExecutionContextModel >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>>> >>>>>>>> com.xxx.platform.core.model.batch.BatchJobExecutionContextModel >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> com.xxx.platform.module.search.core.model.SearchKeywordRedirectModel >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>>> >>>>>>>> com.xxx.platform.module.search.core.model.SearchPageRedirectModel >>>>>>>>>>>>>>>>> WARN : HHH000072: Duplicate joins for class: >>>>>>>>>>>>>>>>> >>>>>>>> com.xxx.platform.module.promotion.core.model.PromotionModel >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> and when I run some test I get the following exception: >>>>>>>>>>>>>>>>> java.lang.NoSuchMethodError: >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> java.util.concurrent.ConcurrentHashMap.keySet()Ljava/util/concurrent/ConcurrentHashMap$KeySetView; >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> org.hibernate.internal.SessionFactoryImpl.iterateEntityNameResolvers(SessionFactoryImpl.java:733) >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl$CoordinatingEntityNameResolver.resolveEntityName(SessionImpl.java:2470) >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl.guessEntityName(SessionImpl.java:1992) >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl.getEntityPersister(SessionImpl.java:1485) >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:163) >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> org.hibernate.event.internal.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:85) >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>> org.hibernate.internal.SessionImpl.fireMerge(SessionImpl.java:882) >>>>>>>>>>>>>>>>> at >>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:864) >>>>>>>>>>>>>>>>> at >>>>>>>>>> org.hibernate.internal.SessionImpl.merge(SessionImpl.java:869) >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> org.hibernate.jpa.spi.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:1196) >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> org.springframework.batch.item.database.JpaItemWriter.doWrite(JpaItemWriter.java:104) >>>>>>>>>>>>>>>>> at >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> org.springframework.batch.item.database.JpaItemWriter.write(JpaItemWriter.java:83) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2015-04-01 1:23 GMT+03:00 Steve Ebersole < >>>>>>>> steve(a)hibernate.org&gt;: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I am told that the bug does not affect the >>>>>>>> JBoss->Central sync >>>>>>>>>>>>>>>>>> process. So at some point the artifacts should all be >>>>>>>> available >>>>>>>>>> in Central >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:19 PM, Steve Ebersole < >>>>>>>>>> steve(a)hibernate.org >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> hibernate-core seems to be the only artifact that is >>>>>>>> available >>>>>>>>>> in >>>>>>>>>>>>>>>>>>> JBoss Nexus. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:18 PM, Steve Ebersole < >>>>>>>>>>>>>>>>>>> steve(a)hibernate.org&gt; wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> So apparently the artifacts / repo issue is a Nexus >>>>>>>> bug that is >>>>>>>>>>>>>>>>>>>> effecting the JBoss repo (and therefore us)... >>>>>>>>>>>>>>>>>>>> http://issues.sonatype.org/browse/NEXUS-7654 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> As I pointed out in the announcement, I am managing the >>>>>>>>>> "migration >>>>>>>>>>>>>>>>>>>> guide" in source repo while I develop the Betas. See >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat... >>>>>>>>>>>>>>>>>>>> As far are the new bootstrapping apis, see >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBoot... >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBoot... >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev < >>>>>>>>>>>>>>>>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi guys, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I just tried the latest beta and I cannot compile my >>>>>>>> project. >>>>>>>>>>>>>>>>>>>>> With the >>>>>>>>>>>>>>>>>>>>> latest hibernate 4.3.X I was able to do this: >>>>>>>>>>>>>>>>>>>>> ------- >>>>>>>>>>>>>>>>>>>>> final org.hibernate.cfg.Configuration >>>>>>>> configuration = >>>>>>>>>>>>>>>>>>>>> getHibernateConfiguration(); >>>>>>>>>>>>>>>>>>>>> configuration.buildMappings(); >>>>>>>>>>>>>>>>>>>>> final SchemaUpdate schemaUpdate = new >>>>>>>>>>>>>>>>>>>>> SchemaUpdate(configuration); >>>>>>>>>>>>>>>>>>>>> ------- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> however it seems that the SchemaUpdate constructor >>>>>>>> has been >>>>>>>>>>>>>>>>>>>>> removed and now >>>>>>>>>>>>>>>>>>>>> a new one is added: >>>>>>>>>>>>>>>>>>>>> -------- >>>>>>>>>>>>>>>>>>>>> public SchemaUpdate(MetadataImplementor metadata) >>>>>>>> { >>>>>>>>>>>>>>>>>>>>> this( >>>>>>>>>>>>>>>>>>>>> >>>>>>>> metadata.getMetadataBuildingOptions().getServiceRegistry(), >>>>>>>>>>>>>>>>>>>>> metadata ); >>>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>>> --------- >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Also the configuration.buildMappings() method has been >>>>>>>>>>>>>>>>>>>>> deprecated. Where do >>>>>>>>>>>>>>>>>>>>> I get the MetadataImplementor from? Also is there any >>>>>>>>>> changelog I >>>>>>>>>>>>>>>>>>>>> can refer >>>>>>>>>>>>>>>>>>>>> to? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks. >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 >>>>>>>> 8550 C311 >>>>>>>>>>>>>>>>>>>>> 0611 >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>>>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>>>>>>>>>>>> >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>>>>> C311 >>>>>>>>>> 0611 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>>>>> C311 0611 >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Regards, Petar! >>>>>>>>>>>>>> Karlovo, Bulgaria. >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> Public PGP Key at: >>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611 >>>>>>>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 >>>>>>>> C311 0611 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> hibernate-dev mailing list >>>>>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> hibernate-dev mailing list >>>>>>>> hibernate-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev