[hibernate-dev] Trying Hibernate 5.0.0.Beta1
Steve Ebersole
steve at hibernate.org
Wed Apr 1 09:03:50 EDT 2015
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