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

Because compiling told me that none of the 5.0 bootstrapping packages/classes could be found. Anyway, I am working on simplifying your demo thing into something simpler. On Mon, Apr 6, 2015 at 6:33 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; wrote: > Hmm.. here's the result of mvn dependency:tree -Dverbose > -Dincludes=org.hibernate > > [INFO] --- maven-dependency-plugin:2.9:tree (default-cli) @ HHH-8805 --- > [WARNING] Using Maven 2 dependency tree to get verbose output, which may > be inconsistent with actual Maven 3 resolution > [INFO] org.test:HHH-8805:jar:0.0.1-SNAPSHOT > [INFO] \- > org.springframework.boot:spring-boot-starter-data-jpa:jar:1.2.3.RELEASE:compile > [INFO] \- > org.hibernate:hibernate-entitymanager:jar:5.0.0-SNAPSHOT:compile (version > managed from 4.3.8.Final) > [INFO] \- org.hibernate:hibernate-core:jar:5.0.0-SNAPSHOT:compile > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD SUCCESS > [INFO] > ------------------------------------------------------------------------ > > How do you know it's using 4.3.8? > > 2015-04-06 14:25 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: > >> So your repo is still trying to use Hibernate 4.3.8. So I cannot >> reproduce this. >> >> On top of that, it uses tons of dependencies not needed for a simple bug >> reproducer. >> >> On Mon, Apr 6, 2015 at 5:58 AM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >> >>> So on export the tables simply are not created due to lack of >>> privileges. So that explains why they are not found later. >>> >>> On Mon, Apr 6, 2015 at 5:56 AM, Steve Ebersole <steve(a)hibernate.org&gt; >>> wrote: >>> >>>> Well there is a gigantic comment in org.hibernate.tool.schema. >>>> extract.internal.*legacy*.DatabaseInformationImpl that says how the tableInformationMap >>>> is not used, and why :) >>>> >>>> The problem is the HHH000262 log statement. That is saying that the >>>> tables are not found querying the database metadata. >>>> >>>> On Mon, Apr 6, 2015 at 1:34 AM, Petar Tahchiev <paranoiabla(a)gmail.com&gt; >>>> wrote: >>>> >>>>> Just a quick follow-up here: SchemaMigratorImpl:125 is calling >>>>> existingDatabase.getTableInformation where existingDatabase is of type >>>>> org.hibernate.tool.schema.extract.internal.*legacy*.DatabaseInformationImpl >>>>> (I have no idea why is it using the legacy one), and If I step into it I >>>>> can see it's using a tableInformationMap which is empty - really weird as I >>>>> can see before that the hbm2ddl was reporting tables were not found so I >>>>> was expecting it to create them: >>>>> >>>>> 2015-04-06 09:29:40,608 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: warehouse >>>>> 2015-04-06 09:29:40,610 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: widget_title_lv >>>>> 2015-04-06 09:29:40,614 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: wishlist >>>>> 2015-04-06 09:29:40,618 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: wishlist_entry >>>>> 2015-04-06 09:29:40,622 >>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl >>>>> [main] INFO : HHH000262: Table not found: working_day >>>>> >>>>> >>>>> I'll try to create a test that reproduces the problem >>>>> >>>>> >>>>> 2015-04-06 5:20 GMT+03:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>>> >>>>>> I see you have a test repository reproducing the error. I will try >>>>>> to run from there. >>>>>> >>>>>> On Sun, Apr 5, 2015 at 3:02 AM, Petar Tahchiev < >>>>>> paranoiabla(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Hi Steve, >>>>>>> >>>>>>> the test project that I created still fails with the latest >>>>>>> SNAPSHOT release, although the foreign keys are not created. Can you please >>>>>>> investigate if that is related to the same issue. The test repository is >>>>>>> here: >>>>>>> >>>>>>> https://github.com/paranoiabla/HHH-8805 >>>>>>> >>>>>>> >>>>>>> 2015-04-03 16:15 GMT+03:00 Emmanuel Bernard <emmanuel(a)hibernate.org >>>>>>> >: >>>>>>> >>>>>>>> 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 >>>>>>>> >: >>>>>>>> >> >>>>>>>> >>> 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&gt; >>>>>>>> >>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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 >