[hibernate-dev] Trying Hibernate 5.0.0.Beta1

Steve Ebersole steve at hibernate.org
Wed Apr 1 12:09:59 EDT 2015 

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 at hibernate.org> 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 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