From steve at hibernate.org Tue Jul 1 12:39:18 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 1 Jul 2014 11:39:18 -0500
Subject: [hibernate-dev] IRC Developer Meeting
Message-ID:
Discussed EntityEntry/EntityKey memory enhancements and continued
JdbcSession design discussion...
[11:37] Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-01-14.41.html
[11:37] Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-01-14.41.txt
[11:37] Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-01-14.41.log.html
From sanne at hibernate.org Tue Jul 1 13:54:50 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 1 Jul 2014 19:54:50 +0200
Subject: [hibernate-dev] Thread-Safety of NoopOptimizer
Message-ID:
I'm trying to understand if the NoopOptimizer could drop the
"synchronized" at line 53.
I added the synchronization myself some months ago, when we discovered
that we could remove a level of synchronization which was more coarse
grained, but then when inspecting the safety of the various smaller
parts, when hitting the NoopOptimizer I wasn't too sure - as the
AccessCallback is pluggable - and opted to be safe rather than sorry
as I thought this Optimizer would not be used in a high-performance
use case.
It seems I was wrong an some people actually use this Optimizer in a
scenario needing high scalability, and this one also happens to be the
default Optimizer.
By looking at all AccessCallback implementors in the ORM codebase, it
looks like safe to remove the synchronization, but are there reliable
tests I could use to verify this?
There are some more optimisations that come to mind when looking into
the various Optimizer and Generator implementors, but I don't feel
comfortable into changing these without running some stress tests.
TiA,
Sanne
From smarlow at redhat.com Wed Jul 2 14:36:54 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 02 Jul 2014 14:36:54 -0400
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To:
References:
Message-ID: <53B45146.3030507@redhat.com>
On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
>
> I give Gradle 1GB
>
> export GRADLE_OPTS="-Xmx1024M"
Are you on master or an earlier ORM branch? I have
GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
takes all available CPU (feels like my ThinkPad is on its knees until
the build completes).
>
> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
> To work around that I forced Gradle to use one thread
>
> ./gradlew -no-daemon --parallel-threads 1 clean test
Thanks for the tip, I will try this.
>
> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From smarlow at redhat.com Wed Jul 2 15:43:22 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 02 Jul 2014 15:43:22 -0400
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <53B45146.3030507@redhat.com>
References:
<53B45146.3030507@redhat.com>
Message-ID: <53B460DA.9010005@redhat.com>
On 07/02/2014 02:36 PM, Scott Marlow wrote:
> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
>>
>> I give Gradle 1GB
>>
>> export GRADLE_OPTS="-Xmx1024M"
>
> Are you on master or an earlier ORM branch? I have
> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
> takes all available CPU (feels like my ThinkPad is on its knees until
> the build completes).
For me, when I run the testsuite on the master branch, my cpu gets
pegged at 100% utilization.
>
>
>>
>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
>> To work around that I forced Gradle to use one thread
>>
>> ./gradlew -no-daemon --parallel-threads 1 clean test
>
> Thanks for the tip, I will try this.
This (-no-daemon --parallel-threads 1) didn't help me. Eventually, the
testsuite will complete but it seems to take a long time (45 minutes or
so). I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
>
>>
>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
>> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>>
>> Emmanuel
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From smarlow at redhat.com Wed Jul 2 17:24:01 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 02 Jul 2014 17:24:01 -0400
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <53B460DA.9010005@redhat.com>
References: <53B45146.3030507@redhat.com>
<53B460DA.9010005@redhat.com>
Message-ID: <53B47871.5000102@redhat.com>
I removed GRADLE_OPTS and ran again with "-no-daemon --parallel-threads
1" and my laptop still pegged the cpu at 100% but seemed a little more
responsive. From running TOP, I could see that six or seven separate
Java processes are running (if each one is taking up to 1gig of memory
on my 8 gig laptop, that could explain why I'm seeing thrashing).
On 07/02/2014 03:43 PM, Scott Marlow wrote:
> On 07/02/2014 02:36 PM, Scott Marlow wrote:
>> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
>>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
>>>
>>> I give Gradle 1GB
>>>
>>> export GRADLE_OPTS="-Xmx1024M"
>>
>> Are you on master or an earlier ORM branch? I have
>> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
>> takes all available CPU (feels like my ThinkPad is on its knees until
>> the build completes).
>
> For me, when I run the testsuite on the master branch, my cpu gets
> pegged at 100% utilization.
>
>>
>>
>>>
>>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
>>> To work around that I forced Gradle to use one thread
>>>
>>> ./gradlew -no-daemon --parallel-threads 1 clean test
>>
>> Thanks for the tip, I will try this.
>
> This (-no-daemon --parallel-threads 1) didn't help me. Eventually, the
> testsuite will complete but it seems to take a long time (45 minutes or
> so). I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
>
>>
>>>
>>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
>>> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>>>
>>> Emmanuel
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From emmanuel at hibernate.org Thu Jul 3 12:03:26 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 3 Jul 2014 18:03:26 +0200
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <53B460DA.9010005@redhat.com>
References:
<53B45146.3030507@redhat.com> <53B460DA.9010005@redhat.com>
Message-ID:
For me the test suite would not even complete, it would hang after ~2500 tests with 0 CPU usage for ever without the --parallel-threads 1 option so it?s a matter of life and death for my setup ;)
With that option, it runs in about 7 to 10 mins I think (I have a SSD and 16 GB of ram).
On 02 Jul 2014, at 21:43, Scott Marlow wrote:
> On 07/02/2014 02:36 PM, Scott Marlow wrote:
>> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
>>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
>>>
>>> I give Gradle 1GB
>>>
>>> export GRADLE_OPTS="-Xmx1024M"
>>
>> Are you on master or an earlier ORM branch? I have
>> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
>> takes all available CPU (feels like my ThinkPad is on its knees until
>> the build completes).
>
> For me, when I run the testsuite on the master branch, my cpu gets pegged at 100% utilization.
>
>>
>>
>>>
>>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
>>> To work around that I forced Gradle to use one thread
>>>
>>> ./gradlew -no-daemon --parallel-threads 1 clean test
>>
>> Thanks for the tip, I will try this.
>
> This (-no-daemon --parallel-threads 1) didn't help me. Eventually, the testsuite will complete but it seems to take a long time (45 minutes or so). I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
>
>>
>>>
>>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
>>> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>>>
>>> Emmanuel
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
From steve at hibernate.org Thu Jul 3 13:37:34 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 3 Jul 2014 12:37:34 -0500
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To:
References:
<53B45146.3030507@redhat.com> <53B460DA.9010005@redhat.com>
Message-ID:
I've mentioned the sheer number of "expected failures" on master now
multiple times on IRC during meetings. I think that is a large reason for
the time/perf issues running the testsuite on master. I have also
mentioned the flag that controls this behavior each time. Have any of
y'all tried that top see if that helps you?
On Thu, Jul 3, 2014 at 11:03 AM, Emmanuel Bernard
wrote:
> For me the test suite would not even complete, it would hang after ~2500
> tests with 0 CPU usage for ever without the --parallel-threads 1 option so
> it?s a matter of life and death for my setup ;)
> With that option, it runs in about 7 to 10 mins I think (I have a SSD and
> 16 GB of ram).
>
>
> On 02 Jul 2014, at 21:43, Scott Marlow wrote:
>
> > On 07/02/2014 02:36 PM, Scott Marlow wrote:
> >> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
> >>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X
> and IntelliJ IDEA so here are a few tidbits:
> >>>
> >>> I give Gradle 1GB
> >>>
> >>> export GRADLE_OPTS="-Xmx1024M"
> >>
> >> Are you on master or an earlier ORM branch? I have
> >> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
> >> takes all available CPU (feels like my ThinkPad is on its knees until
> >> the build completes).
> >
> > For me, when I run the testsuite on the master branch, my cpu gets
> pegged at 100% utilization.
> >
> >>
> >>
> >>>
> >>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core
> subsystem. Basically at least one of the worker hangs for ever.
> >>> To work around that I forced Gradle to use one thread
> >>>
> >>> ./gradlew -no-daemon --parallel-threads 1 clean test
> >>
> >> Thanks for the tip, I will try this.
> >
> > This (-no-daemon --parallel-threads 1) didn't help me. Eventually, the
> testsuite will complete but it seems to take a long time (45 minutes or
> so). I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
> >
> >>
> >>>
> >>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both
> to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that
> is to use `./gradlew idea` and open the project in the IDE. You then have
> to manually add the generated source directory in a few modules.
> >>> Things are explained here:
> https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
> >>>
> >>> Emmanuel
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From emmanuel at hibernate.org Mon Jul 7 09:35:20 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 7 Jul 2014 15:35:20 +0200
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To:
References:
<53B45146.3030507@redhat.com> <53B460DA.9010005@redhat.com>
Message-ID:
Ah interesting. I do not remember such a discussion but I am not at all meetings. Is there a pointer to one of them?
On 03 Jul 2014, at 19:37, Steve Ebersole wrote:
> I've mentioned the sheer number of "expected failures" on master now multiple times on IRC during meetings. I think that is a large reason for the time/perf issues running the testsuite on master. I have also mentioned the flag that controls this behavior each time. Have any of y'all tried that top see if that helps you?
>
>
> On Thu, Jul 3, 2014 at 11:03 AM, Emmanuel Bernard wrote:
> For me the test suite would not even complete, it would hang after ~2500 tests with 0 CPU usage for ever without the --parallel-threads 1 option so it?s a matter of life and death for my setup ;)
> With that option, it runs in about 7 to 10 mins I think (I have a SSD and 16 GB of ram).
>
>
> On 02 Jul 2014, at 21:43, Scott Marlow wrote:
>
> > On 07/02/2014 02:36 PM, Scott Marlow wrote:
> >> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
> >>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X and IntelliJ IDEA so here are a few tidbits:
> >>>
> >>> I give Gradle 1GB
> >>>
> >>> export GRADLE_OPTS="-Xmx1024M"
> >>
> >> Are you on master or an earlier ORM branch? I have
> >> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
> >> takes all available CPU (feels like my ThinkPad is on its knees until
> >> the build completes).
> >
> > For me, when I run the testsuite on the master branch, my cpu gets pegged at 100% utilization.
> >
> >>
> >>
> >>>
> >>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core subsystem. Basically at least one of the worker hangs for ever.
> >>> To work around that I forced Gradle to use one thread
> >>>
> >>> ./gradlew -no-daemon --parallel-threads 1 clean test
> >>
> >> Thanks for the tip, I will try this.
> >
> > This (-no-daemon --parallel-threads 1) didn't help me. Eventually, the testsuite will complete but it seems to take a long time (45 minutes or so). I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
> >
> >>
> >>>
> >>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that is to use `./gradlew idea` and open the project in the IDE. You then have to manually add the generated source directory in a few modules.
> >>> Things are explained here: https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
> >>>
> >>> Emmanuel
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From etienne.miret at ens-lyon.org Mon Jul 7 14:29:03 2014
From: etienne.miret at ens-lyon.org (Etienne Miret)
Date: Mon, 7 Jul 2014 20:29:03 +0200
Subject: [hibernate-dev] Gradle not running some unit tests
Message-ID:
Hello all,
Willing to investigate some Hibernate bugs, I downloaded the sources (from github), compiled them and ran unit tests. I used the provided Gradle wrapper to compile and run the tests. However, hibernate-core/target/reports/tests/index.html reports a number of test classes as not containing any tests. I mainly looked at org.hibernate.test.cut.CompositeUserTypeTest, and I can tell that:
* it contains two method annotated with @org.junit.Test
* it extends org.hibernate.testing.junit4.BaseUnitTestCase
(through BaseCoreFunctionalTestCase), which has a
@org.junit.runner.RunWith annotation.
>From what I know of Gradle, this is enough to have the tests detected and ran. And actually, those tests *are* detected and ran on branch 4.2. But on branch master, this test class appears in the report with 0 tests within.
Does anyone know why those tests are missing from the report?
In case this is of any help, here is the output of ./gradle --version:
------------------------------------------------------------
Gradle 1.9
------------------------------------------------------------
Build time: 2013-11-19 08:20:02 UTC
Build number: none
Revision: 7970ec3503b4f5767ee1c1c69f8b4186c4763e3d
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy: 2.2.0
JVM: 1.7.0_60 (Oracle Corporation 24.60-b09)
OS: Mac OS X 10.9.4 x86_64
Regards,
--
Etienne Miret
From brmeyer at redhat.com Mon Jul 7 17:36:18 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Mon, 7 Jul 2014 17:36:18 -0400 (EDT)
Subject: [hibernate-dev] Hibernate ORM/Validator included in Apache Karaf by
default
In-Reply-To: <1025273615.5253692.1404768513039.JavaMail.zimbra@redhat.com>
Message-ID: <907685510.5261202.1404768978850.JavaMail.zimbra@redhat.com>
FYI, I just learned that the Apache Karaf team has included Hibernate ORM and Hibernate Validator as default system features, starting with Karaf 2.4.x, 2.3.4+, and 3.0.x. I'd call that a big vote of confidence for Hibernate OSGi. So, thanks to everyone who helped make that a reality!
https://issues.apache.org/jira/browse/KARAF-2666
https://issues.apache.org/jira/browse/KARAF-2746
https://issues.apache.org/jira/browse/KARAF-2751
From sanne at hibernate.org Mon Jul 7 18:21:36 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 7 Jul 2014 23:21:36 +0100
Subject: [hibernate-dev] Hibernate ORM/Validator included in Apache
Karaf by default
In-Reply-To: <907685510.5261202.1404768978850.JavaMail.zimbra@redhat.com>
References: <1025273615.5253692.1404768513039.JavaMail.zimbra@redhat.com>
<907685510.5261202.1404768978850.JavaMail.zimbra@redhat.com>
Message-ID:
Congratulations!
Now let's fix the missing projects :-)
On 7 July 2014 22:36, Brett Meyer wrote:
> FYI, I just learned that the Apache Karaf team has included Hibernate ORM and Hibernate Validator as default system features, starting with Karaf 2.4.x, 2.3.4+, and 3.0.x. I'd call that a big vote of confidence for Hibernate OSGi. So, thanks to everyone who helped make that a reality!
>
> https://issues.apache.org/jira/browse/KARAF-2666
> https://issues.apache.org/jira/browse/KARAF-2746
> https://issues.apache.org/jira/browse/KARAF-2751
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
From sanne at hibernate.org Mon Jul 7 19:21:00 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 Jul 2014 00:21:00 +0100
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
Message-ID:
Hi all,
I'm looking forward to a release of Hibernate ORM 4.3, especially
after my fix for Service loading under OSGi gets integrated (HHH-9258
is slowing down progress on Search).
I see it has been a long while since 4.3.5.Final.
Assuming that gets integrated quickly, could we also plan for a release please?
Cheers,
Sanne
From sanne at hibernate.org Tue Jul 8 06:49:53 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 Jul 2014 11:49:53 +0100
Subject: [hibernate-dev] SearchFactory API exposes Class type for entity
Message-ID:
When I started refactoring the Search code towards free-form I simply
started to remove all references to Class and replace them with
TypeIdentifier, essentially working only on hibernate-search-engine
and closing the ORM integration modules which don't need to be
affected.
The SearchFactory interface however is meant as public API and exposes
Class in its signatures to identify specific entity types (I'll use
"entity" in its conceptual meaning): for example we have
void optimize(Class entityType);
Since not only Hibernate Search / ORM will be using Class &
annotations, I could split out the SearchFactory and its default
"class to index mapping" strategies into a separate module, or I could
just keep it there: public API but ignored in case of different
integrations?
I think I'll leave it there for now, but early comments are welcome.
Sanne
From steve at hibernate.org Tue Jul 8 10:50:01 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 8 Jul 2014 09:50:01 -0500
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To:
References:
Message-ID:
Gail was going to work on this. IIRC she was waiting to finish the merge
work she was doing. Gail?
On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero wrote:
> Hi all,
> I'm looking forward to a release of Hibernate ORM 4.3, especially
> after my fix for Service loading under OSGi gets integrated (HHH-9258
> is slowing down progress on Search).
>
> I see it has been a long while since 4.3.5.Final.
> Assuming that gets integrated quickly, could we also plan for a release
> please?
>
> Cheers,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From steve at hibernate.org Tue Jul 8 11:52:51 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 8 Jul 2014 10:52:51 -0500
Subject: [hibernate-dev] IRC Developer Meeting - 7/8
Message-ID:
Mostly more design discussion of JdbcSession
[10:49] Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-08-14.42.html
[10:49] Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-08-14.42.txt
[10:49] Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-07-08-14.42.log.html
From gbadner at redhat.com Tue Jul 8 15:53:11 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 8 Jul 2014 15:53:11 -0400 (EDT)
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
problem
Message-ID: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads having a different ContextClassLoader (CCL) than their caller. As a result, SerializableBlobProxy.generateProxy() throws IllegalArgumentException because WrappedBlob is not found. The same happens for SerializableClobProxy.generateProxy() because WrappedClob is not found.
IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate 5.
I'm looking for either a fix or workaround for this in Hibernate 4.2.x and 4.3.x.
A) A possible fix for HHH-8310 suggests using the ClassLoader returned by WrappedBlob.class.getClassLoader(). Could this somehow get an unintended ClassLoader?
B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.
Which would be more appropriate?
Thanks,
Gail
[1] https://hibernate.atlassian.net/browse/HHH-8310
[2] https://jira.spring.io/browse/SPR-11125
From sanne at hibernate.org Tue Jul 8 16:20:30 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 8 Jul 2014 21:20:30 +0100
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
problem
In-Reply-To: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
Message-ID:
On 8 July 2014 20:53, Gail Badner wrote:
> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads having a different ContextClassLoader (CCL) than their caller. As a result, SerializableBlobProxy.generateProxy() throws IllegalArgumentException because WrappedBlob is not found. The same happens for SerializableClobProxy.generateProxy() because WrappedClob is not found.
>
> IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate 5.
>
> I'm looking for either a fix or workaround for this in Hibernate 4.2.x and 4.3.x.
>
> A) A possible fix for HHH-8310 suggests using the ClassLoader returned by WrappedBlob.class.getClassLoader(). Could this somehow get an unintended ClassLoader?
I'd use this approach, you could only get an unintended ClassLoader if
there are duplicates exposed on the same classpath, but in such a case
nothing would work correctly anyway.
Sanne
>
> B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.
>
> Which would be more appropriate?
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/browse/HHH-8310
> [2] https://jira.spring.io/browse/SPR-11125
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
From smarlow at redhat.com Tue Jul 8 17:04:34 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 08 Jul 2014 17:04:34 -0400
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
problem
In-Reply-To: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
Message-ID: <53BC5CE2.6040904@redhat.com>
This sounds similar to https://community.jboss.org/message/879546
On 07/08/2014 03:53 PM, Gail Badner wrote:
> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads having a different ContextClassLoader (CCL) than their caller. As a result, SerializableBlobProxy.generateProxy() throws IllegalArgumentException because WrappedBlob is not found. The same happens for SerializableClobProxy.generateProxy() because WrappedClob is not found.
>
> IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate 5.
>
> I'm looking for either a fix or workaround for this in Hibernate 4.2.x and 4.3.x.
>
> A) A possible fix for HHH-8310 suggests using the ClassLoader returned by WrappedBlob.class.getClassLoader(). Could this somehow get an unintended ClassLoader?
>
> B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.
>
> Which would be more appropriate?
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/browse/HHH-8310
> [2] https://jira.spring.io/browse/SPR-11125
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From smarlow at redhat.com Tue Jul 8 17:19:50 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 08 Jul 2014 17:19:50 -0400
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
problem
In-Reply-To: <53BC5CE2.6040904@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
<53BC5CE2.6040904@redhat.com>
Message-ID: <53BC6076.2010305@redhat.com>
On 07/08/2014 05:04 PM, Scott Marlow wrote:
> This sounds similar to https://community.jboss.org/message/879546
I was hoping to hear more feedback from the above link but didn't. I
suspect that its a classloader issue with ear sub-deployments having
Hibernate on their classpath but not the ear top level classloader.
>
> On 07/08/2014 03:53 PM, Gail Badner wrote:
>> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads having a different ContextClassLoader (CCL) than their caller. As a result, SerializableBlobProxy.generateProxy() throws IllegalArgumentException because WrappedBlob is not found. The same happens for SerializableClobProxy.generateProxy() because WrappedClob is not found.
>>
>> IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate 5.
>>
>> I'm looking for either a fix or workaround for this in Hibernate 4.2.x and 4.3.x.
>>
>> A) A possible fix for HHH-8310 suggests using the ClassLoader returned by WrappedBlob.class.getClassLoader(). Could this somehow get an unintended ClassLoader?
Good question but this change might impact HHH-8010. Might be good to
check with Brett on why OSGi needs to use an alternative classloader
(which is set in ClassLoaderHelper).
>>
>> B) A workaround is for the caller to initialize ClassLoaderHelper.overridenClassLoader before calling Spring.
I don't think this will work in a multiple deployment environment (e.g.
WildFly) unless ClassLoaderHelper defaulted to the ORM classloader
instead of an application level classloader.
>>
>> Which would be more appropriate?
>>
>> Thanks,
>> Gail
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-8310
>> [2] https://jira.spring.io/browse/SPR-11125
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From gbadner at redhat.com Tue Jul 8 17:40:00 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 8 Jul 2014 17:40:00 -0400 (EDT)
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
problem
In-Reply-To: <53BC6076.2010305@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
<53BC5CE2.6040904@redhat.com> <53BC6076.2010305@redhat.com>
Message-ID: <892665831.8371949.1404855600334.JavaMail.zimbra@redhat.com>
Hi Scott,
I believe the classloading problem you mention is the same. Both BlobProxy.getProxyClassLoader() and SerializableBlobProxy.getProxyClassLoader() return ClassLoaderHelper.getContextClassLoader() if non-null.
Gail
----- Original Message -----
> From: "Scott Marlow"
> To: "Gail Badner" , "hibernate-dev"
> Sent: Tuesday, July 8, 2014 2:19:50 PM
> Subject: Re: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading problem
>
> On 07/08/2014 05:04 PM, Scott Marlow wrote:
> > This sounds similar to https://community.jboss.org/message/879546
>
> I was hoping to hear more feedback from the above link but didn't. I
> suspect that its a classloader issue with ear sub-deployments having
> Hibernate on their classpath but not the ear top level classloader.
>
>
> >
> > On 07/08/2014 03:53 PM, Gail Badner wrote:
> >> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads
> >> having a different ContextClassLoader (CCL) than their caller. As a
> >> result, SerializableBlobProxy.generateProxy() throws
> >> IllegalArgumentException because WrappedBlob is not found. The same
> >> happens for SerializableClobProxy.generateProxy() because WrappedClob is
> >> not found.
> >>
> >> IIUC, this will be fixed by accessing the ClassLoaderService in Hibernate
> >> 5.
> >>
> >> I'm looking for either a fix or workaround for this in Hibernate 4.2.x and
> >> 4.3.x.
> >>
> >> A) A possible fix for HHH-8310 suggests using the ClassLoader returned by
> >> WrappedBlob.class.getClassLoader(). Could this somehow get an unintended
> >> ClassLoader?
>
> Good question but this change might impact HHH-8010. Might be good to
> check with Brett on why OSGi needs to use an alternative classloader
> (which is set in ClassLoaderHelper).
>
> >>
> >> B) A workaround is for the caller to initialize
> >> ClassLoaderHelper.overridenClassLoader before calling Spring.
>
> I don't think this will work in a multiple deployment environment (e.g.
> WildFly) unless ClassLoaderHelper defaulted to the ORM classloader
> instead of an application level classloader.
>
> >>
> >> Which would be more appropriate?
> >>
> >> Thanks,
> >> Gail
> >>
> >> [1] https://hibernate.atlassian.net/browse/HHH-8310
> >> [2] https://jira.spring.io/browse/SPR-11125
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
From gbadner at redhat.com Tue Jul 8 22:39:21 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 8 Jul 2014 22:39:21 -0400 (EDT)
Subject: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading
problem
In-Reply-To: <892665831.8371949.1404855600334.JavaMail.zimbra@redhat.com>
References: <2080879375.8293326.1404849191029.JavaMail.zimbra@redhat.com>
<53BC5CE2.6040904@redhat.com> <53BC6076.2010305@redhat.com>
<892665831.8371949.1404855600334.JavaMail.zimbra@redhat.com>
Message-ID: <982605977.8616050.1404873561795.JavaMail.zimbra@redhat.com>
I heard back from Steve and he agrees that getting the ClassLoader from WrappedBlob.class.getClassLoader() should be fine.
To answer Scott: IIUC, HHH-8010 has to do with using a specified OsgiClassLoader to build a SessionFactory or EntityManagerFactory. Most usages of ClassLoaderHelper.getContextClassLoader() are in fact involved in building the SessionFactory or EntityManagerFactory.
AFAICT, SerializableBlobProxy and SerializableClobProxy are not involved in the process of building a SessionFactory or EntityManagerFactory, so making the suggested change to generate proxies shouldn't impact HHH-8010.
After Scott mentioned the message discussing this same problem with BlobProxy, I found that ClobProxy, NClobProxy, and ResultSetWrapperProxy also prefer ClassLoaderHelper.getContextClassLoader(). I'll make a similar change to their getProxyClassLoader() methods (using the appropriate interface). I've replied to the thread.
I also noticed that ReflectHelper and SerializationHelper use ClassLoaderHelper.getContextClassLoader() and I am guessing there are some uses of these classes that would be susceptible to the same Spring bug. I'm not going to deal with these now though.
Thanks all for the feedback! :)
Gail
----- Original Message -----
> From: "Gail Badner"
> To: "Scott Marlow"
> Cc: "hibernate-dev"
> Sent: Tuesday, July 8, 2014 2:40:00 PM
> Subject: Re: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob classloading problem
>
> Hi Scott,
>
> I believe the classloading problem you mention is the same. Both
> BlobProxy.getProxyClassLoader() and
> SerializableBlobProxy.getProxyClassLoader() return
> ClassLoaderHelper.getContextClassLoader() if non-null.
>
> Gail
>
> ----- Original Message -----
> > From: "Scott Marlow"
> > To: "Gail Badner" , "hibernate-dev"
> >
> > Sent: Tuesday, July 8, 2014 2:19:50 PM
> > Subject: Re: [hibernate-dev] HHH-8310 : WrappedBlob/WrappedClob
> > classloading problem
> >
> > On 07/08/2014 05:04 PM, Scott Marlow wrote:
> > > This sounds similar to https://community.jboss.org/message/879546
> >
> > I was hoping to hear more feedback from the above link but didn't. I
> > suspect that its a classloader issue with ear sub-deployments having
> > Hibernate on their classpath but not the ear top level classloader.
> >
> >
> > >
> > > On 07/08/2014 03:53 PM, Gail Badner wrote:
> > >> HHH-8310 [1] mentions a Spring bug SPR-11125 [2] that results in threads
> > >> having a different ContextClassLoader (CCL) than their caller. As a
> > >> result, SerializableBlobProxy.generateProxy() throws
> > >> IllegalArgumentException because WrappedBlob is not found. The same
> > >> happens for SerializableClobProxy.generateProxy() because WrappedClob is
> > >> not found.
> > >>
> > >> IIUC, this will be fixed by accessing the ClassLoaderService in
> > >> Hibernate
> > >> 5.
> > >>
> > >> I'm looking for either a fix or workaround for this in Hibernate 4.2.x
> > >> and
> > >> 4.3.x.
> > >>
> > >> A) A possible fix for HHH-8310 suggests using the ClassLoader returned
> > >> by
> > >> WrappedBlob.class.getClassLoader(). Could this somehow get an unintended
> > >> ClassLoader?
> >
> > Good question but this change might impact HHH-8010. Might be good to
> > check with Brett on why OSGi needs to use an alternative classloader
> > (which is set in ClassLoaderHelper).
> >
> > >>
> > >> B) A workaround is for the caller to initialize
> > >> ClassLoaderHelper.overridenClassLoader before calling Spring.
> >
> > I don't think this will work in a multiple deployment environment (e.g.
> > WildFly) unless ClassLoaderHelper defaulted to the ORM classloader
> > instead of an application level classloader.
> >
> > >>
> > >> Which would be more appropriate?
> > >>
> > >> Thanks,
> > >> Gail
> > >>
> > >> [1] https://hibernate.atlassian.net/browse/HHH-8310
> > >> [2] https://jira.spring.io/browse/SPR-11125
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> >
> >
>
From gunnar at hibernate.org Wed Jul 9 06:17:40 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 9 Jul 2014 12:17:40 +0200
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To:
References:
Message-ID:
Will this contain the recent improvements for the extra state in
EntityEntry? We need this in OGM to move forward with more intelligent
querying of embedded data for document stores but also for Neo4j.
Thanks,
--Gunnar
2014-07-08 16:50 GMT+02:00 Steve Ebersole :
> Gail was going to work on this. IIRC she was waiting to finish the merge
> work she was doing. Gail?
>
>
> On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero
> wrote:
>
> > Hi all,
> > I'm looking forward to a release of Hibernate ORM 4.3, especially
> > after my fix for Service loading under OSGi gets integrated (HHH-9258
> > is slowing down progress on Search).
> >
> > I see it has been a long while since 4.3.5.Final.
> > Assuming that gets integrated quickly, could we also plan for a release
> > please?
> >
> > Cheers,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From sanne at hibernate.org Wed Jul 9 07:14:51 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 9 Jul 2014 12:14:51 +0100
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To:
References:
Message-ID:
Hi Gunnar,
it's still unclear what effect it's having on the performance of
Hibernate ORM version 4.2-latest, so I had a chat with John and we
agreed that we can treat it optimistically as it's very likely to just
have caused a different effect on some other code area.
So, assuming it's not too late for version 4.3.6, could you push it to
4.3 *only* ?
We can then later decide to backport to 4.2 or not based on more
information, but as you say we need it for OGM anyway so let's push it
to 4.3 and move on.
--Sanne
On 9 July 2014 11:17, Gunnar Morling wrote:
> Will this contain the recent improvements for the extra state in
> EntityEntry? We need this in OGM to move forward with more intelligent
> querying of embedded data for document stores but also for Neo4j.
>
> Thanks,
>
> --Gunnar
>
>
>
>
> 2014-07-08 16:50 GMT+02:00 Steve Ebersole :
>
>> Gail was going to work on this. IIRC she was waiting to finish the merge
>> work she was doing. Gail?
>>
>>
>> On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero
>> wrote:
>>
>> > Hi all,
>> > I'm looking forward to a release of Hibernate ORM 4.3, especially
>> > after my fix for Service loading under OSGi gets integrated (HHH-9258
>> > is slowing down progress on Search).
>> >
>> > I see it has been a long while since 4.3.5.Final.
>> > Assuming that gets integrated quickly, could we also plan for a release
>> > please?
>> >
>> > Cheers,
>> > Sanne
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
From emmanuel at hibernate.org Wed Jul 9 07:24:24 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 9 Jul 2014 13:24:24 +0200
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To:
References:
Message-ID:
We need to address some of Gunnar?s comments on the master PR. He proposed some renaming for example. Gunnar, do you want to take the lead?
On 09 Jul 2014, at 13:14, Sanne Grinovero wrote:
> Hi Gunnar,
> it's still unclear what effect it's having on the performance of
> Hibernate ORM version 4.2-latest, so I had a chat with John and we
> agreed that we can treat it optimistically as it's very likely to just
> have caused a different effect on some other code area.
>
> So, assuming it's not too late for version 4.3.6, could you push it to
> 4.3 *only* ?
>
> We can then later decide to backport to 4.2 or not based on more
> information, but as you say we need it for OGM anyway so let's push it
> to 4.3 and move on.
>
> --Sanne
>
> On 9 July 2014 11:17, Gunnar Morling wrote:
>> Will this contain the recent improvements for the extra state in
>> EntityEntry? We need this in OGM to move forward with more intelligent
>> querying of embedded data for document stores but also for Neo4j.
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>>
>>
>> 2014-07-08 16:50 GMT+02:00 Steve Ebersole :
>>
>>> Gail was going to work on this. IIRC she was waiting to finish the merge
>>> work she was doing. Gail?
>>>
>>>
>>> On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero
>>> wrote:
>>>
>>>> Hi all,
>>>> I'm looking forward to a release of Hibernate ORM 4.3, especially
>>>> after my fix for Service loading under OSGi gets integrated (HHH-9258
>>>> is slowing down progress on Search).
>>>>
>>>> I see it has been a long while since 4.3.5.Final.
>>>> Assuming that gets integrated quickly, could we also plan for a release
>>>> please?
>>>>
>>>> Cheers,
>>>> Sanne
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
From gunnar at hibernate.org Wed Jul 9 08:38:36 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 9 Jul 2014 14:38:36 +0200
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To:
References:
Message-ID:
2014-07-09 13:24 GMT+02:00 Emmanuel Bernard :
> We need to address some of Gunnar?s comments on the master PR. He proposed
> some renaming for example. Gunnar, do you want to take the lead?
>
Yes, I can do the merge to 4.3.
I don't have strong feelings on the renaming, but I'm a bit concerned about
the de-serialization issue. Do we for now just assume that all potential EE
implementations use the same persistent representation? Then always
de-serializing into DefaultEntityEntry as it's currently happening should
be ok.
On 09 Jul 2014, at 13:14, Sanne Grinovero wrote:
>
> > Hi Gunnar,
> > it's still unclear what effect it's having on the performance of
> > Hibernate ORM version 4.2-latest, so I had a chat with John and we
> > agreed that we can treat it optimistically as it's very likely to just
> > have caused a different effect on some other code area.
> >
> > So, assuming it's not too late for version 4.3.6, could you push it to
> > 4.3 *only* ?
> >
> > We can then later decide to backport to 4.2 or not based on more
> > information, but as you say we need it for OGM anyway so let's push it
> > to 4.3 and move on.
> >
> > --Sanne
> >
> > On 9 July 2014 11:17, Gunnar Morling wrote:
> >> Will this contain the recent improvements for the extra state in
> >> EntityEntry? We need this in OGM to move forward with more intelligent
> >> querying of embedded data for document stores but also for Neo4j.
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >>
> >>
> >>
> >>
> >> 2014-07-08 16:50 GMT+02:00 Steve Ebersole :
> >>
> >>> Gail was going to work on this. IIRC she was waiting to finish the
> merge
> >>> work she was doing. Gail?
> >>>
> >>>
> >>> On Mon, Jul 7, 2014 at 6:21 PM, Sanne Grinovero
> >>> wrote:
> >>>
> >>>> Hi all,
> >>>> I'm looking forward to a release of Hibernate ORM 4.3, especially
> >>>> after my fix for Service loading under OSGi gets integrated (HHH-9258
> >>>> is slowing down progress on Search).
> >>>>
> >>>> I see it has been a long while since 4.3.5.Final.
> >>>> Assuming that gets integrated quickly, could we also plan for a
> release
> >>>> please?
> >>>>
> >>>> Cheers,
> >>>> Sanne
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
From gunnar at hibernate.org Wed Jul 9 09:32:53 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 9 Jul 2014 15:32:53 +0200
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To: <53B47871.5000102@redhat.com>
References:
<53B45146.3030507@redhat.com> <53B460DA.9010005@redhat.com>
<53B47871.5000102@redhat.com>
Message-ID:
2014-07-02 23:24 GMT+02:00 Scott Marlow :
> I removed GRADLE_OPTS and ran again with "-no-daemon --parallel-threads
> 1" and my laptop still pegged the cpu at 100% but seemed a little more
> responsive. From running TOP, I could see that six or seven separate
> Java processes are running (if each one is taking up to 1gig of memory
> on my 8 gig laptop, that could explain why I'm seeing thrashing).
>
Did you ever find a way for running the build? My machine basically becomes
nearly unusable due to extremely high CPU usage once I start the build on
master :(
Steve, any pointer on the options/flags recommended to build ORM on master
would be much appreciated. Thanks!
--Gunnar
>
> On 07/02/2014 03:43 PM, Scott Marlow wrote:
> > On 07/02/2014 02:36 PM, Scott Marlow wrote:
> >> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
> >>> I had a lot of hurdles to make Hibernate ORM run and build on Mac OS X
> and IntelliJ IDEA so here are a few tidbits:
> >>>
> >>> I give Gradle 1GB
> >>>
> >>> export GRADLE_OPTS="-Xmx1024M"
> >>
> >> Are you on master or an earlier ORM branch? I have
> >> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
> >> takes all available CPU (feels like my ThinkPad is on its knees until
> >> the build completes).
> >
> > For me, when I run the testsuite on the master branch, my cpu gets
> > pegged at 100% utilization.
> >
> >>
> >>
> >>>
> >>> Gradle hangs on me after ~ 2300 to 2400 tests for hibernate-core
> subsystem. Basically at least one of the worker hangs for ever.
> >>> To work around that I forced Gradle to use one thread
> >>>
> >>> ./gradlew -no-daemon --parallel-threads 1 clean test
> >>
> >> Thanks for the tip, I will try this.
> >
> > This (-no-daemon --parallel-threads 1) didn't help me. Eventually, the
> > testsuite will complete but it seems to take a long time (45 minutes or
> > so). I also tried setting GRADLE_OPTS="-Xmx1024M" but that didn't help.
> >
> >>
> >>>
> >>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried both
> to run IDEA with Java 6 (default) and Java 7 (hacked). The way around that
> is to use `./gradlew idea` and open the project in the IDE. You then have
> to manually add the generated source directory in a few modules.
> >>> Things are explained here:
> https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
> >>>
> >>> Emmanuel
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From emmanuel at hibernate.org Wed Jul 9 12:07:16 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 9 Jul 2014 18:07:16 +0200
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To:
References:
Message-ID:
On 09 Jul 2014, at 14:38, Gunnar Morling wrote:
> 2014-07-09 13:24 GMT+02:00 Emmanuel Bernard :
> We need to address some of Gunnar?s comments on the master PR. He proposed some renaming for example. Gunnar, do you want to take the lead?
>
> Yes, I can do the merge to 4.3.
>
> I don't have strong feelings on the renaming, but I'm a bit concerned about the de-serialization issue. Do we for now just assume that all potential EE implementations use the same persistent representation? Then always de-serializing into DefaultEntityEntry as it's currently happening should be ok.
That has my preference. But we should find a way to make it more explicit.
From smarlow at redhat.com Wed Jul 9 14:09:27 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 09 Jul 2014 14:09:27 -0400
Subject: [hibernate-dev] Gradle, ORM and Mac OS X
In-Reply-To:
References: <53B45146.3030507@redhat.com> <53B460DA.9010005@redhat.com> <53B47871.5000102@redhat.com>
Message-ID: <53BD8557.7000608@redhat.com>
On 07/09/2014 09:32 AM, Gunnar Morling wrote:
> 2014-07-02 23:24 GMT+02:00 Scott Marlow >:
>
> I removed GRADLE_OPTS and ran again with "-no-daemon --parallel-threads
> 1" and my laptop still pegged the cpu at 100% but seemed a little more
> responsive. From running TOP, I could see that six or seven separate
> Java processes are running (if each one is taking up to 1gig of memory
> on my 8 gig laptop, that could explain why I'm seeing thrashing).
>
>
> Did you ever find a way for running the build? My machine basically
> becomes nearly unusable due to extremely high CPU usage once I start the
> build on master :(
I found some relief from setting "export GRADLE_OPTS=". My CPU still
reaches near 100% but my KDE UI seems more responsive.
>
> Steve, any pointer on the options/flags recommended to build ORM on
> master would be much appreciated. Thanks!
>
> --Gunnar
>
>
> On 07/02/2014 03:43 PM, Scott Marlow wrote:
> > On 07/02/2014 02:36 PM, Scott Marlow wrote:
> >> On 06/30/2014 06:27 AM, Emmanuel Bernard wrote:
> >>> I had a lot of hurdles to make Hibernate ORM run and build on
> Mac OS X and IntelliJ IDEA so here are a few tidbits:
> >>>
> >>> I give Gradle 1GB
> >>>
> >>> export GRADLE_OPTS="-Xmx1024M"
> >>
> >> Are you on master or an earlier ORM branch? I have
> >> GRADLE_OPTS="-Xmx1024m -Xms512m" and running the testsuite on Fedora
> >> takes all available CPU (feels like my ThinkPad is on its knees
> until
> >> the build completes).
> >
> > For me, when I run the testsuite on the master branch, my cpu gets
> > pegged at 100% utilization.
> >
> >>
> >>
> >>>
> >>> Gradle hangs on me after ~ 2300 to 2400 tests for
> hibernate-core subsystem. Basically at least one of the worker hangs
> for ever.
> >>> To work around that I forced Gradle to use one thread
> >>>
> >>> ./gradlew -no-daemon --parallel-threads 1 clean test
> >>
> >> Thanks for the tip, I will try this.
> >
> > This (-no-daemon --parallel-threads 1) didn't help me.
> Eventually, the
> > testsuite will complete but it seems to take a long time (45
> minutes or
> > so). I also tried setting GRADLE_OPTS="-Xmx1024M" but that
> didn't help.
> >
> >>
> >>>
> >>> IntelliJ IDEA does not import ORM properly on Mac OS X. I tried
> both to run IDEA with Java 6 (default) and Java 7 (hacked). The way
> around that is to use `./gradlew idea` and open the project in the
> IDE. You then have to manually add the generated source directory in
> a few modules.
> >>> Things are explained here:
> https://community.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
> >>>
> >>> Emmanuel
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
>
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
From gbadner at redhat.com Wed Jul 9 18:07:46 2014
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 9 Jul 2014 18:07:46 -0400 (EDT)
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To:
References:
Message-ID: <449512583.10369329.1404943666419.JavaMail.zimbra@redhat.com>
I don't see HHH-8683 is pushed and resolved.
I will do the release later this evening.
Thanks,
Gail
----- Original Message -----
> From: "Emmanuel Bernard"
> To: "Gunnar Morling"
> Cc: "Hibernate Dev"
> Sent: Wednesday, July 9, 2014 9:07:16 AM
> Subject: Re: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
>
>
> On 09 Jul 2014, at 14:38, Gunnar Morling wrote:
>
> > 2014-07-09 13:24 GMT+02:00 Emmanuel Bernard :
> > We need to address some of Gunnar?s comments on the master PR. He proposed
> > some renaming for example. Gunnar, do you want to take the lead?
> >
> > Yes, I can do the merge to 4.3.
> >
> > I don't have strong feelings on the renaming, but I'm a bit concerned about
> > the de-serialization issue. Do we for now just assume that all potential
> > EE implementations use the same persistent representation? Then always
> > de-serializing into DefaultEntityEntry as it's currently happening should
> > be ok.
>
> That has my preference. But we should find a way to make it more explicit.
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From gbadner at redhat.com Wed Jul 9 19:15:10 2014
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 9 Jul 2014 19:15:10 -0400 (EDT)
Subject: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
In-Reply-To: <449512583.10369329.1404943666419.JavaMail.zimbra@redhat.com>
References:
<449512583.10369329.1404943666419.JavaMail.zimbra@redhat.com>
Message-ID: <1372043681.10413884.1404947710421.JavaMail.zimbra@redhat.com>
Oops, it is there...
----- Original Message -----
> From: "Gail Badner"
> To: "Emmanuel Bernard"
> Cc: "Hibernate Dev"
> Sent: Wednesday, July 9, 2014 3:07:46 PM
> Subject: Re: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
>
> I don't see HHH-8683 is pushed and resolved.
>
> I will do the release later this evening.
>
> Thanks,
> Gail
>
> ----- Original Message -----
> > From: "Emmanuel Bernard"
> > To: "Gunnar Morling"
> > Cc: "Hibernate Dev"
> > Sent: Wednesday, July 9, 2014 9:07:16 AM
> > Subject: Re: [hibernate-dev] Release of Hibernate ORM 4.3.6 ?
> >
> >
> > On 09 Jul 2014, at 14:38, Gunnar Morling wrote:
> >
> > > 2014-07-09 13:24 GMT+02:00 Emmanuel Bernard :
> > > We need to address some of Gunnar?s comments on the master PR. He
> > > proposed
> > > some renaming for example. Gunnar, do you want to take the lead?
> > >
> > > Yes, I can do the merge to 4.3.
> > >
> > > I don't have strong feelings on the renaming, but I'm a bit concerned
> > > about
> > > the de-serialization issue. Do we for now just assume that all potential
> > > EE implementations use the same persistent representation? Then always
> > > de-serializing into DefaultEntityEntry as it's currently happening should
> > > be ok.
> >
> > That has my preference. But we should find a way to make it more explicit.
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
From gbadner at redhat.com Thu Jul 10 02:40:49 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 10 Jul 2014 02:40:49 -0400 (EDT)
Subject: [hibernate-dev] Delaying 4.3.6 until tomorrow
In-Reply-To: <822063939.10746061.1404974394132.JavaMail.zimbra@redhat.com>
Message-ID: <825983463.10746168.1404974449906.JavaMail.zimbra@redhat.com>
I've started making preparations for the 4.3.6 release, but now I can't access the wiki with release instructions.
Since it's getting late anyhow, I'm going to put off releasing until tomorrow.
Gail
From steve at hibernate.org Thu Jul 10 10:40:32 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 10 Jul 2014 09:40:32 -0500
Subject: [hibernate-dev] Delaying 4.3.6 until tomorrow
In-Reply-To: <825983463.10746168.1404974449906.JavaMail.zimbra@redhat.com>
References: <822063939.10746061.1404974394132.JavaMail.zimbra@redhat.com>
<825983463.10746168.1404974449906.JavaMail.zimbra@redhat.com>
Message-ID:
Ping me in the morning if you still can't get to it. Could you just not
see it? Or was something down with JBoss.org?
On Thu, Jul 10, 2014 at 1:40 AM, Gail Badner wrote:
> I've started making preparations for the 4.3.6 release, but now I can't
> access the wiki with release instructions.
>
> Since it's getting late anyhow, I'm going to put off releasing until
> tomorrow.
>
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From gbadner at redhat.com Thu Jul 10 13:19:52 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 10 Jul 2014 13:19:52 -0400 (EDT)
Subject: [hibernate-dev] Delaying 4.3.6 until tomorrow
In-Reply-To:
References: <822063939.10746061.1404974394132.JavaMail.zimbra@redhat.com>
<825983463.10746168.1404974449906.JavaMail.zimbra@redhat.com>
Message-ID: <395446612.11699892.1405012792549.JavaMail.zimbra@redhat.com>
I can see it now. It must have gone down last night.
----- Original Message -----
> From: "Steve Ebersole"
> To: "Gail Badner"
> Cc: "Hibernate Dev"
> Sent: Thursday, July 10, 2014 7:40:32 AM
> Subject: Re: [hibernate-dev] Delaying 4.3.6 until tomorrow
>
> Ping me in the morning if you still can't get to it. Could you just not
> see it? Or was something down with JBoss.org?
>
>
> On Thu, Jul 10, 2014 at 1:40 AM, Gail Badner wrote:
>
> > I've started making preparations for the 4.3.6 release, but now I can't
> > access the wiki with release instructions.
> >
> > Since it's getting late anyhow, I'm going to put off releasing until
> > tomorrow.
> >
> > Gail
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
From gbadner at redhat.com Thu Jul 10 14:43:45 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 10 Jul 2014 14:43:45 -0400 (EDT)
Subject: [hibernate-dev] Scheduling 4.3.6 and 4.2.15 releases for Wednesday,
7/16/14
In-Reply-To: <1017990003.11792037.1405017652575.JavaMail.zimbra@redhat.com>
Message-ID: <406153936.11799871.1405017825086.JavaMail.zimbra@redhat.com>
I am rescheduling the 4.3.6 release for Wednesday next week.
That will give us enough time to do necessary backports to 4.2 and also release 4.2.15.
Regards,
Gail
From davide at hibernate.org Thu Jul 10 17:44:18 2014
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 10 Jul 2014 22:44:18 +0100
Subject: [hibernate-dev] Hibernate OGM 4.1 Beta 5 is out: JP-QL queries for
Neo4j and more
Message-ID:
It's my pleasure to announce a new release of Hibernate OGM.
Hibernate OGM can now convert JP-QL queries into cypher queries when
working with Neo4j. We improved the JSON representation used for
associations in CouchDB and MongoDB making it more concise. We also worked
on several bug fixes and improvements under the hood.
Check out the anonuncement for more details[1].
Davide
[1]
http://in.relation.to/Bloggers/HibernateOGM410Beta5IsOutJPQLQueriesForNeo4jAndMore
From sanne at hibernate.org Fri Jul 11 04:55:20 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 11 Jul 2014 09:55:20 +0100
Subject: [hibernate-dev] Scheduling 4.3.6 and 4.2.15 releases for
Wednesday, 7/16/14
In-Reply-To: <406153936.11799871.1405017825086.JavaMail.zimbra@redhat.com>
References: <1017990003.11792037.1405017652575.JavaMail.zimbra@redhat.com>
<406153936.11799871.1405017825086.JavaMail.zimbra@redhat.com>
Message-ID:
Gail, there are (at least) two other Hibernate projects waiting for that
release. Sad news!
On 10 Jul 2014 19:44, "Gail Badner" wrote:
> I am rescheduling the 4.3.6 release for Wednesday next week.
>
> That will give us enough time to do necessary backports to 4.2 and also
> release 4.2.15.
>
> Regards,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From paranoiabla at gmail.com Fri Jul 11 07:53:18 2014
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 11 Jul 2014 14:53:18 +0300
Subject: [hibernate-dev] Hibernate + Log4J2 Performance Problem
Message-ID:
Hello,
I'm really sorry to post this here but I couldn't find any jboss-logging
mailing list. So here's my question. I'm reading this issue:
https://issues.jboss.org/browse/JBLOGGING-95
and I'm trying to make my hibernate use log4j2. So far I had
org.jboss.loggingjboss-logging-log4j${jboss.logging.version}
and I have log4j -> log4j2 routed. Unfortunately now my hibernate creates a
log4j.log file and log4j prints the messages to the command line (still no
log4j2) :(
So I got rid of this dependency and I added the jboss-logging. So now
here's my set of jars:
hibernate-core
hibernate-entitymanager
hibernate-c3p0
hibernate-validator
log4j2
org.jboss.logging:jboss-logging:jar:3.2.0.Beta1
then I run my task and I get performance of:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 3:12.951s
[INFO] Finished at: Fri Jul 11 12:50:41 EEST 2014
[INFO] Final Memory: 128M/508M
[INFO]
------------------------------------------------------------------------
3 minutes and 12 seconds. Performance is quite good. However I use the
maven enforcer plugin and maven did warn me I have duplicate classes:
Duplicate classes found:
Found in:
org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile
org.jboss.logging:jboss-logging:jar:3.2.0.Beta1:compile
Duplicate classes:
org/jboss/logging/Field.class
org/jboss/logging/LoggerProvider.class
org/jboss/logging/Log4jLoggerProvider.class
org/jboss/logging/NDC.class
org/jboss/logging/MessageBundle.class
org/jboss/logging/AbstractMdcLoggerProvider.class
org/jboss/logging/Log4jLogger$1.class
org/jboss/logging/Messages$1.class
org/jboss/logging/JDKLevel.class
org/jboss/logging/DelegatingBasicLogger.class
org/jboss/logging/JDKLoggerProvider.class
org/jboss/logging/Slf4jLoggerProvider.class
org/jboss/logging/LoggingClass.class
org/jboss/logging/Messages.class
org/jboss/logging/AbstractLoggerProvider.class
org/jboss/logging/Property.class
org/jboss/logging/JBossLogRecord.class
org/jboss/logging/SerializedLogger.class
org/jboss/logging/Message.class
org/jboss/logging/MDC.class
org/jboss/logging/Message$Format.class
org/jboss/logging/JBossLogManagerProvider$1.class
org/jboss/logging/Cause.class
org/jboss/logging/Param.class
org/jboss/logging/JDKLogger$1.class
org/jboss/logging/JBossLogManagerLogger.class
org/jboss/logging/Slf4jLogger.class
org/jboss/logging/JBossLogManagerProvider.class
org/jboss/logging/FormatWith.class
org/jboss/logging/Slf4jLocationAwareLogger$1.class
org/jboss/logging/Logger$Level.class
org/jboss/logging/BasicLogger.class
org/jboss/logging/Logger$1.class
org/jboss/logging/JDKLogger.class
org/jboss/logging/JBossLogManagerLogger$1.class
org/jboss/logging/MessageLogger.class
org/jboss/logging/ParameterConverter.class
org/jboss/logging/Logger.class
org/jboss/logging/Slf4jLocationAwareLogger.class
org/jboss/logging/Log4jLogger.class
org/jboss/logging/LoggerProviders$1.class
org/jboss/logging/Slf4jLogger$1.class
org/jboss/logging/AbstractLoggerProvider$Entry.class
org/jboss/logging/LogMessage.class
org/jboss/logging/LoggerProviders.class
I excluded the jboss-logging from all hibernate dependencies like this:
org.hibernatehibernate-validator${hibernate.validator.version}org.jboss.loggingjboss-logging
No more duplicate classes :) . I run the same task again and here's the
performance:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 1:30:04.829s
[INFO] Finished at: Fri Jul 11 12:28:08 EEST 2014
[INFO] Final Memory: 118M/512M
[INFO]
------------------------------------------------------------------------
1 hour and 30 minutes and 4 seconds!!!!!! OMG :X How could this be??? And
on top of this no Log4j messages are coming through :(
This is probably a bug or I'm clearly missing how to setup Hibernate and
LOG4J2. Can you please help me, or at least point me to a forum or mailing
list where I can post this.
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
From sanne at hibernate.org Fri Jul 11 08:17:36 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 11 Jul 2014 13:17:36 +0100
Subject: [hibernate-dev] Hibernate + Log4J2 Performance Problem
In-Reply-To:
References:
Message-ID:
Hi,
I never tried Log4j2 myself, but while excluding all jboss-logging
artifacts, are you making sure you keep at least one (compatible)
version of it?
You need JBoss Logging to log anything, even if you re-route the
actual output to a different logger, as that's what Hibernate will use
as primary fa?ade.
HTH
Sanne
On 11 July 2014 12:53, Petar Tahchiev wrote:
> Hello,
>
> I'm really sorry to post this here but I couldn't find any jboss-logging
> mailing list. So here's my question. I'm reading this issue:
>
> https://issues.jboss.org/browse/JBLOGGING-95
>
> and I'm trying to make my hibernate use log4j2. So far I had
>
>
> org.jboss.logging
> jboss-logging-log4j
> ${jboss.logging.version}
>
>
> and I have log4j -> log4j2 routed. Unfortunately now my hibernate creates a
> log4j.log file and log4j prints the messages to the command line (still no
> log4j2) :(
>
> So I got rid of this dependency and I added the jboss-logging. So now
> here's my set of jars:
>
> hibernate-core
> hibernate-entitymanager
> hibernate-c3p0
> hibernate-validator
> log4j2
> org.jboss.logging:jboss-logging:jar:3.2.0.Beta1
>
> then I run my task and I get performance of:
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 3:12.951s
> [INFO] Finished at: Fri Jul 11 12:50:41 EEST 2014
> [INFO] Final Memory: 128M/508M
> [INFO]
> ------------------------------------------------------------------------
>
> 3 minutes and 12 seconds. Performance is quite good. However I use the
> maven enforcer plugin and maven did warn me I have duplicate classes:
>
> Duplicate classes found:
>
> Found in:
> org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile
> org.jboss.logging:jboss-logging:jar:3.2.0.Beta1:compile
> Duplicate classes:
> org/jboss/logging/Field.class
> org/jboss/logging/LoggerProvider.class
> org/jboss/logging/Log4jLoggerProvider.class
> org/jboss/logging/NDC.class
> org/jboss/logging/MessageBundle.class
> org/jboss/logging/AbstractMdcLoggerProvider.class
> org/jboss/logging/Log4jLogger$1.class
> org/jboss/logging/Messages$1.class
> org/jboss/logging/JDKLevel.class
> org/jboss/logging/DelegatingBasicLogger.class
> org/jboss/logging/JDKLoggerProvider.class
> org/jboss/logging/Slf4jLoggerProvider.class
> org/jboss/logging/LoggingClass.class
> org/jboss/logging/Messages.class
> org/jboss/logging/AbstractLoggerProvider.class
> org/jboss/logging/Property.class
> org/jboss/logging/JBossLogRecord.class
> org/jboss/logging/SerializedLogger.class
> org/jboss/logging/Message.class
> org/jboss/logging/MDC.class
> org/jboss/logging/Message$Format.class
> org/jboss/logging/JBossLogManagerProvider$1.class
> org/jboss/logging/Cause.class
> org/jboss/logging/Param.class
> org/jboss/logging/JDKLogger$1.class
> org/jboss/logging/JBossLogManagerLogger.class
> org/jboss/logging/Slf4jLogger.class
> org/jboss/logging/JBossLogManagerProvider.class
> org/jboss/logging/FormatWith.class
> org/jboss/logging/Slf4jLocationAwareLogger$1.class
> org/jboss/logging/Logger$Level.class
> org/jboss/logging/BasicLogger.class
> org/jboss/logging/Logger$1.class
> org/jboss/logging/JDKLogger.class
> org/jboss/logging/JBossLogManagerLogger$1.class
> org/jboss/logging/MessageLogger.class
> org/jboss/logging/ParameterConverter.class
> org/jboss/logging/Logger.class
> org/jboss/logging/Slf4jLocationAwareLogger.class
> org/jboss/logging/Log4jLogger.class
> org/jboss/logging/LoggerProviders$1.class
> org/jboss/logging/Slf4jLogger$1.class
> org/jboss/logging/AbstractLoggerProvider$Entry.class
> org/jboss/logging/LogMessage.class
> org/jboss/logging/LoggerProviders.class
>
> I excluded the jboss-logging from all hibernate dependencies like this:
>
> org.hibernate
> hibernate-validator
> ${hibernate.validator.version}
>
>
> org.jboss.logging
> jboss-logging
>
>
>
>
> No more duplicate classes :) . I run the same task again and here's the
> performance:
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESS
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 1:30:04.829s
> [INFO] Finished at: Fri Jul 11 12:28:08 EEST 2014
> [INFO] Final Memory: 118M/512M
> [INFO]
> ------------------------------------------------------------------------
>
> 1 hour and 30 minutes and 4 seconds!!!!!! OMG :X How could this be??? And
> on top of this no Log4j messages are coming through :(
>
> This is probably a bug or I'm clearly missing how to setup Hibernate and
> LOG4J2. Can you please help me, or at least point me to a forum or mailing
> list where I can post this.
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
From paranoiabla at gmail.com Fri Jul 11 08:44:04 2014
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 11 Jul 2014 15:44:04 +0300
Subject: [hibernate-dev] Hibernate + Log4J2 Performance Problem
In-Reply-To:
References:
Message-ID:
Hi Sanne,
yes, as you can see:
-------------------------------------------------
So I got rid of this dependency and I added the jboss-logging. So now
here's my set of jars:
hibernate-core
hibernate-entitymanager
hibernate-c3p0
hibernate-validator
log4j2
org.jboss.logging:jboss-logging:jar:3.2.0.Beta1
-----------------------------------------
I have log4j2 and jboss-logging:jar:3.2.0.Beta1
I upgraded to version 3.2.0.Beta1 because this bug
https://issues.jboss.org/browse/JBLOGGING-95
mentions that it was fixed in this version.
2014-07-11 15:17 GMT+03:00 Sanne Grinovero :
> Hi,
> I never tried Log4j2 myself, but while excluding all jboss-logging
> artifacts, are you making sure you keep at least one (compatible)
> version of it?
> You need JBoss Logging to log anything, even if you re-route the
> actual output to a different logger, as that's what Hibernate will use
> as primary fa?ade.
>
> HTH
> Sanne
>
> On 11 July 2014 12:53, Petar Tahchiev wrote:
> > Hello,
> >
> > I'm really sorry to post this here but I couldn't find any jboss-logging
> > mailing list. So here's my question. I'm reading this issue:
> >
> > https://issues.jboss.org/browse/JBLOGGING-95
> >
> > and I'm trying to make my hibernate use log4j2. So far I had
> >
> >
> > org.jboss.logging
> > jboss-logging-log4j
> > ${jboss.logging.version}
> >
> >
> > and I have log4j -> log4j2 routed. Unfortunately now my hibernate
> creates a
> > log4j.log file and log4j prints the messages to the command line (still
> no
> > log4j2) :(
> >
> > So I got rid of this dependency and I added the jboss-logging. So now
> > here's my set of jars:
> >
> > hibernate-core
> > hibernate-entitymanager
> > hibernate-c3p0
> > hibernate-validator
> > log4j2
> > org.jboss.logging:jboss-logging:jar:3.2.0.Beta1
> >
> > then I run my task and I get performance of:
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] BUILD SUCCESS
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Total time: 3:12.951s
> > [INFO] Finished at: Fri Jul 11 12:50:41 EEST 2014
> > [INFO] Final Memory: 128M/508M
> > [INFO]
> > ------------------------------------------------------------------------
> >
> > 3 minutes and 12 seconds. Performance is quite good. However I use the
> > maven enforcer plugin and maven did warn me I have duplicate classes:
> >
> > Duplicate classes found:
> >
> > Found in:
> > org.jboss.logging:jboss-logging:jar:3.1.3.GA:compile
> > org.jboss.logging:jboss-logging:jar:3.2.0.Beta1:compile
> > Duplicate classes:
> > org/jboss/logging/Field.class
> > org/jboss/logging/LoggerProvider.class
> > org/jboss/logging/Log4jLoggerProvider.class
> > org/jboss/logging/NDC.class
> > org/jboss/logging/MessageBundle.class
> > org/jboss/logging/AbstractMdcLoggerProvider.class
> > org/jboss/logging/Log4jLogger$1.class
> > org/jboss/logging/Messages$1.class
> > org/jboss/logging/JDKLevel.class
> > org/jboss/logging/DelegatingBasicLogger.class
> > org/jboss/logging/JDKLoggerProvider.class
> > org/jboss/logging/Slf4jLoggerProvider.class
> > org/jboss/logging/LoggingClass.class
> > org/jboss/logging/Messages.class
> > org/jboss/logging/AbstractLoggerProvider.class
> > org/jboss/logging/Property.class
> > org/jboss/logging/JBossLogRecord.class
> > org/jboss/logging/SerializedLogger.class
> > org/jboss/logging/Message.class
> > org/jboss/logging/MDC.class
> > org/jboss/logging/Message$Format.class
> > org/jboss/logging/JBossLogManagerProvider$1.class
> > org/jboss/logging/Cause.class
> > org/jboss/logging/Param.class
> > org/jboss/logging/JDKLogger$1.class
> > org/jboss/logging/JBossLogManagerLogger.class
> > org/jboss/logging/Slf4jLogger.class
> > org/jboss/logging/JBossLogManagerProvider.class
> > org/jboss/logging/FormatWith.class
> > org/jboss/logging/Slf4jLocationAwareLogger$1.class
> > org/jboss/logging/Logger$Level.class
> > org/jboss/logging/BasicLogger.class
> > org/jboss/logging/Logger$1.class
> > org/jboss/logging/JDKLogger.class
> > org/jboss/logging/JBossLogManagerLogger$1.class
> > org/jboss/logging/MessageLogger.class
> > org/jboss/logging/ParameterConverter.class
> > org/jboss/logging/Logger.class
> > org/jboss/logging/Slf4jLocationAwareLogger.class
> > org/jboss/logging/Log4jLogger.class
> > org/jboss/logging/LoggerProviders$1.class
> > org/jboss/logging/Slf4jLogger$1.class
> > org/jboss/logging/AbstractLoggerProvider$Entry.class
> > org/jboss/logging/LogMessage.class
> > org/jboss/logging/LoggerProviders.class
> >
> > I excluded the jboss-logging from all hibernate dependencies like this:
> >
> > org.hibernate
> > hibernate-validator
> > ${hibernate.validator.version}
> >
> >
> > org.jboss.logging
> > jboss-logging
> >
> >
> >
> >
> > No more duplicate classes :) . I run the same task again and here's the
> > performance:
> >
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] BUILD SUCCESS
> > [INFO]
> > ------------------------------------------------------------------------
> > [INFO] Total time: 1:30:04.829s
> > [INFO] Finished at: Fri Jul 11 12:28:08 EEST 2014
> > [INFO] Final Memory: 118M/512M
> > [INFO]
> > ------------------------------------------------------------------------
> >
> > 1 hour and 30 minutes and 4 seconds!!!!!! OMG :X How could this be??? And
> > on top of this no Log4j messages are coming through :(
> >
> > This is probably a bug or I'm clearly missing how to setup Hibernate and
> > LOG4J2. Can you please help me, or at least point me to a forum or
> mailing
> > list where I can post this.
> >
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> >
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
From smarlow at redhat.com Fri Jul 11 09:06:13 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 11 Jul 2014 09:06:13 -0400
Subject: [hibernate-dev] Hibernate + Log4J2 Performance Problem
In-Reply-To:
References:
Message-ID: <53BFE145.2090408@redhat.com>
On 07/11/2014 07:53 AM, Petar Tahchiev wrote:
> Hello,
>
> I'm really sorry to post this here but I couldn't find any jboss-logging
> mailing list.
https://lists.jboss.org/mailman/listinfo/wildfly-dev might also be a
good place to post on. The developers that work on jboss-logging, will
see your wildfly-dev post but probably not your hibernate-dev post.
Scott
From smarlow at redhat.com Fri Jul 11 09:36:32 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 11 Jul 2014 09:36:32 -0400
Subject: [hibernate-dev] failures running with a Java security manager + ORM
4.3.5.Final
Message-ID: <53BFE860.3030802@redhat.com>
I have been running the EE 7 compatibility tests with the Java security
manager enabled to find issues like http://pastie.org/9378079
Should we try to fix these on the ORM 4.3 branch (WildFly 9.0 currently
is using 4.3.5.Final) or on master (which should show up in WildFly at
some point)?
Scott
From paranoiabla at gmail.com Fri Jul 11 10:23:37 2014
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 11 Jul 2014 17:23:37 +0300
Subject: [hibernate-dev] Delaying 4.3.6 until tomorrow
Message-ID:
Hi guys,
any chance to have this included in 4.3.6:
https://hibernate.atlassian.net/browse/HHH-9217
I have supplied a pull request - it's really simple but keeps blocking me.
--
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
From sanne at hibernate.org Fri Jul 11 18:35:41 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 11 Jul 2014 23:35:41 +0100
Subject: [hibernate-dev] Released Hibernate Commons Annotations 4.0.5.Final
Message-ID:
Hello all,
I've just release Hibernate Commons Annotations 4.0.5.Final, to fix a
single but annoying issue:
https://hibernate.atlassian.net/browse/HCANN-60
-- Sanne
From sanne at hibernate.org Sun Jul 13 08:47:51 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 13 Jul 2014 13:47:51 +0100
Subject: [hibernate-dev] Explaining versioning and dependency compatibility
Message-ID:
I've been explaining $subject to a forum user [1]. I'm confident it's
only a problem for newcomers, but are we expecting more expert
developers to pass this lore by word of mouth?
I think we should add an explanation on these on the website but I'm
not sure where this would be more appropriate to present.
Should we highlight compatible versions of other integration points on
each sub section?
For example I could edit the Search area to mention which versions of
ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
different ones!), Commons Annotations, etc.. are supposed to work for
each release.
[1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
-- Sanne
From sanne at hibernate.org Sun Jul 13 18:30:37 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 13 Jul 2014 23:30:37 +0100
Subject: [hibernate-dev] Removal of method in ServiceRegistryBuilder broke
JBoss Tools
Message-ID:
Just noticed this post, a user unable to use Hibernate 4.3.5.Final
with the Hibernate/JBoss Tools:
https://forum.hibernate.org/viewtopic.php?f=6&t=1035330
The method "buildServiceRegistry()" seems to have been renamed to
"build()", but also the class was deprecated.
Seems useful to just add the old method back, as a delegate to
build().. may I do that?
-- Sanne
From gunnar at hibernate.org Mon Jul 14 06:21:40 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 14 Jul 2014 12:21:40 +0200
Subject: [hibernate-dev] Explaining versioning and dependency
compatibility
In-Reply-To:
References:
Message-ID:
2014-07-13 14:47 GMT+02:00 Sanne Grinovero :
> I've been explaining $subject to a forum user [1]. I'm confident it's
> only a problem for newcomers, but are we expecting more expert
> developers to pass this lore by word of mouth?
>
Not so sure whether it's not a problem for expert users as well every now
and then.
Looking at OGM for instance, we're currently in the situation that we
depend on a specific micro version of ORM (4.3.6 once it's out), which may
be a surprising fact. Personally, I think it'd be rational for a user to
expect compatibility based on minor version families of our projects, e.g.
that each OGM 4.1.x release is compatible with each ORM 4.3.x release.
As we can't guarantee this due to the rapid evolvement atm. (e.g. we add
new SPIs in ORM micro releases for the sake of OGM), some clear
documentation is highly desirable.
I think we should add an explanation on these on the website but I'm
> not sure where this would be more appropriate to present.
>
> Should we highlight compatible versions of other integration points on
> each sub section?
> For example I could edit the Search area to mention which versions of
> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
> different ones!), Commons Annotations, etc.. are supposed to work for
> each release.
>
Documenting the matching/required versions of upstream projects in each
project area may be one way. E.g. Search could document its requirements,
OGM its own etc. I don't think Search should document any expectations
towards OGM versions as the dependency is the other way around?
Speaking in Maven terms, I still think that providing this information in
form of bill-of-materials POMs would be the approach most helpful to users.
Such project BOM would contain the versions of all its components and
dependencies. Users would reference this BOM using the "import" scope in
their dependency management configuration and thus get matching versions
when declaring a dependency to any of the artifacts listed in the BOM.
I vaguely remember though that in the past there had been reservations
towards providing such BOMs?
@Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to do
this for OGM; Shall we give it a try?
--Gunnar
> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
>
> -- Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From sanne at hibernate.org Mon Jul 14 06:54:03 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Jul 2014 11:54:03 +0100
Subject: [hibernate-dev] Explaining versioning and dependency
compatibility
In-Reply-To:
References:
Message-ID:
Good point on OGM' s need for a specific micro. We could propose a 4.4
series of ORM after you finish defining the integration point? So OGM
x.Final will be able to depend on a more reasonable version range.
About BOM files, I'm just skeptical as I don't see how we should
maintain and test them:
- would we update some separate BOM project at every release?
- would you re-run the testsuite of each and all projects at every BOM
update overriding the testsuite versions to make sure it's a valid
combination? (how to automate?)
- I'd also expect some integration tests to actually verify the
correctness of the BOM file (e.g. syntax)
Also the documented dependency ranges on the website could need some
testing in a perfect world, but:
a) I'd expect it to be simpler as it' s a smaller matrix if each
project documents its own dependencies only
b) each project somehow "is aware" if when it breaks compatibility
with older dependencies, like you notice now with OGM: it's an
explicit step you just have to remember to document (and rare enough
so that I wouldn't bother too much to automate).
c) *Personal opinion* I feel like a statement about *expected
compatibility* does create a lower expectation in terms of accuracy
than a BOM file, so that I wouldn't expect need for actual QA on this
subject as much as I would expect it on BOM files which we would
officially distribute.
I'm not strictly against BOM but it sounds like taking a lot of our
bandwidth for a minor practical improvement.
Ultimately we should be very aware that our modules are in constant
change, and people mixing our latest are aware of a little bit of risk
in using latest as there is a mismatch between our expectations vs our
capacity to test and deliver a single unified platform, I think that's
more something for assemblies such as WildFly, JBoss EAP, Spring, and
whoever else redistributes our jars as a combination. We should be
ready to provide recommendations (as what we expect to work) to the
people making these distributions and our users but.. would you
consider untested BOM files to be good for that?
Sanne
On 14 July 2014 11:21, Gunnar Morling wrote:
> 2014-07-13 14:47 GMT+02:00 Sanne Grinovero :
>
>> I've been explaining $subject to a forum user [1]. I'm confident it's
>> only a problem for newcomers, but are we expecting more expert
>> developers to pass this lore by word of mouth?
>
>
> Not so sure whether it's not a problem for expert users as well every now
> and then.
>
> Looking at OGM for instance, we're currently in the situation that we depend
> on a specific micro version of ORM (4.3.6 once it's out), which may be a
> surprising fact. Personally, I think it'd be rational for a user to expect
> compatibility based on minor version families of our projects, e.g. that
> each OGM 4.1.x release is compatible with each ORM 4.3.x release.
>
> As we can't guarantee this due to the rapid evolvement atm. (e.g. we add new
> SPIs in ORM micro releases for the sake of OGM), some clear documentation is
> highly desirable.
>
>> I think we should add an explanation on these on the website but I'm
>> not sure where this would be more appropriate to present.
>>
>> Should we highlight compatible versions of other integration points on
>> each sub section?
>> For example I could edit the Search area to mention which versions of
>> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
>> different ones!), Commons Annotations, etc.. are supposed to work for
>> each release.
>
>
> Documenting the matching/required versions of upstream projects in each
> project area may be one way. E.g. Search could document its requirements,
> OGM its own etc. I don't think Search should document any expectations
> towards OGM versions as the dependency is the other way around?
>
> Speaking in Maven terms, I still think that providing this information in
> form of bill-of-materials POMs would be the approach most helpful to users.
> Such project BOM would contain the versions of all its components and
> dependencies. Users would reference this BOM using the "import" scope in
> their dependency management configuration and thus get matching versions
> when declaring a dependency to any of the artifacts listed in the BOM.
>
> I vaguely remember though that in the past there had been reservations
> towards providing such BOMs?
>
> @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to do
> this for OGM; Shall we give it a try?
>
> --Gunnar
>
>
>>
>> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
>>
>> -- Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
From gunnar at hibernate.org Mon Jul 14 10:23:18 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 14 Jul 2014 16:23:18 +0200
Subject: [hibernate-dev] Explaining versioning and dependency
compatibility
In-Reply-To:
References:
Message-ID:
2014-07-14 12:54 GMT+02:00 Sanne Grinovero :
> Good point on OGM' s need for a specific micro. We could propose a 4.4
> series of ORM after you finish defining the integration point? So OGM
> x.Final will be able to depend on a more reasonable version range.
>
Yes, that'd be vey nice.
> About BOM files, I'm just skeptical as I don't see how we should
> maintain and test them:
>
We'd maintain it in the same way as we maintain the dependencyManagement
block in our current POMs. Only that it's not part of the parent POM itself
but is extracted into a separate POM file. We'd import that BOM in our own
build and thus verify and test it.
The significant difference would be that a user can do the same (import
that BOM) and thus get matching versions of our artifacts.
> - would we update some separate BOM project at every release?
>
It would be just a module of each project, e.g. hibernate-ogm-bom, which
gets released as all the other modules.
> - would you re-run the testsuite of each and all projects at every BOM
> update overriding the testsuite versions to make sure it's a valid
> combination? (how to automate?)
- I'd also expect some integration tests to actually verify the
> correctness of the BOM file (e.g. syntax)
>
See above, as the BOM would be used in a project's build itself, it gets
verified.
> Also the documented dependency ranges on the website could need some
> testing in a perfect world, but:
> a) I'd expect it to be simpler as it' s a smaller matrix if each
> project documents its own dependencies only
> b) each project somehow "is aware" if when it breaks compatibility
> with older dependencies, like you notice now with OGM: it's an
> explicit step you just have to remember to document (and rare enough
> so that I wouldn't bother too much to automate).
> c) *Personal opinion* I feel like a statement about *expected
> compatibility* does create a lower expectation in terms of accuracy
> than a BOM file, so that I wouldn't expect need for actual QA on this
> subject as much as I would expect it on BOM files which we would
> officially distribute.
>
Atm. we also specify which version of our dependencies we expect (in our
parent POMs). So this information is there, it's only very hard for users
to extract it if they want to add any of our dependencies themselves
(they'd have to look up the version we depend on to make sure they don't
override it with a non-compatible one). By giving users the BOMs for
importing, this information is much more conveniently accessible (and there
is no risk for it of getting out-dated as with a wiki/web site based
approach).
>
> I'm not strictly against BOM but it sounds like taking a lot of our
> bandwidth for a minor practical improvement.
>
Maybe we have different things in mind?
It's not a huge effort, actually I've just pushed a branch for this for
OGM:
https://github.com/gunnarmorling/hibernate-ogm/compare/hibernate:master...gunnarmorling:OGM-574?expand=1
Ultimately we should be very aware that our modules are in constant
> change, and people mixing our latest are aware of a little bit of risk
> in using latest as there is a mismatch between our expectations vs our
> capacity to test and deliver a single unified platform, I think that's
> more something for assemblies such as WildFly, JBoss EAP, Spring, and
> whoever else redistributes our jars as a combination. We should be
> ready to provide recommendations (as what we expect to work) to the
> people making these distributions and our users but.. would you
> consider untested BOM files to be good for that?
>
They are not untested (at least in my model), as they are used for our own
build.
Sanne
>
--Gunnar
> On 14 July 2014 11:21, Gunnar Morling wrote:
> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero :
> >
> >> I've been explaining $subject to a forum user [1]. I'm confident it's
> >> only a problem for newcomers, but are we expecting more expert
> >> developers to pass this lore by word of mouth?
> >
> >
> > Not so sure whether it's not a problem for expert users as well every now
> > and then.
> >
> > Looking at OGM for instance, we're currently in the situation that we
> depend
> > on a specific micro version of ORM (4.3.6 once it's out), which may be a
> > surprising fact. Personally, I think it'd be rational for a user to
> expect
> > compatibility based on minor version families of our projects, e.g. that
> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
> >
> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we add
> new
> > SPIs in ORM micro releases for the sake of OGM), some clear
> documentation is
> > highly desirable.
> >
> >> I think we should add an explanation on these on the website but I'm
> >> not sure where this would be more appropriate to present.
> >>
> >> Should we highlight compatible versions of other integration points on
> >> each sub section?
> >> For example I could edit the Search area to mention which versions of
> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
> >> different ones!), Commons Annotations, etc.. are supposed to work for
> >> each release.
> >
> >
> > Documenting the matching/required versions of upstream projects in each
> > project area may be one way. E.g. Search could document its requirements,
> > OGM its own etc. I don't think Search should document any expectations
> > towards OGM versions as the dependency is the other way around?
> >
> > Speaking in Maven terms, I still think that providing this information in
> > form of bill-of-materials POMs would be the approach most helpful to
> users.
> > Such project BOM would contain the versions of all its components and
> > dependencies. Users would reference this BOM using the "import" scope in
> > their dependency management configuration and thus get matching versions
> > when declaring a dependency to any of the artifacts listed in the BOM.
> >
> > I vaguely remember though that in the past there had been reservations
> > towards providing such BOMs?
> >
> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to
> do
> > this for OGM; Shall we give it a try?
> >
> > --Gunnar
> >
> >
> >>
> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
> >>
> >> -- Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>
From sanne at hibernate.org Mon Jul 14 10:38:52 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Jul 2014 15:38:52 +0100
Subject: [hibernate-dev] Explaining versioning and dependency
compatibility
In-Reply-To:
References:
Message-ID:
On 14 July 2014 15:23, Gunnar Morling wrote:
> 2014-07-14 12:54 GMT+02:00 Sanne Grinovero :
>
>> Good point on OGM' s need for a specific micro. We could propose a 4.4
>> series of ORM after you finish defining the integration point? So OGM
>> x.Final will be able to depend on a more reasonable version range.
>
>
> Yes, that'd be vey nice.
>
>>
>> About BOM files, I'm just skeptical as I don't see how we should
>> maintain and test them:
>
>
> We'd maintain it in the same way as we maintain the dependencyManagement
> block in our current POMs. Only that it's not part of the parent POM itself
> but is extracted into a separate POM file. We'd import that BOM in our own
> build and thus verify and test it.
>
> The significant difference would be that a user can do the same (import that
> BOM) and thus get matching versions of our artifacts.
>
>>
>> - would we update some separate BOM project at every release?
>
>
> It would be just a module of each project, e.g. hibernate-ogm-bom, which
> gets released as all the other modules.
>
>>
>> - would you re-run the testsuite of each and all projects at every BOM
>> update overriding the testsuite versions to make sure it's a valid
>> combination? (how to automate?)
>>
>> - I'd also expect some integration tests to actually verify the
>> correctness of the BOM file (e.g. syntax)
>
>
> See above, as the BOM would be used in a project's build itself, it gets
> verified.
I don't understand how this would work. Let's take Search for example,
so I'd maintain a BOM file in Hibernate Search, and release a new one
at each of Search releases?
That implies my BOM file is "the one for Hibernate Search version X",
not for all projects together.
This doesn't answer the question of users "which version of Hibernate
Validator, Hibernate ORM, Hibernate Search work fine together? "
Let's say we release multiple BOM files. How do I use those in my
project, which one do I use to define my version of ORM?
As far as I know there is no such thing as "import the union of
multiple BOMs, validating the intersection is consistent" in Maven.
Sanne
>
>>
>> Also the documented dependency ranges on the website could need some
>> testing in a perfect world, but:
>> a) I'd expect it to be simpler as it' s a smaller matrix if each
>> project documents its own dependencies only
>> b) each project somehow "is aware" if when it breaks compatibility
>> with older dependencies, like you notice now with OGM: it's an
>> explicit step you just have to remember to document (and rare enough
>> so that I wouldn't bother too much to automate).
>> c) *Personal opinion* I feel like a statement about *expected
>> compatibility* does create a lower expectation in terms of accuracy
>> than a BOM file, so that I wouldn't expect need for actual QA on this
>> subject as much as I would expect it on BOM files which we would
>> officially distribute.
>
>
> Atm. we also specify which version of our dependencies we expect (in our
> parent POMs). So this information is there, it's only very hard for users to
> extract it if they want to add any of our dependencies themselves (they'd
> have to look up the version we depend on to make sure they don't override it
> with a non-compatible one). By giving users the BOMs for importing, this
> information is much more conveniently accessible (and there is no risk for
> it of getting out-dated as with a wiki/web site based approach).
>>
>>
>> I'm not strictly against BOM but it sounds like taking a lot of our
>> bandwidth for a minor practical improvement.
>
>
> Maybe we have different things in mind?
>
> It's not a huge effort, actually I've just pushed a branch for this for OGM:
> https://github.com/gunnarmorling/hibernate-ogm/compare/hibernate:master...gunnarmorling:OGM-574?expand=1
>
>> Ultimately we should be very aware that our modules are in constant
>> change, and people mixing our latest are aware of a little bit of risk
>> in using latest as there is a mismatch between our expectations vs our
>> capacity to test and deliver a single unified platform, I think that's
>> more something for assemblies such as WildFly, JBoss EAP, Spring, and
>> whoever else redistributes our jars as a combination. We should be
>> ready to provide recommendations (as what we expect to work) to the
>> people making these distributions and our users but.. would you
>> consider untested BOM files to be good for that?
>
>
> They are not untested (at least in my model), as they are used for our own
> build.
>
>> Sanne
>
>
> --Gunnar
>
>>
>> On 14 July 2014 11:21, Gunnar Morling wrote:
>> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero :
>> >
>> >> I've been explaining $subject to a forum user [1]. I'm confident it's
>> >> only a problem for newcomers, but are we expecting more expert
>> >> developers to pass this lore by word of mouth?
>> >
>> >
>> > Not so sure whether it's not a problem for expert users as well every
>> > now
>> > and then.
>> >
>> > Looking at OGM for instance, we're currently in the situation that we
>> > depend
>> > on a specific micro version of ORM (4.3.6 once it's out), which may be a
>> > surprising fact. Personally, I think it'd be rational for a user to
>> > expect
>> > compatibility based on minor version families of our projects, e.g. that
>> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
>> >
>> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we add
>> > new
>> > SPIs in ORM micro releases for the sake of OGM), some clear
>> > documentation is
>> > highly desirable.
>> >
>> >> I think we should add an explanation on these on the website but I'm
>> >> not sure where this would be more appropriate to present.
>> >>
>> >> Should we highlight compatible versions of other integration points on
>> >> each sub section?
>> >> For example I could edit the Search area to mention which versions of
>> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
>> >> different ones!), Commons Annotations, etc.. are supposed to work for
>> >> each release.
>> >
>> >
>> > Documenting the matching/required versions of upstream projects in each
>> > project area may be one way. E.g. Search could document its
>> > requirements,
>> > OGM its own etc. I don't think Search should document any expectations
>> > towards OGM versions as the dependency is the other way around?
>> >
>> > Speaking in Maven terms, I still think that providing this information
>> > in
>> > form of bill-of-materials POMs would be the approach most helpful to
>> > users.
>> > Such project BOM would contain the versions of all its components and
>> > dependencies. Users would reference this BOM using the "import" scope in
>> > their dependency management configuration and thus get matching versions
>> > when declaring a dependency to any of the artifacts listed in the BOM.
>> >
>> > I vaguely remember though that in the past there had been reservations
>> > towards providing such BOMs?
>> >
>> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to
>> > do
>> > this for OGM; Shall we give it a try?
>> >
>> > --Gunnar
>> >
>> >
>> >>
>> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
>> >>
>> >> -- Sanne
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>
>
From steve at hibernate.org Mon Jul 14 10:44:14 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 14 Jul 2014 09:44:14 -0500
Subject: [hibernate-dev] Explaining versioning and dependency
compatibility
In-Reply-To:
References:
Message-ID:
I actually think ORM 4.4 stabilizing the APIs and SPIs used in the other
projects would be a good idea as well.
On Mon, Jul 14, 2014 at 5:54 AM, Sanne Grinovero
wrote:
> Good point on OGM' s need for a specific micro. We could propose a 4.4
> series of ORM after you finish defining the integration point? So OGM
> x.Final will be able to depend on a more reasonable version range.
>
> About BOM files, I'm just skeptical as I don't see how we should
> maintain and test them:
> - would we update some separate BOM project at every release?
> - would you re-run the testsuite of each and all projects at every BOM
> update overriding the testsuite versions to make sure it's a valid
> combination? (how to automate?)
> - I'd also expect some integration tests to actually verify the
> correctness of the BOM file (e.g. syntax)
>
> Also the documented dependency ranges on the website could need some
> testing in a perfect world, but:
> a) I'd expect it to be simpler as it' s a smaller matrix if each
> project documents its own dependencies only
> b) each project somehow "is aware" if when it breaks compatibility
> with older dependencies, like you notice now with OGM: it's an
> explicit step you just have to remember to document (and rare enough
> so that I wouldn't bother too much to automate).
> c) *Personal opinion* I feel like a statement about *expected
> compatibility* does create a lower expectation in terms of accuracy
> than a BOM file, so that I wouldn't expect need for actual QA on this
> subject as much as I would expect it on BOM files which we would
> officially distribute.
>
> I'm not strictly against BOM but it sounds like taking a lot of our
> bandwidth for a minor practical improvement.
>
>
> Ultimately we should be very aware that our modules are in constant
> change, and people mixing our latest are aware of a little bit of risk
> in using latest as there is a mismatch between our expectations vs our
> capacity to test and deliver a single unified platform, I think that's
> more something for assemblies such as WildFly, JBoss EAP, Spring, and
> whoever else redistributes our jars as a combination. We should be
> ready to provide recommendations (as what we expect to work) to the
> people making these distributions and our users but.. would you
> consider untested BOM files to be good for that?
>
> Sanne
>
>
> On 14 July 2014 11:21, Gunnar Morling wrote:
> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero :
> >
> >> I've been explaining $subject to a forum user [1]. I'm confident it's
> >> only a problem for newcomers, but are we expecting more expert
> >> developers to pass this lore by word of mouth?
> >
> >
> > Not so sure whether it's not a problem for expert users as well every now
> > and then.
> >
> > Looking at OGM for instance, we're currently in the situation that we
> depend
> > on a specific micro version of ORM (4.3.6 once it's out), which may be a
> > surprising fact. Personally, I think it'd be rational for a user to
> expect
> > compatibility based on minor version families of our projects, e.g. that
> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
> >
> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we add
> new
> > SPIs in ORM micro releases for the sake of OGM), some clear
> documentation is
> > highly desirable.
> >
> >> I think we should add an explanation on these on the website but I'm
> >> not sure where this would be more appropriate to present.
> >>
> >> Should we highlight compatible versions of other integration points on
> >> each sub section?
> >> For example I could edit the Search area to mention which versions of
> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
> >> different ones!), Commons Annotations, etc.. are supposed to work for
> >> each release.
> >
> >
> > Documenting the matching/required versions of upstream projects in each
> > project area may be one way. E.g. Search could document its requirements,
> > OGM its own etc. I don't think Search should document any expectations
> > towards OGM versions as the dependency is the other way around?
> >
> > Speaking in Maven terms, I still think that providing this information in
> > form of bill-of-materials POMs would be the approach most helpful to
> users.
> > Such project BOM would contain the versions of all its components and
> > dependencies. Users would reference this BOM using the "import" scope in
> > their dependency management configuration and thus get matching versions
> > when declaring a dependency to any of the artifacts listed in the BOM.
> >
> > I vaguely remember though that in the past there had been reservations
> > towards providing such BOMs?
> >
> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574 to
> do
> > this for OGM; Shall we give it a try?
> >
> > --Gunnar
> >
> >
> >>
> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
> >>
> >> -- Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From steve at hibernate.org Mon Jul 14 10:45:20 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 14 Jul 2014 09:45:20 -0500
Subject: [hibernate-dev] Removal of method in ServiceRegistryBuilder
broke JBoss Tools
In-Reply-To:
References:
Message-ID:
Sure, that's fine.
On Sun, Jul 13, 2014 at 5:30 PM, Sanne Grinovero
wrote:
> Just noticed this post, a user unable to use Hibernate 4.3.5.Final
> with the Hibernate/JBoss Tools:
> https://forum.hibernate.org/viewtopic.php?f=6&t=1035330
>
> The method "buildServiceRegistry()" seems to have been renamed to
> "build()", but also the class was deprecated.
> Seems useful to just add the old method back, as a delegate to
> build().. may I do that?
>
> -- Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
From sanne at hibernate.org Mon Jul 14 11:09:34 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 14 Jul 2014 16:09:34 +0100
Subject: [hibernate-dev] Removal of method in ServiceRegistryBuilder
broke JBoss Tools
In-Reply-To:
References:
Message-ID:
Done as HHH-9288, should be included in 4.3.6.Final
On 14 July 2014 15:45, Steve Ebersole wrote:
> Sure, that's fine.
>
>
> On Sun, Jul 13, 2014 at 5:30 PM, Sanne Grinovero
> wrote:
>>
>> Just noticed this post, a user unable to use Hibernate 4.3.5.Final
>> with the Hibernate/JBoss Tools:
>> https://forum.hibernate.org/viewtopic.php?f=6&t=1035330
>>
>> The method "buildServiceRegistry()" seems to have been renamed to
>> "build()", but also the class was deprecated.
>> Seems useful to just add the old method back, as a delegate to
>> build().. may I do that?
>>
>> -- Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
From gunnar at hibernate.org Tue Jul 15 04:10:33 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 15 Jul 2014 10:10:33 +0200
Subject: [hibernate-dev] Explaining versioning and dependency
compatibility
In-Reply-To:
References:
Message-ID:
2014-07-14 16:38 GMT+02:00 Sanne Grinovero :
> On 14 July 2014 15:23, Gunnar Morling wrote:
> > 2014-07-14 12:54 GMT+02:00 Sanne Grinovero :
> >
> >> Good point on OGM' s need for a specific micro. We could propose a 4.4
> >> series of ORM after you finish defining the integration point? So OGM
> >> x.Final will be able to depend on a more reasonable version range.
> >
> >
> > Yes, that'd be vey nice.
> >
> >>
> >> About BOM files, I'm just skeptical as I don't see how we should
> >> maintain and test them:
> >
> >
> > We'd maintain it in the same way as we maintain the dependencyManagement
> > block in our current POMs. Only that it's not part of the parent POM
> itself
> > but is extracted into a separate POM file. We'd import that BOM in our
> own
> > build and thus verify and test it.
> >
> > The significant difference would be that a user can do the same (import
> that
> > BOM) and thus get matching versions of our artifacts.
> >
> >>
> >> - would we update some separate BOM project at every release?
> >
> >
> > It would be just a module of each project, e.g. hibernate-ogm-bom, which
> > gets released as all the other modules.
> >
> >>
> >> - would you re-run the testsuite of each and all projects at every BOM
> >> update overriding the testsuite versions to make sure it's a valid
> >> combination? (how to automate?)
> >>
> >> - I'd also expect some integration tests to actually verify the
> >> correctness of the BOM file (e.g. syntax)
> >
> >
> > See above, as the BOM would be used in a project's build itself, it gets
> > verified.
>
> I don't understand how this would work. Let's take Search for example,
> so I'd maintain a BOM file in Hibernate Search, and release a new one
> at each of Search releases?
>
Yes.
You implicitly do the same also today by releasing your parent POM which
contains the versions of the required ORM etc. modules. Only that a user
cannot easily make use of those versions when declaring a dependency to ORM
or any of the Search dependencies themselves.
> That implies my BOM file is "the one for Hibernate Search version X",
> not for all projects together.
> This doesn't answer the question of users "which version of Hibernate
> Validator, Hibernate ORM, Hibernate Search work fine together? "
>
It depends on the perspective. It answers the question "Which is the right
version of ORM, if I want to work with release XYZ of Search?" What it does
not answer is "If I'm working with ORM version XYZ, which version of Search
do I need to add?".
Maybe the situation is also a bit different for Search and OGM. I guess
Search more often is added to projects which are using ORM already and thus
need to find out the matching Search version (unless they are willing to
switch to another ORM version and just take the latest Search). For OGM I'd
rather expect that users start with the latest version of OGM and are fine
with whatever ORM version this requires (at least until we truly support
polyglot scenarios, where again OGM may be added to an existing ORM
application).
So at least for OGM a BOM as I described it would be very helpful. E.g. the
user in the forum would have benefitted from it as he wouldn't have to
manually specify ORM versions but would get those declared in the OGM BOM.
As Hardy is saying, Validator has no version requirements in this context.
Let's say we release multiple BOM files. How do I use those in my
> project, which one do I use to define my version of ORM?
>
You'd have to use the one of the "most downstream" Hibernate project you're
using. E.g. when working with ORM and Search, the one from Search. When
working with ORM, Search and OGM, the one from OGM. BOMs can also include
other BOMs, so e.g. in the OGM BOM we could import the one from Search, so
we wouldn't have to re-declare versions for all Search components in OGM.
> As far as I know there is no such thing as "import the union of
> multiple BOMs, validating the intersection is consistent" in Maven.
>
Unfortunately that's true. I hoped the DependencyConvergence rule for the
enforcer plug-in would help, but this one only deals with resolved
dependencies and not things declared in . So if a
user would import the Search *and* the OGM BOM (which they shouldn't),
there'd be a risk of inconsistencies (in this case the import declared
first takes precedence).
Nevertheless I feel that (at least for OGM) providing such BOM would be
beneficial to users.
Sanne
>
--Gunnar
>
>
>
> >
> >>
> >> Also the documented dependency ranges on the website could need some
> >> testing in a perfect world, but:
> >> a) I'd expect it to be simpler as it' s a smaller matrix if each
> >> project documents its own dependencies only
> >> b) each project somehow "is aware" if when it breaks compatibility
> >> with older dependencies, like you notice now with OGM: it's an
> >> explicit step you just have to remember to document (and rare enough
> >> so that I wouldn't bother too much to automate).
> >> c) *Personal opinion* I feel like a statement about *expected
> >> compatibility* does create a lower expectation in terms of accuracy
> >> than a BOM file, so that I wouldn't expect need for actual QA on this
> >> subject as much as I would expect it on BOM files which we would
> >> officially distribute.
> >
> >
> > Atm. we also specify which version of our dependencies we expect (in our
> > parent POMs). So this information is there, it's only very hard for
> users to
> > extract it if they want to add any of our dependencies themselves (they'd
> > have to look up the version we depend on to make sure they don't
> override it
> > with a non-compatible one). By giving users the BOMs for importing, this
> > information is much more conveniently accessible (and there is no risk
> for
> > it of getting out-dated as with a wiki/web site based approach).
> >>
> >>
> >> I'm not strictly against BOM but it sounds like taking a lot of our
> >> bandwidth for a minor practical improvement.
> >
> >
> > Maybe we have different things in mind?
> >
> > It's not a huge effort, actually I've just pushed a branch for this for
> OGM:
> >
> https://github.com/gunnarmorling/hibernate-ogm/compare/hibernate:master...gunnarmorling:OGM-574?expand=1
> >
> >> Ultimately we should be very aware that our modules are in constant
> >> change, and people mixing our latest are aware of a little bit of risk
> >> in using latest as there is a mismatch between our expectations vs our
> >> capacity to test and deliver a single unified platform, I think that's
> >> more something for assemblies such as WildFly, JBoss EAP, Spring, and
> >> whoever else redistributes our jars as a combination. We should be
> >> ready to provide recommendations (as what we expect to work) to the
> >> people making these distributions and our users but.. would you
> >> consider untested BOM files to be good for that?
> >
> >
> > They are not untested (at least in my model), as they are used for our
> own
> > build.
> >
> >> Sanne
> >
> >
> > --Gunnar
> >
> >>
> >> On 14 July 2014 11:21, Gunnar Morling wrote:
> >> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero :
> >> >
> >> >> I've been explaining $subject to a forum user [1]. I'm confident it's
> >> >> only a problem for newcomers, but are we expecting more expert
> >> >> developers to pass this lore by word of mouth?
> >> >
> >> >
> >> > Not so sure whether it's not a problem for expert users as well every
> >> > now
> >> > and then.
> >> >
> >> > Looking at OGM for instance, we're currently in the situation that we
> >> > depend
> >> > on a specific micro version of ORM (4.3.6 once it's out), which may
> be a
> >> > surprising fact. Personally, I think it'd be rational for a user to
> >> > expect
> >> > compatibility based on minor version families of our projects, e.g.
> that
> >> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
> >> >
> >> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we
> add
> >> > new
> >> > SPIs in ORM micro releases for the sake of OGM), some clear
> >> > documentation is
> >> > highly desirable.
> >> >
> >> >> I think we should add an explanation on these on the website but I'm
> >> >> not sure where this would be more appropriate to present.
> >> >>
> >> >> Should we highlight compatible versions of other integration points
> on
> >> >> each sub section?
> >> >> For example I could edit the Search area to mention which versions of
> >> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
> >> >> different ones!), Commons Annotations, etc.. are supposed to work for
> >> >> each release.
> >> >
> >> >
> >> > Documenting the matching/required versions of upstream projects in
> each
> >> > project area may be one way. E.g. Search could document its
> >> > requirements,
> >> > OGM its own etc. I don't think Search should document any expectations
> >> > towards OGM versions as the dependency is the other way around?
> >> >
> >> > Speaking in Maven terms, I still think that providing this information
> >> > in
> >> > form of bill-of-materials POMs would be the approach most helpful to
> >> > users.
> >> > Such project BOM would contain the versions of all its components and
> >> > dependencies. Users would reference this BOM using the "import" scope
> in
> >> > their dependency management configuration and thus get matching
> versions
> >> > when declaring a dependency to any of the artifacts listed in the BOM.
> >> >
> >> > I vaguely remember though that in the past there had been reservations
> >> > towards providing such BOMs?
> >> >
> >> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574
> to
> >> > do
> >> > this for OGM; Shall we give it a try?
> >> >
> >> > --Gunnar
> >> >
> >> >
> >> >>
> >> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
> >> >>
> >> >> -- Sanne
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> >
> >
> >
>
From sanne at hibernate.org Tue Jul 15 06:27:37 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 15 Jul 2014 11:27:37 +0100
Subject: [hibernate-dev] Explaining versioning and dependency
compatibility
In-Reply-To:
References:
Message-ID:
Interesting points. Indeed the need of users is different for the
Validator, Search, OGM examples, we might not be needing a "fits all"
solution.
So for OGM a BOM file might be useful. You should probably add all
other optional projects in there as well, that would resolve the
"intersections" problem.
For Validator, I don't understand why you all say there is no
dependency: it might be a wide range, but there is integration code in
ORM which has not always be there, and not always the same. I don't
expect Validator 3.x to work with latest ORM, and you should state
that somewhere.
On top of this, Validator has some shared dependencies with the other
modules; most of these are usually not a problem but there are
situations in which some combo might not work because of say a
breaking change int JBoss Logger or Commons Annotations.
Indeed for Search one might want to simply add some very basic
full-text search capability on an existing complex ORM application and
not wish to change ORM, or in a different case one wants to play with
the latest power features in the latest Search version. Depending on
the case one searches for compatibility for a specific version of ORM
or for a particular version of Search. I think it would be nice if
both project had some kind of informational box close to the version
details to list which "recommended" compatible version we suggest.
Even for OGM if we do BOM files, I would still like to see such an
information box on the website as not everyone is versed with Maven.
On 15 July 2014 09:10, Gunnar Morling wrote:
> 2014-07-14 16:38 GMT+02:00 Sanne Grinovero :
>
>> On 14 July 2014 15:23, Gunnar Morling wrote:
>> > 2014-07-14 12:54 GMT+02:00 Sanne Grinovero :
>> >
>> >> Good point on OGM' s need for a specific micro. We could propose a 4.4
>> >> series of ORM after you finish defining the integration point? So OGM
>> >> x.Final will be able to depend on a more reasonable version range.
>> >
>> >
>> > Yes, that'd be vey nice.
>> >
>> >>
>> >> About BOM files, I'm just skeptical as I don't see how we should
>> >> maintain and test them:
>> >
>> >
>> > We'd maintain it in the same way as we maintain the dependencyManagement
>> > block in our current POMs. Only that it's not part of the parent POM
>> > itself
>> > but is extracted into a separate POM file. We'd import that BOM in our
>> > own
>> > build and thus verify and test it.
>> >
>> > The significant difference would be that a user can do the same (import
>> > that
>> > BOM) and thus get matching versions of our artifacts.
>> >
>> >>
>> >> - would we update some separate BOM project at every release?
>> >
>> >
>> > It would be just a module of each project, e.g. hibernate-ogm-bom, which
>> > gets released as all the other modules.
>> >
>> >>
>> >> - would you re-run the testsuite of each and all projects at every BOM
>> >> update overriding the testsuite versions to make sure it's a valid
>> >> combination? (how to automate?)
>> >>
>> >> - I'd also expect some integration tests to actually verify the
>> >> correctness of the BOM file (e.g. syntax)
>> >
>> >
>> > See above, as the BOM would be used in a project's build itself, it gets
>> > verified.
>>
>> I don't understand how this would work. Let's take Search for example,
>> so I'd maintain a BOM file in Hibernate Search, and release a new one
>> at each of Search releases?
>
>
> Yes.
>
> You implicitly do the same also today by releasing your parent POM which
> contains the versions of the required ORM etc. modules. Only that a user
> cannot easily make use of those versions when declaring a dependency to ORM
> or any of the Search dependencies themselves.
>
>>
>> That implies my BOM file is "the one for Hibernate Search version X",
>> not for all projects together.
>> This doesn't answer the question of users "which version of Hibernate
>> Validator, Hibernate ORM, Hibernate Search work fine together? "
>
>
> It depends on the perspective. It answers the question "Which is the right
> version of ORM, if I want to work with release XYZ of Search?" What it does
> not answer is "If I'm working with ORM version XYZ, which version of Search
> do I need to add?".
>
> Maybe the situation is also a bit different for Search and OGM. I guess
> Search more often is added to projects which are using ORM already and thus
> need to find out the matching Search version (unless they are willing to
> switch to another ORM version and just take the latest Search). For OGM I'd
> rather expect that users start with the latest version of OGM and are fine
> with whatever ORM version this requires (at least until we truly support
> polyglot scenarios, where again OGM may be added to an existing ORM
> application).
>
> So at least for OGM a BOM as I described it would be very helpful. E.g. the
> user in the forum would have benefitted from it as he wouldn't have to
> manually specify ORM versions but would get those declared in the OGM BOM.
>
> As Hardy is saying, Validator has no version requirements in this context.
>
>> Let's say we release multiple BOM files. How do I use those in my
>> project, which one do I use to define my version of ORM?
>
>
> You'd have to use the one of the "most downstream" Hibernate project you're
> using. E.g. when working with ORM and Search, the one from Search. When
> working with ORM, Search and OGM, the one from OGM. BOMs can also include
> other BOMs, so e.g. in the OGM BOM we could import the one from Search, so
> we wouldn't have to re-declare versions for all Search components in OGM.
>
>>
>> As far as I know there is no such thing as "import the union of
>> multiple BOMs, validating the intersection is consistent" in Maven.
>
>
> Unfortunately that's true. I hoped the DependencyConvergence rule for the
> enforcer plug-in would help, but this one only deals with resolved
> dependencies and not things declared in . So if a user
> would import the Search *and* the OGM BOM (which they shouldn't), there'd be
> a risk of inconsistencies (in this case the import declared first takes
> precedence).
>
> Nevertheless I feel that (at least for OGM) providing such BOM would be
> beneficial to users.
>
>> Sanne
>
>
> --Gunnar
>
>>
>>
>>
>>
>> >
>> >>
>> >> Also the documented dependency ranges on the website could need some
>> >> testing in a perfect world, but:
>> >> a) I'd expect it to be simpler as it' s a smaller matrix if each
>> >> project documents its own dependencies only
>> >> b) each project somehow "is aware" if when it breaks compatibility
>> >> with older dependencies, like you notice now with OGM: it's an
>> >> explicit step you just have to remember to document (and rare enough
>> >> so that I wouldn't bother too much to automate).
>> >> c) *Personal opinion* I feel like a statement about *expected
>> >> compatibility* does create a lower expectation in terms of accuracy
>> >> than a BOM file, so that I wouldn't expect need for actual QA on this
>> >> subject as much as I would expect it on BOM files which we would
>> >> officially distribute.
>> >
>> >
>> > Atm. we also specify which version of our dependencies we expect (in our
>> > parent POMs). So this information is there, it's only very hard for
>> > users to
>> > extract it if they want to add any of our dependencies themselves
>> > (they'd
>> > have to look up the version we depend on to make sure they don't
>> > override it
>> > with a non-compatible one). By giving users the BOMs for importing, this
>> > information is much more conveniently accessible (and there is no risk
>> > for
>> > it of getting out-dated as with a wiki/web site based approach).
>> >>
>> >>
>> >> I'm not strictly against BOM but it sounds like taking a lot of our
>> >> bandwidth for a minor practical improvement.
>> >
>> >
>> > Maybe we have different things in mind?
>> >
>> > It's not a huge effort, actually I've just pushed a branch for this for
>> > OGM:
>> >
>> > https://github.com/gunnarmorling/hibernate-ogm/compare/hibernate:master...gunnarmorling:OGM-574?expand=1
>> >
>> >> Ultimately we should be very aware that our modules are in constant
>> >> change, and people mixing our latest are aware of a little bit of risk
>> >> in using latest as there is a mismatch between our expectations vs our
>> >> capacity to test and deliver a single unified platform, I think that's
>> >> more something for assemblies such as WildFly, JBoss EAP, Spring, and
>> >> whoever else redistributes our jars as a combination. We should be
>> >> ready to provide recommendations (as what we expect to work) to the
>> >> people making these distributions and our users but.. would you
>> >> consider untested BOM files to be good for that?
>> >
>> >
>> > They are not untested (at least in my model), as they are used for our
>> > own
>> > build.
>> >
>> >> Sanne
>> >
>> >
>> > --Gunnar
>> >
>> >>
>> >> On 14 July 2014 11:21, Gunnar Morling wrote:
>> >> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero :
>> >> >
>> >> >> I've been explaining $subject to a forum user [1]. I'm confident
>> >> >> it's
>> >> >> only a problem for newcomers, but are we expecting more expert
>> >> >> developers to pass this lore by word of mouth?
>> >> >
>> >> >
>> >> > Not so sure whether it's not a problem for expert users as well every
>> >> > now
>> >> > and then.
>> >> >
>> >> > Looking at OGM for instance, we're currently in the situation that we
>> >> > depend
>> >> > on a specific micro version of ORM (4.3.6 once it's out), which may
>> >> > be a
>> >> > surprising fact. Personally, I think it'd be rational for a user to
>> >> > expect
>> >> > compatibility based on minor version families of our projects, e.g.
>> >> > that
>> >> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
>> >> >
>> >> > As we can't guarantee this due to the rapid evolvement atm. (e.g. we
>> >> > add
>> >> > new
>> >> > SPIs in ORM micro releases for the sake of OGM), some clear
>> >> > documentation is
>> >> > highly desirable.
>> >> >
>> >> >> I think we should add an explanation on these on the website but I'm
>> >> >> not sure where this would be more appropriate to present.
>> >> >>
>> >> >> Should we highlight compatible versions of other integration points
>> >> >> on
>> >> >> each sub section?
>> >> >> For example I could edit the Search area to mention which versions
>> >> >> of
>> >> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
>> >> >> different ones!), Commons Annotations, etc.. are supposed to work
>> >> >> for
>> >> >> each release.
>> >> >
>> >> >
>> >> > Documenting the matching/required versions of upstream projects in
>> >> > each
>> >> > project area may be one way. E.g. Search could document its
>> >> > requirements,
>> >> > OGM its own etc. I don't think Search should document any
>> >> > expectations
>> >> > towards OGM versions as the dependency is the other way around?
>> >> >
>> >> > Speaking in Maven terms, I still think that providing this
>> >> > information
>> >> > in
>> >> > form of bill-of-materials POMs would be the approach most helpful to
>> >> > users.
>> >> > Such project BOM would contain the versions of all its components and
>> >> > dependencies. Users would reference this BOM using the "import" scope
>> >> > in
>> >> > their dependency management configuration and thus get matching
>> >> > versions
>> >> > when declaring a dependency to any of the artifacts listed in the
>> >> > BOM.
>> >> >
>> >> > I vaguely remember though that in the past there had been
>> >> > reservations
>> >> > towards providing such BOMs?
>> >> >
>> >> > @Davide, I've created https://hibernate.atlassian.net/browse/OGM-574
>> >> > to
>> >> > do
>> >> > this for OGM; Shall we give it a try?
>> >> >
>> >> > --Gunnar
>> >> >
>> >> >
>> >> >>
>> >> >> [1] https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
>> >> >>
>> >> >> -- Sanne
>> >> >> _______________________________________________
>> >> >> hibernate-dev mailing list
>> >> >> hibernate-dev at lists.jboss.org
>> >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> >
>> >
>> >
>
>
From emmanuel at hibernate.org Tue Jul 15 17:26:20 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 15 Jul 2014 23:26:20 +0200
Subject: [hibernate-dev] Explaining versioning and dependency
compatibility
In-Reply-To:
References:
Message-ID:
On 15 Jul 2014, at 12:27, Sanne Grinovero wrote:
> For Validator, I don't understand why you all say there is no
> dependency: it might be a wide range, but there is integration code in
> ORM which has not always be there, and not always the same. I don't
> expect Validator 3.x to work with latest ORM, and you should state
> that somewhere.
The shared dependencies might be problematic but I think ORM uses Bean Validation?s APIs only so we are very well isolated from Hibernate Validator per se.
> Indeed for Search one might want to simply add some very basic
> full-text search capability on an existing complex ORM application and
> not wish to change ORM, or in a different case one wants to play with
> the latest power features in the latest Search version. Depending on
> the case one searches for compatibility for a specific version of ORM
> or for a particular version of Search. I think it would be nice if
> both project had some kind of informational box close to the version
> details to list which "recommended" compatible version we suggest.
Remember we had that in the first wiki and that was a nightmare. I know I was the one maintaining it :)
>
> Even for OGM if we do BOM files, I would still like to see such an
> information box on the website as not everyone is versed with Maven.
For OGM indeed it seems to be useful not only to list the other Hibernate project versions but also to show which version of which driver we test against.
Now that would break if we plan to support multiple versions of a driver or more likely embedded datastores like Noe4J and Infinispan that might break their APIs.
While we can create different modules, the BOM would be at a loss to express that.
Emmanuel
From emmanuel at hibernate.org Wed Jul 16 03:51:06 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 16 Jul 2014 09:51:06 +0200
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
Message-ID: <20140716075106.GC7229@hibernate.org>
Anyone knows a way to disable JIRA notification when someone edits an
entry or comment? This creates a lot of noise and is 99% of the time
either a minor typo or some wiki syntax fixes / improvements.
That would make my day.
From emmanuel at hibernate.org Wed Jul 16 14:08:39 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 16 Jul 2014 20:08:39 +0200
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
In-Reply-To: <20140716075106.GC7229@hibernate.org>
References: <20140716075106.GC7229@hibernate.org>
Message-ID: <96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>
Anyone against me removing notifications when comments are edited ? Still a small subset but that's progress.
> On 16 juil. 2014, at 09:51, Emmanuel Bernard wrote:
>
> Anyone knows a way to disable JIRA notification when someone edits an
> entry or comment? This creates a lot of noise and is 99% of the time
> either a minor typo or some wiki syntax fixes / improvements.
>
> That would make my day.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
From sanne at hibernate.org Wed Jul 16 14:14:06 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 16 Jul 2014 19:14:06 +0100
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
In-Reply-To: <96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>
References: <20140716075106.GC7229@hibernate.org>
<96E7CE55-BBBF-4C6F-BBDB-DFDF136C9631@hibernate.org>
Message-ID:
+1 to remove them.
Actually didn't we once had an option enabled to disable editing?
On 16 July 2014 19:08, Emmanuel Bernard wrote:
> Anyone against me removing notifications when comments are edited ? Still a small subset but that's progress.
>
>> On 16 juil. 2014, at 09:51, Emmanuel Bernard wrote:
>>
>> Anyone knows a way to disable JIRA notification when someone edits an
>> entry or comment? This creates a lot of noise and is 99% of the time
>> either a minor typo or some wiki syntax fixes / improvements.
>>
>> That would make my day.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
From jlesinge at gmail.com Wed Jul 16 14:17:27 2014
From: jlesinge at gmail.com (John Worrell)
Date: Wed, 16 Jul 2014 19:17:27 +0100
Subject: [hibernate-dev] Contributing to OGM / Cassandra
Message-ID:
Hi,
I'm interested in contributing to the Cassandra module of Hibernate-OGM -
what would be the baest way to go about this?
Thanks,
John
From steve at hibernate.org Wed Jul 16 14:35:42 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 16 Jul 2014 13:35:42 -0500
Subject: [hibernate-dev] Disable JIRA notifications for "edits"
In-Reply-To: