Re: [hibernate-dev] Release YML
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 : > 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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
2015-04-01 2:21 GMT+02:00 Steve Ebersole : > 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 > 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 > > 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 wrote: > >> > Ahh, seems this may be an option to work around it: > >> > > >> > > >> > 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. > >> > > >> > > >> > I had missed that part. > >> > > >> > > >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole > >> wrote: > >> > > >> >> When I say "internal" here, I mean internal to java classes. > >> >> > >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole > > >> >> 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 < > >> paranoia...@gmail.com> > >> >>> wrote: > >> >>> > >> According to this: > >> > >> https://gist.github.com/AlainODea/1375759b8720a3f9f094 > >> > >> Notably the Java 1.7 *ConcurrentHashMap#keySet()* returns a Set > >> while > >> the 1.8*ConcurrentHashMap#keySet()* returns a > >> ConcurrentHashMap.KeySetView`. > >> > >> I think you're using some Java8 API. > >> > >> > >> 2015-04-01 2:25 GMT+03:00 Petar Tahchiev : > >> > >> > petar@petar-ThinkPad-X1-Carbon:~$ java -version > >> > java version "1.7.0_71" > >> > Java(TM) SE Runtime Environment (build 1.7.0_71-b14) > >> > Java HotSpot(TM) 64-Bit Server VM (build 24.71-b01, mixed mode) > >> > petar
Re: [hibernate-dev] Release YML
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 pgpxuPTXRoBXk.pgp Description: PGP signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
> 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 : > 2015-04-01 2:21 GMT+02:00 Steve Ebersole : > >> 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 >> 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 >> > 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 wrote: >> >> > Ahh, seems this may be an option to work around it: >> >> > >> >> > >> >> > 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. >> >> > >> >> > >> >> > I had missed that part. >> >> > >> >> > >> >> > On Tue, Mar 31, 2015 at 6:34 PM, Steve Ebersole > > >> >> wrote: >> >> > >> >> >> When I say "internal" here, I mean internal to java classes. >> >> >> >> >> >> On Tue, Mar 31, 2015 at 6:30 PM, Steve Ebersole < >> st...@hibernate.org> >> >> >> wrote: >> >> >> >> >> >>> Nope. It just effects any code comp
[hibernate-dev] document update change?
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] document update change?
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 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
One other thing I noticed: hibernate-core-5 depends on org.jboss.logging jboss-logging 3.2.1.Final and if you have hibernate-validator 5.1.3.Final (the last stable), it will depend on org.jboss.logging jboss-logging 3.1.4.GA 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 : > 2015-04-01 2:21 GMT+02:00 Steve Ebersole : > > > 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 > > 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. > > > > >
Re: [hibernate-dev] document update change?
> 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 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 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 :
> One other thing I noticed:
> hibernate-core-5 depends on
>
> org.jboss.logging
> jboss-logging
> 3.2.1.Final
>
> and if you have hibernate-validator 5.1.3.Final (the last stable), it will
> depend on
>
> org.jboss.logging
> jboss-logging
> 3.1.4.GA
>
> 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 ins
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 wrote: > One other thing I noticed: > hibernate-core-5 depends on > > org.jboss.logging > jboss-logging > 3.2.1.Final > > and if you have hibernate-validator 5.1.3.Final (the last stable), it will > depend on > > org.jboss.logging > jboss-logging > 3.1.4.GA > > 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 : > >> 2015-04-01 2:21 GMT+02:00 Steve Ebersole : >> >> > 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 >> > 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 it
Re: [hibernate-dev] document update change?
On 1 April 2015 at 11:39, Ales Justin 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 > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 : > 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 wrote: > > One other thing I noticed: > > hibernate-core-5 depends on > > > > org.jboss.logging > > jboss-logging > > 3.2.1.Final > > > > and if you have hibernate-validator 5.1.3.Final (the last stable), it > will > > depend on > > > > org.jboss.logging > > jboss-logging > > 3.1.4.GA > > > > 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 : > > > >> 2015-04-01 2:21 GMT+02:00 Steve Ebersole : > >> > >> > 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 > >> > 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
Re: [hibernate-dev] document update change?
>>> 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 ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 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
> 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 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 :
>>
>>> One other thing I noticed:
>>> hibernate-core-5 depends on
>>>
>>> org.jboss.logging
>>> jboss-logging
>>> 3.2.1.Final
>>>
>>> and if you have hibernate-validator 5.1.3.Final (the last stable), it
>>> will depend on
>>>
>>> org.jboss.logging
>>> jboss-logging
>>> 3.1.4.GA
>>>
>>> So you will get an exception of method not found on some jboss-logging
>>> API. I excluded the jboss-loggin f
Re: [hibernate-dev] Release YML
No. You know why it could not find the POM ;) On Wed, Apr 1, 2015 at 2:26 AM, 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?). > > 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 : > >> 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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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
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 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 :
>
>> One other thing I noticed:
>> hibernate-core-5 depends on
>>
>> org.jboss.logging
>> jboss-logging
>> 3.2.1.Final
>>
>> and if you have hibernate-validator 5.1.3.Final (the last stable), it
>> will depend on
>>
>> org.jboss.logging
>> jboss-logging
>> 3.1.4.GA
>>
>> 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
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 pgp5Y67nlUmk0.pgp Description: PGP signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Java 6, 7 and 8... oh my!
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 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 : > >> 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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Java 6, 7 and 8... oh my!
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 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 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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 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
> 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
>> 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 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 :
>>>
One other thing I noticed:
hibernate
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
https://hibernate.atlassian.net/browse/HHH-9704
On Wed, Apr 1, 2015 at 6:20 AM, Steve Ebersole 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
> 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
>> 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 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 :
>>>
One other thing I noticed:
hibernate-core-5 depends on
org.jboss.logging
jboss-logging
3.2.1.Final
and if you hav
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 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 : > >> 2015-04-01 2:21 GMT+02:00 Steve Ebersole : >> >>> 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 >>> 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 >>> > 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 wrote: >>> >> > Ahh, seems this may be an option to work around it: >>> >> > >>> >> > >>> >> > Using the general *Map* interface in place of the concrete >>> >> > *ConcurrentHashMap* type here side-steps the coupling to the Java 8 >>> >> return >>> >> >
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 : > 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 > 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 : >> >>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole : >>> 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 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 >>> > > 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 n
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 :
>
> 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
> 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
>> 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
>>> 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 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);
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
Gunnar, it is applied. Add something that is java 8 specific and see... On Apr 1, 2015 7:59 AM, "Gunnar Morling" 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 : > >> 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 >> 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 : >>> 2015-04-01 2:21 GMT+02:00 Steve Ebersole : > 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 > 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 < > sa...@hibernate.org> > > wrote: >
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 : > Gunnar, it is applied. Add something that is java 8 specific and see... > On Apr 1, 2015 7:59 AM, "Gunnar Morling" 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 : >> >>> 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 >>> 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 : > 2015-04-01 2:21 GMT+02:00 Steve Ebersole : > >> 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 >> 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
Re: [hibernate-dev] Release YML
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 pgpORUB6rPYNs.pgp Description: PGP signature ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Release YML
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 : > 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 > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Trying Hibernate 5.0.0.Beta1
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 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 : > >> Gunnar, it is applied. Add something that is java 8 specific and see... >> On Apr 1, 2015 7:59 AM, "Gunnar Morling" 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 : >>> 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 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 : > >> 2015-04-01 2:21 GMT+02:00 Steve Ebersole : >> >>> 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 >>> 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 >>>
Re: [hibernate-dev] Java 6, 7 and 8... oh my!
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 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
> 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 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@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
