From gunnar at hibernate.org  Wed Apr  1 02:55:48 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 1 Apr 2015 08:55:48 +0200
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
Message-ID: <CADGJaX_cBO77g8F8dFfxdOyozfQb_4To2620g=bqKxCf5oPWgA@mail.gmail.com>

Hi,

Can you share the exact exception/error you get when using the generated
model with Java 6? The required() attribute already exists as of Java 6 [1].

You should be able to make the generated code Java 6 compatible by either
setting the right options for XJC (the JAXB code generator) or in the worst
case by falling back to an older version of XJC. I had a quick look, this
setting looks promising:

    -target (2.0|2.1): Avoid generating code that relies on any JAXB
2.1|2.2 features. This will allow the generated code to run with JAXB 2.0
runtime (such as JavaSE 6.)

That being said, I think it'd be fine to require Java 7 for ORM 5. OGM,
Search and also many other libraries have done that move by now.

--Gunnar

[1]
http://docs.oracle.com/javase/6/docs/api/javax/xml/bind/annotation/XmlElement.html#required()



2015-04-01 2:04 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> So we now have to deal with a multi-jdk build in Hibernate ORM.  We need
> Java 8 in order to compile the new hibernate-java8 module.
>
> I wanted to remain compatible with Java 6 for the rest.  However, I ran
> into a snag there because of JAXB which we now use (in conjunction with
> StAX) to process XML in ORM.  ANyway, the JAX generation creates a model
> that is only compatible with Java 7.  I have not yet had time to
> investigate this deeply.  But it has to do with a change in the definition
> of javax.xml.bind.annotation.XmlElement and a change in its definition
> between 1.6 and 1.7 to add a new
> attribute javax.xml.bind.annotation.XmlElement#required.
>
> If anyone is familiar with this situation, I'd love to hear some options
> before I spend a lot of time investigating it.
>
> The other option is that we say we are going to drop Java 6 support since
> it has been unsupported now for, what, 3 years?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Apr  1 03:26:08 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 1 Apr 2015 09:26:08 +0200
Subject: [hibernate-dev] Release YML
In-Reply-To: <CAFdSV9uJSUrysw=w5QBn69P9W5OqBeEPAW8zaQMFCoAMU=6QFQ@mail.gmail.com>
References: <CAFdSV9v-F1Fdinx7RUz3jdK+vmxhngEfhV9h1TKL1+p+OVw0eQ@mail.gmail.com>
	<CAFdSV9uJSUrysw=w5QBn69P9W5OqBeEPAW8zaQMFCoAMU=6QFQ@mail.gmail.com>
Message-ID: <CADGJaX_8bEXKVTF9s+Qw4BGbdjfORpUExny4PXgwEqq3c-JhvA@mail.gmail.com>

The job for building the web-site failed because it couldn't retrieve the
hibernate-core POM from Nexus (see [1], not sure why, maybe you did the
web-site push before releasing the artifact in Nexus?).

I've re-triggered the build and it gets past this issue now, but it now
fails apparently to to lack of access rights for hibernate.github.io.git
[2].

@Sanne: It seems one key is still missing from the CI nodes set-up? Can you
add it?

--Gunnar

[1] http://ci.hibernate.org/view/Website/job/www.hibernate.org/179/console
[1] http://ci.hibernate.org/view/Website/job/www.hibernate.org/180/console



2015-04-01 4:43 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> For today's release I added a YML file to both staging staging and verified
> that the staging site picked it up properly.  I then pushed it to the
> production branch, but it is not being displayed there.  Any idea why?
>
>
> https://github.com/hibernate/hibernate.org/blob/production/_data/projects/orm/releases/5.0.0.Beta1.yml
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Apr  1 03:39:44 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 1 Apr 2015 09:39:44 +0200
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
Message-ID: <CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>

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
>

From hardy at hibernate.org  Wed Apr  1 04:40:16 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 1 Apr 2015 10:40:16 +0200
Subject: [hibernate-dev] Release YML
In-Reply-To: <CADGJaX_8bEXKVTF9s+Qw4BGbdjfORpUExny4PXgwEqq3c-JhvA@mail.gmail.com>
References: <CAFdSV9v-F1Fdinx7RUz3jdK+vmxhngEfhV9h1TKL1+p+OVw0eQ@mail.gmail.com>
	<CAFdSV9uJSUrysw=w5QBn69P9W5OqBeEPAW8zaQMFCoAMU=6QFQ@mail.gmail.com>
	<CADGJaX_8bEXKVTF9s+Qw4BGbdjfORpUExny4PXgwEqq3c-JhvA@mail.gmail.com>
Message-ID: <20150401084016.GA86572@Nineveh.lan>

Hi,

On Wed, Apr 01, 2015 at 09:26:08AM +0200, Gunnar Morling wrote:
> The job for building the web-site failed because it couldn't retrieve the
> hibernate-core POM from Nexus (see [1], not sure why, maybe you did the
> web-site push before releasing the artifact in Nexus?).

FYI, part of the site building process is to parse the poms to get some additional
metadata (eg in the case of Search we display the ORM version we built the release against).

I created the issue WEBSITE-300 to document this better in the "Publishing the site" section 
of the documentation.

> I've re-triggered the build and it gets past this issue now, but it now
> fails apparently to to lack of access rights for hibernate.github.io.git

This was probably missed during the latest changes to the infrastructure, right?

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150401/6d35179e/attachment.bin 

From gunnar at hibernate.org  Wed Apr  1 05:32:02 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 1 Apr 2015 11:32:02 +0200
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
Message-ID: <CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>

> 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
>>
>
>

From ales.justin at gmail.com  Wed Apr  1 05:59:55 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Wed, 1 Apr 2015 11:59:55 +0200
Subject: [hibernate-dev] document update change?
Message-ID: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>

Did entity updating changed in HS5 / Lucene4?
(aka Document updating)

Since this used to work for us (with HS4, Lucene3):

---
@Test
public void testProjectionQueriesHandleEntityModificationProperly() throws Exception {
    Entity e = createEntity("test", 1)
        .withProperty("prop", Arrays.asList("aaa", "bbb", "ccc"))
        .store();

    Query query = new Query("test")
        .addProjection(new PropertyProjection("prop", String.class))
        .addSort("prop");

    assertEquals(3, service.prepare(query).asList(withDefaults()).size());

    e = createEntity(e.getKey())
        .withProperty("prop", Arrays.asList("aaa", "bbb"))
        .store();

    assertEquals(2, service.prepare(query).asList(withDefaults()).size());

    service.delete(e.getKey());

    assertEquals(0, service.prepare(query).asList(withDefaults()).size());
}

---

Where we add each list/collection value under same field:

if (propertyValue instanceof Collection) {
    Collection collection = (Collection) propertyValue;
    for (Object element : collection) {
        if (PropertyUtils.isIndexedProperty(element)) {
            final Bridge inner = BridgeUtils.matchBridge(element);
            luceneOptions.addFieldToDocument(propertyName, inner.objectToString(element), document);
        }
    }

---

As it looks like the update still keeps the old values around:

java.lang.AssertionError: expected:<2> but was:<3>
    at org.junit.Assert.fail(Assert.java:88)
    at org.junit.Assert.failNotEquals(Assert.java:743)
    at org.junit.Assert.assertEquals(Assert.java:118)
    at org.junit.Assert.assertEquals(Assert.java:555)
    at org.junit.Assert.assertEquals(Assert.java:542)
    at org.jboss.test.capedwarf.datastore.test.QueryOptimizationsTest.testProjectionQueriesHandleEntityModificationProperly(QueryOptimizationsTest.java:510)

---

Any way to force / fix this?

-Ales


From sanne at hibernate.org  Wed Apr  1 06:07:58 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 1 Apr 2015 11:07:58 +0100
Subject: [hibernate-dev] document update change?
In-Reply-To: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
References: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
Message-ID: <CAFm4XO1JE7gX7Nt-5YxmGk7VJjJNm8ckRH6urZsfckdMNvdG3Q@mail.gmail.com>

Hi Ales,
I expect our Update routines to still work. I don't know what the code
you're showing does though, as those are not our APIs.

If you could share a test using our APIs I'll look at it.

The only thing I can think of is that now there's an explicit FLUSH
type of Work, if you miss that you might hit stale (deleted) values
with a Query.. but this mistake should only be possible if you're
driving the backend directly as our public APIs generate them as
needed.

Thanks,
Sanne

On 1 April 2015 at 10:59, Ales Justin <ales.justin at gmail.com> wrote:
> Did entity updating changed in HS5 / Lucene4?
> (aka Document updating)
>
> Since this used to work for us (with HS4, Lucene3):
>
> ---
> @Test
> public void testProjectionQueriesHandleEntityModificationProperly() throws Exception {
>     Entity e = createEntity("test", 1)
>         .withProperty("prop", Arrays.asList("aaa", "bbb", "ccc"))
>         .store();
>
>     Query query = new Query("test")
>         .addProjection(new PropertyProjection("prop", String.class))
>         .addSort("prop");
>
>     assertEquals(3, service.prepare(query).asList(withDefaults()).size());
>
>     e = createEntity(e.getKey())
>         .withProperty("prop", Arrays.asList("aaa", "bbb"))
>         .store();
>
>     assertEquals(2, service.prepare(query).asList(withDefaults()).size());
>
>     service.delete(e.getKey());
>
>     assertEquals(0, service.prepare(query).asList(withDefaults()).size());
> }
>
> ---
>
> Where we add each list/collection value under same field:
>
> if (propertyValue instanceof Collection) {
>     Collection collection = (Collection) propertyValue;
>     for (Object element : collection) {
>         if (PropertyUtils.isIndexedProperty(element)) {
>             final Bridge inner = BridgeUtils.matchBridge(element);
>             luceneOptions.addFieldToDocument(propertyName, inner.objectToString(element), document);
>         }
>     }
>
> ---
>
> As it looks like the update still keeps the old values around:
>
> java.lang.AssertionError: expected:<2> but was:<3>
>     at org.junit.Assert.fail(Assert.java:88)
>     at org.junit.Assert.failNotEquals(Assert.java:743)
>     at org.junit.Assert.assertEquals(Assert.java:118)
>     at org.junit.Assert.assertEquals(Assert.java:555)
>     at org.junit.Assert.assertEquals(Assert.java:542)
>     at org.jboss.test.capedwarf.datastore.test.QueryOptimizationsTest.testProjectionQueriesHandleEntityModificationProperly(QueryOptimizationsTest.java:510)
>
> ---
>
> Any way to force / fix this?
>
> -Ales
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From paranoiabla at gmail.com  Wed Apr  1 06:32:50 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 13:32:50 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
Message-ID: <CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>

One other thing I noticed:
hibernate-core-5 depends on

<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.2.1.Final</version>

and if you have hibernate-validator 5.1.3.Final (the last stable), it will
depend on

<groupId>org.jboss.logging</groupId>
<artifactId>jboss-logging</artifactId>
<version>3.1.4.GA</version>

So you will get an exception of method not found on some jboss-logging API.
I excluded the jboss-loggin from the hibernate-validator
dependency, but now I get a ton of these TRACE statements (literally every
millisecond):

2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance
2015-04-01 13:28:02,090
org.hibernate.event.internal.DefaultPersistEventListener
[http-nio-8112-exec-9] TRACE: Ignoring persistent instance


 But at least it works.. I guess the only real solution is to have
hibernate-validator use the same jboss-logging version.


2015-04-01 10:39 GMT+03: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
> >
> _______________________________________________
> 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

From ales.justin at gmail.com  Wed Apr  1 06:39:15 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Wed, 1 Apr 2015 12:39:15 +0200
Subject: [hibernate-dev] document update change?
In-Reply-To: <CAFm4XO1JE7gX7Nt-5YxmGk7VJjJNm8ckRH6urZsfckdMNvdG3Q@mail.gmail.com>
References: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
	<CAFm4XO1JE7gX7Nt-5YxmGk7VJjJNm8ckRH6urZsfckdMNvdG3Q@mail.gmail.com>
Message-ID: <9FCCEB14-AEE9-4D22-BD79-5FB861868DF6@gmail.com>

> I expect our Update routines to still work. I don't know what the code
> you're showing does though, as those are not our APIs.
> 
> If you could share a test using our APIs I'll look at it.

What about if you run our test? :-)
(it should be easy -- once you have all CD projects checked-out and built)

> The only thing I can think of is that now there's an explicit FLUSH
> type of Work, if you miss that you might hit stale (deleted) values
> with a Query.. but this mistake should only be possible if you're
> driving the backend directly as our public APIs generate them as
> needed.

Do we need to call this flush explicitly?

As I added Thread::sleep(3000) between update and lookup, and it didn't help.

-Ales


From paranoiabla at gmail.com  Wed Apr  1 06:40:25 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 13:40:25 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
Message-ID: <CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>

Oh,

and one last thing: I don't think this is fixed:
https://hibernate.atlassian.net/browse/HHH-8805

Here's my mapping:

    @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
        CascadeType.PERSIST,
        CascadeType.MERGE,
        CascadeType.REFRESH
    }, fetch = FetchType.LAZY)
    @JoinTable(indexes = {
        @Index(unique = false, columnList = "entity_pk")
    }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
inverseJoinColumns = {
        @JoinColumn(unique = false, nullable = true, insertable = true,
updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
name = "filter_pk")
    }, joinColumns = {
        @JoinColumn(unique = false, nullable = true, insertable = true,
updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
name = "entity_pk")
    }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name =
"entity_filters")
    private Collection<AbstractFilterModelDefinition> filters;

As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is
possible to add it. However here's what the schema tool generates:

    create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters (entity_pk);

    alter table entity_filters
        add constraint FKra38l70n01disvkge7i9ff5ym
        foreign key (filter_pk)
        references abstract_filter (pk);

    alter table entity_filters
        add constraint FKderx50xtd0lkeeblrj3o0ipq9
        foreign key (entity_pk)
        references stock_level (pk);

    alter table entity_filters
        add constraint FK7ery3yx4pg32ogvv1wpr150oq
        foreign key (entity_pk)
        references content_slot (pk);

    alter table entity_filters
        add constraint FKse5m2mj7rrwj8ndimynfnr2px
        foreign key (entity_pk)
        references blog_entry (pk);

    alter table entity_filters
        add constraint FK9nubqtdhrmefjv2a5oab2fcr2
        foreign key (entity_pk)
        references price (pk);

    alter table entity_filters
        add constraint FKcsuwqm524wu4u41oatrcalxvh
        foreign key (entity_pk)
        references tax (pk);

    alter table entity_filters
        add constraint FKmd3mm5pw9naa05ype38m6x1eo
        foreign key (entity_pk)
        references abstract_template (pk);

    alter table entity_filters
        add constraint FKsx6vnh2tga70pkne44dnq8kp0
        foreign key (entity_pk)
        references discount (pk);

    alter table entity_filters
        add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
        foreign key (entity_pk)
        references classification_feature (pk);

    alter table entity_filters
        add constraint FKpoh168do203hfqwb7so7c4c79
        foreign key (entity_pk)
        references cms_navigation_node (pk);

    alter table entity_filters
        add constraint FKi85fkvbm7otl679ijlr6oyoff
        foreign key (entity_pk)
        references product (pk);

    alter table entity_filters
        add constraint FKi8semxf3lq0n12lm05v7oydeq
        foreign key (entity_pk)
        references abstract_page (pk);

    alter table entity_filters
        add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
        foreign key (entity_pk)
        references promotion (pk);

    alter table entity_filters
        add constraint FKfw64whfl6vgbqehj20qmc39i3
        foreign key (entity_pk)
        references simple_cms_widget (pk);

The foreign keys are all different (in Hibernate 4.3.x they were the same),
but I just don't want them. Shall I reopen the issue?


2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:

> One other thing I noticed:
> hibernate-core-5 depends on
>
> <groupId>org.jboss.logging</groupId>
> <artifactId>jboss-logging</artifactId>
> <version>3.2.1.Final</version>
>
> and if you have hibernate-validator 5.1.3.Final (the last stable), it will
> depend on
>
> <groupId>org.jboss.logging</groupId>
> <artifactId>jboss-logging</artifactId>
> <version>3.1.4.GA</version>
>
> So you will get an exception of method not found on some jboss-logging
> API. I excluded the jboss-loggin from the hibernate-validator
> dependency, but now I get a ton of these TRACE statements (literally every
> millisecond):
>
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>
>
>  But at least it works.. I guess the only real solution is to have
> hibernate-validator use the same jboss-logging version.
>
>
> 2015-04-01 10:39 GMT+03: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
>> >
>> _______________________________________________
>> 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

From sanne at hibernate.org  Wed Apr  1 06:45:55 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 1 Apr 2015 11:45:55 +0100
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
Message-ID: <CAFm4XO3HFsWyF2Ox6_1KGSSzUKJrRFMf7JXZDpf9dm3OaSE=Vg@mail.gmail.com>

Hi Petar,
the version issue of jboss-logging is a known limitation; I've
described some details on the wildfly-dev mailing list.
I was expecting for people to choose the most up to date version of
jboss-logging in case of conflicting versions though, or manage the
version explicitly rather than leaving the choice to the build tool.

The TRACE problem was not expected of course. May I assume you have
the TRACE level enabled?

Thanks,
Sanne

On 1 April 2015 at 11:32, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> One other thing I noticed:
> hibernate-core-5 depends on
>
> <groupId>org.jboss.logging</groupId>
> <artifactId>jboss-logging</artifactId>
> <version>3.2.1.Final</version>
>
> and if you have hibernate-validator 5.1.3.Final (the last stable), it will
> depend on
>
> <groupId>org.jboss.logging</groupId>
> <artifactId>jboss-logging</artifactId>
> <version>3.1.4.GA</version>
>
> So you will get an exception of method not found on some jboss-logging API.
> I excluded the jboss-loggin from the hibernate-validator
> dependency, but now I get a ton of these TRACE statements (literally every
> millisecond):
>
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> 2015-04-01 13:28:02,090
> org.hibernate.event.internal.DefaultPersistEventListener
> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>
>
>  But at least it works.. I guess the only real solution is to have
> hibernate-validator use the same jboss-logging version.
>
>
> 2015-04-01 10:39 GMT+03: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
>> >
>> _______________________________________________
>> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Wed Apr  1 06:49:48 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 1 Apr 2015 11:49:48 +0100
Subject: [hibernate-dev] document update change?
In-Reply-To: <9FCCEB14-AEE9-4D22-BD79-5FB861868DF6@gmail.com>
References: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
	<CAFm4XO1JE7gX7Nt-5YxmGk7VJjJNm8ckRH6urZsfckdMNvdG3Q@mail.gmail.com>
	<9FCCEB14-AEE9-4D22-BD79-5FB861868DF6@gmail.com>
Message-ID: <CAFm4XO3qC8eBzWB=zqFrmOtJauAECFwkDZ+B7yd5c3_M6itETg@mail.gmail.com>

On 1 April 2015 at 11:39, Ales Justin <ales.justin at gmail.com> wrote:
>> I expect our Update routines to still work. I don't know what the code
>> you're showing does though, as those are not our APIs.
>>
>> If you could share a test using our APIs I'll look at it.
>
> What about if you run our test? :-)
> (it should be easy -- once you have all CD projects checked-out and built)

Sorry I won't have time this week, I'll be on holidays next week, and
then probably have to catch up the week after. If you're happy to wait
a month, ok.

>> The only thing I can think of is that now there's an explicit FLUSH
>> type of Work, if you miss that you might hit stale (deleted) values
>> with a Query.. but this mistake should only be possible if you're
>> driving the backend directly as our public APIs generate them as
>> needed.
>
> Do we need to call this flush explicitly?

Yes

> As I added Thread::sleep(3000) between update and lookup, and it didn't help.

It's event based, not time sensitive.

>
> -Ales
>

From paranoiabla at gmail.com  Wed Apr  1 06:54:48 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 13:54:48 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFm4XO3HFsWyF2Ox6_1KGSSzUKJrRFMf7JXZDpf9dm3OaSE=Vg@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAFm4XO3HFsWyF2Ox6_1KGSSzUKJrRFMf7JXZDpf9dm3OaSE=Vg@mail.gmail.com>
Message-ID: <CAKnbemW7BbYYjXdpsuy18qZpToHsnASpgV2eZ-ehhjc+hxs9vA@mail.gmail.com>

Frankly I don't know if it is enabled or how to enable it :) I'm using
spring-boot with log4j2 as a logging implementation and It was working
perfectly fine with hibernate 4.3.8.Final and hibernate-validator
5.1.3.Final

2015-04-01 13:45 GMT+03:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi Petar,
> the version issue of jboss-logging is a known limitation; I've
> described some details on the wildfly-dev mailing list.
> I was expecting for people to choose the most up to date version of
> jboss-logging in case of conflicting versions though, or manage the
> version explicitly rather than leaving the choice to the build tool.
>
> The TRACE problem was not expected of course. May I assume you have
> the TRACE level enabled?
>
> Thanks,
> Sanne
>
> On 1 April 2015 at 11:32, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> > One other thing I noticed:
> > hibernate-core-5 depends on
> >
> > <groupId>org.jboss.logging</groupId>
> > <artifactId>jboss-logging</artifactId>
> > <version>3.2.1.Final</version>
> >
> > and if you have hibernate-validator 5.1.3.Final (the last stable), it
> will
> > depend on
> >
> > <groupId>org.jboss.logging</groupId>
> > <artifactId>jboss-logging</artifactId>
> > <version>3.1.4.GA</version>
> >
> > So you will get an exception of method not found on some jboss-logging
> API.
> > I excluded the jboss-loggin from the hibernate-validator
> > dependency, but now I get a ton of these TRACE statements (literally
> every
> > millisecond):
> >
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> > 2015-04-01 13:28:02,090
> > org.hibernate.event.internal.DefaultPersistEventListener
> > [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
> >
> >
> >  But at least it works.. I guess the only real solution is to have
> > hibernate-validator use the same jboss-logging version.
> >
> >
> > 2015-04-01 10:39 GMT+03: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
> >> >
> >> _______________________________________________
> >> 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
> > _______________________________________________
> > 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

From ales.justin at gmail.com  Wed Apr  1 06:58:59 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Wed, 1 Apr 2015 12:58:59 +0200
Subject: [hibernate-dev] document update change?
In-Reply-To: <CAFm4XO3qC8eBzWB=zqFrmOtJauAECFwkDZ+B7yd5c3_M6itETg@mail.gmail.com>
References: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
	<CAFm4XO1JE7gX7Nt-5YxmGk7VJjJNm8ckRH6urZsfckdMNvdG3Q@mail.gmail.com>
	<9FCCEB14-AEE9-4D22-BD79-5FB861868DF6@gmail.com>
	<CAFm4XO3qC8eBzWB=zqFrmOtJauAECFwkDZ+B7yd5c3_M6itETg@mail.gmail.com>
Message-ID: <489B0F8E-0A1D-4D9A-9F13-B84D91BE3925@gmail.com>

>>> I expect our Update routines to still work. I don't know what the code
>>> you're showing does though, as those are not our APIs.
>>> 
>>> If you could share a test using our APIs I'll look at it.
>> 
>> What about if you run our test? :-)
>> (it should be easy -- once you have all CD projects checked-out and built)
> 
> Sorry I won't have time this week, I'll be on holidays next week, and
> then probably have to catch up the week after. If you're happy to wait
> a month, ok.

A month ... geez ... :-)

>>> The only thing I can think of is that now there's an explicit FLUSH
>>> type of Work, if you miss that you might hit stale (deleted) values
>>> with a Query.. but this mistake should only be possible if you're
>>> driving the backend directly as our public APIs generate them as
>>> needed.
>> 
>> Do we need to call this flush explicitly?
> 
> Yes

Ah, OK, we might be missing this (not 100% though ...).

Where / when / on-what do we need to call this?

-Ales


From steve at hibernate.org  Wed Apr  1 07:18:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 06:18:27 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
Message-ID: <CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>

Hmm, it seems I inadvertently set the wrong fix version on HHH-8805.  It is
fixed in our metamodel branch which is 6.0.  I pulled the necessary
metamodel (org.hibernate.mapping) changes back to master (5.0), but only
the hbm.xml form of naming the FK "none" (magic value) is supported to
truly disable generation.  For the time being you can use this as well from
annotations; just name the FK "none".

If you can write some tests for this, it will make it easier for me to
implement.



On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Oh,
>
> and one last thing: I don't think this is fixed:
> https://hibernate.atlassian.net/browse/HHH-8805
>
> Here's my mapping:
>
>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>         CascadeType.PERSIST,
>         CascadeType.MERGE,
>         CascadeType.REFRESH
>     }, fetch = FetchType.LAZY)
>     @JoinTable(indexes = {
>         @Index(unique = false, columnList = "entity_pk")
>     }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
> inverseJoinColumns = {
>         @JoinColumn(unique = false, nullable = true, insertable = true,
> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
> name = "filter_pk")
>     }, joinColumns = {
>         @JoinColumn(unique = false, nullable = true, insertable = true,
> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
> name = "entity_pk")
>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name =
> "entity_filters")
>     private Collection<AbstractFilterModelDefinition> filters;
>
> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is
> possible to add it. However here's what the schema tool generates:
>
>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
> (entity_pk);
>
>     alter table entity_filters
>         add constraint FKra38l70n01disvkge7i9ff5ym
>         foreign key (filter_pk)
>         references abstract_filter (pk);
>
>     alter table entity_filters
>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>         foreign key (entity_pk)
>         references stock_level (pk);
>
>     alter table entity_filters
>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>         foreign key (entity_pk)
>         references content_slot (pk);
>
>     alter table entity_filters
>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>         foreign key (entity_pk)
>         references blog_entry (pk);
>
>     alter table entity_filters
>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>         foreign key (entity_pk)
>         references price (pk);
>
>     alter table entity_filters
>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>         foreign key (entity_pk)
>         references tax (pk);
>
>     alter table entity_filters
>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>         foreign key (entity_pk)
>         references abstract_template (pk);
>
>     alter table entity_filters
>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>         foreign key (entity_pk)
>         references discount (pk);
>
>     alter table entity_filters
>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>         foreign key (entity_pk)
>         references classification_feature (pk);
>
>     alter table entity_filters
>         add constraint FKpoh168do203hfqwb7so7c4c79
>         foreign key (entity_pk)
>         references cms_navigation_node (pk);
>
>     alter table entity_filters
>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>         foreign key (entity_pk)
>         references product (pk);
>
>     alter table entity_filters
>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>         foreign key (entity_pk)
>         references abstract_page (pk);
>
>     alter table entity_filters
>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>         foreign key (entity_pk)
>         references promotion (pk);
>
>     alter table entity_filters
>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>         foreign key (entity_pk)
>         references simple_cms_widget (pk);
>
> The foreign keys are all different (in Hibernate 4.3.x they were the
> same), but I just don't want them. Shall I reopen the issue?
>
>
> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>
>> One other thing I noticed:
>> hibernate-core-5 depends on
>>
>> <groupId>org.jboss.logging</groupId>
>> <artifactId>jboss-logging</artifactId>
>> <version>3.2.1.Final</version>
>>
>> and if you have hibernate-validator 5.1.3.Final (the last stable), it
>> will depend on
>>
>> <groupId>org.jboss.logging</groupId>
>> <artifactId>jboss-logging</artifactId>
>> <version>3.1.4.GA</version>
>>
>> So you will get an exception of method not found on some jboss-logging
>> API. I excluded the jboss-loggin from the hibernate-validator
>> dependency, but now I get a ton of these TRACE statements (literally
>> every millisecond):
>>
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>> 2015-04-01 13:28:02,090
>> org.hibernate.event.internal.DefaultPersistEventListener
>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>
>>
>>  But at least it works.. I guess the only real solution is to have
>> hibernate-validator use the same jboss-logging version.
>>
>>
>> 2015-04-01 10:39 GMT+03: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
>>> >
>>> _______________________________________________
>>> 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
>

From steve at hibernate.org  Wed Apr  1 07:20:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 06:20:00 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
Message-ID: <CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>

And no, we generally do not reopen issues from Closed state.  And here,
given the different branches, I'd be more inclined to create a different
issue referencing the original.

On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Hmm, it seems I inadvertently set the wrong fix version on HHH-8805.  It
> is fixed in our metamodel branch which is 6.0.  I pulled the necessary
> metamodel (org.hibernate.mapping) changes back to master (5.0), but only
> the hbm.xml form of naming the FK "none" (magic value) is supported to
> truly disable generation.  For the time being you can use this as well from
> annotations; just name the FK "none".
>
> If you can write some tests for this, it will make it easier for me to
> implement.
>
>
>
> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Oh,
>>
>> and one last thing: I don't think this is fixed:
>> https://hibernate.atlassian.net/browse/HHH-8805
>>
>> Here's my mapping:
>>
>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>         CascadeType.PERSIST,
>>         CascadeType.MERGE,
>>         CascadeType.REFRESH
>>     }, fetch = FetchType.LAZY)
>>     @JoinTable(indexes = {
>>         @Index(unique = false, columnList = "entity_pk")
>>     }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>> inverseJoinColumns = {
>>         @JoinColumn(unique = false, nullable = true, insertable = true,
>> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>> name = "filter_pk")
>>     }, joinColumns = {
>>         @JoinColumn(unique = false, nullable = true, insertable = true,
>> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>> name = "entity_pk")
>>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name =
>> "entity_filters")
>>     private Collection<AbstractFilterModelDefinition> filters;
>>
>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is
>> possible to add it. However here's what the schema tool generates:
>>
>>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>> (entity_pk);
>>
>>     alter table entity_filters
>>         add constraint FKra38l70n01disvkge7i9ff5ym
>>         foreign key (filter_pk)
>>         references abstract_filter (pk);
>>
>>     alter table entity_filters
>>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>>         foreign key (entity_pk)
>>         references stock_level (pk);
>>
>>     alter table entity_filters
>>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>>         foreign key (entity_pk)
>>         references content_slot (pk);
>>
>>     alter table entity_filters
>>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>>         foreign key (entity_pk)
>>         references blog_entry (pk);
>>
>>     alter table entity_filters
>>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>>         foreign key (entity_pk)
>>         references price (pk);
>>
>>     alter table entity_filters
>>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>>         foreign key (entity_pk)
>>         references tax (pk);
>>
>>     alter table entity_filters
>>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>>         foreign key (entity_pk)
>>         references abstract_template (pk);
>>
>>     alter table entity_filters
>>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>>         foreign key (entity_pk)
>>         references discount (pk);
>>
>>     alter table entity_filters
>>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>>         foreign key (entity_pk)
>>         references classification_feature (pk);
>>
>>     alter table entity_filters
>>         add constraint FKpoh168do203hfqwb7so7c4c79
>>         foreign key (entity_pk)
>>         references cms_navigation_node (pk);
>>
>>     alter table entity_filters
>>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>>         foreign key (entity_pk)
>>         references product (pk);
>>
>>     alter table entity_filters
>>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>>         foreign key (entity_pk)
>>         references abstract_page (pk);
>>
>>     alter table entity_filters
>>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>>         foreign key (entity_pk)
>>         references promotion (pk);
>>
>>     alter table entity_filters
>>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>>         foreign key (entity_pk)
>>         references simple_cms_widget (pk);
>>
>> The foreign keys are all different (in Hibernate 4.3.x they were the
>> same), but I just don't want them. Shall I reopen the issue?
>>
>>
>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>
>>> One other thing I noticed:
>>> hibernate-core-5 depends on
>>>
>>> <groupId>org.jboss.logging</groupId>
>>> <artifactId>jboss-logging</artifactId>
>>> <version>3.2.1.Final</version>
>>>
>>> and if you have hibernate-validator 5.1.3.Final (the last stable), it
>>> will depend on
>>>
>>> <groupId>org.jboss.logging</groupId>
>>> <artifactId>jboss-logging</artifactId>
>>> <version>3.1.4.GA</version>
>>>
>>> So you will get an exception of method not found on some jboss-logging
>>> API. I excluded the jboss-loggin from the hibernate-validator
>>> dependency, but now I get a ton of these TRACE statements (literally
>>> every millisecond):
>>>
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>> 2015-04-01 13:28:02,090
>>> org.hibernate.event.internal.DefaultPersistEventListener
>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>
>>>
>>>  But at least it works.. I guess the only real solution is to have
>>> hibernate-validator use the same jboss-logging version.
>>>
>>>
>>> 2015-04-01 10:39 GMT+03: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
>>>> >
>>>> _______________________________________________
>>>> 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
>>
>
>

From steve at hibernate.org  Wed Apr  1 07:22:22 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 06:22:22 -0500
Subject: [hibernate-dev] Release YML
In-Reply-To: <CADGJaX_8bEXKVTF9s+Qw4BGbdjfORpUExny4PXgwEqq3c-JhvA@mail.gmail.com>
References: <CAFdSV9v-F1Fdinx7RUz3jdK+vmxhngEfhV9h1TKL1+p+OVw0eQ@mail.gmail.com>
	<CAFdSV9uJSUrysw=w5QBn69P9W5OqBeEPAW8zaQMFCoAMU=6QFQ@mail.gmail.com>
	<CADGJaX_8bEXKVTF9s+Qw4BGbdjfORpUExny4PXgwEqq3c-JhvA@mail.gmail.com>
Message-ID: <CAFdSV9vnfT=JFO3_4veLCy70wMcDqftUymZFSi21vJzxzX31qg@mail.gmail.com>

No.  You know why it could not find the POM ;)

On Wed, Apr 1, 2015 at 2:26 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> The job for building the web-site failed because it couldn't retrieve the
> hibernate-core POM from Nexus (see [1], not sure why, maybe you did the
> web-site push before releasing the artifact in Nexus?).
>
> I've re-triggered the build and it gets past this issue now, but it now
> fails apparently to to lack of access rights for hibernate.github.io.git
> [2].
>
> @Sanne: It seems one key is still missing from the CI nodes set-up? Can
> you add it?
>
> --Gunnar
>
> [1] http://ci.hibernate.org/view/Website/job/www.hibernate.org/179/console
> [1] http://ci.hibernate.org/view/Website/job/www.hibernate.org/180/console
>
>
>
> 2015-04-01 4:43 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> For today's release I added a YML file to both staging staging and
>> verified
>> that the staging site picked it up properly.  I then pushed it to the
>> production branch, but it is not being displayed there.  Any idea why?
>>
>>
>> https://github.com/hibernate/hibernate.org/blob/production/_data/projects/orm/releases/5.0.0.Beta1.yml
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From hardy at hibernate.org  Wed Apr  1 07:25:51 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 1 Apr 2015 13:25:51 +0200
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFm4XO3HFsWyF2Ox6_1KGSSzUKJrRFMf7JXZDpf9dm3OaSE=Vg@mail.gmail.com>
References: <CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAFm4XO3HFsWyF2Ox6_1KGSSzUKJrRFMf7JXZDpf9dm3OaSE=Vg@mail.gmail.com>
Message-ID: <20150401112551.GA87097@Nineveh.lan>

Hi,

On Wed, Apr 01, 2015 at 11:45:55AM +0100, Sanne Grinovero wrote:
> the version issue of jboss-logging is a known limitation; I've
> described some details on the wildfly-dev mailing list.
> I was expecting for people to choose the most up to date version of
> jboss-logging in case of conflicting versions though, or manage the
> version explicitly rather than leaving the choice to the build tool.

I would also expect that choosing the latest jboss-logging version should
work. Have you tried explicitly adding jboss-logging as dependency? 
That said, excluding the transitive jboss-logging dependency from validator
should work as well. Did you run 'mvn dependency:tree' to see what the resulting
dependencies are in your project? 

You could also try to use Hibernate Validator 5.2.0.Beta1. In relation to any
5.1 features, there should be no difference and I consider it stable. 

> The TRACE problem was not expected of course. May I assume you have
> the TRACE level enabled?

How does your log configuration look like?

--Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150401/e040fd88/attachment.bin 

From steve at hibernate.org  Wed Apr  1 07:32:36 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 06:32:36 -0500
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CADGJaX_cBO77g8F8dFfxdOyozfQb_4To2620g=bqKxCf5oPWgA@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CADGJaX_cBO77g8F8dFfxdOyozfQb_4To2620g=bqKxCf5oPWgA@mail.gmail.com>
Message-ID: <CAFdSV9vbqOsH5bAn2MkAWNzqhACf9Pwzv8KDMedQieEiu_Pt6A@mail.gmail.com>

Sorry, wrong class...  XmlElementRef, not XmlElement:

/home/sebersole/projects/hibernate/hibernate-orm/hibernate-core/target/generated-src/jaxb/main/org/hibernate/boot/jaxb/hbm/spi/JaxbHbmFilterType.java:57:
error: cannot find symbol
    @XmlElementRef(name = "aliases", namespace = "
http://www.hibernate.org/xsd/orm/hbm", type = JAXBElement.class, required =
false)

                                                  ^
  symbol:   method required()
  location: @interface XmlElementRef


If we decide to stick with support for Java 6, I will try to incorporate
this -target option.  Thanks!



On Wed, Apr 1, 2015 at 1:55 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> Can you share the exact exception/error you get when using the generated
> model with Java 6? The required() attribute already exists as of Java 6 [1].
>
> You should be able to make the generated code Java 6 compatible by either
> setting the right options for XJC (the JAXB code generator) or in the worst
> case by falling back to an older version of XJC. I had a quick look, this
> setting looks promising:
>
>     -target (2.0|2.1): Avoid generating code that relies on any JAXB
> 2.1|2.2 features. This will allow the generated code to run with JAXB 2.0
> runtime (such as JavaSE 6.)
>
> That being said, I think it'd be fine to require Java 7 for ORM 5. OGM,
> Search and also many other libraries have done that move by now.
>
> --Gunnar
>
> [1]
> http://docs.oracle.com/javase/6/docs/api/javax/xml/bind/annotation/XmlElement.html#required()
>
>
>
> 2015-04-01 2:04 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> So we now have to deal with a multi-jdk build in Hibernate ORM.  We need
>> Java 8 in order to compile the new hibernate-java8 module.
>>
>> I wanted to remain compatible with Java 6 for the rest.  However, I ran
>> into a snag there because of JAXB which we now use (in conjunction with
>> StAX) to process XML in ORM.  ANyway, the JAX generation creates a model
>> that is only compatible with Java 7.  I have not yet had time to
>> investigate this deeply.  But it has to do with a change in the definition
>> of javax.xml.bind.annotation.XmlElement and a change in its definition
>> between 1.6 and 1.7 to add a new
>> attribute javax.xml.bind.annotation.XmlElement#required.
>>
>> If anyone is familiar with this situation, I'd love to hear some options
>> before I spend a lot of time investigating it.
>>
>> The other option is that we say we are going to drop Java 6 support since
>> it has been unsupported now for, what, 3 years?
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Wed Apr  1 07:34:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 06:34:09 -0500
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
Message-ID: <CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>

Baseline on Java 8?  Hmm... Well thanks for tempting me :)

What do you mean by "be able to experiment with significant API
improvements"?

On Tue, Mar 31, 2015 at 7:18 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I wouldn't disagree on requiring Java 7.
> I probably wouldn't disagree with Java 8 either, after all we're not
> removing older versions of Hibernate from any download location and
> we'll still support and maintain some older versions. It would
> actually be nice to have the latest ORM version to be able to
> experiment with significant API improvements.
>
> FYI Hibernate Search is requiring Java 7 already, and our CI servers
> are already testing our projects with JDK9 as well.
>
> That said, Java 6 is still being supported by some vendors. Not by
> Oracle, but Red Hat and SAP will support it for much longer.
>
> -- Sanne
>
> On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org> wrote:
> > So we now have to deal with a multi-jdk build in Hibernate ORM.  We need
> > Java 8 in order to compile the new hibernate-java8 module.
> >
> > I wanted to remain compatible with Java 6 for the rest.  However, I ran
> > into a snag there because of JAXB which we now use (in conjunction with
> > StAX) to process XML in ORM.  ANyway, the JAX generation creates a model
> > that is only compatible with Java 7.  I have not yet had time to
> > investigate this deeply.  But it has to do with a change in the
> definition
> > of javax.xml.bind.annotation.XmlElement and a change in its definition
> > between 1.6 and 1.7 to add a new
> > attribute javax.xml.bind.annotation.XmlElement#required.
> >
> > If anyone is familiar with this situation, I'd love to hear some options
> > before I spend a lot of time investigating it.
> >
> > The other option is that we say we are going to drop Java 6 support since
> > it has been unsupported now for, what, 3 years?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Apr  1 07:36:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 06:36:11 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
	<CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
Message-ID: <CAFdSV9sVUfw+rVNcJwMxj1Jx9CQ=ceh_DZiBuFQtfJ2WsJDeMQ@mail.gmail.com>

https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66093

On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve at hibernate.org> wrote:

> And no, we generally do not reopen issues from Closed state.  And here,
> given the different branches, I'd be more inclined to create a different
> issue referencing the original.
>
> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Hmm, it seems I inadvertently set the wrong fix version on HHH-8805.  It
>> is fixed in our metamodel branch which is 6.0.  I pulled the necessary
>> metamodel (org.hibernate.mapping) changes back to master (5.0), but only
>> the hbm.xml form of naming the FK "none" (magic value) is supported to
>> truly disable generation.  For the time being you can use this as well from
>> annotations; just name the FK "none".
>>
>> If you can write some tests for this, it will make it easier for me to
>> implement.
>>
>>
>>
>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Oh,
>>>
>>> and one last thing: I don't think this is fixed:
>>> https://hibernate.atlassian.net/browse/HHH-8805
>>>
>>> Here's my mapping:
>>>
>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>>         CascadeType.PERSIST,
>>>         CascadeType.MERGE,
>>>         CascadeType.REFRESH
>>>     }, fetch = FetchType.LAZY)
>>>     @JoinTable(indexes = {
>>>         @Index(unique = false, columnList = "entity_pk")
>>>     }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>> inverseJoinColumns = {
>>>         @JoinColumn(unique = false, nullable = true, insertable = true,
>>> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>> name = "filter_pk")
>>>     }, joinColumns = {
>>>         @JoinColumn(unique = false, nullable = true, insertable = true,
>>> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>> name = "entity_pk")
>>>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name =
>>> "entity_filters")
>>>     private Collection<AbstractFilterModelDefinition> filters;
>>>
>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is
>>> possible to add it. However here's what the schema tool generates:
>>>
>>>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>>> (entity_pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKra38l70n01disvkge7i9ff5ym
>>>         foreign key (filter_pk)
>>>         references abstract_filter (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>>>         foreign key (entity_pk)
>>>         references stock_level (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>>>         foreign key (entity_pk)
>>>         references content_slot (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>>>         foreign key (entity_pk)
>>>         references blog_entry (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>>>         foreign key (entity_pk)
>>>         references price (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>>>         foreign key (entity_pk)
>>>         references tax (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>>>         foreign key (entity_pk)
>>>         references abstract_template (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>>>         foreign key (entity_pk)
>>>         references discount (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>>>         foreign key (entity_pk)
>>>         references classification_feature (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKpoh168do203hfqwb7so7c4c79
>>>         foreign key (entity_pk)
>>>         references cms_navigation_node (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>>>         foreign key (entity_pk)
>>>         references product (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>>>         foreign key (entity_pk)
>>>         references abstract_page (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>>>         foreign key (entity_pk)
>>>         references promotion (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>>>         foreign key (entity_pk)
>>>         references simple_cms_widget (pk);
>>>
>>> The foreign keys are all different (in Hibernate 4.3.x they were the
>>> same), but I just don't want them. Shall I reopen the issue?
>>>
>>>
>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>
>>>> One other thing I noticed:
>>>> hibernate-core-5 depends on
>>>>
>>>> <groupId>org.jboss.logging</groupId>
>>>> <artifactId>jboss-logging</artifactId>
>>>> <version>3.2.1.Final</version>
>>>>
>>>> and if you have hibernate-validator 5.1.3.Final (the last stable), it
>>>> will depend on
>>>>
>>>> <groupId>org.jboss.logging</groupId>
>>>> <artifactId>jboss-logging</artifactId>
>>>> <version>3.1.4.GA</version>
>>>>
>>>> So you will get an exception of method not found on some jboss-logging
>>>> API. I excluded the jboss-loggin from the hibernate-validator
>>>> dependency, but now I get a ton of these TRACE statements (literally
>>>> every millisecond):
>>>>
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>
>>>>
>>>>  But at least it works.. I guess the only real solution is to have
>>>> hibernate-validator use the same jboss-logging version.
>>>>
>>>>
>>>> 2015-04-01 10:39 GMT+03: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
>>>>> >
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>>
>

From steve at hibernate.org  Wed Apr  1 07:44:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 06:44:28 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
	<CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
Message-ID: <CAFdSV9u4EezEyVOLSCs=hkW77aSF3+9ScBgrMJ628jXX+B8m8g@mail.gmail.com>

https://hibernate.atlassian.net/browse/HHH-9704

On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve at hibernate.org> wrote:

> And no, we generally do not reopen issues from Closed state.  And here,
> given the different branches, I'd be more inclined to create a different
> issue referencing the original.
>
> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Hmm, it seems I inadvertently set the wrong fix version on HHH-8805.  It
>> is fixed in our metamodel branch which is 6.0.  I pulled the necessary
>> metamodel (org.hibernate.mapping) changes back to master (5.0), but only
>> the hbm.xml form of naming the FK "none" (magic value) is supported to
>> truly disable generation.  For the time being you can use this as well from
>> annotations; just name the FK "none".
>>
>> If you can write some tests for this, it will make it easier for me to
>> implement.
>>
>>
>>
>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Oh,
>>>
>>> and one last thing: I don't think this is fixed:
>>> https://hibernate.atlassian.net/browse/HHH-8805
>>>
>>> Here's my mapping:
>>>
>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>>         CascadeType.PERSIST,
>>>         CascadeType.MERGE,
>>>         CascadeType.REFRESH
>>>     }, fetch = FetchType.LAZY)
>>>     @JoinTable(indexes = {
>>>         @Index(unique = false, columnList = "entity_pk")
>>>     }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>> inverseJoinColumns = {
>>>         @JoinColumn(unique = false, nullable = true, insertable = true,
>>> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>> name = "filter_pk")
>>>     }, joinColumns = {
>>>         @JoinColumn(unique = false, nullable = true, insertable = true,
>>> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>> name = "entity_pk")
>>>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name =
>>> "entity_filters")
>>>     private Collection<AbstractFilterModelDefinition> filters;
>>>
>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is
>>> possible to add it. However here's what the schema tool generates:
>>>
>>>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>>> (entity_pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKra38l70n01disvkge7i9ff5ym
>>>         foreign key (filter_pk)
>>>         references abstract_filter (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>>>         foreign key (entity_pk)
>>>         references stock_level (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>>>         foreign key (entity_pk)
>>>         references content_slot (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>>>         foreign key (entity_pk)
>>>         references blog_entry (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>>>         foreign key (entity_pk)
>>>         references price (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>>>         foreign key (entity_pk)
>>>         references tax (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>>>         foreign key (entity_pk)
>>>         references abstract_template (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>>>         foreign key (entity_pk)
>>>         references discount (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>>>         foreign key (entity_pk)
>>>         references classification_feature (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKpoh168do203hfqwb7so7c4c79
>>>         foreign key (entity_pk)
>>>         references cms_navigation_node (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>>>         foreign key (entity_pk)
>>>         references product (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>>>         foreign key (entity_pk)
>>>         references abstract_page (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>>>         foreign key (entity_pk)
>>>         references promotion (pk);
>>>
>>>     alter table entity_filters
>>>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>>>         foreign key (entity_pk)
>>>         references simple_cms_widget (pk);
>>>
>>> The foreign keys are all different (in Hibernate 4.3.x they were the
>>> same), but I just don't want them. Shall I reopen the issue?
>>>
>>>
>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>
>>>> One other thing I noticed:
>>>> hibernate-core-5 depends on
>>>>
>>>> <groupId>org.jboss.logging</groupId>
>>>> <artifactId>jboss-logging</artifactId>
>>>> <version>3.2.1.Final</version>
>>>>
>>>> and if you have hibernate-validator 5.1.3.Final (the last stable), it
>>>> will depend on
>>>>
>>>> <groupId>org.jboss.logging</groupId>
>>>> <artifactId>jboss-logging</artifactId>
>>>> <version>3.1.4.GA</version>
>>>>
>>>> So you will get an exception of method not found on some jboss-logging
>>>> API. I excluded the jboss-loggin from the hibernate-validator
>>>> dependency, but now I get a ton of these TRACE statements (literally
>>>> every millisecond):
>>>>
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>> 2015-04-01 13:28:02,090
>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>
>>>>
>>>>  But at least it works.. I guess the only real solution is to have
>>>> hibernate-validator use the same jboss-logging version.
>>>>
>>>>
>>>> 2015-04-01 10:39 GMT+03: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
>>>>> >
>>>>> _______________________________________________
>>>>> 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
>>>
>>
>>
>

From steve at hibernate.org  Wed Apr  1 07:48:45 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 06:48:45 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
Message-ID: <CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>

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
>>>
>>
>>
>

From gunnar at hibernate.org  Wed Apr  1 08:59:12 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 1 Apr 2015 14:59:12 +0200
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
Message-ID: <CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>

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
>>>>
>>>
>>>
>>
>

From paranoiabla at gmail.com  Wed Apr  1 09:02:24 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 1 Apr 2015 16:02:24 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9sVUfw+rVNcJwMxj1Jx9CQ=ceh_DZiBuFQtfJ2WsJDeMQ@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
	<CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
	<CAFdSV9sVUfw+rVNcJwMxj1Jx9CQ=ceh_DZiBuFQtfJ2WsJDeMQ@mail.gmail.com>
Message-ID: <CAKnbemXsM=z1Y1J8qkTC-znfFT_jfQazDtBNMukHaQWT-aat5w@mail.gmail.com>

OK, maybe I'm doing something wrong. I also tried setting the foreign key
name to "none" like this:

    @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch =
FetchType.LAZY)
    @JoinTable(inverseJoinColumns = {
                    @JoinColumn(unique = false, nullable = true, insertable
= true, updatable = true, foreignKey = @ForeignKey(name = "none", value =
ConstraintMode.NO_CONSTRAINT), name = "filter_pk") }, indexes = {
                    @Index(unique = false, columnList = "entity_pk") },
inverseForeignKey = @ForeignKey(name = "none", value =
ConstraintMode.NO_CONSTRAINT), foreignKey = @ForeignKey(name = "none",
value = ConstraintMode.NO_CONSTRAINT), joinColumns = {
                    @JoinColumn(unique = false, nullable = true, insertable
= true, updatable = true, foreignKey = @ForeignKey(name = "none", value =
ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, name =
"entity_filters")


it didn't help - the foreign keys are still generated. I prepared a sample
project with 2 tests:
1) will try to create an entity and fail because of the foreign key
2) will export the schema.sql so you can see the foregin keys are still
generated.

Sample project is here: https://github.com/paranoiabla/HHH-8805

2015-04-01 14:36 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

>
> https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66093
>
> On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> And no, we generally do not reopen issues from Closed state.  And here,
>> given the different branches, I'd be more inclined to create a different
>> issue referencing the original.
>>
>> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Hmm, it seems I inadvertently set the wrong fix version on HHH-8805.  It
>>> is fixed in our metamodel branch which is 6.0.  I pulled the necessary
>>> metamodel (org.hibernate.mapping) changes back to master (5.0), but only
>>> the hbm.xml form of naming the FK "none" (magic value) is supported to
>>> truly disable generation.  For the time being you can use this as well from
>>> annotations; just name the FK "none".
>>>
>>> If you can write some tests for this, it will make it easier for me to
>>> implement.
>>>
>>>
>>>
>>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>> Oh,
>>>>
>>>> and one last thing: I don't think this is fixed:
>>>> https://hibernate.atlassian.net/browse/HHH-8805
>>>>
>>>> Here's my mapping:
>>>>
>>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>>>         CascadeType.PERSIST,
>>>>         CascadeType.MERGE,
>>>>         CascadeType.REFRESH
>>>>     }, fetch = FetchType.LAZY)
>>>>     @JoinTable(indexes = {
>>>>         @Index(unique = false, columnList = "entity_pk")
>>>>     }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>>> inverseJoinColumns = {
>>>>         @JoinColumn(unique = false, nullable = true, insertable = true,
>>>> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>>> name = "filter_pk")
>>>>     }, joinColumns = {
>>>>         @JoinColumn(unique = false, nullable = true, insertable = true,
>>>> updatable = true, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>>> name = "entity_pk")
>>>>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name =
>>>> "entity_filters")
>>>>     private Collection<AbstractFilterModelDefinition> filters;
>>>>
>>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it is
>>>> possible to add it. However here's what the schema tool generates:
>>>>
>>>>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>>>> (entity_pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKra38l70n01disvkge7i9ff5ym
>>>>         foreign key (filter_pk)
>>>>         references abstract_filter (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>>>>         foreign key (entity_pk)
>>>>         references stock_level (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>>>>         foreign key (entity_pk)
>>>>         references content_slot (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>>>>         foreign key (entity_pk)
>>>>         references blog_entry (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>>>>         foreign key (entity_pk)
>>>>         references price (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>>>>         foreign key (entity_pk)
>>>>         references tax (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>>>>         foreign key (entity_pk)
>>>>         references abstract_template (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>>>>         foreign key (entity_pk)
>>>>         references discount (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>>>>         foreign key (entity_pk)
>>>>         references classification_feature (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKpoh168do203hfqwb7so7c4c79
>>>>         foreign key (entity_pk)
>>>>         references cms_navigation_node (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>>>>         foreign key (entity_pk)
>>>>         references product (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>>>>         foreign key (entity_pk)
>>>>         references abstract_page (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>>>>         foreign key (entity_pk)
>>>>         references promotion (pk);
>>>>
>>>>     alter table entity_filters
>>>>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>>>>         foreign key (entity_pk)
>>>>         references simple_cms_widget (pk);
>>>>
>>>> The foreign keys are all different (in Hibernate 4.3.x they were the
>>>> same), but I just don't want them. Shall I reopen the issue?
>>>>
>>>>
>>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>
>>>>> One other thing I noticed:
>>>>> hibernate-core-5 depends on
>>>>>
>>>>> <groupId>org.jboss.logging</groupId>
>>>>> <artifactId>jboss-logging</artifactId>
>>>>> <version>3.2.1.Final</version>
>>>>>
>>>>> and if you have hibernate-validator 5.1.3.Final (the last stable), it
>>>>> will depend on
>>>>>
>>>>> <groupId>org.jboss.logging</groupId>
>>>>> <artifactId>jboss-logging</artifactId>
>>>>> <version>3.1.4.GA</version>
>>>>>
>>>>> So you will get an exception of method not found on some jboss-logging
>>>>> API. I excluded the jboss-loggin from the hibernate-validator
>>>>> dependency, but now I get a ton of these TRACE statements (literally
>>>>> every millisecond):
>>>>>
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>> 2015-04-01 13:28:02,090
>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>
>>>>>
>>>>>  But at least it works.. I guess the only real solution is to have
>>>>> hibernate-validator use the same jboss-logging version.
>>>>>
>>>>>
>>>>> 2015-04-01 10:39 GMT+03: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
>>>>>> >
>>>>>> _______________________________________________
>>>>>> 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

From steve at hibernate.org  Wed Apr  1 09:03:50 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 08:03:50 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
Message-ID: <CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>

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
>>>>>
>>>>
>>>>
>>>
>>
>

From gunnar at hibernate.org  Wed Apr  1 09:32:57 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 1 Apr 2015 15:32:57 +0200
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
Message-ID: <CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>

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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>

From hardy at hibernate.org  Wed Apr  1 10:29:43 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 1 Apr 2015 16:29:43 +0200
Subject: [hibernate-dev] Release YML
In-Reply-To: <CAFdSV9vnfT=JFO3_4veLCy70wMcDqftUymZFSi21vJzxzX31qg@mail.gmail.com>
References: <CAFdSV9v-F1Fdinx7RUz3jdK+vmxhngEfhV9h1TKL1+p+OVw0eQ@mail.gmail.com>
	<CAFdSV9uJSUrysw=w5QBn69P9W5OqBeEPAW8zaQMFCoAMU=6QFQ@mail.gmail.com>
	<CADGJaX_8bEXKVTF9s+Qw4BGbdjfORpUExny4PXgwEqq3c-JhvA@mail.gmail.com>
	<CAFdSV9vnfT=JFO3_4veLCy70wMcDqftUymZFSi21vJzxzX31qg@mail.gmail.com>
Message-ID: <20150401142943.GA88357@Nineveh.local>

On Wed, Apr 01, 2015 at 06:22:22AM -0500, Steve Ebersole wrote:
> No.  You know why it could not find the POM ;)

LOL. It keeps amazing me what a time sink Nexus is. 

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150401/558d15be/attachment.bin 

From gunnar at hibernate.org  Wed Apr  1 11:42:48 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 1 Apr 2015 17:42:48 +0200
Subject: [hibernate-dev] Release YML
In-Reply-To: <20150401142943.GA88357@Nineveh.local>
References: <CAFdSV9v-F1Fdinx7RUz3jdK+vmxhngEfhV9h1TKL1+p+OVw0eQ@mail.gmail.com>
	<CAFdSV9uJSUrysw=w5QBn69P9W5OqBeEPAW8zaQMFCoAMU=6QFQ@mail.gmail.com>
	<CADGJaX_8bEXKVTF9s+Qw4BGbdjfORpUExny4PXgwEqq3c-JhvA@mail.gmail.com>
	<CAFdSV9vnfT=JFO3_4veLCy70wMcDqftUymZFSi21vJzxzX31qg@mail.gmail.com>
	<20150401142943.GA88357@Nineveh.local>
Message-ID: <CADGJaX8JXriytT7qJv+axf5OYME5eSghKCgx0u6fo8bWS6AR1A@mail.gmail.com>

Ok, Sanne did the required set-up and the job has succeeded now:
http://ci.hibernate.org/view/Website/job/www.hibernate.org/ I can see the
Beta1 download, doc links etc.

Generally best is to check this job for failures if an expected change to
the web site does not show up on prod.

--Gunnar



2015-04-01 16:29 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:

> On Wed, Apr 01, 2015 at 06:22:22AM -0500, Steve Ebersole wrote:
> > No.  You know why it could not find the POM ;)
>
> LOL. It keeps amazing me what a time sink Nexus is.
>
> --Hardy
>

From steve at hibernate.org  Wed Apr  1 12:09:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 11:09:59 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
Message-ID: <CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>

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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

From steve at hibernate.org  Wed Apr  1 12:46:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 1 Apr 2015 11:46:27 -0500
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
	<CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
Message-ID: <CAFdSV9uBHETwF8smssZja798-j51jWkzTa23ckp+VayAggsCiA@mail.gmail.com>

Sanne, I went back and tried applying this -target flag but have not had
any luck with it.  I applied it through the XJC2Task Ant task:

        ant.xjc(
                destdir: "${jaxbTargetDir}",
                binding: hbmXjb.path,
                schema: hbmXsd.path,
                extension: 'true',
                target: '2.0'
        ) {
            arg line:     '-Xinheritance -Xsimplify'
        }

But it had o effect in the end.

On Wed, Apr 1, 2015 at 6:34 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Baseline on Java 8?  Hmm... Well thanks for tempting me :)
>
> What do you mean by "be able to experiment with significant API
> improvements"?
>
> On Tue, Mar 31, 2015 at 7:18 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> I wouldn't disagree on requiring Java 7.
>> I probably wouldn't disagree with Java 8 either, after all we're not
>> removing older versions of Hibernate from any download location and
>> we'll still support and maintain some older versions. It would
>> actually be nice to have the latest ORM version to be able to
>> experiment with significant API improvements.
>>
>> FYI Hibernate Search is requiring Java 7 already, and our CI servers
>> are already testing our projects with JDK9 as well.
>>
>> That said, Java 6 is still being supported by some vendors. Not by
>> Oracle, but Red Hat and SAP will support it for much longer.
>>
>> -- Sanne
>>
>> On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org> wrote:
>> > So we now have to deal with a multi-jdk build in Hibernate ORM.  We need
>> > Java 8 in order to compile the new hibernate-java8 module.
>> >
>> > I wanted to remain compatible with Java 6 for the rest.  However, I ran
>> > into a snag there because of JAXB which we now use (in conjunction with
>> > StAX) to process XML in ORM.  ANyway, the JAX generation creates a model
>> > that is only compatible with Java 7.  I have not yet had time to
>> > investigate this deeply.  But it has to do with a change in the
>> definition
>> > of javax.xml.bind.annotation.XmlElement and a change in its definition
>> > between 1.6 and 1.7 to add a new
>> > attribute javax.xml.bind.annotation.XmlElement#required.
>> >
>> > If anyone is familiar with this situation, I'd love to hear some options
>> > before I spend a lot of time investigating it.
>> >
>> > The other option is that we say we are going to drop Java 6 support
>> since
>> > it has been unsupported now for, what, 3 years?
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From johara at redhat.com  Thu Apr  2 05:45:02 2015
From: johara at redhat.com (John O'Hara)
Date: Thu, 02 Apr 2015 10:45:02 +0100
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
Message-ID: <551D0F9E.1000801@redhat.com>

Steve,

I have pushed a proposal for HHH-9701 to: 
https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701

There are a couple of areas that I would appreciate feedback;

1) Serialization/Deserialization - EntityEntries implementations can be 
serialized and each implementation provide their own serialization 
method. I have modified the serialization of EntityEntry in 
EntityEntryContext to write the Implementation class to the OutputStream 
so the correct class can be used to deserialize the object stream.  Is 
the exception handling sufficient here, or do we need more robust 
handling of deserialization exceptions? : see 
https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380

2) In our (perf team) use case, we want to be able to share the 
ImmutableEntityEntry between sessions when they are referenced cached in 
the 2lc. I have modified EntityEntryContext to not null 
managedEntity.$$_hibernate_setEntityEntry if the EntityEntry is an 
instance of ImmutableEntityEntry.  Do we need to add an extra checks 
here, to ensure that the entity is Reference Cached? I am not sure how 
we would test that case? : see 
https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281

3) Lock Mode: Steve you mentioned about not doing locking for Immutable 
entities. Where is the locking implemented? Would it be sufficient to 
simply set the LockMode on the ImmutableEntityEntry to NONE/READ_ONLY 
when setLockMode is called?

Thanks

John



-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From steve at hibernate.org  Thu Apr  2 09:19:04 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 2 Apr 2015 08:19:04 -0500
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
	<CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
Message-ID: <CAFdSV9uL++E11n5zZtUM8WeEsT1Qb7TW4zFhZHbewMP2aNz8-g@mail.gmail.com>

After considering this some more, I think moving to Java 8 as baseline is
just not reasonable yet.  And tbh I just do not see a compelling reason to
move to Java 7 as the baseline.  So if reasonably possible I would still
like to remain backwards compatible with Java 6.

The only hurdle I believe is this JAXB point.  I see 2 options...

1) Make certain our code is compatible with JAXB 2.0.  I am not well versed
enough in JAXB features between its versions yet to know how good of an
idea this is.

2) make our codr compatible with the newer JAXB version.  This works as-is
in Java 7 and 8 runtimes.  For use in Java 6 runtimes, users would need to
update the JAXB used in their JDK/JRE.  Doing so is a well defined process
using endorsed libs.  See
http://docs.oracle.com/javase/6/docs/technotes/guides/standards/index.html

I think option (1) is the way to go, but do not have a lot of experience
here.  What do y'all think?
On Apr 1, 2015 6:34 AM, "Steve Ebersole" <steve at hibernate.org> wrote:

> Baseline on Java 8?  Hmm... Well thanks for tempting me :)
>
> What do you mean by "be able to experiment with significant API
> improvements"?
>
> On Tue, Mar 31, 2015 at 7:18 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> I wouldn't disagree on requiring Java 7.
>> I probably wouldn't disagree with Java 8 either, after all we're not
>> removing older versions of Hibernate from any download location and
>> we'll still support and maintain some older versions. It would
>> actually be nice to have the latest ORM version to be able to
>> experiment with significant API improvements.
>>
>> FYI Hibernate Search is requiring Java 7 already, and our CI servers
>> are already testing our projects with JDK9 as well.
>>
>> That said, Java 6 is still being supported by some vendors. Not by
>> Oracle, but Red Hat and SAP will support it for much longer.
>>
>> -- Sanne
>>
>> On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org> wrote:
>> > So we now have to deal with a multi-jdk build in Hibernate ORM.  We need
>> > Java 8 in order to compile the new hibernate-java8 module.
>> >
>> > I wanted to remain compatible with Java 6 for the rest.  However, I ran
>> > into a snag there because of JAXB which we now use (in conjunction with
>> > StAX) to process XML in ORM.  ANyway, the JAX generation creates a model
>> > that is only compatible with Java 7.  I have not yet had time to
>> > investigate this deeply.  But it has to do with a change in the
>> definition
>> > of javax.xml.bind.annotation.XmlElement and a change in its definition
>> > between 1.6 and 1.7 to add a new
>> > attribute javax.xml.bind.annotation.XmlElement#required.
>> >
>> > If anyone is familiar with this situation, I'd love to hear some options
>> > before I spend a lot of time investigating it.
>> >
>> > The other option is that we say we are going to drop Java 6 support
>> since
>> > it has been unsupported now for, what, 3 years?
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Thu Apr  2 10:08:06 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 2 Apr 2015 16:08:06 +0200
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CAFdSV9uL++E11n5zZtUM8WeEsT1Qb7TW4zFhZHbewMP2aNz8-g@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
	<CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
	<CAFdSV9uL++E11n5zZtUM8WeEsT1Qb7TW4zFhZHbewMP2aNz8-g@mail.gmail.com>
Message-ID: <CADGJaX91VTQSkHZRM-jr27ghAWZZc5kP0BfQAOo_MfGVTCh+oA@mail.gmail.com>

Had a quick look into (1).

The "target" parameter is not supported by that version of the Ant task
currently in use. If I change the class name of the Ant task from
"org.jvnet.jaxb2_commons.xjc.XJC2Task" into "com.sun.tools.xjc.XJC2Task",
the "target" parameter is recognized and setting it to "2.0" causes no
required() attribute to be generated for @XmlElementRef.

Do you remember why that task from JAXB Commons is used rather than the
original XJC one?

2015-04-02 15:19 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> After considering this some more, I think moving to Java 8 as baseline is
> just not reasonable yet.  And tbh I just do not see a compelling reason to
> move to Java 7 as the baseline.  So if reasonably possible I would still
> like to remain backwards compatible with Java 6.
>
> The only hurdle I believe is this JAXB point.  I see 2 options...
>
> 1) Make certain our code is compatible with JAXB 2.0.  I am not well versed
> enough in JAXB features between its versions yet to know how good of an
> idea this is.
>
> 2) make our codr compatible with the newer JAXB version.  This works as-is
> in Java 7 and 8 runtimes.  For use in Java 6 runtimes, users would need to
> update the JAXB used in their JDK/JRE.  Doing so is a well defined process
> using endorsed libs.  See
> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/index.html
>
> I think option (1) is the way to go, but do not have a lot of experience
> here.  What do y'all think?
> On Apr 1, 2015 6:34 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
>
> > Baseline on Java 8?  Hmm... Well thanks for tempting me :)
> >
> > What do you mean by "be able to experiment with significant API
> > improvements"?
> >
> > On Tue, Mar 31, 2015 at 7:18 PM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >
> >> I wouldn't disagree on requiring Java 7.
> >> I probably wouldn't disagree with Java 8 either, after all we're not
> >> removing older versions of Hibernate from any download location and
> >> we'll still support and maintain some older versions. It would
> >> actually be nice to have the latest ORM version to be able to
> >> experiment with significant API improvements.
> >>
> >> FYI Hibernate Search is requiring Java 7 already, and our CI servers
> >> are already testing our projects with JDK9 as well.
> >>
> >> That said, Java 6 is still being supported by some vendors. Not by
> >> Oracle, but Red Hat and SAP will support it for much longer.
> >>
> >> -- Sanne
> >>
> >> On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org> wrote:
> >> > So we now have to deal with a multi-jdk build in Hibernate ORM.  We
> need
> >> > Java 8 in order to compile the new hibernate-java8 module.
> >> >
> >> > I wanted to remain compatible with Java 6 for the rest.  However, I
> ran
> >> > into a snag there because of JAXB which we now use (in conjunction
> with
> >> > StAX) to process XML in ORM.  ANyway, the JAX generation creates a
> model
> >> > that is only compatible with Java 7.  I have not yet had time to
> >> > investigate this deeply.  But it has to do with a change in the
> >> definition
> >> > of javax.xml.bind.annotation.XmlElement and a change in its definition
> >> > between 1.6 and 1.7 to add a new
> >> > attribute javax.xml.bind.annotation.XmlElement#required.
> >> >
> >> > If anyone is familiar with this situation, I'd love to hear some
> options
> >> > before I spend a lot of time investigating it.
> >> >
> >> > The other option is that we say we are going to drop Java 6 support
> >> since
> >> > it has been unsupported now for, what, 3 years?
> >> > _______________________________________________
> >> > 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
>

From gunnar at hibernate.org  Thu Apr  2 10:37:06 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 2 Apr 2015 16:37:06 +0200
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CADGJaX91VTQSkHZRM-jr27ghAWZZc5kP0BfQAOo_MfGVTCh+oA@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
	<CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
	<CAFdSV9uL++E11n5zZtUM8WeEsT1Qb7TW4zFhZHbewMP2aNz8-g@mail.gmail.com>
	<CADGJaX91VTQSkHZRM-jr27ghAWZZc5kP0BfQAOo_MfGVTCh+oA@mail.gmail.com>
Message-ID: <CADGJaX9=SPGqMJ1NnL5738pd9=TqzWi0oxTcfg_puP05Sh7=Rg@mail.gmail.com>

It also works with that task from JAXB Commons when updating the JAXB
Commons libs (and JAXB itself). That task has the "target" parameter in
newer versions. I can send you a PR for that update.

2015-04-02 16:08 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> Had a quick look into (1).
>
> The "target" parameter is not supported by that version of the Ant task
> currently in use. If I change the class name of the Ant task from
> "org.jvnet.jaxb2_commons.xjc.XJC2Task" into "com.sun.tools.xjc.XJC2Task",
> the "target" parameter is recognized and setting it to "2.0" causes no
> required() attribute to be generated for @XmlElementRef.
>
> Do you remember why that task from JAXB Commons is used rather than the
> original XJC one?
>
> 2015-04-02 15:19 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> After considering this some more, I think moving to Java 8 as baseline is
>> just not reasonable yet.  And tbh I just do not see a compelling reason to
>> move to Java 7 as the baseline.  So if reasonably possible I would still
>> like to remain backwards compatible with Java 6.
>>
>> The only hurdle I believe is this JAXB point.  I see 2 options...
>>
>> 1) Make certain our code is compatible with JAXB 2.0.  I am not well
>> versed
>> enough in JAXB features between its versions yet to know how good of an
>> idea this is.
>>
>> 2) make our codr compatible with the newer JAXB version.  This works as-is
>> in Java 7 and 8 runtimes.  For use in Java 6 runtimes, users would need to
>> update the JAXB used in their JDK/JRE.  Doing so is a well defined process
>> using endorsed libs.  See
>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/index.html
>>
>> I think option (1) is the way to go, but do not have a lot of experience
>> here.  What do y'all think?
>> On Apr 1, 2015 6:34 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
>>
>> > Baseline on Java 8?  Hmm... Well thanks for tempting me :)
>> >
>> > What do you mean by "be able to experiment with significant API
>> > improvements"?
>> >
>> > On Tue, Mar 31, 2015 at 7:18 PM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >
>> >> I wouldn't disagree on requiring Java 7.
>> >> I probably wouldn't disagree with Java 8 either, after all we're not
>> >> removing older versions of Hibernate from any download location and
>> >> we'll still support and maintain some older versions. It would
>> >> actually be nice to have the latest ORM version to be able to
>> >> experiment with significant API improvements.
>> >>
>> >> FYI Hibernate Search is requiring Java 7 already, and our CI servers
>> >> are already testing our projects with JDK9 as well.
>> >>
>> >> That said, Java 6 is still being supported by some vendors. Not by
>> >> Oracle, but Red Hat and SAP will support it for much longer.
>> >>
>> >> -- Sanne
>> >>
>> >> On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org> wrote:
>> >> > So we now have to deal with a multi-jdk build in Hibernate ORM.  We
>> need
>> >> > Java 8 in order to compile the new hibernate-java8 module.
>> >> >
>> >> > I wanted to remain compatible with Java 6 for the rest.  However, I
>> ran
>> >> > into a snag there because of JAXB which we now use (in conjunction
>> with
>> >> > StAX) to process XML in ORM.  ANyway, the JAX generation creates a
>> model
>> >> > that is only compatible with Java 7.  I have not yet had time to
>> >> > investigate this deeply.  But it has to do with a change in the
>> >> definition
>> >> > of javax.xml.bind.annotation.XmlElement and a change in its
>> definition
>> >> > between 1.6 and 1.7 to add a new
>> >> > attribute javax.xml.bind.annotation.XmlElement#required.
>> >> >
>> >> > If anyone is familiar with this situation, I'd love to hear some
>> options
>> >> > before I spend a lot of time investigating it.
>> >> >
>> >> > The other option is that we say we are going to drop Java 6 support
>> >> since
>> >> > it has been unsupported now for, what, 3 years?
>> >> > _______________________________________________
>> >> > 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
>>
>
>

From steve at hibernate.org  Thu Apr  2 10:49:57 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 2 Apr 2015 09:49:57 -0500
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CADGJaX91VTQSkHZRM-jr27ghAWZZc5kP0BfQAOo_MfGVTCh+oA@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
	<CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
	<CAFdSV9uL++E11n5zZtUM8WeEsT1Qb7TW4zFhZHbewMP2aNz8-g@mail.gmail.com>
	<CADGJaX91VTQSkHZRM-jr27ghAWZZc5kP0BfQAOo_MfGVTCh+oA@mail.gmail.com>
Message-ID: <CAFdSV9tRfTYQVs3+LfwfGQwVjWUS=AVNUvUSUD-aXfGA5VMG9g@mail.gmail.com>

It is just the one used in almost every example I have ever seen.  I really
have no idea why one is used versus another.

On Thu, Apr 2, 2015 at 9:08 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Had a quick look into (1).
>
> The "target" parameter is not supported by that version of the Ant task
> currently in use. If I change the class name of the Ant task from
> "org.jvnet.jaxb2_commons.xjc.XJC2Task" into "com.sun.tools.xjc.XJC2Task",
> the "target" parameter is recognized and setting it to "2.0" causes no
> required() attribute to be generated for @XmlElementRef.
>
> Do you remember why that task from JAXB Commons is used rather than the
> original XJC one?
>
> 2015-04-02 15:19 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> After considering this some more, I think moving to Java 8 as baseline is
>> just not reasonable yet.  And tbh I just do not see a compelling reason to
>> move to Java 7 as the baseline.  So if reasonably possible I would still
>> like to remain backwards compatible with Java 6.
>>
>> The only hurdle I believe is this JAXB point.  I see 2 options...
>>
>> 1) Make certain our code is compatible with JAXB 2.0.  I am not well
>> versed
>> enough in JAXB features between its versions yet to know how good of an
>> idea this is.
>>
>> 2) make our codr compatible with the newer JAXB version.  This works as-is
>> in Java 7 and 8 runtimes.  For use in Java 6 runtimes, users would need to
>> update the JAXB used in their JDK/JRE.  Doing so is a well defined process
>> using endorsed libs.  See
>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/index.html
>>
>> I think option (1) is the way to go, but do not have a lot of experience
>> here.  What do y'all think?
>> On Apr 1, 2015 6:34 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
>>
>> > Baseline on Java 8?  Hmm... Well thanks for tempting me :)
>> >
>> > What do you mean by "be able to experiment with significant API
>> > improvements"?
>> >
>> > On Tue, Mar 31, 2015 at 7:18 PM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >
>> >> I wouldn't disagree on requiring Java 7.
>> >> I probably wouldn't disagree with Java 8 either, after all we're not
>> >> removing older versions of Hibernate from any download location and
>> >> we'll still support and maintain some older versions. It would
>> >> actually be nice to have the latest ORM version to be able to
>> >> experiment with significant API improvements.
>> >>
>> >> FYI Hibernate Search is requiring Java 7 already, and our CI servers
>> >> are already testing our projects with JDK9 as well.
>> >>
>> >> That said, Java 6 is still being supported by some vendors. Not by
>> >> Oracle, but Red Hat and SAP will support it for much longer.
>> >>
>> >> -- Sanne
>> >>
>> >> On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org> wrote:
>> >> > So we now have to deal with a multi-jdk build in Hibernate ORM.  We
>> need
>> >> > Java 8 in order to compile the new hibernate-java8 module.
>> >> >
>> >> > I wanted to remain compatible with Java 6 for the rest.  However, I
>> ran
>> >> > into a snag there because of JAXB which we now use (in conjunction
>> with
>> >> > StAX) to process XML in ORM.  ANyway, the JAX generation creates a
>> model
>> >> > that is only compatible with Java 7.  I have not yet had time to
>> >> > investigate this deeply.  But it has to do with a change in the
>> >> definition
>> >> > of javax.xml.bind.annotation.XmlElement and a change in its
>> definition
>> >> > between 1.6 and 1.7 to add a new
>> >> > attribute javax.xml.bind.annotation.XmlElement#required.
>> >> >
>> >> > If anyone is familiar with this situation, I'd love to hear some
>> options
>> >> > before I spend a lot of time investigating it.
>> >> >
>> >> > The other option is that we say we are going to drop Java 6 support
>> >> since
>> >> > it has been unsupported now for, what, 3 years?
>> >> > _______________________________________________
>> >> > 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
>>
>
>

From steve at hibernate.org  Thu Apr  2 10:50:15 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 2 Apr 2015 09:50:15 -0500
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CADGJaX9=SPGqMJ1NnL5738pd9=TqzWi0oxTcfg_puP05Sh7=Rg@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
	<CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
	<CAFdSV9uL++E11n5zZtUM8WeEsT1Qb7TW4zFhZHbewMP2aNz8-g@mail.gmail.com>
	<CADGJaX91VTQSkHZRM-jr27ghAWZZc5kP0BfQAOo_MfGVTCh+oA@mail.gmail.com>
	<CADGJaX9=SPGqMJ1NnL5738pd9=TqzWi0oxTcfg_puP05Sh7=Rg@mail.gmail.com>
Message-ID: <CAFdSV9tV9=b6Og4UhdV7XsV6c4x7U49ivrC0PGGjkJbYktW4jQ@mail.gmail.com>

I just want the one that "works" :)

On Thu, Apr 2, 2015 at 9:37 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> It also works with that task from JAXB Commons when updating the JAXB
> Commons libs (and JAXB itself). That task has the "target" parameter in
> newer versions. I can send you a PR for that update.
>
> 2015-04-02 16:08 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>
>> Had a quick look into (1).
>>
>> The "target" parameter is not supported by that version of the Ant task
>> currently in use. If I change the class name of the Ant task from
>> "org.jvnet.jaxb2_commons.xjc.XJC2Task" into "com.sun.tools.xjc.XJC2Task",
>> the "target" parameter is recognized and setting it to "2.0" causes no
>> required() attribute to be generated for @XmlElementRef.
>>
>> Do you remember why that task from JAXB Commons is used rather than the
>> original XJC one?
>>
>> 2015-04-02 15:19 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> After considering this some more, I think moving to Java 8 as baseline is
>>> just not reasonable yet.  And tbh I just do not see a compelling reason
>>> to
>>> move to Java 7 as the baseline.  So if reasonably possible I would still
>>> like to remain backwards compatible with Java 6.
>>>
>>> The only hurdle I believe is this JAXB point.  I see 2 options...
>>>
>>> 1) Make certain our code is compatible with JAXB 2.0.  I am not well
>>> versed
>>> enough in JAXB features between its versions yet to know how good of an
>>> idea this is.
>>>
>>> 2) make our codr compatible with the newer JAXB version.  This works
>>> as-is
>>> in Java 7 and 8 runtimes.  For use in Java 6 runtimes, users would need
>>> to
>>> update the JAXB used in their JDK/JRE.  Doing so is a well defined
>>> process
>>> using endorsed libs.  See
>>>
>>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/index.html
>>>
>>> I think option (1) is the way to go, but do not have a lot of experience
>>> here.  What do y'all think?
>>> On Apr 1, 2015 6:34 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
>>>
>>> > Baseline on Java 8?  Hmm... Well thanks for tempting me :)
>>> >
>>> > What do you mean by "be able to experiment with significant API
>>> > improvements"?
>>> >
>>> > On Tue, Mar 31, 2015 at 7:18 PM, Sanne Grinovero <sanne at hibernate.org>
>>> > wrote:
>>> >
>>> >> I wouldn't disagree on requiring Java 7.
>>> >> I probably wouldn't disagree with Java 8 either, after all we're not
>>> >> removing older versions of Hibernate from any download location and
>>> >> we'll still support and maintain some older versions. It would
>>> >> actually be nice to have the latest ORM version to be able to
>>> >> experiment with significant API improvements.
>>> >>
>>> >> FYI Hibernate Search is requiring Java 7 already, and our CI servers
>>> >> are already testing our projects with JDK9 as well.
>>> >>
>>> >> That said, Java 6 is still being supported by some vendors. Not by
>>> >> Oracle, but Red Hat and SAP will support it for much longer.
>>> >>
>>> >> -- Sanne
>>> >>
>>> >> On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org> wrote:
>>> >> > So we now have to deal with a multi-jdk build in Hibernate ORM.  We
>>> need
>>> >> > Java 8 in order to compile the new hibernate-java8 module.
>>> >> >
>>> >> > I wanted to remain compatible with Java 6 for the rest.  However, I
>>> ran
>>> >> > into a snag there because of JAXB which we now use (in conjunction
>>> with
>>> >> > StAX) to process XML in ORM.  ANyway, the JAX generation creates a
>>> model
>>> >> > that is only compatible with Java 7.  I have not yet had time to
>>> >> > investigate this deeply.  But it has to do with a change in the
>>> >> definition
>>> >> > of javax.xml.bind.annotation.XmlElement and a change in its
>>> definition
>>> >> > between 1.6 and 1.7 to add a new
>>> >> > attribute javax.xml.bind.annotation.XmlElement#required.
>>> >> >
>>> >> > If anyone is familiar with this situation, I'd love to hear some
>>> options
>>> >> > before I spend a lot of time investigating it.
>>> >> >
>>> >> > The other option is that we say we are going to drop Java 6 support
>>> >> since
>>> >> > it has been unsupported now for, what, 3 years?
>>> >> > _______________________________________________
>>> >> > 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
>>>
>>
>>
>

From steve at hibernate.org  Thu Apr  2 14:57:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 2 Apr 2015 13:57:52 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemXsM=z1Y1J8qkTC-znfFT_jfQazDtBNMukHaQWT-aat5w@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
	<CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
	<CAFdSV9sVUfw+rVNcJwMxj1Jx9CQ=ceh_DZiBuFQtfJ2WsJDeMQ@mail.gmail.com>
	<CAKnbemXsM=z1Y1J8qkTC-znfFT_jfQazDtBNMukHaQWT-aat5w@mail.gmail.com>
Message-ID: <CAFdSV9vem0iWMO8qxf3e-54cB6XmoY62i_0Bsx=HBUVPj-j5Vw@mail.gmail.com>

Petar, so I was unfortunately remembering the work done for 6.0 when saying
that wrt the FK name.  What I found is that binding support for JPA @FK is,
lets say "spotty" at best:  https://hibernate.atlassian.net/browse/HHH-9709

On Wed, Apr 1, 2015 at 8:02 AM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

>
> OK, maybe I'm doing something wrong. I also tried setting the foreign key
> name to "none" like this:
>
>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
> CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch =
> FetchType.LAZY)
>     @JoinTable(inverseJoinColumns = {
>                     @JoinColumn(unique = false, nullable = true,
> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
> "none", value = ConstraintMode.NO_CONSTRAINT), name = "filter_pk") },
> indexes = {
>                     @Index(unique = false, columnList = "entity_pk") },
> inverseForeignKey = @ForeignKey(name = "none", value =
> ConstraintMode.NO_CONSTRAINT), foreignKey = @ForeignKey(name = "none",
> value = ConstraintMode.NO_CONSTRAINT), joinColumns = {
>                     @JoinColumn(unique = false, nullable = true,
> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
> "none", value = ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, name
> = "entity_filters")
>
>
> it didn't help - the foreign keys are still generated. I prepared a sample
> project with 2 tests:
> 1) will try to create an entity and fail because of the foreign key
> 2) will export the schema.sql so you can see the foregin keys are still
> generated.
>
> Sample project is here: https://github.com/paranoiabla/HHH-8805
>
>
> 2015-04-01 14:36 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>>
>> https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66093
>>
>> On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> And no, we generally do not reopen issues from Closed state.  And here,
>>> given the different branches, I'd be more inclined to create a different
>>> issue referencing the original.
>>>
>>> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> Hmm, it seems I inadvertently set the wrong fix version on HHH-8805.
>>>> It is fixed in our metamodel branch which is 6.0.  I pulled the necessary
>>>> metamodel (org.hibernate.mapping) changes back to master (5.0), but only
>>>> the hbm.xml form of naming the FK "none" (magic value) is supported to
>>>> truly disable generation.  For the time being you can use this as well from
>>>> annotations; just name the FK "none".
>>>>
>>>> If you can write some tests for this, it will make it easier for me to
>>>> implement.
>>>>
>>>>
>>>>
>>>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla at gmail.com>
>>>> wrote:
>>>>
>>>>> Oh,
>>>>>
>>>>> and one last thing: I don't think this is fixed:
>>>>> https://hibernate.atlassian.net/browse/HHH-8805
>>>>>
>>>>> Here's my mapping:
>>>>>
>>>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>>>>         CascadeType.PERSIST,
>>>>>         CascadeType.MERGE,
>>>>>         CascadeType.REFRESH
>>>>>     }, fetch = FetchType.LAZY)
>>>>>     @JoinTable(indexes = {
>>>>>         @Index(unique = false, columnList = "entity_pk")
>>>>>     }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>>>> inverseJoinColumns = {
>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>> true, updatable = true, foreignKey =
>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "filter_pk")
>>>>>     }, joinColumns = {
>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>> true, updatable = true, foreignKey =
>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_pk")
>>>>>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name =
>>>>> "entity_filters")
>>>>>     private Collection<AbstractFilterModelDefinition> filters;
>>>>>
>>>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it
>>>>> is possible to add it. However here's what the schema tool generates:
>>>>>
>>>>>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>>>>> (entity_pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKra38l70n01disvkge7i9ff5ym
>>>>>         foreign key (filter_pk)
>>>>>         references abstract_filter (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>>>>>         foreign key (entity_pk)
>>>>>         references stock_level (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>>>>>         foreign key (entity_pk)
>>>>>         references content_slot (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>>>>>         foreign key (entity_pk)
>>>>>         references blog_entry (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>>>>>         foreign key (entity_pk)
>>>>>         references price (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>>>>>         foreign key (entity_pk)
>>>>>         references tax (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>>>>>         foreign key (entity_pk)
>>>>>         references abstract_template (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>>>>>         foreign key (entity_pk)
>>>>>         references discount (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>>>>>         foreign key (entity_pk)
>>>>>         references classification_feature (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKpoh168do203hfqwb7so7c4c79
>>>>>         foreign key (entity_pk)
>>>>>         references cms_navigation_node (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>>>>>         foreign key (entity_pk)
>>>>>         references product (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>>>>>         foreign key (entity_pk)
>>>>>         references abstract_page (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>>>>>         foreign key (entity_pk)
>>>>>         references promotion (pk);
>>>>>
>>>>>     alter table entity_filters
>>>>>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>>>>>         foreign key (entity_pk)
>>>>>         references simple_cms_widget (pk);
>>>>>
>>>>> The foreign keys are all different (in Hibernate 4.3.x they were the
>>>>> same), but I just don't want them. Shall I reopen the issue?
>>>>>
>>>>>
>>>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>
>>>>>> One other thing I noticed:
>>>>>> hibernate-core-5 depends on
>>>>>>
>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>> <version>3.2.1.Final</version>
>>>>>>
>>>>>> and if you have hibernate-validator 5.1.3.Final (the last stable), it
>>>>>> will depend on
>>>>>>
>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>> <version>3.1.4.GA</version>
>>>>>>
>>>>>> So you will get an exception of method not found on some
>>>>>> jboss-logging API. I excluded the jboss-loggin from the hibernate-validator
>>>>>> dependency, but now I get a ton of these TRACE statements (literally
>>>>>> every millisecond):
>>>>>>
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>> 2015-04-01 13:28:02,090
>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>
>>>>>>
>>>>>>  But at least it works.. I guess the only real solution is to have
>>>>>> hibernate-validator use the same jboss-logging version.
>>>>>>
>>>>>>
>>>>>> 2015-04-01 10:39 GMT+03: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
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> 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
>

From ales.justin at gmail.com  Thu Apr  2 15:00:33 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Thu, 2 Apr 2015 21:00:33 +0200
Subject: [hibernate-dev] document update change?
In-Reply-To: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
References: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
Message-ID: <02A54091-7B07-4B98-A34F-EB11786EA581@gmail.com>

When debugging, I see this -- it get "bbb" twice (old and new, where I would actually expect stale "ccc"):

results = {java.util.ArrayList at 17380}  size = 3
 0 = {java.lang.Object[3]@17384} 
  0 = {com.google.appengine.api.datastore.Key at 17395} "test(1)"
  1 = {java.lang.String at 17396} "#Thu Apr 02 20:53:33 CEST 2015\nprop=STRING\n"
  2 = {java.lang.String at 17397} "040:aaa"
 1 = {java.lang.Object[3]@17385} 
  0 = {com.google.appengine.api.datastore.Key at 17391} "test(1)"
  1 = {java.lang.String at 17392} "#Thu Apr 02 20:51:24 CEST 2015\nprop=STRING\n"
  2 = {java.lang.String at 17393} "040:bbb"
 2 = {java.lang.Object[3]@17386} 
  0 = {com.google.appengine.api.datastore.Key at 17387} "test(1)"
  1 = {java.lang.String at 17388} "#Thu Apr 02 20:53:33 CEST 2015\nprop=STRING\n"
  2 = {java.lang.String at 17389} "040:bbb"


But still no idea on why dup "bbb" is there ...

-Ales

> On 01 Apr 2015, at 11:59, Ales Justin <ales.justin at gmail.com> wrote:
> 
> Did entity updating changed in HS5 / Lucene4?
> (aka Document updating)
> 
> Since this used to work for us (with HS4, Lucene3):
> 
> ---
> @Test
> public void testProjectionQueriesHandleEntityModificationProperly() throws Exception {
>     Entity e = createEntity("test", 1)
>         .withProperty("prop", Arrays.asList("aaa", "bbb", "ccc"))
>         .store();
> 
>     Query query = new Query("test")
>         .addProjection(new PropertyProjection("prop", String.class))
>         .addSort("prop");
> 
>     assertEquals(3, service.prepare(query).asList(withDefaults()).size());
> 
>     e = createEntity(e.getKey())
>         .withProperty("prop", Arrays.asList("aaa", "bbb"))
>         .store();
> 
>     assertEquals(2, service.prepare(query).asList(withDefaults()).size());
> 
>     service.delete(e.getKey());
> 
>     assertEquals(0, service.prepare(query).asList(withDefaults()).size());
> }
> 
> ---
> 
> Where we add each list/collection value under same field:
> 
> if (propertyValue instanceof Collection) {
>     Collection collection = (Collection) propertyValue;
>     for (Object element : collection) {
>         if (PropertyUtils.isIndexedProperty(element)) {
>             final Bridge inner = BridgeUtils.matchBridge(element);
>             luceneOptions.addFieldToDocument(propertyName, inner.objectToString(element), document);
>         }
>     }
> 
> ---
> 
> As it looks like the update still keeps the old values around:
> 
> java.lang.AssertionError: expected:<2> but was:<3>
>     at org.junit.Assert.fail(Assert.java:88)
>     at org.junit.Assert.failNotEquals(Assert.java:743)
>     at org.junit.Assert.assertEquals(Assert.java:118)
>     at org.junit.Assert.assertEquals(Assert.java:555)
>     at org.junit.Assert.assertEquals(Assert.java:542)
>     at org.jboss.test.capedwarf.datastore.test.QueryOptimizationsTest.testProjectionQueriesHandleEntityModificationProperly(QueryOptimizationsTest.java:510)
> 
> ---
> 
> Any way to force / fix this?
> 
> -Ales
> 


From paranoiabla at gmail.com  Thu Apr  2 15:05:49 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 2 Apr 2015 22:05:49 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9vem0iWMO8qxf3e-54cB6XmoY62i_0Bsx=HBUVPj-j5Vw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
	<CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
	<CAFdSV9sVUfw+rVNcJwMxj1Jx9CQ=ceh_DZiBuFQtfJ2WsJDeMQ@mail.gmail.com>
	<CAKnbemXsM=z1Y1J8qkTC-znfFT_jfQazDtBNMukHaQWT-aat5w@mail.gmail.com>
	<CAFdSV9vem0iWMO8qxf3e-54cB6XmoY62i_0Bsx=HBUVPj-j5Vw@mail.gmail.com>
Message-ID: <CAKnbemUyFSOYK7TUdYZMc9RKQ_xHzQds_DyAbwr=guyxpbK31Q@mail.gmail.com>

Cool,

ping me once resolved - I'm eager to test it :)

2015-04-02 21:57 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> Petar, so I was unfortunately remembering the work done for 6.0 when
> saying that wrt the FK name.  What I found is that binding support for JPA
> @FK is, lets say "spotty" at best:
> https://hibernate.atlassian.net/browse/HHH-9709
>
> On Wed, Apr 1, 2015 at 8:02 AM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>>
>> OK, maybe I'm doing something wrong. I also tried setting the foreign key
>> name to "none" like this:
>>
>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>> CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch =
>> FetchType.LAZY)
>>     @JoinTable(inverseJoinColumns = {
>>                     @JoinColumn(unique = false, nullable = true,
>> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "filter_pk") },
>> indexes = {
>>                     @Index(unique = false, columnList = "entity_pk") },
>> inverseForeignKey = @ForeignKey(name = "none", value =
>> ConstraintMode.NO_CONSTRAINT), foreignKey = @ForeignKey(name = "none",
>> value = ConstraintMode.NO_CONSTRAINT), joinColumns = {
>>                     @JoinColumn(unique = false, nullable = true,
>> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, name
>> = "entity_filters")
>>
>>
>> it didn't help - the foreign keys are still generated. I prepared a
>> sample project with 2 tests:
>> 1) will try to create an entity and fail because of the foreign key
>> 2) will export the schema.sql so you can see the foregin keys are still
>> generated.
>>
>> Sample project is here: https://github.com/paranoiabla/HHH-8805
>>
>>
>> 2015-04-01 14:36 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>>
>>> https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66093
>>>
>>> On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> And no, we generally do not reopen issues from Closed state.  And here,
>>>> given the different branches, I'd be more inclined to create a different
>>>> issue referencing the original.
>>>>
>>>> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> Hmm, it seems I inadvertently set the wrong fix version on HHH-8805.
>>>>> It is fixed in our metamodel branch which is 6.0.  I pulled the necessary
>>>>> metamodel (org.hibernate.mapping) changes back to master (5.0), but only
>>>>> the hbm.xml form of naming the FK "none" (magic value) is supported to
>>>>> truly disable generation.  For the time being you can use this as well from
>>>>> annotations; just name the FK "none".
>>>>>
>>>>> If you can write some tests for this, it will make it easier for me to
>>>>> implement.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Oh,
>>>>>>
>>>>>> and one last thing: I don't think this is fixed:
>>>>>> https://hibernate.atlassian.net/browse/HHH-8805
>>>>>>
>>>>>> Here's my mapping:
>>>>>>
>>>>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>>>>>         CascadeType.PERSIST,
>>>>>>         CascadeType.MERGE,
>>>>>>         CascadeType.REFRESH
>>>>>>     }, fetch = FetchType.LAZY)
>>>>>>     @JoinTable(indexes = {
>>>>>>         @Index(unique = false, columnList = "entity_pk")
>>>>>>     }, inverseForeignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>>>>> inverseJoinColumns = {
>>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>>> true, updatable = true, foreignKey =
>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "filter_pk")
>>>>>>     }, joinColumns = {
>>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>>> true, updatable = true, foreignKey =
>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_pk")
>>>>>>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name =
>>>>>> "entity_filters")
>>>>>>     private Collection<AbstractFilterModelDefinition> filters;
>>>>>>
>>>>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it
>>>>>> is possible to add it. However here's what the schema tool generates:
>>>>>>
>>>>>>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>>>>>> (entity_pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKra38l70n01disvkge7i9ff5ym
>>>>>>         foreign key (filter_pk)
>>>>>>         references abstract_filter (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>>>>>>         foreign key (entity_pk)
>>>>>>         references stock_level (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>>>>>>         foreign key (entity_pk)
>>>>>>         references content_slot (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>>>>>>         foreign key (entity_pk)
>>>>>>         references blog_entry (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>>>>>>         foreign key (entity_pk)
>>>>>>         references price (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>>>>>>         foreign key (entity_pk)
>>>>>>         references tax (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>>>>>>         foreign key (entity_pk)
>>>>>>         references abstract_template (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>>>>>>         foreign key (entity_pk)
>>>>>>         references discount (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>>>>>>         foreign key (entity_pk)
>>>>>>         references classification_feature (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKpoh168do203hfqwb7so7c4c79
>>>>>>         foreign key (entity_pk)
>>>>>>         references cms_navigation_node (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>>>>>>         foreign key (entity_pk)
>>>>>>         references product (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>>>>>>         foreign key (entity_pk)
>>>>>>         references abstract_page (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>>>>>>         foreign key (entity_pk)
>>>>>>         references promotion (pk);
>>>>>>
>>>>>>     alter table entity_filters
>>>>>>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>>>>>>         foreign key (entity_pk)
>>>>>>         references simple_cms_widget (pk);
>>>>>>
>>>>>> The foreign keys are all different (in Hibernate 4.3.x they were the
>>>>>> same), but I just don't want them. Shall I reopen the issue?
>>>>>>
>>>>>>
>>>>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>>
>>>>>>> One other thing I noticed:
>>>>>>> hibernate-core-5 depends on
>>>>>>>
>>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>>> <version>3.2.1.Final</version>
>>>>>>>
>>>>>>> and if you have hibernate-validator 5.1.3.Final (the last stable),
>>>>>>> it will depend on
>>>>>>>
>>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>>> <version>3.1.4.GA</version>
>>>>>>>
>>>>>>> So you will get an exception of method not found on some
>>>>>>> jboss-logging API. I excluded the jboss-loggin from the hibernate-validator
>>>>>>> dependency, but now I get a ton of these TRACE statements (literally
>>>>>>> every millisecond):
>>>>>>>
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>> 2015-04-01 13:28:02,090
>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>
>>>>>>>
>>>>>>>  But at least it works.. I guess the only real solution is to have
>>>>>>> hibernate-validator use the same jboss-logging version.
>>>>>>>
>>>>>>>
>>>>>>> 2015-04-01 10:39 GMT+03: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
>>>>>>>> >
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>
>
>


-- 
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

From steve at hibernate.org  Thu Apr  2 15:06:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 2 Apr 2015 14:06:28 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemUyFSOYK7TUdYZMc9RKQ_xHzQds_DyAbwr=guyxpbK31Q@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
	<CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
	<CAFdSV9sVUfw+rVNcJwMxj1Jx9CQ=ceh_DZiBuFQtfJ2WsJDeMQ@mail.gmail.com>
	<CAKnbemXsM=z1Y1J8qkTC-znfFT_jfQazDtBNMukHaQWT-aat5w@mail.gmail.com>
	<CAFdSV9vem0iWMO8qxf3e-54cB6XmoY62i_0Bsx=HBUVPj-j5Vw@mail.gmail.com>
	<CAKnbemUyFSOYK7TUdYZMc9RKQ_xHzQds_DyAbwr=guyxpbK31Q@mail.gmail.com>
Message-ID: <CAFdSV9vREXyV8G0SMY1OaHA4ND7WaSyqt=idspSoOSVDB4B8MQ@mail.gmail.com>

I am working on it as we speak :)

On Thu, Apr 2, 2015 at 2:05 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Cool,
>
> ping me once resolved - I'm eager to test it :)
>
> 2015-04-02 21:57 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> Petar, so I was unfortunately remembering the work done for 6.0 when
>> saying that wrt the FK name.  What I found is that binding support for JPA
>> @FK is, lets say "spotty" at best:
>> https://hibernate.atlassian.net/browse/HHH-9709
>>
>> On Wed, Apr 1, 2015 at 8:02 AM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>>
>>> OK, maybe I'm doing something wrong. I also tried setting the foreign
>>> key name to "none" like this:
>>>
>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>> CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch =
>>> FetchType.LAZY)
>>>     @JoinTable(inverseJoinColumns = {
>>>                     @JoinColumn(unique = false, nullable = true,
>>> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
>>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "filter_pk") },
>>> indexes = {
>>>                     @Index(unique = false, columnList = "entity_pk") },
>>> inverseForeignKey = @ForeignKey(name = "none", value =
>>> ConstraintMode.NO_CONSTRAINT), foreignKey = @ForeignKey(name = "none",
>>> value = ConstraintMode.NO_CONSTRAINT), joinColumns = {
>>>                     @JoinColumn(unique = false, nullable = true,
>>> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
>>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, name
>>> = "entity_filters")
>>>
>>>
>>> it didn't help - the foreign keys are still generated. I prepared a
>>> sample project with 2 tests:
>>> 1) will try to create an entity and fail because of the foreign key
>>> 2) will export the schema.sql so you can see the foregin keys are still
>>> generated.
>>>
>>> Sample project is here: https://github.com/paranoiabla/HHH-8805
>>>
>>>
>>> 2015-04-01 14:36 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>>
>>>> https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66093
>>>>
>>>> On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> And no, we generally do not reopen issues from Closed state.  And
>>>>> here, given the different branches, I'd be more inclined to create a
>>>>> different issue referencing the original.
>>>>>
>>>>> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> Hmm, it seems I inadvertently set the wrong fix version on HHH-8805.
>>>>>> It is fixed in our metamodel branch which is 6.0.  I pulled the necessary
>>>>>> metamodel (org.hibernate.mapping) changes back to master (5.0), but only
>>>>>> the hbm.xml form of naming the FK "none" (magic value) is supported to
>>>>>> truly disable generation.  For the time being you can use this as well from
>>>>>> annotations; just name the FK "none".
>>>>>>
>>>>>> If you can write some tests for this, it will make it easier for me
>>>>>> to implement.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <paranoiabla at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Oh,
>>>>>>>
>>>>>>> and one last thing: I don't think this is fixed:
>>>>>>> https://hibernate.atlassian.net/browse/HHH-8805
>>>>>>>
>>>>>>> Here's my mapping:
>>>>>>>
>>>>>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>>>>>>         CascadeType.PERSIST,
>>>>>>>         CascadeType.MERGE,
>>>>>>>         CascadeType.REFRESH
>>>>>>>     }, fetch = FetchType.LAZY)
>>>>>>>     @JoinTable(indexes = {
>>>>>>>         @Index(unique = false, columnList = "entity_pk")
>>>>>>>     }, inverseForeignKey =
>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), inverseJoinColumns = {
>>>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>>>> true, updatable = true, foreignKey =
>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "filter_pk")
>>>>>>>     }, joinColumns = {
>>>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>>>> true, updatable = true, foreignKey =
>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_pk")
>>>>>>>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name
>>>>>>> = "entity_filters")
>>>>>>>     private Collection<AbstractFilterModelDefinition> filters;
>>>>>>>
>>>>>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever it
>>>>>>> is possible to add it. However here's what the schema tool generates:
>>>>>>>
>>>>>>>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>>>>>>> (entity_pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKra38l70n01disvkge7i9ff5ym
>>>>>>>         foreign key (filter_pk)
>>>>>>>         references abstract_filter (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references stock_level (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references content_slot (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references blog_entry (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references price (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references tax (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references abstract_template (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references discount (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references classification_feature (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKpoh168do203hfqwb7so7c4c79
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references cms_navigation_node (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references product (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references abstract_page (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references promotion (pk);
>>>>>>>
>>>>>>>     alter table entity_filters
>>>>>>>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>>>>>>>         foreign key (entity_pk)
>>>>>>>         references simple_cms_widget (pk);
>>>>>>>
>>>>>>> The foreign keys are all different (in Hibernate 4.3.x they were the
>>>>>>> same), but I just don't want them. Shall I reopen the issue?
>>>>>>>
>>>>>>>
>>>>>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>>>
>>>>>>>> One other thing I noticed:
>>>>>>>> hibernate-core-5 depends on
>>>>>>>>
>>>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>>>> <version>3.2.1.Final</version>
>>>>>>>>
>>>>>>>> and if you have hibernate-validator 5.1.3.Final (the last stable),
>>>>>>>> it will depend on
>>>>>>>>
>>>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>>>> <version>3.1.4.GA</version>
>>>>>>>>
>>>>>>>> So you will get an exception of method not found on some
>>>>>>>> jboss-logging API. I excluded the jboss-loggin from the hibernate-validator
>>>>>>>> dependency, but now I get a ton of these TRACE statements
>>>>>>>> (literally every millisecond):
>>>>>>>>
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>
>>>>>>>>
>>>>>>>>  But at least it works.. I guess the only real solution is to have
>>>>>>>> hibernate-validator use the same jboss-logging version.
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-04-01 10:39 GMT+03: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
>>>>>>>>> >
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>
>>
>>
>
>
> --
> 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
>

From steve at hibernate.org  Thu Apr  2 18:16:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 2 Apr 2015 17:16:44 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9vREXyV8G0SMY1OaHA4ND7WaSyqt=idspSoOSVDB4B8MQ@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
	<CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
	<CAFdSV9sVUfw+rVNcJwMxj1Jx9CQ=ceh_DZiBuFQtfJ2WsJDeMQ@mail.gmail.com>
	<CAKnbemXsM=z1Y1J8qkTC-znfFT_jfQazDtBNMukHaQWT-aat5w@mail.gmail.com>
	<CAFdSV9vem0iWMO8qxf3e-54cB6XmoY62i_0Bsx=HBUVPj-j5Vw@mail.gmail.com>
	<CAKnbemUyFSOYK7TUdYZMc9RKQ_xHzQds_DyAbwr=guyxpbK31Q@mail.gmail.com>
	<CAFdSV9vREXyV8G0SMY1OaHA4ND7WaSyqt=idspSoOSVDB4B8MQ@mail.gmail.com>
Message-ID: <CAFdSV9sfWzB4BsPDh4XARMJm_C4W-Na+_Ad27+1paEjsbEfjgQ@mail.gmail.com>

Ok Petar, when you get a chance pull and give that a try wrt ForeignKeys

On Thu, Apr 2, 2015 at 2:06 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I am working on it as we speak :)
>
> On Thu, Apr 2, 2015 at 2:05 PM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Cool,
>>
>> ping me once resolved - I'm eager to test it :)
>>
>> 2015-04-02 21:57 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Petar, so I was unfortunately remembering the work done for 6.0 when
>>> saying that wrt the FK name.  What I found is that binding support for JPA
>>> @FK is, lets say "spotty" at best:
>>> https://hibernate.atlassian.net/browse/HHH-9709
>>>
>>> On Wed, Apr 1, 2015 at 8:02 AM, Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>>
>>>> OK, maybe I'm doing something wrong. I also tried setting the foreign
>>>> key name to "none" like this:
>>>>
>>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>>> CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch =
>>>> FetchType.LAZY)
>>>>     @JoinTable(inverseJoinColumns = {
>>>>                     @JoinColumn(unique = false, nullable = true,
>>>> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
>>>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "filter_pk") },
>>>> indexes = {
>>>>                     @Index(unique = false, columnList = "entity_pk") },
>>>> inverseForeignKey = @ForeignKey(name = "none", value =
>>>> ConstraintMode.NO_CONSTRAINT), foreignKey = @ForeignKey(name = "none",
>>>> value = ConstraintMode.NO_CONSTRAINT), joinColumns = {
>>>>                     @JoinColumn(unique = false, nullable = true,
>>>> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
>>>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, name
>>>> = "entity_filters")
>>>>
>>>>
>>>> it didn't help - the foreign keys are still generated. I prepared a
>>>> sample project with 2 tests:
>>>> 1) will try to create an entity and fail because of the foreign key
>>>> 2) will export the schema.sql so you can see the foregin keys are still
>>>> generated.
>>>>
>>>> Sample project is here: https://github.com/paranoiabla/HHH-8805
>>>>
>>>>
>>>> 2015-04-01 14:36 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>>
>>>>> https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66093
>>>>>
>>>>> On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>>
>>>>>> And no, we generally do not reopen issues from Closed state.  And
>>>>>> here, given the different branches, I'd be more inclined to create a
>>>>>> different issue referencing the original.
>>>>>>
>>>>>> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> Hmm, it seems I inadvertently set the wrong fix version on
>>>>>>> HHH-8805.  It is fixed in our metamodel branch which is 6.0.  I pulled the
>>>>>>> necessary metamodel (org.hibernate.mapping) changes back to master (5.0),
>>>>>>> but only the hbm.xml form of naming the FK "none" (magic value) is
>>>>>>> supported to truly disable generation.  For the time being you can use this
>>>>>>> as well from annotations; just name the FK "none".
>>>>>>>
>>>>>>> If you can write some tests for this, it will make it easier for me
>>>>>>> to implement.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <
>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>
>>>>>>>> Oh,
>>>>>>>>
>>>>>>>> and one last thing: I don't think this is fixed:
>>>>>>>> https://hibernate.atlassian.net/browse/HHH-8805
>>>>>>>>
>>>>>>>> Here's my mapping:
>>>>>>>>
>>>>>>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade =
>>>>>>>> {
>>>>>>>>         CascadeType.PERSIST,
>>>>>>>>         CascadeType.MERGE,
>>>>>>>>         CascadeType.REFRESH
>>>>>>>>     }, fetch = FetchType.LAZY)
>>>>>>>>     @JoinTable(indexes = {
>>>>>>>>         @Index(unique = false, columnList = "entity_pk")
>>>>>>>>     }, inverseForeignKey =
>>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), inverseJoinColumns = {
>>>>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>>>>> true, updatable = true, foreignKey =
>>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "filter_pk")
>>>>>>>>     }, joinColumns = {
>>>>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>>>>> true, updatable = true, foreignKey =
>>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_pk")
>>>>>>>>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT), name
>>>>>>>> = "entity_filters")
>>>>>>>>     private Collection<AbstractFilterModelDefinition> filters;
>>>>>>>>
>>>>>>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever
>>>>>>>> it is possible to add it. However here's what the schema tool generates:
>>>>>>>>
>>>>>>>>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>>>>>>>> (entity_pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKra38l70n01disvkge7i9ff5ym
>>>>>>>>         foreign key (filter_pk)
>>>>>>>>         references abstract_filter (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references stock_level (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references content_slot (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references blog_entry (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references price (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references tax (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references abstract_template (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references discount (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references classification_feature (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKpoh168do203hfqwb7so7c4c79
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references cms_navigation_node (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references product (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references abstract_page (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references promotion (pk);
>>>>>>>>
>>>>>>>>     alter table entity_filters
>>>>>>>>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>>>>>>>>         foreign key (entity_pk)
>>>>>>>>         references simple_cms_widget (pk);
>>>>>>>>
>>>>>>>> The foreign keys are all different (in Hibernate 4.3.x they were
>>>>>>>> the same), but I just don't want them. Shall I reopen the issue?
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>>>>
>>>>>>>>> One other thing I noticed:
>>>>>>>>> hibernate-core-5 depends on
>>>>>>>>>
>>>>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>>>>> <version>3.2.1.Final</version>
>>>>>>>>>
>>>>>>>>> and if you have hibernate-validator 5.1.3.Final (the last stable),
>>>>>>>>> it will depend on
>>>>>>>>>
>>>>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>>>>> <version>3.1.4.GA</version>
>>>>>>>>>
>>>>>>>>> So you will get an exception of method not found on some
>>>>>>>>> jboss-logging API. I excluded the jboss-loggin from the hibernate-validator
>>>>>>>>> dependency, but now I get a ton of these TRACE statements
>>>>>>>>> (literally every millisecond):
>>>>>>>>>
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  But at least it works.. I guess the only real solution is to have
>>>>>>>>> hibernate-validator use the same jboss-logging version.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2015-04-01 10:39 GMT+03: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
>>>>>>>>>> >
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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
>>>>
>>>
>>>
>>
>>
>> --
>> 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
>>
>
>

From paranoiabla at gmail.com  Thu Apr  2 19:54:40 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 3 Apr 2015 02:54:40 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9sfWzB4BsPDh4XARMJm_C4W-Na+_Ad27+1paEjsbEfjgQ@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
	<CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
	<CAFdSV9sVUfw+rVNcJwMxj1Jx9CQ=ceh_DZiBuFQtfJ2WsJDeMQ@mail.gmail.com>
	<CAKnbemXsM=z1Y1J8qkTC-znfFT_jfQazDtBNMukHaQWT-aat5w@mail.gmail.com>
	<CAFdSV9vem0iWMO8qxf3e-54cB6XmoY62i_0Bsx=HBUVPj-j5Vw@mail.gmail.com>
	<CAKnbemUyFSOYK7TUdYZMc9RKQ_xHzQds_DyAbwr=guyxpbK31Q@mail.gmail.com>
	<CAFdSV9vREXyV8G0SMY1OaHA4ND7WaSyqt=idspSoOSVDB4B8MQ@mail.gmail.com>
	<CAFdSV9sfWzB4BsPDh4XARMJm_C4W-Na+_Ad27+1paEjsbEfjgQ@mail.gmail.com>
Message-ID: <CAKnbemUK9PDJRfeRVrzGOkPQ3V9B_wfK659XiEwk9VUh2ixYaA@mail.gmail.com>

Hi Steve,

I just pulled and did ./gradlew install. Unfortunately this didn't install
the jars in my local maven repo because the maven plugin declaration was
missing (you might want to consider adding it). Anyways, after I added it
the jars were installed in my repo. I ran schema export and the schema
result was missing the foreign keys - great!!!
However when I ran my tests against HSQL (my tests are using
hibernate.ddl-auto=update to create the tables) I got an exception:


2015-04-03 02:39:50,456 org.springframework.boot.SpringApplication [main]
ERROR: Application startup failed
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'entityManagerFactory' defined in class path resource
[org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaAutoConfiguration.class]:
Invocation of init method failed; nested exception is
javax.persistence.PersistenceException: [PersistenceUnit: default] Unable
to build Hibernate SessionFactory
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1566)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
    at
org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:956)
    at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:747)
    at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
    at
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:691)
    at
org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
    at
org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:98)
    at
org.springframework.test.context.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:68)
    at
org.springframework.test.context.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:86)
    at
org.springframework.test.context.DefaultTestContext.getApplicationContext(DefaultTestContext.java:72)
    at
org.springframework.test.context.web.ServletTestExecutionListener.setUpRequestContextIfNecessary(ServletTestExecutionListener.java:170)
    at
org.springframework.test.context.web.ServletTestExecutionListener.prepareTestInstance(ServletTestExecutionListener.java:110)
    at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:212)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:200)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:252)
    at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:254)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:217)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:83)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
    at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:68)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:163)
    at org.junit.runners.Suite.runChild(Suite.java:127)
    at org.junit.runners.Suite.runChild(Suite.java:26)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
    at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createReqestAndRun(JUnitCoreWrapper.java:139)
    at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:111)
    at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:84)
    at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:135)
    at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
    at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
    at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
default] Unable to build Hibernate SessionFactory
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
    at
org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
    at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
    at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1625)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1562)
    ... 50 more
Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: BIG
PROBLEM
    at
org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:128)
    at
org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
    at
org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
    at
org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
    at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:456)
    at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:151)
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
    ... 55 more
2015-04-03 02:39:50,456 org.springframework.test.context.TestContextManager
[main] ERROR: Caught exception while allowing TestExecutionListener
[org.springframework.test.context.web.ServletTestExecutionListener at 14dc3f89]
to prepare test instance
[com.samplestore.storefront.controllers.pages.CustomerServiceContentPageControllerIntegrationTest at 5e3193ac
]
java.lang.IllegalStateException: Failed to load ApplicationContext
    at
org.springframework.test.context.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:94)
    at
org.springframework.test.context.DefaultTestContext.getApplicationContext(DefaultTestContext.java:72)
    at
org.springframework.test.context.web.ServletTestExecutionListener.setUpRequestContextIfNecessary(ServletTestExecutionListener.java:170)
    at
org.springframework.test.context.web.ServletTestExecutionListener.prepareTestInstance(ServletTestExecutionListener.java:110)
    at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:212)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:200)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:252)
    at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:254)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:217)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:83)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
    at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:68)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:163)
    at org.junit.runners.Suite.runChild(Suite.java:127)
    at org.junit.runners.Suite.runChild(Suite.java:26)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
    at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
    at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createReqestAndRun(JUnitCoreWrapper.java:139)
    at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:111)
    at
org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:84)
    at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:135)
    at
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
    at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
    at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'entityManagerFactory' defined in class path
resource
[org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaAutoConfiguration.class]:
Invocation of init method failed; nested exception is
javax.persistence.PersistenceException: [PersistenceUnit: default] Unable
to build Hibernate SessionFactory
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1566)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:476)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:303)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:299)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
    at
org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:956)
    at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:747)
    at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:480)
    at
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:691)
    at
org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
    at
org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:98)
    at
org.springframework.test.context.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:68)
    at
org.springframework.test.context.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:86)
    ... 36 more
Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
default] Unable to build Hibernate SessionFactory
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
    at
org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
    at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
    at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1625)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1562)
    ... 50 more
Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: BIG
PROBLEM
    at
org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:128)
    at
org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
    at
org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
    at
org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
    at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:456)
    at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:151)
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
    ... 55 more

So I placed a log in SchemaMigratorImpl:128 to see which table it is
finding as null. The result - absract_filter. And I can see in the logs
just on the line before that

2015-04-03 02:48:44,082
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
[main] INFO : HHH000262: Table not found: abstract_filter
abstract_filter
2015-04-03 02:48:44,084
org.springframework.web.context.support.GenericWebApplicationContext [main]
WARN : Exception encountered during context initialization - cancelling
refresh attempt
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'entityManagerFactory' defined in class path resource
[org/springframework/boot/autoconfigure/orm/jpa/HibernateJpaAutoConfiguration.class]:
Invocation of init method failed; nested exception is
javax.persistence.PersistenceException: [PersistenceUnit: default] Unable
to build Hibernate SessionFactory
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1566)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:539)
    at org.springf

So the hbm2ddl must be creating it. So I don't know why it is failing to
find it afterwords.

2015-04-03 1:16 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> Ok Petar, when you get a chance pull and give that a try wrt ForeignKeys
>
> On Thu, Apr 2, 2015 at 2:06 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I am working on it as we speak :)
>>
>> On Thu, Apr 2, 2015 at 2:05 PM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Cool,
>>>
>>> ping me once resolved - I'm eager to test it :)
>>>
>>> 2015-04-02 21:57 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> Petar, so I was unfortunately remembering the work done for 6.0 when
>>>> saying that wrt the FK name.  What I found is that binding support for JPA
>>>> @FK is, lets say "spotty" at best:
>>>> https://hibernate.atlassian.net/browse/HHH-9709
>>>>
>>>> On Wed, Apr 1, 2015 at 8:02 AM, Petar Tahchiev <paranoiabla at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> OK, maybe I'm doing something wrong. I also tried setting the foreign
>>>>> key name to "none" like this:
>>>>>
>>>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade = {
>>>>> CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, fetch =
>>>>> FetchType.LAZY)
>>>>>     @JoinTable(inverseJoinColumns = {
>>>>>                     @JoinColumn(unique = false, nullable = true,
>>>>> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
>>>>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "filter_pk") },
>>>>> indexes = {
>>>>>                     @Index(unique = false, columnList = "entity_pk")
>>>>> }, inverseForeignKey = @ForeignKey(name = "none", value =
>>>>> ConstraintMode.NO_CONSTRAINT), foreignKey = @ForeignKey(name = "none",
>>>>> value = ConstraintMode.NO_CONSTRAINT), joinColumns = {
>>>>>                     @JoinColumn(unique = false, nullable = true,
>>>>> insertable = true, updatable = true, foreignKey = @ForeignKey(name =
>>>>> "none", value = ConstraintMode.NO_CONSTRAINT), name = "entity_pk") }, name
>>>>> = "entity_filters")
>>>>>
>>>>>
>>>>> it didn't help - the foreign keys are still generated. I prepared a
>>>>> sample project with 2 tests:
>>>>> 1) will try to create an entity and fail because of the foreign key
>>>>> 2) will export the schema.sql so you can see the foregin keys are
>>>>> still generated.
>>>>>
>>>>> Sample project is here: https://github.com/paranoiabla/HHH-8805
>>>>>
>>>>>
>>>>> 2015-04-01 14:36 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>>
>>>>>> https://hibernate.atlassian.net/browse/HHH-8805?focusedCommentId=66093&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-66093
>>>>>>
>>>>>> On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole <steve at hibernate.org>
>>>>>> wrote:
>>>>>>
>>>>>>> And no, we generally do not reopen issues from Closed state.  And
>>>>>>> here, given the different branches, I'd be more inclined to create a
>>>>>>> different issue referencing the original.
>>>>>>>
>>>>>>> On Wed, Apr 1, 2015 at 6:18 AM, Steve Ebersole <steve at hibernate.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hmm, it seems I inadvertently set the wrong fix version on
>>>>>>>> HHH-8805.  It is fixed in our metamodel branch which is 6.0.  I pulled the
>>>>>>>> necessary metamodel (org.hibernate.mapping) changes back to master (5.0),
>>>>>>>> but only the hbm.xml form of naming the FK "none" (magic value) is
>>>>>>>> supported to truly disable generation.  For the time being you can use this
>>>>>>>> as well from annotations; just name the FK "none".
>>>>>>>>
>>>>>>>> If you can write some tests for this, it will make it easier for me
>>>>>>>> to implement.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Apr 1, 2015 at 5:40 AM, Petar Tahchiev <
>>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Oh,
>>>>>>>>>
>>>>>>>>> and one last thing: I don't think this is fixed:
>>>>>>>>> https://hibernate.atlassian.net/browse/HHH-8805
>>>>>>>>>
>>>>>>>>> Here's my mapping:
>>>>>>>>>
>>>>>>>>>     @ManyToMany(targetEntity = AbstractFilterModel.class, cascade
>>>>>>>>> = {
>>>>>>>>>         CascadeType.PERSIST,
>>>>>>>>>         CascadeType.MERGE,
>>>>>>>>>         CascadeType.REFRESH
>>>>>>>>>     }, fetch = FetchType.LAZY)
>>>>>>>>>     @JoinTable(indexes = {
>>>>>>>>>         @Index(unique = false, columnList = "entity_pk")
>>>>>>>>>     }, inverseForeignKey =
>>>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), inverseJoinColumns = {
>>>>>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>>>>>> true, updatable = true, foreignKey =
>>>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "filter_pk")
>>>>>>>>>     }, joinColumns = {
>>>>>>>>>         @JoinColumn(unique = false, nullable = true, insertable =
>>>>>>>>> true, updatable = true, foreignKey =
>>>>>>>>> @ForeignKey(ConstraintMode.NO_CONSTRAINT), name = "entity_pk")
>>>>>>>>>     }, foreignKey = @ForeignKey(ConstraintMode.NO_CONSTRAINT),
>>>>>>>>> name = "entity_filters")
>>>>>>>>>     private Collection<AbstractFilterModelDefinition> filters;
>>>>>>>>>
>>>>>>>>> As you can see I have added ConstraintMode.NO_CONSTRAINT wherever
>>>>>>>>> it is possible to add it. However here's what the schema tool generates:
>>>>>>>>>
>>>>>>>>>     create index IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>>>>>>>>> (entity_pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKra38l70n01disvkge7i9ff5ym
>>>>>>>>>         foreign key (filter_pk)
>>>>>>>>>         references abstract_filter (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKderx50xtd0lkeeblrj3o0ipq9
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references stock_level (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FK7ery3yx4pg32ogvv1wpr150oq
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references content_slot (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKse5m2mj7rrwj8ndimynfnr2px
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references blog_entry (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FK9nubqtdhrmefjv2a5oab2fcr2
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references price (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKcsuwqm524wu4u41oatrcalxvh
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references tax (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKmd3mm5pw9naa05ype38m6x1eo
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references abstract_template (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKsx6vnh2tga70pkne44dnq8kp0
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references discount (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FK6yx2wc1w1yb6qa1cx4byv7mju
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references classification_feature (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKpoh168do203hfqwb7so7c4c79
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references cms_navigation_node (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKi85fkvbm7otl679ijlr6oyoff
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references product (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKi8semxf3lq0n12lm05v7oydeq
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references abstract_page (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKsjqo9a6quh1cg4y0wyqo4tp8b
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references promotion (pk);
>>>>>>>>>
>>>>>>>>>     alter table entity_filters
>>>>>>>>>         add constraint FKfw64whfl6vgbqehj20qmc39i3
>>>>>>>>>         foreign key (entity_pk)
>>>>>>>>>         references simple_cms_widget (pk);
>>>>>>>>>
>>>>>>>>> The foreign keys are all different (in Hibernate 4.3.x they were
>>>>>>>>> the same), but I just don't want them. Shall I reopen the issue?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2015-04-01 13:32 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>>>>>
>>>>>>>>>> One other thing I noticed:
>>>>>>>>>> hibernate-core-5 depends on
>>>>>>>>>>
>>>>>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>>>>>> <version>3.2.1.Final</version>
>>>>>>>>>>
>>>>>>>>>> and if you have hibernate-validator 5.1.3.Final (the last
>>>>>>>>>> stable), it will depend on
>>>>>>>>>>
>>>>>>>>>> <groupId>org.jboss.logging</groupId>
>>>>>>>>>> <artifactId>jboss-logging</artifactId>
>>>>>>>>>> <version>3.1.4.GA</version>
>>>>>>>>>>
>>>>>>>>>> So you will get an exception of method not found on some
>>>>>>>>>> jboss-logging API. I excluded the jboss-loggin from the hibernate-validator
>>>>>>>>>> dependency, but now I get a ton of these TRACE statements
>>>>>>>>>> (literally every millisecond):
>>>>>>>>>>
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>> 2015-04-01 13:28:02,090
>>>>>>>>>> org.hibernate.event.internal.DefaultPersistEventListener
>>>>>>>>>> [http-nio-8112-exec-9] TRACE: Ignoring persistent instance
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  But at least it works.. I guess the only real solution is to
>>>>>>>>>> have hibernate-validator use the same jboss-logging version.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2015-04-01 10:39 GMT+03: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
>>>>>>>>>>> >
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> 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

From ales.justin at gmail.com  Fri Apr  3 06:18:52 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Fri, 3 Apr 2015 12:18:52 +0200
Subject: [hibernate-dev] document update change?
In-Reply-To: <02A54091-7B07-4B98-A34F-EB11786EA581@gmail.com>
References: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
	<02A54091-7B07-4B98-A34F-EB11786EA581@gmail.com>
Message-ID: <9FD4FFF9-A2AA-41F8-8CA6-12F4BB64D93D@gmail.com>

I think the problem is in our SearchWorkCreator, and how HS doesn't provide old value when doing update (while doing delete).

* https://github.com/capedwarf/capedwarf-blue/blob/master/datastore/src/main/java/org/jboss/capedwarf/datastore/CapedwarfSearchWorkCreator.java <https://github.com/capedwarf/capedwarf-blue/blob/master/datastore/src/main/java/org/jboss/capedwarf/datastore/CapedwarfSearchWorkCreator.java>

We "explode" original value with multiple "similar" values -- due to how projections and indexing works in GAE.
But since we don't get old value, we cannot fully re-construct previous "similar" values.

This used to work.
What changed in HS?

Or how to get old value to do proper delete?
e.g.
Grabbing the old value from cache (is it really still there? the old one that is ...), 
and creating proper DELETE manually, where I can then change UPDATE to ADD.

-Ales

> On 02 Apr 2015, at 21:00, Ales Justin <ales.justin at gmail.com> wrote:
> 
> When debugging, I see this -- it get "bbb" twice (old and new, where I would actually expect stale "ccc"):
> 
> results = {java.util.ArrayList at 17380}  size = 3
>  0 = {java.lang.Object[3]@17384} 
>   0 = {com.google.appengine.api.datastore.Key at 17395} "test(1)"
>   1 = {java.lang.String at 17396} "#Thu Apr 02 20:53:33 CEST 2015\nprop=STRING\n"
>   2 = {java.lang.String at 17397} "040:aaa"
>  1 = {java.lang.Object[3]@17385} 
>   0 = {com.google.appengine.api.datastore.Key at 17391} "test(1)"
>   1 = {java.lang.String at 17392} "#Thu Apr 02 20:51:24 CEST 2015\nprop=STRING\n"
>   2 = {java.lang.String at 17393} "040:bbb"
>  2 = {java.lang.Object[3]@17386} 
>   0 = {com.google.appengine.api.datastore.Key at 17387} "test(1)"
>   1 = {java.lang.String at 17388} "#Thu Apr 02 20:53:33 CEST 2015\nprop=STRING\n"
>   2 = {java.lang.String at 17389} "040:bbb"
> 
> 
> But still no idea on why dup "bbb" is there ...
> 
> -Ales
> 
>> On 01 Apr 2015, at 11:59, Ales Justin <ales.justin at gmail.com <mailto:ales.justin at gmail.com>> wrote:
>> 
>> Did entity updating changed in HS5 / Lucene4?
>> (aka Document updating)
>> 
>> Since this used to work for us (with HS4, Lucene3):
>> 
>> ---
>> @Test
>> public void testProjectionQueriesHandleEntityModificationProperly() throws Exception {
>>     Entity e = createEntity("test", 1)
>>         .withProperty("prop", Arrays.asList("aaa", "bbb", "ccc"))
>>         .store();
>> 
>>     Query query = new Query("test")
>>         .addProjection(new PropertyProjection("prop", String.class))
>>         .addSort("prop");
>> 
>>     assertEquals(3, service.prepare(query).asList(withDefaults()).size());
>> 
>>     e = createEntity(e.getKey())
>>         .withProperty("prop", Arrays.asList("aaa", "bbb"))
>>         .store();
>> 
>>     assertEquals(2, service.prepare(query).asList(withDefaults()).size());
>> 
>>     service.delete(e.getKey());
>> 
>>     assertEquals(0, service.prepare(query).asList(withDefaults()).size());
>> }
>> 
>> ---
>> 
>> Where we add each list/collection value under same field:
>> 
>> if (propertyValue instanceof Collection) {
>>     Collection collection = (Collection) propertyValue;
>>     for (Object element : collection) {
>>         if (PropertyUtils.isIndexedProperty(element)) {
>>             final Bridge inner = BridgeUtils.matchBridge(element);
>>             luceneOptions.addFieldToDocument(propertyName, inner.objectToString(element), document);
>>         }
>>     }
>> 
>> ---
>> 
>> As it looks like the update still keeps the old values around:
>> 
>> java.lang.AssertionError: expected:<2> but was:<3>
>>     at org.junit.Assert.fail(Assert.java:88)
>>     at org.junit.Assert.failNotEquals(Assert.java:743)
>>     at org.junit.Assert.assertEquals(Assert.java:118)
>>     at org.junit.Assert.assertEquals(Assert.java:555)
>>     at org.junit.Assert.assertEquals(Assert.java:542)
>>     at org.jboss.test.capedwarf.datastore.test.QueryOptimizationsTest.testProjectionQueriesHandleEntityModificationProperly(QueryOptimizationsTest.java:510)
>> 
>> ---
>> 
>> Any way to force / fix this?
>> 
>> -Ales
>> 
> 


From ales.justin at gmail.com  Fri Apr  3 06:38:00 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Fri, 3 Apr 2015 12:38:00 +0200
Subject: [hibernate-dev] document update change?
In-Reply-To: <9FD4FFF9-A2AA-41F8-8CA6-12F4BB64D93D@gmail.com>
References: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
	<02A54091-7B07-4B98-A34F-EB11786EA581@gmail.com>
	<9FD4FFF9-A2AA-41F8-8CA6-12F4BB64D93D@gmail.com>
Message-ID: <752149A9-7678-45D7-84BF-9E7160781765@gmail.com>

OK, found the culprit ...

It is this "weird" rule -- why not remove if the value class is the same?!

private boolean shouldRemove(Object value, Object previousValue) {
   return !(value == null || previousValue == null) && !value.getClass().equals(previousValue.getClass());
}
in

---
private void processPutKeyValueCommand(final PutKeyValueCommand command, final InvocationContext ctx, final Object previousValue, TransactionContext transactionContext) {
   final boolean usingSkipIndexCleanupFlag = usingSkipIndexCleanup(command);
   //whatever the new type, we might still need to cleanup for the previous value (and schedule removal first!)
   Object value = extractValue(command.getValue());
   if (!usingSkipIndexCleanupFlag && updateKnownTypesIfNeeded(previousValue) && shouldRemove(value, previousValue)) {
      if (shouldModifyIndexes(command, ctx)) {
         transactionContext = transactionContext == null ? makeTransactionalEventContext() : transactionContext;
         removeFromIndexes(previousValue, extractValue(command.getKey()), transactionContext);

---

-Ales

> On 03 Apr 2015, at 12:18, Ales Justin <ales.justin at gmail.com> wrote:
> 
> I think the problem is in our SearchWorkCreator, and how HS doesn't provide old value when doing update (while doing delete).
> 
> * https://github.com/capedwarf/capedwarf-blue/blob/master/datastore/src/main/java/org/jboss/capedwarf/datastore/CapedwarfSearchWorkCreator.java <https://github.com/capedwarf/capedwarf-blue/blob/master/datastore/src/main/java/org/jboss/capedwarf/datastore/CapedwarfSearchWorkCreator.java>
> 
> We "explode" original value with multiple "similar" values -- due to how projections and indexing works in GAE.
> But since we don't get old value, we cannot fully re-construct previous "similar" values.
> 
> This used to work.
> What changed in HS?
> 
> Or how to get old value to do proper delete?
> e.g.
> Grabbing the old value from cache (is it really still there? the old one that is ...), 
> and creating proper DELETE manually, where I can then change UPDATE to ADD.
> 
> -Ales
> 
>> On 02 Apr 2015, at 21:00, Ales Justin <ales.justin at gmail.com <mailto:ales.justin at gmail.com>> wrote:
>> 
>> When debugging, I see this -- it get "bbb" twice (old and new, where I would actually expect stale "ccc"):
>> 
>> results = {java.util.ArrayList at 17380}  size = 3
>>  0 = {java.lang.Object[3]@17384} 
>>   0 = {com.google.appengine.api.datastore.Key at 17395} "test(1)"
>>   1 = {java.lang.String at 17396} "#Thu Apr 02 20:53:33 CEST 2015\nprop=STRING\n"
>>   2 = {java.lang.String at 17397} "040:aaa"
>>  1 = {java.lang.Object[3]@17385} 
>>   0 = {com.google.appengine.api.datastore.Key at 17391} "test(1)"
>>   1 = {java.lang.String at 17392} "#Thu Apr 02 20:51:24 CEST 2015\nprop=STRING\n"
>>   2 = {java.lang.String at 17393} "040:bbb"
>>  2 = {java.lang.Object[3]@17386} 
>>   0 = {com.google.appengine.api.datastore.Key at 17387} "test(1)"
>>   1 = {java.lang.String at 17388} "#Thu Apr 02 20:53:33 CEST 2015\nprop=STRING\n"
>>   2 = {java.lang.String at 17389} "040:bbb"
>> 
>> 
>> But still no idea on why dup "bbb" is there ...
>> 
>> -Ales
>> 
>>> On 01 Apr 2015, at 11:59, Ales Justin <ales.justin at gmail.com <mailto:ales.justin at gmail.com>> wrote:
>>> 
>>> Did entity updating changed in HS5 / Lucene4?
>>> (aka Document updating)
>>> 
>>> Since this used to work for us (with HS4, Lucene3):
>>> 
>>> ---
>>> @Test
>>> public void testProjectionQueriesHandleEntityModificationProperly() throws Exception {
>>>     Entity e = createEntity("test", 1)
>>>         .withProperty("prop", Arrays.asList("aaa", "bbb", "ccc"))
>>>         .store();
>>> 
>>>     Query query = new Query("test")
>>>         .addProjection(new PropertyProjection("prop", String.class))
>>>         .addSort("prop");
>>> 
>>>     assertEquals(3, service.prepare(query).asList(withDefaults()).size());
>>> 
>>>     e = createEntity(e.getKey())
>>>         .withProperty("prop", Arrays.asList("aaa", "bbb"))
>>>         .store();
>>> 
>>>     assertEquals(2, service.prepare(query).asList(withDefaults()).size());
>>> 
>>>     service.delete(e.getKey());
>>> 
>>>     assertEquals(0, service.prepare(query).asList(withDefaults()).size());
>>> }
>>> 
>>> ---
>>> 
>>> Where we add each list/collection value under same field:
>>> 
>>> if (propertyValue instanceof Collection) {
>>>     Collection collection = (Collection) propertyValue;
>>>     for (Object element : collection) {
>>>         if (PropertyUtils.isIndexedProperty(element)) {
>>>             final Bridge inner = BridgeUtils.matchBridge(element);
>>>             luceneOptions.addFieldToDocument(propertyName, inner.objectToString(element), document);
>>>         }
>>>     }
>>> 
>>> ---
>>> 
>>> As it looks like the update still keeps the old values around:
>>> 
>>> java.lang.AssertionError: expected:<2> but was:<3>
>>>     at org.junit.Assert.fail(Assert.java:88)
>>>     at org.junit.Assert.failNotEquals(Assert.java:743)
>>>     at org.junit.Assert.assertEquals(Assert.java:118)
>>>     at org.junit.Assert.assertEquals(Assert.java:555)
>>>     at org.junit.Assert.assertEquals(Assert.java:542)
>>>     at org.jboss.test.capedwarf.datastore.test.QueryOptimizationsTest.testProjectionQueriesHandleEntityModificationProperly(QueryOptimizationsTest.java:510)
>>> 
>>> ---
>>> 
>>> Any way to force / fix this?
>>> 
>>> -Ales
>>> 
>> 
> 


From ales.justin at gmail.com  Fri Apr  3 06:58:21 2015
From: ales.justin at gmail.com (Ales Justin)
Date: Fri, 3 Apr 2015 12:58:21 +0200
Subject: [hibernate-dev] document update change?
In-Reply-To: <752149A9-7678-45D7-84BF-9E7160781765@gmail.com>
References: <5AF2E0F7-9BE8-487D-B3FF-DF29A9CF0F14@gmail.com>
	<02A54091-7B07-4B98-A34F-EB11786EA581@gmail.com>
	<9FD4FFF9-A2AA-41F8-8CA6-12F4BB64D93D@gmail.com>
	<752149A9-7678-45D7-84BF-9E7160781765@gmail.com>
Message-ID: <4338B523-68E3-4D11-9465-A8D0E6CA9C08@gmail.com>

https://github.com/infinispan/infinispan/commit/2d299745df1ce83c23ddc63e066ee820c184b8a7 <https://github.com/infinispan/infinispan/commit/2d299745df1ce83c23ddc63e066ee820c184b8a7>

> On 03 Apr 2015, at 12:38, Ales Justin <ales.justin at gmail.com> wrote:
> 
> OK, found the culprit ...
> 
> It is this "weird" rule -- why not remove if the value class is the same?!
> 
> private boolean shouldRemove(Object value, Object previousValue) {
>    return !(value == null || previousValue == null) && !value.getClass().equals(previousValue.getClass());
> }
> in
> 
> ---
> private void processPutKeyValueCommand(final PutKeyValueCommand command, final InvocationContext ctx, final Object previousValue, TransactionContext transactionContext) {
>    final boolean usingSkipIndexCleanupFlag = usingSkipIndexCleanup(command);
>    //whatever the new type, we might still need to cleanup for the previous value (and schedule removal first!)
>    Object value = extractValue(command.getValue());
>    if (!usingSkipIndexCleanupFlag && updateKnownTypesIfNeeded(previousValue) && shouldRemove(value, previousValue)) {
>       if (shouldModifyIndexes(command, ctx)) {
>          transactionContext = transactionContext == null ? makeTransactionalEventContext() : transactionContext;
>          removeFromIndexes(previousValue, extractValue(command.getKey()), transactionContext);
> 
> ---
> 
> -Ales
> 
>> On 03 Apr 2015, at 12:18, Ales Justin <ales.justin at gmail.com <mailto:ales.justin at gmail.com>> wrote:
>> 
>> I think the problem is in our SearchWorkCreator, and how HS doesn't provide old value when doing update (while doing delete).
>> 
>> * https://github.com/capedwarf/capedwarf-blue/blob/master/datastore/src/main/java/org/jboss/capedwarf/datastore/CapedwarfSearchWorkCreator.java <https://github.com/capedwarf/capedwarf-blue/blob/master/datastore/src/main/java/org/jboss/capedwarf/datastore/CapedwarfSearchWorkCreator.java>
>> 
>> We "explode" original value with multiple "similar" values -- due to how projections and indexing works in GAE.
>> But since we don't get old value, we cannot fully re-construct previous "similar" values.
>> 
>> This used to work.
>> What changed in HS?
>> 
>> Or how to get old value to do proper delete?
>> e.g.
>> Grabbing the old value from cache (is it really still there? the old one that is ...), 
>> and creating proper DELETE manually, where I can then change UPDATE to ADD.
>> 
>> -Ales
>> 
>>> On 02 Apr 2015, at 21:00, Ales Justin <ales.justin at gmail.com <mailto:ales.justin at gmail.com>> wrote:
>>> 
>>> When debugging, I see this -- it get "bbb" twice (old and new, where I would actually expect stale "ccc"):
>>> 
>>> results = {java.util.ArrayList at 17380}  size = 3
>>>  0 = {java.lang.Object[3]@17384} 
>>>   0 = {com.google.appengine.api.datastore.Key at 17395} "test(1)"
>>>   1 = {java.lang.String at 17396} "#Thu Apr 02 20:53:33 CEST 2015\nprop=STRING\n"
>>>   2 = {java.lang.String at 17397} "040:aaa"
>>>  1 = {java.lang.Object[3]@17385} 
>>>   0 = {com.google.appengine.api.datastore.Key at 17391} "test(1)"
>>>   1 = {java.lang.String at 17392} "#Thu Apr 02 20:51:24 CEST 2015\nprop=STRING\n"
>>>   2 = {java.lang.String at 17393} "040:bbb"
>>>  2 = {java.lang.Object[3]@17386} 
>>>   0 = {com.google.appengine.api.datastore.Key at 17387} "test(1)"
>>>   1 = {java.lang.String at 17388} "#Thu Apr 02 20:53:33 CEST 2015\nprop=STRING\n"
>>>   2 = {java.lang.String at 17389} "040:bbb"
>>> 
>>> 
>>> But still no idea on why dup "bbb" is there ...
>>> 
>>> -Ales
>>> 
>>>> On 01 Apr 2015, at 11:59, Ales Justin <ales.justin at gmail.com <mailto:ales.justin at gmail.com>> wrote:
>>>> 
>>>> Did entity updating changed in HS5 / Lucene4?
>>>> (aka Document updating)
>>>> 
>>>> Since this used to work for us (with HS4, Lucene3):
>>>> 
>>>> ---
>>>> @Test
>>>> public void testProjectionQueriesHandleEntityModificationProperly() throws Exception {
>>>>     Entity e = createEntity("test", 1)
>>>>         .withProperty("prop", Arrays.asList("aaa", "bbb", "ccc"))
>>>>         .store();
>>>> 
>>>>     Query query = new Query("test")
>>>>         .addProjection(new PropertyProjection("prop", String.class))
>>>>         .addSort("prop");
>>>> 
>>>>     assertEquals(3, service.prepare(query).asList(withDefaults()).size());
>>>> 
>>>>     e = createEntity(e.getKey())
>>>>         .withProperty("prop", Arrays.asList("aaa", "bbb"))
>>>>         .store();
>>>> 
>>>>     assertEquals(2, service.prepare(query).asList(withDefaults()).size());
>>>> 
>>>>     service.delete(e.getKey());
>>>> 
>>>>     assertEquals(0, service.prepare(query).asList(withDefaults()).size());
>>>> }
>>>> 
>>>> ---
>>>> 
>>>> Where we add each list/collection value under same field:
>>>> 
>>>> if (propertyValue instanceof Collection) {
>>>>     Collection collection = (Collection) propertyValue;
>>>>     for (Object element : collection) {
>>>>         if (PropertyUtils.isIndexedProperty(element)) {
>>>>             final Bridge inner = BridgeUtils.matchBridge(element);
>>>>             luceneOptions.addFieldToDocument(propertyName, inner.objectToString(element), document);
>>>>         }
>>>>     }
>>>> 
>>>> ---
>>>> 
>>>> As it looks like the update still keeps the old values around:
>>>> 
>>>> java.lang.AssertionError: expected:<2> but was:<3>
>>>>     at org.junit.Assert.fail(Assert.java:88)
>>>>     at org.junit.Assert.failNotEquals(Assert.java:743)
>>>>     at org.junit.Assert.assertEquals(Assert.java:118)
>>>>     at org.junit.Assert.assertEquals(Assert.java:555)
>>>>     at org.junit.Assert.assertEquals(Assert.java:542)
>>>>     at org.jboss.test.capedwarf.datastore.test.QueryOptimizationsTest.testProjectionQueriesHandleEntityModificationProperly(QueryOptimizationsTest.java:510)
>>>> 
>>>> ---
>>>> 
>>>> Any way to force / fix this?
>>>> 
>>>> -Ales
>>>> 
>>> 
>> 
> 


From emmanuel at hibernate.org  Fri Apr  3 09:15:13 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 3 Apr 2015 15:15:13 +0200
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-
	rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
Message-ID: <A98DF404-C62E-4866-8B18-8271FC9E82C9@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 at hibernate.org> 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 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
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From paranoiabla at gmail.com  Sun Apr  5 04:02:52 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Sun, 5 Apr 2015 11:02:52 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
Message-ID: <CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>

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



-- 
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

From steve at hibernate.org  Sun Apr  5 22:19:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 5 Apr 2015 21:19:13 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemUK9PDJRfeRVrzGOkPQ3V9B_wfK659XiEwk9VUh2ixYaA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX-nuQ1BDj+rB-rBzdQ5NJ9tJy8PfhXJmfGRCDDT=0T4iQ@mail.gmail.com>
	<CAKnbemXgJkuiFnH27xDrFYB-eay80YYvkEJX+6vTtX-kFJV6DA@mail.gmail.com>
	<CAKnbemXAa4SugmcqznCpJ-gkCcap9upeE8yYMhobopH=02hp7Q@mail.gmail.com>
	<CAFdSV9tZ-FHTRe=eEO4nq2fG5-31M+7PujmMGCUd4ijbqeu1GQ@mail.gmail.com>
	<CAFdSV9v6=jP4sLbK2HKdXf2k7=vgUBLVhOMEXL-5rcR82chMvg@mail.gmail.com>
	<CAFdSV9sVUfw+rVNcJwMxj1Jx9CQ=ceh_DZiBuFQtfJ2WsJDeMQ@mail.gmail.com>
	<CAKnbemXsM=z1Y1J8qkTC-znfFT_jfQazDtBNMukHaQWT-aat5w@mail.gmail.com>
	<CAFdSV9vem0iWMO8qxf3e-54cB6XmoY62i_0Bsx=HBUVPj-j5Vw@mail.gmail.com>
	<CAKnbemUyFSOYK7TUdYZMc9RKQ_xHzQds_DyAbwr=guyxpbK31Q@mail.gmail.com>
	<CAFdSV9vREXyV8G0SMY1OaHA4ND7WaSyqt=idspSoOSVDB4B8MQ@mail.gmail.com>
	<CAFdSV9sfWzB4BsPDh4XARMJm_C4W-Na+_Ad27+1paEjsbEfjgQ@mail.gmail.com>
	<CAKnbemUK9PDJRfeRVrzGOkPQ3V9B_wfK659XiEwk9VUh2ixYaA@mail.gmail.com>
Message-ID: <CAFdSV9urmijNVTtxZDrPmqjtyT+8dXTkkDq3VGZMOzwV00jo2A@mail.gmail.com>

On Thu, Apr 2, 2015 at 6:54 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Hi Steve,
>
> I just pulled and did ./gradlew install. Unfortunately this didn't install
> the jars in my local maven repo because the maven plugin declaration was
> missing (you might want to consider adding it).
>

That's because the task is not called install.  Install is Maven
terminlology, our build used Gradle.  The task you want is called
publishToMavenLocal.  And no, I'd prefer to not add that plugin.  I moved
away from Maven for a reason (well, ok, several) and prefer the Gradle
terminology.  The idea of "installing" my artifacts is such a logical
misnomer.



> Anyways, after I added it the jars were installed in my repo. I ran schema
> export and the schema result was missing the foreign keys - great!!!
> However when I ran my tests against HSQL (my tests are using
> hibernate.ddl-auto=update to create the tables) I got an exception:
>

SchemaMigratorImpl.java:128 is trying to get your table metadata from the
driver, but not finding any table information.  I'd need a test (simplified
this time please) that illustrates the problem.  Or else you can debug into
it.  What table?  What is special about that table versus other tables it
finds before?  Or does it not find any tables before?  Etc...

From steve at hibernate.org  Sun Apr  5 22:20:34 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 5 Apr 2015 21:20:34 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
Message-ID: <CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>

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

From steve at hibernate.org  Sun Apr  5 23:51:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sun, 5 Apr 2015 22:51:20 -0500
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <551D0F9E.1000801@redhat.com>
References: <551D0F9E.1000801@redhat.com>
Message-ID: <CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>

On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara <johara at redhat.com> wrote:

>  Steve,
>
> I have pushed a proposal for HHH-9701 to:
> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>
> There are a couple of areas that I would appreciate feedback;
>
> 1) Serialization/Deserialization - EntityEntries implementations can be
> serialized and each implementation provide their own serialization method.
> I have modified the serialization of EntityEntry in EntityEntryContext to
> write the Implementation class to the OutputStream so the correct class can
> be used to deserialize the object stream.  Is the exception handling
> sufficient here, or do we need more robust handling of deserialization
> exceptions? : see
> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>

I added some comments to that section.  Also, overall I would extract the
deserialization bit into a separate method (deserializeEntityEntry).



2) In our (perf team) use case, we want to be able to share the
> ImmutableEntityEntry between sessions when they are referenced cached in
> the 2lc. I have modified EntityEntryContext to not null
> managedEntity.$$_hibernate_setEntityEntry if the EntityEntry is an instance
> of ImmutableEntityEntry.  Do we need to add an extra checks here, to ensure
> that the entity is Reference Cached? I am not sure how we would test that
> case? : see
> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>

It really depends on what y'all consider the trigger for using
ImmutableEntityEntry.  When would the EntityPersister use the
EntityEntryFactory producing ImmutableEntityEntry instances?
a) when the entity is marked immutable?
b) when the entity is marked immutable *and* we need to cache it by
reference?
c) some other condition?

I agree that we should only not clear that reference when the entity is
enabled for cache-by-reference.  How that plays into this depends on the
answer to the above question.

If (a), then I think that yes it makes sense to add a check to only clear
the ManagedEntity's EntityEntry reference if using cache-by-reference.

If (b), then the EntiytPersister is only using the EntityEntryFactory
producing ImmutableEntityEntry instances when both are true.  So the fact
that an entry is an instance of ImmutableEntityEntry indicates that we need
to not clear it from the ManagedEntity.




> 3) Lock Mode: Steve you mentioned about not doing locking for Immutable
> entities. Where is the locking implemented? Would it be sufficient to
> simply set the LockMode on the ImmutableEntityEntry to NONE/READ_ONLY when
> setLockMode is called?
>


Locking is implemented in many places.

What I had in mind, in terms of implementation for EntityEntry, is somewhat
influenced by the choice between ignore versus exception in cases where
something is not supported.  Basically I had thought to throw an exception
in ImmutableEntityEntry#setLockMode or to simply ignore the call
altogether.  This is not a great solution.

It is hard for me to justify ignoring the lock request in all cases.  What
does everyone else think?

From paranoiabla at gmail.com  Mon Apr  6 02:34:47 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Mon, 6 Apr 2015 09:34:47 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
Message-ID: <CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>

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

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

From paranoiabla at gmail.com  Mon Apr  6 03:59:07 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Mon, 6 Apr 2015 10:59:07 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
Message-ID: <CAKnbemU1CQEsTVzvu8BEsG+pGETbiyi_yoQMTNwCndf7uLU5Aw@mail.gmail.com>

Wow, that's interesting. When I set the hbm2ddl-auto property to *create*,
then I get a lot of these:

2015-04-06 10:35:14,243 org.hibernate.tool.hbm2ddl.SchemaExport [main]
ERROR: HHH000389: Unsuccessful: alter table abstract_order drop constraint
FKqmp2kh2yeov0xhpk0heyrxg6q
2015-04-06 10:35:14,243 org.hibernate.tool.hbm2ddl.SchemaExport [main]
ERROR: user lacks privilege or object not found: PUBLIC.ABSTRACT_ORDER
2015-04-06 10:35:14,243 org.hibernate.tool.hbm2ddl.SchemaExport [main]
ERROR: HHH000389: Unsuccessful: alter table abstract_order drop constraint
FKni48bu7u20jisn95bc32ssqbm

but then it all seems to work fine. However, if I set it up to *update* it
throws the "BIG PROBLEM" in the SchemaMigratorImpl as I explained above.
This is a different behaviour than Hibernate 4.3.x and i'm not sure if it
is bug or maybe the update value has been deprecated...



2015-04-06 9:34 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:

> 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 at hibernate.org>:
>
>> 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 at gmail.com>
>> 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 at 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 at hibernate.org> 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 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
>>>> >>>>>>>>
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>
>>>> > _______________________________________________
>>>> > 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
>>>>
>>>
>>>
>>>
>>> --
>>> 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

From steve at hibernate.org  Mon Apr  6 06:56:01 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 6 Apr 2015 05:56:01 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
Message-ID: <CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>

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 at gmail.com>
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 at hibernate.org>:
>
>> 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 at gmail.com>
>> 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 at 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 at hibernate.org> 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 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
>>>> >>>>>>>>
>>>> >>>>>>>
>>>> >>>>>>>
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>
>>>> >>
>>>> > _______________________________________________
>>>> > 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
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>

From steve at hibernate.org  Mon Apr  6 06:58:17 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 6 Apr 2015 05:58:17 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
Message-ID: <CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>

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 at hibernate.org> 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 at gmail.com>
> 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 at hibernate.org>:
>>
>>> 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 at gmail.com>
>>> 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 at 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 at hibernate.org>
>>>>> 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 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
>>>>> >>>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>>
>>>>> >>>>>>
>>>>> >>>>>
>>>>> >>>>
>>>>> >>
>>>>> > _______________________________________________
>>>>> > 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>>
>
>

From steve at hibernate.org  Mon Apr  6 07:25:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 6 Apr 2015 06:25:30 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
	<CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
Message-ID: <CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>

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 at hibernate.org> 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 at hibernate.org>
> 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 at gmail.com>
>> 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 at hibernate.org>:
>>>
>>>> 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 at gmail.com>
>>>> 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 at 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 at hibernate.org>
>>>>>> 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 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
>>>>>> >>>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>
>>>>>> > _______________________________________________
>>>>>> > 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>
>>
>>
>

From paranoiabla at gmail.com  Mon Apr  6 07:33:01 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Mon, 6 Apr 2015 14:33:01 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
	<CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
	<CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>
Message-ID: <CAKnbemVft10UkvuKW2j=r=2ve9WWEiOX8KtKpb--JhW619Jv=A@mail.gmail.com>

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

> 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 at hibernate.org>
> 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 at hibernate.org>
>> 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 at gmail.com>
>>> 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 at hibernate.org>:
>>>>
>>>>> 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 at gmail.com>
>>>>> 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 at 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 at hibernate.org>
>>>>>>> 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 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
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>
>>>>>>> >>>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> >>
>>>>>>> > _______________________________________________
>>>>>>> > 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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

From steve at hibernate.org  Mon Apr  6 07:34:50 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 6 Apr 2015 06:34:50 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemVft10UkvuKW2j=r=2ve9WWEiOX8KtKpb--JhW619Jv=A@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
	<CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
	<CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>
	<CAKnbemVft10UkvuKW2j=r=2ve9WWEiOX8KtKpb--JhW619Jv=A@mail.gmail.com>
Message-ID: <CAFdSV9vfMPhaYx_d9kBqibPkVEkVAhBCDG54hNuTe3JoBhuxEw@mail.gmail.com>

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 at gmail.com>
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 at hibernate.org>:
>
>> 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 at hibernate.org>
>> 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 at hibernate.org>
>>> 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 at gmail.com>
>>>> 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 at hibernate.org>:
>>>>>
>>>>>> 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 at gmail.com
>>>>>> > 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 at 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 at hibernate.org>
>>>>>>>> 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 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
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>
>>>>>>>> >>>>>
>>>>>>>> >>>>
>>>>>>>> >>
>>>>>>>> > _______________________________________________
>>>>>>>> > 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> 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
>

From steve at hibernate.org  Mon Apr  6 08:22:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 6 Apr 2015 07:22:23 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9vfMPhaYx_d9kBqibPkVEkVAhBCDG54hNuTe3JoBhuxEw@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
	<CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
	<CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>
	<CAKnbemVft10UkvuKW2j=r=2ve9WWEiOX8KtKpb--JhW619Jv=A@mail.gmail.com>
	<CAFdSV9vfMPhaYx_d9kBqibPkVEkVAhBCDG54hNuTe3JoBhuxEw@mail.gmail.com>
Message-ID: <CAFdSV9ttoGsEHp8J-Ej46oJMd=xVBMWYNBGmGpc2E390etFKTA@mail.gmail.com>

I am not fully aware of HSQLDB usage, but I wonder if you end up using 2
different databases.  I am fairly certain you are using an in-memory
database.  In the test you are asking Hibernate to create a
ConnectionProvider explicitly (your buildHibernateConfiguration method).  I
know absolutely zero about spring boot to know how in the heck it is
creating the the Hibernate EntityManager for you, but I suspect it somehow
causes a different HSQLDB instance to be started.

The reason I say that is in my simplified version of your test I re-use the
same HSQLDB instance for sure and get different results.

Still there does seem to be a problem
in org.hibernate.tool.schema.extract.internal.legacy.DatabaseInformationImpl
where it is not finding tables.  If you have a local fork of Hibernate
could you try changing the determineCatalogFilter and determineSchemaFilter
in
org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
to return ALL_CATALOGS_FILTER and ALL_SCHEMAS_FILTER instead of
SANS_CATALOG_FILTER and SANS_SCHEMA_FILTER as the fallback options and see
if that helps for you?


On Mon, Apr 6, 2015 at 6:34 AM, Steve Ebersole <steve at hibernate.org> wrote:

> 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 at gmail.com>
> 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 at hibernate.org>:
>>
>>> 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 at hibernate.org>
>>> 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 at hibernate.org>
>>>> 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 at gmail.com>
>>>>> 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 at hibernate.org>:
>>>>>>
>>>>>>> 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 at gmail.com> 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 at 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 at hibernate.org>
>>>>>>>>> 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 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
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>
>>>>>>>>> >>
>>>>>>>>> > _______________________________________________
>>>>>>>>> > 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 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
>>
>
>

From paranoiabla at gmail.com  Mon Apr  6 08:35:52 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Mon, 6 Apr 2015 15:35:52 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9ttoGsEHp8J-Ej46oJMd=xVBMWYNBGmGpc2E390etFKTA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
	<CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
	<CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>
	<CAKnbemVft10UkvuKW2j=r=2ve9WWEiOX8KtKpb--JhW619Jv=A@mail.gmail.com>
	<CAFdSV9vfMPhaYx_d9kBqibPkVEkVAhBCDG54hNuTe3JoBhuxEw@mail.gmail.com>
	<CAFdSV9ttoGsEHp8J-Ej46oJMd=xVBMWYNBGmGpc2E390etFKTA@mail.gmail.com>
Message-ID: <CAKnbemW0YMO-K0KQS4_u_=cH9Og5otArkqkyL+bVHRh6rqNeWA@mail.gmail.com>

Hi Steve,

thank you soo much for your support. I tried changing it but it had no
effect. I also added a breakpoint in
InformationExtractorJdbcDatabaseMetaDataImpl:135 and :151 but the flow
never really goes through those breakpoints :(

2015-04-06 15:22 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> I am not fully aware of HSQLDB usage, but I wonder if you end up using 2
> different databases.  I am fairly certain you are using an in-memory
> database.  In the test you are asking Hibernate to create a
> ConnectionProvider explicitly (your buildHibernateConfiguration method).  I
> know absolutely zero about spring boot to know how in the heck it is
> creating the the Hibernate EntityManager for you, but I suspect it somehow
> causes a different HSQLDB instance to be started.
>
> The reason I say that is in my simplified version of your test I re-use
> the same HSQLDB instance for sure and get different results.
>
> Still there does seem to be a problem
> in org.hibernate.tool.schema.extract.internal.legacy.DatabaseInformationImpl
> where it is not finding tables.  If you have a local fork of Hibernate
> could you try changing the determineCatalogFilter and determineSchemaFilter
> in
> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
> to return ALL_CATALOGS_FILTER and ALL_SCHEMAS_FILTER instead of
> SANS_CATALOG_FILTER and SANS_SCHEMA_FILTER as the fallback options and see
> if that helps for you?
>
>
> On Mon, Apr 6, 2015 at 6:34 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> 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 at gmail.com>
>> 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 at hibernate.org>:
>>>
>>>> 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 at hibernate.org>
>>>> 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 at hibernate.org>
>>>>> 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 at gmail.com
>>>>>> > 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 at hibernate.org>:
>>>>>>>
>>>>>>>> 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 at gmail.com> 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 at 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 at hibernate.org>
>>>>>>>>>> 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 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
>>>>>>>>>> >>>>>>>>
>>>>>>>>>> >>>>>>>
>>>>>>>>>> >>>>>>>
>>>>>>>>>> >>>>>>
>>>>>>>>>> >>>>>
>>>>>>>>>> >>>>
>>>>>>>>>> >>
>>>>>>>>>> > _______________________________________________
>>>>>>>>>> > 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>
>>
>>
>


-- 
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

From steve at hibernate.org  Mon Apr  6 10:37:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 6 Apr 2015 09:37:06 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemW0YMO-K0KQS4_u_=cH9Og5otArkqkyL+bVHRh6rqNeWA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
	<CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
	<CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>
	<CAKnbemVft10UkvuKW2j=r=2ve9WWEiOX8KtKpb--JhW619Jv=A@mail.gmail.com>
	<CAFdSV9vfMPhaYx_d9kBqibPkVEkVAhBCDG54hNuTe3JoBhuxEw@mail.gmail.com>
	<CAFdSV9ttoGsEHp8J-Ej46oJMd=xVBMWYNBGmGpc2E390etFKTA@mail.gmail.com>
	<CAKnbemW0YMO-K0KQS4_u_=cH9Og5otArkqkyL+bVHRh6rqNeWA@mail.gmail.com>
Message-ID: <CAFdSV9sMNpS15L3WNLzAi8bt+1rv=a2=iG7B6HphemyyfSEHag@mail.gmail.com>

Petar, not sure what to say.  That sounds like a local set up problem.  I
cannot really help with that.

Anyway, I have a "stripped down" version of your test.  I ripped out Spring
and added a Gradle build script.  The actual test class/method changed
slightly to be just one test method:


public class Hhh8805ApplicationTests {
    @Test
    public void testIt() {
        final StandardServiceRegistry standardRegistry = new
StandardServiceRegistryBuilder()
                .loadProperties( "demo/hibernate.properties" )
                .build();

        try {
            final MetadataImplementor metadata = (MetadataImplementor) new
MetadataSources( standardRegistry )
                    .addAnnotatedClass(AbstractEntityModel.class)
                    .addAnnotatedClass( AbstractFilteredEntityModel.class )
                    .addAnnotatedClass( AbstractFilterModel.class )
                    .addAnnotatedClass( CategoryModel.class )
                    .addAnnotatedClass( ProductModel.class )
                    .addAnnotatedClass( DesktopFilter.class )
                    .addAnnotatedClass( MobileFilter.class )
                    .buildMetadata();

            // export the schema
            new SchemaExport( metadata ).execute( false, true, false, false
);

            try {
                // update the schema
                new SchemaUpdate( metadata ).execute( false, true );
            }
            finally {
                // drop the schema
                new SchemaExport( metadata ).execute( false, true, false,
false );
            }

        }
        finally {
            StandardServiceRegistryBuilder.destroy( standardRegistry );
        }

    }
}

So basically, it does an explicit SchemaExport followed by an explicit
SchemaUpdate.  Just like your tests, it does the initial SchemExport to
make sure that SchemaUpdate is finding the existing tables and altering
them.  Anyway, this fails but it fails in a way I completely expect after
looking at it based on what is quite likely a bug but a bug that is in 4.3
(at least) as well.  The failure is an attempt to create the index you
 specified in the mappings.  Hibernate is trying to create the index, but
for your database it is generating the name to use in the CREATE INDEX
command incorrectly (this is the bug):

09:34:08,484 ERROR SchemaExport:458 - HHH000389: Unsuccessful: create index
entity_filters.IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters (entity_pk)
09:34:08,484 ERROR SchemaExport:459 - invalid schema name: ENTITY_FILTERS

I need to investigate this one a bit.  I created
https://hibernate.atlassian.net/browse/HHH-9713 to do that investigation.


On Mon, Apr 6, 2015 at 7:35 AM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Hi Steve,
>
> thank you soo much for your support. I tried changing it but it had no
> effect. I also added a breakpoint in
> InformationExtractorJdbcDatabaseMetaDataImpl:135 and :151 but the flow
> never really goes through those breakpoints :(
>
> 2015-04-06 15:22 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> I am not fully aware of HSQLDB usage, but I wonder if you end up using 2
>> different databases.  I am fairly certain you are using an in-memory
>> database.  In the test you are asking Hibernate to create a
>> ConnectionProvider explicitly (your buildHibernateConfiguration method).  I
>> know absolutely zero about spring boot to know how in the heck it is
>> creating the the Hibernate EntityManager for you, but I suspect it somehow
>> causes a different HSQLDB instance to be started.
>>
>> The reason I say that is in my simplified version of your test I re-use
>> the same HSQLDB instance for sure and get different results.
>>
>> Still there does seem to be a problem
>> in org.hibernate.tool.schema.extract.internal.legacy.DatabaseInformationImpl
>> where it is not finding tables.  If you have a local fork of Hibernate
>> could you try changing the determineCatalogFilter and determineSchemaFilter
>> in
>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
>> to return ALL_CATALOGS_FILTER and ALL_SCHEMAS_FILTER instead of
>> SANS_CATALOG_FILTER and SANS_SCHEMA_FILTER as the fallback options and see
>> if that helps for you?
>>
>>
>> On Mon, Apr 6, 2015 at 6:34 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> 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 at gmail.com>
>>> 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 at hibernate.org>:
>>>>
>>>>> 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 at hibernate.org>
>>>>> 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 at hibernate.org>
>>>>>> 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 at gmail.com> 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 at hibernate.org>:
>>>>>>>>
>>>>>>>>> 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 at gmail.com> 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 at 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 at hibernate.org>
>>>>>>>>>>> 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 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
>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>>
>>>>>>>>>>> >>>>>>
>>>>>>>>>>> >>>>>
>>>>>>>>>>> >>>>
>>>>>>>>>>> >>
>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>> > 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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
>>>>
>>>
>>>
>>
>
>
> --
> 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
>

From steve at hibernate.org  Mon Apr  6 15:07:40 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 6 Apr 2015 14:07:40 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9sMNpS15L3WNLzAi8bt+1rv=a2=iG7B6HphemyyfSEHag@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
	<CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
	<CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>
	<CAKnbemVft10UkvuKW2j=r=2ve9WWEiOX8KtKpb--JhW619Jv=A@mail.gmail.com>
	<CAFdSV9vfMPhaYx_d9kBqibPkVEkVAhBCDG54hNuTe3JoBhuxEw@mail.gmail.com>
	<CAFdSV9ttoGsEHp8J-Ej46oJMd=xVBMWYNBGmGpc2E390etFKTA@mail.gmail.com>
	<CAKnbemW0YMO-K0KQS4_u_=cH9Og5otArkqkyL+bVHRh6rqNeWA@mail.gmail.com>
	<CAFdSV9sMNpS15L3WNLzAi8bt+1rv=a2=iG7B6HphemyyfSEHag@mail.gmail.com>
Message-ID: <CAFdSV9ujuRkxx_RHwSCeB3OT69vBNszeE7f5442wkCEgM6DugA@mail.gmail.com>

Petar, I just resolved HHH-9713 and it was working against my simplified
version of your demo.  Just fyi...

On Mon, Apr 6, 2015 at 9:37 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Petar, not sure what to say.  That sounds like a local set up problem.  I
> cannot really help with that.
>
> Anyway, I have a "stripped down" version of your test.  I ripped out
> Spring and added a Gradle build script.  The actual test class/method
> changed slightly to be just one test method:
>
>
> public class Hhh8805ApplicationTests {
>     @Test
>     public void testIt() {
>         final StandardServiceRegistry standardRegistry = new
> StandardServiceRegistryBuilder()
>                 .loadProperties( "demo/hibernate.properties" )
>                 .build();
>
>         try {
>             final MetadataImplementor metadata = (MetadataImplementor) new
> MetadataSources( standardRegistry )
>                     .addAnnotatedClass(AbstractEntityModel.class)
>                     .addAnnotatedClass( AbstractFilteredEntityModel.class )
>                     .addAnnotatedClass( AbstractFilterModel.class )
>                     .addAnnotatedClass( CategoryModel.class )
>                     .addAnnotatedClass( ProductModel.class )
>                     .addAnnotatedClass( DesktopFilter.class )
>                     .addAnnotatedClass( MobileFilter.class )
>                     .buildMetadata();
>
>             // export the schema
>             new SchemaExport( metadata ).execute( false, true, false,
> false );
>
>             try {
>                 // update the schema
>                 new SchemaUpdate( metadata ).execute( false, true );
>             }
>             finally {
>                 // drop the schema
>                 new SchemaExport( metadata ).execute( false, true, false,
> false );
>             }
>
>         }
>         finally {
>             StandardServiceRegistryBuilder.destroy( standardRegistry );
>         }
>
>     }
> }
>
> So basically, it does an explicit SchemaExport followed by an explicit
> SchemaUpdate.  Just like your tests, it does the initial SchemExport to
> make sure that SchemaUpdate is finding the existing tables and altering
> them.  Anyway, this fails but it fails in a way I completely expect after
> looking at it based on what is quite likely a bug but a bug that is in 4.3
> (at least) as well.  The failure is an attempt to create the index you
>  specified in the mappings.  Hibernate is trying to create the index, but
> for your database it is generating the name to use in the CREATE INDEX
> command incorrectly (this is the bug):
>
> 09:34:08,484 ERROR SchemaExport:458 - HHH000389: Unsuccessful: create
> index entity_filters.IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
> (entity_pk)
> 09:34:08,484 ERROR SchemaExport:459 - invalid schema name: ENTITY_FILTERS
>
> I need to investigate this one a bit.  I created
> https://hibernate.atlassian.net/browse/HHH-9713 to do that investigation.
>
>
> On Mon, Apr 6, 2015 at 7:35 AM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Hi Steve,
>>
>> thank you soo much for your support. I tried changing it but it had no
>> effect. I also added a breakpoint in
>> InformationExtractorJdbcDatabaseMetaDataImpl:135 and :151 but the flow
>> never really goes through those breakpoints :(
>>
>> 2015-04-06 15:22 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> I am not fully aware of HSQLDB usage, but I wonder if you end up using 2
>>> different databases.  I am fairly certain you are using an in-memory
>>> database.  In the test you are asking Hibernate to create a
>>> ConnectionProvider explicitly (your buildHibernateConfiguration method).  I
>>> know absolutely zero about spring boot to know how in the heck it is
>>> creating the the Hibernate EntityManager for you, but I suspect it somehow
>>> causes a different HSQLDB instance to be started.
>>>
>>> The reason I say that is in my simplified version of your test I re-use
>>> the same HSQLDB instance for sure and get different results.
>>>
>>> Still there does seem to be a problem
>>> in org.hibernate.tool.schema.extract.internal.legacy.DatabaseInformationImpl
>>> where it is not finding tables.  If you have a local fork of Hibernate
>>> could you try changing the determineCatalogFilter and determineSchemaFilter
>>> in
>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
>>> to return ALL_CATALOGS_FILTER and ALL_SCHEMAS_FILTER instead of
>>> SANS_CATALOG_FILTER and SANS_SCHEMA_FILTER as the fallback options and see
>>> if that helps for you?
>>>
>>>
>>> On Mon, Apr 6, 2015 at 6:34 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> 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 at gmail.com>
>>>> 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 at hibernate.org>:
>>>>>
>>>>>> 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 at hibernate.org>
>>>>>> 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 at hibernate.org>
>>>>>>> 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 at gmail.com> 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 at hibernate.org>:
>>>>>>>>>
>>>>>>>>>> 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 at gmail.com> 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 at 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 at hibernate.org>
>>>>>>>>>>>> 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 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
>>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>> >>>>>>>
>>>>>>>>>>>> >>>>>>>
>>>>>>>>>>>> >>>>>>
>>>>>>>>>>>> >>>>>
>>>>>>>>>>>> >>>>
>>>>>>>>>>>> >>
>>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>>> > 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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> 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
>>
>
>

From paranoiabla at gmail.com  Mon Apr  6 15:41:08 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Mon, 6 Apr 2015 22:41:08 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAFdSV9ujuRkxx_RHwSCeB3OT69vBNszeE7f5442wkCEgM6DugA@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
	<CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
	<CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>
	<CAKnbemVft10UkvuKW2j=r=2ve9WWEiOX8KtKpb--JhW619Jv=A@mail.gmail.com>
	<CAFdSV9vfMPhaYx_d9kBqibPkVEkVAhBCDG54hNuTe3JoBhuxEw@mail.gmail.com>
	<CAFdSV9ttoGsEHp8J-Ej46oJMd=xVBMWYNBGmGpc2E390etFKTA@mail.gmail.com>
	<CAKnbemW0YMO-K0KQS4_u_=cH9Og5otArkqkyL+bVHRh6rqNeWA@mail.gmail.com>
	<CAFdSV9sMNpS15L3WNLzAi8bt+1rv=a2=iG7B6HphemyyfSEHag@mail.gmail.com>
	<CAFdSV9ujuRkxx_RHwSCeB3OT69vBNszeE7f5442wkCEgM6DugA@mail.gmail.com>
Message-ID: <CAKnbemX6TyFwQRudVQgp=b3xEjxvMNp9H2j0KGeZin7hVRB30g@mail.gmail.com>

Hi Steve,

just tested - works like a charm. Thanks a ton :) The only 2 things left
for me are
1) "[main] WARN : HHH000072: Duplicate joins for class" - I'm not really
bothered with this one as it is a warning.
2) "TRACE: Ignoring persistent instance" - as I already mentioned there's a
massive TRACE log (millions of lines) which started appearing once I
excluded the logging

            <exclusions>
                <exclusion>
                    <!-- Hibernate5 uses newer so we need to exclude this-->
                    <groupId>org.jboss.logging</groupId>
                    <artifactId>jboss-logging</artifactId>
                </exclusion>
            </exclusions>

Again, this is a minor issue, as I'm hoping the hibernate validator project
will update the commons logging and this issue will be resolved.

Thanks again for your support :)


2015-04-06 22:07 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> Petar, I just resolved HHH-9713 and it was working against my simplified
> version of your demo.  Just fyi...
>
> On Mon, Apr 6, 2015 at 9:37 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Petar, not sure what to say.  That sounds like a local set up problem.  I
>> cannot really help with that.
>>
>> Anyway, I have a "stripped down" version of your test.  I ripped out
>> Spring and added a Gradle build script.  The actual test class/method
>> changed slightly to be just one test method:
>>
>>
>> public class Hhh8805ApplicationTests {
>>     @Test
>>     public void testIt() {
>>         final StandardServiceRegistry standardRegistry = new
>> StandardServiceRegistryBuilder()
>>                 .loadProperties( "demo/hibernate.properties" )
>>                 .build();
>>
>>         try {
>>             final MetadataImplementor metadata = (MetadataImplementor)
>> new MetadataSources( standardRegistry )
>>                     .addAnnotatedClass(AbstractEntityModel.class)
>>                     .addAnnotatedClass( AbstractFilteredEntityModel.class
>> )
>>                     .addAnnotatedClass( AbstractFilterModel.class )
>>                     .addAnnotatedClass( CategoryModel.class )
>>                     .addAnnotatedClass( ProductModel.class )
>>                     .addAnnotatedClass( DesktopFilter.class )
>>                     .addAnnotatedClass( MobileFilter.class )
>>                     .buildMetadata();
>>
>>             // export the schema
>>             new SchemaExport( metadata ).execute( false, true, false,
>> false );
>>
>>             try {
>>                 // update the schema
>>                 new SchemaUpdate( metadata ).execute( false, true );
>>             }
>>             finally {
>>                 // drop the schema
>>                 new SchemaExport( metadata ).execute( false, true, false,
>> false );
>>             }
>>
>>         }
>>         finally {
>>             StandardServiceRegistryBuilder.destroy( standardRegistry );
>>         }
>>
>>     }
>> }
>>
>> So basically, it does an explicit SchemaExport followed by an explicit
>> SchemaUpdate.  Just like your tests, it does the initial SchemExport to
>> make sure that SchemaUpdate is finding the existing tables and altering
>> them.  Anyway, this fails but it fails in a way I completely expect after
>> looking at it based on what is quite likely a bug but a bug that is in 4.3
>> (at least) as well.  The failure is an attempt to create the index you
>>  specified in the mappings.  Hibernate is trying to create the index, but
>> for your database it is generating the name to use in the CREATE INDEX
>> command incorrectly (this is the bug):
>>
>> 09:34:08,484 ERROR SchemaExport:458 - HHH000389: Unsuccessful: create
>> index entity_filters.IDX8b6xl4emqmow8hikaf4hgx9xn on entity_filters
>> (entity_pk)
>> 09:34:08,484 ERROR SchemaExport:459 - invalid schema name: ENTITY_FILTERS
>>
>> I need to investigate this one a bit.  I created
>> https://hibernate.atlassian.net/browse/HHH-9713 to do that investigation.
>>
>>
>> On Mon, Apr 6, 2015 at 7:35 AM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Hi Steve,
>>>
>>> thank you soo much for your support. I tried changing it but it had no
>>> effect. I also added a breakpoint in
>>> InformationExtractorJdbcDatabaseMetaDataImpl:135 and :151 but the flow
>>> never really goes through those breakpoints :(
>>>
>>> 2015-04-06 15:22 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> I am not fully aware of HSQLDB usage, but I wonder if you end up using
>>>> 2 different databases.  I am fairly certain you are using an in-memory
>>>> database.  In the test you are asking Hibernate to create a
>>>> ConnectionProvider explicitly (your buildHibernateConfiguration method).  I
>>>> know absolutely zero about spring boot to know how in the heck it is
>>>> creating the the Hibernate EntityManager for you, but I suspect it somehow
>>>> causes a different HSQLDB instance to be started.
>>>>
>>>> The reason I say that is in my simplified version of your test I re-use
>>>> the same HSQLDB instance for sure and get different results.
>>>>
>>>> Still there does seem to be a problem
>>>> in org.hibernate.tool.schema.extract.internal.legacy.DatabaseInformationImpl
>>>> where it is not finding tables.  If you have a local fork of Hibernate
>>>> could you try changing the determineCatalogFilter and determineSchemaFilter
>>>> in
>>>> org.hibernate.tool.schema.extract.internal.InformationExtractorJdbcDatabaseMetaDataImpl
>>>> to return ALL_CATALOGS_FILTER and ALL_SCHEMAS_FILTER instead of
>>>> SANS_CATALOG_FILTER and SANS_SCHEMA_FILTER as the fallback options and see
>>>> if that helps for you?
>>>>
>>>>
>>>> On Mon, Apr 6, 2015 at 6:34 AM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> 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 at gmail.com>
>>>>> 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 at hibernate.org>:
>>>>>>
>>>>>>> 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 at hibernate.org>
>>>>>>> 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 at hibernate.org
>>>>>>>> > 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 at gmail.com> 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 at hibernate.org>:
>>>>>>>>>>
>>>>>>>>>>> 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 at gmail.com> 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 at 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 at hibernate.org> 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 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
>>>>>>>>>>>>> >>>>>>>>
>>>>>>>>>>>>> >>>>>>>
>>>>>>>>>>>>> >>>>>>>
>>>>>>>>>>>>> >>>>>>
>>>>>>>>>>>>> >>>>>
>>>>>>>>>>>>> >>>>
>>>>>>>>>>>>> >>
>>>>>>>>>>>>> > _______________________________________________
>>>>>>>>>>>>> > 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
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> 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

From steve at hibernate.org  Mon Apr  6 16:39:32 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 6 Apr 2015 15:39:32 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
In-Reply-To: <CAKnbemX6TyFwQRudVQgp=b3xEjxvMNp9H2j0KGeZin7hVRB30g@mail.gmail.com>
References: <CAKnbemW3-TP6aC+mtN-e75GjJ0_cJJ2AWfrFq-Z_4xSCv9RA2g@mail.gmail.com>
	<CAFdSV9tKpZO0O-08VeXepCNHJ5h=6tfpWPj1JpcQk84zYwBPYA@mail.gmail.com>
	<CAFdSV9vnZLFaJZJZ85uTtz=vasqmkvxj9BaZ+MMk6y=SsMuMzg@mail.gmail.com>
	<CAFdSV9t4sXicNyNjJvXnVo6K8TWE1xPum_4qqcSVGMKusxMUGg@mail.gmail.com>
	<CAKnbemXqtK13P--dncz=YvfQ0fzGmh+zrD+Ay7BA9OFmTwE_3Q@mail.gmail.com>
	<CAFdSV9tcWDRnmr8Noe9HuKmpF70iA=5Shj-xp-t62qH6_n6Xdw@mail.gmail.com>
	<CAKnbemU9XrY-KOd6dK8hOVA=OB59gUPex-c9+H7oxh-gBVYxUw@mail.gmail.com>
	<CAKnbemWrNM_SJUT1+aX+xPDf3owseJa0L+J0yc6OagEZ2hz8GA@mail.gmail.com>
	<CAFdSV9uqMQ1PbHDoHsuyGY5sN19X+E6xN_+VNzPmL_Vu_xC5Dw@mail.gmail.com>
	<CAFdSV9tLQrfx8tKE=2rQBHtsCL=rN4KPJmJ0Gh2Yxn5=t8T4LA@mail.gmail.com>
	<CAFdSV9sFiLZsFAczAM99A4-61dp=kGakyfdXWFsezW-HEq66uA@mail.gmail.com>
	<CAFm4XO1RiYzwafWWM69hua8=rKHAcF8Wrrexa-J_ji2Ox+18Wg@mail.gmail.com>
	<CAFdSV9vim4=5T6zAB85JihnTGdTWfxA_jWgMpjmuV2c2co-R1Q@mail.gmail.com>
	<CAFdSV9vjqiUwmRV-7_pPa_uyZ2V6AA_=nca6cXXJHqGKNGsd2w@mail.gmail.com>
	<CADGJaX_9VKB_patj0zMvE=396vnhbUBtYF9GrE7LhG5b7614_g@mail.gmail.com>
	<CAFdSV9v=Fv5U0CDVca43jju0_zbgN-KDAbd4z5VCQUeNW9odWw@mail.gmail.com>
	<CADGJaX_amyBaJhfrgffd61VhneHbjpOtPpGVR-c0vpQVbY0BDA@mail.gmail.com>
	<CAFdSV9sDhS5SJDc0=EKpLg6OEnS+H=cU_=zkKqHr0XO8N3BqVg@mail.gmail.com>
	<CADGJaX9FJfm3hm-eugA+BiqpV_jdk4iRZK-bGcf0ZcKud5Utzw@mail.gmail.com>
	<CAFdSV9shM6oQxmow9rwe7O+8k_hP-ALcaGKL+X_DfV6kZ9XYvQ@mail.gmail.com>
	<A98DF404-C62E-4866-8B18-8271FC9E82C9@hibernate.org>
	<CAKnbemV3r_i3UaxX_uGZnfG4kX4NmZFMMtqD_C4EEwRMosMtyw@mail.gmail.com>
	<CAFdSV9tft6rD4xLnV7kwiKBS326Z8V7X-=_ksJCNZifw1vMf-g@mail.gmail.com>
	<CAKnbemWzrgz2GmxLoJ=qOaDYPiiQbU30AvRo14ehFNW+kzLQ4g@mail.gmail.com>
	<CAFdSV9usE3Lez2ofjs1uQygSXLrxXmtofptqWBztoofLQKKcGQ@mail.gmail.com>
	<CAFdSV9sD1nicCgNe99VHVXZYuvtwUB0=FWN8TXS4H8o0Y6B-kw@mail.gmail.com>
	<CAFdSV9ub+UWVkC1VbCubcDripa0N_9fx8WedfoUjA3KCTFxaCw@mail.gmail.com>
	<CAKnbemVft10UkvuKW2j=r=2ve9WWEiOX8KtKpb--JhW619Jv=A@mail.gmail.com>
	<CAFdSV9vfMPhaYx_d9kBqibPkVEkVAhBCDG54hNuTe3JoBhuxEw@mail.gmail.com>
	<CAFdSV9ttoGsEHp8J-Ej46oJMd=xVBMWYNBGmGpc2E390etFKTA@mail.gmail.com>
	<CAKnbemW0YMO-K0KQS4_u_=cH9Og5otArkqkyL+bVHRh6rqNeWA@mail.gmail.com>
	<CAFdSV9sMNpS15L3WNLzAi8bt+1rv=a2=iG7B6HphemyyfSEHag@mail.gmail.com>
	<CAFdSV9ujuRkxx_RHwSCeB3OT69vBNszeE7f5442wkCEgM6DugA@mail.gmail.com>
	<CAKnbemX6TyFwQRudVQgp=b3xEjxvMNp9H2j0KGeZin7hVRB30g@mail.gmail.com>
Message-ID: <CAFdSV9tEXmKH2DvTm1keOFBvcaqrrQiLAKTKDTMf1E9hxL0U2A@mail.gmail.com>

On Mon, Apr 6, 2015 at 2:41 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Hi Steve,
>
> just tested - works like a charm. Thanks a ton :) The only 2 things left
> for me are
> 1) "[main] WARN : HHH000072: Duplicate joins for class" - I'm not really
> bothered with this one as it is a warning.
>

Like I mentioned earlier, I will look into the HHH000072 logging.  I had
seen that as I was getting ready for 5.0.0.Beta1 and planned to come back
and look into it.  Just have not had time yet.  A (simple!!) test case that
consistently reproduces it would help.



> 2) "TRACE: Ignoring persistent instance" - as I already mentioned there's
> a massive TRACE log (millions of lines) which started appearing once I
> excluded the logging
> Again, this is a minor issue, as I'm hoping the hibernate validator
> project will update the commons logging and this issue will be resolved.
>

That is the plan.



>
> Thanks again for your support :)
>

And to you.  Thanks for running it through its paces :)

From steve at hibernate.org  Mon Apr  6 19:08:18 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 6 Apr 2015 18:08:18 -0500
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CAFdSV9tV9=b6Og4UhdV7XsV6c4x7U49ivrC0PGGjkJbYktW4jQ@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
	<CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
	<CAFdSV9uL++E11n5zZtUM8WeEsT1Qb7TW4zFhZHbewMP2aNz8-g@mail.gmail.com>
	<CADGJaX91VTQSkHZRM-jr27ghAWZZc5kP0BfQAOo_MfGVTCh+oA@mail.gmail.com>
	<CADGJaX9=SPGqMJ1NnL5738pd9=TqzWi0oxTcfg_puP05Sh7=Rg@mail.gmail.com>
	<CAFdSV9tV9=b6Og4UhdV7XsV6c4x7U49ivrC0PGGjkJbYktW4jQ@mail.gmail.com>
Message-ID: <CAFdSV9uWW0FO_ZhUxJ19pmkTwo9gftwb9Gb0Z9Rtt_YSM7wQ=g@mail.gmail.com>

So if we get target to work on these XJC tasks and generate JAXB models
without required... does that hinder runtime binding at all in Java 7/8?

On Thu, Apr 2, 2015 at 9:50 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I just want the one that "works" :)
>
> On Thu, Apr 2, 2015 at 9:37 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> It also works with that task from JAXB Commons when updating the JAXB
>> Commons libs (and JAXB itself). That task has the "target" parameter in
>> newer versions. I can send you a PR for that update.
>>
>> 2015-04-02 16:08 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>>
>>> Had a quick look into (1).
>>>
>>> The "target" parameter is not supported by that version of the Ant task
>>> currently in use. If I change the class name of the Ant task from
>>> "org.jvnet.jaxb2_commons.xjc.XJC2Task" into "com.sun.tools.xjc.XJC2Task",
>>> the "target" parameter is recognized and setting it to "2.0" causes no
>>> required() attribute to be generated for @XmlElementRef.
>>>
>>> Do you remember why that task from JAXB Commons is used rather than the
>>> original XJC one?
>>>
>>> 2015-04-02 15:19 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> After considering this some more, I think moving to Java 8 as baseline
>>>> is
>>>> just not reasonable yet.  And tbh I just do not see a compelling reason
>>>> to
>>>> move to Java 7 as the baseline.  So if reasonably possible I would still
>>>> like to remain backwards compatible with Java 6.
>>>>
>>>> The only hurdle I believe is this JAXB point.  I see 2 options...
>>>>
>>>> 1) Make certain our code is compatible with JAXB 2.0.  I am not well
>>>> versed
>>>> enough in JAXB features between its versions yet to know how good of an
>>>> idea this is.
>>>>
>>>> 2) make our codr compatible with the newer JAXB version.  This works
>>>> as-is
>>>> in Java 7 and 8 runtimes.  For use in Java 6 runtimes, users would need
>>>> to
>>>> update the JAXB used in their JDK/JRE.  Doing so is a well defined
>>>> process
>>>> using endorsed libs.  See
>>>>
>>>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/index.html
>>>>
>>>> I think option (1) is the way to go, but do not have a lot of experience
>>>> here.  What do y'all think?
>>>> On Apr 1, 2015 6:34 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
>>>>
>>>> > Baseline on Java 8?  Hmm... Well thanks for tempting me :)
>>>> >
>>>> > What do you mean by "be able to experiment with significant API
>>>> > improvements"?
>>>> >
>>>> > On Tue, Mar 31, 2015 at 7:18 PM, Sanne Grinovero <sanne at hibernate.org
>>>> >
>>>> > wrote:
>>>> >
>>>> >> I wouldn't disagree on requiring Java 7.
>>>> >> I probably wouldn't disagree with Java 8 either, after all we're not
>>>> >> removing older versions of Hibernate from any download location and
>>>> >> we'll still support and maintain some older versions. It would
>>>> >> actually be nice to have the latest ORM version to be able to
>>>> >> experiment with significant API improvements.
>>>> >>
>>>> >> FYI Hibernate Search is requiring Java 7 already, and our CI servers
>>>> >> are already testing our projects with JDK9 as well.
>>>> >>
>>>> >> That said, Java 6 is still being supported by some vendors. Not by
>>>> >> Oracle, but Red Hat and SAP will support it for much longer.
>>>> >>
>>>> >> -- Sanne
>>>> >>
>>>> >> On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>> >> > So we now have to deal with a multi-jdk build in Hibernate ORM.
>>>> We need
>>>> >> > Java 8 in order to compile the new hibernate-java8 module.
>>>> >> >
>>>> >> > I wanted to remain compatible with Java 6 for the rest.  However,
>>>> I ran
>>>> >> > into a snag there because of JAXB which we now use (in conjunction
>>>> with
>>>> >> > StAX) to process XML in ORM.  ANyway, the JAX generation creates a
>>>> model
>>>> >> > that is only compatible with Java 7.  I have not yet had time to
>>>> >> > investigate this deeply.  But it has to do with a change in the
>>>> >> definition
>>>> >> > of javax.xml.bind.annotation.XmlElement and a change in its
>>>> definition
>>>> >> > between 1.6 and 1.7 to add a new
>>>> >> > attribute javax.xml.bind.annotation.XmlElement#required.
>>>> >> >
>>>> >> > If anyone is familiar with this situation, I'd love to hear some
>>>> options
>>>> >> > before I spend a lot of time investigating it.
>>>> >> >
>>>> >> > The other option is that we say we are going to drop Java 6 support
>>>> >> since
>>>> >> > it has been unsupported now for, what, 3 years?
>>>> >> > _______________________________________________
>>>> >> > 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
>>>>
>>>
>>>
>>
>

From gunnar at hibernate.org  Tue Apr  7 05:06:21 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 7 Apr 2015 11:06:21 +0200
Subject: [hibernate-dev] Java 6, 7 and 8... oh my!
In-Reply-To: <CAFdSV9uWW0FO_ZhUxJ19pmkTwo9gftwb9Gb0Z9Rtt_YSM7wQ=g@mail.gmail.com>
References: <CAFdSV9soZZvga5FYUrDUADnX8tUw6BzKeT4Tj8G1-fmbrNhG_w@mail.gmail.com>
	<CAFm4XO1KUTg6qqquu7o=FhKXPz4DfdJk4G9LAXf-KG8adBUuoQ@mail.gmail.com>
	<CAFdSV9vMb6SJYM5vqaCUozcHM51hS09OKTFeqm2aoVyyF0Bsyg@mail.gmail.com>
	<CAFdSV9uL++E11n5zZtUM8WeEsT1Qb7TW4zFhZHbewMP2aNz8-g@mail.gmail.com>
	<CADGJaX91VTQSkHZRM-jr27ghAWZZc5kP0BfQAOo_MfGVTCh+oA@mail.gmail.com>
	<CADGJaX9=SPGqMJ1NnL5738pd9=TqzWi0oxTcfg_puP05Sh7=Rg@mail.gmail.com>
	<CAFdSV9tV9=b6Og4UhdV7XsV6c4x7U49ivrC0PGGjkJbYktW4jQ@mail.gmail.com>
	<CAFdSV9uWW0FO_ZhUxJ19pmkTwo9gftwb9Gb0Z9Rtt_YSM7wQ=g@mail.gmail.com>
Message-ID: <CADGJaX9AWaB3RQamr-sia3L_9C8o4uG5trPnKR_t_aKeD9foTw@mail.gmail.com>

Binding on Java 7/8 at runtime should work just fine.

I've sent PR https://github.com/hibernate/hibernate-orm/pull/930 to update
XJC and configure the "target" parameter. I've built that branch with JDK 8
successfully, all tests pass.

I've also checked where the required() attribute actually is used within
JAXB (RI), and it only is referenced during schema generation (to generate
minOccurs=0 in derived schema documents if an element is not required) but
apparently not at runtime.


2015-04-07 1:08 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> So if we get target to work on these XJC tasks and generate JAXB models
> without required... does that hinder runtime binding at all in Java 7/8?
>
> On Thu, Apr 2, 2015 at 9:50 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I just want the one that "works" :)
>>
>> On Thu, Apr 2, 2015 at 9:37 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> It also works with that task from JAXB Commons when updating the JAXB
>>> Commons libs (and JAXB itself). That task has the "target" parameter in
>>> newer versions. I can send you a PR for that update.
>>>
>>> 2015-04-02 16:08 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>>>
>>>> Had a quick look into (1).
>>>>
>>>> The "target" parameter is not supported by that version of the Ant task
>>>> currently in use. If I change the class name of the Ant task from
>>>> "org.jvnet.jaxb2_commons.xjc.XJC2Task" into "com.sun.tools.xjc.XJC2Task",
>>>> the "target" parameter is recognized and setting it to "2.0" causes no
>>>> required() attribute to be generated for @XmlElementRef.
>>>>
>>>> Do you remember why that task from JAXB Commons is used rather than the
>>>> original XJC one?
>>>>
>>>> 2015-04-02 15:19 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> After considering this some more, I think moving to Java 8 as baseline
>>>>> is
>>>>> just not reasonable yet.  And tbh I just do not see a compelling
>>>>> reason to
>>>>> move to Java 7 as the baseline.  So if reasonably possible I would
>>>>> still
>>>>> like to remain backwards compatible with Java 6.
>>>>>
>>>>> The only hurdle I believe is this JAXB point.  I see 2 options...
>>>>>
>>>>> 1) Make certain our code is compatible with JAXB 2.0.  I am not well
>>>>> versed
>>>>> enough in JAXB features between its versions yet to know how good of an
>>>>> idea this is.
>>>>>
>>>>> 2) make our codr compatible with the newer JAXB version.  This works
>>>>> as-is
>>>>> in Java 7 and 8 runtimes.  For use in Java 6 runtimes, users would
>>>>> need to
>>>>> update the JAXB used in their JDK/JRE.  Doing so is a well defined
>>>>> process
>>>>> using endorsed libs.  See
>>>>>
>>>>> http://docs.oracle.com/javase/6/docs/technotes/guides/standards/index.html
>>>>>
>>>>> I think option (1) is the way to go, but do not have a lot of
>>>>> experience
>>>>> here.  What do y'all think?
>>>>> On Apr 1, 2015 6:34 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
>>>>>
>>>>> > Baseline on Java 8?  Hmm... Well thanks for tempting me :)
>>>>> >
>>>>> > What do you mean by "be able to experiment with significant API
>>>>> > improvements"?
>>>>> >
>>>>> > On Tue, Mar 31, 2015 at 7:18 PM, Sanne Grinovero <
>>>>> sanne at hibernate.org>
>>>>> > wrote:
>>>>> >
>>>>> >> I wouldn't disagree on requiring Java 7.
>>>>> >> I probably wouldn't disagree with Java 8 either, after all we're not
>>>>> >> removing older versions of Hibernate from any download location and
>>>>> >> we'll still support and maintain some older versions. It would
>>>>> >> actually be nice to have the latest ORM version to be able to
>>>>> >> experiment with significant API improvements.
>>>>> >>
>>>>> >> FYI Hibernate Search is requiring Java 7 already, and our CI servers
>>>>> >> are already testing our projects with JDK9 as well.
>>>>> >>
>>>>> >> That said, Java 6 is still being supported by some vendors. Not by
>>>>> >> Oracle, but Red Hat and SAP will support it for much longer.
>>>>> >>
>>>>> >> -- Sanne
>>>>> >>
>>>>> >> On 1 April 2015 at 01:04, Steve Ebersole <steve at hibernate.org>
>>>>> wrote:
>>>>> >> > So we now have to deal with a multi-jdk build in Hibernate ORM.
>>>>> We need
>>>>> >> > Java 8 in order to compile the new hibernate-java8 module.
>>>>> >> >
>>>>> >> > I wanted to remain compatible with Java 6 for the rest.  However,
>>>>> I ran
>>>>> >> > into a snag there because of JAXB which we now use (in
>>>>> conjunction with
>>>>> >> > StAX) to process XML in ORM.  ANyway, the JAX generation creates
>>>>> a model
>>>>> >> > that is only compatible with Java 7.  I have not yet had time to
>>>>> >> > investigate this deeply.  But it has to do with a change in the
>>>>> >> definition
>>>>> >> > of javax.xml.bind.annotation.XmlElement and a change in its
>>>>> definition
>>>>> >> > between 1.6 and 1.7 to add a new
>>>>> >> > attribute javax.xml.bind.annotation.XmlElement#required.
>>>>> >> >
>>>>> >> > If anyone is familiar with this situation, I'd love to hear some
>>>>> options
>>>>> >> > before I spend a lot of time investigating it.
>>>>> >> >
>>>>> >> > The other option is that we say we are going to drop Java 6
>>>>> support
>>>>> >> since
>>>>> >> > it has been unsupported now for, what, 3 years?
>>>>> >> > _______________________________________________
>>>>> >> > 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
>>>>>
>>>>
>>>>
>>>
>>
>

From steve at hibernate.org  Tue Apr  7 10:27:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 7 Apr 2015 09:27:00 -0500
Subject: [hibernate-dev] Transaction
In-Reply-To: <CAFdSV9sVQuNjxjUbTQDQcX_9mR=HSsjbiiEpvC+UQkUqxfefvQ@mail.gmail.com>
References: <CAFdSV9sE5k50n8=BWiXNG8Uy81Jf+6a7yJHpRH7SsTLeL0tOCA@mail.gmail.com>
	<CAFdSV9sVQuNjxjUbTQDQcX_9mR=HSsjbiiEpvC+UQkUqxfefvQ@mail.gmail.com>
Message-ID: <CAFdSV9uS77TsGT==_nutbHpgRrVk-Be92ofEUNUZn6a6Ypz1KA@mail.gmail.com>

Ok, not hearing any feedback on this so I will proceed as outlined here.

On Wed, Mar 25, 2015 at 3:15 PM, Steve Ebersole <steve at hibernate.org> wrote:

> We also identified needs for Status#ROLLING_BACK and Status#COMMITTING, so
> consider those in the enum as well.
>
> On Wed, Mar 25, 2015 at 12:19 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I thought I had asked this before, but maybe not.  Andrea and I are
>> working through the transaction/jdbc changes and I really would like to
>> clean up the org.hibernate.Transaction API.  But before I start cutting I
>> wanted to make sure noone is using the methods I plan on getting rid of...
>>
>> Here is the new proposed contract:
>>
>> public interface Transsaction {
>>     public void begin();
>>     public void commit();
>>     public void rollback();
>>     public void markRollbackOnly();
>>
>>     public Status getStatus();
>>
>>     public int getTimeout();
>>     public void setTimeout(int seconds);
>>
>>     public void registerSynchronization(Synchronization synchronization);
>> }
>>
>> public enum Status {
>>   NOT_ACTIVE,
>>   ACTIVE,
>>   COMMITTED,
>>   ROLLED_BACK,
>>     FAILED_COMMIT
>> }
>>
>> Notes:
>> 1) isInitiator() has been removed with no real replacement.  I could not
>> really see when that would be useful.
>> 2) isParticipating() has been removed with no real replacement.
>> 2) isActive(), wasCommitted() and wasRolledBack has all been removed with
>> call to getStatus() as replacement
>> 3) getLocalStatus() is gone.  Who cares :)  If users are asking us this,
>> we really should be checking the REAL state of the transaction
>> 4) Transaction is now a single impl.  The distinctions are all handled
>> internally.  TransactionImplementor is gone too.
>>
>> Thoughts?  Concerns?
>>
>
>

From gunnar at hibernate.org  Tue Apr  7 11:17:37 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 7 Apr 2015 17:17:37 +0200
Subject: [hibernate-dev] Transaction
In-Reply-To: <CAFdSV9uS77TsGT==_nutbHpgRrVk-Be92ofEUNUZn6a6Ypz1KA@mail.gmail.com>
References: <CAFdSV9sE5k50n8=BWiXNG8Uy81Jf+6a7yJHpRH7SsTLeL0tOCA@mail.gmail.com>
	<CAFdSV9sVQuNjxjUbTQDQcX_9mR=HSsjbiiEpvC+UQkUqxfefvQ@mail.gmail.com>
	<CAFdSV9uS77TsGT==_nutbHpgRrVk-Be92ofEUNUZn6a6Ypz1KA@mail.gmail.com>
Message-ID: <CADGJaX-BqSuC8ahckbusQJP5R2VFbRdUHgaZigMv_F=OLNLcgw@mail.gmail.com>

> 4) Transaction is now a single impl.  The distinctions are all handled
internally.  TransactionImplementor is gone too

Can OGM still register a custom TransactionFactory? We'd need that in order
to return our "NoSQL-local" transaction implementation.



2015-04-07 16:27 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Ok, not hearing any feedback on this so I will proceed as outlined here.
>
> On Wed, Mar 25, 2015 at 3:15 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > We also identified needs for Status#ROLLING_BACK and Status#COMMITTING,
> so
> > consider those in the enum as well.
> >
> > On Wed, Mar 25, 2015 at 12:19 PM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> I thought I had asked this before, but maybe not.  Andrea and I are
> >> working through the transaction/jdbc changes and I really would like to
> >> clean up the org.hibernate.Transaction API.  But before I start cutting
> I
> >> wanted to make sure noone is using the methods I plan on getting rid
> of...
> >>
> >> Here is the new proposed contract:
> >>
> >> public interface Transsaction {
> >>     public void begin();
> >>     public void commit();
> >>     public void rollback();
> >>     public void markRollbackOnly();
> >>
> >>     public Status getStatus();
> >>
> >>     public int getTimeout();
> >>     public void setTimeout(int seconds);
> >>
> >>     public void registerSynchronization(Synchronization
> synchronization);
> >> }
> >>
> >> public enum Status {
> >>   NOT_ACTIVE,
> >>   ACTIVE,
> >>   COMMITTED,
> >>   ROLLED_BACK,
> >>     FAILED_COMMIT
> >> }
> >>
> >> Notes:
> >> 1) isInitiator() has been removed with no real replacement.  I could not
> >> really see when that would be useful.
> >> 2) isParticipating() has been removed with no real replacement.
> >> 2) isActive(), wasCommitted() and wasRolledBack has all been removed
> with
> >> call to getStatus() as replacement
> >> 3) getLocalStatus() is gone.  Who cares :)  If users are asking us this,
> >> we really should be checking the REAL state of the transaction
> >> 4) Transaction is now a single impl.  The distinctions are all handled
> >> internally.  TransactionImplementor is gone too.
> >>
> >> Thoughts?  Concerns?
> >>
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Apr  7 13:32:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 7 Apr 2015 12:32:09 -0500
Subject: [hibernate-dev] Transaction
In-Reply-To: <CADGJaX-BqSuC8ahckbusQJP5R2VFbRdUHgaZigMv_F=OLNLcgw@mail.gmail.com>
References: <CAFdSV9sE5k50n8=BWiXNG8Uy81Jf+6a7yJHpRH7SsTLeL0tOCA@mail.gmail.com>
	<CAFdSV9sVQuNjxjUbTQDQcX_9mR=HSsjbiiEpvC+UQkUqxfefvQ@mail.gmail.com>
	<CAFdSV9uS77TsGT==_nutbHpgRrVk-Be92ofEUNUZn6a6Ypz1KA@mail.gmail.com>
	<CADGJaX-BqSuC8ahckbusQJP5R2VFbRdUHgaZigMv_F=OLNLcgw@mail.gmail.com>
Message-ID: <CAFdSV9s+cavAoAuiW6TPnN24CjzB0EwMYZAvrVpFurNe=ySDvA@mail.gmail.com>

There will be a different way to do that...
On Apr 7, 2015 10:17 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> > 4) Transaction is now a single impl.  The distinctions are all handled
> internally.  TransactionImplementor is gone too
>
> Can OGM still register a custom TransactionFactory? We'd need that in
> order to return our "NoSQL-local" transaction implementation.
>
>
>
> 2015-04-07 16:27 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Ok, not hearing any feedback on this so I will proceed as outlined here.
>>
>> On Wed, Mar 25, 2015 at 3:15 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > We also identified needs for Status#ROLLING_BACK and Status#COMMITTING,
>> so
>> > consider those in the enum as well.
>> >
>> > On Wed, Mar 25, 2015 at 12:19 PM, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >
>> >> I thought I had asked this before, but maybe not.  Andrea and I are
>> >> working through the transaction/jdbc changes and I really would like to
>> >> clean up the org.hibernate.Transaction API.  But before I start
>> cutting I
>> >> wanted to make sure noone is using the methods I plan on getting rid
>> of...
>> >>
>> >> Here is the new proposed contract:
>> >>
>> >> public interface Transsaction {
>> >>     public void begin();
>> >>     public void commit();
>> >>     public void rollback();
>> >>     public void markRollbackOnly();
>> >>
>> >>     public Status getStatus();
>> >>
>> >>     public int getTimeout();
>> >>     public void setTimeout(int seconds);
>> >>
>> >>     public void registerSynchronization(Synchronization
>> synchronization);
>> >> }
>> >>
>> >> public enum Status {
>> >>   NOT_ACTIVE,
>> >>   ACTIVE,
>> >>   COMMITTED,
>> >>   ROLLED_BACK,
>> >>     FAILED_COMMIT
>> >> }
>> >>
>> >> Notes:
>> >> 1) isInitiator() has been removed with no real replacement.  I could
>> not
>> >> really see when that would be useful.
>> >> 2) isParticipating() has been removed with no real replacement.
>> >> 2) isActive(), wasCommitted() and wasRolledBack has all been removed
>> with
>> >> call to getStatus() as replacement
>> >> 3) getLocalStatus() is gone.  Who cares :)  If users are asking us
>> this,
>> >> we really should be checking the REAL state of the transaction
>> >> 4) Transaction is now a single impl.  The distinctions are all handled
>> >> internally.  TransactionImplementor is gone too.
>> >>
>> >> Thoughts?  Concerns?
>> >>
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From johara at redhat.com  Tue Apr  7 14:59:16 2015
From: johara at redhat.com (John O'Hara)
Date: Tue, 07 Apr 2015 19:59:16 +0100
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>
References: <551D0F9E.1000801@redhat.com>
	<CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>
Message-ID: <55242904.8040306@redhat.com>

Steve,

I have made changes based on the github comments and your comments below 
(https://github.com/johnaoahra80/hibernate-orm/commits/HHH-9701).

Do you want me to squash the commits down to one? Not sure how this 
would effect the comments you have already made on GH

Thanks

John

On 06/04/15 04:51, Steve Ebersole wrote:
>
>
> On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara <johara at redhat.com 
> <mailto:johara at redhat.com>> wrote:
>
>     Steve,
>
>     I have pushed a proposal for HHH-9701 to:
>     https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>
>     There are a couple of areas that I would appreciate feedback;
>
>     1) Serialization/Deserialization - EntityEntries implementations
>     can be serialized and each implementation provide their own
>     serialization method. I have modified the serialization of
>     EntityEntry in EntityEntryContext to write the Implementation
>     class to the OutputStream so the correct class can be used to
>     deserialize the object stream.  Is the exception handling
>     sufficient here, or do we need more robust handling of
>     deserialization exceptions? : see
>     https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>
>
> I added some comments to that section.  Also, overall I would extract 
> the deserialization bit into a separate method (deserializeEntityEntry).
>
>
>     2) In our (perf team) use case, we want to be able to share the
>     ImmutableEntityEntry between sessions when they are referenced
>     cached in the 2lc. I have modified EntityEntryContext to not null
>     managedEntity.$$_hibernate_setEntityEntry if the EntityEntry is an
>     instance of ImmutableEntityEntry.  Do we need to add an extra
>     checks here, to ensure that the entity is Reference Cached? I am
>     not sure how we would test that case? : see
>     https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>
>
> It really depends on what y'all consider the trigger for using 
> ImmutableEntityEntry.  When would the EntityPersister use the 
> EntityEntryFactory producing ImmutableEntityEntry instances?
> a) when the entity is marked immutable?
> b) when the entity is marked immutable *and* we need to cache it by 
> reference?
> c) some other condition?
>
> I agree that we should only not clear that reference when the entity 
> is enabled for cache-by-reference.  How that plays into this depends 
> on the answer to the above question.
>
> If (a), then I think that yes it makes sense to add a check to only 
> clear the ManagedEntity's EntityEntry reference if using 
> cache-by-reference.
>
> If (b), then the EntiytPersister is only using the EntityEntryFactory 
> producing ImmutableEntityEntry instances when both are true.  So the 
> fact that an entry is an instance of ImmutableEntityEntry indicates 
> that we need to not clear it from the ManagedEntity.
>
>
>
>     3) Lock Mode: Steve you mentioned about not doing locking for
>     Immutable entities. Where is the locking implemented? Would it be
>     sufficient to simply set the LockMode on the ImmutableEntityEntry
>     to NONE/READ_ONLY when setLockMode is called?
>
>
>
> Locking is implemented in many places.
>
> What I had in mind, in terms of implementation for EntityEntry, is 
> somewhat influenced by the choice between ignore versus exception in 
> cases where something is not supported.  Basically I had thought to 
> throw an exception in ImmutableEntityEntry#setLockMode or to simply 
> ignore the call altogether.  This is not a great solution.
>
> It is hard for me to justify ignoring the lock request in all cases.  
> What does everyone else think?
>
>
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From steve at hibernate.org  Tue Apr  7 15:02:05 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 7 Apr 2015 14:02:05 -0500
Subject: [hibernate-dev] ORM 5.0 and IntelliJ
Message-ID: <CAFdSV9tiUwiDDHTVNSgbok3u1tUTxCu6x2mej55j0wG8rURJyg@mail.gmail.com>

Another change with master is that IntelliJ import finally works as far as
properly setting up excludes in IntelliJ to not "hide" generated-src.  The
fact that generated-src is under the $buildDir makes this more complicated
than it need to be, but it works.

There is currently a minor issue with IntelliJ import in ORM master that I
have not yet investigated.  It has to do with attempting to set different
"jdkName" for the hibernate-java8 module.  I reported an issue with
IntelliJ, but then it seems to work from my standalone gradle-mixed-jdk
project[1]

Anyway, just a heads up..

[1] - https://github.com/sebersole/gradle-mixed-jdk

From steve at hibernate.org  Tue Apr  7 15:20:49 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 7 Apr 2015 14:20:49 -0500
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <55242904.8040306@redhat.com>
References: <551D0F9E.1000801@redhat.com>
	<CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>
	<55242904.8040306@redhat.com>
Message-ID: <CAFdSV9uHpKY_8WbJwLf7cMx75qwyZnK=j_OPJMQ_tFATMwKg=A@mail.gmail.com>

TBH, I have no idea what happens to comments on a Pull Request when you
squash and force push.

I'd just leave the multiple commits.  We can squash them later.

On Tue, Apr 7, 2015 at 1:59 PM, John O'Hara <johara at redhat.com> wrote:

>  Steve,
>
> I have made changes based on the github comments and your comments below (
> https://github.com/johnaoahra80/hibernate-orm/commits/HHH-9701).
>
> Do you want me to squash the commits down to one? Not sure how this would
> effect the comments you have already made on GH
>
> Thanks
>
> John
>
>
> On 06/04/15 04:51, Steve Ebersole wrote:
>
>
>
> On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara <johara at redhat.com> wrote:
>
>>  Steve,
>>
>> I have pushed a proposal for HHH-9701 to:
>> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>
>> There are a couple of areas that I would appreciate feedback;
>>
>> 1) Serialization/Deserialization - EntityEntries implementations can be
>> serialized and each implementation provide their own serialization method.
>> I have modified the serialization of EntityEntry in EntityEntryContext to
>> write the Implementation class to the OutputStream so the correct class can
>> be used to deserialize the object stream.  Is the exception handling
>> sufficient here, or do we need more robust handling of deserialization
>> exceptions? : see
>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>>
>
>  I added some comments to that section.  Also, overall I would extract
> the deserialization bit into a separate method (deserializeEntityEntry).
>
>
>
>  2) In our (perf team) use case, we want to be able to share the
>> ImmutableEntityEntry between sessions when they are referenced cached in
>> the 2lc. I have modified EntityEntryContext to not null
>> managedEntity.$$_hibernate_setEntityEntry if the EntityEntry is an instance
>> of ImmutableEntityEntry.  Do we need to add an extra checks here, to ensure
>> that the entity is Reference Cached? I am not sure how we would test that
>> case? : see
>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>>
>
>  It really depends on what y'all consider the trigger for using
> ImmutableEntityEntry.  When would the EntityPersister use the
> EntityEntryFactory producing ImmutableEntityEntry instances?
> a) when the entity is marked immutable?
> b) when the entity is marked immutable *and* we need to cache it by
> reference?
> c) some other condition?
>
>  I agree that we should only not clear that reference when the entity is
> enabled for cache-by-reference.  How that plays into this depends on the
> answer to the above question.
>
>  If (a), then I think that yes it makes sense to add a check to only
> clear the ManagedEntity's EntityEntry reference if using cache-by-reference.
>
>  If (b), then the EntiytPersister is only using the EntityEntryFactory
> producing ImmutableEntityEntry instances when both are true.  So the fact
> that an entry is an instance of ImmutableEntityEntry indicates that we need
> to not clear it from the ManagedEntity.
>
>
>
>
>> 3) Lock Mode: Steve you mentioned about not doing locking for Immutable
>> entities. Where is the locking implemented? Would it be sufficient to
>> simply set the LockMode on the ImmutableEntityEntry to NONE/READ_ONLY when
>> setLockMode is called?
>>
>
>
>  Locking is implemented in many places.
>
>  What I had in mind, in terms of implementation for EntityEntry, is
> somewhat influenced by the choice between ignore versus exception in cases
> where something is not supported.  Basically I had thought to throw an
> exception in ImmutableEntityEntry#setLockMode or to simply ignore the call
> altogether.  This is not a great solution.
>
>  It is hard for me to justify ignoring the lock request in all cases.
> What does everyone else think?
>
>
>
>
>
> --
> John O'Harajohara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>
>
>

From gunnar at hibernate.org  Wed Apr  8 10:50:23 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 8 Apr 2015 16:50:23 +0200
Subject: [hibernate-dev] SEO ranking of ORM docs
Message-ID: <CADGJaX9EKfJeU3xXoJ3ijX14cN+6VuxhBKZJ3fzKnn5uq0W=Eg@mail.gmail.com>

Hi,

When searching the web for things around Hibernate ORM, I often find 3.x
documents as the top result. E.g. searching for "hibernate inheritance" on
Google returns
https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/inheritance.html
as the first result.

Instead it would be nice to see
https://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html/ch10.html there
(or some other up-to-date docs containing the relevant information), i.e.
docs from the latest stable release.

I have no idea really what would have to be done to achieve that. But maybe
someone else knows the right knobs to turn?

Cheers,

--Gunnar

From steve at hibernate.org  Wed Apr  8 23:13:24 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 8 Apr 2015 22:13:24 -0500
Subject: [hibernate-dev] javac -source and -target
Message-ID: <CAFdSV9tiVV_UYURdFrH9j0oYV+gBMXBtMFRnxpzOaNSZrO6Sow@mail.gmail.com>

Is there ever a time *in out projects* where we would want the -source and
-target to name different versions?

I think generally speaking I cannot see a practical reason for this, and we
don't allow that anyway today (in ORM anyway).

From johara at redhat.com  Fri Apr 10 10:26:41 2015
From: johara at redhat.com (John O'Hara)
Date: Fri, 10 Apr 2015 15:26:41 +0100
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <CAFdSV9uHpKY_8WbJwLf7cMx75qwyZnK=j_OPJMQ_tFATMwKg=A@mail.gmail.com>
References: <551D0F9E.1000801@redhat.com>	<CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>	<55242904.8040306@redhat.com>
	<CAFdSV9uHpKY_8WbJwLf7cMx75qwyZnK=j_OPJMQ_tFATMwKg=A@mail.gmail.com>
Message-ID: <5527DDA1.6000903@redhat.com>

I have updated my current branch: 
https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701

  * Extracted the deserialization of EntityEntry in EntityEntryContext
    into a separate method:
    https://github.com/johnaoahra80/hibernate-orm/commit/d9f5dc76e05a111d37dbdac64c6aa1bd485a1ba9
  * Created a LockModeException for invalid lock modes for an
    ImmutableEntity:
    https://github.com/johnaoahra80/hibernate-orm/commit/99e308ae267f9bfc30547784087955d7dc1e73e0

Do we need a new Exception type here, or could we just use a 
HibernateException with a message about invalid lock type?

  * Added a check when EntityEntryContext.clear() or EntityEntry.
    removeEntityEntry() is called to see if the EntityEntry is
    ImmutableEntityEntry AND the Entity is referenced cached in the 2lc:
    https://github.com/johnaoahra80/hibernate-orm/commit/310a2eb5b8988189806a2e688090a7ea16ae5474

Not sure of the performance implications on this, I am planning a run on 
WF9 to test and regressions in our use case.

  * Extracted an AbstractEntityEntry superclass that MutableEntityEntry
    and ImmutableEntityEntry both inherit from:
    https://github.com/johnaoahra80/hibernate-orm/commit/df50d344441ed4cc8f3c3c8df90edc106dd52adb

John



On 07/04/15 20:20, Steve Ebersole wrote:
> TBH, I have no idea what happens to comments on a Pull Request when 
> you squash and force push.
>
> I'd just leave the multiple commits.  We can squash them later.
>
> On Tue, Apr 7, 2015 at 1:59 PM, John O'Hara <johara at redhat.com 
> <mailto:johara at redhat.com>> wrote:
>
>     Steve,
>
>     I have made changes based on the github comments and your comments
>     below
>     (https://github.com/johnaoahra80/hibernate-orm/commits/HHH-9701).
>
>     Do you want me to squash the commits down to one? Not sure how
>     this would effect the comments you have already made on GH
>
>     Thanks
>
>     John
>
>
>     On 06/04/15 04:51, Steve Ebersole wrote:
>>
>>
>>     On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara <johara at redhat.com
>>     <mailto:johara at redhat.com>> wrote:
>>
>>         Steve,
>>
>>         I have pushed a proposal for HHH-9701 to:
>>         https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>
>>         There are a couple of areas that I would appreciate feedback;
>>
>>         1) Serialization/Deserialization - EntityEntries
>>         implementations can be serialized and each implementation
>>         provide their own serialization method. I have modified the
>>         serialization of EntityEntry in EntityEntryContext to write
>>         the Implementation class to the OutputStream so the correct
>>         class can be used to deserialize the object stream.  Is the
>>         exception handling sufficient here, or do we need more robust
>>         handling of deserialization exceptions? : see
>>         https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>>
>>
>>     I added some comments to that section. Also, overall I would
>>     extract the deserialization bit into a separate method
>>     (deserializeEntityEntry).
>>
>>
>>         2) In our (perf team) use case, we want to be able to share
>>         the  ImmutableEntityEntry between sessions when they are
>>         referenced cached in the 2lc. I have modified
>>         EntityEntryContext to not null
>>         managedEntity.$$_hibernate_setEntityEntry if the EntityEntry
>>         is an instance of ImmutableEntityEntry.  Do we need to add an
>>         extra checks here, to ensure that the entity is Reference
>>         Cached? I am not sure how we would test that case? : see
>>         https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>>
>>
>>     It really depends on what y'all consider the trigger for using
>>     ImmutableEntityEntry. When would the EntityPersister use the
>>     EntityEntryFactory producing ImmutableEntityEntry instances?
>>     a) when the entity is marked immutable?
>>     b) when the entity is marked immutable *and* we need to cache it
>>     by reference?
>>     c) some other condition?
>>
>>     I agree that we should only not clear that reference when the
>>     entity is enabled for cache-by-reference.  How that plays into
>>     this depends on the answer to the above question.
>>
>>     If (a), then I think that yes it makes sense to add a check to
>>     only clear the ManagedEntity's EntityEntry reference if using
>>     cache-by-reference.
>>
>>     If (b), then the EntiytPersister is only using the
>>     EntityEntryFactory producing ImmutableEntityEntry instances when
>>     both are true.  So the fact that an entry is an instance of
>>     ImmutableEntityEntry indicates that we need to not clear it from
>>     the ManagedEntity.
>>
>>
>>
>>         3) Lock Mode: Steve you mentioned about not doing locking for
>>         Immutable entities. Where is the locking implemented? Would
>>         it be sufficient to simply set the LockMode on the
>>         ImmutableEntityEntry to NONE/READ_ONLY when setLockMode is
>>         called?
>>
>>
>>
>>     Locking is implemented in many places.
>>
>>     What I had in mind, in terms of implementation for EntityEntry,
>>     is somewhat influenced by the choice between ignore versus
>>     exception in cases where something is not supported.  Basically I
>>     had thought to throw an exception in
>>     ImmutableEntityEntry#setLockMode or to simply ignore the call
>>     altogether.  This is not a great solution.
>>
>>     It is hard for me to justify ignoring the lock request in all
>>     cases.  What does everyone else think?
>>
>>
>>
>
>
>     -- 
>     John O'Hara
>     johara at redhat.com  <mailto:johara at redhat.com>
>
>     JBoss, by Red Hat
>     Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>     Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From steve at hibernate.org  Fri Apr 10 12:45:24 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 10 Apr 2015 11:45:24 -0500
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <5527DDA1.6000903@redhat.com>
References: <551D0F9E.1000801@redhat.com>
	<CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>
	<55242904.8040306@redhat.com>
	<CAFdSV9uHpKY_8WbJwLf7cMx75qwyZnK=j_OPJMQ_tFATMwKg=A@mail.gmail.com>
	<5527DDA1.6000903@redhat.com>
Message-ID: <CAFdSV9vyXauzh+9bVEa1kqz5uRq_+s1+R4en+WmqYnKmEEa0Mw@mail.gmail.com>

Well the performance is exactly what I had in mind when I asked you about
the exact "trigger for using ImmutableEntityEntry" in your use-case.  But
you never replied to that.



On Fri, Apr 10, 2015 at 9:26 AM, John O'Hara <johara at redhat.com> wrote:

>  I have updated my current branch:
> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>
>    - Extracted the deserialization of EntityEntry in EntityEntryContext
>    into a separate method:
>    https://github.com/johnaoahra80/hibernate-orm/commit/d9f5dc76e05a111d37dbdac64c6aa1bd485a1ba9
>    - Created a LockModeException for invalid lock modes for an
>    ImmutableEntity:
>    https://github.com/johnaoahra80/hibernate-orm/commit/99e308ae267f9bfc30547784087955d7dc1e73e0
>
> Do we need a new Exception type here, or could we just use a
> HibernateException with a message about invalid lock type?
>
>    - Added a check when EntityEntryContext.clear() or EntityEntry.
>    removeEntityEntry() is called to see if the EntityEntry is
>    ImmutableEntityEntry AND the Entity is referenced cached in the 2lc:
>    https://github.com/johnaoahra80/hibernate-orm/commit/310a2eb5b8988189806a2e688090a7ea16ae5474
>
> Not sure of the performance implications on this, I am planning a run on
> WF9 to test and regressions in our use case.
>
>    - Extracted an AbstractEntityEntry superclass that MutableEntityEntry
>    and ImmutableEntityEntry both inherit from:
>    https://github.com/johnaoahra80/hibernate-orm/commit/df50d344441ed4cc8f3c3c8df90edc106dd52adb
>
> John
>
>
>
>
> On 07/04/15 20:20, Steve Ebersole wrote:
>
> TBH, I have no idea what happens to comments on a Pull Request when you
> squash and force push.
>
>  I'd just leave the multiple commits.  We can squash them later.
>
> On Tue, Apr 7, 2015 at 1:59 PM, John O'Hara <johara at redhat.com> wrote:
>
>>  Steve,
>>
>> I have made changes based on the github comments and your comments below (
>> https://github.com/johnaoahra80/hibernate-orm/commits/HHH-9701).
>>
>> Do you want me to squash the commits down to one? Not sure how this would
>> effect the comments you have already made on GH
>>
>> Thanks
>>
>> John
>>
>>
>> On 06/04/15 04:51, Steve Ebersole wrote:
>>
>>
>>
>> On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara <johara at redhat.com> wrote:
>>
>>>  Steve,
>>>
>>> I have pushed a proposal for HHH-9701 to:
>>> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>>
>>> There are a couple of areas that I would appreciate feedback;
>>>
>>> 1) Serialization/Deserialization - EntityEntries implementations can be
>>> serialized and each implementation provide their own serialization method.
>>> I have modified the serialization of EntityEntry in EntityEntryContext to
>>> write the Implementation class to the OutputStream so the correct class can
>>> be used to deserialize the object stream.  Is the exception handling
>>> sufficient here, or do we need more robust handling of deserialization
>>> exceptions? : see
>>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>>>
>>
>>  I added some comments to that section.  Also, overall I would extract
>> the deserialization bit into a separate method (deserializeEntityEntry).
>>
>>
>>
>>  2) In our (perf team) use case, we want to be able to share the
>>> ImmutableEntityEntry between sessions when they are referenced cached in
>>> the 2lc. I have modified EntityEntryContext to not null
>>> managedEntity.$$_hibernate_setEntityEntry if the EntityEntry is an instance
>>> of ImmutableEntityEntry.  Do we need to add an extra checks here, to ensure
>>> that the entity is Reference Cached? I am not sure how we would test that
>>> case? : see
>>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>>>
>>
>>  It really depends on what y'all consider the trigger for using
>> ImmutableEntityEntry.  When would the EntityPersister use the
>> EntityEntryFactory producing ImmutableEntityEntry instances?
>> a) when the entity is marked immutable?
>> b) when the entity is marked immutable *and* we need to cache it by
>> reference?
>> c) some other condition?
>>
>>  I agree that we should only not clear that reference when the entity is
>> enabled for cache-by-reference.  How that plays into this depends on the
>> answer to the above question.
>>
>>  If (a), then I think that yes it makes sense to add a check to only
>> clear the ManagedEntity's EntityEntry reference if using cache-by-reference.
>>
>>  If (b), then the EntiytPersister is only using the EntityEntryFactory
>> producing ImmutableEntityEntry instances when both are true.  So the fact
>> that an entry is an instance of ImmutableEntityEntry indicates that we need
>> to not clear it from the ManagedEntity.
>>
>>
>>
>>
>>> 3) Lock Mode: Steve you mentioned about not doing locking for Immutable
>>> entities. Where is the locking implemented? Would it be sufficient to
>>> simply set the LockMode on the ImmutableEntityEntry to NONE/READ_ONLY when
>>> setLockMode is called?
>>>
>>
>>
>>  Locking is implemented in many places.
>>
>>  What I had in mind, in terms of implementation for EntityEntry, is
>> somewhat influenced by the choice between ignore versus exception in cases
>> where something is not supported.  Basically I had thought to throw an
>> exception in ImmutableEntityEntry#setLockMode or to simply ignore the call
>> altogether.  This is not a great solution.
>>
>>  It is hard for me to justify ignoring the lock request in all cases.
>> What does everyone else think?
>>
>>
>>
>>
>>
>>   --
>> John O'Harajohara at redhat.com
>>
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>
>>
>>
>
>
> --
> John O'Harajohara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>
>
>

From steve at hibernate.org  Fri Apr 10 12:46:21 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 10 Apr 2015 11:46:21 -0500
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <CAFdSV9vyXauzh+9bVEa1kqz5uRq_+s1+R4en+WmqYnKmEEa0Mw@mail.gmail.com>
References: <551D0F9E.1000801@redhat.com>
	<CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>
	<55242904.8040306@redhat.com>
	<CAFdSV9uHpKY_8WbJwLf7cMx75qwyZnK=j_OPJMQ_tFATMwKg=A@mail.gmail.com>
	<5527DDA1.6000903@redhat.com>
	<CAFdSV9vyXauzh+9bVEa1kqz5uRq_+s1+R4en+WmqYnKmEEa0Mw@mail.gmail.com>
Message-ID: <CAFdSV9uq4A54F2gsxGT8UurqPTcfJZ6sCN5VDdNXERGZtDjLPg@mail.gmail.com>

To post my question again...

It really depends on what y'all consider the trigger for using
ImmutableEntityEntry.  When would the EntityPersister use the
EntityEntryFactory producing ImmutableEntityEntry instances?
a) when the entity is marked immutable?
b) when the entity is marked immutable *and* we need to cache it by
reference?
c) some other condition?

Because the answer to this ^^ dictates how we need to check whether we can
clear this reference


On Fri, Apr 10, 2015 at 11:45 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> Well the performance is exactly what I had in mind when I asked you about
> the exact "trigger for using ImmutableEntityEntry" in your use-case.  But
> you never replied to that.
>
>
>
> On Fri, Apr 10, 2015 at 9:26 AM, John O'Hara <johara at redhat.com> wrote:
>
>>  I have updated my current branch:
>> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>
>>    - Extracted the deserialization of EntityEntry in EntityEntryContext
>>    into a separate method:
>>    https://github.com/johnaoahra80/hibernate-orm/commit/d9f5dc76e05a111d37dbdac64c6aa1bd485a1ba9
>>    - Created a LockModeException for invalid lock modes for an
>>    ImmutableEntity:
>>    https://github.com/johnaoahra80/hibernate-orm/commit/99e308ae267f9bfc30547784087955d7dc1e73e0
>>
>> Do we need a new Exception type here, or could we just use a
>> HibernateException with a message about invalid lock type?
>>
>>    - Added a check when EntityEntryContext.clear() or EntityEntry.
>>    removeEntityEntry() is called to see if the EntityEntry is
>>    ImmutableEntityEntry AND the Entity is referenced cached in the 2lc:
>>    https://github.com/johnaoahra80/hibernate-orm/commit/310a2eb5b8988189806a2e688090a7ea16ae5474
>>
>> Not sure of the performance implications on this, I am planning a run on
>> WF9 to test and regressions in our use case.
>>
>>    - Extracted an AbstractEntityEntry superclass that MutableEntityEntry
>>    and ImmutableEntityEntry both inherit from:
>>    https://github.com/johnaoahra80/hibernate-orm/commit/df50d344441ed4cc8f3c3c8df90edc106dd52adb
>>
>> John
>>
>>
>>
>>
>> On 07/04/15 20:20, Steve Ebersole wrote:
>>
>> TBH, I have no idea what happens to comments on a Pull Request when you
>> squash and force push.
>>
>>  I'd just leave the multiple commits.  We can squash them later.
>>
>> On Tue, Apr 7, 2015 at 1:59 PM, John O'Hara <johara at redhat.com> wrote:
>>
>>>  Steve,
>>>
>>> I have made changes based on the github comments and your comments below
>>> (https://github.com/johnaoahra80/hibernate-orm/commits/HHH-9701).
>>>
>>> Do you want me to squash the commits down to one? Not sure how this
>>> would effect the comments you have already made on GH
>>>
>>> Thanks
>>>
>>> John
>>>
>>>
>>> On 06/04/15 04:51, Steve Ebersole wrote:
>>>
>>>
>>>
>>> On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara <johara at redhat.com> wrote:
>>>
>>>>  Steve,
>>>>
>>>> I have pushed a proposal for HHH-9701 to:
>>>> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>>>
>>>> There are a couple of areas that I would appreciate feedback;
>>>>
>>>> 1) Serialization/Deserialization - EntityEntries implementations can be
>>>> serialized and each implementation provide their own serialization method.
>>>> I have modified the serialization of EntityEntry in EntityEntryContext to
>>>> write the Implementation class to the OutputStream so the correct class can
>>>> be used to deserialize the object stream.  Is the exception handling
>>>> sufficient here, or do we need more robust handling of deserialization
>>>> exceptions? : see
>>>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>>>>
>>>
>>>  I added some comments to that section.  Also, overall I would extract
>>> the deserialization bit into a separate method (deserializeEntityEntry).
>>>
>>>
>>>
>>>  2) In our (perf team) use case, we want to be able to share the
>>>> ImmutableEntityEntry between sessions when they are referenced cached in
>>>> the 2lc. I have modified EntityEntryContext to not null
>>>> managedEntity.$$_hibernate_setEntityEntry if the EntityEntry is an instance
>>>> of ImmutableEntityEntry.  Do we need to add an extra checks here, to ensure
>>>> that the entity is Reference Cached? I am not sure how we would test that
>>>> case? : see
>>>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>>>>
>>>
>>>  It really depends on what y'all consider the trigger for using
>>> ImmutableEntityEntry.  When would the EntityPersister use the
>>> EntityEntryFactory producing ImmutableEntityEntry instances?
>>> a) when the entity is marked immutable?
>>> b) when the entity is marked immutable *and* we need to cache it by
>>> reference?
>>> c) some other condition?
>>>
>>>  I agree that we should only not clear that reference when the entity
>>> is enabled for cache-by-reference.  How that plays into this depends on the
>>> answer to the above question.
>>>
>>>  If (a), then I think that yes it makes sense to add a check to only
>>> clear the ManagedEntity's EntityEntry reference if using cache-by-reference.
>>>
>>>  If (b), then the EntiytPersister is only using the EntityEntryFactory
>>> producing ImmutableEntityEntry instances when both are true.  So the fact
>>> that an entry is an instance of ImmutableEntityEntry indicates that we need
>>> to not clear it from the ManagedEntity.
>>>
>>>
>>>
>>>
>>>> 3) Lock Mode: Steve you mentioned about not doing locking for Immutable
>>>> entities. Where is the locking implemented? Would it be sufficient to
>>>> simply set the LockMode on the ImmutableEntityEntry to NONE/READ_ONLY when
>>>> setLockMode is called?
>>>>
>>>
>>>
>>>  Locking is implemented in many places.
>>>
>>>  What I had in mind, in terms of implementation for EntityEntry, is
>>> somewhat influenced by the choice between ignore versus exception in cases
>>> where something is not supported.  Basically I had thought to throw an
>>> exception in ImmutableEntityEntry#setLockMode or to simply ignore the call
>>> altogether.  This is not a great solution.
>>>
>>>  It is hard for me to justify ignoring the lock request in all cases.
>>> What does everyone else think?
>>>
>>>
>>>
>>>
>>>
>>>   --
>>> John O'Harajohara at redhat.com
>>>
>>> JBoss, by Red Hat
>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>>
>>>
>>>
>>
>>
>> --
>> John O'Harajohara at redhat.com
>>
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>
>>
>>
>

From sanne at hibernate.org  Fri Apr 10 13:25:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 10 Apr 2015 19:25:47 +0200
Subject: [hibernate-dev] Adding a custom table to the user defined mapping
Message-ID: <CAFm4XO3SUxF2UaFGshdtjL50nNa-aXbR=DO6BtrDH349yC4VwA@mail.gmail.com>

Hi all,
I'm considering solving a complex issue in Hibernate Search by having
it add a couple of "system entities" to the set of user defined
entities.

Do we have any example on how I'd do that?

Bonus brownies if we could figure out a way to mark these as
"internal".. i.e. it would be nice to not allow user code to load
these, have other entities relate to these, or mention them in HQL
queries.
I'd need a backdoor to allow Search code to do that though :)
Of course I don't expect us to be able to hide the physical tables.

I guess I could get pretty far by using JDBC rather than defining it
as an entity, but I'd rather avoid that. If that were my only option,
I'd at least want to extend the schema generation/validation tasks to
include by custom table.

Thanks,
Sanne

From alex.snaps at gmail.com  Fri Apr 10 16:25:52 2015
From: alex.snaps at gmail.com (Alex Snaps)
Date: Fri, 10 Apr 2015 20:25:52 +0000
Subject: [hibernate-dev] JSR107 H2LC module
Message-ID: <CAKux6pZDK6_heUPG8F89b=RRkZAZiLV+3w0EYXfmFZ2kkgShaQ@mail.gmail.com>

Hey guys,
I'm not completely, only mostly, done with the JSR-107, aka javax.cache,
aka jcache, 2nd level cache for Hibernate.
I still have to sort out the issue with dependencies, where the current
hibernate-ehcache module suffers from the new module being added (I use
ehcache as the provider for testing); and finish the integration with the
hibernate-orm cache test module. I hope to finish these off within the
coming week.
That being said, I thought I'd share it already, as I'm seeking input on it
from other caching modules (i.e. infinispan mainly I guess)... So maybe
Sanne or someone may be able to find some time to do a "conceptual" review.
I'm trying to hangout on IRC more often now, so feel free to call me out on
there...
Anyways, rfc! I hope this can make sense for others...
Let me know what you think. It's all on my github fork in the
hibernate-jcache module:
https://github.com/alexsnaps/hibernate-orm/tree/jsr107
Alex

From steve at hibernate.org  Fri Apr 10 16:35:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 10 Apr 2015 15:35:58 -0500
Subject: [hibernate-dev] JSR107 H2LC module
In-Reply-To: <CAKux6pZDK6_heUPG8F89b=RRkZAZiLV+3w0EYXfmFZ2kkgShaQ@mail.gmail.com>
References: <CAKux6pZDK6_heUPG8F89b=RRkZAZiLV+3w0EYXfmFZ2kkgShaQ@mail.gmail.com>
Message-ID: <CAFdSV9uPd32FU5+t0muwEhbqcFw8JD-WFJU-A1zvWLe5m4NssQ@mail.gmail.com>

I can't really speak to the caching aspect as well as others, but if you
need help sorting out the dependencies give me a shout.

On Fri, Apr 10, 2015 at 3:25 PM, Alex Snaps <alex.snaps at gmail.com> wrote:

> Hey guys,
> I'm not completely, only mostly, done with the JSR-107, aka javax.cache,
> aka jcache, 2nd level cache for Hibernate.
> I still have to sort out the issue with dependencies, where the current
> hibernate-ehcache module suffers from the new module being added (I use
> ehcache as the provider for testing); and finish the integration with the
> hibernate-orm cache test module. I hope to finish these off within the
> coming week.
> That being said, I thought I'd share it already, as I'm seeking input on it
> from other caching modules (i.e. infinispan mainly I guess)... So maybe
> Sanne or someone may be able to find some time to do a "conceptual" review.
> I'm trying to hangout on IRC more often now, so feel free to call me out on
> there...
> Anyways, rfc! I hope this can make sense for others...
> Let me know what you think. It's all on my github fork in the
> hibernate-jcache module:
> https://github.com/alexsnaps/hibernate-orm/tree/jsr107
> Alex
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From alex.snaps at gmail.com  Fri Apr 10 16:55:58 2015
From: alex.snaps at gmail.com (Alex Snaps)
Date: Fri, 10 Apr 2015 20:55:58 +0000
Subject: [hibernate-dev] JSR107 H2LC module
In-Reply-To: <CAFdSV9uPd32FU5+t0muwEhbqcFw8JD-WFJU-A1zvWLe5m4NssQ@mail.gmail.com>
References: <CAKux6pZDK6_heUPG8F89b=RRkZAZiLV+3w0EYXfmFZ2kkgShaQ@mail.gmail.com>
	<CAFdSV9uPd32FU5+t0muwEhbqcFw8JD-WFJU-A1zvWLe5m4NssQ@mail.gmail.com>
Message-ID: <CAKux6pYERuQut_UzB+1XrTcKzRo9CT-jHgOXVDsEe18QM-LB8A@mail.gmail.com>

Thanks Steve!
I actually might, but I first have to figure how to best do this anyways...
maybe I can use the RI for testing, I didn't try... Issue being it can
easily deadlock in multithreaded usage.
Anyways, just figured out I first need to fix a case issue. Managed to have
a file wrongly name: NonstrictEntityRegionAccessStrategy.java w/o uppercase
S... fixing it obviously was a no op from git's perspective on this crappy
non-case sensitive FS! Apologies to anyone trying to run this for now...
Alex

On Fri, Apr 10, 2015 at 4:35 PM Steve Ebersole <steve at hibernate.org> wrote:

> I can't really speak to the caching aspect as well as others, but if you
> need help sorting out the dependencies give me a shout.
>
> On Fri, Apr 10, 2015 at 3:25 PM, Alex Snaps <alex.snaps at gmail.com> wrote:
>
>> Hey guys,
>> I'm not completely, only mostly, done with the JSR-107, aka javax.cache,
>> aka jcache, 2nd level cache for Hibernate.
>> I still have to sort out the issue with dependencies, where the current
>> hibernate-ehcache module suffers from the new module being added (I use
>> ehcache as the provider for testing); and finish the integration with the
>> hibernate-orm cache test module. I hope to finish these off within the
>> coming week.
>> That being said, I thought I'd share it already, as I'm seeking input on
>> it
>> from other caching modules (i.e. infinispan mainly I guess)... So maybe
>> Sanne or someone may be able to find some time to do a "conceptual"
>> review.
>> I'm trying to hangout on IRC more often now, so feel free to call me out
>> on
>> there...
>> Anyways, rfc! I hope this can make sense for others...
>> Let me know what you think. It's all on my github fork in the
>> hibernate-jcache module:
>> https://github.com/alexsnaps/hibernate-orm/tree/jsr107
>> Alex
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From johara at redhat.com  Mon Apr 13 06:37:18 2015
From: johara at redhat.com (John O'Hara)
Date: Mon, 13 Apr 2015 11:37:18 +0100
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <CAFdSV9uq4A54F2gsxGT8UurqPTcfJZ6sCN5VDdNXERGZtDjLPg@mail.gmail.com>
References: <551D0F9E.1000801@redhat.com>	<CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>	<55242904.8040306@redhat.com>	<CAFdSV9uHpKY_8WbJwLf7cMx75qwyZnK=j_OPJMQ_tFATMwKg=A@mail.gmail.com>	<5527DDA1.6000903@redhat.com>	<CAFdSV9vyXauzh+9bVEa1kqz5uRq_+s1+R4en+WmqYnKmEEa0Mw@mail.gmail.com>
	<CAFdSV9uq4A54F2gsxGT8UurqPTcfJZ6sCN5VDdNXERGZtDjLPg@mail.gmail.com>
Message-ID: <552B9C5E.4040202@redhat.com>

I think there are two factors to consider, when the entity is marked as 
Immutable, and when the EntityEntry can be shared between sessions.

Our use case concerns the ImmutableEntityEntry being cached and shared 
between sessions, so we need to check if the Entity is reference cached 
in the 2lc.

Therefore I think the answer to the question below is;

  * I would consider the the trigger for using ImmutableEntityEntry when
    the Entity is marked as Immutable;
  * I would consider the trigger for not nulling the EntityEntry in the
    EntityEntryContext when the EntityEntry is an ImmutableEntityEntry
    and the Entity is reference cached in the 2lc


There might be further optimizations for ImmutableEntityEntries that are 
not cached and shared between sessions that I am not aware of.

It seems the most logical place to determine whether to create a 
MutableEntityEntry or an ImmutableEntityEntry is when a call is made to 
AbstractEntityPersister getEntityEntryFactory() and we can test to see 
if the Entity is Immutable.

I was unsure how of the best method to determine if the Enity would be 
cached in the 2lc, so tested at the point EntityEntry is nulled in 
EntityEntryContext. removeEntityEntry() or EntityEntryContext.clear()


On 10/04/15 17:46, Steve Ebersole wrote:
> To post my question again...
>
> It really depends on what y'all consider the trigger for using 
> ImmutableEntityEntry.  When would the EntityPersister use the 
> EntityEntryFactory producing ImmutableEntityEntry instances?
> a) when the entity is marked immutable?
> b) when the entity is marked immutable *and* we need to cache it by 
> reference?
> c) some other condition?
>
> Because the answer to this ^^ dictates how we need to check whether we 
> can clear this reference
>
>
> On Fri, Apr 10, 2015 at 11:45 AM, Steve Ebersole <steve at hibernate.org 
> <mailto:steve at hibernate.org>> wrote:
>
>     Well the performance is exactly what I had in mind when I asked
>     you about the exact "trigger for using ImmutableEntityEntry" in
>     your use-case.  But you never replied to that.
>
>
>
>     On Fri, Apr 10, 2015 at 9:26 AM, John O'Hara <johara at redhat.com
>     <mailto:johara at redhat.com>> wrote:
>
>         I have updated my current branch:
>         https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>
>           * Extracted the deserialization of EntityEntry in
>             EntityEntryContext into a separate method:
>             https://github.com/johnaoahra80/hibernate-orm/commit/d9f5dc76e05a111d37dbdac64c6aa1bd485a1ba9
>           * Created a LockModeException for invalid lock modes for an
>             ImmutableEntity:
>             https://github.com/johnaoahra80/hibernate-orm/commit/99e308ae267f9bfc30547784087955d7dc1e73e0
>
>         Do we need a new Exception type here, or could we just use a
>         HibernateException with a message about invalid lock type?
>
>           * Added a check when EntityEntryContext.clear() or
>             EntityEntry. removeEntityEntry() is called to see if the
>             EntityEntry is ImmutableEntityEntry AND the Entity is
>             referenced cached in the 2lc:
>             https://github.com/johnaoahra80/hibernate-orm/commit/310a2eb5b8988189806a2e688090a7ea16ae5474
>
>         Not sure of the performance implications on this, I am
>         planning a run on WF9 to test and regressions in our use case.
>
>           * Extracted an AbstractEntityEntry superclass that
>             MutableEntityEntry and ImmutableEntityEntry both inherit
>             from:
>             https://github.com/johnaoahra80/hibernate-orm/commit/df50d344441ed4cc8f3c3c8df90edc106dd52adb
>
>         John
>
>
>
>
>         On 07/04/15 20:20, Steve Ebersole wrote:
>>         TBH, I have no idea what happens to comments on a Pull
>>         Request when you squash and force push.
>>
>>         I'd just leave the multiple commits.  We can squash them later.
>>
>>         On Tue, Apr 7, 2015 at 1:59 PM, John O'Hara
>>         <johara at redhat.com <mailto:johara at redhat.com>> wrote:
>>
>>             Steve,
>>
>>             I have made changes based on the github comments and your
>>             comments below
>>             (https://github.com/johnaoahra80/hibernate-orm/commits/HHH-9701).
>>
>>             Do you want me to squash the commits down to one? Not
>>             sure how this would effect the comments you have already
>>             made on GH
>>
>>             Thanks
>>
>>             John
>>
>>
>>             On 06/04/15 04:51, Steve Ebersole wrote:
>>>
>>>
>>>             On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara
>>>             <johara at redhat.com <mailto:johara at redhat.com>> wrote:
>>>
>>>                 Steve,
>>>
>>>                 I have pushed a proposal for HHH-9701 to:
>>>                 https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>>
>>>                 There are a couple of areas that I would appreciate
>>>                 feedback;
>>>
>>>                 1) Serialization/Deserialization - EntityEntries
>>>                 implementations can be serialized and each
>>>                 implementation provide their own serialization
>>>                 method. I have modified the serialization of
>>>                 EntityEntry in EntityEntryContext to write the
>>>                 Implementation class to the OutputStream so the
>>>                 correct class can be used to deserialize the object
>>>                 stream.  Is the exception handling sufficient here,
>>>                 or do we need more robust handling of
>>>                 deserialization exceptions? : see
>>>                 https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>>>
>>>
>>>             I added some comments to that section.  Also, overall I
>>>             would extract the deserialization bit into a separate
>>>             method (deserializeEntityEntry).
>>>
>>>
>>>                 2) In our (perf team) use case, we want to be able
>>>                 to share the ImmutableEntityEntry between sessions
>>>                 when they are referenced cached in the 2lc. I have
>>>                 modified EntityEntryContext to not null
>>>                 managedEntity.$$_hibernate_setEntityEntry if the
>>>                 EntityEntry is an instance of ImmutableEntityEntry.
>>>                 Do we need to add an extra checks here, to ensure
>>>                 that the entity is Reference Cached? I am not sure
>>>                 how we would test that case? : see
>>>                 https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>>>
>>>
>>>             It really depends on what y'all consider the trigger for
>>>             using ImmutableEntityEntry. When would the
>>>             EntityPersister use the EntityEntryFactory producing
>>>             ImmutableEntityEntry instances?
>>>             a) when the entity is marked immutable?
>>>             b) when the entity is marked immutable *and* we need to
>>>             cache it by reference?
>>>             c) some other condition?
>>>
>>>             I agree that we should only not clear that reference
>>>             when the entity is enabled for cache-by-reference. How
>>>             that plays into this depends on the answer to the above
>>>             question.
>>>
>>>             If (a), then I think that yes it makes sense to add a
>>>             check to only clear the ManagedEntity's EntityEntry
>>>             reference if using cache-by-reference.
>>>
>>>             If (b), then the EntiytPersister is only using the
>>>             EntityEntryFactory producing ImmutableEntityEntry
>>>             instances when both are true.  So the fact that an entry
>>>             is an instance of ImmutableEntityEntry indicates that we
>>>             need to not clear it from the ManagedEntity.
>>>
>>>
>>>
>>>                 3) Lock Mode: Steve you mentioned about not doing
>>>                 locking for Immutable entities. Where is the locking
>>>                 implemented? Would it be sufficient to simply set
>>>                 the LockMode on the ImmutableEntityEntry to
>>>                 NONE/READ_ONLY when setLockMode is called?
>>>
>>>
>>>
>>>             Locking is implemented in many places.
>>>
>>>             What I had in mind, in terms of implementation for
>>>             EntityEntry, is somewhat influenced by the choice
>>>             between ignore versus exception in cases where something
>>>             is not supported. Basically I had thought to throw an
>>>             exception in ImmutableEntityEntry#setLockMode or to
>>>             simply ignore the call altogether.  This is not a great
>>>             solution.
>>>
>>>             It is hard for me to justify ignoring the lock request
>>>             in all cases.  What does everyone else think?
>>>
>>>
>>>
>>
>>
>>             -- 
>>             John O'Hara
>>             johara at redhat.com  <mailto:johara at redhat.com>
>>
>>             JBoss, by Red Hat
>>             Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>             Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>
>>
>
>
>         -- 
>         John O'Hara
>         johara at redhat.com  <mailto:johara at redhat.com>
>
>         JBoss, by Red Hat
>         Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>         Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>
>
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From jonathan.halliday at redhat.com  Mon Apr 13 07:12:14 2015
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Mon, 13 Apr 2015 12:12:14 +0100
Subject: [hibernate-dev] OGM cassandra backend
Message-ID: <552BA48E.2030802@redhat.com>


The first part of the cassandra backend work is ready for review. I've 
backed out the incomplete association support, leaving the basic 
framework for the backend module with enough functionality to support 
entities that don't have relations. It's still larger than an average 
PR, but the module design follows an established pattern so it shouldn't 
cause too much problem.

Unfortunately the plugin that runs cassandra embedded is a bit stale and 
won't play nice with the newer cassandra release that is required for 
some bug fixes. Until it catches up, you (and the CI cluster) will need 
to bring up a db server manually before running the tests. Fortunately 
it's not hard:

http://www.apache.org/dyn/closer.cgi?path=/cassandra/2.1.4/apache-cassandra-2.1.4-bin.tar.gz

untar, then run  bin/cassandra -f

I has intended to roll straight into the association support 
functionality whist the PR on this first part was being reviewed, but I 
think I'll context switch to some infinispan stuff and return to OGM 
aligned with the next sprint starting in a couple of weeks.

Jonathan.

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)

From gunnar at hibernate.org  Wed Apr 15 05:52:30 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 15 Apr 2015 11:52:30 +0200
Subject: [hibernate-dev] OGM 5 Bootstrap: Reading property value in
	MetadataBuilderContributor
Message-ID: <CADGJaX_tERKfY5bLgj1LGTLJ_m6wzP0iH_uF6kWDHK7VtaEcAg@mail.gmail.com>

Steve, all,

For migrating OGM to the new ORM 5 bootstrap APIs, I am looking into using
a MetadataBuilderContributor for applying an OGM-specific
ImplicitNamingStrategy.

Provided it is exposed via META-INF/services, the contributor is run
un-conditionally. So I'd need a way to find out whether the passed
MetadataBuilder is meant to bootstrap Hibernate ORM or OGM.

If there is no way to do so (I couldn't find any), could the previously
applied configuration settings be exposed e.g. via

* an accessor MetadataBuilder#getSettings()
* or a new parameter on
MetadataBuilderContributor#contribute(MetadataBuilder b, Map<String,
Object> settings)
* or even MetadataBuilderContributor#contribute(MetadataBuilder b,
StandardServiceRegistry ssr)

?

Then I could make contribute() instantly return depending on some property
which is set before (we can do that for JPA in HibernateOgmPersistence,
OGM's PersistenceProvider, and in a custom ServiceRegistry factory for
non-JPA).

Thanks,

--Gunnar

From jonathan.halliday at redhat.com  Wed Apr 15 07:41:07 2015
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Wed, 15 Apr 2015 12:41:07 +0100
Subject: [hibernate-dev] OGM test refactoring
Message-ID: <552E4E53.5030901@redhat.com>


In the course of developing the cassandra backend for OGM I've hit an 
issue with some of the backendtck tests.

These tests are in core and reused by each backend. It's possible to 
exclude tests at class or method level per backend, which prevents 
irrelevant tests from running for a given backend. So far, so good.

The problem I'm seeing stems from the fact that even when a test is 
excluded, the annotated POJOs it uses are still parsed and passed 
through schema creation, since that occurs in a setup step before the 
individual tests are iterated and (not) run.

There are certain POJOs that contains mappings cassandra can't support. 
Even with the corresponding test disabled, when these are passed to the 
schema creator it blows up, effectively preventing the other legitimate 
tests in the same class from running.

In an ideal world I'd like a class/method level annotation listing the 
required POJOs to replace the getAnnotatedClasses method, allowing POJOs 
to be parsed or skipped in accordance with the corresponding annotation 
on the same test method.

@RequiredPOJO(Foo.class)
@Test
@SkipByGridDialect(...)
public void testFoo()

Alternatively I can (I think) subclass the test class in the backend and 
override the getAnnotatedClasses method to exclude the problem POJOs, 
whilst leaving the @SkipByGridDialect on the shared parent for clarity. 
  Or simply copy and paste the whole thing and nuke the offending 
POJOs/methods in my backend's copy.

On a related note, many of the offending tests could be altered in such 
a way that the resulting schema is acceptable to cassandra, which would 
largely sidestep the issue but alter the test semantics. In many 
instances I suspect the semantic in question is one that's not critical 
to the test's intent, but I may be wrong.

Essentially cassandra uses what a relational db would call 'index 
organized tables', i.e. the on-disk layout of data is a function of the 
table's key. As a result, it's not possible to declare tables without a 
primary key. Such mappings result from collections with bag semantics, 
such as @OneToMany List<Object>, since the list may have dups. Removing 
the bag semantics such as by adding an index column, avoids this issue. 
But then you're testing something different...


Any preference on the approach to changing the test suite?

Jonathan.

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)

From gunnar at hibernate.org  Wed Apr 15 08:54:46 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 15 Apr 2015 14:54:46 +0200
Subject: [hibernate-dev] OGM test refactoring
In-Reply-To: <552E4E53.5030901@redhat.com>
References: <552E4E53.5030901@redhat.com>
Message-ID: <CADGJaX-4E=Dsx=ZePA1dVmF+JqmDhWbN0U=0xCj6Wof2s_gEkA@mail.gmail.com>

How many tests are affected by this problem?

If not too many, it might be feasible to split those test methods into
several test classes (each only referencing the entities it actually needs)
which you then can mark individually with @SkipByGridDialect as needed.

I am no big of copying/pasting tests to the backend, we generally aim for
having as many tests in the TCK as possible. Only tests for store-specific
features or the persistent format should be in the backends whenever
possible. Sub-classing might work, though I find it not as nice to work
with, as it requires you to look/edit at two places when working with a
given test (we have some tests which use that pattern for MongoDB). I also
would prefer to not change semantics of existing tests.

I like the idea of a @TestEntities(Entity1.class, Entity2.class) annotation
which allows to specify the required entity types per test class and/or
method (probably cumulative, if given at both levels). This would be my
preference if splitting up doesn't work.

Can you name an example of a test affected by this?



2015-04-15 13:41 GMT+02:00 Jonathan Halliday <jonathan.halliday at redhat.com>:

>
> In the course of developing the cassandra backend for OGM I've hit an
> issue with some of the backendtck tests.
>
> These tests are in core and reused by each backend. It's possible to
> exclude tests at class or method level per backend, which prevents
> irrelevant tests from running for a given backend. So far, so good.
>
> The problem I'm seeing stems from the fact that even when a test is
> excluded, the annotated POJOs it uses are still parsed and passed
> through schema creation, since that occurs in a setup step before the
> individual tests are iterated and (not) run.
>
> There are certain POJOs that contains mappings cassandra can't support.
> Even with the corresponding test disabled, when these are passed to the
> schema creator it blows up, effectively preventing the other legitimate
> tests in the same class from running.
>
> In an ideal world I'd like a class/method level annotation listing the
> required POJOs to replace the getAnnotatedClasses method, allowing POJOs
> to be parsed or skipped in accordance with the corresponding annotation
> on the same test method.
>
> @RequiredPOJO(Foo.class)
> @Test
> @SkipByGridDialect(...)
> public void testFoo()
>
> Alternatively I can (I think) subclass the test class in the backend and
> override the getAnnotatedClasses method to exclude the problem POJOs,
> whilst leaving the @SkipByGridDialect on the shared parent for clarity.
>   Or simply copy and paste the whole thing and nuke the offending
> POJOs/methods in my backend's copy.
>
> On a related note, many of the offending tests could be altered in such
> a way that the resulting schema is acceptable to cassandra, which would
> largely sidestep the issue but alter the test semantics. In many
> instances I suspect the semantic in question is one that's not critical
> to the test's intent, but I may be wrong.
>
> Essentially cassandra uses what a relational db would call 'index
> organized tables', i.e. the on-disk layout of data is a function of the
> table's key. As a result, it's not possible to declare tables without a
> primary key. Such mappings result from collections with bag semantics,
> such as @OneToMany List<Object>, since the list may have dups. Removing
> the bag semantics such as by adding an index column, avoids this issue.
> But then you're testing something different...
>
>
> Any preference on the approach to changing the test suite?
>
> Jonathan.
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (USA), Matt Parson
> (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From jonathan.halliday at redhat.com  Wed Apr 15 09:53:52 2015
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Wed, 15 Apr 2015 14:53:52 +0100
Subject: [hibernate-dev] OGM test refactoring
In-Reply-To: <CADGJaX-4E=Dsx=ZePA1dVmF+JqmDhWbN0U=0xCj6Wof2s_gEkA@mail.gmail.com>
References: <552E4E53.5030901@redhat.com>
	<CADGJaX-4E=Dsx=ZePA1dVmF+JqmDhWbN0U=0xCj6Wof2s_gEkA@mail.gmail.com>
Message-ID: <552E6D70.3030807@redhat.com>



On 15/04/15 13:54, Gunnar Morling wrote:
> How many tests are affected by this problem?

hmm, good question. At present most of the association tests and a 
handful of assorted others that happen to use associations are blowing 
up because I haven't finished the association support.  I'm working 
through them gradually, resolving the legit failures and excluding the 
one that can't be expected to ever work.  My feeling so far is that it 
will affect maybe 5-10 test classes, which for refacoring purposes is a 
more important count than number of test methods.

> If not too many, it might be feasible to split those test methods into
> several test classes (each only referencing the entities it actually
> needs) which you then can mark individually with @SkipByGridDialect as
> needed.

umm, the point is that @SkipByGridDialect doesn't work, or I could just 
put it on existing methods. However that's a moot point, since if it's 
refactored to a separate class I can exclude it by class name in the 
pom.  Not sure I like the ongoing cognitive load of having two different 
strategies for test exclusions, but it's certainly less engineering 
effort than adding support for method level POJO usage declarations.

>
> I am no big of copying/pasting tests to the backend, we generally aim
> for having as many tests in the TCK as possible. Only tests for
> store-specific features or the persistent format should be in the
> backends whenever possible. Sub-classing might work, though I find it
> not as nice to work with, as it requires you to look/edit at two places
> when working with a given test (we have some tests which use that
> pattern for MongoDB). I also would prefer to not change semantics of
> existing tests.
>
> I like the idea of a @TestEntities(Entity1.class, Entity2.class)
> annotation which allows to specify the required entity types per test
> class and/or method (probably cumulative, if given at both levels). This
> would be my preference if splitting up doesn't work.
>
> Can you name an example of a test affected by this?

Basket.java:  @OneToMany List<Product>  from ManyToOneTest

>
>
>
> 2015-04-15 13:41 GMT+02:00 Jonathan Halliday
> <jonathan.halliday at redhat.com <mailto:jonathan.halliday at redhat.com>>:
>
>
>     In the course of developing the cassandra backend for OGM I've hit an
>     issue with some of the backendtck tests.
>
>     These tests are in core and reused by each backend. It's possible to
>     exclude tests at class or method level per backend, which prevents
>     irrelevant tests from running for a given backend. So far, so good.
>
>     The problem I'm seeing stems from the fact that even when a test is
>     excluded, the annotated POJOs it uses are still parsed and passed
>     through schema creation, since that occurs in a setup step before the
>     individual tests are iterated and (not) run.
>
>     There are certain POJOs that contains mappings cassandra can't support.
>     Even with the corresponding test disabled, when these are passed to the
>     schema creator it blows up, effectively preventing the other legitimate
>     tests in the same class from running.
>
>     In an ideal world I'd like a class/method level annotation listing the
>     required POJOs to replace the getAnnotatedClasses method, allowing POJOs
>     to be parsed or skipped in accordance with the corresponding annotation
>     on the same test method.
>
>     @RequiredPOJO(Foo.class)
>     @Test
>     @SkipByGridDialect(...)
>     public void testFoo()
>
>     Alternatively I can (I think) subclass the test class in the backend and
>     override the getAnnotatedClasses method to exclude the problem POJOs,
>     whilst leaving the @SkipByGridDialect on the shared parent for clarity.
>        Or simply copy and paste the whole thing and nuke the offending
>     POJOs/methods in my backend's copy.
>
>     On a related note, many of the offending tests could be altered in such
>     a way that the resulting schema is acceptable to cassandra, which would
>     largely sidestep the issue but alter the test semantics. In many
>     instances I suspect the semantic in question is one that's not critical
>     to the test's intent, but I may be wrong.
>
>     Essentially cassandra uses what a relational db would call 'index
>     organized tables', i.e. the on-disk layout of data is a function of the
>     table's key. As a result, it's not possible to declare tables without a
>     primary key. Such mappings result from collections with bag semantics,
>     such as @OneToMany List<Object>, since the list may have dups. Removing
>     the bag semantics such as by adding an index column, avoids this issue.
>     But then you're testing something different...
>
>
>     Any preference on the approach to changing the test suite?
>
>     Jonathan.
>
>     --
>     Registered in England and Wales under Company Registration No.
>     03798903 <tel:03798903>
>     Directors: Michael Cunningham (USA), Matt Parson
>     (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)

From steve at hibernate.org  Wed Apr 15 09:55:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Apr 2015 08:55:13 -0500
Subject: [hibernate-dev] OGM 5 Bootstrap: Reading property value in
	MetadataBuilderContributor
In-Reply-To: <CADGJaX_tERKfY5bLgj1LGTLJ_m6wzP0iH_uF6kWDHK7VtaEcAg@mail.gmail.com>
References: <CADGJaX_tERKfY5bLgj1LGTLJ_m6wzP0iH_uF6kWDHK7VtaEcAg@mail.gmail.com>
Message-ID: <CAFdSV9uOLN0=S0YxARewj1n6C1VQ3HnPktApeQQ5+vQ3HLMfaQ@mail.gmail.com>

I am not really sure what you mean by "need a way to find out whether the
passed MetadataBuilder is meant to bootstrap Hibernate ORM or OGM".  I
assume what you mean is really much more simple: how do I access
configuration settings from within a MetadataBuilderContributor?
Presumably a "yes OGM is available on the classpath, but it should not be
used here" setting.  That is the general tact we use for discovered
services and allowing them to be skipped.

Anyway, I will have to alter the MetadataBuilderContributor interface to
accept the StandardServiceRegistry.  Your option (3)


Also...

Funny timing :)  I was thinking some more this morning about ways to allow
OGM to alter stuff in this process.  I think another thing we should do is
to make the SessionFactoryBuilder pluggable.  The default impl would build
instances of org.hibernate.internal.SessionFactoryImpl.  OGM could plug in
an impl that builds the OGM-specific SessionFactory.  That would allow OGM
users to seamlessly use the same bootstrap constructs.

Perhaps even a pluggable MetadataBuildingProcess?



On Wed, Apr 15, 2015 at 4:52 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Steve, all,
>
> For migrating OGM to the new ORM 5 bootstrap APIs, I am looking into using
> a MetadataBuilderContributor for applying an OGM-specific
> ImplicitNamingStrategy.
>
> Provided it is exposed via META-INF/services, the contributor is run
> un-conditionally. So I'd need a way to find out whether the passed
> MetadataBuilder is meant to bootstrap Hibernate ORM or OGM.
>
> If there is no way to do so (I couldn't find any), could the previously
> applied configuration settings be exposed e.g. via
>
> * an accessor MetadataBuilder#getSettings()
> * or a new parameter on
> MetadataBuilderContributor#contribute(MetadataBuilder b, Map<String,
> Object> settings)
> * or even MetadataBuilderContributor#contribute(MetadataBuilder b,
> StandardServiceRegistry ssr)
>
> ?
>
> Then I could make contribute() instantly return depending on some property
> which is set before (we can do that for JPA in HibernateOgmPersistence,
> OGM's PersistenceProvider, and in a custom ServiceRegistry factory for
> non-JPA).
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Apr 15 10:07:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 15 Apr 2015 09:07:20 -0500
Subject: [hibernate-dev] Adding a custom table to the user defined
	mapping
In-Reply-To: <CAFm4XO3SUxF2UaFGshdtjL50nNa-aXbR=DO6BtrDH349yC4VwA@mail.gmail.com>
References: <CAFm4XO3SUxF2UaFGshdtjL50nNa-aXbR=DO6BtrDH349yC4VwA@mail.gmail.com>
Message-ID: <CAFdSV9tu-MJcLe0qpy9+aK327-S=AdieCxVYEseixSOgxVCMbQ@mail.gmail.com>

On Fri, Apr 10, 2015 at 12:25 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi all,
> I'm considering solving a complex issue in Hibernate Search by having
> it add a couple of "system entities" to the set of user defined
> entities.
>
> Do we have any example on how I'd do that?
>

Yep.  This is exactly what Envers does.  Currently, I have Envers
using org.hibernate.boot.spi.AdditionalJaxbMappingProducer for this
purpose.  That was a transitory fix since Envers already build DOM
(represeting the hbm.xml of the entities they want to add) and because I
did not want to waste cycles atm rewriting all of Envers bootstrapping to
"be more correct" and generate model classes directly.

We could start to develop the more correct approach for you to use.
Basically you would generate org.hibernate.mapping model instances yourself
and have them added to the "metadata sources".

Either way, you'd also be interested in looking at their "flush cycle
hooks" as you would probably have similar requirements.


Bonus brownies if we could figure out a way to mark these as
> "internal".. i.e. it would be nice to not allow user code to load
> these, have other entities relate to these, or mention them in HQL
> queries.
> I'd need a backdoor to allow Search code to do that though :)
> Of course I don't expect us to be able to hide the physical tables.
>

This does not exist today.  Blocking them from being used in associations
would be very detrimental to Envers if we were ever to expose this
generically.  But your other 2 points would work wonderfully with Envers
too.  We can add that for post-5.0 if you wish.  I don't see it as
critical.  As far as querying, I'd suggest marking these are not allowing
implicit polymorphism (are they returned, e.g., from a query like `from
java.lang.Object`?).


>
> I guess I could get pretty far by using JDBC rather than defining it
> as an entity, but I'd rather avoid that. If that were my only option,
> I'd at least want to extend the schema generation/validation tasks to
> include by custom table.
>

If you do go this route, this is pretty easy now in 5.0.  You'd simply
obtain the Database from the Metadata (preferrably while building, so
specifically from the org.hibernate.boot.spi.InFlightMetadataCollector).
>From there you could add tables, sequences, etc directly.  This is what
drives schema export, update, etc.

From jonathan.halliday at redhat.com  Wed Apr 15 10:24:18 2015
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Wed, 15 Apr 2015 15:24:18 +0100
Subject: [hibernate-dev] OGM test refactoring
In-Reply-To: <CADGJaX-fYtVf12-ZhWbViMxsZPFy9Cvk2FJAC-zYoUbWMCOz_Q@mail.gmail.com>
References: <552E4E53.5030901@redhat.com>	<CADGJaX-4E=Dsx=ZePA1dVmF+JqmDhWbN0U=0xCj6Wof2s_gEkA@mail.gmail.com>	<552E6D70.3030807@redhat.com>
	<CADGJaX-fYtVf12-ZhWbViMxsZPFy9Cvk2FJAC-zYoUbWMCOz_Q@mail.gmail.com>
Message-ID: <552E7492.3010207@redhat.com>



On 15/04/15 15:20, Gunnar Morling wrote:
>  > umm, the point is that @SkipByGridDialect doesn't work, or I could
> just put it on existing methods.
>
> By splitting up the affected tests into several classes you should be
> able to apply @SkipByGridDialect on the class level. Then no session
> factory at allwill be built bootstrapped for a skipped backend.

hmm, something fishy there - I recall trying that and finding it didn't 
work as the creation was still done before the annotation processing. 
That was a while back though and I may have fallen foul of the 
interesting issues where the test class that's actually used is the one 
from the last build in the mvn repo, not the current source in the core 
module.  I'll give it another try, since it's certainly an attractive 
path forward if it does work.

>
> So you should be fine if you manage to cut affected tests into pieces
> (classes) which either require an entity not processable by Cassandra
> (then exclude that test class via @SkipByGridDialect) or which require
> only entities processable by Cassandra (then you still could apply
> @SkipByGridDialect on the method-level to skip specific methods due to
> reasons other than the reading of the entities themselves).
>
>>Not sure I like the ongoing cognitive load of having two different
> strategies for test exclusions, but it's certainly less engineering
> effort than adding support for method level POJO usage declarations.
>
> Right, I would not like that either. Also exclusions in the POM won't
> apply when e.g. running all tests of a module in your IDE. The mechanism
> should solely based on the OGM test runner.
>
>
>
> 2015-04-15 15:53 GMT+02:00 Jonathan Halliday
> <jonathan.halliday at redhat.com <mailto:jonathan.halliday at redhat.com>>:
>
>
>
>     On 15/04/15 13:54, Gunnar Morling wrote:
>
>         How many tests are affected by this problem?
>
>
>     hmm, good question. At present most of the association tests and a
>     handful of assorted others that happen to use associations are
>     blowing up because I haven't finished the association support.  I'm
>     working through them gradually, resolving the legit failures and
>     excluding the one that can't be expected to ever work.  My feeling
>     so far is that it will affect maybe 5-10 test classes, which for
>     refacoring purposes is a more important count than number of test
>     methods.
>
>         If not too many, it might be feasible to split those test
>         methods into
>         several test classes (each only referencing the entities it actually
>         needs) which you then can mark individually with
>         @SkipByGridDialect as
>         needed.
>
>
>     umm, the point is that @SkipByGridDialect doesn't work, or I could
>     just put it on existing methods. However that's a moot point, since
>     if it's refactored to a separate class I can exclude it by class
>     name in the pom.  Not sure I like the ongoing cognitive load of
>     having two different strategies for test exclusions, but it's
>     certainly less engineering effort than adding support for method
>     level POJO usage declarations.
>
>
>         I am no big of copying/pasting tests to the backend, we
>         generally aim
>         for having as many tests in the TCK as possible. Only tests for
>         store-specific features or the persistent format should be in the
>         backends whenever possible. Sub-classing might work, though I
>         find it
>         not as nice to work with, as it requires you to look/edit at two
>         places
>         when working with a given test (we have some tests which use that
>         pattern for MongoDB). I also would prefer to not change semantics of
>         existing tests.
>
>         I like the idea of a @TestEntities(Entity1.class, Entity2.class)
>         annotation which allows to specify the required entity types per
>         test
>         class and/or method (probably cumulative, if given at both
>         levels). This
>         would be my preference if splitting up doesn't work.
>
>         Can you name an example of a test affected by this?
>
>
>     Basket.java:  @OneToMany List<Product>  from ManyToOneTest
>
>
>
>
>         2015-04-15 13:41 GMT+02:00 Jonathan Halliday
>         <jonathan.halliday at redhat.com
>         <mailto:jonathan.halliday at redhat.com>
>         <mailto:jonathan.halliday at __redhat.com
>         <mailto:jonathan.halliday at redhat.com>>>:
>
>
>
>              In the course of developing the cassandra backend for OGM
>         I've hit an
>              issue with some of the backendtck tests.
>
>              These tests are in core and reused by each backend. It's
>         possible to
>              exclude tests at class or method level per backend, which
>         prevents
>              irrelevant tests from running for a given backend. So far,
>         so good.
>
>              The problem I'm seeing stems from the fact that even when a
>         test is
>              excluded, the annotated POJOs it uses are still parsed and
>         passed
>              through schema creation, since that occurs in a setup step
>         before the
>              individual tests are iterated and (not) run.
>
>              There are certain POJOs that contains mappings cassandra
>         can't support.
>              Even with the corresponding test disabled, when these are
>         passed to the
>              schema creator it blows up, effectively preventing the
>         other legitimate
>              tests in the same class from running.
>
>              In an ideal world I'd like a class/method level annotation
>         listing the
>              required POJOs to replace the getAnnotatedClasses method,
>         allowing POJOs
>              to be parsed or skipped in accordance with the
>         corresponding annotation
>              on the same test method.
>
>              @RequiredPOJO(Foo.class)
>              @Test
>              @SkipByGridDialect(...)
>              public void testFoo()
>
>              Alternatively I can (I think) subclass the test class in
>         the backend and
>              override the getAnnotatedClasses method to exclude the
>         problem POJOs,
>              whilst leaving the @SkipByGridDialect on the shared parent
>         for clarity.
>                 Or simply copy and paste the whole thing and nuke the
>         offending
>              POJOs/methods in my backend's copy.
>
>              On a related note, many of the offending tests could be
>         altered in such
>              a way that the resulting schema is acceptable to cassandra,
>         which would
>              largely sidestep the issue but alter the test semantics. In
>         many
>              instances I suspect the semantic in question is one that's
>         not critical
>              to the test's intent, but I may be wrong.
>
>              Essentially cassandra uses what a relational db would call
>         'index
>              organized tables', i.e. the on-disk layout of data is a
>         function of the
>              table's key. As a result, it's not possible to declare
>         tables without a
>              primary key. Such mappings result from collections with bag
>         semantics,
>              such as @OneToMany List<Object>, since the list may have
>         dups. Removing
>              the bag semantics such as by adding an index column, avoids
>         this issue.
>              But then you're testing something different...
>
>
>              Any preference on the approach to changing the test suite?
>
>              Jonathan.
>
>              --
>              Registered in England and Wales under Company Registration No.
>         03798903 <tel:03798903> <tel:03798903 <tel:03798903>>
>              Directors: Michael Cunningham (USA), Matt Parson
>              (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
>              _________________________________________________
>              hibernate-dev mailing list
>         hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>         <mailto:hibernate-dev at lists.__jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>>
>         https://lists.jboss.org/__mailman/listinfo/hibernate-dev
>         <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>
>
>     --
>     Registered in England and Wales under Company Registration No.
>     03798903 <tel:03798903> Directors: Michael Cunningham (USA), Matt Parson
>     (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
>
>

-- 
Registered in England and Wales under Company Registration No. 03798903 
Directors: Michael Cunningham (USA), Matt Parson
(USA), Charlie Peters (USA), Michael O'Neill(Ireland)

From gunnar at hibernate.org  Wed Apr 15 10:20:23 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 15 Apr 2015 16:20:23 +0200
Subject: [hibernate-dev] OGM test refactoring
In-Reply-To: <552E6D70.3030807@redhat.com>
References: <552E4E53.5030901@redhat.com>
	<CADGJaX-4E=Dsx=ZePA1dVmF+JqmDhWbN0U=0xCj6Wof2s_gEkA@mail.gmail.com>
	<552E6D70.3030807@redhat.com>
Message-ID: <CADGJaX-fYtVf12-ZhWbViMxsZPFy9Cvk2FJAC-zYoUbWMCOz_Q@mail.gmail.com>

> umm, the point is that @SkipByGridDialect doesn't work, or I could just
put it on existing methods.

By splitting up the affected tests into several classes you should be able
to apply @SkipByGridDialect on the class level. Then no session factory at
all will be built bootstrapped for a skipped backend.

So you should be fine if you manage to cut affected tests into pieces
(classes) which either require an entity not processable by Cassandra (then
exclude that test class via @SkipByGridDialect) or which require only
entities processable by Cassandra (then you still could apply
@SkipByGridDialect on the method-level to skip specific methods due to
reasons other than the reading of the entities themselves).

> Not sure I like the ongoing cognitive load of having two different
strategies for test exclusions, but it's certainly less engineering effort
than adding support for method level POJO usage declarations.

Right, I would not like that either. Also exclusions in the POM won't apply
when e.g. running all tests of a module in your IDE. The mechanism should
solely based on the OGM test runner.



2015-04-15 15:53 GMT+02:00 Jonathan Halliday <jonathan.halliday at redhat.com>:

>
>
> On 15/04/15 13:54, Gunnar Morling wrote:
>
>> How many tests are affected by this problem?
>>
>
> hmm, good question. At present most of the association tests and a handful
> of assorted others that happen to use associations are blowing up because I
> haven't finished the association support.  I'm working through them
> gradually, resolving the legit failures and excluding the one that can't be
> expected to ever work.  My feeling so far is that it will affect maybe 5-10
> test classes, which for refacoring purposes is a more important count than
> number of test methods.
>
>  If not too many, it might be feasible to split those test methods into
>> several test classes (each only referencing the entities it actually
>> needs) which you then can mark individually with @SkipByGridDialect as
>> needed.
>>
>
> umm, the point is that @SkipByGridDialect doesn't work, or I could just
> put it on existing methods. However that's a moot point, since if it's
> refactored to a separate class I can exclude it by class name in the pom.
> Not sure I like the ongoing cognitive load of having two different
> strategies for test exclusions, but it's certainly less engineering effort
> than adding support for method level POJO usage declarations.
>
>
>> I am no big of copying/pasting tests to the backend, we generally aim
>> for having as many tests in the TCK as possible. Only tests for
>> store-specific features or the persistent format should be in the
>> backends whenever possible. Sub-classing might work, though I find it
>> not as nice to work with, as it requires you to look/edit at two places
>> when working with a given test (we have some tests which use that
>> pattern for MongoDB). I also would prefer to not change semantics of
>> existing tests.
>>
>> I like the idea of a @TestEntities(Entity1.class, Entity2.class)
>> annotation which allows to specify the required entity types per test
>> class and/or method (probably cumulative, if given at both levels). This
>> would be my preference if splitting up doesn't work.
>>
>> Can you name an example of a test affected by this?
>>
>
> Basket.java:  @OneToMany List<Product>  from ManyToOneTest
>
>
>>
>>
>> 2015-04-15 13:41 GMT+02:00 Jonathan Halliday
>> <jonathan.halliday at redhat.com <mailto:jonathan.halliday at redhat.com>>:
>>
>>
>>
>>     In the course of developing the cassandra backend for OGM I've hit an
>>     issue with some of the backendtck tests.
>>
>>     These tests are in core and reused by each backend. It's possible to
>>     exclude tests at class or method level per backend, which prevents
>>     irrelevant tests from running for a given backend. So far, so good.
>>
>>     The problem I'm seeing stems from the fact that even when a test is
>>     excluded, the annotated POJOs it uses are still parsed and passed
>>     through schema creation, since that occurs in a setup step before the
>>     individual tests are iterated and (not) run.
>>
>>     There are certain POJOs that contains mappings cassandra can't
>> support.
>>     Even with the corresponding test disabled, when these are passed to
>> the
>>     schema creator it blows up, effectively preventing the other
>> legitimate
>>     tests in the same class from running.
>>
>>     In an ideal world I'd like a class/method level annotation listing the
>>     required POJOs to replace the getAnnotatedClasses method, allowing
>> POJOs
>>     to be parsed or skipped in accordance with the corresponding
>> annotation
>>     on the same test method.
>>
>>     @RequiredPOJO(Foo.class)
>>     @Test
>>     @SkipByGridDialect(...)
>>     public void testFoo()
>>
>>     Alternatively I can (I think) subclass the test class in the backend
>> and
>>     override the getAnnotatedClasses method to exclude the problem POJOs,
>>     whilst leaving the @SkipByGridDialect on the shared parent for
>> clarity.
>>        Or simply copy and paste the whole thing and nuke the offending
>>     POJOs/methods in my backend's copy.
>>
>>     On a related note, many of the offending tests could be altered in
>> such
>>     a way that the resulting schema is acceptable to cassandra, which
>> would
>>     largely sidestep the issue but alter the test semantics. In many
>>     instances I suspect the semantic in question is one that's not
>> critical
>>     to the test's intent, but I may be wrong.
>>
>>     Essentially cassandra uses what a relational db would call 'index
>>     organized tables', i.e. the on-disk layout of data is a function of
>> the
>>     table's key. As a result, it's not possible to declare tables without
>> a
>>     primary key. Such mappings result from collections with bag semantics,
>>     such as @OneToMany List<Object>, since the list may have dups.
>> Removing
>>     the bag semantics such as by adding an index column, avoids this
>> issue.
>>     But then you're testing something different...
>>
>>
>>     Any preference on the approach to changing the test suite?
>>
>>     Jonathan.
>>
>>     --
>>     Registered in England and Wales under Company Registration No.
>>     03798903 <tel:03798903>
>>     Directors: Michael Cunningham (USA), Matt Parson
>>     (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
>>     _______________________________________________
>>     hibernate-dev mailing list
>>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (USA), Matt Parson
> (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
>

From mih_vlad at yahoo.com  Wed Apr 15 16:27:30 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Wed, 15 Apr 2015 20:27:30 +0000 (UTC)
Subject: [hibernate-dev] Any change of adding generics to Hibernate specific
	API
Message-ID: <227323507.3861546.1429129650656.JavaMail.yahoo@mail.yahoo.com>

Hi,
Although many rely on the Java Persistence API, Hibernate still offers specific features, like mapping a native SQLQuery result set to a DTO:
.setResultTransformer(Transformers.aliasToBean(DTO.class));
Is it possible to add TypedQuery and TypedSQLQuery, analogous to the JPA specs, so you can use generics with specific API?
Adding new interfaces and some overloaded Session methods wouldn't break backward compatibility.

Vlad MiIhalcea

From gbadner at redhat.com  Wed Apr 15 17:13:48 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 15 Apr 2015 17:13:48 -0400 (EDT)
Subject: [hibernate-dev] Preparing to release 4.3.9.Final and 4.2.19.Final
Message-ID: <1533391845.377211.1429132428366.JavaMail.zimbra@redhat.com>

Please do not push any commits to 4.3 or 4.2 branches until I finish the releases.
Thanks!
Gail

From gbadner at redhat.com  Wed Apr 15 18:06:26 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 15 Apr 2015 18:06:26 -0400 (EDT)
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
	<826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
	<CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>
Message-ID: <1532647237.393859.1429135586855.JavaMail.zimbra@redhat.com>

When will we start having these meetings?

----- Original Message -----
> From: "Sanne Grinovero" <sanne at hibernate.org>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, March 23, 2015 2:17:40 PM
> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> 
> +1 it's a nice time to allow me to join occasionally as needed
> 
> Sanne
> 
> On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com> wrote:
> > 11am Seattle time would be ideal. Thanks!
> > Gail
> >
> > ----- Original Message -----
> >> From: "Brett Meyer" <brmeyer at redhat.com>
> >> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >> Sent: Monday, March 23, 2015 6:51:49 AM
> >> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >>
> >> Big +1 from me -- I'd be more than happy to be involved.
> >>
> >> ----- Original Message -----
> >> > From: "andrea boriero" <dreborier at gmail.com>
> >> > To: "Steve Ebersole" <steve at hibernate.org>
> >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> >> > Sent: Sunday, March 22, 2015 3:45:01 PM
> >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >> >
> >> > for me at the moment it would be 6pm and it should be good.
> >> >
> >> > On 21 March 2015 at 21:08, Steve Ebersole <steve at hibernate.org> wrote:
> >> >
> >> > > Gail and I discussed Jira a little bit last week and how to best
> >> > > manage
> >> > > scheduling issues.
> >> > >
> >> > > We both agreed that a team get together, either weekly or
> >> > > every-other-week,
> >> > > to discuss new issues to triage them would be a great idea.
> >> > >
> >> > > One thing I absolutely do not want happening is just scheduling issues
> >> > > as
> >> > > a
> >> > > means to come back and triage them later.  Scheduling an issue, on a
> >> > > "real
> >> > > version" anyway, should mean something.  It should mean some level of
> >> > > dedication to finish that task for that release.  In short, unless you
> >> > > are
> >> > > volunteering to take on a task *yourself* for that release, please do
> >> > > not
> >> > > schedule it for that release.
> >> > >
> >> > > As for the triage meeting, I would definitely like Gail and Andrea
> >> > > involved.  Of course anyone is welcome.  The reason I mention this is
> >> > > that
> >> > > Gail is usually left on early side of scheduling these.  So we will
> >> > > find
> >> > > a
> >> > > time that works best for us 3 and go from there.  I recommend that we
> >> > > leverage HipChat for these discussion.
> >> > >
> >> > > Andrea is coming to Austin for a few days starting Monday, so I would
> >> > > like
> >> > > to start this triaging while he is here.  Gail, I am thinking 1pm my
> >> > > time
> >> > > (11am yours) would be a good time.  Andrea, does that work for you
> >> > > after
> >> > > Austin?
> >> > > _______________________________________________
> >> > > 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
> >> >
> >> _______________________________________________
> >> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From gbadner at redhat.com  Wed Apr 15 20:46:58 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 15 Apr 2015 20:46:58 -0400 (EDT)
Subject: [hibernate-dev] Preparing to release 4.3.9.Final and
 4.2.19.Final
In-Reply-To: <1533391845.377211.1429132428366.JavaMail.zimbra@redhat.com>
References: <1533391845.377211.1429132428366.JavaMail.zimbra@redhat.com>
Message-ID: <1122193114.427646.1429145218965.JavaMail.zimbra@redhat.com>

I've finished with the releases and have uploaded artifacts, release bundles, and docs for both releases.

I'll write up a blog later this evening with some details.

Thanks,
Gail

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, April 15, 2015 2:13:48 PM
> Subject: [hibernate-dev] Preparing to release 4.3.9.Final and 4.2.19.Final
> 
> Please do not push any commits to 4.3 or 4.2 branches until I finish the
> releases.
> Thanks!
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From gbadner at redhat.com  Thu Apr 16 02:20:59 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 16 Apr 2015 02:20:59 -0400 (EDT)
Subject: [hibernate-dev] Hibernate 4.3.9.Final and 4.2.19.Final Released
In-Reply-To: <583136885.528698.1429165159570.JavaMail.zimbra@redhat.com>
Message-ID: <1370363011.529215.1429165259624.JavaMail.zimbra@redhat.com>

For details, see: http://in.relation.to/Bloggers/HibernateORM439Final4218FinalAnd4219FinalReleased

Gail Badner
Red Hat, Hibernate ORM

From steve at hibernate.org  Thu Apr 16 08:20:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 16 Apr 2015 07:20:23 -0500
Subject: [hibernate-dev] org.hibernate.cfg.Settings deprecated
Message-ID: <CAFdSV9tdWTisyc-=gnX8T-0SaOMkRNPteStJ6KVVPNCdhB=UKg@mail.gmail.com>

Last night I pushed some changes which included deprecating
org.hibernate.cfg.Settings in favor
of org.hibernate.boot.spi.SessionFactoryOptions.  The main reason for this
was to make it easier for OGM and others to hook into the SessionFactory
creation process.  For now, I have made Settings delegate
to SessionFactoryOptions.

I am not sure if anything external relies on this Settings contract.  But
there are a few usages I wanted to discuss.

First is caching.  Part of the SPI for building RegionFactrory is passing
along the Settings object.  Ideally I'd just swap this with
SessionFactoryOptions.  And given that this targets a major release (5.0),
that should be ok.  Anyone against that?  Sanne?  Galder?  Alex?

Second is the initiation of BV integration.  The TypesafeActivator accesses
the Settings object in order to
call org.hibernate.cfg.Settings#setCheckNullability.  As of now, this is
the only setter method I have left on Settings (it simply passes that call
on to the SessionFactoryOptions, which exposes just this one setter for
just this one case).  I'd like to make it so that SessionFactoryOptions is
immutable at the time SessionFactory is built.  This was largely true for
Settings already aside from this one use case.  I am just not sure yet of
the best way to allow an Integrator to affect this SessionFactoryBuilder
process.  Thoughts?

From steve at hibernate.org  Thu Apr 16 09:16:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 16 Apr 2015 08:16:41 -0500
Subject: [hibernate-dev] ORM Team "triage" meeting
In-Reply-To: <1532647237.393859.1429135586855.JavaMail.zimbra@redhat.com>
References: <CAFdSV9t9P2GLroTOpbDpokt=pv2LWN=HxMZo5UvkB++EdN3m_Q@mail.gmail.com>
	<CAL00eSSffdM6dzSecLvObx9KZttDbpoxMUL09fEXzQ7KL=cWLA@mail.gmail.com>
	<622303598.2758003.1427118709845.JavaMail.zimbra@redhat.com>
	<826763478.3552493.1427137846428.JavaMail.zimbra@redhat.com>
	<CAFm4XO2wNgSckVzqjnB_52fAjDBuBO=SVmyLf+zHvy39grMSAg@mail.gmail.com>
	<1532647237.393859.1429135586855.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9tWmePYfLZBhBW8BuN-wvrAT8C6KS6v6zbZwJ2j1adymA@mail.gmail.com>

Sometime after the next 5.0 release.  You know, after I have time to
breathe :)

On Wed, Apr 15, 2015 at 5:06 PM, Gail Badner <gbadner at redhat.com> wrote:

> When will we start having these meetings?
>
> ----- Original Message -----
> > From: "Sanne Grinovero" <sanne at hibernate.org>
> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > Sent: Monday, March 23, 2015 2:17:40 PM
> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> >
> > +1 it's a nice time to allow me to join occasionally as needed
> >
> > Sanne
> >
> > On 23 March 2015 at 19:10, Gail Badner <gbadner at redhat.com> wrote:
> > > 11am Seattle time would be ideal. Thanks!
> > > Gail
> > >
> > > ----- Original Message -----
> > >> From: "Brett Meyer" <brmeyer at redhat.com>
> > >> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > >> Sent: Monday, March 23, 2015 6:51:49 AM
> > >> Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > >>
> > >> Big +1 from me -- I'd be more than happy to be involved.
> > >>
> > >> ----- Original Message -----
> > >> > From: "andrea boriero" <dreborier at gmail.com>
> > >> > To: "Steve Ebersole" <steve at hibernate.org>
> > >> > Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > >> > Sent: Sunday, March 22, 2015 3:45:01 PM
> > >> > Subject: Re: [hibernate-dev] ORM Team "triage" meeting
> > >> >
> > >> > for me at the moment it would be 6pm and it should be good.
> > >> >
> > >> > On 21 March 2015 at 21:08, Steve Ebersole <steve at hibernate.org>
> wrote:
> > >> >
> > >> > > Gail and I discussed Jira a little bit last week and how to best
> > >> > > manage
> > >> > > scheduling issues.
> > >> > >
> > >> > > We both agreed that a team get together, either weekly or
> > >> > > every-other-week,
> > >> > > to discuss new issues to triage them would be a great idea.
> > >> > >
> > >> > > One thing I absolutely do not want happening is just scheduling
> issues
> > >> > > as
> > >> > > a
> > >> > > means to come back and triage them later.  Scheduling an issue,
> on a
> > >> > > "real
> > >> > > version" anyway, should mean something.  It should mean some
> level of
> > >> > > dedication to finish that task for that release.  In short,
> unless you
> > >> > > are
> > >> > > volunteering to take on a task *yourself* for that release,
> please do
> > >> > > not
> > >> > > schedule it for that release.
> > >> > >
> > >> > > As for the triage meeting, I would definitely like Gail and Andrea
> > >> > > involved.  Of course anyone is welcome.  The reason I mention
> this is
> > >> > > that
> > >> > > Gail is usually left on early side of scheduling these.  So we
> will
> > >> > > find
> > >> > > a
> > >> > > time that works best for us 3 and go from there.  I recommend
> that we
> > >> > > leverage HipChat for these discussion.
> > >> > >
> > >> > > Andrea is coming to Austin for a few days starting Monday, so I
> would
> > >> > > like
> > >> > > to start this triaging while he is here.  Gail, I am thinking 1pm
> my
> > >> > > time
> > >> > > (11am yours) would be a good time.  Andrea, does that work for you
> > >> > > after
> > >> > > Austin?
> > >> > > _______________________________________________
> > >> > > 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
> > >> >
> > >> _______________________________________________
> > >> 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
> > _______________________________________________
> > 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
>

From smarlow at redhat.com  Thu Apr 16 09:47:51 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 16 Apr 2015 09:47:51 -0400
Subject: [hibernate-dev] Hibernate 4.3.9.Final and 4.2.19.Final Released
In-Reply-To: <1370363011.529215.1429165259624.JavaMail.zimbra@redhat.com>
References: <1370363011.529215.1429165259624.JavaMail.zimbra@redhat.com>
Message-ID: <552FBD87.4090904@redhat.com>

Congratulations on the new releases!

On 04/16/2015 02:20 AM, Gail Badner wrote:
> For details, see: http://in.relation.to/Bloggers/HibernateORM439Final4218FinalAnd4219FinalReleased
>
> Gail Badner
> Red Hat, Hibernate ORM
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Apr 17 08:38:16 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 17 Apr 2015 13:38:16 +0100
Subject: [hibernate-dev] Multi-Tenancy for Hibernate Search users:
	5.2.0.Beta1 released
Message-ID: <CAFm4XO1OqFZbweoMxmtc5+5oun9RdPecWE-pR5cS4fPhcvGofQ@mail.gmail.com>

Hello all,
version 5.2.0.Beta1 of Hibernate Search is available.

The description is here:
 - http://in.relation.to/Bloggers/MultiTenancyForHibernateSearchUsers520Beta1Released

Regards,
Sanne

From steve at hibernate.org  Fri Apr 17 14:55:08 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Apr 2015 13:55:08 -0500
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <552B9C5E.4040202@redhat.com>
References: <551D0F9E.1000801@redhat.com>
	<CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>
	<55242904.8040306@redhat.com>
	<CAFdSV9uHpKY_8WbJwLf7cMx75qwyZnK=j_OPJMQ_tFATMwKg=A@mail.gmail.com>
	<5527DDA1.6000903@redhat.com>
	<CAFdSV9vyXauzh+9bVEa1kqz5uRq_+s1+R4en+WmqYnKmEEa0Mw@mail.gmail.com>
	<CAFdSV9uq4A54F2gsxGT8UurqPTcfJZ6sCN5VDdNXERGZtDjLPg@mail.gmail.com>
	<552B9C5E.4040202@redhat.com>
Message-ID: <CAFdSV9uA5Q=TKidk+fQLafvUKAi4WVk6j=rHOaR-rxZoUoQpGw@mail.gmail.com>

I commented on your pull request.

My main concern is how you determine "canClearEntityEntryReference".  That
needs to change.  See my comment.



On Mon, Apr 13, 2015 at 5:37 AM, John O'Hara <johara at redhat.com> wrote:

>  I think there are two factors to consider, when the entity is marked as
> Immutable, and when the EntityEntry can be shared between sessions.
>
> Our use case concerns the ImmutableEntityEntry being cached and shared
> between sessions, so we need to check if the Entity is reference cached in
> the 2lc.
>
> Therefore I think the answer to the question below is;
>
>
>    - I would consider the the trigger for using ImmutableEntityEntry when
>    the Entity is marked as Immutable;
>    - I would consider the trigger for not nulling the EntityEntry in the
>    EntityEntryContext when the EntityEntry is an ImmutableEntityEntry and the
>    Entity is reference cached in the 2lc
>
>
> There might be further optimizations for ImmutableEntityEntries that are
> not cached and shared between sessions that I am not aware of.
>
> It seems the most logical place to determine whether to create a
> MutableEntityEntry or an ImmutableEntityEntry is when a call is made to
> AbstractEntityPersister getEntityEntryFactory() and we can test to see if
> the Entity is Immutable.
>
> I was unsure how of the best method to determine if the Enity would be
> cached in the 2lc, so tested at the point EntityEntry is nulled in
> EntityEntryContext. removeEntityEntry() or EntityEntryContext.clear()
>
>
>
> On 10/04/15 17:46, Steve Ebersole wrote:
>
> To post my question again...
>
>  It really depends on what y'all consider the trigger for using
> ImmutableEntityEntry.  When would the EntityPersister use the
> EntityEntryFactory producing ImmutableEntityEntry instances?
> a) when the entity is marked immutable?
> b) when the entity is marked immutable *and* we need to cache it by
> reference?
> c) some other condition?
>
>  Because the answer to this ^^ dictates how we need to check whether we
> can clear this reference
>
>
> On Fri, Apr 10, 2015 at 11:45 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Well the performance is exactly what I had in mind when I asked you about
>> the exact "trigger for using ImmutableEntityEntry" in your use-case.
>> But you never replied to that.
>>
>>
>>
>> On Fri, Apr 10, 2015 at 9:26 AM, John O'Hara <johara at redhat.com> wrote:
>>
>>>  I have updated my current branch:
>>> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>>
>>>    - Extracted the deserialization of EntityEntry in EntityEntryContext
>>>    into a separate method:
>>>    https://github.com/johnaoahra80/hibernate-orm/commit/d9f5dc76e05a111d37dbdac64c6aa1bd485a1ba9
>>>    - Created a LockModeException for invalid lock modes for an
>>>    ImmutableEntity:
>>>    https://github.com/johnaoahra80/hibernate-orm/commit/99e308ae267f9bfc30547784087955d7dc1e73e0
>>>
>>> Do we need a new Exception type here, or could we just use a
>>> HibernateException with a message about invalid lock type?
>>>
>>>    - Added a check when EntityEntryContext.clear() or EntityEntry.
>>>    removeEntityEntry() is called to see if the EntityEntry is
>>>    ImmutableEntityEntry AND the Entity is referenced cached in the 2lc:
>>>    https://github.com/johnaoahra80/hibernate-orm/commit/310a2eb5b8988189806a2e688090a7ea16ae5474
>>>
>>> Not sure of the performance implications on this, I am planning a run on
>>> WF9 to test and regressions in our use case.
>>>
>>>    - Extracted an AbstractEntityEntry superclass that
>>>    MutableEntityEntry and ImmutableEntityEntry both inherit from:
>>>    https://github.com/johnaoahra80/hibernate-orm/commit/df50d344441ed4cc8f3c3c8df90edc106dd52adb
>>>
>>>  John
>>>
>>>
>>>
>>>
>>> On 07/04/15 20:20, Steve Ebersole wrote:
>>>
>>> TBH, I have no idea what happens to comments on a Pull Request when you
>>> squash and force push.
>>>
>>>  I'd just leave the multiple commits.  We can squash them later.
>>>
>>> On Tue, Apr 7, 2015 at 1:59 PM, John O'Hara <johara at redhat.com> wrote:
>>>
>>>>  Steve,
>>>>
>>>> I have made changes based on the github comments and your comments
>>>> below (https://github.com/johnaoahra80/hibernate-orm/commits/HHH-9701).
>>>>
>>>> Do you want me to squash the commits down to one? Not sure how this
>>>> would effect the comments you have already made on GH
>>>>
>>>> Thanks
>>>>
>>>> John
>>>>
>>>>
>>>> On 06/04/15 04:51, Steve Ebersole wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara <johara at redhat.com> wrote:
>>>>
>>>>>  Steve,
>>>>>
>>>>> I have pushed a proposal for HHH-9701 to:
>>>>> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>>>>
>>>>> There are a couple of areas that I would appreciate feedback;
>>>>>
>>>>> 1) Serialization/Deserialization - EntityEntries implementations can
>>>>> be serialized and each implementation provide their own serialization
>>>>> method. I have modified the serialization of EntityEntry in
>>>>> EntityEntryContext to write the Implementation class to the OutputStream so
>>>>> the correct class can be used to deserialize the object stream.  Is the
>>>>> exception handling sufficient here, or do we need more robust handling of
>>>>> deserialization exceptions? : see
>>>>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>>>>>
>>>>
>>>>  I added some comments to that section.  Also, overall I would extract
>>>> the deserialization bit into a separate method (deserializeEntityEntry).
>>>>
>>>>
>>>>
>>>>  2) In our (perf team) use case, we want to be able to share the
>>>>> ImmutableEntityEntry between sessions when they are referenced cached in
>>>>> the 2lc. I have modified EntityEntryContext to not null
>>>>> managedEntity.$$_hibernate_setEntityEntry if the EntityEntry is an instance
>>>>> of ImmutableEntityEntry.  Do we need to add an extra checks here, to ensure
>>>>> that the entity is Reference Cached? I am not sure how we would test that
>>>>> case? : see
>>>>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>>>>>
>>>>
>>>>  It really depends on what y'all consider the trigger for using
>>>> ImmutableEntityEntry.  When would the EntityPersister use the
>>>> EntityEntryFactory producing ImmutableEntityEntry instances?
>>>> a) when the entity is marked immutable?
>>>> b) when the entity is marked immutable *and* we need to cache it by
>>>> reference?
>>>> c) some other condition?
>>>>
>>>>  I agree that we should only not clear that reference when the entity
>>>> is enabled for cache-by-reference.  How that plays into this depends on the
>>>> answer to the above question.
>>>>
>>>>  If (a), then I think that yes it makes sense to add a check to only
>>>> clear the ManagedEntity's EntityEntry reference if using cache-by-reference.
>>>>
>>>>  If (b), then the EntiytPersister is only using the EntityEntryFactory
>>>> producing ImmutableEntityEntry instances when both are true.  So the fact
>>>> that an entry is an instance of ImmutableEntityEntry indicates that we need
>>>> to not clear it from the ManagedEntity.
>>>>
>>>>
>>>>
>>>>
>>>>> 3) Lock Mode: Steve you mentioned about not doing locking for
>>>>> Immutable entities. Where is the locking implemented? Would it be
>>>>> sufficient to simply set the LockMode on the ImmutableEntityEntry to
>>>>> NONE/READ_ONLY when setLockMode is called?
>>>>>
>>>>
>>>>
>>>>  Locking is implemented in many places.
>>>>
>>>>  What I had in mind, in terms of implementation for EntityEntry, is
>>>> somewhat influenced by the choice between ignore versus exception in cases
>>>> where something is not supported.  Basically I had thought to throw an
>>>> exception in ImmutableEntityEntry#setLockMode or to simply ignore the call
>>>> altogether.  This is not a great solution.
>>>>
>>>>  It is hard for me to justify ignoring the lock request in all cases.
>>>> What does everyone else think?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>   --
>>>> John O'Harajohara at redhat.com
>>>>
>>>> JBoss, by Red Hat
>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> John O'Harajohara at redhat.com
>>>
>>> JBoss, by Red Hat
>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>>
>>>
>>>
>>
>
>
> --
> John O'Harajohara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>
>
>

From johara at redhat.com  Fri Apr 17 15:04:38 2015
From: johara at redhat.com (John O'Hara)
Date: Fri, 17 Apr 2015 20:04:38 +0100
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <CAFdSV9uA5Q=TKidk+fQLafvUKAi4WVk6j=rHOaR-rxZoUoQpGw@mail.gmail.com>
References: <551D0F9E.1000801@redhat.com>	<CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>	<55242904.8040306@redhat.com>	<CAFdSV9uHpKY_8WbJwLf7cMx75qwyZnK=j_OPJMQ_tFATMwKg=A@mail.gmail.com>	<5527DDA1.6000903@redhat.com>	<CAFdSV9vyXauzh+9bVEa1kqz5uRq_+s1+R4en+WmqYnKmEEa0Mw@mail.gmail.com>	<CAFdSV9uq4A54F2gsxGT8UurqPTcfJZ6sCN5VDdNXERGZtDjLPg@mail.gmail.com>	<552B9C5E.4040202@redhat.com>
	<CAFdSV9uA5Q=TKidk+fQLafvUKAi4WVk6j=rHOaR-rxZoUoQpGw@mail.gmail.com>
Message-ID: <55315946.2020202@redhat.com>

Thanks for reviewing, I was unsure of the best way to test if the Entity 
was referenced cached (or could be cached), I look at 
org.hibernate.persister.entity.EntityPersister#canUseReferenceCacheEntries 
instead.

Would it matter if the entity was Immutable and not cached? In that case 
we would not be nulling the ref to the EntityEntry, but the Entity could 
not be shared between sessions. Would the Entity object (and EntityEntry 
object) be GC'd after a session was closed if the entity was not cached? 
Is there the potential for a mem leak there?

I will also change the Exception name and cache the EntityEntryFactory 
when the EntityPersister is constructed



On 17/04/15 19:55, Steve Ebersole wrote:
> I commented on your pull request.
>
> My main concern is how you determine "canClearEntityEntryReference".  
> That needs to change.  See my comment.
>
>
>
> On Mon, Apr 13, 2015 at 5:37 AM, John O'Hara <johara at redhat.com 
> <mailto:johara at redhat.com>> wrote:
>
>     I think there are two factors to consider, when the entity is
>     marked as Immutable, and when the EntityEntry can be shared
>     between sessions.
>
>     Our use case concerns the ImmutableEntityEntry being cached and
>     shared between sessions, so we need to check if the Entity is
>     reference cached in the 2lc.
>
>     Therefore I think the answer to the question below is;
>
>       * I would consider the the trigger for using
>         ImmutableEntityEntry when the Entity is marked as Immutable;
>       * I would consider the trigger for not nulling the EntityEntry
>         in the EntityEntryContext when the EntityEntry is an
>         ImmutableEntityEntry and the Entity is reference cached in the 2lc
>
>
>     There might be further optimizations for ImmutableEntityEntries
>     that are not cached and shared between sessions that I am not
>     aware of.
>
>     It seems the most logical place to determine whether to create a
>     MutableEntityEntry or an ImmutableEntityEntry is when a call is
>     made to AbstractEntityPersister getEntityEntryFactory() and we can
>     test to see if the Entity is Immutable.
>
>     I was unsure how of the best method to determine if the Enity
>     would be cached in the 2lc, so tested at the point EntityEntry is
>     nulled in EntityEntryContext. removeEntityEntry() or
>     EntityEntryContext.clear()
>
>
>
>     On 10/04/15 17:46, Steve Ebersole wrote:
>>     To post my question again...
>>
>>     It really depends on what y'all consider the trigger for using
>>     ImmutableEntityEntry.  When would the EntityPersister use the
>>     EntityEntryFactory producing ImmutableEntityEntry instances?
>>     a) when the entity is marked immutable?
>>     b) when the entity is marked immutable *and* we need to cache it
>>     by reference?
>>     c) some other condition?
>>
>>     Because the answer to this ^^ dictates how we need to check
>>     whether we can clear this reference
>>
>>
>>     On Fri, Apr 10, 2015 at 11:45 AM, Steve Ebersole
>>     <steve at hibernate.org <mailto:steve at hibernate.org>> wrote:
>>
>>         Well the performance is exactly what I had in mind when I
>>         asked you about the exact "trigger for using
>>         ImmutableEntityEntry" in your use-case.  But you never
>>         replied to that.
>>
>>
>>
>>         On Fri, Apr 10, 2015 at 9:26 AM, John O'Hara
>>         <johara at redhat.com <mailto:johara at redhat.com>> wrote:
>>
>>             I have updated my current branch:
>>             https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>
>>               * Extracted the deserialization of EntityEntry in
>>                 EntityEntryContext into a separate method:
>>                 https://github.com/johnaoahra80/hibernate-orm/commit/d9f5dc76e05a111d37dbdac64c6aa1bd485a1ba9
>>               * Created a LockModeException for invalid lock modes
>>                 for an ImmutableEntity:
>>                 https://github.com/johnaoahra80/hibernate-orm/commit/99e308ae267f9bfc30547784087955d7dc1e73e0
>>
>>             Do we need a new Exception type here, or could we just
>>             use a HibernateException with a message about invalid
>>             lock type?
>>
>>               * Added a check when EntityEntryContext.clear() or
>>                 EntityEntry. removeEntityEntry() is called to see if
>>                 the EntityEntry is ImmutableEntityEntry AND the
>>                 Entity is referenced cached in the 2lc:
>>                 https://github.com/johnaoahra80/hibernate-orm/commit/310a2eb5b8988189806a2e688090a7ea16ae5474
>>
>>             Not sure of the performance implications on this, I am
>>             planning a run on WF9 to test and regressions in our use
>>             case.
>>
>>               * Extracted an AbstractEntityEntry superclass that
>>                 MutableEntityEntry and ImmutableEntityEntry both
>>                 inherit from:
>>                 https://github.com/johnaoahra80/hibernate-orm/commit/df50d344441ed4cc8f3c3c8df90edc106dd52adb
>>
>>             John
>>
>>
>>
>>
>>             On 07/04/15 20:20, Steve Ebersole wrote:
>>>             TBH, I have no idea what happens to comments on a Pull
>>>             Request when you squash and force push.
>>>
>>>             I'd just leave the multiple commits.  We can squash them
>>>             later.
>>>
>>>             On Tue, Apr 7, 2015 at 1:59 PM, John O'Hara
>>>             <johara at redhat.com <mailto:johara at redhat.com>> wrote:
>>>
>>>                 Steve,
>>>
>>>                 I have made changes based on the github comments and
>>>                 your comments below
>>>                 (https://github.com/johnaoahra80/hibernate-orm/commits/HHH-9701).
>>>
>>>                 Do you want me to squash the commits down to one?
>>>                 Not sure how this would effect the comments you have
>>>                 already made on GH
>>>
>>>                 Thanks
>>>
>>>                 John
>>>
>>>
>>>                 On 06/04/15 04:51, Steve Ebersole wrote:
>>>>
>>>>
>>>>                 On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara
>>>>                 <johara at redhat.com <mailto:johara at redhat.com>> wrote:
>>>>
>>>>                     Steve,
>>>>
>>>>                     I have pushed a proposal for HHH-9701 to:
>>>>                     https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>>>
>>>>                     There are a couple of areas that I would
>>>>                     appreciate feedback;
>>>>
>>>>                     1) Serialization/Deserialization -
>>>>                     EntityEntries implementations can be serialized
>>>>                     and each implementation provide their own
>>>>                     serialization method. I have modified the
>>>>                     serialization of EntityEntry in
>>>>                     EntityEntryContext to write the Implementation
>>>>                     class to the OutputStream so the correct class
>>>>                     can be used to deserialize the object stream. 
>>>>                     Is the exception handling sufficient here, or
>>>>                     do we need more robust handling of
>>>>                     deserialization exceptions? : see
>>>>                     https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>>>>
>>>>
>>>>                 I added some comments to that section. Also,
>>>>                 overall I would extract the deserialization bit
>>>>                 into a separate method (deserializeEntityEntry).
>>>>
>>>>
>>>>                     2) In our (perf team) use case, we want to be
>>>>                     able to share the ImmutableEntityEntry between
>>>>                     sessions when they are referenced cached in the
>>>>                     2lc. I have modified EntityEntryContext to not
>>>>                     null managedEntity.$$_hibernate_setEntityEntry
>>>>                     if the EntityEntry is an instance of
>>>>                     ImmutableEntityEntry. Do we need to add an
>>>>                     extra checks here, to ensure that the entity is
>>>>                     Reference Cached? I am not sure how we would
>>>>                     test that case? : see
>>>>                     https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>>>>
>>>>
>>>>                 It really depends on what y'all consider the
>>>>                 trigger for using ImmutableEntityEntry. When would
>>>>                 the EntityPersister use the EntityEntryFactory
>>>>                 producing ImmutableEntityEntry instances?
>>>>                 a) when the entity is marked immutable?
>>>>                 b) when the entity is marked immutable *and* we
>>>>                 need to cache it by reference?
>>>>                 c) some other condition?
>>>>
>>>>                 I agree that we should only not clear that
>>>>                 reference when the entity is enabled for
>>>>                 cache-by-reference. How that plays into this
>>>>                 depends on the answer to the above question.
>>>>
>>>>                 If (a), then I think that yes it makes sense to add
>>>>                 a check to only clear the ManagedEntity's
>>>>                 EntityEntry reference if using cache-by-reference.
>>>>
>>>>                 If (b), then the EntiytPersister is only using the
>>>>                 EntityEntryFactory producing ImmutableEntityEntry
>>>>                 instances when both are true.  So the fact that an
>>>>                 entry is an instance of ImmutableEntityEntry
>>>>                 indicates that we need to not clear it from the
>>>>                 ManagedEntity.
>>>>
>>>>
>>>>
>>>>                     3) Lock Mode: Steve you mentioned about not
>>>>                     doing locking for Immutable entities. Where is
>>>>                     the locking implemented? Would it be sufficient
>>>>                     to simply set the LockMode on the
>>>>                     ImmutableEntityEntry to NONE/READ_ONLY when
>>>>                     setLockMode is called?
>>>>
>>>>
>>>>
>>>>                 Locking is implemented in many places.
>>>>
>>>>                 What I had in mind, in terms of implementation for
>>>>                 EntityEntry, is somewhat influenced by the choice
>>>>                 between ignore versus exception in cases where
>>>>                 something is not supported. Basically I had thought
>>>>                 to throw an exception in
>>>>                 ImmutableEntityEntry#setLockMode or to simply
>>>>                 ignore the call altogether. This is not a great
>>>>                 solution.
>>>>
>>>>                 It is hard for me to justify ignoring the lock
>>>>                 request in all cases. What does everyone else think?
>>>>
>>>>
>>>>
>>>
>>>
>>>                 -- 
>>>                 John O'Hara
>>>                 johara at redhat.com  <mailto:johara at redhat.com>
>>>
>>>                 JBoss, by Red Hat
>>>                 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>>                 Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>>
>>>
>>
>>
>>             -- 
>>             John O'Hara
>>             johara at redhat.com  <mailto:johara at redhat.com>
>>
>>             JBoss, by Red Hat
>>             Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>             Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>
>>
>>
>
>
>     -- 
>     John O'Hara
>     johara at redhat.com  <mailto:johara at redhat.com>
>
>     JBoss, by Red Hat
>     Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>     Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>
>


-- 
John O'Hara
johara at redhat.com

JBoss, by Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).


From steve at hibernate.org  Fri Apr 17 17:12:35 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 17 Apr 2015 16:12:35 -0500
Subject: [hibernate-dev] HHH-9701 - Develop "immutable EntityEntry" impl
In-Reply-To: <55315946.2020202@redhat.com>
References: <551D0F9E.1000801@redhat.com>
	<CAFdSV9uWUkOimNisVbyQYVR8zHM6camMaOunFMvwxiBpp5VqhQ@mail.gmail.com>
	<55242904.8040306@redhat.com>
	<CAFdSV9uHpKY_8WbJwLf7cMx75qwyZnK=j_OPJMQ_tFATMwKg=A@mail.gmail.com>
	<5527DDA1.6000903@redhat.com>
	<CAFdSV9vyXauzh+9bVEa1kqz5uRq_+s1+R4en+WmqYnKmEEa0Mw@mail.gmail.com>
	<CAFdSV9uq4A54F2gsxGT8UurqPTcfJZ6sCN5VDdNXERGZtDjLPg@mail.gmail.com>
	<552B9C5E.4040202@redhat.com>
	<CAFdSV9uA5Q=TKidk+fQLafvUKAi4WVk6j=rHOaR-rxZoUoQpGw@mail.gmail.com>
	<55315946.2020202@redhat.com>
Message-ID: <CAFdSV9vvruBRzCyyAOxxw0dz+tQ3CAuh1fizgZPfhw3pS2R_mA@mail.gmail.com>

And change the name of DefaultEntityEntryFactory :)

On Fri, Apr 17, 2015 at 2:04 PM, John O'Hara <johara at redhat.com> wrote:

>  Thanks for reviewing, I was unsure of the best way to test if the Entity
> was referenced cached (or could be cached), I look at
> org.hibernate.persister.entity.EntityPersister#canUseReferenceCacheEntries
> instead.
>
> Would it matter if the entity was Immutable and not cached? In that case
> we would not be nulling the ref to the EntityEntry, but the Entity could
> not be shared between sessions. Would the Entity object (and EntityEntry
> object) be GC'd after a session was closed if the entity was not cached? Is
> there the potential for a mem leak there?
>
> I will also change the Exception name and cache the EntityEntryFactory
> when the EntityPersister is constructed
>
>
>
>
> On 17/04/15 19:55, Steve Ebersole wrote:
>
> I commented on your pull request.
>
>  My main concern is how you determine "canClearEntityEntryReference".
> That needs to change.  See my comment.
>
>
>
> On Mon, Apr 13, 2015 at 5:37 AM, John O'Hara <johara at redhat.com> wrote:
>
>>  I think there are two factors to consider, when the entity is marked as
>> Immutable, and when the EntityEntry can be shared between sessions.
>>
>> Our use case concerns the ImmutableEntityEntry being cached and shared
>> between sessions, so we need to check if the Entity is reference cached in
>> the 2lc.
>>
>> Therefore I think the answer to the question below is;
>>
>>
>>    - I would consider the the trigger for using ImmutableEntityEntry
>>    when the Entity is marked as Immutable;
>>    - I would consider the trigger for not nulling the EntityEntry in the
>>    EntityEntryContext when the EntityEntry is an ImmutableEntityEntry and the
>>    Entity is reference cached in the 2lc
>>
>>
>> There might be further optimizations for ImmutableEntityEntries that are
>> not cached and shared between sessions that I am not aware of.
>>
>> It seems the most logical place to determine whether to create a
>> MutableEntityEntry or an ImmutableEntityEntry is when a call is made to
>> AbstractEntityPersister getEntityEntryFactory() and we can test to see if
>> the Entity is Immutable.
>>
>> I was unsure how of the best method to determine if the Enity would be
>> cached in the 2lc, so tested at the point EntityEntry is nulled in
>> EntityEntryContext. removeEntityEntry() or EntityEntryContext.clear()
>>
>>
>>
>> On 10/04/15 17:46, Steve Ebersole wrote:
>>
>> To post my question again...
>>
>>  It really depends on what y'all consider the trigger for using
>> ImmutableEntityEntry.  When would the EntityPersister use the
>> EntityEntryFactory producing ImmutableEntityEntry instances?
>> a) when the entity is marked immutable?
>> b) when the entity is marked immutable *and* we need to cache it by
>> reference?
>> c) some other condition?
>>
>>  Because the answer to this ^^ dictates how we need to check whether we
>> can clear this reference
>>
>>
>> On Fri, Apr 10, 2015 at 11:45 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Well the performance is exactly what I had in mind when I asked you
>>> about the exact "trigger for using ImmutableEntityEntry" in your
>>> use-case.  But you never replied to that.
>>>
>>>
>>>
>>> On Fri, Apr 10, 2015 at 9:26 AM, John O'Hara <johara at redhat.com> wrote:
>>>
>>>>  I have updated my current branch:
>>>> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>>>
>>>>    - Extracted the deserialization of EntityEntry in
>>>>    EntityEntryContext into a separate method:
>>>>    https://github.com/johnaoahra80/hibernate-orm/commit/d9f5dc76e05a111d37dbdac64c6aa1bd485a1ba9
>>>>    - Created a LockModeException for invalid lock modes for an
>>>>    ImmutableEntity:
>>>>    https://github.com/johnaoahra80/hibernate-orm/commit/99e308ae267f9bfc30547784087955d7dc1e73e0
>>>>
>>>> Do we need a new Exception type here, or could we just use a
>>>> HibernateException with a message about invalid lock type?
>>>>
>>>>    - Added a check when EntityEntryContext.clear() or EntityEntry.
>>>>    removeEntityEntry() is called to see if the EntityEntry is
>>>>    ImmutableEntityEntry AND the Entity is referenced cached in the 2lc:
>>>>    https://github.com/johnaoahra80/hibernate-orm/commit/310a2eb5b8988189806a2e688090a7ea16ae5474
>>>>
>>>> Not sure of the performance implications on this, I am planning a run
>>>> on WF9 to test and regressions in our use case.
>>>>
>>>>    - Extracted an AbstractEntityEntry superclass that
>>>>    MutableEntityEntry and ImmutableEntityEntry both inherit from:
>>>>    https://github.com/johnaoahra80/hibernate-orm/commit/df50d344441ed4cc8f3c3c8df90edc106dd52adb
>>>>
>>>>  John
>>>>
>>>>
>>>>
>>>>
>>>> On 07/04/15 20:20, Steve Ebersole wrote:
>>>>
>>>> TBH, I have no idea what happens to comments on a Pull Request when you
>>>> squash and force push.
>>>>
>>>>  I'd just leave the multiple commits.  We can squash them later.
>>>>
>>>> On Tue, Apr 7, 2015 at 1:59 PM, John O'Hara <johara at redhat.com> wrote:
>>>>
>>>>>  Steve,
>>>>>
>>>>> I have made changes based on the github comments and your comments
>>>>> below (https://github.com/johnaoahra80/hibernate-orm/commits/HHH-9701
>>>>> ).
>>>>>
>>>>> Do you want me to squash the commits down to one? Not sure how this
>>>>> would effect the comments you have already made on GH
>>>>>
>>>>> Thanks
>>>>>
>>>>> John
>>>>>
>>>>>
>>>>> On 06/04/15 04:51, Steve Ebersole wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 2, 2015 at 4:45 AM, John O'Hara <johara at redhat.com> wrote:
>>>>>
>>>>>>  Steve,
>>>>>>
>>>>>> I have pushed a proposal for HHH-9701 to:
>>>>>> https://github.com/johnaoahra80/hibernate-orm/tree/HHH-9701
>>>>>>
>>>>>> There are a couple of areas that I would appreciate feedback;
>>>>>>
>>>>>> 1) Serialization/Deserialization - EntityEntries implementations can
>>>>>> be serialized and each implementation provide their own serialization
>>>>>> method. I have modified the serialization of EntityEntry in
>>>>>> EntityEntryContext to write the Implementation class to the OutputStream so
>>>>>> the correct class can be used to deserialize the object stream.  Is the
>>>>>> exception handling sufficient here, or do we need more robust handling of
>>>>>> deserialization exceptions? : see
>>>>>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44R380
>>>>>>
>>>>>
>>>>>  I added some comments to that section.  Also, overall I would
>>>>> extract the deserialization bit into a separate method
>>>>> (deserializeEntityEntry).
>>>>>
>>>>>
>>>>>
>>>>>  2) In our (perf team) use case, we want to be able to share the
>>>>>> ImmutableEntityEntry between sessions when they are referenced cached in
>>>>>> the 2lc. I have modified EntityEntryContext to not null
>>>>>> managedEntity.$$_hibernate_setEntityEntry if the EntityEntry is an instance
>>>>>> of ImmutableEntityEntry.  Do we need to add an extra checks here, to ensure
>>>>>> that the entity is Reference Cached? I am not sure how we would test that
>>>>>> case? : see
>>>>>> https://github.com/johnaoahra80/hibernate-orm/commit/ec9b1fa3b97131ff1e65a1cc30ff6e4f2d2c8a28#diff-b55e1e51b30abe8d3c280bb22aeb6a44L281
>>>>>>
>>>>>
>>>>>  It really depends on what y'all consider the trigger for using
>>>>> ImmutableEntityEntry.  When would the EntityPersister use the
>>>>> EntityEntryFactory producing ImmutableEntityEntry instances?
>>>>> a) when the entity is marked immutable?
>>>>> b) when the entity is marked immutable *and* we need to cache it by
>>>>> reference?
>>>>> c) some other condition?
>>>>>
>>>>>  I agree that we should only not clear that reference when the entity
>>>>> is enabled for cache-by-reference.  How that plays into this depends on the
>>>>> answer to the above question.
>>>>>
>>>>>  If (a), then I think that yes it makes sense to add a check to only
>>>>> clear the ManagedEntity's EntityEntry reference if using cache-by-reference.
>>>>>
>>>>>  If (b), then the EntiytPersister is only using the
>>>>> EntityEntryFactory producing ImmutableEntityEntry instances when both are
>>>>> true.  So the fact that an entry is an instance of ImmutableEntityEntry
>>>>> indicates that we need to not clear it from the ManagedEntity.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> 3) Lock Mode: Steve you mentioned about not doing locking for
>>>>>> Immutable entities. Where is the locking implemented? Would it be
>>>>>> sufficient to simply set the LockMode on the ImmutableEntityEntry to
>>>>>> NONE/READ_ONLY when setLockMode is called?
>>>>>>
>>>>>
>>>>>
>>>>>  Locking is implemented in many places.
>>>>>
>>>>>  What I had in mind, in terms of implementation for EntityEntry, is
>>>>> somewhat influenced by the choice between ignore versus exception in cases
>>>>> where something is not supported.  Basically I had thought to throw an
>>>>> exception in ImmutableEntityEntry#setLockMode or to simply ignore the call
>>>>> altogether.  This is not a great solution.
>>>>>
>>>>>  It is hard for me to justify ignoring the lock request in all
>>>>> cases.  What does everyone else think?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   --
>>>>> John O'Harajohara at redhat.com
>>>>>
>>>>> JBoss, by Red Hat
>>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>>>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> John O'Harajohara at redhat.com
>>>>
>>>> JBoss, by Red Hat
>>>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>>>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> John O'Harajohara at redhat.com
>>
>> JBoss, by Red Hat
>> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
>> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>>
>>
>>
>
>
> --
> John O'Harajohara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Michael O'Neill (Ireland).
>
>
>

From hardy at hibernate.org  Tue Apr 21 04:41:41 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 21 Apr 2015 10:41:41 +0200
Subject: [hibernate-dev] [Validator] Build problems!?
Message-ID: <20150421084141.GA72503@Nineveh.lan>

Hi,

I seem to have a odd build problem and wondering whether someone could verify the problem
or in any ways enlighten me regarding what's going on.

I can build the Validator master branch w/o problem ('mvn clean install'), but a 'mvn deploy' (SNAPSHOT deploy)
fails (output below). The funny thing is that the failure seems to occur during the main 
compilation task which seems odd, since the classes compile fine when using the 'install' target.
It might be related to the fact that a 'deploy' enables different profiles/settings, but a start 
would be to figure out whether others have the same problem. 

-- Hardy

P.S.: The Cloudbees HV-5.2-SNAPSHOT-DEPLOY job recently also fails erratically. It might be the same problem.

>>>>
mvn deploy
[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Build Order:
[INFO] 
[INFO] Hibernate Validator Aggregator
[INFO] Hibernate Validator Test Utils
[INFO] Hibernate Validator Engine
[INFO] Hibernate Validator Engine JDK 1.8 Tests
[INFO] Hibernate Validator Portable Extension
[INFO] Hibernate Validator TCK Runner
[INFO] Hibernate Validator Wildfly Integration Tests
[INFO] Hibernate Validator Annotation Processor
[INFO] Hibernate Validator Performance Tests
[INFO] Hibernate Validator OSGi Modules
[INFO] Hibernate Validator Karaf Features
[INFO] Hibernate Validator OSGi integration test
[INFO] Hibernate Validator Manual
[INFO] Hibernate Validator Distribution
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building Hibernate Validator Aggregator 5.2.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ hibernate-validator-parent ---
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ hibernate-validator-parent ---
[INFO] Installing /Users/hardy/work/hibernate/git/beanvalidation/validator/pom.xml to /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-SNAPSHOT.pom
[INFO] 
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ hibernate-validator-parent ---
Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml (620 B at 0.3 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-20150421.083018-230.pom
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-20150421.083018-230.pom (33 KB at 8.2 KB/sec)
Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml (839 B at 0.9 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml (620 B at 0.3 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml (839 B at 0.5 KB/sec)
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building Hibernate Validator Test Utils 5.2.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ hibernate-validator-test-utils ---
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hibernate-validator-test-utils ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ hibernate-validator-test-utils ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 11 source files to /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hibernate-validator-test-utils ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ hibernate-validator-test-utils ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.15:test (default-test) @ hibernate-validator-test-utils ---
[INFO] No tests to run.
[INFO] 
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hibernate-validator-test-utils ---
[INFO] Building jar: /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
[INFO] 
[INFO] --- maven-checkstyle-plugin:2.14:checkstyle (check-style) @ hibernate-validator-test-utils ---
[INFO] Starting audit...
Audit done.
[WARNING] Unable to locate Source XRef to link to - DISABLED
[INFO] 
[INFO] --- maven-install-plugin:2.3.1:install (default-install) @ hibernate-validator-test-utils ---
[INFO] Installing /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar to /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
[INFO] Installing /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/pom.xml to /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-SNAPSHOT.pom
[INFO] 
[INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ hibernate-validator-test-utils ---
Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml (1007 B at 1.1 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.jar
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.jar (27 KB at 13.9 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.pom
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.pom (2 KB at 1.4 KB/sec)
Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml (303 B at 0.3 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml (1007 B at 0.8 KB/sec)
Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml (303 B at 0.2 KB/sec)
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building Hibernate Validator Engine 5.2.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] 
[INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ hibernate-validator ---
[INFO] 
[INFO] --- jaxb2-maven-plugin:1.3.1:xjc (default) @ hibernate-validator ---
[INFO] No changes detected in schema or binding files, skipping source generation.
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hibernate-validator ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 13 resources
[INFO] Copying 4 resources to META-INF
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ hibernate-validator ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 367 source files to /Users/hardy/work/hibernate/git/beanvalidation/validator/engine/target/classes
An exception has occurred in the compiler (1.8.0_25). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.
java.lang.IllegalStateException: endPosTable already set
	at com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
	at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
	at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
	at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
	at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
	at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
	at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
	at com.sun.tools.javac.main.Main.compile(Main.java:523)
	at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
	at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
	at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
	at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169)
	at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:823)
	at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
	at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
	at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
	at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
	at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
	at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
	at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
	at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:483)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
	at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
	at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
	at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] An unknown compilation problem occurred
[INFO] 1 error
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] Hibernate Validator Aggregator ..................... SUCCESS [ 11.399 s]
[INFO] Hibernate Validator Test Utils ..................... SUCCESS [ 10.637 s]
[INFO] Hibernate Validator Engine ......................... FAILURE [  1.835 s]
[INFO] Hibernate Validator Engine JDK 1.8 Tests ........... SKIPPED
[INFO] Hibernate Validator Portable Extension ............. SKIPPED
[INFO] Hibernate Validator TCK Runner ..................... SKIPPED
[INFO] Hibernate Validator Wildfly Integration Tests ...... SKIPPED
[INFO] Hibernate Validator Annotation Processor ........... SKIPPED
[INFO] Hibernate Validator Performance Tests .............. SKIPPED
[INFO] Hibernate Validator OSGi Modules ................... SKIPPED
[INFO] Hibernate Validator Karaf Features ................. SKIPPED
[INFO] Hibernate Validator OSGi integration test .......... SKIPPED
[INFO] Hibernate Validator Manual ......................... SKIPPED
[INFO] Hibernate Validator Distribution ................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 24.389 s
[INFO] Finished at: 2015-04-21T10:30:39+02:00
[INFO] Final Memory: 34M/374M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on project hibernate-validator: Compilation failure
[ERROR] An unknown compilation problem occurred
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150421/01d76792/attachment-0001.bin 

From gunnar at hibernate.org  Tue Apr 21 05:12:02 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 21 Apr 2015 11:12:02 +0200
Subject: [hibernate-dev] [Validator] Build problems!?
In-Reply-To: <20150421084141.GA72503@Nineveh.lan>
References: <20150421084141.GA72503@Nineveh.lan>
Message-ID: <CADGJaX8=4wcDjsS4D=OEqDXio-Y97Y7JFxj+c-kyCjVk1Nw9XQ@mail.gmail.com>

Hi,

I cannot reproduce that issue in HV.

Could you try and run the Logging AP not via the compiler plug-in but via
the maven-annotation-plugin (
https://code.google.com/p/maven-annotation-plugin/)? E.g. like so:

    <build>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                    <encoding>UTF-8</encoding>
                    <compilerArgument>-proc:none</compilerArgument>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.bsc.maven</groupId>
                <artifactId>maven-processor-plugin</artifactId>
                <version>2.2.4</version>
                <configuration>

  <defaultOutputDirectory>${project.build.directory}/generated-sources</defaultOutputDirectory>
                    <processors>

  <processor>org.jboss.logging.processor.apt.LoggingToolsProcessor</processor>
                    </processors>
                </configuration>
                <executions>
                    <execution>
                        <id>process</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>process</goal>
                        </goals>
                    </execution>
                </executions>
                <dependencies>
                    <dependency>
                        <groupId>org.jboss.logging</groupId>
                        <artifactId>jboss-logging-processor</artifactId>
                        <version>${jboss.logging.version}</version>
                    </dependency>
                </dependencies>
            </plugin>
        </plugins>
    </build>

--Gunnar


2015-04-21 10:41 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:

> Hi,
>
> I seem to have a odd build problem and wondering whether someone could
> verify the problem
> or in any ways enlighten me regarding what's going on.
>
> I can build the Validator master branch w/o problem ('mvn clean install'),
> but a 'mvn deploy' (SNAPSHOT deploy)
> fails (output below). The funny thing is that the failure seems to occur
> during the main
> compilation task which seems odd, since the classes compile fine when
> using the 'install' target.
> It might be related to the fact that a 'deploy' enables different
> profiles/settings, but a start
> would be to figure out whether others have the same problem.
>
> -- Hardy
>
> P.S.: The Cloudbees HV-5.2-SNAPSHOT-DEPLOY job recently also fails
> erratically. It might be the same problem.
>
> >>>>
> mvn deploy
> [INFO] Scanning for projects...
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Hibernate Validator Aggregator
> [INFO] Hibernate Validator Test Utils
> [INFO] Hibernate Validator Engine
> [INFO] Hibernate Validator Engine JDK 1.8 Tests
> [INFO] Hibernate Validator Portable Extension
> [INFO] Hibernate Validator TCK Runner
> [INFO] Hibernate Validator Wildfly Integration Tests
> [INFO] Hibernate Validator Annotation Processor
> [INFO] Hibernate Validator Performance Tests
> [INFO] Hibernate Validator OSGi Modules
> [INFO] Hibernate Validator Karaf Features
> [INFO] Hibernate Validator OSGi integration test
> [INFO] Hibernate Validator Manual
> [INFO] Hibernate Validator Distribution
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Hibernate Validator Aggregator 5.2.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @
> hibernate-validator-parent ---
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> hibernate-validator-parent ---
> [INFO] Installing
> /Users/hardy/work/hibernate/git/beanvalidation/validator/pom.xml to
> /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @
> hibernate-validator-parent ---
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> Downloaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> (620 B at 0.3 KB/sec)
> Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-20150421.083018-230.pom
> Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-20150421.083018-230.pom
> (33 KB at 8.2 KB/sec)
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> Downloaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> (839 B at 0.9 KB/sec)
> Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> (620 B at 0.3 KB/sec)
> Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> (839 B at 0.5 KB/sec)
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Hibernate Validator Test Utils 5.2.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @
> hibernate-validator-test-utils ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> hibernate-validator-test-utils ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @
> hibernate-validator-test-utils ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 11 source files to
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/classes
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources
> (default-testResources) @ hibernate-validator-test-utils ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> hibernate-validator-test-utils ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> hibernate-validator-test-utils ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @
> hibernate-validator-test-utils ---
> [INFO] Building jar:
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
> [INFO]
> [INFO] --- maven-checkstyle-plugin:2.14:checkstyle (check-style) @
> hibernate-validator-test-utils ---
> [INFO] Starting audit...
> Audit done.
> [WARNING] Unable to locate Source XRef to link to - DISABLED
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> hibernate-validator-test-utils ---
> [INFO] Installing
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
> to
> /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
> [INFO] Installing
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/pom.xml
> to
> /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @
> hibernate-validator-test-utils ---
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> Downloaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> (1007 B at 1.1 KB/sec)
> Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.jar
> Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.jar
> (27 KB at 13.9 KB/sec)
> Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.pom
> Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.pom
> (2 KB at 1.4 KB/sec)
> Downloading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> Downloaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> (303 B at 0.3 KB/sec)
> Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> (1007 B at 0.8 KB/sec)
> Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> (303 B at 0.2 KB/sec)
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building Hibernate Validator Engine 5.2.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @
> hibernate-validator ---
> [INFO]
> [INFO] --- jaxb2-maven-plugin:1.3.1:xjc (default) @ hibernate-validator ---
> [INFO] No changes detected in schema or binding files, skipping source
> generation.
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> hibernate-validator ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 13 resources
> [INFO] Copying 4 resources to META-INF
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @
> hibernate-validator ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 367 source files to
> /Users/hardy/work/hibernate/git/beanvalidation/validator/engine/target/classes
> An exception has occurred in the compiler (1.8.0_25). Please file a bug at
> the Java Developer Connection (http://java.sun.com/webapps/bugreport)
> after checking the Bug Parade for duplicates. Include your program and the
> following diagnostic in your report.  Thank you.
> java.lang.IllegalStateException: endPosTable already set
>         at
> com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
>         at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
>         at
> com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
>         at
> com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
>         at
> com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892)
>         at
> com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
>         at
> com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
>         at
> com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
>         at
> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
>         at com.sun.tools.javac.main.Main.compile(Main.java:523)
>         at
> com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
>         at
> com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
>         at
> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
>         at
> org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169)
>         at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:823)
>         at
> org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
>         at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
>         at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>         at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>         at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>         at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>         at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>         at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>         at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
>         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
>         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
>         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
>         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
>         at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:483)
>         at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>         at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>         at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>         at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [INFO] -------------------------------------------------------------
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] An unknown compilation problem occurred
> [INFO] 1 error
> [INFO] -------------------------------------------------------------
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Hibernate Validator Aggregator ..................... SUCCESS [
> 11.399 s]
> [INFO] Hibernate Validator Test Utils ..................... SUCCESS [
> 10.637 s]
> [INFO] Hibernate Validator Engine ......................... FAILURE [
> 1.835 s]
> [INFO] Hibernate Validator Engine JDK 1.8 Tests ........... SKIPPED
> [INFO] Hibernate Validator Portable Extension ............. SKIPPED
> [INFO] Hibernate Validator TCK Runner ..................... SKIPPED
> [INFO] Hibernate Validator Wildfly Integration Tests ...... SKIPPED
> [INFO] Hibernate Validator Annotation Processor ........... SKIPPED
> [INFO] Hibernate Validator Performance Tests .............. SKIPPED
> [INFO] Hibernate Validator OSGi Modules ................... SKIPPED
> [INFO] Hibernate Validator Karaf Features ................. SKIPPED
> [INFO] Hibernate Validator OSGi integration test .......... SKIPPED
> [INFO] Hibernate Validator Manual ......................... SKIPPED
> [INFO] Hibernate Validator Distribution ................... SKIPPED
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 24.389 s
> [INFO] Finished at: 2015-04-21T10:30:39+02:00
> [INFO] Final Memory: 34M/374M
> [INFO]
> ------------------------------------------------------------------------
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.2:compile
> (default-compile) on project hibernate-validator: Compilation failure
> [ERROR] An unknown compilation problem occurred
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue Apr 21 05:12:08 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 21 Apr 2015 10:12:08 +0100
Subject: [hibernate-dev] [Validator] Build problems!?
In-Reply-To: <20150421084141.GA72503@Nineveh.lan>
References: <20150421084141.GA72503@Nineveh.lan>
Message-ID: <CAFm4XO2=uQU5mU7uZjjRWzpz0kX8wHY97EVgJ9JD7hvF0mWcRg@mail.gmail.com>

Interesting, an exception in the compiler?!
I'll try it too, but could you try a more up to date JDK?

On 21 April 2015 at 09:41, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> I seem to have a odd build problem and wondering whether someone could verify the problem
> or in any ways enlighten me regarding what's going on.
>
> I can build the Validator master branch w/o problem ('mvn clean install'), but a 'mvn deploy' (SNAPSHOT deploy)
> fails (output below). The funny thing is that the failure seems to occur during the main
> compilation task which seems odd, since the classes compile fine when using the 'install' target.
> It might be related to the fact that a 'deploy' enables different profiles/settings, but a start
> would be to figure out whether others have the same problem.
>
> -- Hardy
>
> P.S.: The Cloudbees HV-5.2-SNAPSHOT-DEPLOY job recently also fails erratically. It might be the same problem.
>
>>>>>
> mvn deploy
> [INFO] Scanning for projects...
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] Hibernate Validator Aggregator
> [INFO] Hibernate Validator Test Utils
> [INFO] Hibernate Validator Engine
> [INFO] Hibernate Validator Engine JDK 1.8 Tests
> [INFO] Hibernate Validator Portable Extension
> [INFO] Hibernate Validator TCK Runner
> [INFO] Hibernate Validator Wildfly Integration Tests
> [INFO] Hibernate Validator Annotation Processor
> [INFO] Hibernate Validator Performance Tests
> [INFO] Hibernate Validator OSGi Modules
> [INFO] Hibernate Validator Karaf Features
> [INFO] Hibernate Validator OSGi integration test
> [INFO] Hibernate Validator Manual
> [INFO] Hibernate Validator Distribution
> [INFO]
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Hibernate Validator Aggregator 5.2.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ hibernate-validator-parent ---
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ hibernate-validator-parent ---
> [INFO] Installing /Users/hardy/work/hibernate/git/beanvalidation/validator/pom.xml to /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ hibernate-validator-parent ---
> Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml (620 B at 0.3 KB/sec)
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-20150421.083018-230.pom
> Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-20150421.083018-230.pom (33 KB at 8.2 KB/sec)
> Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml (839 B at 0.9 KB/sec)
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml (620 B at 0.3 KB/sec)
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml (839 B at 0.5 KB/sec)
> [INFO]
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Hibernate Validator Test Utils 5.2.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ hibernate-validator-test-utils ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hibernate-validator-test-utils ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/src/main/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ hibernate-validator-test-utils ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 11 source files to /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/classes
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ hibernate-validator-test-utils ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/src/test/resources
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ hibernate-validator-test-utils ---
> [INFO] No sources to compile
> [INFO]
> [INFO] --- maven-surefire-plugin:2.15:test (default-test) @ hibernate-validator-test-utils ---
> [INFO] No tests to run.
> [INFO]
> [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ hibernate-validator-test-utils ---
> [INFO] Building jar: /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
> [INFO]
> [INFO] --- maven-checkstyle-plugin:2.14:checkstyle (check-style) @ hibernate-validator-test-utils ---
> [INFO] Starting audit...
> Audit done.
> [WARNING] Unable to locate Source XRef to link to - DISABLED
> [INFO]
> [INFO] --- maven-install-plugin:2.3.1:install (default-install) @ hibernate-validator-test-utils ---
> [INFO] Installing /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar to /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
> [INFO] Installing /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/pom.xml to /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-SNAPSHOT.pom
> [INFO]
> [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @ hibernate-validator-test-utils ---
> Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml (1007 B at 1.1 KB/sec)
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.jar
> Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.jar (27 KB at 13.9 KB/sec)
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.pom
> Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.pom (2 KB at 1.4 KB/sec)
> Downloading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> Downloaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml (303 B at 0.3 KB/sec)
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml (1007 B at 0.8 KB/sec)
> Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> Uploaded: https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml (303 B at 0.2 KB/sec)
> [INFO]
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Hibernate Validator Engine 5.2.0-SNAPSHOT
> [INFO] ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @ hibernate-validator ---
> [INFO]
> [INFO] --- jaxb2-maven-plugin:1.3.1:xjc (default) @ hibernate-validator ---
> [INFO] No changes detected in schema or binding files, skipping source generation.
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ hibernate-validator ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 13 resources
> [INFO] Copying 4 resources to META-INF
> [INFO]
> [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ hibernate-validator ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 367 source files to /Users/hardy/work/hibernate/git/beanvalidation/validator/engine/target/classes
> An exception has occurred in the compiler (1.8.0_25). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport)  after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report.  Thank you.
> java.lang.IllegalStateException: endPosTable already set
>         at com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
>         at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
>         at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
>         at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
>         at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892)
>         at com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
>         at com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
>         at com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
>         at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
>         at com.sun.tools.javac.main.Main.compile(Main.java:523)
>         at com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
>         at com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
>         at org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
>         at org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169)
>         at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:823)
>         at org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
>         at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
>         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
>         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
>         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
>         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
>         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
>         at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
>         at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
>         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
>         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
>         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
>         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
>         at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:483)
>         at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
>         at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
>         at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
>         at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [INFO] -------------------------------------------------------------
> [ERROR] COMPILATION ERROR :
> [INFO] -------------------------------------------------------------
> [ERROR] An unknown compilation problem occurred
> [INFO] 1 error
> [INFO] -------------------------------------------------------------
> [INFO] ------------------------------------------------------------------------
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Hibernate Validator Aggregator ..................... SUCCESS [ 11.399 s]
> [INFO] Hibernate Validator Test Utils ..................... SUCCESS [ 10.637 s]
> [INFO] Hibernate Validator Engine ......................... FAILURE [  1.835 s]
> [INFO] Hibernate Validator Engine JDK 1.8 Tests ........... SKIPPED
> [INFO] Hibernate Validator Portable Extension ............. SKIPPED
> [INFO] Hibernate Validator TCK Runner ..................... SKIPPED
> [INFO] Hibernate Validator Wildfly Integration Tests ...... SKIPPED
> [INFO] Hibernate Validator Annotation Processor ........... SKIPPED
> [INFO] Hibernate Validator Performance Tests .............. SKIPPED
> [INFO] Hibernate Validator OSGi Modules ................... SKIPPED
> [INFO] Hibernate Validator Karaf Features ................. SKIPPED
> [INFO] Hibernate Validator OSGi integration test .......... SKIPPED
> [INFO] Hibernate Validator Manual ......................... SKIPPED
> [INFO] Hibernate Validator Distribution ................... SKIPPED
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 24.389 s
> [INFO] Finished at: 2015-04-21T10:30:39+02:00
> [INFO] Final Memory: 34M/374M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.2:compile (default-compile) on project hibernate-validator: Compilation failure
> [ERROR] An unknown compilation problem occurred
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Tue Apr 21 05:16:33 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 21 Apr 2015 11:16:33 +0200
Subject: [hibernate-dev] [Validator] Build problems!?
In-Reply-To: <CAFm4XO2=uQU5mU7uZjjRWzpz0kX8wHY97EVgJ9JD7hvF0mWcRg@mail.gmail.com>
References: <20150421084141.GA72503@Nineveh.lan>
	<CAFm4XO2=uQU5mU7uZjjRWzpz0kX8wHY97EVgJ9JD7hvF0mWcRg@mail.gmail.com>
Message-ID: <CADGJaX_f-LeevRpYdqzo1b=2dHLgegjReAgxE_uuDi9yC6ocGQ@mail.gmail.com>

Ah, you may be running into this issue:
https://jira.codehaus.org/browse/MCOMPILER-236 ("Compilation error due to
MCOMPILER-157 in deploy phase").

Setting useIncrementalCompilation=false is named as a work-around there.
Either that or using the annotation-plugin as I described probably both
should do the trick.

2015-04-21 11:12 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Interesting, an exception in the compiler?!
> I'll try it too, but could you try a more up to date JDK?
>
> On 21 April 2015 at 09:41, Hardy Ferentschik <hardy at hibernate.org> wrote:
> > Hi,
> >
> > I seem to have a odd build problem and wondering whether someone could
> verify the problem
> > or in any ways enlighten me regarding what's going on.
> >
> > I can build the Validator master branch w/o problem ('mvn clean
> install'), but a 'mvn deploy' (SNAPSHOT deploy)
> > fails (output below). The funny thing is that the failure seems to occur
> during the main
> > compilation task which seems odd, since the classes compile fine when
> using the 'install' target.
> > It might be related to the fact that a 'deploy' enables different
> profiles/settings, but a start
> > would be to figure out whether others have the same problem.
> >
> > -- Hardy
> >
> > P.S.: The Cloudbees HV-5.2-SNAPSHOT-DEPLOY job recently also fails
> erratically. It might be the same problem.
> >
> >>>>>
> > mvn deploy
> > [INFO] Scanning for projects...
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] Reactor Build Order:
> > [INFO]
> > [INFO] Hibernate Validator Aggregator
> > [INFO] Hibernate Validator Test Utils
> > [INFO] Hibernate Validator Engine
> > [INFO] Hibernate Validator Engine JDK 1.8 Tests
> > [INFO] Hibernate Validator Portable Extension
> > [INFO] Hibernate Validator TCK Runner
> > [INFO] Hibernate Validator Wildfly Integration Tests
> > [INFO] Hibernate Validator Annotation Processor
> > [INFO] Hibernate Validator Performance Tests
> > [INFO] Hibernate Validator OSGi Modules
> > [INFO] Hibernate Validator Karaf Features
> > [INFO] Hibernate Validator OSGi integration test
> > [INFO] Hibernate Validator Manual
> > [INFO] Hibernate Validator Distribution
> > [INFO]
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] Building Hibernate Validator Aggregator 5.2.0-SNAPSHOT
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO]
> > [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @
> hibernate-validator-parent ---
> > [INFO]
> > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> hibernate-validator-parent ---
> > [INFO] Installing
> /Users/hardy/work/hibernate/git/beanvalidation/validator/pom.xml to
> /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-SNAPSHOT.pom
> > [INFO]
> > [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @
> hibernate-validator-parent ---
> > Downloading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> > Downloaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> (620 B at 0.3 KB/sec)
> > Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-20150421.083018-230.pom
> > Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/hibernate-validator-parent-5.2.0-20150421.083018-230.pom
> (33 KB at 8.2 KB/sec)
> > Downloading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> > Downloaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> (839 B at 0.9 KB/sec)
> > Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> > Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/5.2.0-SNAPSHOT/maven-metadata.xml
> (620 B at 0.3 KB/sec)
> > Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> > Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-parent/maven-metadata.xml
> (839 B at 0.5 KB/sec)
> > [INFO]
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] Building Hibernate Validator Test Utils 5.2.0-SNAPSHOT
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO]
> > [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @
> hibernate-validator-test-utils ---
> > [INFO]
> > [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> hibernate-validator-test-utils ---
> > [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > [INFO] skip non existing resourceDirectory
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/src/main/resources
> > [INFO]
> > [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @
> hibernate-validator-test-utils ---
> > [INFO] Changes detected - recompiling the module!
> > [INFO] Compiling 11 source files to
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/classes
> > [INFO]
> > [INFO] --- maven-resources-plugin:2.6:testResources
> (default-testResources) @ hibernate-validator-test-utils ---
> > [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > [INFO] skip non existing resourceDirectory
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/src/test/resources
> > [INFO]
> > [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @
> hibernate-validator-test-utils ---
> > [INFO] No sources to compile
> > [INFO]
> > [INFO] --- maven-surefire-plugin:2.15:test (default-test) @
> hibernate-validator-test-utils ---
> > [INFO] No tests to run.
> > [INFO]
> > [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @
> hibernate-validator-test-utils ---
> > [INFO] Building jar:
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
> > [INFO]
> > [INFO] --- maven-checkstyle-plugin:2.14:checkstyle (check-style) @
> hibernate-validator-test-utils ---
> > [INFO] Starting audit...
> > Audit done.
> > [WARNING] Unable to locate Source XRef to link to - DISABLED
> > [INFO]
> > [INFO] --- maven-install-plugin:2.3.1:install (default-install) @
> hibernate-validator-test-utils ---
> > [INFO] Installing
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/target/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
> to
> /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-SNAPSHOT.jar
> > [INFO] Installing
> /Users/hardy/work/hibernate/git/beanvalidation/validator/test-utils/pom.xml
> to
> /Users/hardy/tmp/m2/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-SNAPSHOT.pom
> > [INFO]
> > [INFO] --- maven-deploy-plugin:2.7:deploy (default-deploy) @
> hibernate-validator-test-utils ---
> > Downloading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> > Downloaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> (1007 B at 1.1 KB/sec)
> > Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.jar
> > Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.jar
> (27 KB at 13.9 KB/sec)
> > Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.pom
> > Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/hibernate-validator-test-utils-5.2.0-20150421.083030-5.pom
> (2 KB at 1.4 KB/sec)
> > Downloading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> > Downloaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> (303 B at 0.3 KB/sec)
> > Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> > Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/5.2.0-SNAPSHOT/maven-metadata.xml
> (1007 B at 0.8 KB/sec)
> > Uploading:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> > Uploaded:
> https://repository.jboss.org/nexus/content/repositories/snapshots/org/hibernate/hibernate-validator-test-utils/maven-metadata.xml
> (303 B at 0.2 KB/sec)
> > [INFO]
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] Building Hibernate Validator Engine 5.2.0-SNAPSHOT
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO]
> > [INFO] --- maven-enforcer-plugin:1.0.1:enforce (enforce-java) @
> hibernate-validator ---
> > [INFO]
> > [INFO] --- jaxb2-maven-plugin:1.3.1:xjc (default) @ hibernate-validator
> ---
> > [INFO] No changes detected in schema or binding files, skipping source
> generation.
> > [INFO]
> > [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> hibernate-validator ---
> > [INFO] Using 'UTF-8' encoding to copy filtered resources.
> > [INFO] Copying 13 resources
> > [INFO] Copying 4 resources to META-INF
> > [INFO]
> > [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @
> hibernate-validator ---
> > [INFO] Changes detected - recompiling the module!
> > [INFO] Compiling 367 source files to
> /Users/hardy/work/hibernate/git/beanvalidation/validator/engine/target/classes
> > An exception has occurred in the compiler (1.8.0_25). Please file a bug
> at the Java Developer Connection (http://java.sun.com/webapps/bugreport)
> after checking the Bug Parade for duplicates. Include your program and the
> following diagnostic in your report.  Thank you.
> > java.lang.IllegalStateException: endPosTable already set
> >         at
> com.sun.tools.javac.util.DiagnosticSource.setEndPosTable(DiagnosticSource.java:136)
> >         at com.sun.tools.javac.util.Log.setEndPosTable(Log.java:350)
> >         at
> com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667)
> >         at
> com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950)
> >         at
> com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.<init>(JavacProcessingEnvironment.java:892)
> >         at
> com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.next(JavacProcessingEnvironment.java:921)
> >         at
> com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1187)
> >         at
> com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170)
> >         at
> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856)
> >         at com.sun.tools.javac.main.Main.compile(Main.java:523)
> >         at
> com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129)
> >         at
> com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138)
> >         at
> org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125)
> >         at
> org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:169)
> >         at
> org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:823)
> >         at
> org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129)
> >         at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> >         at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> >         at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> >         at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> >         at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> >         at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> >         at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> >         at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> >         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> >         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> >         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> >         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> >         at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >         at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >         at java.lang.reflect.Method.invoke(Method.java:483)
> >         at
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> >         at
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> >         at
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> >         at
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> > [INFO] -------------------------------------------------------------
> > [ERROR] COMPILATION ERROR :
> > [INFO] -------------------------------------------------------------
> > [ERROR] An unknown compilation problem occurred
> > [INFO] 1 error
> > [INFO] -------------------------------------------------------------
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] Hibernate Validator Aggregator ..................... SUCCESS [
> 11.399 s]
> > [INFO] Hibernate Validator Test Utils ..................... SUCCESS [
> 10.637 s]
> > [INFO] Hibernate Validator Engine ......................... FAILURE [
> 1.835 s]
> > [INFO] Hibernate Validator Engine JDK 1.8 Tests ........... SKIPPED
> > [INFO] Hibernate Validator Portable Extension ............. SKIPPED
> > [INFO] Hibernate Validator TCK Runner ..................... SKIPPED
> > [INFO] Hibernate Validator Wildfly Integration Tests ...... SKIPPED
> > [INFO] Hibernate Validator Annotation Processor ........... SKIPPED
> > [INFO] Hibernate Validator Performance Tests .............. SKIPPED
> > [INFO] Hibernate Validator OSGi Modules ................... SKIPPED
> > [INFO] Hibernate Validator Karaf Features ................. SKIPPED
> > [INFO] Hibernate Validator OSGi integration test .......... SKIPPED
> > [INFO] Hibernate Validator Manual ......................... SKIPPED
> > [INFO] Hibernate Validator Distribution ................... SKIPPED
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] BUILD FAILURE
> > [INFO]
> ------------------------------------------------------------------------
> > [INFO] Total time: 24.389 s
> > [INFO] Finished at: 2015-04-21T10:30:39+02:00
> > [INFO] Final Memory: 34M/374M
> > [INFO]
> ------------------------------------------------------------------------
> > [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.2:compile
> (default-compile) on project hibernate-validator: Compilation failure
> > [ERROR] An unknown compilation problem occurred
> > [ERROR] -> [Help 1]
> > [ERROR]
> > [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> > [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> >
> >
> > _______________________________________________
> > 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
>

From steve at hibernate.org  Tue Apr 21 14:09:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 21 Apr 2015 13:09:53 -0500
Subject: [hibernate-dev] org.hibernate.cfg.Settings deprecated
In-Reply-To: <CAFdSV9tdWTisyc-=gnX8T-0SaOMkRNPteStJ6KVVPNCdhB=UKg@mail.gmail.com>
References: <CAFdSV9tdWTisyc-=gnX8T-0SaOMkRNPteStJ6KVVPNCdhB=UKg@mail.gmail.com>
Message-ID: <CAFdSV9uGkVuAON6m+HZaUr6EB=0+3MO3=ixCbL9oK05YWBMzbw@mail.gmail.com>

Ok, silence will be taken as a vote to do whatever I feel is best
regardless of impact on these integration impls...  So anyone?

On Thu, Apr 16, 2015 at 7:20 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Last night I pushed some changes which included deprecating
> org.hibernate.cfg.Settings in favor
> of org.hibernate.boot.spi.SessionFactoryOptions.  The main reason for this
> was to make it easier for OGM and others to hook into the SessionFactory
> creation process.  For now, I have made Settings delegate
> to SessionFactoryOptions.
>
> I am not sure if anything external relies on this Settings contract.  But
> there are a few usages I wanted to discuss.
>
> First is caching.  Part of the SPI for building RegionFactrory is passing
> along the Settings object.  Ideally I'd just swap this with
> SessionFactoryOptions.  And given that this targets a major release (5.0),
> that should be ok.  Anyone against that?  Sanne?  Galder?  Alex?
>
> Second is the initiation of BV integration.  The TypesafeActivator
> accesses the Settings object in order to
> call org.hibernate.cfg.Settings#setCheckNullability.  As of now, this is
> the only setter method I have left on Settings (it simply passes that call
> on to the SessionFactoryOptions, which exposes just this one setter for
> just this one case).  I'd like to make it so that SessionFactoryOptions is
> immutable at the time SessionFactory is built.  This was largely true for
> Settings already aside from this one use case.  I am just not sure yet of
> the best way to allow an Integrator to affect this SessionFactoryBuilder
> process.  Thoughts?
>

From hardy at hibernate.org  Tue Apr 21 14:52:46 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 21 Apr 2015 20:52:46 +0200
Subject: [hibernate-dev] org.hibernate.cfg.Settings deprecated
In-Reply-To: <CAFdSV9uGkVuAON6m+HZaUr6EB=0+3MO3=ixCbL9oK05YWBMzbw@mail.gmail.com>
References: <CAFdSV9tdWTisyc-=gnX8T-0SaOMkRNPteStJ6KVVPNCdhB=UKg@mail.gmail.com>
	<CAFdSV9uGkVuAON6m+HZaUr6EB=0+3MO3=ixCbL9oK05YWBMzbw@mail.gmail.com>
Message-ID: <20150421185246.GB44775@Nineveh.lan>

On Tue, Apr 21, 2015 at 01:09:53PM -0500, Steve Ebersole wrote:
> Ok, silence will be taken as a vote to do whatever I feel is best
> regardless of impact on these integration impls...  So anyone?

Sorry, I forgot about this one. TBH, I have not much useful to say on
what the best way to do this is. It seems to make sense to disable ORM based
null checking if Bean Validation is used (even though Emmanuel wrote this code
initially. I am not 100% which kinds of scenarios this tries to prevent. My guess
is that when this option is enabled and Bean Valdation's @NotNull
is used as well, the ORM validation kicks in first and throws some ORM specific exception
instead of the ConstraintViolationException one would expect in this case).

So whatever you come up with, I would expect some possibility for the integrator to make sure 
ORM null checking is disabled.

--Hardy 

> 
> On Thu, Apr 16, 2015 at 7:20 AM, Steve Ebersole <steve at hibernate.org> wrote:
> 
> > Last night I pushed some changes which included deprecating
> > org.hibernate.cfg.Settings in favor
> > of org.hibernate.boot.spi.SessionFactoryOptions.  The main reason for this
> > was to make it easier for OGM and others to hook into the SessionFactory
> > creation process.  For now, I have made Settings delegate
> > to SessionFactoryOptions.
> >
> > I am not sure if anything external relies on this Settings contract.  But
> > there are a few usages I wanted to discuss.
> >
> > First is caching.  Part of the SPI for building RegionFactrory is passing
> > along the Settings object.  Ideally I'd just swap this with
> > SessionFactoryOptions.  And given that this targets a major release (5.0),
> > that should be ok.  Anyone against that?  Sanne?  Galder?  Alex?
> >
> > Second is the initiation of BV integration.  The TypesafeActivator
> > accesses the Settings object in order to
> > call org.hibernate.cfg.Settings#setCheckNullability.  As of now, this is
> > the only setter method I have left on Settings (it simply passes that call
> > on to the SessionFactoryOptions, which exposes just this one setter for
> > just this one case).  I'd like to make it so that SessionFactoryOptions is
> > immutable at the time SessionFactory is built.  This was largely true for
> > Settings already aside from this one use case.  I am just not sure yet of
> > the best way to allow an Integrator to affect this SessionFactoryBuilder
> > process.  Thoughts?
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From manderse at redhat.com  Tue Apr 21 17:14:19 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Tue, 21 Apr 2015 23:14:19 +0200
Subject: [hibernate-dev] org.hibernate.cfg.Settings deprecated
In-Reply-To: <CAFdSV9uGkVuAON6m+HZaUr6EB=0+3MO3=ixCbL9oK05YWBMzbw@mail.gmail.com>
References: <CAFdSV9tdWTisyc-=gnX8T-0SaOMkRNPteStJ6KVVPNCdhB=UKg@mail.gmail.com>
	<CAFdSV9uGkVuAON6m+HZaUr6EB=0+3MO3=ixCbL9oK05YWBMzbw@mail.gmail.com>
Message-ID: <670F52B4-911A-4F20-9939-B7F38FF59553@redhat.com>

As long as we can explicitly disable things via API like we could in 
past this should be fine.

i.e. in tools we used setting properties to disable second level 
caching, hibernate validator, connection pooling, tx management and 
search setup since it just doesn't either make sense or won't work when 
trying
to load hibernate model outside an app server.

/max

> Ok, silence will be taken as a vote to do whatever I feel is best
> regardless of impact on these integration impls...  So anyone?
>
> On Thu, Apr 16, 2015 at 7:20 AM, Steve Ebersole <steve at hibernate.org> 
> wrote:
>
>> Last night I pushed some changes which included deprecating
>> org.hibernate.cfg.Settings in favor
>> of org.hibernate.boot.spi.SessionFactoryOptions.  The main reason for 
>> this
>> was to make it easier for OGM and others to hook into the 
>> SessionFactory
>> creation process.  For now, I have made Settings delegate
>> to SessionFactoryOptions.
>>
>> I am not sure if anything external relies on this Settings contract.  
>> But
>> there are a few usages I wanted to discuss.
>>
>> First is caching.  Part of the SPI for building RegionFactrory is 
>> passing
>> along the Settings object.  Ideally I'd just swap this with
>> SessionFactoryOptions.  And given that this targets a major release 
>> (5.0),
>> that should be ok.  Anyone against that?  Sanne?  Galder?  Alex?
>>
>> Second is the initiation of BV integration.  The TypesafeActivator
>> accesses the Settings object in order to
>> call org.hibernate.cfg.Settings#setCheckNullability.  As of now, this 
>> is
>> the only setter method I have left on Settings (it simply passes that 
>> call
>> on to the SessionFactoryOptions, which exposes just this one setter 
>> for
>> just this one case).  I'd like to make it so that 
>> SessionFactoryOptions is
>> immutable at the time SessionFactory is built.  This was largely true 
>> for
>> Settings already aside from this one use case.  I am just not sure 
>> yet of
>> the best way to allow an Integrator to affect this 
>> SessionFactoryBuilder
>> process.  Thoughts?
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


/max
http://about.me/maxandersen

From steve at hibernate.org  Tue Apr 21 17:20:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 21 Apr 2015 16:20:20 -0500
Subject: [hibernate-dev] org.hibernate.cfg.Settings deprecated
In-Reply-To: <670F52B4-911A-4F20-9939-B7F38FF59553@redhat.com>
References: <CAFdSV9tdWTisyc-=gnX8T-0SaOMkRNPteStJ6KVVPNCdhB=UKg@mail.gmail.com>
	<CAFdSV9uGkVuAON6m+HZaUr6EB=0+3MO3=ixCbL9oK05YWBMzbw@mail.gmail.com>
	<670F52B4-911A-4F20-9939-B7F38FF59553@redhat.com>
Message-ID: <CAFdSV9upEpP2RdZ12jzQCaFuFSbnO-aEGHdKu76wnLhUgOdQag@mail.gmail.com>

That's really more a function of bootstrapping, not the actual Settings
object.  And yes, these hibernate.properties et al are still picked up and
used.

On Tue, Apr 21, 2015 at 4:14 PM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> As long as we can explicitly disable things via API like we could in past
> this should be fine.
>
> i.e. in tools we used setting properties to disable second level caching,
> hibernate validator, connection pooling, tx management and search setup
> since it just doesn't either make sense or won't work when trying
> to load hibernate model outside an app server.
>
> /max
>
>  Ok, silence will be taken as a vote to do whatever I feel is best
>> regardless of impact on these integration impls...  So anyone?
>>
>> On Thu, Apr 16, 2015 at 7:20 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>  Last night I pushed some changes which included deprecating
>>> org.hibernate.cfg.Settings in favor
>>> of org.hibernate.boot.spi.SessionFactoryOptions.  The main reason for
>>> this
>>> was to make it easier for OGM and others to hook into the SessionFactory
>>> creation process.  For now, I have made Settings delegate
>>> to SessionFactoryOptions.
>>>
>>> I am not sure if anything external relies on this Settings contract.  But
>>> there are a few usages I wanted to discuss.
>>>
>>> First is caching.  Part of the SPI for building RegionFactrory is passing
>>> along the Settings object.  Ideally I'd just swap this with
>>> SessionFactoryOptions.  And given that this targets a major release
>>> (5.0),
>>> that should be ok.  Anyone against that?  Sanne?  Galder?  Alex?
>>>
>>> Second is the initiation of BV integration.  The TypesafeActivator
>>> accesses the Settings object in order to
>>> call org.hibernate.cfg.Settings#setCheckNullability.  As of now, this is
>>> the only setter method I have left on Settings (it simply passes that
>>> call
>>> on to the SessionFactoryOptions, which exposes just this one setter for
>>> just this one case).  I'd like to make it so that SessionFactoryOptions
>>> is
>>> immutable at the time SessionFactory is built.  This was largely true for
>>> Settings already aside from this one use case.  I am just not sure yet of
>>> the best way to allow an Integrator to affect this SessionFactoryBuilder
>>> process.  Thoughts?
>>>
>>>  _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
> /max
> http://about.me/maxandersen
>

From sanne at hibernate.org  Wed Apr 22 04:41:08 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 22 Apr 2015 09:41:08 +0100
Subject: [hibernate-dev] Hibernate Search 5 compatible with Hibernate ORM 4?
Message-ID: <CAFm4XO0dLJsF57+xjaB3Qr4a8DqOYWif0FZQCK5-6cUpmdTR+Q@mail.gmail.com>

Just a heads up: I'm not seeing the question from the subject often enough.

In fact, I only see it when I suggest to upgrade when helping some
user. It's like they are very surprised "no way, I didn't think that
was possible?!"

I think I've been hammering this information in each and every release
blog, but apparently an assumption on major versions needing to be
aligned is stronger.

I guess we should embrace that? We can upgrade a minor of Hibernate
Search to use Hibernate ORM 5 when it comes, that will fix the
alignment of planets.

Still, we also had hopes for a quick version 6 ..

Just some thoughts.

Thanks,
Sanne

From amits.84 at gmail.com  Wed Apr 22 08:06:50 2015
From: amits.84 at gmail.com (amit shah)
Date: Wed, 22 Apr 2015 17:36:50 +0530
Subject: [hibernate-dev] Multitenancy Per Schema Fails With NPE
Message-ID: <CALpK9-RatQXWSP75Mb=P60ec+5uFVi6hwxmCBaDGgY7AA8-qKg@mail.gmail.com>

I'm using schema based multi-tenancy providing implementations for both
MultiTenantConnectionProvider & CurrentTenantIdentifierResolver. Trying to
get a hibernate session for a single tenant fails with an NPE.

Looking into the source code, it seems that JDBCServicesImpl initializes
the connectionProvider to null in the else block

	private JdbcConnectionAccess buildJdbcConnectionAccess(Map configValues) {
		final MultiTenancyStrategy multiTenancyStrategy =
MultiTenancyStrategy.determineMultiTenancyStrategy( configValues );

		if ( MultiTenancyStrategy.NONE == multiTenancyStrategy ) {
			connectionProvider = serviceRegistry.getService( ConnectionProvider.class );
			return new ConnectionProviderJdbcConnectionAccess( connectionProvider );
		}
		else {
			connectionProvider = null;
			final MultiTenantConnectionProvider multiTenantConnectionProvider =
serviceRegistry.getService( MultiTenantConnectionProvider.class );
			return new MultiTenantConnectionProviderJdbcConnectionAccess(
multiTenantConnectionProvider );
		}
	}

Please find the test case attached to the mail. I have also logged an issue
<https://hibernate.atlassian.net/browse/HHH-9740>since it's blocking. Is
there something basic that I am missing.

Thanks,
Amit.

From steve at hibernate.org  Wed Apr 22 09:48:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 22 Apr 2015 08:48:44 -0500
Subject: [hibernate-dev] Multitenancy Per Schema Fails With NPE
In-Reply-To: <CALpK9-RatQXWSP75Mb=P60ec+5uFVi6hwxmCBaDGgY7AA8-qKg@mail.gmail.com>
References: <CALpK9-RatQXWSP75Mb=P60ec+5uFVi6hwxmCBaDGgY7AA8-qKg@mail.gmail.com>
Message-ID: <CAFdSV9v+=vcfWSx+wUDXgFxGODRetjCpPJdzrG9aK3HyS7HBzQ@mail.gmail.com>

1) This is a list for discussing the development of Hibernate itself, not
for discussing usage of Hibernate.  Please use the forums, StackOverflow,
or #hibernate IRC for user questions.

2) If this really leads to a NPE in *Hibernate* (not your code) trying to
open a connection, then that would be a bug.  If that is the case, please
open a Jira, and be sure to include (a) a test case and (b) the full stack
trace for the NPE.
On Apr 22, 2015 7:07 AM, "amit shah" <amits.84 at gmail.com> wrote:

> I'm using schema based multi-tenancy providing implementations for both
> MultiTenantConnectionProvider & CurrentTenantIdentifierResolver. Trying to
> get a hibernate session for a single tenant fails with an NPE.
>
> Looking into the source code, it seems that JDBCServicesImpl initializes
> the connectionProvider to null in the else block
>
>         private JdbcConnectionAccess buildJdbcConnectionAccess(Map
> configValues) {
>                 final MultiTenancyStrategy multiTenancyStrategy =
> MultiTenancyStrategy.determineMultiTenancyStrategy( configValues );
>
>                 if ( MultiTenancyStrategy.NONE == multiTenancyStrategy ) {
>                         connectionProvider = serviceRegistry.getService(
> ConnectionProvider.class );
>                         return new ConnectionProviderJdbcConnectionAccess(
> connectionProvider );
>                 }
>                 else {
>                         connectionProvider = null;
>                         final MultiTenantConnectionProvider
> multiTenantConnectionProvider =
> serviceRegistry.getService( MultiTenantConnectionProvider.class );
>                         return new
> MultiTenantConnectionProviderJdbcConnectionAccess(
> multiTenantConnectionProvider );
>                 }
>         }
>
> Please find the test case attached to the mail. I have also logged an issue
> <https://hibernate.atlassian.net/browse/HHH-9740>since it's blocking. Is
> there something basic that I am missing.
>
> Thanks,
> Amit.
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Fri Apr 24 14:53:16 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 24 Apr 2015 20:53:16 +0200
Subject: [hibernate-dev] EntityManagetFactory unwrap - HHH-9665
Message-ID: <20150424185316.GA36540@Nineveh.lan>

Hi there,

Steve and I are having a discussion around the intended behavior of EntityManagerFactory#unwrap.
See also HHH-9665[1] and the corresponding pull request [2].

At the moment the implementation in EntityManagerFactoryImpl allows to unwrap into the implementation
class itself. This way the user gets a reference to an internal class. IMO there should be instead a 
public interface which the user can unwrap to, eg HibernateEntityManagerFactory. This interface hosts 
additional methods we want to expose on top of the HibernateEntityManagerFactory. The unwrapping to 
should be disallowed (by expception) in this case. IMO this is just a continuation of the whole
idea of splitting packages between public, spi and internal. Of course this cannot stop a user from
doing an explicit cast, but that's a different story imo.

Steve and I have different take on this issue, so we where wondering what others think?

--Hardy

[1] https://hibernate.atlassian.net/browse/HHH-9665
[2] https://github.com/hibernate/hibernate-orm/pull/911
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150424/3f5404f7/attachment.bin 

From steve at hibernate.org  Fri Apr 24 15:20:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 24 Apr 2015 14:20:55 -0500
Subject: [hibernate-dev] EntityManagetFactory unwrap - HHH-9665
In-Reply-To: <20150424185316.GA36540@Nineveh.lan>
References: <20150424185316.GA36540@Nineveh.lan>
Message-ID: <CAFdSV9uDEBjkHeffovYGW=eT6A_VDOL6tR45SdGK7ac7+yoeqQ@mail.gmail.com>

Also I wanted to clarify that, as I told you on IRC, I am fine to change
this expectation if that is the general consensus as long as it is all done
by next Wednesday.  I know that sounds short notice, but in reality I have
been trying to ping you about that for weeks.

However, even given that the Pull Request is only partial:
1) it moves exposing some internal types to an API/SPI method.  IMO the
Pull Request should be complete and fix that as well.
2) there is code in ORM that casts to EntityManagerFactoryImpl in order to
access these methods, no?.  unless I missed it, you did not fix those
usages to now refer to HibernateEntityManagerFactory.

On Fri, Apr 24, 2015 at 1:53 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi there,
>
> Steve and I are having a discussion around the intended behavior of
> EntityManagerFactory#unwrap.
> See also HHH-9665[1] and the corresponding pull request [2].
>
> At the moment the implementation in EntityManagerFactoryImpl allows to
> unwrap into the implementation
> class itself. This way the user gets a reference to an internal class. IMO
> there should be instead a
> public interface which the user can unwrap to, eg
> HibernateEntityManagerFactory. This interface hosts
> additional methods we want to expose on top of the
> HibernateEntityManagerFactory. The unwrapping to
> should be disallowed (by expception) in this case. IMO this is just a
> continuation of the whole
> idea of splitting packages between public, spi and internal. Of course
> this cannot stop a user from
> doing an explicit cast, but that's a different story imo.
>
> Steve and I have different take on this issue, so we where wondering what
> others think?
>
> --Hardy
>
> [1] https://hibernate.atlassian.net/browse/HHH-9665
> [2] https://github.com/hibernate/hibernate-orm/pull/911
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Fri Apr 24 16:00:25 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 24 Apr 2015 22:00:25 +0200
Subject: [hibernate-dev] EntityManagetFactory unwrap - HHH-9665
In-Reply-To: <CAFdSV9uDEBjkHeffovYGW=eT6A_VDOL6tR45SdGK7ac7+yoeqQ@mail.gmail.com>
References: <20150424185316.GA36540@Nineveh.lan>
	<CAFdSV9uDEBjkHeffovYGW=eT6A_VDOL6tR45SdGK7ac7+yoeqQ@mail.gmail.com>
Message-ID: <20150424200025.GC36540@Nineveh.lan>

On Fri, Apr 24, 2015 at 02:20:55PM -0500, Steve Ebersole wrote:
> Also I wanted to clarify that, as I told you on IRC, I am fine to change
> this expectation if that is the general consensus as long as it is all done
> by next Wednesday. 

Sure, I got that. 

> I know that sounds short notice, but in reality I have
> been trying to ping you about that for weeks.

My wrong, I missed that.

> However, even given that the Pull Request is only partial:
> 1) it moves exposing some internal types to an API/SPI method.  IMO the
> Pull Request should be complete and fix that as well.

On second thought, I think it was a mistake to move the methods which expose 
internal types into the interface. I had a wrong thinking about backwards compatibility
in mind. However, since the methods are anyways still in the EntityManagerFactoryImpl
we can just say that if you need to use these methods you need a cast. This way
you get a "clean" interface for HibernateEntityManagerFactory. WDYT?

> 2) there is code in ORM that casts to EntityManagerFactoryImpl in order to
> access these methods, no?.  unless I missed it, you did not fix those
> usages to now refer to HibernateEntityManagerFactory.

I guess in ORM code it is also ok to cast, no? However I could have a look at
clean up the ones where it would make sense to unwrap.

--Hardy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20150424/df8a09a6/attachment.bin 

From Josiah.Haswell at ca.com  Fri Apr 24 21:00:07 2015
From: Josiah.Haswell at ca.com (Haswell, Josiah D)
Date: Sat, 25 Apr 2015 01:00:07 +0000
Subject: [hibernate-dev] Datomic OGM implementation
Message-ID: <c2c3e5764d5345ab86e0b5d9269c76e8@uslims213.ca.com>

Hi folks,

How can I begin to submit a new grid dialect to the project?  I'm most of the way through implementing a dialect for Datomic<http://www.datomic.com/>, and am most of the way through the approval process to submit it back to the community.  I've had to make some (pretty minor) changes to
Hibernate-ogm-core that I'd like feedback on, as well.  Do I just submit a pull request?

Thanks!

Josiah Haswell

From amits.84 at gmail.com  Mon Apr 27 01:35:42 2015
From: amits.84 at gmail.com (amit shah)
Date: Mon, 27 Apr 2015 11:05:42 +0530
Subject: [hibernate-dev] Multitenancy Per Schema Fails With NPE
In-Reply-To: <CAFdSV9v+=vcfWSx+wUDXgFxGODRetjCpPJdzrG9aK3HyS7HBzQ@mail.gmail.com>
References: <CALpK9-RatQXWSP75Mb=P60ec+5uFVi6hwxmCBaDGgY7AA8-qKg@mail.gmail.com>
	<CAFdSV9v+=vcfWSx+wUDXgFxGODRetjCpPJdzrG9aK3HyS7HBzQ@mail.gmail.com>
Message-ID: <CALpK9-SOatR2S1c=LgsELruGcxCbUXkD+v31zpbeJLz0CLY=fQ@mail.gmail.com>

I did log a blocker issue <https://hibernate.atlassian.net/browse/HHH-9740>on
jira but to get a quick response I posted the issue here again.
I do not see any traction on the jira issue, neither did stackoverflow or
the IRC chat help out.
Any help would be appreciated.

Thanks !

On Wed, Apr 22, 2015 at 7:18 PM, Steve Ebersole <steve at hibernate.org> wrote:

> 1) This is a list for discussing the development of Hibernate itself, not
> for discussing usage of Hibernate.  Please use the forums, StackOverflow,
> or #hibernate IRC for user questions.
>
> 2) If this really leads to a NPE in *Hibernate* (not your code) trying to
> open a connection, then that would be a bug.  If that is the case, please
> open a Jira, and be sure to include (a) a test case and (b) the full stack
> trace for the NPE.
> On Apr 22, 2015 7:07 AM, "amit shah" <amits.84 at gmail.com> wrote:
>
>> I'm using schema based multi-tenancy providing implementations for both
>> MultiTenantConnectionProvider & CurrentTenantIdentifierResolver. Trying to
>> get a hibernate session for a single tenant fails with an NPE.
>>
>> Looking into the source code, it seems that JDBCServicesImpl initializes
>> the connectionProvider to null in the else block
>>
>>         private JdbcConnectionAccess buildJdbcConnectionAccess(Map
>> configValues) {
>>                 final MultiTenancyStrategy multiTenancyStrategy =
>> MultiTenancyStrategy.determineMultiTenancyStrategy( configValues );
>>
>>                 if ( MultiTenancyStrategy.NONE == multiTenancyStrategy ) {
>>                         connectionProvider = serviceRegistry.getService(
>> ConnectionProvider.class );
>>                         return new
>> ConnectionProviderJdbcConnectionAccess( connectionProvider );
>>                 }
>>                 else {
>>                         connectionProvider = null;
>>                         final MultiTenantConnectionProvider
>> multiTenantConnectionProvider =
>> serviceRegistry.getService( MultiTenantConnectionProvider.class );
>>                         return new
>> MultiTenantConnectionProviderJdbcConnectionAccess(
>> multiTenantConnectionProvider );
>>                 }
>>         }
>>
>> Please find the test case attached to the mail. I have also logged an
>> issue
>> <https://hibernate.atlassian.net/browse/HHH-9740>since it's blocking. Is
>> there something basic that I am missing.
>>
>> Thanks,
>> Amit.
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From davide at hibernate.org  Mon Apr 27 06:07:10 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Mon, 27 Apr 2015 11:07:10 +0100
Subject: [hibernate-dev] Datomic OGM implementation
In-Reply-To: <c2c3e5764d5345ab86e0b5d9269c76e8@uslims213.ca.com>
References: <c2c3e5764d5345ab86e0b5d9269c76e8@uslims213.ca.com>
Message-ID: <CANoTJYMqScO=S-V0tMacyDO2hLziMESrc7YiPEvFgBroLt+Zvw@mail.gmail.com>

Hi Josiah,
thank you very much, that looks like great news.

Usually before changing the existing  modules we discuss the requirements
on this mailing list, on the JIRA or on the forum.

Sending a pull request with the description of the problem is probably the
fastest way to have feedback, just keep the amount of changes to a minimum
so that it's easier for the reviewer to understand what's going on.

Cheers,
Davide

On Sat, Apr 25, 2015 at 2:00 AM, Haswell, Josiah D <Josiah.Haswell at ca.com>
wrote:

> Hi folks,
>
> How can I begin to submit a new grid dialect to the project?  I'm most of
> the way through implementing a dialect for Datomic<http://www.datomic.com/>,
> and am most of the way through the approval process to submit it back to
> the community.  I've had to make some (pretty minor) changes to
> Hibernate-ogm-core that I'd like feedback on, as well.  Do I just submit a
> pull request?
>
> Thanks!
>
> Josiah Haswell
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Apr 27 06:59:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 27 Apr 2015 05:59:09 -0500
Subject: [hibernate-dev] Multitenancy Per Schema Fails With NPE
In-Reply-To: <CALpK9-SOatR2S1c=LgsELruGcxCbUXkD+v31zpbeJLz0CLY=fQ@mail.gmail.com>
References: <CALpK9-RatQXWSP75Mb=P60ec+5uFVi6hwxmCBaDGgY7AA8-qKg@mail.gmail.com>
	<CAFdSV9v+=vcfWSx+wUDXgFxGODRetjCpPJdzrG9aK3HyS7HBzQ@mail.gmail.com>
	<CALpK9-SOatR2S1c=LgsELruGcxCbUXkD+v31zpbeJLz0CLY=fQ@mail.gmail.com>
Message-ID: <CAFdSV9ugVs3EEB4nXkn5TO3CwaNhDU297pwTbPiaVx9pi1P0eA@mail.gmail.com>

You are trying to use auto schema validation.  That is not yet supported
for multi-tenancy.  None of the auto schema tools are.  If you need to run
any of the schema tools, you will need to do so manually.

On Mon, Apr 27, 2015 at 12:35 AM, amit shah <amits.84 at gmail.com> wrote:

> I did log a blocker issue
> <https://hibernate.atlassian.net/browse/HHH-9740>on jira but to get a
> quick response I posted the issue here again.
> I do not see any traction on the jira issue, neither did stackoverflow or
> the IRC chat help out.
> Any help would be appreciated.
>
> Thanks !
>
> On Wed, Apr 22, 2015 at 7:18 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> 1) This is a list for discussing the development of Hibernate itself, not
>> for discussing usage of Hibernate.  Please use the forums, StackOverflow,
>> or #hibernate IRC for user questions.
>>
>> 2) If this really leads to a NPE in *Hibernate* (not your code) trying to
>> open a connection, then that would be a bug.  If that is the case, please
>> open a Jira, and be sure to include (a) a test case and (b) the full stack
>> trace for the NPE.
>> On Apr 22, 2015 7:07 AM, "amit shah" <amits.84 at gmail.com> wrote:
>>
>>> I'm using schema based multi-tenancy providing implementations for both
>>> MultiTenantConnectionProvider & CurrentTenantIdentifierResolver. Trying
>>> to
>>> get a hibernate session for a single tenant fails with an NPE.
>>>
>>> Looking into the source code, it seems that JDBCServicesImpl initializes
>>> the connectionProvider to null in the else block
>>>
>>>         private JdbcConnectionAccess buildJdbcConnectionAccess(Map
>>> configValues) {
>>>                 final MultiTenancyStrategy multiTenancyStrategy =
>>> MultiTenancyStrategy.determineMultiTenancyStrategy( configValues );
>>>
>>>                 if ( MultiTenancyStrategy.NONE == multiTenancyStrategy )
>>> {
>>>                         connectionProvider = serviceRegistry.getService(
>>> ConnectionProvider.class );
>>>                         return new
>>> ConnectionProviderJdbcConnectionAccess( connectionProvider );
>>>                 }
>>>                 else {
>>>                         connectionProvider = null;
>>>                         final MultiTenantConnectionProvider
>>> multiTenantConnectionProvider =
>>> serviceRegistry.getService( MultiTenantConnectionProvider.class );
>>>                         return new
>>> MultiTenantConnectionProviderJdbcConnectionAccess(
>>> multiTenantConnectionProvider );
>>>                 }
>>>         }
>>>
>>> Please find the test case attached to the mail. I have also logged an
>>> issue
>>> <https://hibernate.atlassian.net/browse/HHH-9740>since it's blocking. Is
>>> there something basic that I am missing.
>>>
>>> Thanks,
>>> Amit.
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>

From Josiah.Haswell at ca.com  Mon Apr 27 15:38:34 2015
From: Josiah.Haswell at ca.com (Haswell, Josiah D)
Date: Mon, 27 Apr 2015 19:38:34 +0000
Subject: [hibernate-dev] Quick question about PostCommitInsertEventListener
Message-ID: <61a18eec7982440caee3d53a120e4dd6@uslims213.ca.com>

Hi folks,


In Datomic, when you create an entity, you must give the entity a temporary ID before you insert it.  After the transaction completes, each entity in the transaction is given an actual persistence ID back from the database.  My initial approach was to generate the temporary identifier in the createTuple method of the IdentityColumnAwareGridDialect, and provide a customer persister implementation to handle it.  It occurred to me that it might be easier to just use a listener.  After a bit of fiddling around, I discovered that PostCommitInsertEventListener can (apparently) substitute out the ID at what appears to be the correct location.  From what I can tell, this both simplifies the code, and the generated ID seems to be propagated to everything correctly.  Is the custom persister the preferred way to do this?  Or should this work?  Is there a better place to perform that substitution?

Thanks!

Josiah



From sanne at hibernate.org  Tue Apr 28 06:49:31 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 28 Apr 2015 11:49:31 +0100
Subject: [hibernate-dev] EntityManagetFactory unwrap - HHH-9665
In-Reply-To: <20150424200025.GC36540@Nineveh.lan>
References: <20150424185316.GA36540@Nineveh.lan>
	<CAFdSV9uDEBjkHeffovYGW=eT6A_VDOL6tR45SdGK7ac7+yoeqQ@mail.gmail.com>
	<20150424200025.GC36540@Nineveh.lan>
Message-ID: <CAFm4XO3X1Yg_-g+OWkKiwGCYwJEkQd8796-c2RtVMRBrROZcrg@mail.gmail.com>

I don't feel the need to be over protective on what the user can do.
Some people know what they are doing, everyone else should stay away
from "unwrap".

Sanne

On 24 April 2015 at 21:00, Hardy Ferentschik <hardy at hibernate.org> wrote:
> On Fri, Apr 24, 2015 at 02:20:55PM -0500, Steve Ebersole wrote:
>> Also I wanted to clarify that, as I told you on IRC, I am fine to change
>> this expectation if that is the general consensus as long as it is all done
>> by next Wednesday.
>
> Sure, I got that.
>
>> I know that sounds short notice, but in reality I have
>> been trying to ping you about that for weeks.
>
> My wrong, I missed that.
>
>> However, even given that the Pull Request is only partial:
>> 1) it moves exposing some internal types to an API/SPI method.  IMO the
>> Pull Request should be complete and fix that as well.
>
> On second thought, I think it was a mistake to move the methods which expose
> internal types into the interface. I had a wrong thinking about backwards compatibility
> in mind. However, since the methods are anyways still in the EntityManagerFactoryImpl
> we can just say that if you need to use these methods you need a cast. This way
> you get a "clean" interface for HibernateEntityManagerFactory. WDYT?
>
>> 2) there is code in ORM that casts to EntityManagerFactoryImpl in order to
>> access these methods, no?.  unless I missed it, you did not fix those
>> usages to now refer to HibernateEntityManagerFactory.
>
> I guess in ORM code it is also ok to cast, no? However I could have a look at
> clean up the ones where it would make sense to unwrap.
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From emmanuel at hibernate.org  Tue Apr 28 10:32:00 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 28 Apr 2015 16:32:00 +0200
Subject: [hibernate-dev] [OGM] Sprint organisation meeting
Message-ID: <B9BFC78C-FB66-4C23-910E-382299E80ED0@hibernate.org>

We did discuss the next 3 weeks of work:

ORM 5 compatibility for OGM and Search in alpha stage

More query
User feedback around MongoDB
Cassandra
?
Emmanuel to send the ordered list of issues to work on soon.

Meeting ended Tue Apr 28 14:26:46 2015 UTC.
Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-04-28-13.01.html
Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-04-28-13.01.txt
Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2015/hibernate-dev.2015-04-28-13.01.log.html

From steve at hibernate.org  Tue Apr 28 11:51:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Apr 2015 10:51:23 -0500
Subject: [hibernate-dev] org.hibernate.cfg.Settings deprecated
In-Reply-To: <20150421185246.GB44775@Nineveh.lan>
References: <CAFdSV9tdWTisyc-=gnX8T-0SaOMkRNPteStJ6KVVPNCdhB=UKg@mail.gmail.com>
	<CAFdSV9uGkVuAON6m+HZaUr6EB=0+3MO3=ixCbL9oK05YWBMzbw@mail.gmail.com>
	<20150421185246.GB44775@Nineveh.lan>
Message-ID: <CAFdSV9tkXwEuzbimfxrQ=GOL-UNbckBVnxgiPhMaFeZkM5oMhg@mail.gmail.com>

Har

On Tue, Apr 21, 2015 at 1:52 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> On Tue, Apr 21, 2015 at 01:09:53PM -0500, Steve Ebersole wrote:
> > Ok, silence will be taken as a vote to do whatever I feel is best
> > regardless of impact on these integration impls...  So anyone?
>
> Sorry, I forgot about this one. TBH, I have not much useful to say on
> what the best way to do this is. It seems to make sense to disable ORM
> based
> null checking if Bean Validation is used (even though Emmanuel wrote this
> code
> initially. I am not 100% which kinds of scenarios this tries to prevent.
> My guess
> is that when this option is enabled and Bean Valdation's @NotNull
> is used as well, the ORM validation kicks in first and throws some ORM
> specific exception
> instead of the ConstraintViolationException one would expect in this case).
>
> So whatever you come up with, I would expect some possibility for the
> integrator to make sure
> ORM null checking is disabled.
>
> --Hardy
>
> >
> > On Thu, Apr 16, 2015 at 7:20 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> > > Last night I pushed some changes which included deprecating
> > > org.hibernate.cfg.Settings in favor
> > > of org.hibernate.boot.spi.SessionFactoryOptions.  The main reason for
> this
> > > was to make it easier for OGM and others to hook into the
> SessionFactory
> > > creation process.  For now, I have made Settings delegate
> > > to SessionFactoryOptions.
> > >
> > > I am not sure if anything external relies on this Settings contract.
> But
> > > there are a few usages I wanted to discuss.
> > >
> > > First is caching.  Part of the SPI for building RegionFactrory is
> passing
> > > along the Settings object.  Ideally I'd just swap this with
> > > SessionFactoryOptions.  And given that this targets a major release
> (5.0),
> > > that should be ok.  Anyone against that?  Sanne?  Galder?  Alex?
> > >
> > > Second is the initiation of BV integration.  The TypesafeActivator
> > > accesses the Settings object in order to
> > > call org.hibernate.cfg.Settings#setCheckNullability.  As of now, this
> is
> > > the only setter method I have left on Settings (it simply passes that
> call
> > > on to the SessionFactoryOptions, which exposes just this one setter for
> > > just this one case).  I'd like to make it so that
> SessionFactoryOptions is
> > > immutable at the time SessionFactory is built.  This was largely true
> for
> > > Settings already aside from this one use case.  I am just not sure yet
> of
> > > the best way to allow an Integrator to affect this
> SessionFactoryBuilder
> > > process.  Thoughts?
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Apr 28 11:56:24 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Apr 2015 10:56:24 -0500
Subject: [hibernate-dev] org.hibernate.cfg.Settings deprecated
In-Reply-To: <20150421185246.GB44775@Nineveh.lan>
References: <CAFdSV9tdWTisyc-=gnX8T-0SaOMkRNPteStJ6KVVPNCdhB=UKg@mail.gmail.com>
	<CAFdSV9uGkVuAON6m+HZaUr6EB=0+3MO3=ixCbL9oK05YWBMzbw@mail.gmail.com>
	<20150421185246.GB44775@Nineveh.lan>
Message-ID: <CAFdSV9vHVBiLz+8AE9W=hgQ_qyJdy_4SWwvdrJnC4qT3Lq9XYg@mail.gmail.com>

Hardy,

Settings still has that method.  I also had to expose that from
SessionFactoryOptions, and Settings delegates to that.

Long term, I am not sure.  Obviously I dislike the setters here.  Maybe a
good case for adding a SessionFactoryBuilderInitializer (along the lines of
MetadataBuilderInitializer).  We would have a
SessionFactoryBuilderInitializer for trhe validator integration that would
initialize this setting based on whatever it bases calling the setter now.
Users would still be able to override that directly via the
SessionFactoryBuilder.


On Tue, Apr 21, 2015 at 1:52 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> On Tue, Apr 21, 2015 at 01:09:53PM -0500, Steve Ebersole wrote:
> > Ok, silence will be taken as a vote to do whatever I feel is best
> > regardless of impact on these integration impls...  So anyone?
>
> Sorry, I forgot about this one. TBH, I have not much useful to say on
> what the best way to do this is. It seems to make sense to disable ORM
> based
> null checking if Bean Validation is used (even though Emmanuel wrote this
> code
> initially. I am not 100% which kinds of scenarios this tries to prevent.
> My guess
> is that when this option is enabled and Bean Valdation's @NotNull
> is used as well, the ORM validation kicks in first and throws some ORM
> specific exception
> instead of the ConstraintViolationException one would expect in this case).
>
> So whatever you come up with, I would expect some possibility for the
> integrator to make sure
> ORM null checking is disabled.
>
> --Hardy
>
> >
> > On Thu, Apr 16, 2015 at 7:20 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> > > Last night I pushed some changes which included deprecating
> > > org.hibernate.cfg.Settings in favor
> > > of org.hibernate.boot.spi.SessionFactoryOptions.  The main reason for
> this
> > > was to make it easier for OGM and others to hook into the
> SessionFactory
> > > creation process.  For now, I have made Settings delegate
> > > to SessionFactoryOptions.
> > >
> > > I am not sure if anything external relies on this Settings contract.
> But
> > > there are a few usages I wanted to discuss.
> > >
> > > First is caching.  Part of the SPI for building RegionFactrory is
> passing
> > > along the Settings object.  Ideally I'd just swap this with
> > > SessionFactoryOptions.  And given that this targets a major release
> (5.0),
> > > that should be ok.  Anyone against that?  Sanne?  Galder?  Alex?
> > >
> > > Second is the initiation of BV integration.  The TypesafeActivator
> > > accesses the Settings object in order to
> > > call org.hibernate.cfg.Settings#setCheckNullability.  As of now, this
> is
> > > the only setter method I have left on Settings (it simply passes that
> call
> > > on to the SessionFactoryOptions, which exposes just this one setter for
> > > just this one case).  I'd like to make it so that
> SessionFactoryOptions is
> > > immutable at the time SessionFactory is built.  This was largely true
> for
> > > Settings already aside from this one use case.  I am just not sure yet
> of
> > > the best way to allow an Integrator to affect this
> SessionFactoryBuilder
> > > process.  Thoughts?
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Tue Apr 28 12:04:23 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 28 Apr 2015 18:04:23 +0200
Subject: [hibernate-dev] Quick question about
	PostCommitInsertEventListener
In-Reply-To: <61a18eec7982440caee3d53a120e4dd6@uslims213.ca.com>
References: <61a18eec7982440caee3d53a120e4dd6@uslims213.ca.com>
Message-ID: <51F9A315-04BA-4A4C-891B-3609CADDB965@hibernate.org>

Hi,

I think a post-commit-insert event listener would be the best for you from what I have looked at.

Emmanuel

> On 27 Apr 2015, at 21:38, Haswell, Josiah D <Josiah.Haswell at ca.com> wrote:
> 
> Hi folks,
> 
> 
> In Datomic, when you create an entity, you must give the entity a temporary ID before you insert it.  After the transaction completes, each entity in the transaction is given an actual persistence ID back from the database.  My initial approach was to generate the temporary identifier in the createTuple method of the IdentityColumnAwareGridDialect, and provide a customer persister implementation to handle it.  It occurred to me that it might be easier to just use a listener.  After a bit of fiddling around, I discovered that PostCommitInsertEventListener can (apparently) substitute out the ID at what appears to be the correct location.  From what I can tell, this both simplifies the code, and the generated ID seems to be propagated to everything correctly.  Is the custom persister the preferred way to do this?  Or should this work?  Is there a better place to perform that substitution?
> 
> Thanks!
> 
> Josiah
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From emmanuel at hibernate.org  Tue Apr 28 12:06:20 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 28 Apr 2015 18:06:20 +0200
Subject: [hibernate-dev] org.hibernate.cfg.Settings deprecated
In-Reply-To: <20150421185246.GB44775@Nineveh.lan>
References: <CAFdSV9tdWTisyc-=gnX8T-0SaOMkRNPteStJ6KVVPNCdhB=UKg@mail.gmail.com>
	<CAFdSV9uGkVuAON6m+HZaUr6EB=0+3MO3=ixCbL9oK05YWBMzbw@mail.gmail.com>
	<20150421185246.GB44775@Nineveh.lan>
Message-ID: <414A871F-9F17-416C-84BB-083E090AD8EF@hibernate.org>


> On 21 Apr 2015, at 20:52, Hardy Ferentschik <hardy at hibernate.org> wrote:
> 
>  My guess
> is that when this option is enabled and Bean Valdation's @NotNull
> is used as well, the ORM validation kicks in first and throws some ORM specific exception
> instead of the ConstraintViolationException one would expect in this case).

Correct.

From emmanuel at hibernate.org  Tue Apr 28 12:10:45 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 28 Apr 2015 18:10:45 +0200
Subject: [hibernate-dev] Datomic OGM implementation
In-Reply-To: <c2c3e5764d5345ab86e0b5d9269c76e8@uslims213.ca.com>
References: <c2c3e5764d5345ab86e0b5d9269c76e8@uslims213.ca.com>
Message-ID: <8F134015-E750-4A39-AC11-6CCB9C9154BF@hibernate.org>

Nice :)

Also there is a bit of paperwork, can you:
- create a jboss.org user account
- log in
- go to cla.jboss.org and accept the Hibernate contributor agreement

This is very similar to the Apache CLA which makes sure that your code is really from you and not someone else?s. Ping me when you have done it, I need to get some button clicked.

Emmanuel

> On 25 Apr 2015, at 03:00, Haswell, Josiah D <Josiah.Haswell at ca.com> wrote:
> 
> Hi folks,
> 
> How can I begin to submit a new grid dialect to the project?  I'm most of the way through implementing a dialect for Datomic<http://www.datomic.com/>, and am most of the way through the approval process to submit it back to the community.  I've had to make some (pretty minor) changes to
> Hibernate-ogm-core that I'd like feedback on, as well.  Do I just submit a pull request?
> 
> Thanks!
> 
> Josiah Haswell
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From gunnar at hibernate.org  Tue Apr 28 16:53:16 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 28 Apr 2015 22:53:16 +0200
Subject: [hibernate-dev] Changes around transaction -> changed exception
	behavior
Message-ID: <CADGJaX89h4988K3SjMqZ0kMA57RH=Jf_VVma2yot1a4k4u7EUQ@mail.gmail.com>

 Hi,

while working on making OGM work with ORM 5, I noticed a slightly different
behaviour wrt. to exceptions occurring during flushes.

Previously, such exceptions would bubble up as is, whereas now the
beforeTransactionCompletion() logic is called in a try/catch block,
wrapping any exceptions in a TransactionException. It's no big deal for me
(I just need to adapt some tests in our suite which expect specific
exception types), but then I was wondering whether that change poses a
migration issue for existing client code, e.g.
expecting/handling StaleObjectStateException which would need to be adapted
accordingly?

Anyone thinking it's a problem?

Thanks,

--Gunnar

From steve at hibernate.org  Tue Apr 28 17:26:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 28 Apr 2015 16:26:31 -0500
Subject: [hibernate-dev] Changes around transaction -> changed exception
	behavior
In-Reply-To: <CADGJaX89h4988K3SjMqZ0kMA57RH=Jf_VVma2yot1a4k4u7EUQ@mail.gmail.com>
References: <CADGJaX89h4988K3SjMqZ0kMA57RH=Jf_VVma2yot1a4k4u7EUQ@mail.gmail.com>
Message-ID: <CAFdSV9tJuzm3n-HF2LYH86Oe=Ee08eKfmHzdMz57rEBZ82+Z0A@mail.gmail.com>

Where does that wrapping happen?

On Tue, Apr 28, 2015 at 3:53 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

>  Hi,
>
> while working on making OGM work with ORM 5, I noticed a slightly different
> behaviour wrt. to exceptions occurring during flushes.
>
> Previously, such exceptions would bubble up as is, whereas now the
> beforeTransactionCompletion() logic is called in a try/catch block,
> wrapping any exceptions in a TransactionException. It's no big deal for me
> (I just need to adapt some tests in our suite which expect specific
> exception types), but then I was wondering whether that change poses a
> migration issue for existing client code, e.g.
> expecting/handling StaleObjectStateException which would need to be adapted
> accordingly?
>
> Anyone thinking it's a problem?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue Apr 28 17:32:57 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 28 Apr 2015 23:32:57 +0200
Subject: [hibernate-dev] Changes around transaction -> changed exception
	behavior
In-Reply-To: <CAFdSV9tJuzm3n-HF2LYH86Oe=Ee08eKfmHzdMz57rEBZ82+Z0A@mail.gmail.com>
References: <CADGJaX89h4988K3SjMqZ0kMA57RH=Jf_VVma2yot1a4k4u7EUQ@mail.gmail.com>
	<CAFdSV9tJuzm3n-HF2LYH86Oe=Ee08eKfmHzdMz57rEBZ82+Z0A@mail.gmail.com>
Message-ID: <CADGJaX_LtaTFV2f3oKuQ4e5-iigrLZMC+SYWtgPzU7HWg89W5Q@mail.gmail.com>

TransactionImpl#commit(); The before-completion code is now invoked through
transactionDriverControl.commit(); whereas previously this happened out of
a try/catch block.

2015-04-28 23:26 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Where does that wrapping happen?
>
> On Tue, Apr 28, 2015 at 3:53 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>>  Hi,
>>
>> while working on making OGM work with ORM 5, I noticed a slightly
>> different
>> behaviour wrt. to exceptions occurring during flushes.
>>
>> Previously, such exceptions would bubble up as is, whereas now the
>> beforeTransactionCompletion() logic is called in a try/catch block,
>> wrapping any exceptions in a TransactionException. It's no big deal for me
>> (I just need to adapt some tests in our suite which expect specific
>> exception types), but then I was wondering whether that change poses a
>> migration issue for existing client code, e.g.
>> expecting/handling StaleObjectStateException which would need to be
>> adapted
>> accordingly?
>>
>> Anyone thinking it's a problem?
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From emmanuel at hibernate.org  Wed Apr 29 05:07:25 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 29 Apr 2015 11:07:25 +0200
Subject: [hibernate-dev] Hibernate Search 5 compatible with Hibernate
	ORM 4?
In-Reply-To: <CAFm4XO0dLJsF57+xjaB3Qr4a8DqOYWif0FZQCK5-6cUpmdTR+Q@mail.gmail.com>
References: <CAFm4XO0dLJsF57+xjaB3Qr4a8DqOYWif0FZQCK5-6cUpmdTR+Q@mail.gmail.com>
Message-ID: <3B4B5EEA-00C1-4DF0-A71A-76E8309D0E29@hibernate.org>

I liked and still do like the planet alignment to make the major a platform signal. But when we discussed it, you all were against me.

> On 22 Apr 2015, at 10:41, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Just a heads up: I'm not seeing the question from the subject often enough.
> 
> In fact, I only see it when I suggest to upgrade when helping some
> user. It's like they are very surprised "no way, I didn't think that
> was possible?!"
> 
> I think I've been hammering this information in each and every release
> blog, but apparently an assumption on major versions needing to be
> aligned is stronger.
> 
> I guess we should embrace that? We can upgrade a minor of Hibernate
> Search to use Hibernate ORM 5 when it comes, that will fix the
> alignment of planets.
> 
> Still, we also had hopes for a quick version 6 ..
> 
> Just some thoughts.
> 
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From emmanuel at hibernate.org  Wed Apr 29 05:14:53 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 29 Apr 2015 11:14:53 +0200
Subject: [hibernate-dev] Any change of adding generics to Hibernate
	specific API
In-Reply-To: <227323507.3861546.1429129650656.JavaMail.yahoo@mail.yahoo.com>
References: <227323507.3861546.1429129650656.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <B795FDE4-48C0-4C76-A39C-388C017F8013@hibernate.org>

Hi Vlad,

That?s an interesting proposal. It is certainly possible. But since the Session and Query API (Hibernate native) is historically non typed, I wonder if that is worth introducing these new typed version and add more overloaded methods on Session.
Do you think it is worth the additional complexity?

Steve, do you have some plan for a Session API revamp some time in the future? Some spring cleaning of sort.

Emmanuel


> On 15 Apr 2015, at 22:27, Mihalcea Vlad <mih_vlad at yahoo.com> wrote:
> 
> Hi,
> Although many rely on the Java Persistence API, Hibernate still offers specific features, like mapping a native SQLQuery result set to a DTO:
> .setResultTransformer(Transformers.aliasToBean(DTO.class));
> Is it possible to add TypedQuery and TypedSQLQuery, analogous to the JPA specs, so you can use generics with specific API?
> Adding new interfaces and some overloaded Session methods wouldn't break backward compatibility.
> 
> Vlad MiIhalcea
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From sanne at hibernate.org  Wed Apr 29 06:42:12 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Apr 2015 11:42:12 +0100
Subject: [hibernate-dev] Hibernate Search 5 compatible with Hibernate
	ORM 4?
In-Reply-To: <3B4B5EEA-00C1-4DF0-A71A-76E8309D0E29@hibernate.org>
References: <CAFm4XO0dLJsF57+xjaB3Qr4a8DqOYWif0FZQCK5-6cUpmdTR+Q@mail.gmail.com>
	<3B4B5EEA-00C1-4DF0-A71A-76E8309D0E29@hibernate.org>
Message-ID: <CAFm4XO2_+cj5hjWQqU1gDFCW-Lq9Rhb3S9MhiYtCd8QwN032mQ@mail.gmail.com>

Ok so we have all been wrong, but also we couldn't wait.
Looking forward, does this mean you'd prefer to upgrade to ORM 5 in a
minor version of Hibernate Search?

Sanne

On 29 April 2015 at 10:07, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> I liked and still do like the planet alignment to make the major a platform signal. But when we discussed it, you all were against me.
>
>> On 22 Apr 2015, at 10:41, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Just a heads up: I'm not seeing the question from the subject often enough.
>>
>> In fact, I only see it when I suggest to upgrade when helping some
>> user. It's like they are very surprised "no way, I didn't think that
>> was possible?!"
>>
>> I think I've been hammering this information in each and every release
>> blog, but apparently an assumption on major versions needing to be
>> aligned is stronger.
>>
>> I guess we should embrace that? We can upgrade a minor of Hibernate
>> Search to use Hibernate ORM 5 when it comes, that will fix the
>> alignment of planets.
>>
>> Still, we also had hopes for a quick version 6 ..
>>
>> Just some thoughts.
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Wed Apr 29 08:00:43 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 29 Apr 2015 14:00:43 +0200
Subject: [hibernate-dev] Hibernate Search 5 compatible with Hibernate
	ORM 4?
In-Reply-To: <CAFm4XO2_+cj5hjWQqU1gDFCW-Lq9Rhb3S9MhiYtCd8QwN032mQ@mail.gmail.com>
References: <CAFm4XO0dLJsF57+xjaB3Qr4a8DqOYWif0FZQCK5-6cUpmdTR+Q@mail.gmail.com>
	<3B4B5EEA-00C1-4DF0-A71A-76E8309D0E29@hibernate.org>
	<CAFm4XO2_+cj5hjWQqU1gDFCW-Lq9Rhb3S9MhiYtCd8QwN032mQ@mail.gmail.com>
Message-ID: <9848649F-CA94-4BB3-88E2-DDD6E0D3A987@hibernate.org>

Yes I think a 5.x supporting ORM 5 would be my preference. I sort of remember us discussing that option in AMS.

> On 29 Apr 2015, at 12:42, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Ok so we have all been wrong, but also we couldn't wait.
> Looking forward, does this mean you'd prefer to upgrade to ORM 5 in a
> minor version of Hibernate Search?
> 
> Sanne
> 
> On 29 April 2015 at 10:07, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> I liked and still do like the planet alignment to make the major a platform signal. But when we discussed it, you all were against me.
>> 
>>> On 22 Apr 2015, at 10:41, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> 
>>> Just a heads up: I'm not seeing the question from the subject often enough.
>>> 
>>> In fact, I only see it when I suggest to upgrade when helping some
>>> user. It's like they are very surprised "no way, I didn't think that
>>> was possible?!"
>>> 
>>> I think I've been hammering this information in each and every release
>>> blog, but apparently an assumption on major versions needing to be
>>> aligned is stronger.
>>> 
>>> I guess we should embrace that? We can upgrade a minor of Hibernate
>>> Search to use Hibernate ORM 5 when it comes, that will fix the
>>> alignment of planets.
>>> 
>>> Still, we also had hopes for a quick version 6 ..
>>> 
>>> Just some thoughts.
>>> 
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 



From steve at hibernate.org  Wed Apr 29 09:16:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 08:16:58 -0500
Subject: [hibernate-dev] Any change of adding generics to Hibernate
 specific API
In-Reply-To: <B795FDE4-48C0-4C76-A39C-388C017F8013@hibernate.org>
References: <227323507.3861546.1429129650656.JavaMail.yahoo@mail.yahoo.com>
	<B795FDE4-48C0-4C76-A39C-388C017F8013@hibernate.org>
Message-ID: <CAFdSV9spbu7L4tXnFOFinNt+8JYjowVGbc0O0R38e2MB3xzA-w@mail.gmail.com>

We discussed this before on the list.  The main thing to decide is
Session#load and proxies.  Basically there are times when:

public T load(Class<T> entityType, Object id)

simply will not work.  This is the discussion I started wrt annotating the
proxy interface, rather than the impl class.

Basically I am not going to do this work piecemeal.  When we add typing, I
will add it everywhere at once.  So as soon as we can come up with an
elegant solution for that, I can add that to the roadmap.  And please see
the previous discussion before we just start re-hashing the same points
over and over :)  It was a quite long thread.


On Wed, Apr 29, 2015 at 4:14 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Hi Vlad,
>
> That?s an interesting proposal. It is certainly possible. But since the
> Session and Query API (Hibernate native) is historically non typed, I
> wonder if that is worth introducing these new typed version and add more
> overloaded methods on Session.
> Do you think it is worth the additional complexity?
>
> Steve, do you have some plan for a Session API revamp some time in the
> future? Some spring cleaning of sort.
>
> Emmanuel
>
>
> > On 15 Apr 2015, at 22:27, Mihalcea Vlad <mih_vlad at yahoo.com> wrote:
> >
> > Hi,
> > Although many rely on the Java Persistence API, Hibernate still offers
> specific features, like mapping a native SQLQuery result set to a DTO:
> > .setResultTransformer(Transformers.aliasToBean(DTO.class));
> > Is it possible to add TypedQuery and TypedSQLQuery, analogous to the JPA
> specs, so you can use generics with specific API?
> > Adding new interfaces and some overloaded Session methods wouldn't break
> backward compatibility.
> >
> > Vlad MiIhalcea
> > _______________________________________________
> > 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

From steve at hibernate.org  Wed Apr 29 09:21:50 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 08:21:50 -0500
Subject: [hibernate-dev] Changes around transaction -> changed exception
	behavior
In-Reply-To: <CADGJaX_LtaTFV2f3oKuQ4e5-iigrLZMC+SYWtgPzU7HWg89W5Q@mail.gmail.com>
References: <CADGJaX89h4988K3SjMqZ0kMA57RH=Jf_VVma2yot1a4k4u7EUQ@mail.gmail.com>
	<CAFdSV9tJuzm3n-HF2LYH86Oe=Ee08eKfmHzdMz57rEBZ82+Z0A@mail.gmail.com>
	<CADGJaX_LtaTFV2f3oKuQ4e5-iigrLZMC+SYWtgPzU7HWg89W5Q@mail.gmail.com>
Message-ID: <CAFdSV9sxXcoHFq2FuoaCx+mzTHS3Vso_PSY9U3u=ns8TNBJjUw@mail.gmail.com>

Yes, I think that logic is not correct.  A bigger concern I have there tbh
is HEM; there is some very fragile (at best) code that tries to "decode"
the exceptions thrown by the native APIs.  That stuff could very easily
break.

On Tue, Apr 28, 2015 at 4:32 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> TransactionImpl#commit(); The before-completion code is now invoked
> through transactionDriverControl.commit(); whereas previously this
> happened out of a try/catch block.
>
> 2015-04-28 23:26 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Where does that wrapping happen?
>>
>> On Tue, Apr 28, 2015 at 3:53 PM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>>  Hi,
>>>
>>> while working on making OGM work with ORM 5, I noticed a slightly
>>> different
>>> behaviour wrt. to exceptions occurring during flushes.
>>>
>>> Previously, such exceptions would bubble up as is, whereas now the
>>> beforeTransactionCompletion() logic is called in a try/catch block,
>>> wrapping any exceptions in a TransactionException. It's no big deal for
>>> me
>>> (I just need to adapt some tests in our suite which expect specific
>>> exception types), but then I was wondering whether that change poses a
>>> migration issue for existing client code, e.g.
>>> expecting/handling StaleObjectStateException which would need to be
>>> adapted
>>> accordingly?
>>>
>>> Anyone thinking it's a problem?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From mih_vlad at yahoo.com  Wed Apr 29 10:01:11 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Wed, 29 Apr 2015 14:01:11 +0000 (UTC)
Subject: [hibernate-dev] hibernate.cache.default_cache_concurrency_strategy
	has no effect
Message-ID: <108657981.426988.1430316071330.JavaMail.yahoo@mail.yahoo.com>

Hi,
Setting the "hibernate.cache.default_cache_concurrency_strategy" property doesn't have any effect.
This setting is inspected in AnnotationBinder.prepareDefaultCacheConcurrencyStrategy method, but thatmethod is never called.

Here's a test to replicate the issue:
https://github.com/vladmihalcea/hibernate-master-class/blob/master/core/src/test/java/com/vladmihalcea/hibernate/masterclass/laboratory/cache/CollectionCacheTest.java
The only workaround is to manually declare the caching strategy on each entity:
@Entity(name = "repository")
@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
Vlad Mihalcea


From steve at hibernate.org  Wed Apr 29 11:20:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 10:20:23 -0500
Subject: [hibernate-dev] Today's release
Message-ID: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>

I had originally planned on today's release being the first CR for 5.0.  I
am re-thinking that now.  Here is why...

1) If we were to ever start offering a typed API, a major major release
would be the time to do that.  However, we'd still have the "load() + proxy
interfaces" issue to decide a course of action on.
2) I have just introduced that Transaction changes after the first Beta.
It is probably prudent to have one more Beta to allow people time to try
out those changes and ask for changes.
3) I would still like to complete deprecating the Settings contract.  The
last piece there is the discussion I started earlier on the dev list wrt
its usage in SPI contracts (L2 cache, etc).  I would likely not get that
done today.

So I wanted to suggest that today's release instead be Beta2, with CR1
slated for 4 weeks from today.  Thoughts?

From steve at hibernate.org  Wed Apr 29 11:22:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 10:22:41 -0500
Subject: [hibernate-dev] Today's release
In-Reply-To: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>
References: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>
Message-ID: <CAFdSV9tO-9sNMDYtkyKdB+4GcFz0qzd2A9fEeWFO-F05grupWg@mail.gmail.com>

Oh... and I'd *like* to get the Karaf features file figured out.  Not
blocker, but a nice to have.

On Wed, Apr 29, 2015 at 10:20 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> I had originally planned on today's release being the first CR for 5.0.  I
> am re-thinking that now.  Here is why...
>
> 1) If we were to ever start offering a typed API, a major major release
> would be the time to do that.  However, we'd still have the "load() + proxy
> interfaces" issue to decide a course of action on.
> 2) I have just introduced that Transaction changes after the first Beta.
> It is probably prudent to have one more Beta to allow people time to try
> out those changes and ask for changes.
> 3) I would still like to complete deprecating the Settings contract.  The
> last piece there is the discussion I started earlier on the dev list wrt
> its usage in SPI contracts (L2 cache, etc).  I would likely not get that
> done today.
>
> So I wanted to suggest that today's release instead be Beta2, with CR1
> slated for 4 weeks from today.  Thoughts?
>

From sanne at hibernate.org  Wed Apr 29 11:49:02 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Apr 2015 16:49:02 +0100
Subject: [hibernate-dev] Today's release
In-Reply-To: <CAFdSV9tO-9sNMDYtkyKdB+4GcFz0qzd2A9fEeWFO-F05grupWg@mail.gmail.com>
References: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>
	<CAFdSV9tO-9sNMDYtkyKdB+4GcFz0qzd2A9fEeWFO-F05grupWg@mail.gmail.com>
Message-ID: <CAFm4XO3uRdGUJR1-ra0qhLBE6dFN9VduPRcDViyOc1axAVRwRQ@mail.gmail.com>

I would love that as I should really check on two last things but
couldn't make time yet.
 - the Locking API
 - checking if what I'm having in mind regarding EntityKey vs CacheKey
needs any API change

+1 for a little extra time

Thanks!
Sanne

On 29 April 2015 at 16:22, Steve Ebersole <steve at hibernate.org> wrote:
> Oh... and I'd *like* to get the Karaf features file figured out.  Not
> blocker, but a nice to have.
>
> On Wed, Apr 29, 2015 at 10:20 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> I had originally planned on today's release being the first CR for 5.0.  I
>> am re-thinking that now.  Here is why...
>>
>> 1) If we were to ever start offering a typed API, a major major release
>> would be the time to do that.  However, we'd still have the "load() + proxy
>> interfaces" issue to decide a course of action on.
>> 2) I have just introduced that Transaction changes after the first Beta.
>> It is probably prudent to have one more Beta to allow people time to try
>> out those changes and ask for changes.
>> 3) I would still like to complete deprecating the Settings contract.  The
>> last piece there is the discussion I started earlier on the dev list wrt
>> its usage in SPI contracts (L2 cache, etc).  I would likely not get that
>> done today.
>>
>> So I wanted to suggest that today's release instead be Beta2, with CR1
>> slated for 4 weeks from today.  Thoughts?
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Apr 29 11:54:48 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 10:54:48 -0500
Subject: [hibernate-dev] Today's release
In-Reply-To: <CAFm4XO3uRdGUJR1-ra0qhLBE6dFN9VduPRcDViyOc1axAVRwRQ@mail.gmail.com>
References: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>
	<CAFdSV9tO-9sNMDYtkyKdB+4GcFz0qzd2A9fEeWFO-F05grupWg@mail.gmail.com>
	<CAFm4XO3uRdGUJR1-ra0qhLBE6dFN9VduPRcDViyOc1axAVRwRQ@mail.gmail.com>
Message-ID: <CAFdSV9ujcLqGDy3jGxEWQ4YauXAuKY8UtE-6YWvdfvMyo+hjhQ@mail.gmail.com>

For EntityKey vs CacheKey, that reminds me... have we ever unified the
differing notions of a "cache key"?  Aka, just have the RegionFactory build
CachKeys for us so that we don't have to always be re-wrapping...

On Wed, Apr 29, 2015 at 10:49 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I would love that as I should really check on two last things but
> couldn't make time yet.
>  - the Locking API
>  - checking if what I'm having in mind regarding EntityKey vs CacheKey
> needs any API change
>
> +1 for a little extra time
>
> Thanks!
> Sanne
>
> On 29 April 2015 at 16:22, Steve Ebersole <steve at hibernate.org> wrote:
> > Oh... and I'd *like* to get the Karaf features file figured out.  Not
> > blocker, but a nice to have.
> >
> > On Wed, Apr 29, 2015 at 10:20 AM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> I had originally planned on today's release being the first CR for
> 5.0.  I
> >> am re-thinking that now.  Here is why...
> >>
> >> 1) If we were to ever start offering a typed API, a major major release
> >> would be the time to do that.  However, we'd still have the "load() +
> proxy
> >> interfaces" issue to decide a course of action on.
> >> 2) I have just introduced that Transaction changes after the first Beta.
> >> It is probably prudent to have one more Beta to allow people time to try
> >> out those changes and ask for changes.
> >> 3) I would still like to complete deprecating the Settings contract.
> The
> >> last piece there is the discussion I started earlier on the dev list wrt
> >> its usage in SPI contracts (L2 cache, etc).  I would likely not get that
> >> done today.
> >>
> >> So I wanted to suggest that today's release instead be Beta2, with CR1
> >> slated for 4 weeks from today.  Thoughts?
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From dreborier at gmail.com  Wed Apr 29 11:57:35 2015
From: dreborier at gmail.com (andrea boriero)
Date: Wed, 29 Apr 2015 16:57:35 +0100
Subject: [hibernate-dev] Today's release
In-Reply-To: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>
References: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>
Message-ID: <CAL00eST+dwTSFv4==OkZZRw-9DLG63497O11wTPXODSPYE25sg@mail.gmail.com>

I agree with the Beta2 in order to give time to try out the Transaction
Changes :)

+1

On 29 April 2015 at 16:20, Steve Ebersole <steve at hibernate.org> wrote:

> I had originally planned on today's release being the first CR for 5.0.  I
> am re-thinking that now.  Here is why...
>
> 1) If we were to ever start offering a typed API, a major major release
> would be the time to do that.  However, we'd still have the "load() + proxy
> interfaces" issue to decide a course of action on.
> 2) I have just introduced that Transaction changes after the first Beta.
> It is probably prudent to have one more Beta to allow people time to try
> out those changes and ask for changes.
> 3) I would still like to complete deprecating the Settings contract.  The
> last piece there is the discussion I started earlier on the dev list wrt
> its usage in SPI contracts (L2 cache, etc).  I would likely not get that
> done today.
>
> So I wanted to suggest that today's release instead be Beta2, with CR1
> slated for 4 weeks from today.  Thoughts?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Apr 29 12:15:05 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 29 Apr 2015 17:15:05 +0100
Subject: [hibernate-dev] Today's release
In-Reply-To: <CAFdSV9ujcLqGDy3jGxEWQ4YauXAuKY8UtE-6YWvdfvMyo+hjhQ@mail.gmail.com>
References: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>
	<CAFdSV9tO-9sNMDYtkyKdB+4GcFz0qzd2A9fEeWFO-F05grupWg@mail.gmail.com>
	<CAFm4XO3uRdGUJR1-ra0qhLBE6dFN9VduPRcDViyOc1axAVRwRQ@mail.gmail.com>
	<CAFdSV9ujcLqGDy3jGxEWQ4YauXAuKY8UtE-6YWvdfvMyo+hjhQ@mail.gmail.com>
Message-ID: <CAFm4XO1fpj3L4r0fD6oTgCaMUpX3yS9e2+0n3NLSYQuy2vqcAw@mail.gmail.com>

On 29 April 2015 at 16:54, Steve Ebersole <steve at hibernate.org> wrote:
> For EntityKey vs CacheKey, that reminds me... have we ever unified the
> differing notions of a "cache key"?  Aka, just have the RegionFactory build
> CachKeys for us so that we don't have to always be re-wrapping...

Right that's what I'm referring to. I don't know if someone will have
time to properly implement it all (as changes would need to be
performance tested and that's going to take time), so I would aim to
at very least check that this won't need API changes later.


>
> On Wed, Apr 29, 2015 at 10:49 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> I would love that as I should really check on two last things but
>> couldn't make time yet.
>>  - the Locking API
>>  - checking if what I'm having in mind regarding EntityKey vs CacheKey
>> needs any API change
>>
>> +1 for a little extra time
>>
>> Thanks!
>> Sanne
>>
>> On 29 April 2015 at 16:22, Steve Ebersole <steve at hibernate.org> wrote:
>> > Oh... and I'd *like* to get the Karaf features file figured out.  Not
>> > blocker, but a nice to have.
>> >
>> > On Wed, Apr 29, 2015 at 10:20 AM, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >
>> >> I had originally planned on today's release being the first CR for 5.0.
>> >> I
>> >> am re-thinking that now.  Here is why...
>> >>
>> >> 1) If we were to ever start offering a typed API, a major major release
>> >> would be the time to do that.  However, we'd still have the "load() +
>> >> proxy
>> >> interfaces" issue to decide a course of action on.
>> >> 2) I have just introduced that Transaction changes after the first
>> >> Beta.
>> >> It is probably prudent to have one more Beta to allow people time to
>> >> try
>> >> out those changes and ask for changes.
>> >> 3) I would still like to complete deprecating the Settings contract.
>> >> The
>> >> last piece there is the discussion I started earlier on the dev list
>> >> wrt
>> >> its usage in SPI contracts (L2 cache, etc).  I would likely not get
>> >> that
>> >> done today.
>> >>
>> >> So I wanted to suggest that today's release instead be Beta2, with CR1
>> >> slated for 4 weeks from today.  Thoughts?
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Wed Apr 29 13:02:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 12:02:20 -0500
Subject: [hibernate-dev] Today's release
In-Reply-To: <CAFm4XO1fpj3L4r0fD6oTgCaMUpX3yS9e2+0n3NLSYQuy2vqcAw@mail.gmail.com>
References: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>
	<CAFdSV9tO-9sNMDYtkyKdB+4GcFz0qzd2A9fEeWFO-F05grupWg@mail.gmail.com>
	<CAFm4XO3uRdGUJR1-ra0qhLBE6dFN9VduPRcDViyOc1axAVRwRQ@mail.gmail.com>
	<CAFdSV9ujcLqGDy3jGxEWQ4YauXAuKY8UtE-6YWvdfvMyo+hjhQ@mail.gmail.com>
	<CAFm4XO1fpj3L4r0fD6oTgCaMUpX3yS9e2+0n3NLSYQuy2vqcAw@mail.gmail.com>
Message-ID: <CAFdSV9uYqS=XCATfsf=mtRGyc3+9uzsSX4DaHmpcytOikmdttw@mail.gmail.com>

WRT performance testing... well I think we can agree that the performance
would not be worse.  So I don't see the harm in that regard.

On Wed, Apr 29, 2015 at 11:15 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 29 April 2015 at 16:54, Steve Ebersole <steve at hibernate.org> wrote:
> > For EntityKey vs CacheKey, that reminds me... have we ever unified the
> > differing notions of a "cache key"?  Aka, just have the RegionFactory
> build
> > CachKeys for us so that we don't have to always be re-wrapping...
>
> Right that's what I'm referring to. I don't know if someone will have
> time to properly implement it all (as changes would need to be
> performance tested and that's going to take time), so I would aim to
> at very least check that this won't need API changes later.
>
>
> >
> > On Wed, Apr 29, 2015 at 10:49 AM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> I would love that as I should really check on two last things but
> >> couldn't make time yet.
> >>  - the Locking API
> >>  - checking if what I'm having in mind regarding EntityKey vs CacheKey
> >> needs any API change
> >>
> >> +1 for a little extra time
> >>
> >> Thanks!
> >> Sanne
> >>
> >> On 29 April 2015 at 16:22, Steve Ebersole <steve at hibernate.org> wrote:
> >> > Oh... and I'd *like* to get the Karaf features file figured out.  Not
> >> > blocker, but a nice to have.
> >> >
> >> > On Wed, Apr 29, 2015 at 10:20 AM, Steve Ebersole <steve at hibernate.org
> >
> >> > wrote:
> >> >
> >> >> I had originally planned on today's release being the first CR for
> 5.0.
> >> >> I
> >> >> am re-thinking that now.  Here is why...
> >> >>
> >> >> 1) If we were to ever start offering a typed API, a major major
> release
> >> >> would be the time to do that.  However, we'd still have the "load() +
> >> >> proxy
> >> >> interfaces" issue to decide a course of action on.
> >> >> 2) I have just introduced that Transaction changes after the first
> >> >> Beta.
> >> >> It is probably prudent to have one more Beta to allow people time to
> >> >> try
> >> >> out those changes and ask for changes.
> >> >> 3) I would still like to complete deprecating the Settings contract.
> >> >> The
> >> >> last piece there is the discussion I started earlier on the dev list
> >> >> wrt
> >> >> its usage in SPI contracts (L2 cache, etc).  I would likely not get
> >> >> that
> >> >> done today.
> >> >>
> >> >> So I wanted to suggest that today's release instead be Beta2, with
> CR1
> >> >> slated for 4 weeks from today.  Thoughts?
> >> >>
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From steve at hibernate.org  Wed Apr 29 13:05:04 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 12:05:04 -0500
Subject: [hibernate-dev] Today's release
In-Reply-To: <CAFdSV9uYqS=XCATfsf=mtRGyc3+9uzsSX4DaHmpcytOikmdttw@mail.gmail.com>
References: <CAFdSV9s5G+s8ZqHgwxS7wO=a_rva=MxpOM2MiEXji=ci2mFtQQ@mail.gmail.com>
	<CAFdSV9tO-9sNMDYtkyKdB+4GcFz0qzd2A9fEeWFO-F05grupWg@mail.gmail.com>
	<CAFm4XO3uRdGUJR1-ra0qhLBE6dFN9VduPRcDViyOc1axAVRwRQ@mail.gmail.com>
	<CAFdSV9ujcLqGDy3jGxEWQ4YauXAuKY8UtE-6YWvdfvMyo+hjhQ@mail.gmail.com>
	<CAFm4XO1fpj3L4r0fD6oTgCaMUpX3yS9e2+0n3NLSYQuy2vqcAw@mail.gmail.com>
	<CAFdSV9uYqS=XCATfsf=mtRGyc3+9uzsSX4DaHmpcytOikmdttw@mail.gmail.com>
Message-ID: <CAFdSV9tKGFxLRCs2CiuXCcwG2OqHYhbchmvKYZmKEDphgj8yaw@mail.gmail.com>

Ok, I'll call it a quorum in terms of making this Beta2...

On Wed, Apr 29, 2015 at 12:02 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> WRT performance testing... well I think we can agree that the performance
> would not be worse.  So I don't see the harm in that regard.
>
> On Wed, Apr 29, 2015 at 11:15 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 29 April 2015 at 16:54, Steve Ebersole <steve at hibernate.org> wrote:
>> > For EntityKey vs CacheKey, that reminds me... have we ever unified the
>> > differing notions of a "cache key"?  Aka, just have the RegionFactory
>> build
>> > CachKeys for us so that we don't have to always be re-wrapping...
>>
>> Right that's what I'm referring to. I don't know if someone will have
>> time to properly implement it all (as changes would need to be
>> performance tested and that's going to take time), so I would aim to
>> at very least check that this won't need API changes later.
>>
>>
>> >
>> > On Wed, Apr 29, 2015 at 10:49 AM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> I would love that as I should really check on two last things but
>> >> couldn't make time yet.
>> >>  - the Locking API
>> >>  - checking if what I'm having in mind regarding EntityKey vs CacheKey
>> >> needs any API change
>> >>
>> >> +1 for a little extra time
>> >>
>> >> Thanks!
>> >> Sanne
>> >>
>> >> On 29 April 2015 at 16:22, Steve Ebersole <steve at hibernate.org> wrote:
>> >> > Oh... and I'd *like* to get the Karaf features file figured out.  Not
>> >> > blocker, but a nice to have.
>> >> >
>> >> > On Wed, Apr 29, 2015 at 10:20 AM, Steve Ebersole <
>> steve at hibernate.org>
>> >> > wrote:
>> >> >
>> >> >> I had originally planned on today's release being the first CR for
>> 5.0.
>> >> >> I
>> >> >> am re-thinking that now.  Here is why...
>> >> >>
>> >> >> 1) If we were to ever start offering a typed API, a major major
>> release
>> >> >> would be the time to do that.  However, we'd still have the "load()
>> +
>> >> >> proxy
>> >> >> interfaces" issue to decide a course of action on.
>> >> >> 2) I have just introduced that Transaction changes after the first
>> >> >> Beta.
>> >> >> It is probably prudent to have one more Beta to allow people time to
>> >> >> try
>> >> >> out those changes and ask for changes.
>> >> >> 3) I would still like to complete deprecating the Settings contract.
>> >> >> The
>> >> >> last piece there is the discussion I started earlier on the dev list
>> >> >> wrt
>> >> >> its usage in SPI contracts (L2 cache, etc).  I would likely not get
>> >> >> that
>> >> >> done today.
>> >> >>
>> >> >> So I wanted to suggest that today's release instead be Beta2, with
>> CR1
>> >> >> slated for 4 weeks from today.  Thoughts?
>> >> >>
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>>
>
>

From gbadner at redhat.com  Wed Apr 29 18:19:23 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 29 Apr 2015 18:19:23 -0400 (EDT)
Subject: [hibernate-dev]
 hibernate.cache.default_cache_concurrency_strategy	has no effect
In-Reply-To: <108657981.426988.1430316071330.JavaMail.yahoo@mail.yahoo.com>
References: <108657981.426988.1430316071330.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <1663714545.10428643.1430345963373.JavaMail.zimbra@redhat.com>

This mailing list is for discussing Hibernate development. Please open a JIRA issue at https://hibernate.atlassian.net/projects/HHH and attach your test.

Thanks,
Gail
----- Original Message -----
> From: "Mihalcea Vlad" <mih_vlad at yahoo.com>
> To: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, April 29, 2015 7:01:11 AM
> Subject: [hibernate-dev] hibernate.cache.default_cache_concurrency_strategy	has no effect
> 
> Hi,
> Setting the "hibernate.cache.default_cache_concurrency_strategy" property
> doesn't have any effect.
> This setting is inspected in
> AnnotationBinder.prepareDefaultCacheConcurrencyStrategy method, but
> thatmethod is never called.
> 
> Here's a test to replicate the issue:
> https://github.com/vladmihalcea/hibernate-master-class/blob/master/core/src/test/java/com/vladmihalcea/hibernate/masterclass/laboratory/cache/CollectionCacheTest.java
> The only workaround is to manually declare the caching strategy on each
> entity:
> @Entity(name = "repository")
> @org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
> Vlad Mihalcea
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From steve at hibernate.org  Wed Apr 29 23:39:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 22:39:52 -0500
Subject: [hibernate-dev] Changes around transaction -> changed exception
	behavior
In-Reply-To: <CAFdSV9sxXcoHFq2FuoaCx+mzTHS3Vso_PSY9U3u=ns8TNBJjUw@mail.gmail.com>
References: <CADGJaX89h4988K3SjMqZ0kMA57RH=Jf_VVma2yot1a4k4u7EUQ@mail.gmail.com>
	<CAFdSV9tJuzm3n-HF2LYH86Oe=Ee08eKfmHzdMz57rEBZ82+Z0A@mail.gmail.com>
	<CADGJaX_LtaTFV2f3oKuQ4e5-iigrLZMC+SYWtgPzU7HWg89W5Q@mail.gmail.com>
	<CAFdSV9sxXcoHFq2FuoaCx+mzTHS3Vso_PSY9U3u=ns8TNBJjUw@mail.gmail.com>
Message-ID: <CAFdSV9sjsA-eSo4uZbvowv9c67yKXx9oX08Wdt13zJF0=NW3=A@mail.gmail.com>

https://hibernate.atlassian.net/browse/HHH-9760

On Wed, Apr 29, 2015 at 8:21 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Yes, I think that logic is not correct.  A bigger concern I have there tbh
> is HEM; there is some very fragile (at best) code that tries to "decode"
> the exceptions thrown by the native APIs.  That stuff could very easily
> break.
>
> On Tue, Apr 28, 2015 at 4:32 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> TransactionImpl#commit(); The before-completion code is now invoked
>> through transactionDriverControl.commit(); whereas previously this
>> happened out of a try/catch block.
>>
>> 2015-04-28 23:26 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Where does that wrapping happen?
>>>
>>> On Tue, Apr 28, 2015 at 3:53 PM, Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>>  Hi,
>>>>
>>>> while working on making OGM work with ORM 5, I noticed a slightly
>>>> different
>>>> behaviour wrt. to exceptions occurring during flushes.
>>>>
>>>> Previously, such exceptions would bubble up as is, whereas now the
>>>> beforeTransactionCompletion() logic is called in a try/catch block,
>>>> wrapping any exceptions in a TransactionException. It's no big deal for
>>>> me
>>>> (I just need to adapt some tests in our suite which expect specific
>>>> exception types), but then I was wondering whether that change poses a
>>>> migration issue for existing client code, e.g.
>>>> expecting/handling StaleObjectStateException which would need to be
>>>> adapted
>>>> accordingly?
>>>>
>>>> Anyone thinking it's a problem?
>>>>
>>>> Thanks,
>>>>
>>>> --Gunnar
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>

From steve at hibernate.org  Wed Apr 29 23:41:39 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 22:41:39 -0500
Subject: [hibernate-dev] Any change of adding generics to Hibernate
 specific API
In-Reply-To: <CAFdSV9spbu7L4tXnFOFinNt+8JYjowVGbc0O0R38e2MB3xzA-w@mail.gmail.com>
References: <227323507.3861546.1429129650656.JavaMail.yahoo@mail.yahoo.com>
	<B795FDE4-48C0-4C76-A39C-388C017F8013@hibernate.org>
	<CAFdSV9spbu7L4tXnFOFinNt+8JYjowVGbc0O0R38e2MB3xzA-w@mail.gmail.com>
Message-ID: <CAFdSV9uMb_57_CD2bJP34hM9pctaKyRZOsZ1+7+MyGADD31CXQ@mail.gmail.com>

https://hibernate.atlassian.net/browse/HHH-9761

On Wed, Apr 29, 2015 at 8:16 AM, Steve Ebersole <steve at hibernate.org> wrote:

> We discussed this before on the list.  The main thing to decide is
> Session#load and proxies.  Basically there are times when:
>
> public T load(Class<T> entityType, Object id)
>
> simply will not work.  This is the discussion I started wrt annotating the
> proxy interface, rather than the impl class.
>
> Basically I am not going to do this work piecemeal.  When we add typing, I
> will add it everywhere at once.  So as soon as we can come up with an
> elegant solution for that, I can add that to the roadmap.  And please see
> the previous discussion before we just start re-hashing the same points
> over and over :)  It was a quite long thread.
>
>
> On Wed, Apr 29, 2015 at 4:14 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>> Hi Vlad,
>>
>> That?s an interesting proposal. It is certainly possible. But since the
>> Session and Query API (Hibernate native) is historically non typed, I
>> wonder if that is worth introducing these new typed version and add more
>> overloaded methods on Session.
>> Do you think it is worth the additional complexity?
>>
>> Steve, do you have some plan for a Session API revamp some time in the
>> future? Some spring cleaning of sort.
>>
>> Emmanuel
>>
>>
>> > On 15 Apr 2015, at 22:27, Mihalcea Vlad <mih_vlad at yahoo.com> wrote:
>> >
>> > Hi,
>> > Although many rely on the Java Persistence API, Hibernate still offers
>> specific features, like mapping a native SQLQuery result set to a DTO:
>> > .setResultTransformer(Transformers.aliasToBean(DTO.class));
>> > Is it possible to add TypedQuery and TypedSQLQuery, analogous to the
>> JPA specs, so you can use generics with specific API?
>> > Adding new interfaces and some overloaded Session methods wouldn't
>> break backward compatibility.
>> >
>> > Vlad MiIhalcea
>> > _______________________________________________
>> > 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
>
>
>

From steve at hibernate.org  Thu Apr 30 00:35:36 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 29 Apr 2015 23:35:36 -0500
Subject: [hibernate-dev] Hibernate O/RM 5.0.0.Beta2 release
Message-ID: <CAFdSV9sjRFx13-wKmAg2W+FqPRh_ONOdE+YPzGa3KqF7jgg-Ow@mail.gmail.com>

http://in.relation.to/Bloggers/HibernateORM500Beta2Release

From gunnar at hibernate.org  Thu Apr 30 02:57:41 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 30 Apr 2015 08:57:41 +0200
Subject: [hibernate-dev] Any change of adding generics to Hibernate
 specific API
In-Reply-To: <CAFdSV9uMb_57_CD2bJP34hM9pctaKyRZOsZ1+7+MyGADD31CXQ@mail.gmail.com>
References: <227323507.3861546.1429129650656.JavaMail.yahoo@mail.yahoo.com>
	<B795FDE4-48C0-4C76-A39C-388C017F8013@hibernate.org>
	<CAFdSV9spbu7L4tXnFOFinNt+8JYjowVGbc0O0R38e2MB3xzA-w@mail.gmail.com>
	<CAFdSV9uMb_57_CD2bJP34hM9pctaKyRZOsZ1+7+MyGADD31CXQ@mail.gmail.com>
Message-ID: <CADGJaX_WEea6jnxgfykf82_MX4RcohviSBtfuvJfRCpw+SRBvg@mail.gmail.com>

Looks like that's the previous discussion Steve was referring to:
http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007625.html

2015-04-30 5:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> https://hibernate.atlassian.net/browse/HHH-9761
>
> On Wed, Apr 29, 2015 at 8:16 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > We discussed this before on the list.  The main thing to decide is
> > Session#load and proxies.  Basically there are times when:
> >
> > public T load(Class<T> entityType, Object id)
> >
> > simply will not work.  This is the discussion I started wrt annotating
> the
> > proxy interface, rather than the impl class.
> >
> > Basically I am not going to do this work piecemeal.  When we add typing,
> I
> > will add it everywhere at once.  So as soon as we can come up with an
> > elegant solution for that, I can add that to the roadmap.  And please see
> > the previous discussion before we just start re-hashing the same points
> > over and over :)  It was a quite long thread.
> >
> >
> > On Wed, Apr 29, 2015 at 4:14 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>
> > wrote:
> >
> >> Hi Vlad,
> >>
> >> That?s an interesting proposal. It is certainly possible. But since the
> >> Session and Query API (Hibernate native) is historically non typed, I
> >> wonder if that is worth introducing these new typed version and add more
> >> overloaded methods on Session.
> >> Do you think it is worth the additional complexity?
> >>
> >> Steve, do you have some plan for a Session API revamp some time in the
> >> future? Some spring cleaning of sort.
> >>
> >> Emmanuel
> >>
> >>
> >> > On 15 Apr 2015, at 22:27, Mihalcea Vlad <mih_vlad at yahoo.com> wrote:
> >> >
> >> > Hi,
> >> > Although many rely on the Java Persistence API, Hibernate still offers
> >> specific features, like mapping a native SQLQuery result set to a DTO:
> >> > .setResultTransformer(Transformers.aliasToBean(DTO.class));
> >> > Is it possible to add TypedQuery and TypedSQLQuery, analogous to the
> >> JPA specs, so you can use generics with specific API?
> >> > Adding new interfaces and some overloaded Session methods wouldn't
> >> break backward compatibility.
> >> >
> >> > Vlad MiIhalcea
> >> > _______________________________________________
> >> > 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
> >
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mih_vlad at yahoo.com  Thu Apr 30 02:59:20 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Thu, 30 Apr 2015 06:59:20 +0000 (UTC)
Subject: [hibernate-dev] Any change of adding generics to Hibernate
 specific API
In-Reply-To: <CADGJaX_WEea6jnxgfykf82_MX4RcohviSBtfuvJfRCpw+SRBvg@mail.gmail.com>
References: <CADGJaX_WEea6jnxgfykf82_MX4RcohviSBtfuvJfRCpw+SRBvg@mail.gmail.com>
Message-ID: <596213910.1058147.1430377160143.JavaMail.yahoo@mail.yahoo.com>

Thanks. I'll check it out.
?
 


     On Thursday, April 30, 2015 9:57 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
   

 Looks like that's the previous discussion Steve was referring to:
http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007625.html

2015-04-30 5:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> https://hibernate.atlassian.net/browse/HHH-9761
>
> On Wed, Apr 29, 2015 at 8:16 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > We discussed this before on the list.? The main thing to decide is
> > Session#load and proxies.? Basically there are times when:
> >
> > public T load(Class<T> entityType, Object id)
> >
> > simply will not work.? This is the discussion I started wrt annotating
> the
> > proxy interface, rather than the impl class.
> >
> > Basically I am not going to do this work piecemeal.? When we add typing,
> I
> > will add it everywhere at once.? So as soon as we can come up with an
> > elegant solution for that, I can add that to the roadmap.? And please see
> > the previous discussion before we just start re-hashing the same points
> > over and over :)? It was a quite long thread.
> >
> >
> > On Wed, Apr 29, 2015 at 4:14 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>
> > wrote:
> >
> >> Hi Vlad,
> >>
> >> That?s an interesting proposal. It is certainly possible. But since the
> >> Session and Query API (Hibernate native) is historically non typed, I
> >> wonder if that is worth introducing these new typed version and add more
> >> overloaded methods on Session.
> >> Do you think it is worth the additional complexity?
> >>
> >> Steve, do you have some plan for a Session API revamp some time in the
> >> future? Some spring cleaning of sort.
> >>
> >> Emmanuel
> >>
> >>
> >> > On 15 Apr 2015, at 22:27, Mihalcea Vlad <mih_vlad at yahoo.com> wrote:
> >> >
> >> > Hi,
> >> > Although many rely on the Java Persistence API, Hibernate still offers
> >> specific features, like mapping a native SQLQuery result set to a DTO:
> >> > .setResultTransformer(Transformers.aliasToBean(DTO.class));
> >> > Is it possible to add TypedQuery and TypedSQLQuery, analogous to the
> >> JPA specs, so you can use generics with specific API?
> >> > Adding new interfaces and some overloaded Session methods wouldn't
> >> break backward compatibility.
> >> >
> >> > Vlad MiIhalcea
> >> > _______________________________________________
> >> > 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
> >
> >
> >
> _______________________________________________
> 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

  

From gunnar at hibernate.org  Thu Apr 30 04:08:15 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 30 Apr 2015 10:08:15 +0200
Subject: [hibernate-dev] Keeping context in the scope of a transaction
Message-ID: <CADGJaX-4UjEMrCWArDGgnA=_bEOyKbjMawLmKtR86T1aQZWyTw@mail.gmail.com>

Steve, Andrea,

For OGM we need to store certain data in the scope of a transaction;
specifically this is the list of applied "grid dialect operations", so we
can present these to the user upon failures (and thus "rollbacks") on
non-transactional backends.

Until now we used a custom org.hibernate.Transaction impl for keeping this
data. I am now looking into using the new TransactionCoordinator approach
instead. Is it a save route to initialise the required context upon first
invocation of MyTransactionCoordinator#getTransactionDriverControl() and
clear it via TransactionObserver#afterCompletion()?

It works fine for me in our tests, but I'd like to make sure I am not
missing anything :)

Thanks,

--Gunnar

From dreborier at gmail.com  Thu Apr 30 05:02:33 2015
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 30 Apr 2015 10:02:33 +0100
Subject: [hibernate-dev] Keeping context in the scope of a transaction
In-Reply-To: <CADGJaX-4UjEMrCWArDGgnA=_bEOyKbjMawLmKtR86T1aQZWyTw@mail.gmail.com>
References: <CADGJaX-4UjEMrCWArDGgnA=_bEOyKbjMawLmKtR86T1aQZWyTw@mail.gmail.com>
Message-ID: <CAL00eSTU+zoV1qRFPZMryN9jJCA=nbQPkxz3OPgGyW9kVE9JEA@mail.gmail.com>

Hi Gunnar,

 at the moment I cannot figure out any problem or anything you are missing,
the solution seems good :)





On 30 April 2015 at 09:08, Gunnar Morling <gunnar at hibernate.org> wrote:

> Steve, Andrea,
>
> For OGM we need to store certain data in the scope of a transaction;
> specifically this is the list of applied "grid dialect operations", so we
> can present these to the user upon failures (and thus "rollbacks") on
> non-transactional backends.
>
> Until now we used a custom org.hibernate.Transaction impl for keeping this
> data. I am now looking into using the new TransactionCoordinator approach
> instead. Is it a save route to initialise the required context upon first
> invocation of MyTransactionCoordinator#getTransactionDriverControl() and
> clear it via TransactionObserver#afterCompletion()?
>
> It works fine for me in our tests, but I'd like to make sure I am not
> missing anything :)
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From manderse at redhat.com  Thu Apr 30 05:17:30 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Thu, 30 Apr 2015 11:17:30 +0200
Subject: [hibernate-dev] Hibernate O/RM 5.0.0.Beta2 release
In-Reply-To: <CAFdSV9sjRFx13-wKmAg2W+FqPRh_ONOdE+YPzGa3KqF7jgg-Ow@mail.gmail.com>
References: <CAFdSV9sjRFx13-wKmAg2W+FqPRh_ONOdE+YPzGa3KqF7jgg-Ow@mail.gmail.com>
Message-ID: <E7F4C0C6-5909-43FE-8101-35C313A4A90D@redhat.com>

On 30 Apr 2015, at 6:35, Steve Ebersole wrote:

> http://in.relation.to/Bloggers/HibernateORM500Beta2Release

with respect to:

Much improved (and still improving!) schema management tooling for 
export, validation and migration.

Where is the best place to find info on this.

As discussed in past we aren't able to keep up with supporting Hibernate 
5 from jboss tools,
but I'm curious to see what is there.

If anyone tried using Hibernate Tools both ant and/or Eclipse tooling 
with Hibernate 5 already
I would like to hear if they found issues/problems - some we might be 
able to fix easily.

/max
http://about.me/maxandersen

From steve at hibernate.org  Thu Apr 30 07:25:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 30 Apr 2015 06:25:37 -0500
Subject: [hibernate-dev] Any change of adding generics to Hibernate
 specific API
In-Reply-To: <CADGJaX_WEea6jnxgfykf82_MX4RcohviSBtfuvJfRCpw+SRBvg@mail.gmail.com>
References: <227323507.3861546.1429129650656.JavaMail.yahoo@mail.yahoo.com>
	<B795FDE4-48C0-4C76-A39C-388C017F8013@hibernate.org>
	<CAFdSV9spbu7L4tXnFOFinNt+8JYjowVGbc0O0R38e2MB3xzA-w@mail.gmail.com>
	<CAFdSV9uMb_57_CD2bJP34hM9pctaKyRZOsZ1+7+MyGADD31CXQ@mail.gmail.com>
	<CADGJaX_WEea6jnxgfykf82_MX4RcohviSBtfuvJfRCpw+SRBvg@mail.gmail.com>
Message-ID: <CAFdSV9vyMCTKQrMEEXReg7b92Z3j26wwBgopNtsKoW9Z3_g0kQ@mail.gmail.com>

Indeed that is it.  Thanks for finding it, that was a task for me for
today! :)

On Thu, Apr 30, 2015 at 1:57 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Looks like that's the previous discussion Steve was referring to:
> http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007625.html
>
> 2015-04-30 5:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> https://hibernate.atlassian.net/browse/HHH-9761
>>
>> On Wed, Apr 29, 2015 at 8:16 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > We discussed this before on the list.  The main thing to decide is
>> > Session#load and proxies.  Basically there are times when:
>> >
>> > public T load(Class<T> entityType, Object id)
>> >
>> > simply will not work.  This is the discussion I started wrt annotating
>> the
>> > proxy interface, rather than the impl class.
>> >
>> > Basically I am not going to do this work piecemeal.  When we add
>> typing, I
>> > will add it everywhere at once.  So as soon as we can come up with an
>> > elegant solution for that, I can add that to the roadmap.  And please
>> see
>> > the previous discussion before we just start re-hashing the same points
>> > over and over :)  It was a quite long thread.
>> >
>> >
>> > On Wed, Apr 29, 2015 at 4:14 AM, Emmanuel Bernard <
>> emmanuel at hibernate.org>
>> > wrote:
>> >
>> >> Hi Vlad,
>> >>
>> >> That?s an interesting proposal. It is certainly possible. But since the
>> >> Session and Query API (Hibernate native) is historically non typed, I
>> >> wonder if that is worth introducing these new typed version and add
>> more
>> >> overloaded methods on Session.
>> >> Do you think it is worth the additional complexity?
>> >>
>> >> Steve, do you have some plan for a Session API revamp some time in the
>> >> future? Some spring cleaning of sort.
>> >>
>> >> Emmanuel
>> >>
>> >>
>> >> > On 15 Apr 2015, at 22:27, Mihalcea Vlad <mih_vlad at yahoo.com> wrote:
>> >> >
>> >> > Hi,
>> >> > Although many rely on the Java Persistence API, Hibernate still
>> offers
>> >> specific features, like mapping a native SQLQuery result set to a DTO:
>> >> > .setResultTransformer(Transformers.aliasToBean(DTO.class));
>> >> > Is it possible to add TypedQuery and TypedSQLQuery, analogous to the
>> >> JPA specs, so you can use generics with specific API?
>> >> > Adding new interfaces and some overloaded Session methods wouldn't
>> >> break backward compatibility.
>> >> >
>> >> > Vlad MiIhalcea
>> >> > _______________________________________________
>> >> > 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
>> >
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Thu Apr 30 07:36:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 30 Apr 2015 06:36:28 -0500
Subject: [hibernate-dev] Hibernate O/RM 5.0.0.Beta2 release
In-Reply-To: <E7F4C0C6-5909-43FE-8101-35C313A4A90D@redhat.com>
References: <CAFdSV9sjRFx13-wKmAg2W+FqPRh_ONOdE+YPzGa3KqF7jgg-Ow@mail.gmail.com>
	<E7F4C0C6-5909-43FE-8101-35C313A4A90D@redhat.com>
Message-ID: <CAFdSV9t_9buGvbFD2rSK0nTdOsB_q_KPxovY8_k+d6SHek-kqA@mail.gmail.com>

A lot of it is just in my head :)  Ultimately the plan is to finally
actually support validation and migration (update) in 5.x.

The actual backings to these are also pluggable now via service
repository.  You can see the details for this part
in org.hibernate.tool.schema.spi.SchemaManagementTool.  TBH, I wonder if is
actually better to have the individual tools (SchemaCreator, SchemaDropper,
etc) be pluggable rather than the whole thing.  That's more like the way
proper way.  The one I see getting replaced is SchemaMigrator, although I
can see someone swapping SchemaValidator too.  I have spoken with the
LiquiBase developer before about SchemaMigrator; it would rock to offer
transparent support for LiquiBase here.

As far as the rest, I will try to get the thoughts in my head down on
"paper".  Specific improvements off top of head:
1) Better (imo) interaction from Dialect via specific
org.hibernate.tool.schema.spi.Exporter contracts
2) (not done yet) Better validation through the concept of "type families"
for column validation
: org.hibernate.type.descriptor.sql.JdbcTypeFamilyInformation
3) Better handling of catalog/schema - this is multi part


On Thu, Apr 30, 2015 at 4:17 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> On 30 Apr 2015, at 6:35, Steve Ebersole wrote:
>
>  http://in.relation.to/Bloggers/HibernateORM500Beta2Release
>>
>
> with respect to:
>
> Much improved (and still improving!) schema management tooling for export,
> validation and migration.
>
> Where is the best place to find info on this.
>
> As discussed in past we aren't able to keep up with supporting Hibernate 5
> from jboss tools,
> but I'm curious to see what is there.
>
> If anyone tried using Hibernate Tools both ant and/or Eclipse tooling with
> Hibernate 5 already
> I would like to hear if they found issues/problems - some we might be able
> to fix easily.
>
> /max
> http://about.me/maxandersen
>

From steve at hibernate.org  Thu Apr 30 07:59:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 30 Apr 2015 06:59:59 -0500
Subject: [hibernate-dev] Keeping context in the scope of a transaction
In-Reply-To: <CAL00eSTU+zoV1qRFPZMryN9jJCA=nbQPkxz3OPgGyW9kVE9JEA@mail.gmail.com>
References: <CADGJaX-4UjEMrCWArDGgnA=_bEOyKbjMawLmKtR86T1aQZWyTw@mail.gmail.com>
	<CAL00eSTU+zoV1qRFPZMryN9jJCA=nbQPkxz3OPgGyW9kVE9JEA@mail.gmail.com>
Message-ID: <CAFdSV9u5qMTB3GpjV-vtpMeiUvRhQGyiA5XSMYjJhVxKLBGKrA@mail.gmail.com>

Hard to say exactly without knowing the exact nature of the data you keep,
but couldn't you keep the same principle as before and keep this on your
return from getTransactionDriverControl (the *Inflow contract, Andrea I
thought we had decided to rename that interface as well?)?

On Thu, Apr 30, 2015 at 4:02 AM, andrea boriero <dreborier at gmail.com> wrote:

> Hi Gunnar,
>
>  at the moment I cannot figure out any problem or anything you are missing,
> the solution seems good :)
>
>
>
>
>
> On 30 April 2015 at 09:08, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > Steve, Andrea,
> >
> > For OGM we need to store certain data in the scope of a transaction;
> > specifically this is the list of applied "grid dialect operations", so we
> > can present these to the user upon failures (and thus "rollbacks") on
> > non-transactional backends.
> >
> > Until now we used a custom org.hibernate.Transaction impl for keeping
> this
> > data. I am now looking into using the new TransactionCoordinator approach
> > instead. Is it a save route to initialise the required context upon first
> > invocation of MyTransactionCoordinator#getTransactionDriverControl() and
> > clear it via TransactionObserver#afterCompletion()?
> >
> > It works fine for me in our tests, but I'd like to make sure I am not
> > missing anything :)
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > 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
>

From dreborier at gmail.com  Thu Apr 30 08:10:31 2015
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 30 Apr 2015 13:10:31 +0100
Subject: [hibernate-dev] Keeping context in the scope of a transaction
In-Reply-To: <CAFdSV9u5qMTB3GpjV-vtpMeiUvRhQGyiA5XSMYjJhVxKLBGKrA@mail.gmail.com>
References: <CADGJaX-4UjEMrCWArDGgnA=_bEOyKbjMawLmKtR86T1aQZWyTw@mail.gmail.com>
	<CAL00eSTU+zoV1qRFPZMryN9jJCA=nbQPkxz3OPgGyW9kVE9JEA@mail.gmail.com>
	<CAFdSV9u5qMTB3GpjV-vtpMeiUvRhQGyiA5XSMYjJhVxKLBGKrA@mail.gmail.com>
Message-ID: <CAL00eSRXL0M0YZPeDPjyWOmuYHAxWa7D+H09=F+=3RJXtJdd_A@mail.gmail.com>

yes we discussed about renaming it

On 30 April 2015 at 12:59, Steve Ebersole <steve at hibernate.org> wrote:

> Hard to say exactly without knowing the exact nature of the data you keep,
> but couldn't you keep the same principle as before and keep this on your
> return from getTransactionDriverControl (the *Inflow contract, Andrea I
> thought we had decided to rename that interface as well?)?
>
> On Thu, Apr 30, 2015 at 4:02 AM, andrea boriero <dreborier at gmail.com>
> wrote:
>
>> Hi Gunnar,
>>
>>  at the moment I cannot figure out any problem or anything you are
>> missing,
>> the solution seems good :)
>>
>>
>>
>>
>>
>> On 30 April 2015 at 09:08, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> > Steve, Andrea,
>> >
>> > For OGM we need to store certain data in the scope of a transaction;
>> > specifically this is the list of applied "grid dialect operations", so
>> we
>> > can present these to the user upon failures (and thus "rollbacks") on
>> > non-transactional backends.
>> >
>> > Until now we used a custom org.hibernate.Transaction impl for keeping
>> this
>> > data. I am now looking into using the new TransactionCoordinator
>> approach
>> > instead. Is it a save route to initialise the required context upon
>> first
>> > invocation of MyTransactionCoordinator#getTransactionDriverControl() and
>> > clear it via TransactionObserver#afterCompletion()?
>> >
>> > It works fine for me in our tests, but I'd like to make sure I am not
>> > missing anything :)
>> >
>> > Thanks,
>> >
>> > --Gunnar
>> > _______________________________________________
>> > 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
>>
>
>

From gunnar at hibernate.org  Thu Apr 30 08:19:57 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 30 Apr 2015 14:19:57 +0200
Subject: [hibernate-dev] Any change of adding generics to Hibernate
 specific API
In-Reply-To: <CAFdSV9vyMCTKQrMEEXReg7b92Z3j26wwBgopNtsKoW9Z3_g0kQ@mail.gmail.com>
References: <227323507.3861546.1429129650656.JavaMail.yahoo@mail.yahoo.com>
	<B795FDE4-48C0-4C76-A39C-388C017F8013@hibernate.org>
	<CAFdSV9spbu7L4tXnFOFinNt+8JYjowVGbc0O0R38e2MB3xzA-w@mail.gmail.com>
	<CAFdSV9uMb_57_CD2bJP34hM9pctaKyRZOsZ1+7+MyGADD31CXQ@mail.gmail.com>
	<CADGJaX_WEea6jnxgfykf82_MX4RcohviSBtfuvJfRCpw+SRBvg@mail.gmail.com>
	<CAFdSV9vyMCTKQrMEEXReg7b92Z3j26wwBgopNtsKoW9Z3_g0kQ@mail.gmail.com>
Message-ID: <CADGJaX-XqOFxF3SnADvXRdn6hqaSMg0HxSdBPeAphHuGTp4nzQ@mail.gmail.com>

No problem, just pay me a drink next time we meet ;)

2015-04-30 13:25 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Indeed that is it.  Thanks for finding it, that was a task for me for
> today! :)
>
> On Thu, Apr 30, 2015 at 1:57 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Looks like that's the previous discussion Steve was referring to:
>> http://lists.jboss.org/pipermail/hibernate-dev/2012-January/007625.html
>>
>> 2015-04-30 5:41 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> https://hibernate.atlassian.net/browse/HHH-9761
>>>
>>> On Wed, Apr 29, 2015 at 8:16 AM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>> > We discussed this before on the list.  The main thing to decide is
>>> > Session#load and proxies.  Basically there are times when:
>>> >
>>> > public T load(Class<T> entityType, Object id)
>>> >
>>> > simply will not work.  This is the discussion I started wrt annotating
>>> the
>>> > proxy interface, rather than the impl class.
>>> >
>>> > Basically I am not going to do this work piecemeal.  When we add
>>> typing, I
>>> > will add it everywhere at once.  So as soon as we can come up with an
>>> > elegant solution for that, I can add that to the roadmap.  And please
>>> see
>>> > the previous discussion before we just start re-hashing the same points
>>> > over and over :)  It was a quite long thread.
>>> >
>>> >
>>> > On Wed, Apr 29, 2015 at 4:14 AM, Emmanuel Bernard <
>>> emmanuel at hibernate.org>
>>> > wrote:
>>> >
>>> >> Hi Vlad,
>>> >>
>>> >> That?s an interesting proposal. It is certainly possible. But since
>>> the
>>> >> Session and Query API (Hibernate native) is historically non typed, I
>>> >> wonder if that is worth introducing these new typed version and add
>>> more
>>> >> overloaded methods on Session.
>>> >> Do you think it is worth the additional complexity?
>>> >>
>>> >> Steve, do you have some plan for a Session API revamp some time in the
>>> >> future? Some spring cleaning of sort.
>>> >>
>>> >> Emmanuel
>>> >>
>>> >>
>>> >> > On 15 Apr 2015, at 22:27, Mihalcea Vlad <mih_vlad at yahoo.com> wrote:
>>> >> >
>>> >> > Hi,
>>> >> > Although many rely on the Java Persistence API, Hibernate still
>>> offers
>>> >> specific features, like mapping a native SQLQuery result set to a DTO:
>>> >> > .setResultTransformer(Transformers.aliasToBean(DTO.class));
>>> >> > Is it possible to add TypedQuery and TypedSQLQuery, analogous to the
>>> >> JPA specs, so you can use generics with specific API?
>>> >> > Adding new interfaces and some overloaded Session methods wouldn't
>>> >> break backward compatibility.
>>> >> >
>>> >> > Vlad MiIhalcea
>>> >> > _______________________________________________
>>> >> > 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
>>> >
>>> >
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From martinbraun123 at aol.com  Thu Apr 30 09:06:35 2015
From: martinbraun123 at aol.com (Martin Braun)
Date: Thu, 30 Apr 2015 09:06:35 -0400
Subject: [hibernate-dev] Google Summer of Code 2015
Message-ID: <14d0a6f97e8-7ee5-5c6b@webprd-m96.mail.aol.com>

Hi there,


I am happy to announce that I will be participating in this years Google Summer of Code working on Hibernate Search.


My project's goal is to make Hibernate Search able to work with other JPA implementors than Hibernate ORM. I have written
a short introduction about me and the project on my blog:


http://hibernatesearchandjpa.blogspot.de/


I am really looking forward to working with you all and please let me know about your thoughts on this project! :)


mfg


Martin Braun
martinbraun123 at aol.com
www.github.com/s4ke


From emmanuel at hibernate.org  Thu Apr 30 09:26:19 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 30 Apr 2015 15:26:19 +0200
Subject: [hibernate-dev] Google Summer of Code 2015
In-Reply-To: <14d0a6f97e8-7ee5-5c6b@webprd-m96.mail.aol.com>
References: <14d0a6f97e8-7ee5-5c6b@webprd-m96.mail.aol.com>
Message-ID: <406272E1-D0AE-4A37-B67E-5F1B9B85B3D9@hibernate.org>

Nice :)

> On 30 Apr 2015, at 15:06, Martin Braun <martinbraun123 at aol.com> wrote:
> 
> Hi there,
> 
> 
> I am happy to announce that I will be participating in this years Google Summer of Code working on Hibernate Search.
> 
> 
> My project's goal is to make Hibernate Search able to work with other JPA implementors than Hibernate ORM. I have written
> a short introduction about me and the project on my blog:
> 
> 
> http://hibernatesearchandjpa.blogspot.de/
> 
> 
> I am really looking forward to working with you all and please let me know about your thoughts on this project! :)
> 
> 
> mfg
> 
> 
> Martin Braun
> martinbraun123 at aol.com
> www.github.com/s4ke
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev