[hibernate-dev] Trying Hibernate 5.0.0.Beta1

Gunnar Morling gunnar at hibernate.org
Wed Apr 1 09:32:57 EDT 2015 

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 at 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 at hibernate.org> 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 at hibernate.org>:
>>
>>> 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 at 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/5f6d1d24f7945eb8a5acdb69d9595004ec4e462f
>>>>
>>>>
>>>>
>>>>
>>>> 2015-04-01 9:39 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>>>>
>>>>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>> 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 at hibernate.org>
>>>>>> 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 at hibernate.org>
>>>>>> > 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/%3C07c401d06aba%240b477c80%2421d67580%24%40thetaphi.de%3E
>>>>>> >>
>>>>>> >> 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 at hibernate.org>
>>>>>> 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 at hibernate.org>
>>>>>> >> wrote:
>>>>>> >> >
>>>>>> >> >> When I say "internal" here, I mean internal to java classes.
>>>>>> >> >>
>>>>>> >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole <
>>>>>> steve at hibernate.org>
>>>>>> >> >> 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 at gmail.com>
>>>>>> >> >>> 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 at gmail.com>:
>>>>>> >> >>>>
>>>>>> >> >>>>> petar at 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 at 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 at petar-ThinkPad-X1-Carbon:~$
>>>>>> >> >>>>>
>>>>>> >> >>>>>
>>>>>> >> >>>>> 2015-04-01 2:21 GMT+03:00 Steve Ebersole <
>>>>>> steve at hibernate.org>:
>>>>>> >> >>>>>
>>>>>> >> >>>>>> 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 at 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 at hibernate.org>:
>>>>>> >> >>>>>>>
>>>>>> >> >>>>>>>> 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 at 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 at hibernate.org> 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-migration-guide.md
>>>>>> >> >>>>>>>>>>  As far are the new bootstrapping apis, see
>>>>>> >> >>>>>>>>>>
>>>>>> >>
>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/NativeBootstrapping.html
>>>>>> >> >>>>>>>>>> and
>>>>>> >> >>>>>>>>>>
>>>>>> >>
>>>>>> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html
>>>>>> >> >>>>>>>>>>
>>>>>> >> >>>>>>>>>> On Tue, Mar 31, 2015 at 5:07 PM, Petar Tahchiev <
>>>>>> >> >>>>>>>>>> paranoiabla at gmail.com> 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 at 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 at lists.jboss.org
>>>>>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>

More information about the hibernate-dev mailing list