From paranoiabla at gmail.com  Mon Jan  4 02:04:14 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Mon, 4 Jan 2016 09:04:14 +0200
Subject: [hibernate-dev] javax.money
In-Reply-To: <CAFdSV9tpm0gMs-Hk96fF1jSiLcKo0qqh7zV5D91vNKWzkBdLVQ@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
	<CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
	<CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>
	<CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>
	<CADGJaX87VTFa+WdZoikg0nZkd72UMD_7sTY9PAA=O75Oe2yJNg@mail.gmail.com>
	<CAFdSV9vepP+YB+QzJ37UehzamKiu7ckEx94QgWfx122Ec5orCw@mail.gmail.com>
	<CADGJaX-Nr4F7_HZXkyyoqwvUny0L3_i5zATTVFmOeqDAu5UoMg@mail.gmail.com>
	<CAFdSV9tpm0gMs-Hk96fF1jSiLcKo0qqh7zV5D91vNKWzkBdLVQ@mail.gmail.com>
Message-ID: <CAKnbemVzf5rn6Q40Sgt-SPD6pP2Qx8mOkVn2bapWOtFQ7NKE+A@mail.gmail.com>

Any updates on this? What has been decided? Can we see some hibernate
support for this JSR?

2015-12-26 19:13 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Correct.  And things are "possible in any number of ways".  Some are just
> more right than others.  The fun is the fact that the question of which
> which is more right can be different depending on your perspective and that
> is clearly the case here.
>
> >From the user's perspective the best solution is actually the least
> attractive from the Hibernate development side of things... specifically
> the best option for the user is for Hibernate to specify a compile-only
> dependency (optional, provided, etc is irrelevant) and for Hibernate to
> internally isolate itself from cases where javax.money is not available on
> the classpath (reflection, etc).  Ultimately I think this is the direction
> to go for this particular integration.
>
> On Wed, Dec 23, 2015 at 2:23 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
> > It's software, so everything is *possible*. Question is whether we
> > deem it acceptable for the user having to depend on another submodule
> > or not. If you think that's ok, then go for it ;)
> >
> >
> > 2015-12-22 23:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > > You mean in addition to Maven's own documentation?  Quote[1]:
> > >
> > > "Optional dependencies are used when it's not really possible (for
> > whatever
> > > reason) to split a project up into sub-modules. The idea is that some
> of
> > the
> > > dependencies are only used for certain features in the project, and
> will
> > not
> > > be needed if that feature isn't used. Ideally, such a feature would be
> > split
> > > into a sub-module that depended on the core functionality
> project...this
> > new
> > > subproject would have only non-optional dependencies, since you'd need
> > them
> > > all if you decided to use the subproject's functionality."
> > >
> > > Beyond Maven's own documentation, simply google...
> > >
> > > [1]
> > >
> >
> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
> > >
> > > On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar at hibernate.org>
> > wrote:
> > >>
> > >> To me, "optional" seems like the right thing for this case. "Provided"
> > >> (at least in the Maven world, I don't know whether Gradle has
> > >> different semantics) suggests that this stuff is really to be provided
> > >> by the runtime; I interpret this as a mandatory requirement towards
> > >> the environment (i.e. a Java EE container *has* to provide the javax.*
> > >> packages).
> > >>
> > >> Optional instead indicates that this stuff may be present at runtime
> > >> or not. If it is present, some optional functionality will be
> > >> available to the user, otherwise not. For the case of Money the user
> > >> is depending on these types anyways - and thus required to expose them
> > >> on the runtime class path -  if he is wishing to work with these types
> > >> in his own code (or not otherwise). No need to analyse the dependency
> > >> graph or whatsoever.
> > >>
> > >> As said we use that style in Hibernate Validator for optional
> > >> constraint validators, and it works well, I can't remember of any
> > >> related issue or complaint. I suppose it'd help if you could point to
> > >> that resource describing potential issues with optional.
> > >>
> > >> 2015-12-22 20:31 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > >> > Well the Bitronix use-case is actually a perfect illustration of why
> > >> > optional/provided dependencies stink.  Nothing in the dependency
> graph
> > >> > indicates what you are expected to do here.  Bitronix users would
> have
> > >> > to
> > >> > look at the documentation to understand this; and dependency
> > >> > graph/analysis
> > >> > tools would be completely at a loss.  And in Bitronix the "decision"
> > is
> > >> > all
> > >> > internal to Bitronix.  Here at least the argument is a little more
> > >> > justified because we are really talking about looking to see if
> > another
> > >> > set
> > >> > of classes (library) are present from the application's classloader
> > >> > (since
> > >> > the application would need to bind to Moneta, etc statically).
> > >> >
> > >> > 'optional' is flat out wrong; that is well documented elsewhere.  I
> > can
> > >> > be
> > >> > persuaded to use 'provided' for something like this, as I already
> > >> > stated.
> > >> >
> > >> >
> > >> > On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <
> > mihalcea.vlad at gmail.com>
> > >> > wrote:
> > >> >
> > >> >> That's how Bitronix Transaction Manager managed optional
> dependencies
> > >> >> as
> > >> >> well.
> > >> >> In its case cglib and javassist were optional dependencies and at
> > >> >> runtime
> > >> >> the framework decided whether to load one provider or the other.
> > >> >>
> > >> >> Vlad
> > >> >>
> > >> >> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <
> > sanne at hibernate.org>
> > >> >> wrote:
> > >> >>
> > >> >> > On 22 December 2015 at 17:34, Gunnar Morling <
> gunnar at hibernate.org
> > >
> > >> >> wrote:
> > >> >> > >> yes we could use an optional/provided dependency, but
> > >> >> > >> that would not be "proper".
> > >> >> > >
> > >> >> > > That would actually be my preference; If the javax.money types
> > are
> > >> >> > > present, enable the required Types etc. otherwise not. It's a
> > >> >> > > pattern
> > >> >> > > we e.g. use in Validator, too, where we provide additional
> > >> >> > > constraint
> > >> >> > > validator types based on what's available in the runtime
> > >> >> > > environment.
> > >> >> >
> > >> >> > +1
> > >> >> >
> > >> >> > > Why do you consider it as not proper?
> > >> >> >
> > >> >> > Same question for me. It might not be perfectly well defined in
> > terms
> > >> >> > of Maven dependencies, still I think the practical benefit for
> > users
> > >> >> > far outweights the cons.. if that's what you're referring to.
> > >> >> >
> > >> >> > Sanne
> > >> >> >
> > >> >> > >
> > >> >> > >
> > >> >> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <steve at hibernate.org
> >:
> > >> >> > >> I had planned to support this JSR when I thought it would be
> > part
> > >> >> > >> of
> > >> >> the
> > >> >> > >> JDK.  But as it is, supporting this properly would mean a
> whole
> > >> >> > >> new
> > >> >> > >> module/artifact just to add these few types + the dependency
> > >> >> > >> (similar
> > >> >> to
> > >> >> > >> hibernate-java8).  I am not a fan of the fact that it would
> > >> >> > >> require a
> > >> >> > >> separate dependency; yes we could use an optional/provided
> > >> >> > >> dependency,
> > >> >> > but
> > >> >> > >> that would not be "proper".
> > >> >> > >>
> > >> >> > >> I am interested in what others think.
> > >> >> > >>
> > >> >> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev
> > >> >> > >> <paranoiabla at gmail.com>
> > >> >> > wrote:
> > >> >> > >>
> > >> >> > >>> Hi guys,
> > >> >> > >>>
> > >> >> > >>> I've been playing lately with JSR 354 javax.money api (
> > >> >> > >>> http://javamoney.java.net) and I was wondering if there's
> any
> > >> >> > >>> plans
> > >> >> > for
> > >> >> > >>> hibernate to support this.
> > >> >> > >>>
> > >> >> > >>> Thanks.
> > >> >> > >>>
> > >> >> > >>> --
> > >> >> > >>> Regards, Petar!
> > >> >> > >>> Karlovo, Bulgaria.
> > >> >> > >>> ---
> > >> >> > >>> Public PGP Key at:
> > >> >> > >>>
> > >> >> > >>>
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> > >> >> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550
> C311
> > >> >> > >>> 0611
> > >> >> > >>> _______________________________________________
> > >> >> > >>> hibernate-dev mailing list
> > >> >> > >>> hibernate-dev at lists.jboss.org
> > >> >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >> > >>>
> > >> >> > >> _______________________________________________
> > >> >> > >> hibernate-dev mailing list
> > >> >> > >> hibernate-dev at lists.jboss.org
> > >> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >> > > _______________________________________________
> > >> >> > > hibernate-dev mailing list
> > >> >> > > hibernate-dev at lists.jboss.org
> > >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >> > _______________________________________________
> > >> >> > hibernate-dev mailing list
> > >> >> > hibernate-dev at lists.jboss.org
> > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >> >
> > >> >> _______________________________________________
> > >> >> hibernate-dev mailing list
> > >> >> hibernate-dev at lists.jboss.org
> > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >>
> > >> > _______________________________________________
> > >> > hibernate-dev mailing list
> > >> > hibernate-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Mon Jan  4 10:29:11 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 04 Jan 2016 15:29:11 +0000
Subject: [hibernate-dev] javax.money
In-Reply-To: <CAKnbemVzf5rn6Q40Sgt-SPD6pP2Qx8mOkVn2bapWOtFQ7NKE+A@mail.gmail.com>
References: <CAKnbemUS2aFQioUBpt+6swKoSqS0Y77PvvXRBKq9ZFvjhRhq4A@mail.gmail.com>
	<CAFdSV9tCUK_zPEFw7a=mqE24BJ-v-g7gZQNo+-axzk+foQCfBA@mail.gmail.com>
	<CADGJaX_yC+-hqDcJ5zRq3JfzfoWTVQ1XV_AcCTru-m=Y0t12Cg@mail.gmail.com>
	<CAFm4XO1kBZ-bQs899rc4eX+2dqrL5OzJaCXnyRc1mqsA7owe2A@mail.gmail.com>
	<CA+gWKMAeZGYEx5hWokBixhkHSVLcNp__MnuwJ0rxdeFSS0nzww@mail.gmail.com>
	<CAFdSV9t77uU7vQUz8Fu+uc-B++qnZSLo919xwY_5wAqo-7-xuw@mail.gmail.com>
	<CADGJaX87VTFa+WdZoikg0nZkd72UMD_7sTY9PAA=O75Oe2yJNg@mail.gmail.com>
	<CAFdSV9vepP+YB+QzJ37UehzamKiu7ckEx94QgWfx122Ec5orCw@mail.gmail.com>
	<CADGJaX-Nr4F7_HZXkyyoqwvUny0L3_i5zATTVFmOeqDAu5UoMg@mail.gmail.com>
	<CAFdSV9tpm0gMs-Hk96fF1jSiLcKo0qqh7zV5D91vNKWzkBdLVQ@mail.gmail.com>
	<CAKnbemVzf5rn6Q40Sgt-SPD6pP2Qx8mOkVn2bapWOtFQ7NKE+A@mail.gmail.com>
Message-ID: <CAFdSV9udks-6K0+dL6CgiXG1ycBSK9zuPMh52dYt-fJpX824HQ@mail.gmail.com>

For sure we will support it in some fashion.  The discussion is simply
about the how

On Mon, Jan 4, 2016 at 1:04 AM Petar Tahchiev <paranoiabla at gmail.com> wrote:

> Any updates on this? What has been decided? Can we see some hibernate
> support for this JSR?
>
> 2015-12-26 19:13 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> Correct.  And things are "possible in any number of ways".  Some are just
>> more right than others.  The fun is the fact that the question of which
>> which is more right can be different depending on your perspective and
>> that
>> is clearly the case here.
>>
>> >From the user's perspective the best solution is actually the least
>> attractive from the Hibernate development side of things... specifically
>> the best option for the user is for Hibernate to specify a compile-only
>> dependency (optional, provided, etc is irrelevant) and for Hibernate to
>> internally isolate itself from cases where javax.money is not available on
>> the classpath (reflection, etc).  Ultimately I think this is the direction
>> to go for this particular integration.
>>
>> On Wed, Dec 23, 2015 at 2:23 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>> > It's software, so everything is *possible*. Question is whether we
>> > deem it acceptable for the user having to depend on another submodule
>> > or not. If you think that's ok, then go for it ;)
>> >
>> >
>> > 2015-12-22 23:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > > You mean in addition to Maven's own documentation?  Quote[1]:
>> > >
>> > > "Optional dependencies are used when it's not really possible (for
>> > whatever
>> > > reason) to split a project up into sub-modules. The idea is that some
>> of
>> > the
>> > > dependencies are only used for certain features in the project, and
>> will
>> > not
>> > > be needed if that feature isn't used. Ideally, such a feature would be
>> > split
>> > > into a sub-module that depended on the core functionality
>> project...this
>> > new
>> > > subproject would have only non-optional dependencies, since you'd need
>> > them
>> > > all if you decided to use the subproject's functionality."
>> > >
>> > > Beyond Maven's own documentation, simply google...
>> > >
>> > > [1]
>> > >
>> >
>> https://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
>> > >
>> > > On Tue, Dec 22, 2015 at 3:50 PM Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> > >>
>> > >> To me, "optional" seems like the right thing for this case.
>> "Provided"
>> > >> (at least in the Maven world, I don't know whether Gradle has
>> > >> different semantics) suggests that this stuff is really to be
>> provided
>> > >> by the runtime; I interpret this as a mandatory requirement towards
>> > >> the environment (i.e. a Java EE container *has* to provide the
>> javax.*
>> > >> packages).
>> > >>
>> > >> Optional instead indicates that this stuff may be present at runtime
>> > >> or not. If it is present, some optional functionality will be
>> > >> available to the user, otherwise not. For the case of Money the user
>> > >> is depending on these types anyways - and thus required to expose
>> them
>> > >> on the runtime class path -  if he is wishing to work with these
>> types
>> > >> in his own code (or not otherwise). No need to analyse the dependency
>> > >> graph or whatsoever.
>> > >>
>> > >> As said we use that style in Hibernate Validator for optional
>> > >> constraint validators, and it works well, I can't remember of any
>> > >> related issue or complaint. I suppose it'd help if you could point to
>> > >> that resource describing potential issues with optional.
>> > >>
>> > >> 2015-12-22 20:31 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > >> > Well the Bitronix use-case is actually a perfect illustration of
>> why
>> > >> > optional/provided dependencies stink.  Nothing in the dependency
>> graph
>> > >> > indicates what you are expected to do here.  Bitronix users would
>> have
>> > >> > to
>> > >> > look at the documentation to understand this; and dependency
>> > >> > graph/analysis
>> > >> > tools would be completely at a loss.  And in Bitronix the
>> "decision"
>> > is
>> > >> > all
>> > >> > internal to Bitronix.  Here at least the argument is a little more
>> > >> > justified because we are really talking about looking to see if
>> > another
>> > >> > set
>> > >> > of classes (library) are present from the application's classloader
>> > >> > (since
>> > >> > the application would need to bind to Moneta, etc statically).
>> > >> >
>> > >> > 'optional' is flat out wrong; that is well documented elsewhere.  I
>> > can
>> > >> > be
>> > >> > persuaded to use 'provided' for something like this, as I already
>> > >> > stated.
>> > >> >
>> > >> >
>> > >> > On Tue, Dec 22, 2015 at 12:26 PM Vlad Mihalcea <
>> > mihalcea.vlad at gmail.com>
>> > >> > wrote:
>> > >> >
>> > >> >> That's how Bitronix Transaction Manager managed optional
>> dependencies
>> > >> >> as
>> > >> >> well.
>> > >> >> In its case cglib and javassist were optional dependencies and at
>> > >> >> runtime
>> > >> >> the framework decided whether to load one provider or the other.
>> > >> >>
>> > >> >> Vlad
>> > >> >>
>> > >> >> On Tue, Dec 22, 2015 at 8:01 PM, Sanne Grinovero <
>> > sanne at hibernate.org>
>> > >> >> wrote:
>> > >> >>
>> > >> >> > On 22 December 2015 at 17:34, Gunnar Morling <
>> gunnar at hibernate.org
>> > >
>> > >> >> wrote:
>> > >> >> > >> yes we could use an optional/provided dependency, but
>> > >> >> > >> that would not be "proper".
>> > >> >> > >
>> > >> >> > > That would actually be my preference; If the javax.money types
>> > are
>> > >> >> > > present, enable the required Types etc. otherwise not. It's a
>> > >> >> > > pattern
>> > >> >> > > we e.g. use in Validator, too, where we provide additional
>> > >> >> > > constraint
>> > >> >> > > validator types based on what's available in the runtime
>> > >> >> > > environment.
>> > >> >> >
>> > >> >> > +1
>> > >> >> >
>> > >> >> > > Why do you consider it as not proper?
>> > >> >> >
>> > >> >> > Same question for me. It might not be perfectly well defined in
>> > terms
>> > >> >> > of Maven dependencies, still I think the practical benefit for
>> > users
>> > >> >> > far outweights the cons.. if that's what you're referring to.
>> > >> >> >
>> > >> >> > Sanne
>> > >> >> >
>> > >> >> > >
>> > >> >> > >
>> > >> >> > > 2015-12-22 17:03 GMT+01:00 Steve Ebersole <
>> steve at hibernate.org>:
>> > >> >> > >> I had planned to support this JSR when I thought it would be
>> > part
>> > >> >> > >> of
>> > >> >> the
>> > >> >> > >> JDK.  But as it is, supporting this properly would mean a
>> whole
>> > >> >> > >> new
>> > >> >> > >> module/artifact just to add these few types + the dependency
>> > >> >> > >> (similar
>> > >> >> to
>> > >> >> > >> hibernate-java8).  I am not a fan of the fact that it would
>> > >> >> > >> require a
>> > >> >> > >> separate dependency; yes we could use an optional/provided
>> > >> >> > >> dependency,
>> > >> >> > but
>> > >> >> > >> that would not be "proper".
>> > >> >> > >>
>> > >> >> > >> I am interested in what others think.
>> > >> >> > >>
>> > >> >> > >> On Mon, Dec 21, 2015, 1:37 PM Petar Tahchiev
>> > >> >> > >> <paranoiabla at gmail.com>
>> > >> >> > wrote:
>> > >> >> > >>
>> > >> >> > >>> Hi guys,
>> > >> >> > >>>
>> > >> >> > >>> I've been playing lately with JSR 354 javax.money api (
>> > >> >> > >>> http://javamoney.java.net) and I was wondering if there's
>> any
>> > >> >> > >>> plans
>> > >> >> > for
>> > >> >> > >>> hibernate to support this.
>> > >> >> > >>>
>> > >> >> > >>> Thanks.
>> > >> >> > >>>
>> > >> >> > >>> --
>> > >> >> > >>> Regards, Petar!
>> > >> >> > >>> Karlovo, Bulgaria.
>> > >> >> > >>> ---
>> > >> >> > >>> Public PGP Key at:
>> > >> >> > >>>
>> > >> >> > >>>
>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> > >> >> > >>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550
>> C311
>> > >> >> > >>> 0611
>> > >> >> > >>> _______________________________________________
>> > >> >> > >>> hibernate-dev mailing list
>> > >> >> > >>> hibernate-dev at lists.jboss.org
>> > >> >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> > >>>
>> > >> >> > >> _______________________________________________
>> > >> >> > >> hibernate-dev mailing list
>> > >> >> > >> hibernate-dev at lists.jboss.org
>> > >> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> > > _______________________________________________
>> > >> >> > > hibernate-dev mailing list
>> > >> >> > > hibernate-dev at lists.jboss.org
>> > >> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> > _______________________________________________
>> > >> >> > hibernate-dev mailing list
>> > >> >> > hibernate-dev at lists.jboss.org
>> > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >> >
>> > >> >> _______________________________________________
>> > >> >> hibernate-dev mailing list
>> > >> >> hibernate-dev at lists.jboss.org
>> > >> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >>
>> > >> > _______________________________________________
>> > >> > hibernate-dev mailing list
>> > >> > hibernate-dev at lists.jboss.org
>> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From steve at hibernate.org  Mon Jan  4 10:50:11 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 04 Jan 2016 15:50:11 +0000
Subject: [hibernate-dev] Spambots can break the gdCaptcha we use for the
	forum
In-Reply-To: <CA+gWKMB8MzVVc48aV1b8B_LE_JGrr9ZXrNt9U-km4Eeb7pYh6w@mail.gmail.com>
References: <CA+gWKMB8MzVVc48aV1b8B_LE_JGrr9ZXrNt9U-km4Eeb7pYh6w@mail.gmail.com>
Message-ID: <CAFdSV9u72YFLJ_Vfm1QEJM7Y0e-8Qr-RGvg6pfmGmzh12Rnxpg@mail.gmail.com>

I thought we had agreed to try what that linked post calls "Newly
Registered Users Group"?  Specifically:

<quote>
phpBB 3.0.6 also sees the introduction of the "Newly Registered Users"
group. This feature, which may be enabled via the User Registration
Settings page of the Administration Control Panel (ACP), allows the
administrator to define a minimum post count; if a user is below this limit
they will be a member of the Newly Registered Users group. Permissions may
be set on this group much like any other group -- an example use is to
place the Newly Registered Users group on the moderation queue for all
forums. The user is automatically removed from the group when they reach
the defined post amount. Be aware that this feature is not retroactive --
users who registered prior to a board's upgrade to phpBB 3.0.6 will not be
placed in the Newly Registered Users group, regardless of their post count.
</quote>

I get the "not retroactive" part, but really no solution is going to help
us retroactively.

On Sun, Dec 27, 2015 at 1:02 PM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I bumped into this phpBB discussion, where it's started that most captchas
> have been broken by spambots (including the gdCaptcha we use for the
> Hibernate forum):
>
> https://www.phpbb.com/community/viewtopic.php?f=46&t=2122696
>
> Should we add an admin user registration option, which might break the
> smapbots automatic scripts because of the variable account activation
> interval?
>
> What do you think?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Tue Jan  5 01:42:32 2016
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 4 Jan 2016 22:42:32 -0800
Subject: [hibernate-dev] Oracle12cDialect identity support
In-Reply-To: <CAFdSV9v5knGMmXRVjJLUXKbaSSe4+VbvLw7W0eojiDgXuD49Gw@mail.gmail.com>
References: <CAFDzhiTAB2VZ0TuGmKeffBYcC_E4G46hQjup80Xsr2K3eQ7wKA@mail.gmail.com>
	<5630A09D-94CC-4077-8C6F-8C34CC42D14F@hibernate.org>
	<CAFdSV9v5knGMmXRVjJLUXKbaSSe4+VbvLw7W0eojiDgXuD49Gw@mail.gmail.com>
Message-ID: <CAFDzhiT4ZcRh4toSjQGC08PPEK32jA2HS3J_dAWsgx616SCGCQ@mail.gmail.com>

Please see below...

On Sat, Dec 26, 2015 at 8:52 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I'd prefer that IDENTITY never be the native generator any time we add a
> new Dialect.
>

+1


>  Native is a Hibernate-only concept and so we can really choose whatever
> we want for native generators.  Also native is an outdated concept,
> replaced by AUTO and SequenceStyleGenerator.  IMO we should never be
> choosing IDENTITY for identifier generation unless a user explicitly asks
> for it.
>

Just to make sure I understand, are you saying we should not be choosing
IDENTITY by default for *new* dialects only?


> So for the first piece, Oracle12cDialect should
> override getNativeIdentifierGeneratorClass to
> return SequenceStyleGenerator.  The Dialect implementation
> of getNativeIdentifierGeneratorClass really assumes databases which support
> IDENTITY but not SEQUENCE.
>

Thanks for clarifying that. I was wondering about that.


> Oracle12cDialect is the first case we have had where a database that
> historically supported SEQUENCES has added support for IDENTITY and we just
> did not account for that properly.  In fact, the "proper" solution would be
> to go into the base Oracle Dialect(s) and override
> getNativeIdentifierGeneratorClass to just always
> return SequenceStyleGenerator.  But doing that in SequenceStyleGenerator
> only is viable too.
>

Did you mean, "doing that in Oracle12cDialect only is viable too"?


>
> As for how to get IDENTITY generation to work consistently with Oracle,
> that I cannot say.  I asked Oscar (the reporter of HHH-9983) for find out
> the way to get IDENTITY generation to work with Oracle 12c *via JDBC*.
>  "Via JDBC" is the operative part.  All of the Oracle documentation and
> google hits at that time only discussed using IDENTITY via command told
> (SQLPlus, etc).  According to his findings we seem to have to correct.
>

I believe Oracle12cDialect identity support is working properly in master
now.

IIUC you are saying that the problem is porting that from 5.1 (master) to
> 5.0?  Due to an SPI change?  What exactly is the SPI that changed?  We did
> make lots of changes to "IdentityColumnSupport" (adding that as a
> first-class contract), but that is really just cosmetic grouping of stuff
> already available on Dialect.  So what change specifically stops you from
> porting those changes to 5.0?
>

I've looked over the changes again and I think the main problem is that the
refactoring done for HHH-10084 [1] will break custom dialects that override
the Dialect methods that are deprecated for 5.1. The deprecated Dialect
methods are no longer used; Hibernate obtains the identity support
information from Dialect#getIdentityColumnSupport only.

I've created a test to illustrate: [2].

Custom dialects will need to be modified to override
getIdentityColumnSupport() to work. Would this type of breaking change be
OK for 5.1 (I'm guessing no...). IMO, it is not OK to introduce this
breaking change in 5.0.

HHH-10084 ([1]) changed the deprecated Dialect methods to delegate to the
IdentityColumnSupport. It also extracted the overridden methods from
Dialect subclasses into dialect-specific IdentityColumnSupport classes.

If I backport HHH-9983 to 5.0, I think I would only backport part of
HHH-10084. I would change IdentityColumnSupportImpl methods to delegate to
the deprecated Dialect methods; I would not extract the overridden methods
into dialect-specific IdentityColumnSupport classes. That way, custom
dialects would not be broken.

What do others think about this breaking change in 5.1? If it's not
acceptable, then I propose making the same changes to master (backing out
of the changes where overridden methods are extracted into dialect-specific
IdentityColumnSupport). The extraction would be delayed until the
deprecated methods are removed (in 6.0?).

WDYT?

Thanks,
Gail

[1]
https://github.com/hibernate/hibernate-orm/commit/2731fe541a4b297e399d46357ad9eb5bbe2d2239
[2]
https://github.com/gbadner/hibernate-core/commit/c1510fce39351728a938cd33529cc39c57c2ca84


> On Thu, Dec 24, 2015 at 4:58 AM Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>
>> I think my preference would be to override in Oracle*Dialect
>> getNativeIdentifierGeneratorClass so that it always returns
>> SequenceStyleGenerator
>>
>> 1. it would be backward compatible with the logic we had for ever (with
>> the exception of 5.0 but I understand that it is not really reliable)
>> 2. I suppose sequences are still the preferred choices for Oracle DB DBAs.
>>
>> Emmanuel
>>
>> > On 24 Dec 2015, at 02:46, Gail Badner <gbadner at redhat.com> wrote:
>> >
>> > Oracle12cDialect was added in 5.0 by HHH-9044. Unfortunately there are
>> > problems with the new identity support that Oracle12cDialect introduced
>> > (HHH-9983). The fix for HHH-9983 involved SPI changes, so it was
>> applied to
>> > master for 5.1 (only).
>> >
>> > A couple of weeks ago, Andrea found that identities seemed to work using
>> > 5.0 when running BulkManipulationTest using Oracle JDBC 12.1.0.1.0. At
>> the
>> > same time it failed for me in the same way as HHH-9983 using 12.1.0.2.0.
>> > Then Andrea and I switched the JDBC versions (Andrea tried 12.1.0.1.0; I
>> > tried 12.1.0.2.0) and we were both able to run BulkManipulationTest
>> > successfully. This was very strange, especially since we were using the
>> > same Oracle instance, each using a different user. I didn't see any
>> > difference in how we were setting Hibernate properties. Several days
>> later,
>> > I tried Oracle JDBC 12.1.0.2.0 again, but BulkManipulationTest was
>> failing
>> > again in the same way as HHH-9983.
>> >
>> > Does anyone know how to get Oracle12cDialect's identity support to work
>> for
>> > 5.0 reliably? Is there some version of Oracle JDBC or DB configuration
>> that
>> > is required?
>> >
>> > If so, please let me know. The rest of this email assumes it is not
>> > possible. If I'm missing some configuration detail, then just ignore the
>> > rest of this message.
>> >
>> > When the unit tests are run using Oracle12cDialect on 5.0, there are
>> many
>> > failures:
>> > * tests with entities explicitly mapped to use an identity fail; these
>> > failures did not happen in 4.3 using Oracle10gDialect because these
>> tests
>> > where skipped (because Oracle10cDialect#supportsIdentityColumns returns
>> > false)
>> > * use @GeneratedValue with default strategy or use hbm mapping for ID
>> > <generator class="native"/>; these failures did not happen in 4.3
>> because
>> > the native generator for Oracle10gDialect uses a sequence; the native
>> > generator for Oracle12cDialect uses an identity.
>> >
>> > Also, starting in 5.0, when using Oracle 12c, StandardDialectResolver
>> will
>> > automatically resolve to Oracle12cDialect if the dialect is not
>> explicitly
>> > mapped. Previously it would have resolved ot Oracle10gDialect.
>> >
>> > I would be OK with changing the native generator in 5.0 from sequence to
>> > identity if identities were working properly. I think it will cause
>> > confusion when applications break. To get things working with 5.0,
>> > applications will need to explicitly set the dialect to
>> Oracle10gDialect,
>> > extend Oracle12cDialect to disable identity support, or change ID
>> mappings
>> > to specify sequences.
>> >
>> > Here are some alternatives to get things working.
>> >
>> > Alternative A:
>> > 1) for 5.0 through 5.x override
>> Dialect#getNativeIdentifierGeneratorClass
>> > to return SequenceStyleGenerator.class; I suggest the change for 5.x
>> > because I don't think it would be an acceptable to change the native
>> > generator for Oracle12cDialect from using a sequence to using an
>> identity
>> > in  5.x;
>> > 2) for 5.0 only, remove support for identities;
>> > 3) for 6.0, if desireable, extend Oracle12gDialect (or whatever is
>> current
>> > at that time) to change the native generator to use an identity.
>> >
>> > Alternative B:
>> > 1) for 5.0 through 5.x, leave Oracle12cDialect as is, and add a new
>> dialect
>> > with native generator that uses a sequence (i.e.,
>> > Oracle12cNativeSequenceGeneratorDialect or something else that is not so
>> > ugly);
>> > 2) for 5.0 through 5.x, change StandardDialectResolver to automatically
>> > resolve to Oracle12cNativeSequenceGeneratorDialect for Oracle 12g
>> server.
>> >
>> > Alternative C:
>> > 1) for 5.0 through 5.x, change native generator for Oracle12cDialect to
>> use
>> > sequence; leave identity support as is (broken in 5.0; fixed in 5.1);
>> > 2) for 5.0 through 5.x, add a new dialect with native generator that
>> uses
>> > an identity (Oracle12cNativeIdentityGeneratorDialect or something else
>> that
>> > is not so ugly).
>> > 3) change StandardDialectResolver to automatically resolve to
>> > Oracle12cDialect for Oracle 12g server.
>> >
>> > I prefer alternative A. Alternatives B and C involve maintaining 2
>> dialects
>> > for the same Oracle version; I would think that one of them would be
>> > deprecated moving forward.
>> >
>> > Thoughts?
>> >
>> > Thanks,
>> > Gail
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Tue Jan  5 07:55:27 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 5 Jan 2016 13:55:27 +0100
Subject: [hibernate-dev] Not letting Jenkins auto-close PRs upon build
	failures
Message-ID: <CADGJaX8w2NitAT+KR7pk+iUF16uq=BF=qh5Sv8R0B7+9mvA-EQ@mail.gmail.com>

Hi,

Not sure whether that's a new behaviour, but it's super annoying that
the pull request builder automatically closes pull requests if there
is a build failure. Can we change this so the PR stays open, please?

The current behaviour is highly frustrating, you need to re-open the
PR again after fixes, and in the worst case a PR falls through the
cracks because it's moved out to the "Closed" tab right away. It's
especially bad for contributor PRs where the failure is caused by
ourselves, e.g. build environment issues.

Thanks,

--Gunnar

From emmanuel at hibernate.org  Tue Jan  5 08:02:18 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 5 Jan 2016 14:02:18 +0100
Subject: [hibernate-dev] Not letting Jenkins auto-close PRs upon build
	failures
In-Reply-To: <CADGJaX8w2NitAT+KR7pk+iUF16uq=BF=qh5Sv8R0B7+9mvA-EQ@mail.gmail.com>
References: <CADGJaX8w2NitAT+KR7pk+iUF16uq=BF=qh5Sv8R0B7+9mvA-EQ@mail.gmail.com>
Message-ID: <B02E01A4-B6C4-43A3-80B2-D61F9701FE60@hibernate.org>

+1, but I don?t know how ;)

> On 05 Jan 2016, at 13:55, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi,
> 
> Not sure whether that's a new behaviour, but it's super annoying that
> the pull request builder automatically closes pull requests if there
> is a build failure. Can we change this so the PR stays open, please?
> 
> The current behaviour is highly frustrating, you need to re-open the
> PR again after fixes, and in the worst case a PR falls through the
> cracks because it's moved out to the "Closed" tab right away. It's
> especially bad for contributor PRs where the failure is caused by
> ourselves, e.g. build environment issues.
> 
> Thanks,
> 
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From smarlow at redhat.com  Tue Jan  5 10:35:07 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 5 Jan 2016 10:35:07 -0500
Subject: [hibernate-dev] should immutable entities in the second level cache
 be invalidated when they are removed from the database?
Message-ID: <568BE2AB.7000103@redhat.com>

I missed adding the WildFly clustering configuration for the Hibernate 
immutable-entity cache.  I opened WFLY-5923 [1] for adding the cache but 
am unsure of whether org.hibernate.annotations.Immutable means that the 
application handles clearing the 2lc of stale immutable entities or if 
that should happen automagically when immutable entities are removed 
from the database.

In a cluster, I expect that the performance of caching 
immutable-entities, would be faster if we assume they will not be 
invalidated from the 2lc (e.g. let applications clear them from the 
cache).

Since we are using Infinispan for the 2lc in WildFly, I would like to 
use an Infinispan simple-cache for immutable-entities, which does no 
invalidation.  However, just because I would like to do this, doesn't 
make it right. :-)  Which is why I'm asking, what the design intention 
is, so I can configure the WildFly clustering configuration (for 
immutable entities), to align with the intent.

 From Immutable javadoc:
"
Mark an Entity or a Collection as immutable. No annotation means the 
element is mutable.

An immutable entity may not be updated by the application. Updates to an 
immutable entity will be ignored, but no exception is thrown.
...
"

Scott

[1] https://issues.jboss.org/browse/WFLY-5923


From steve at hibernate.org  Tue Jan  5 12:36:16 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 05 Jan 2016 17:36:16 +0000
Subject: [hibernate-dev] should immutable entities in the second level
 cache be invalidated when they are removed from the database?
In-Reply-To: <568BE2AB.7000103@redhat.com>
References: <568BE2AB.7000103@redhat.com>
Message-ID: <CAFdSV9uCLnNbb=Z=XaZEs9RDNFeWYyrkQ+1UE0RkOf=TsUKJDg@mail.gmail.com>

Sorry Scott, I am not sure I understand exactly what you are asking.  I
will try to answer what I think you are asking as best I can..


On Tue, Jan 5, 2016 at 9:35 AM Scott Marlow <smarlow at redhat.com> wrote:

> I missed adding the WildFly clustering configuration for the Hibernate
> immutable-entity cache.  I opened WFLY-5923 [1] for adding the cache but
> am unsure of whether org.hibernate.annotations.Immutable means that the
> application handles clearing the 2lc of stale immutable entities or if
> that should happen automagically when immutable entities are removed
> from the database.
>

Perhaps there is a confusion that an immutable entity can in fact be
created and deleted?  Immutable simply means the state of an existing
entity cannot be changed.  In SQL terms, if you will, we can have an INSERT
or a DELETE but never an UPDATE.

If an application has asked that Hibernate cache data, the expectation is
that Hibernate would handle the caching of that data not the application
*so long as it knows about changes to the cached data*.  Now if by "when
immutable entities are removed from the database" you are asking what
should happen when cached data is changed in the database directly, that
answer is always the same and the question of (im)mutablity is completely
irrelevant there: if the underlying data is changed directly in the
database it is up to the application to make sure that the cache is
consistent with those outside changes.



> In a cluster, I expect that the performance of caching
> immutable-entities, would be faster if we assume they will not be
> invalidated from the 2lc (e.g. let applications clear them from the
> cache).
>

I think really this comes down to the question of what "invalidated" means
to the underlying cache and how a deletion of data correlates to that.  But
my guess is that the invalidation still needs to handled (and propagated)
to properly handle the removal case.


Since we are using Infinispan for the 2lc in WildFly, I would like to
> use an Infinispan simple-cache for immutable-entities, which does no
> invalidation.  However, just because I would like to do this, doesn't
> make it right. :-)  Which is why I'm asking, what the design intention
> is, so I can configure the WildFly clustering configuration (for
> immutable entities), to align with the intent.
>

Right, which is what I am trying to describe I guess in my previous
paragraph.  Based on my (granted, very limited) understanding of Infinispan
I assume we still need the invalidation.  One possible option is to allow
the application to configure whether they expect removals from an immutable
dataset.

From steve at hibernate.org  Tue Jan  5 12:46:50 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 05 Jan 2016 17:46:50 +0000
Subject: [hibernate-dev] Oracle12cDialect identity support
In-Reply-To: <CAFDzhiT4ZcRh4toSjQGC08PPEK32jA2HS3J_dAWsgx616SCGCQ@mail.gmail.com>
References: <CAFDzhiTAB2VZ0TuGmKeffBYcC_E4G46hQjup80Xsr2K3eQ7wKA@mail.gmail.com>
	<5630A09D-94CC-4077-8C6F-8C34CC42D14F@hibernate.org>
	<CAFdSV9v5knGMmXRVjJLUXKbaSSe4+VbvLw7W0eojiDgXuD49Gw@mail.gmail.com>
	<CAFDzhiT4ZcRh4toSjQGC08PPEK32jA2HS3J_dAWsgx616SCGCQ@mail.gmail.com>
Message-ID: <CAFdSV9sCSPgfY-ovZf+q202hu_r3p5va=EzCsQNfao-bNf80Hw@mail.gmail.com>

On Tue, Jan 5, 2016 at 12:42 AM Gail Badner <gbadner at redhat.com> wrote:

>
>
>>  Native is a Hibernate-only concept and so we can really choose whatever
>> we want for native generators.  Also native is an outdated concept,
>> replaced by AUTO and SequenceStyleGenerator.  IMO we should never be
>> choosing IDENTITY for identifier generation unless a user explicitly asks
>> for it.
>>
>
> Just to make sure I understand, are you saying we should not be choosing
> IDENTITY by default for *new* dialects only?
>

Well in an ideal world where we can time-travel and retroactively apply our
gained 20/20 hindsight I would change that everywhere.  However we don't
have that luxury :)  So, yes, I would do that just for new Dialects.

So moving forward, any new Dialect should never chose {"native" ->
IDENTITY} and should never chose {AUTO -> IDENTITY}.



>
>
>> So for the first piece, Oracle12cDialect should
>> override getNativeIdentifierGeneratorClass to
>> return SequenceStyleGenerator.  The Dialect implementation
>> of getNativeIdentifierGeneratorClass really assumes databases which support
>> IDENTITY but not SEQUENCE.
>>
>
> Thanks for clarifying that. I was wondering about that.
>
>
>> Oracle12cDialect is the first case we have had where a database that
>> historically supported SEQUENCES has added support for IDENTITY and we just
>> did not account for that properly.  In fact, the "proper" solution would be
>> to go into the base Oracle Dialect(s) and override
>> getNativeIdentifierGeneratorClass to just always
>> return SequenceStyleGenerator.  But doing that in SequenceStyleGenerator
>> only is viable too.
>>
>
> Did you mean, "doing that in Oracle12cDialect only is viable too"?
>

Yes.  Considering I typed that on my phone I am shocked that was my only
typo :)


>
>>
>> As for how to get IDENTITY generation to work consistently with Oracle,
>> that I cannot say.  I asked Oscar (the reporter of HHH-9983) for find out
>> the way to get IDENTITY generation to work with Oracle 12c *via JDBC*.
>>  "Via JDBC" is the operative part.  All of the Oracle documentation and
>> google hits at that time only discussed using IDENTITY via command told
>> (SQLPlus, etc).  According to his findings we seem to have to correct.
>>
>
> I believe Oracle12cDialect identity support is working properly in master
> now.
>
> IIUC you are saying that the problem is porting that from 5.1 (master) to
>> 5.0?  Due to an SPI change?  What exactly is the SPI that changed?  We did
>> make lots of changes to "IdentityColumnSupport" (adding that as a
>> first-class contract), but that is really just cosmetic grouping of stuff
>> already available on Dialect.  So what change specifically stops you from
>> porting those changes to 5.0?
>>
>
> I've looked over the changes again and I think the main problem is that
> the refactoring done for HHH-10084 [1] will break custom dialects that
> override the Dialect methods that are deprecated for 5.1. The deprecated
> Dialect methods are no longer used; Hibernate obtains the identity support
> information from Dialect#getIdentityColumnSupport only.
>

Then the deprecated Dialect methods ought to be removed.  Leaving them only
causes confusion


>
> I've created a test to illustrate: [2].
>
> Custom dialects will need to be modified to override
> getIdentityColumnSupport() to work. Would this type of breaking change be
> OK for 5.1 (I'm guessing no...). IMO, it is not OK to introduce this
> breaking change in 5.0.
>

I am not sure what you are asking when you say "Would this type of breaking
change be OK for 5.1"



>
> HHH-10084 ([1]) changed the deprecated Dialect methods to delegate to the
> IdentityColumnSupport. It also extracted the overridden methods from
> Dialect subclasses into dialect-specific IdentityColumnSupport classes.
>
> If I backport HHH-9983 to 5.0, I think I would only backport part of
> HHH-10084. I would change IdentityColumnSupportImpl methods to delegate to
> the deprecated Dialect methods; I would not extract the overridden methods
> into dialect-specific IdentityColumnSupport classes. That way, custom
> dialects would not be broken.
>

This kind of multi-dispatch makes my head hurt.  And I bet users don't find
it any less confusing...

From smarlow at redhat.com  Tue Jan  5 12:51:18 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 5 Jan 2016 12:51:18 -0500
Subject: [hibernate-dev] should immutable entities in the second level
 cache be invalidated when they are removed from the database?
In-Reply-To: <CAFdSV9uCLnNbb=Z=XaZEs9RDNFeWYyrkQ+1UE0RkOf=TsUKJDg@mail.gmail.com>
References: <568BE2AB.7000103@redhat.com>
	<CAFdSV9uCLnNbb=Z=XaZEs9RDNFeWYyrkQ+1UE0RkOf=TsUKJDg@mail.gmail.com>
Message-ID: <568C0296.8000009@redhat.com>


On 01/05/2016 12:36 PM, Steve Ebersole wrote:
> Sorry Scott, I am not sure I understand exactly what you are asking.  I
> will try to answer what I think you are asking as best I can..
>
>
> On Tue, Jan 5, 2016 at 9:35 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     I missed adding the WildFly clustering configuration for the Hibernate
>     immutable-entity cache.  I opened WFLY-5923 [1] for adding the cache but
>     am unsure of whether org.hibernate.annotations.Immutable means that the
>     application handles clearing the 2lc of stale immutable entities or if
>     that should happen automagically when immutable entities are removed
>     from the database.
>
>
> Perhaps there is a confusion that an immutable entity can in fact be
> created and deleted?  Immutable simply means the state of an existing
> entity cannot be changed.  In SQL terms, if you will, we can have an
> INSERT or a DELETE but never an UPDATE.

Thanks for the answer, this is exactly what I needed to know.

>
> If an application has asked that Hibernate cache data, the expectation
> is that Hibernate would handle the caching of that data not the
> application *so long as it knows about changes to the cached data*.  Now
> if by "when immutable entities are removed from the database" you are
> asking what should happen when cached data is changed in the database
> directly, that answer is always the same and the question of
> (im)mutablity is completely irrelevant there: if the underlying data is
> changed directly in the database it is up to the application to make
> sure that the cache is consistent with those outside changes.
>
>     In a cluster, I expect that the performance of caching
>     immutable-entities, would be faster if we assume they will not be
>     invalidated from the 2lc (e.g. let applications clear them from the
>     cache).
>
>
> I think really this comes down to the question of what "invalidated"
> means to the underlying cache and how a deletion of data correlates to
> that.  But my guess is that the invalidation still needs to handled (and
> propagated) to properly handle the removal case.

Yes, I agree (based on your explanation).

>
>     Since we are using Infinispan for the 2lc in WildFly, I would like to
>     use an Infinispan simple-cache for immutable-entities, which does no
>     invalidation.  However, just because I would like to do this, doesn't
>     make it right. :-)  Which is why I'm asking, what the design intention
>     is, so I can configure the WildFly clustering configuration (for
>     immutable entities), to align with the intent.
>
>
> Right, which is what I am trying to describe I guess in my previous
> paragraph.  Based on my (granted, very limited) understanding of
> Infinispan I assume we still need the invalidation.  One possible option
> is to allow the application to configure whether they expect removals
> from an immutable dataset.

This would be a nice performance enhancement for clustered environments, 
as the (no removals allowed) immutable-entities cache would not need to 
be cluster aware.


From steve at hibernate.org  Tue Jan  5 13:11:48 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 05 Jan 2016 18:11:48 +0000
Subject: [hibernate-dev] HHH-9548 - stored procedures and null parameter
	values
Message-ID: <CAFdSV9u42cjTHy=V0jNZPCxP+QZ-2Xj=5ZfpTGkL_cvukM6uzQ@mail.gmail.com>

HHH-9548[1] presents an interesting conundrum in terms of how to handle
null parameter values in regards to stored procedures and specifically in
terms of any argument defaults that might be defined on the database.  At
the moment our support decides to not pass along the null in the desire to
not "over power" any defined argument defaults - if we pass the NULL, the
database would use that rather than the defined argument default.

Essentially it is one of those 50/50 calls.  I started a discussion on the
JIRA, but please add your thoughts...

[1] https://hibernate.atlassian.net/browse/HHH-9548

From gbadner at redhat.com  Tue Jan  5 21:52:13 2016
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 5 Jan 2016 18:52:13 -0800
Subject: [hibernate-dev] Oracle12cDialect identity support
In-Reply-To: <CAFdSV9sCSPgfY-ovZf+q202hu_r3p5va=EzCsQNfao-bNf80Hw@mail.gmail.com>
References: <CAFDzhiTAB2VZ0TuGmKeffBYcC_E4G46hQjup80Xsr2K3eQ7wKA@mail.gmail.com>
	<5630A09D-94CC-4077-8C6F-8C34CC42D14F@hibernate.org>
	<CAFdSV9v5knGMmXRVjJLUXKbaSSe4+VbvLw7W0eojiDgXuD49Gw@mail.gmail.com>
	<CAFDzhiT4ZcRh4toSjQGC08PPEK32jA2HS3J_dAWsgx616SCGCQ@mail.gmail.com>
	<CAFdSV9sCSPgfY-ovZf+q202hu_r3p5va=EzCsQNfao-bNf80Hw@mail.gmail.com>
Message-ID: <CAFDzhiQGtkV8pOvi3nhFSXZrqy=JDgLWHXygg+v7hS=hv=Kksg@mail.gmail.com>

I was mistaken when I said that an IDENTITY ID will be created when using
@GeneratedValue or @GeneratedValue(strategy= GenerationType.AUTO). With
hibernate.id.new_generator_mappings set to true by default in 5.0 and 5.1,
a SequenceStyleGenerator will be used instead.

Currently, the default for "native" ID generator mapped in hbm.xml uses an
IDENTITY if the dialect supports an IDENTITY. This will be overridden in
Oracle12cDialect as we've been discussing.

On Tue, Jan 5, 2016 at 9:46 AM, Steve Ebersole <steve at hibernate.org> wrote:

>
>
> On Tue, Jan 5, 2016 at 12:42 AM Gail Badner <gbadner at redhat.com> wrote:
>
>>
>>
>>>  Native is a Hibernate-only concept and so we can really choose
>>> whatever we want for native generators.  Also native is an outdated
>>> concept, replaced by AUTO and SequenceStyleGenerator.  IMO we should never
>>> be choosing IDENTITY for identifier generation unless a user explicitly
>>> asks for it.
>>>
>>
>> Just to make sure I understand, are you saying we should not be choosing
>> IDENTITY by default for *new* dialects only?
>>
>
> Well in an ideal world where we can time-travel and retroactively apply
> our gained 20/20 hindsight I would change that everywhere.  However we
> don't have that luxury :)  So, yes, I would do that just for new Dialects.
>
> So moving forward, any new Dialect should never chose {"native" ->
> IDENTITY} and should never chose {AUTO -> IDENTITY}.
>
>
>
>>
>>
>>> So for the first piece, Oracle12cDialect should
>>> override getNativeIdentifierGeneratorClass to
>>> return SequenceStyleGenerator.  The Dialect implementation
>>> of getNativeIdentifierGeneratorClass really assumes databases which support
>>> IDENTITY but not SEQUENCE.
>>>
>>
>> Thanks for clarifying that. I was wondering about that.
>>
>>
>>> Oracle12cDialect is the first case we have had where a database that
>>> historically supported SEQUENCES has added support for IDENTITY and we just
>>> did not account for that properly.  In fact, the "proper" solution would be
>>> to go into the base Oracle Dialect(s) and override
>>> getNativeIdentifierGeneratorClass to just always
>>> return SequenceStyleGenerator.  But doing that in SequenceStyleGenerator
>>> only is viable too.
>>>
>>
>> Did you mean, "doing that in Oracle12cDialect only is viable too"?
>>
>
> Yes.  Considering I typed that on my phone I am shocked that was my only
> typo :)
>
>
>>
>>>
>>> As for how to get IDENTITY generation to work consistently with Oracle,
>>> that I cannot say.  I asked Oscar (the reporter of HHH-9983) for find out
>>> the way to get IDENTITY generation to work with Oracle 12c *via JDBC*.
>>>  "Via JDBC" is the operative part.  All of the Oracle documentation and
>>> google hits at that time only discussed using IDENTITY via command told
>>> (SQLPlus, etc).  According to his findings we seem to have to correct.
>>>
>>
>> I believe Oracle12cDialect identity support is working properly in master
>> now.
>>
>> IIUC you are saying that the problem is porting that from 5.1 (master) to
>>> 5.0?  Due to an SPI change?  What exactly is the SPI that changed?  We did
>>> make lots of changes to "IdentityColumnSupport" (adding that as a
>>> first-class contract), but that is really just cosmetic grouping of stuff
>>> already available on Dialect.  So what change specifically stops you from
>>> porting those changes to 5.0?
>>>
>>
>> I've looked over the changes again and I think the main problem is that
>> the refactoring done for HHH-10084 [1] will break custom dialects that
>> override the Dialect methods that are deprecated for 5.1. The deprecated
>> Dialect methods are no longer used; Hibernate obtains the identity support
>> information from Dialect#getIdentityColumnSupport only.
>>
>
> Then the deprecated Dialect methods ought to be removed.  Leaving them
> only causes confusion
>
>
>>
>> I've created a test to illustrate: [2].
>>
>> Custom dialects will need to be modified to override
>> getIdentityColumnSupport() to work. Would this type of breaking change be
>> OK for 5.1 (I'm guessing no...). IMO, it is not OK to introduce this
>> breaking change in 5.0.
>>
>
> I am not sure what you are asking when you say "Would this type of
> breaking change be OK for 5.1"
>
>
>
>>
>> HHH-10084 ([1]) changed the deprecated Dialect methods to delegate to the
>> IdentityColumnSupport. It also extracted the overridden methods from
>> Dialect subclasses into dialect-specific IdentityColumnSupport classes.
>>
>> If I backport HHH-9983 to 5.0, I think I would only backport part of
>> HHH-10084. I would change IdentityColumnSupportImpl methods to delegate to
>> the deprecated Dialect methods; I would not extract the overridden methods
>> into dialect-specific IdentityColumnSupport classes. That way, custom
>> dialects would not be broken.
>>
>
> This kind of multi-dispatch makes my head hurt.  And I bet users don't
> find it any less confusing...
>
>

From emmanuel at hibernate.org  Wed Jan  6 03:40:23 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 6 Jan 2016 09:40:23 +0100
Subject: [hibernate-dev] [OGM] @Column and embedded objects in OGM
Message-ID: <88F33BA1-CC40-43F2-A086-952300676223@hibernate.org>

Hey guys,

Marco found something that really surprised him. I am not sure if that?s a widespread behavior or just specific to CouchDB?s backend.

@Entity
class A {
   ?
   B embedded;
}

@Embeddable
class B {
    String c;
    @Column(name=?real_d?) d;
}

The document structure is roughly

{
?
    ?embedded?: { ?c?: ?foo? },
    ?real_d?: ?bar"
}

I can see this is happening because the column name has not dot in it. But I would expect as a noob to see the natural behavior and have real_d embedded in the nested document embedded.

Looks like MongoDB does the same and I suspect Noe4J too.

1. Can any one think of a trick (like the naming strategy or something like that) to compensate and do it ?right?.
2. If not, I could not find anything in the documentation nor the FAQ and we should make that very obvious. I finally found some info in the embedded section of MongoDB but Neo4J and CouchDb are silent on the matter. How could we make that clearer in the mean time? FAQ?

Emmanuel

From rvansa at redhat.com  Wed Jan  6 03:41:43 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 6 Jan 2016 09:41:43 +0100
Subject: [hibernate-dev] should immutable entities in the second level
 cache be invalidated when they are removed from the database?
In-Reply-To: <568C0296.8000009@redhat.com>
References: <568BE2AB.7000103@redhat.com>
	<CAFdSV9uCLnNbb=Z=XaZEs9RDNFeWYyrkQ+1UE0RkOf=TsUKJDg@mail.gmail.com>
	<568C0296.8000009@redhat.com>
Message-ID: <568CD347.1080108@redhat.com>

On 01/05/2016 06:51 PM, Scott Marlow wrote:
> On 01/05/2016 12:36 PM, Steve Ebersole wrote:
>> Sorry Scott, I am not sure I understand exactly what you are asking.  I
>> will try to answer what I think you are asking as best I can..
>>
>>
>> On Tue, Jan 5, 2016 at 9:35 AM Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>>      I missed adding the WildFly clustering configuration for the Hibernate
>>      immutable-entity cache.  I opened WFLY-5923 [1] for adding the cache but
>>      am unsure of whether org.hibernate.annotations.Immutable means that the
>>      application handles clearing the 2lc of stale immutable entities or if
>>      that should happen automagically when immutable entities are removed
>>      from the database.
>>
>>
>> Perhaps there is a confusion that an immutable entity can in fact be
>> created and deleted?  Immutable simply means the state of an existing
>> entity cannot be changed.  In SQL terms, if you will, we can have an
>> INSERT or a DELETE but never an UPDATE.
> Thanks for the answer, this is exactly what I needed to know.
>
>> If an application has asked that Hibernate cache data, the expectation
>> is that Hibernate would handle the caching of that data not the
>> application *so long as it knows about changes to the cached data*.  Now
>> if by "when immutable entities are removed from the database" you are
>> asking what should happen when cached data is changed in the database
>> directly, that answer is always the same and the question of
>> (im)mutablity is completely irrelevant there: if the underlying data is
>> changed directly in the database it is up to the application to make
>> sure that the cache is consistent with those outside changes.
>>
>>      In a cluster, I expect that the performance of caching
>>      immutable-entities, would be faster if we assume they will not be
>>      invalidated from the 2lc (e.g. let applications clear them from the
>>      cache).
>>
>>
>> I think really this comes down to the question of what "invalidated"
>> means to the underlying cache and how a deletion of data correlates to
>> that.  But my guess is that the invalidation still needs to handled (and
>> propagated) to properly handle the removal case.
> Yes, I agree (based on your explanation).
>
>>      Since we are using Infinispan for the 2lc in WildFly, I would like to
>>      use an Infinispan simple-cache for immutable-entities, which does no
>>      invalidation.  However, just because I would like to do this, doesn't
>>      make it right. :-)  Which is why I'm asking, what the design intention
>>      is, so I can configure the WildFly clustering configuration (for
>>      immutable entities), to align with the intent.
>>
>>
>> Right, which is what I am trying to describe I guess in my previous
>> paragraph.  Based on my (granted, very limited) understanding of
>> Infinispan I assume we still need the invalidation.  One possible option
>> is to allow the application to configure whether they expect removals
>> from an immutable dataset.
> This would be a nice performance enhancement for clustered environments,
> as the (no removals allowed) immutable-entities cache would not need to
> be cluster aware.

ATM in Infinispan 2LC there's no optimization for Immutable entities, 
because the necessary handling of removals does not differ much from 
updates.
In the past, the immutable-entities configuration was added as Galder 
suggested that in 4.x implementation these can use non-transactional 
cache, but in the end the implementation had flaws causing inconsistencies.

For Immutable and never removed entities, you can AFAIK safely use local 
cache. However I am not aware of any means that would mark entity as 
never removed, or relax the consistency for removals.

Radim

>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From gunnar at hibernate.org  Wed Jan  6 05:40:56 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 6 Jan 2016 11:40:56 +0100
Subject: [hibernate-dev] [OGM] @Column and embedded objects in OGM
In-Reply-To: <88F33BA1-CC40-43F2-A086-952300676223@hibernate.org>
References: <88F33BA1-CC40-43F2-A086-952300676223@hibernate.org>
Message-ID: <CADGJaX8XqO0S_sGjPOAugZKytmAJy9owNRAH5DzSNwg3e0WEJg@mail.gmail.com>

Hi,

Yes, I noticed this some time ago, too. It's tracked by
https://hibernate.atlassian.net/browse/OGM-893.

As it stands, I don't think it's fixable using the ORM
ImplicitNamingStrategy/PhysicalNamingStrategy contracts: The former
doesn't apply for explicitly given names, the latter lacks the
required context to establish the full dot name.

So maybe we could enhance PhysicalNamingStrategy - or have a new
contract specifically for preparing explicit names - to expose the
full attribute path, allowing implementations to prefix the column
with the parent name(s) as we'd need it for the document stores.

Btw. a - cumbersome - workaround is to use @AttributeOverride which
allows to create the right mapping. We can add something to the FAQ if
you like, but then I think it's a bug really which we need to fix, and
we don't have an FAQ entry for each bug.

--Gunnar



2016-01-06 9:40 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> Hey guys,
>
> Marco found something that really surprised him. I am not sure if that?s a widespread behavior or just specific to CouchDB?s backend.
>
> @Entity
> class A {
>    ?
>    B embedded;
> }
>
> @Embeddable
> class B {
>     String c;
>     @Column(name=?real_d?) d;
> }
>
> The document structure is roughly
>
> {
> ?
>     ?embedded?: { ?c?: ?foo? },
>     ?real_d?: ?bar"
> }
>
> I can see this is happening because the column name has not dot in it. But I would expect as a noob to see the natural behavior and have real_d embedded in the nested document embedded.
>
> Looks like MongoDB does the same and I suspect Noe4J too.
>
> 1. Can any one think of a trick (like the naming strategy or something like that) to compensate and do it ?right?.
> 2. If not, I could not find anything in the documentation nor the FAQ and we should make that very obvious. I finally found some info in the embedded section of MongoDB but Neo4J and CouchDb are silent on the matter. How could we make that clearer in the mean time? FAQ?
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Wed Jan  6 10:12:02 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jan 2016 15:12:02 +0000
Subject: [hibernate-dev] HHH-10307 - JTA dependency
Message-ID: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>

HHH-10307[1] is another issue we need to get some consensus on.  Initially
we had removed JTA as a transitive dependency, but that is not really
valid.  We need to discuss alternatives and options.

[1] https://hibernate.atlassian.net/browse/HHH-10307

From mihalcea.vlad at gmail.com  Wed Jan  6 10:53:00 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 6 Jan 2016 17:53:00 +0200
Subject: [hibernate-dev] Hibernate forum inactive users pruning
Message-ID: <CA+gWKMDpbVPgNi7dvdUripoYpczX8LBwobwUMNYSgm580dOV2Q@mail.gmail.com>

Hi,

Among all 75000 registered users, 10000 used to be inactive ones
(registered without any post).

Regular users are always creating an account and post at least one question
on the forum, so there is no reason why we should keep 13 years old user
accounts that haven't posted anything on the forum.

Most have been registered with temporary email addresses or other spam
domain names.

I deleted those and now the forum is so much faster.

Vlad

From steve at hibernate.org  Wed Jan  6 10:55:25 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jan 2016 15:55:25 +0000
Subject: [hibernate-dev] Hibernate forum inactive users pruning
In-Reply-To: <CA+gWKMDpbVPgNi7dvdUripoYpczX8LBwobwUMNYSgm580dOV2Q@mail.gmail.com>
References: <CA+gWKMDpbVPgNi7dvdUripoYpczX8LBwobwUMNYSgm580dOV2Q@mail.gmail.com>
Message-ID: <CAFdSV9vDSavwmrJPuX_Qs7hUOfa1bPKyGio5hqrKLUGCoZ8ZSg@mail.gmail.com>

Awesome!  Although I find it strange that a mere 13% decrease in the number
of registered users would have such a big impact on overall performance of
the forum.

On Wed, Jan 6, 2016 at 9:53 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> Among all 75000 registered users, 10000 used to be inactive ones
> (registered without any post).
>
> Regular users are always creating an account and post at least one question
> on the forum, so there is no reason why we should keep 13 years old user
> accounts that haven't posted anything on the forum.
>
> Most have been registered with temporary email addresses or other spam
> domain names.
>
> I deleted those and now the forum is so much faster.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Jan  6 11:00:23 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 6 Jan 2016 18:00:23 +0200
Subject: [hibernate-dev] Hibernate forum inactive users pruning
In-Reply-To: <CAFdSV9vDSavwmrJPuX_Qs7hUOfa1bPKyGio5hqrKLUGCoZ8ZSg@mail.gmail.com>
References: <CA+gWKMDpbVPgNi7dvdUripoYpczX8LBwobwUMNYSgm580dOV2Q@mail.gmail.com>
	<CAFdSV9vDSavwmrJPuX_Qs7hUOfa1bPKyGio5hqrKLUGCoZ8ZSg@mail.gmail.com>
Message-ID: <CA+gWKMB6TyiYuVGYuT=K65f+bNYuY_8O6GwhVY_LiF3WkRZ4+A@mail.gmail.com>

There must have been some checks probably when the Home page was rendered,
but you can check it out and see the result.
I wish I could find a way to delete banned users too.

My banning routine goes like this:

1. I ban the email address or the whole domain if it's one of those
temporary email domains used by spammers
2. I then delete the spam account to make sure we don't store unnecessary
users in the DB

I noticed that the amount of spam has been reduced, although we still have
it.
They seem to bother to open a Gmail account just to send a post that's not
even visible.
I guess they do it manually, since Gmail should have a more robust Captcha
mechanism.

Vlad

On Wed, Jan 6, 2016 at 5:55 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Awesome!  Although I find it strange that a mere 13% decrease in the
> number of registered users would have such a big impact on overall
> performance of the forum.
>
> On Wed, Jan 6, 2016 at 9:53 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> Among all 75000 registered users, 10000 used to be inactive ones
>> (registered without any post).
>>
>> Regular users are always creating an account and post at least one
>> question
>> on the forum, so there is no reason why we should keep 13 years old user
>> accounts that haven't posted anything on the forum.
>>
>> Most have been registered with temporary email addresses or other spam
>> domain names.
>>
>> I deleted those and now the forum is so much faster.
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Wed Jan  6 11:20:16 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 6 Jan 2016 17:20:16 +0100
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
Message-ID: <CADGJaX-Rr3H=qnnieY9XG0k1XFbdr_W8UF8PZ=wnqmy+ixLMYQ@mail.gmail.com>

To get some clarification: When using solely JDBC, what is required at runtime:

a) the JTA API packages only
b) JTA API and implementation
c) none of the above

?



2016-01-06 16:12 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> HHH-10307[1] is another issue we need to get some consensus on.  Initially
> we had removed JTA as a transitive dependency, but that is not really
> valid.  We need to discuss alternatives and options.
>
> [1] https://hibernate.atlassian.net/browse/HHH-10307
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Jan  6 11:24:13 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jan 2016 16:24:13 +0000
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CADGJaX-Rr3H=qnnieY9XG0k1XFbdr_W8UF8PZ=wnqmy+ixLMYQ@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CADGJaX-Rr3H=qnnieY9XG0k1XFbdr_W8UF8PZ=wnqmy+ixLMYQ@mail.gmail.com>
Message-ID: <CAFdSV9sAiSQy1RPU0WViL7d18UaAjD2c6b=vpqQHqNaAjQtO-g@mail.gmail.com>

(a) just the api


On Wed, Jan 6, 2016 at 10:20 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> To get some clarification: When using solely JDBC, what is required at
> runtime:
>
> a) the JTA API packages only
> b) JTA API and implementation
> c) none of the above
>
> ?
>
>
>
> 2016-01-06 16:12 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > HHH-10307[1] is another issue we need to get some consensus on.
> Initially
> > we had removed JTA as a transitive dependency, but that is not really
> > valid.  We need to discuss alternatives and options.
> >
> > [1] https://hibernate.atlassian.net/browse/HHH-10307
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Jan  6 11:30:41 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 6 Jan 2016 18:30:41 +0200
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
Message-ID: <CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>

Hi,

Since the Hibernate core relies on the JTA dependency, I think we shouldn't
provide that dependency.
When someone doesn't want it he should explicitly mark that (e.g. Maven
exclude).
This way we can also address the parent issue:
https://hibernate.atlassian.net/browse/HHH-10178

Vlad

On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org> wrote:

> HHH-10307[1] is another issue we need to get some consensus on.  Initially
> we had removed JTA as a transitive dependency, but that is not really
> valid.  We need to discuss alternatives and options.
>
> [1] https://hibernate.atlassian.net/browse/HHH-10307
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jan  6 11:36:39 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jan 2016 16:36:39 +0000
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
Message-ID: <CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>

Vlad, the issue is not "someone doesn't want it".  In fact, for the most
part because of our decision to use the JTA contracts in our API "(not)
wanting it" is not really an option.

The issue here is the proliferation of JTA jars (maven coords).  We have
the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns is when
someone wants to use one of the jars other than the one we provide
transitively.  Yes, the result is the same: they still need to exclude the
one we provide transitively.

I have argued this for ages... I think this is a fundamental missing
construct in Maven dependency mappings: the ability to say "remap" all
references to a particular spec jar coord to another.  Gradle luckily
allows users to do that (granted somewhat verbosely), Maven simply does not.


On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> Since the Hibernate core relies on the JTA dependency, I think we
> shouldn't provide that dependency.
> When someone doesn't want it he should explicitly mark that (e.g. Maven
> exclude).
> This way we can also address the parent issue:
> https://hibernate.atlassian.net/browse/HHH-10178
>
> Vlad
> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> HHH-10307[1] is another issue we need to get some consensus on.  Initially
>> we had removed JTA as a transitive dependency, but that is not really
>> valid.  We need to discuss alternatives and options.
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-10307
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From dreborier at gmail.com  Wed Jan  6 11:37:30 2016
From: dreborier at gmail.com (andrea boriero)
Date: Wed, 6 Jan 2016 16:37:30 +0000
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
Message-ID: <CAL00eSSJR2C=jsFqc0fxNbKE2jZz7DgKgpcv7=_ABij12SJfhA@mail.gmail.com>

Hi Vlad,

you mean we should provide that dependency, don't you?

On 6 January 2016 at 16:30, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> Since the Hibernate core relies on the JTA dependency, I think we shouldn't
> provide that dependency.
> When someone doesn't want it he should explicitly mark that (e.g. Maven
> exclude).
> This way we can also address the parent issue:
> https://hibernate.atlassian.net/browse/HHH-10178
>
> Vlad
>
> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > HHH-10307[1] is another issue we need to get some consensus on.
> Initially
> > we had removed JTA as a transitive dependency, but that is not really
> > valid.  We need to discuss alternatives and options.
> >
> > [1] https://hibernate.atlassian.net/browse/HHH-10307
> > _______________________________________________
> > 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 mihalcea.vlad at gmail.com  Wed Jan  6 11:44:36 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 6 Jan 2016 18:44:36 +0200
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
	<CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>
Message-ID: <CA+gWKMAJNBQVaHJMWMQwLHjpZ0FnTJJ4wFp09UvXHP_JHL12+Q@mail.gmail.com>

I thought it was just the javax dependency.
Supplying all those Java EE AS dependency is something else, as you pointed
out.

Adding some separate modules with those dependencies is not an option
either: hibernate-wildfly, hibernate-geronimo, etc?

Vlad

On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Vlad, the issue is not "someone doesn't want it".  In fact, for the most
> part because of our decision to use the JTA contracts in our API "(not)
> wanting it" is not really an option.
>
> The issue here is the proliferation of JTA jars (maven coords).  We have
> the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns is when
> someone wants to use one of the jars other than the one we provide
> transitively.  Yes, the result is the same: they still need to exclude the
> one we provide transitively.
>
> I have argued this for ages... I think this is a fundamental missing
> construct in Maven dependency mappings: the ability to say "remap" all
> references to a particular spec jar coord to another.  Gradle luckily
> allows users to do that (granted somewhat verbosely), Maven simply does not.
>
>
> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> Since the Hibernate core relies on the JTA dependency, I think we
>> shouldn't provide that dependency.
>> When someone doesn't want it he should explicitly mark that (e.g. Maven
>> exclude).
>> This way we can also address the parent issue:
>> https://hibernate.atlassian.net/browse/HHH-10178
>>
>> Vlad
>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> HHH-10307[1] is another issue we need to get some consensus on.
>>> Initially
>>> we had removed JTA as a transitive dependency, but that is not really
>>> valid.  We need to discuss alternatives and options.
>>>
>>> [1] https://hibernate.atlassian.net/browse/HHH-10307
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From steve at hibernate.org  Wed Jan  6 11:59:05 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jan 2016 16:59:05 +0000
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CA+gWKMAJNBQVaHJMWMQwLHjpZ0FnTJJ4wFp09UvXHP_JHL12+Q@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
	<CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>
	<CA+gWKMAJNBQVaHJMWMQwLHjpZ0FnTJJ4wFp09UvXHP_JHL12+Q@mail.gmail.com>
Message-ID: <CAFdSV9v4PVsCuPs=MGF4HabjparzxVf9qS5uKEv23E5r886nGg@mail.gmail.com>

There is nothing "EE AS" specific in any of those jars I mentioned.  They
are all simply different jars of the JTA API.  Every EE spec has the same
problem.  That is the point you are missing.

TBH I forget the history as to why the JBoss's JTA jar (again, nothing
JBoss specific there, just the JTA API) was used rather than
javax.transaction:jta.  That predates our move to git and would require
some digging.  Later we moved from the JBoss JTA jar to the Geronimo
version because the JBoss one had some problem in its OSGi metadata
(the javax.transaction:jta
jar provides zero OSGi metadata btw).



On Wed, Jan 6, 2016 at 10:44 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> I thought it was just the javax dependency.
> Supplying all those Java EE AS dependency is something else, as you
> pointed out.
>
> Adding some separate modules with those dependencies is not an option
> either: hibernate-wildfly, hibernate-geronimo, etc?
>
> Vlad
>
> On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Vlad, the issue is not "someone doesn't want it".  In fact, for the most
>> part because of our decision to use the JTA contracts in our API "(not)
>> wanting it" is not really an option.
>>
>> The issue here is the proliferation of JTA jars (maven coords).  We have
>> the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns is when
>> someone wants to use one of the jars other than the one we provide
>> transitively.  Yes, the result is the same: they still need to exclude the
>> one we provide transitively.
>>
>> I have argued this for ages... I think this is a fundamental missing
>> construct in Maven dependency mappings: the ability to say "remap" all
>> references to a particular spec jar coord to another.  Gradle luckily
>> allows users to do that (granted somewhat verbosely), Maven simply does not.
>>
>>
>> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Since the Hibernate core relies on the JTA dependency, I think we
>>> shouldn't provide that dependency.
>>> When someone doesn't want it he should explicitly mark that (e.g. Maven
>>> exclude).
>>> This way we can also address the parent issue:
>>> https://hibernate.atlassian.net/browse/HHH-10178
>>>
>>> Vlad
>>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> HHH-10307[1] is another issue we need to get some consensus on.
>>>> Initially
>>>> we had removed JTA as a transitive dependency, but that is not really
>>>> valid.  We need to discuss alternatives and options.
>>>>
>>>> [1] https://hibernate.atlassian.net/browse/HHH-10307
>>>>
>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>

From gunnar at hibernate.org  Wed Jan  6 12:22:50 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 6 Jan 2016 18:22:50 +0100
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CAFdSV9v4PVsCuPs=MGF4HabjparzxVf9qS5uKEv23E5r886nGg@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
	<CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>
	<CA+gWKMAJNBQVaHJMWMQwLHjpZ0FnTJJ4wFp09UvXHP_JHL12+Q@mail.gmail.com>
	<CAFdSV9v4PVsCuPs=MGF4HabjparzxVf9qS5uKEv23E5r886nGg@mail.gmail.com>
Message-ID: <CADGJaX8v=fq5K4ay7cyU8YkDikgKAtZXGUfFSKBzvO2OSUP1NA@mail.gmail.com>

I can see how users working with JDBC exclusively can be surprised by
the fact that the JTA API is still needed. I think it boils down to
these options:

1) Push back the need for JTA types to the case of actually using JTA
(e.g. by splitting up the CoreMessageLogger interface etc.)

In my experience classes (such as org.hibernate.Transaction) can be
loaded also if they contain method signatures with absent types (e.g.
registerSynchronization()), as long as these methods are not accessed
(e.g. invoked or obtained via Class#getDeclaredMethods()). Plain
imports are irrelevant (I don't think they are even present a concept
in byte code), actual access of methods/fields with missing types will
cause errors. So this could be doable, assuming that ORM itself
doesn't work with JTA types in the case of JDBC-only.

2) If that's not feasible, JTA is non-optional really, leaving us to
decide whether a) to "suggest" a JTA API version by transitively
exposing it (which the user then still could replace) or b) always
require the user to provide it.

My personal preference would be 1) (assuming it is sensibly doable),
followed by 2a) followed by 2b). Granted, 1) may be hard to test and
also I am not sure whether that behaviour I described is guaranteed by
the spec or only is exposed by specific JVMs.

--Gunnar



2016-01-06 17:59 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> There is nothing "EE AS" specific in any of those jars I mentioned.  They
> are all simply different jars of the JTA API.  Every EE spec has the same
> problem.  That is the point you are missing.
>
> TBH I forget the history as to why the JBoss's JTA jar (again, nothing
> JBoss specific there, just the JTA API) was used rather than
> javax.transaction:jta.  That predates our move to git and would require
> some digging.  Later we moved from the JBoss JTA jar to the Geronimo
> version because the JBoss one had some problem in its OSGi metadata
> (the javax.transaction:jta
> jar provides zero OSGi metadata btw).
>
>
>
> On Wed, Jan 6, 2016 at 10:44 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I thought it was just the javax dependency.
>> Supplying all those Java EE AS dependency is something else, as you
>> pointed out.
>>
>> Adding some separate modules with those dependencies is not an option
>> either: hibernate-wildfly, hibernate-geronimo, etc?
>>
>> Vlad
>>
>> On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Vlad, the issue is not "someone doesn't want it".  In fact, for the most
>>> part because of our decision to use the JTA contracts in our API "(not)
>>> wanting it" is not really an option.
>>>
>>> The issue here is the proliferation of JTA jars (maven coords).  We have
>>> the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns is when
>>> someone wants to use one of the jars other than the one we provide
>>> transitively.  Yes, the result is the same: they still need to exclude the
>>> one we provide transitively.
>>>
>>> I have argued this for ages... I think this is a fundamental missing
>>> construct in Maven dependency mappings: the ability to say "remap" all
>>> references to a particular spec jar coord to another.  Gradle luckily
>>> allows users to do that (granted somewhat verbosely), Maven simply does not.
>>>
>>>
>>> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Since the Hibernate core relies on the JTA dependency, I think we
>>>> shouldn't provide that dependency.
>>>> When someone doesn't want it he should explicitly mark that (e.g. Maven
>>>> exclude).
>>>> This way we can also address the parent issue:
>>>> https://hibernate.atlassian.net/browse/HHH-10178
>>>>
>>>> Vlad
>>>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> HHH-10307[1] is another issue we need to get some consensus on.
>>>>> Initially
>>>>> we had removed JTA as a transitive dependency, but that is not really
>>>>> valid.  We need to discuss alternatives and options.
>>>>>
>>>>> [1] https://hibernate.atlassian.net/browse/HHH-10307
>>>>>
>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Jan  6 12:34:07 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jan 2016 17:34:07 +0000
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CADGJaX8v=fq5K4ay7cyU8YkDikgKAtZXGUfFSKBzvO2OSUP1NA@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
	<CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>
	<CA+gWKMAJNBQVaHJMWMQwLHjpZ0FnTJJ4wFp09UvXHP_JHL12+Q@mail.gmail.com>
	<CAFdSV9v4PVsCuPs=MGF4HabjparzxVf9qS5uKEv23E5r886nGg@mail.gmail.com>
	<CADGJaX8v=fq5K4ay7cyU8YkDikgKAtZXGUfFSKBzvO2OSUP1NA@mail.gmail.com>
Message-ID: <CAFdSV9ugTqJ0NsMobBb3GGm=NnpSB6eYL-XQPT-WY6_YTu0T6A@mail.gmail.com>

The JTA API is a tiny jar.  I am not so concerned with "users working with
JDBC exclusively" being "surprised" that JTA is needed.  JTA's
Synchronization is a well understood pattern.

On Wed, Jan 6, 2016 at 11:22 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> I can see how users working with JDBC exclusively can be surprised by
> the fact that the JTA API is still needed. I think it boils down to
> these options:
>
> 1) Push back the need for JTA types to the case of actually using JTA
> (e.g. by splitting up the CoreMessageLogger interface etc.)
>
> In my experience classes (such as org.hibernate.Transaction) can be
> loaded also if they contain method signatures with absent types (e.g.
> registerSynchronization()), as long as these methods are not accessed
> (e.g. invoked or obtained via Class#getDeclaredMethods()). Plain
> imports are irrelevant (I don't think they are even present a concept
> in byte code), actual access of methods/fields with missing types will
> cause errors. So this could be doable, assuming that ORM itself
> doesn't work with JTA types in the case of JDBC-only.
>
> 2) If that's not feasible, JTA is non-optional really, leaving us to
> decide whether a) to "suggest" a JTA API version by transitively
> exposing it (which the user then still could replace) or b) always
> require the user to provide it.
>
> My personal preference would be 1) (assuming it is sensibly doable),
> followed by 2a) followed by 2b). Granted, 1) may be hard to test and
> also I am not sure whether that behaviour I described is guaranteed by
> the spec or only is exposed by specific JVMs.
>
> --Gunnar
>
>
>
> 2016-01-06 17:59 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > There is nothing "EE AS" specific in any of those jars I mentioned.  They
> > are all simply different jars of the JTA API.  Every EE spec has the same
> > problem.  That is the point you are missing.
> >
> > TBH I forget the history as to why the JBoss's JTA jar (again, nothing
> > JBoss specific there, just the JTA API) was used rather than
> > javax.transaction:jta.  That predates our move to git and would require
> > some digging.  Later we moved from the JBoss JTA jar to the Geronimo
> > version because the JBoss one had some problem in its OSGi metadata
> > (the javax.transaction:jta
> > jar provides zero OSGi metadata btw).
> >
> >
> >
> > On Wed, Jan 6, 2016 at 10:44 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> >
> >> I thought it was just the javax dependency.
> >> Supplying all those Java EE AS dependency is something else, as you
> >> pointed out.
> >>
> >> Adding some separate modules with those dependencies is not an option
> >> either: hibernate-wildfly, hibernate-geronimo, etc?
> >>
> >> Vlad
> >>
> >> On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> Vlad, the issue is not "someone doesn't want it".  In fact, for the
> most
> >>> part because of our decision to use the JTA contracts in our API "(not)
> >>> wanting it" is not really an option.
> >>>
> >>> The issue here is the proliferation of JTA jars (maven coords).  We
> have
> >>> the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns is
> when
> >>> someone wants to use one of the jars other than the one we provide
> >>> transitively.  Yes, the result is the same: they still need to exclude
> the
> >>> one we provide transitively.
> >>>
> >>> I have argued this for ages... I think this is a fundamental missing
> >>> construct in Maven dependency mappings: the ability to say "remap" all
> >>> references to a particular spec jar coord to another.  Gradle luckily
> >>> allows users to do that (granted somewhat verbosely), Maven simply
> does not.
> >>>
> >>>
> >>> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea <mihalcea.vlad at gmail.com
> >
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> Since the Hibernate core relies on the JTA dependency, I think we
> >>>> shouldn't provide that dependency.
> >>>> When someone doesn't want it he should explicitly mark that (e.g.
> Maven
> >>>> exclude).
> >>>> This way we can also address the parent issue:
> >>>> https://hibernate.atlassian.net/browse/HHH-10178
> >>>>
> >>>> Vlad
> >>>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org>
> >>>> wrote:
> >>>>
> >>>>> HHH-10307[1] is another issue we need to get some consensus on.
> >>>>> Initially
> >>>>> we had removed JTA as a transitive dependency, but that is not really
> >>>>> valid.  We need to discuss alternatives and options.
> >>>>>
> >>>>> [1] https://hibernate.atlassian.net/browse/HHH-10307
> >>>>>
> >>>> _______________________________________________
> >>>>> hibernate-dev mailing list
> >>>>> hibernate-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> >>>>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jan  6 12:36:10 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 06 Jan 2016 17:36:10 +0000
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CAFdSV9ugTqJ0NsMobBb3GGm=NnpSB6eYL-XQPT-WY6_YTu0T6A@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
	<CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>
	<CA+gWKMAJNBQVaHJMWMQwLHjpZ0FnTJJ4wFp09UvXHP_JHL12+Q@mail.gmail.com>
	<CAFdSV9v4PVsCuPs=MGF4HabjparzxVf9qS5uKEv23E5r886nGg@mail.gmail.com>
	<CADGJaX8v=fq5K4ay7cyU8YkDikgKAtZXGUfFSKBzvO2OSUP1NA@mail.gmail.com>
	<CAFdSV9ugTqJ0NsMobBb3GGm=NnpSB6eYL-XQPT-WY6_YTu0T6A@mail.gmail.com>
Message-ID: <CAFdSV9uj9RizkzsC7jiSqLtTs6H5K8kVa6ModAPXp3nh9tsvHA@mail.gmail.com>

I'll put it this way Gunnar, as a user would you prefer:

1) org.hibernate.Transaction#addCallback( org.hibernate.TransactionCallback
)
2) org.hibernate.Transaction#addCallback( javax.transaction.Synchronization
)

?



On Wed, Jan 6, 2016 at 11:34 AM Steve Ebersole <steve at hibernate.org> wrote:

> The JTA API is a tiny jar.  I am not so concerned with "users working with
> JDBC exclusively" being "surprised" that JTA is needed.  JTA's
> Synchronization is a well understood pattern.
>
> On Wed, Jan 6, 2016 at 11:22 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> I can see how users working with JDBC exclusively can be surprised by
>> the fact that the JTA API is still needed. I think it boils down to
>> these options:
>>
>> 1) Push back the need for JTA types to the case of actually using JTA
>> (e.g. by splitting up the CoreMessageLogger interface etc.)
>>
>> In my experience classes (such as org.hibernate.Transaction) can be
>> loaded also if they contain method signatures with absent types (e.g.
>> registerSynchronization()), as long as these methods are not accessed
>> (e.g. invoked or obtained via Class#getDeclaredMethods()). Plain
>> imports are irrelevant (I don't think they are even present a concept
>> in byte code), actual access of methods/fields with missing types will
>> cause errors. So this could be doable, assuming that ORM itself
>> doesn't work with JTA types in the case of JDBC-only.
>>
>> 2) If that's not feasible, JTA is non-optional really, leaving us to
>> decide whether a) to "suggest" a JTA API version by transitively
>> exposing it (which the user then still could replace) or b) always
>> require the user to provide it.
>>
>> My personal preference would be 1) (assuming it is sensibly doable),
>> followed by 2a) followed by 2b). Granted, 1) may be hard to test and
>> also I am not sure whether that behaviour I described is guaranteed by
>> the spec or only is exposed by specific JVMs.
>>
>> --Gunnar
>>
>>
>>
>> 2016-01-06 17:59 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > There is nothing "EE AS" specific in any of those jars I mentioned.
>> They
>> > are all simply different jars of the JTA API.  Every EE spec has the
>> same
>> > problem.  That is the point you are missing.
>> >
>> > TBH I forget the history as to why the JBoss's JTA jar (again, nothing
>> > JBoss specific there, just the JTA API) was used rather than
>> > javax.transaction:jta.  That predates our move to git and would require
>> > some digging.  Later we moved from the JBoss JTA jar to the Geronimo
>> > version because the JBoss one had some problem in its OSGi metadata
>> > (the javax.transaction:jta
>> > jar provides zero OSGi metadata btw).
>> >
>> >
>> >
>> > On Wed, Jan 6, 2016 at 10:44 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> > wrote:
>> >
>> >> I thought it was just the javax dependency.
>> >> Supplying all those Java EE AS dependency is something else, as you
>> >> pointed out.
>> >>
>> >> Adding some separate modules with those dependencies is not an option
>> >> either: hibernate-wildfly, hibernate-geronimo, etc?
>> >>
>> >> Vlad
>> >>
>> >> On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >>
>> >>> Vlad, the issue is not "someone doesn't want it".  In fact, for the
>> most
>> >>> part because of our decision to use the JTA contracts in our API
>> "(not)
>> >>> wanting it" is not really an option.
>> >>>
>> >>> The issue here is the proliferation of JTA jars (maven coords).  We
>> have
>> >>> the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns is
>> when
>> >>> someone wants to use one of the jars other than the one we provide
>> >>> transitively.  Yes, the result is the same: they still need to
>> exclude the
>> >>> one we provide transitively.
>> >>>
>> >>> I have argued this for ages... I think this is a fundamental missing
>> >>> construct in Maven dependency mappings: the ability to say "remap" all
>> >>> references to a particular spec jar coord to another.  Gradle luckily
>> >>> allows users to do that (granted somewhat verbosely), Maven simply
>> does not.
>> >>>
>> >>>
>> >>> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea <
>> mihalcea.vlad at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Hi,
>> >>>>
>> >>>> Since the Hibernate core relies on the JTA dependency, I think we
>> >>>> shouldn't provide that dependency.
>> >>>> When someone doesn't want it he should explicitly mark that (e.g.
>> Maven
>> >>>> exclude).
>> >>>> This way we can also address the parent issue:
>> >>>> https://hibernate.atlassian.net/browse/HHH-10178
>> >>>>
>> >>>> Vlad
>> >>>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org>
>> >>>> wrote:
>> >>>>
>> >>>>> HHH-10307[1] is another issue we need to get some consensus on.
>> >>>>> Initially
>> >>>>> we had removed JTA as a transitive dependency, but that is not
>> really
>> >>>>> valid.  We need to discuss alternatives and options.
>> >>>>>
>> >>>>> [1] https://hibernate.atlassian.net/browse/HHH-10307
>> >>>>>
>> >>>> _______________________________________________
>> >>>>> 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 Jan  6 12:48:15 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 6 Jan 2016 18:48:15 +0100
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CAFdSV9uj9RizkzsC7jiSqLtTs6H5K8kVa6ModAPXp3nh9tsvHA@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
	<CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>
	<CA+gWKMAJNBQVaHJMWMQwLHjpZ0FnTJJ4wFp09UvXHP_JHL12+Q@mail.gmail.com>
	<CAFdSV9v4PVsCuPs=MGF4HabjparzxVf9qS5uKEv23E5r886nGg@mail.gmail.com>
	<CADGJaX8v=fq5K4ay7cyU8YkDikgKAtZXGUfFSKBzvO2OSUP1NA@mail.gmail.com>
	<CAFdSV9ugTqJ0NsMobBb3GGm=NnpSB6eYL-XQPT-WY6_YTu0T6A@mail.gmail.com>
	<CAFdSV9uj9RizkzsC7jiSqLtTs6H5K8kVa6ModAPXp3nh9tsvHA@mail.gmail.com>
Message-ID: <CADGJaX_Z9bNYfTi-KWLtybbM1K=1tGOWfAikFjMRW-wcHO3a0A@mail.gmail.com>

I'd prefer 1). The less dependencies I need, the better.

2016-01-06 18:36 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> I'll put it this way Gunnar, as a user would you prefer:
>
> 1) org.hibernate.Transaction#addCallback( org.hibernate.TransactionCallback
> )
> 2) org.hibernate.Transaction#addCallback( javax.transaction.Synchronization
> )
>
> ?
>
>
>
> On Wed, Jan 6, 2016 at 11:34 AM Steve Ebersole <steve at hibernate.org> wrote:
>>
>> The JTA API is a tiny jar.  I am not so concerned with "users working with
>> JDBC exclusively" being "surprised" that JTA is needed.  JTA's
>> Synchronization is a well understood pattern.
>>
>> On Wed, Jan 6, 2016 at 11:22 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>>
>>> I can see how users working with JDBC exclusively can be surprised by
>>> the fact that the JTA API is still needed. I think it boils down to
>>> these options:
>>>
>>> 1) Push back the need for JTA types to the case of actually using JTA
>>> (e.g. by splitting up the CoreMessageLogger interface etc.)
>>>
>>> In my experience classes (such as org.hibernate.Transaction) can be
>>> loaded also if they contain method signatures with absent types (e.g.
>>> registerSynchronization()), as long as these methods are not accessed
>>> (e.g. invoked or obtained via Class#getDeclaredMethods()). Plain
>>> imports are irrelevant (I don't think they are even present a concept
>>> in byte code), actual access of methods/fields with missing types will
>>> cause errors. So this could be doable, assuming that ORM itself
>>> doesn't work with JTA types in the case of JDBC-only.
>>>
>>> 2) If that's not feasible, JTA is non-optional really, leaving us to
>>> decide whether a) to "suggest" a JTA API version by transitively
>>> exposing it (which the user then still could replace) or b) always
>>> require the user to provide it.
>>>
>>> My personal preference would be 1) (assuming it is sensibly doable),
>>> followed by 2a) followed by 2b). Granted, 1) may be hard to test and
>>> also I am not sure whether that behaviour I described is guaranteed by
>>> the spec or only is exposed by specific JVMs.
>>>
>>> --Gunnar
>>>
>>>
>>>
>>> 2016-01-06 17:59 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>> > There is nothing "EE AS" specific in any of those jars I mentioned.
>>> > They
>>> > are all simply different jars of the JTA API.  Every EE spec has the
>>> > same
>>> > problem.  That is the point you are missing.
>>> >
>>> > TBH I forget the history as to why the JBoss's JTA jar (again, nothing
>>> > JBoss specific there, just the JTA API) was used rather than
>>> > javax.transaction:jta.  That predates our move to git and would require
>>> > some digging.  Later we moved from the JBoss JTA jar to the Geronimo
>>> > version because the JBoss one had some problem in its OSGi metadata
>>> > (the javax.transaction:jta
>>> > jar provides zero OSGi metadata btw).
>>> >
>>> >
>>> >
>>> > On Wed, Jan 6, 2016 at 10:44 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> > wrote:
>>> >
>>> >> I thought it was just the javax dependency.
>>> >> Supplying all those Java EE AS dependency is something else, as you
>>> >> pointed out.
>>> >>
>>> >> Adding some separate modules with those dependencies is not an option
>>> >> either: hibernate-wildfly, hibernate-geronimo, etc?
>>> >>
>>> >> Vlad
>>> >>
>>> >> On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <steve at hibernate.org>
>>> >> wrote:
>>> >>
>>> >>> Vlad, the issue is not "someone doesn't want it".  In fact, for the
>>> >>> most
>>> >>> part because of our decision to use the JTA contracts in our API
>>> >>> "(not)
>>> >>> wanting it" is not really an option.
>>> >>>
>>> >>> The issue here is the proliferation of JTA jars (maven coords).  We
>>> >>> have
>>> >>> the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns is
>>> >>> when
>>> >>> someone wants to use one of the jars other than the one we provide
>>> >>> transitively.  Yes, the result is the same: they still need to
>>> >>> exclude the
>>> >>> one we provide transitively.
>>> >>>
>>> >>> I have argued this for ages... I think this is a fundamental missing
>>> >>> construct in Maven dependency mappings: the ability to say "remap"
>>> >>> all
>>> >>> references to a particular spec jar coord to another.  Gradle luckily
>>> >>> allows users to do that (granted somewhat verbosely), Maven simply
>>> >>> does not.
>>> >>>
>>> >>>
>>> >>> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea
>>> >>> <mihalcea.vlad at gmail.com>
>>> >>> wrote:
>>> >>>
>>> >>>> Hi,
>>> >>>>
>>> >>>> Since the Hibernate core relies on the JTA dependency, I think we
>>> >>>> shouldn't provide that dependency.
>>> >>>> When someone doesn't want it he should explicitly mark that (e.g.
>>> >>>> Maven
>>> >>>> exclude).
>>> >>>> This way we can also address the parent issue:
>>> >>>> https://hibernate.atlassian.net/browse/HHH-10178
>>> >>>>
>>> >>>> Vlad
>>> >>>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <steve at hibernate.org>
>>> >>>> wrote:
>>> >>>>
>>> >>>>> HHH-10307[1] is another issue we need to get some consensus on.
>>> >>>>> Initially
>>> >>>>> we had removed JTA as a transitive dependency, but that is not
>>> >>>>> really
>>> >>>>> valid.  We need to discuss alternatives and options.
>>> >>>>>
>>> >>>>> [1] https://hibernate.atlassian.net/browse/HHH-10307
>>> >>>>>
>>> >>>> _______________________________________________
>>> >>>>> 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 Jan  7 02:45:48 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 7 Jan 2016 08:45:48 +0100
Subject: [hibernate-dev] [OGM] @Column and embedded objects in OGM
In-Reply-To: <CADGJaX8XqO0S_sGjPOAugZKytmAJy9owNRAH5DzSNwg3e0WEJg@mail.gmail.com>
References: <88F33BA1-CC40-43F2-A086-952300676223@hibernate.org>
	<CADGJaX8XqO0S_sGjPOAugZKytmAJy9owNRAH5DzSNwg3e0WEJg@mail.gmail.com>
Message-ID: <20160107074548.GC25193@hibernate.org>

I've replied in OGM-893 as things came back to me. That's a proposal,
there might be even better options.

On the FAQ, I'm fine if you think that's unimportant to mention at that
level. But the doc at least would need to be fixed until we have OGM-893
in.

On Wed 2016-01-06 11:40, Gunnar Morling wrote:
> Hi,
> 
> Yes, I noticed this some time ago, too. It's tracked by
> https://hibernate.atlassian.net/browse/OGM-893.
> 
> As it stands, I don't think it's fixable using the ORM
> ImplicitNamingStrategy/PhysicalNamingStrategy contracts: The former
> doesn't apply for explicitly given names, the latter lacks the
> required context to establish the full dot name.
> 
> So maybe we could enhance PhysicalNamingStrategy - or have a new
> contract specifically for preparing explicit names - to expose the
> full attribute path, allowing implementations to prefix the column
> with the parent name(s) as we'd need it for the document stores.
> 
> Btw. a - cumbersome - workaround is to use @AttributeOverride which
> allows to create the right mapping. We can add something to the FAQ if
> you like, but then I think it's a bug really which we need to fix, and
> we don't have an FAQ entry for each bug.
> 
> --Gunnar
> 
> 
> 
> 2016-01-06 9:40 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > Hey guys,
> >
> > Marco found something that really surprised him. I am not sure if that?s a widespread behavior or just specific to CouchDB?s backend.
> >
> > @Entity
> > class A {
> >    ?
> >    B embedded;
> > }
> >
> > @Embeddable
> > class B {
> >     String c;
> >     @Column(name=?real_d?) d;
> > }
> >
> > The document structure is roughly
> >
> > {
> > ?
> >     ?embedded?: { ?c?: ?foo? },
> >     ?real_d?: ?bar"
> > }
> >
> > I can see this is happening because the column name has not dot in it. But I would expect as a noob to see the natural behavior and have real_d embedded in the nested document embedded.
> >
> > Looks like MongoDB does the same and I suspect Noe4J too.
> >
> > 1. Can any one think of a trick (like the naming strategy or something like that) to compensate and do it ?right?.
> > 2. If not, I could not find anything in the documentation nor the FAQ and we should make that very obvious. I finally found some info in the embedded section of MongoDB but Neo4J and CouchDb are silent on the matter. How could we make that clearer in the mean time? FAQ?
> >
> > Emmanuel
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev

From mihalcea.vlad at gmail.com  Thu Jan  7 03:36:36 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 7 Jan 2016 10:36:36 +0200
Subject: [hibernate-dev] Quoting JPA specs
Message-ID: <CA+gWKMCKZVn6x-VZesGXmHcfRCUMeaFWDs+1jNH9uuvbneJ-Qw@mail.gmail.com>

Hi,

I know that any quoting from a copyrighted material needs written approval.
The JPA specs are under copyright, so instead of quoting we should just
provide the section and
make a summary in our own wording.

Vlad

From gunnar at hibernate.org  Thu Jan  7 03:59:05 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 7 Jan 2016 09:59:05 +0100
Subject: [hibernate-dev] Quoting JPA specs
In-Reply-To: <CA+gWKMCKZVn6x-VZesGXmHcfRCUMeaFWDs+1jNH9uuvbneJ-Qw@mail.gmail.com>
References: <CA+gWKMCKZVn6x-VZesGXmHcfRCUMeaFWDs+1jNH9uuvbneJ-Qw@mail.gmail.com>
Message-ID: <CADGJaX9YWHXf85MFsdtj=o69Kd_9UJ9dFiY=Nvix5+Z1hdMzYQ@mail.gmail.com>

Hey,

2016-01-07 9:36 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> Hi,
>
> I know that any quoting from a copyrighted material needs written approval.

Where do you know that from?

Quoting copyrighted material is subject to "fair use" or similar rules
in many countries (see https://en.wikipedia.org/wiki/Fair_use).
Whether it's fair use or not depends on different factors, amongst
them the length of the quoted text. I'd be more than surprised if
quoting single sentences from a spec with several hundreds pages posed
a problem.

Most texts are protected by copyright automatically (provided they
satisfy some requirements regarding originality, length etc.), so if
there was such rule, quoting would effectively be impossible, which
clearly is not the case.

> The JPA specs are under copyright, so instead of quoting we should just
> provide the section and
> make a summary in our own wording.

I don't think that's needed, in addition it'd do more harm than good.
The specific wording makes a difference, summarizing it in your own
words is already an interpretation which may or may not alter the
exact semantics.

>
> Vlad

Cheers,

--Gunnar

> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Thu Jan  7 04:36:44 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 7 Jan 2016 01:36:44 -0800
Subject: [hibernate-dev] HHH-5855 bug report and a possible fix
In-Reply-To: <CA+gWKMB4PfyiyZJVjf0TZqO7jFVXs7yrPDbav-ZCya_J=u3bjQ@mail.gmail.com>
References: <CA+gWKMDJ5Dkt_E-4CJ-hr5zHVRgOBj161TW9Zte+3vxNxpAUTA@mail.gmail.com>
	<CAFDzhiRT7zMpNNSkgVCCQ_vKLAD2O_xR2ycb+=cYhHuKB79f=Q@mail.gmail.com>
	<CAFDzhiSL9H44W=UoiWEbL5k-ZXuGOhp8kKFKpaO2ubZzW3GLAA@mail.gmail.com>
	<CA+gWKMB4PfyiyZJVjf0TZqO7jFVXs7yrPDbav-ZCya_J=u3bjQ@mail.gmail.com>
Message-ID: <CAFDzhiSFxODDOf3JupQuvFTWVfZDh13WVQWhwRYwHBBLo2HWKg@mail.gmail.com>

I've created a pull request for HHH-5855. [1]

I ran into several bugs related to delayed operations, so this is a
work-in-progess. I wanted to create a pull request of what I have so far. I
will revisit it when I return to work 1/14/16. I plan to address the other
bugs separately.

Regards,
Gail

[1] https://github.com/hibernate/hibernate-orm/pull/1212

On Wed, Dec 23, 2015 at 12:05 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi Gail,
>
> I'm glad there is a development plan on this one . I've been following
> this issue for a couple of years and seen some recent comments which
> reminded me of it.
> Someone asked me on my blog if we can get it fixed, as it's causing
> problems when people are trying to merge back detached entities.
>
> If I can help you with anything, just let me know. Now that I've been also
> digging into it, I can at least assist you and test your PR on my fork too.
>
> Vlad
>
> On Wed, Dec 23, 2015 at 9:25 PM, Gail Badner <gbadner at redhat.com> wrote:
>
>> We really don't want to initialize a List when merging. Instead, we want
>> to do the same sort of replace on the values stored in the DelayedOperation
>> objects. That way, the collection will be initialized only when necessary.
>> The DelayedOperations are executed on flush. I'll should get a pull request
>> out for this today or tomorrow.
>>
>> Vlad, If you are interested in digging into an issue that is assigned to
>> me, I'm happy to tell you my status and share what I know about it. I would
>> certainly welcome your help.
>>
>> Thanks,
>> Gail
>>
>> On Wed, Dec 23, 2015 at 10:51 AM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> Hi Vlad,
>>>
>>> I've spend quite a bit of time on this one and already have a fix. I
>>> just have some tests to add to confirm. I will look into what you suggest,
>>> but please check with me first if you see that an issue is assigned to me.
>>>
>>> Thanks,
>>> Gail
>>>
>>> On Wed, Dec 23, 2015 at 4:13 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> Hi guys
>>>>
>>>> I decided to spend some time to investigate the infamous HHH-5855 (
>>>> https://hibernate.atlassian.net/browse/HHH-5855 )  bug and this is my
>>>> report.
>>>>
>>>> One of the first thing that I noticed is that Sets are fine, while this
>>>> bug
>>>> only replicates with bidirectional Bags.
>>>>
>>>> After some hours of debugging and logging (since debugging triggers
>>>> collection initialization), I found the culprit.
>>>>
>>>> In the org.hibernate.type.TypeHelper.replace(Object[] original, Object[]
>>>> target, Type[] types, SessionImplementor session, Object owner, Map
>>>> copyCache) method, when copying the cached entity state (which contains
>>>> the
>>>> newly added child entity along with its identifier) onto the original
>>>> collection:
>>>>
>>>> copied[i] = types[i].replace( original[i], target[i], session, owner,
>>>> copyCache );
>>>>
>>>> inside the org.hibernate.type.CollectionType.replace(Object[] original,
>>>> Object[] target, Type[] types, SessionImplementor session, Object owner,
>>>> Map copyCache)  method there is this check:
>>>>
>>>> if ( !Hibernate.isInitialized( original ) ) {
>>>>    return target;
>>>> }
>>>>
>>>>
>>>> For Sets, the collection is always initialized because of this line
>>>> inside
>>>> the add() method of the org.hibernate.collection.internal.PersistentSet:
>>>>
>>>> final Boolean exists = isOperationQueueEnabled() ?
>>>> readElementExistence( value ) : null;
>>>>
>>>> Because of the the readElementExistence( value ) call the Set is always
>>>> initialized and upon triggering the flush, the newly added Entity being
>>>> already managed it will be left alone.
>>>>
>>>> For PersistentList the aforementioned check is false and the replace
>>>> never
>>>> occurs, hence the transient entity lingers in the persistence context
>>>> and
>>>> the flush will trigger another insert, so we get duplicates.
>>>>
>>>> To make the Bag behave like the Set, all we need to do is to change the
>>>> add
>>>> method like this:
>>>>
>>>> public boolean add(Object object) {
>>>>    initialize(false);
>>>>    if ( !isOperationQueueEnabled() ) {
>>>>       write();
>>>>       return bag.add( object );
>>>>    }
>>>>    else {
>>>>       queueOperation( new SimpleAdd( object ) );
>>>>       return true;
>>>>    }
>>>> }
>>>>
>>>> but then four tests will fail:
>>>>
>>>> org.hibernate.test.legacy.MasterDetailTest > testQueuedBagAdds FAILED
>>>>     java.lang.AssertionError at MasterDetailTest.java:1068
>>>>
>>>> org.hibernate.test.unionsubclass.UnionSubclassTest > testUnionSubclass
>>>> FAILED
>>>>     org.hibernate.ObjectDeletedException at UnionSubclassTest.java:364
>>>>
>>>> org.hibernate.test.version.VersionTest > testCollectionNoVersion FAILED
>>>>     java.lang.AssertionError at VersionTest.java:118
>>>>
>>>> org.hibernate.test.version.VersionTest > testCollectionVersion FAILED
>>>>     java.lang.AssertionError at VersionTest.java:79
>>>>
>>>> 3 of them fail because we expect the List not to be initialized and
>>>> the UnionSubclassTest  fails
>>>> for a doubtful reason (we attempt to delete an entity which is still
>>>> referenced).
>>>>
>>>> Basically, such a change will finally fix this issue and the Sets and
>>>> Lists
>>>> will behave consistently. Since you know the reasons behind the
>>>> difference
>>>> in how Sets and Lists are initialized, we need to discuss if this
>>>> change is
>>>> appropriate or we should address this issue differently.
>>>>
>>>> I have a branch on my fork with a test that replicates this issue and
>>>> that
>>>> the proposed change manages to fix it:
>>>>
>>>> https://github.com/vladmihalcea/hibernate-orm/tree/feature/hhh5855
>>>>
>>>> Let me know what you think and let's discuss it further.
>>>>
>>>> Vlad
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>

From mihalcea.vlad at gmail.com  Thu Jan  7 04:45:17 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 7 Jan 2016 11:45:17 +0200
Subject: [hibernate-dev] HHH-5855 bug report and a possible fix
In-Reply-To: <CAFDzhiSFxODDOf3JupQuvFTWVfZDh13WVQWhwRYwHBBLo2HWKg@mail.gmail.com>
References: <CA+gWKMDJ5Dkt_E-4CJ-hr5zHVRgOBj161TW9Zte+3vxNxpAUTA@mail.gmail.com>
	<CAFDzhiRT7zMpNNSkgVCCQ_vKLAD2O_xR2ycb+=cYhHuKB79f=Q@mail.gmail.com>
	<CAFDzhiSL9H44W=UoiWEbL5k-ZXuGOhp8kKFKpaO2ubZzW3GLAA@mail.gmail.com>
	<CA+gWKMB4PfyiyZJVjf0TZqO7jFVXs7yrPDbav-ZCya_J=u3bjQ@mail.gmail.com>
	<CAFDzhiSFxODDOf3JupQuvFTWVfZDh13WVQWhwRYwHBBLo2HWKg@mail.gmail.com>
Message-ID: <CA+gWKMA3YmPg206XLP+w5Jsaap+WfSsOsnjhP_zFoTo+C3oEMQ@mail.gmail.com>

Thanks Gail,

I'll try it on my fork after I push the migrated User Guide.

Vlad

On Thu, Jan 7, 2016 at 11:36 AM, Gail Badner <gbadner at redhat.com> wrote:

> I've created a pull request for HHH-5855. [1]
>
> I ran into several bugs related to delayed operations, so this is a
> work-in-progess. I wanted to create a pull request of what I have so far. I
> will revisit it when I return to work 1/14/16. I plan to address the other
> bugs separately.
>
> Regards,
> Gail
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1212
>
> On Wed, Dec 23, 2015 at 12:05 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi Gail,
>>
>> I'm glad there is a development plan on this one . I've been following
>> this issue for a couple of years and seen some recent comments which
>> reminded me of it.
>> Someone asked me on my blog if we can get it fixed, as it's causing
>> problems when people are trying to merge back detached entities.
>>
>> If I can help you with anything, just let me know. Now that I've been
>> also digging into it, I can at least assist you and test your PR on my fork
>> too.
>>
>> Vlad
>>
>> On Wed, Dec 23, 2015 at 9:25 PM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> We really don't want to initialize a List when merging. Instead, we want
>>> to do the same sort of replace on the values stored in the DelayedOperation
>>> objects. That way, the collection will be initialized only when necessary.
>>> The DelayedOperations are executed on flush. I'll should get a pull request
>>> out for this today or tomorrow.
>>>
>>> Vlad, If you are interested in digging into an issue that is assigned to
>>> me, I'm happy to tell you my status and share what I know about it. I would
>>> certainly welcome your help.
>>>
>>> Thanks,
>>> Gail
>>>
>>> On Wed, Dec 23, 2015 at 10:51 AM, Gail Badner <gbadner at redhat.com>
>>> wrote:
>>>
>>>> Hi Vlad,
>>>>
>>>> I've spend quite a bit of time on this one and already have a fix. I
>>>> just have some tests to add to confirm. I will look into what you suggest,
>>>> but please check with me first if you see that an issue is assigned to me.
>>>>
>>>> Thanks,
>>>> Gail
>>>>
>>>> On Wed, Dec 23, 2015 at 4:13 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com
>>>> > wrote:
>>>>
>>>>> Hi guys
>>>>>
>>>>> I decided to spend some time to investigate the infamous HHH-5855 (
>>>>> https://hibernate.atlassian.net/browse/HHH-5855 )  bug and this is my
>>>>> report.
>>>>>
>>>>> One of the first thing that I noticed is that Sets are fine, while
>>>>> this bug
>>>>> only replicates with bidirectional Bags.
>>>>>
>>>>> After some hours of debugging and logging (since debugging triggers
>>>>> collection initialization), I found the culprit.
>>>>>
>>>>> In the org.hibernate.type.TypeHelper.replace(Object[] original,
>>>>> Object[]
>>>>> target, Type[] types, SessionImplementor session, Object owner, Map
>>>>> copyCache) method, when copying the cached entity state (which
>>>>> contains the
>>>>> newly added child entity along with its identifier) onto the original
>>>>> collection:
>>>>>
>>>>> copied[i] = types[i].replace( original[i], target[i], session, owner,
>>>>> copyCache );
>>>>>
>>>>> inside the org.hibernate.type.CollectionType.replace(Object[] original,
>>>>> Object[] target, Type[] types, SessionImplementor session, Object
>>>>> owner,
>>>>> Map copyCache)  method there is this check:
>>>>>
>>>>> if ( !Hibernate.isInitialized( original ) ) {
>>>>>    return target;
>>>>> }
>>>>>
>>>>>
>>>>> For Sets, the collection is always initialized because of this line
>>>>> inside
>>>>> the add() method of the
>>>>> org.hibernate.collection.internal.PersistentSet:
>>>>>
>>>>> final Boolean exists = isOperationQueueEnabled() ?
>>>>> readElementExistence( value ) : null;
>>>>>
>>>>> Because of the the readElementExistence( value ) call the Set is always
>>>>> initialized and upon triggering the flush, the newly added Entity being
>>>>> already managed it will be left alone.
>>>>>
>>>>> For PersistentList the aforementioned check is false and the replace
>>>>> never
>>>>> occurs, hence the transient entity lingers in the persistence context
>>>>> and
>>>>> the flush will trigger another insert, so we get duplicates.
>>>>>
>>>>> To make the Bag behave like the Set, all we need to do is to change
>>>>> the add
>>>>> method like this:
>>>>>
>>>>> public boolean add(Object object) {
>>>>>    initialize(false);
>>>>>    if ( !isOperationQueueEnabled() ) {
>>>>>       write();
>>>>>       return bag.add( object );
>>>>>    }
>>>>>    else {
>>>>>       queueOperation( new SimpleAdd( object ) );
>>>>>       return true;
>>>>>    }
>>>>> }
>>>>>
>>>>> but then four tests will fail:
>>>>>
>>>>> org.hibernate.test.legacy.MasterDetailTest > testQueuedBagAdds FAILED
>>>>>     java.lang.AssertionError at MasterDetailTest.java:1068
>>>>>
>>>>> org.hibernate.test.unionsubclass.UnionSubclassTest > testUnionSubclass
>>>>> FAILED
>>>>>     org.hibernate.ObjectDeletedException at UnionSubclassTest.java:364
>>>>>
>>>>> org.hibernate.test.version.VersionTest > testCollectionNoVersion FAILED
>>>>>     java.lang.AssertionError at VersionTest.java:118
>>>>>
>>>>> org.hibernate.test.version.VersionTest > testCollectionVersion FAILED
>>>>>     java.lang.AssertionError at VersionTest.java:79
>>>>>
>>>>> 3 of them fail because we expect the List not to be initialized and
>>>>> the UnionSubclassTest  fails
>>>>> for a doubtful reason (we attempt to delete an entity which is still
>>>>> referenced).
>>>>>
>>>>> Basically, such a change will finally fix this issue and the Sets and
>>>>> Lists
>>>>> will behave consistently. Since you know the reasons behind the
>>>>> difference
>>>>> in how Sets and Lists are initialized, we need to discuss if this
>>>>> change is
>>>>> appropriate or we should address this issue differently.
>>>>>
>>>>> I have a branch on my fork with a test that replicates this issue and
>>>>> that
>>>>> the proposed change manages to fix it:
>>>>>
>>>>> https://github.com/vladmihalcea/hibernate-orm/tree/feature/hhh5855
>>>>>
>>>>> Let me know what you think and let's discuss it further.
>>>>>
>>>>> Vlad
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>>
>>
>

From hardy at hibernate.org  Thu Jan  7 05:21:05 2016
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 7 Jan 2016 11:21:05 +0100
Subject: [hibernate-dev] Quoting JPA specs
In-Reply-To: <CADGJaX9YWHXf85MFsdtj=o69Kd_9UJ9dFiY=Nvix5+Z1hdMzYQ@mail.gmail.com>
References: <CA+gWKMCKZVn6x-VZesGXmHcfRCUMeaFWDs+1jNH9uuvbneJ-Qw@mail.gmail.com>
	<CADGJaX9YWHXf85MFsdtj=o69Kd_9UJ9dFiY=Nvix5+Z1hdMzYQ@mail.gmail.com>
Message-ID: <20160107102105.GA45178@Nineveh.local>

Hi,

> > The JPA specs are under copyright, so instead of quoting we should just
> > provide the section and
> > make a summary in our own wording.
> 
> I don't think that's needed, in addition it'd do more harm than good.
> The specific wording makes a difference, summarizing it in your own
> words is already an interpretation which may or may not alter the
> exact semantics.

+1 I would have the same fear. As Gunnar is saying, the specific wording
might be important.

For what it's worth, I quote quite regularly from the Bean Validation spec
when answering Validator/Bean Validation questions. As long as you make clear
where it is coming from, I don't see a problem here.

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

From mihalcea.vlad at gmail.com  Thu Jan  7 05:42:17 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 7 Jan 2016 12:42:17 +0200
Subject: [hibernate-dev] Quoting JPA specs
In-Reply-To: <20160107102105.GA45178@Nineveh.local>
References: <CA+gWKMCKZVn6x-VZesGXmHcfRCUMeaFWDs+1jNH9uuvbneJ-Qw@mail.gmail.com>
	<CADGJaX9YWHXf85MFsdtj=o69Kd_9UJ9dFiY=Nvix5+Z1hdMzYQ@mail.gmail.com>
	<20160107102105.GA45178@Nineveh.local>
Message-ID: <CA+gWKMD5N2nvE+iY9OWtS+cHeMg1gs-Mw_8B2JQgsOY8uMGeZw@mail.gmail.com>

Hi,

For the Hibernate docs it might be fine since it's non-profit derivative
work.
But I always follow this rule on my blog or in my book because it's better
to be safe than sorry.
The "fair use" might give you a safety hook but ultimately it is the
license agreement that matters the most.

In the JPA spec case we are fine because of the following clause:

"(iii) excerpting
brief portions of the Specification in oral or written communications which
discuss the Specification provided
that such excerpts do not in the aggregate constitute a significant portion
of the Specification."

Vlad

On Thu, Jan 7, 2016 at 12:21 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> > > The JPA specs are under copyright, so instead of quoting we should just
> > > provide the section and
> > > make a summary in our own wording.
> >
> > I don't think that's needed, in addition it'd do more harm than good.
> > The specific wording makes a difference, summarizing it in your own
> > words is already an interpretation which may or may not alter the
> > exact semantics.
>
> +1 I would have the same fear. As Gunnar is saying, the specific wording
> might be important.
>
> For what it's worth, I quote quite regularly from the Bean Validation spec
> when answering Validator/Bean Validation questions. As long as you make
> clear
> where it is coming from, I don't see a problem here.
>
> --Hardy
>

From emmanuel at hibernate.org  Thu Jan  7 06:15:53 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 7 Jan 2016 12:15:53 +0100
Subject: [hibernate-dev] Quoting JPA specs
In-Reply-To: <20160107102105.GA45178@Nineveh.local>
References: <CA+gWKMCKZVn6x-VZesGXmHcfRCUMeaFWDs+1jNH9uuvbneJ-Qw@mail.gmail.com>
	<CADGJaX9YWHXf85MFsdtj=o69Kd_9UJ9dFiY=Nvix5+Z1hdMzYQ@mail.gmail.com>
	<20160107102105.GA45178@Nineveh.local>
Message-ID: <20160107111553.GD25193@hibernate.org>

On Thu 2016-01-07 11:21, Hardy Ferentschik wrote:
> Hi,
> 
> > > The JPA specs are under copyright, so instead of quoting we should just
> > > provide the section and
> > > make a summary in our own wording.
> > 
> > I don't think that's needed, in addition it'd do more harm than good.
> > The specific wording makes a difference, summarizing it in your own
> > words is already an interpretation which may or may not alter the
> > exact semantics.
> 
> +1 I would have the same fear. As Gunnar is saying, the specific wording
> might be important.
> 
> For what it's worth, I quote quite regularly from the Bean Validation spec
> when answering Validator/Bean Validation questions. As long as you make clear
> where it is coming from, I don't see a problem here.

That and Bean Validation is actually ASL :)

From emmanuel at hibernate.org  Thu Jan  7 06:18:23 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 7 Jan 2016 12:18:23 +0100
Subject: [hibernate-dev] Hibernate forum inactive users pruning
In-Reply-To: <CA+gWKMB6TyiYuVGYuT=K65f+bNYuY_8O6GwhVY_LiF3WkRZ4+A@mail.gmail.com>
References: <CA+gWKMDpbVPgNi7dvdUripoYpczX8LBwobwUMNYSgm580dOV2Q@mail.gmail.com>
	<CAFdSV9vDSavwmrJPuX_Qs7hUOfa1bPKyGio5hqrKLUGCoZ8ZSg@mail.gmail.com>
	<CA+gWKMB6TyiYuVGYuT=K65f+bNYuY_8O6GwhVY_LiF3WkRZ4+A@mail.gmail.com>
Message-ID: <20160107111823.GE25193@hibernate.org>

On Wed 2016-01-06 18:00, Vlad Mihalcea wrote:
> There must have been some checks probably when the Home page was rendered,
> but you can check it out and see the result.

Our IT plans to or already has been offloading SSL from the machine and
into a dedicated hardware. You might have been lucky time wise.

From gunnar at hibernate.org  Thu Jan  7 06:19:56 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 7 Jan 2016 12:19:56 +0100
Subject: [hibernate-dev] Quoting JPA specs
In-Reply-To: <20160107111553.GD25193@hibernate.org>
References: <CA+gWKMCKZVn6x-VZesGXmHcfRCUMeaFWDs+1jNH9uuvbneJ-Qw@mail.gmail.com>
	<CADGJaX9YWHXf85MFsdtj=o69Kd_9UJ9dFiY=Nvix5+Z1hdMzYQ@mail.gmail.com>
	<20160107102105.GA45178@Nineveh.local>
	<20160107111553.GD25193@hibernate.org>
Message-ID: <CADGJaX99yiKy1Lmd6=mcfqRBcbvCwr8P0X-8uGoFW+b-duPRmg@mail.gmail.com>

>> For what it's worth, I quote quite regularly from the Bean Validation spec
>> when answering Validator/Bean Validation questions. As long as you make clear
>> where it is coming from, I don't see a problem here.
>
> That and Bean Validation is actually ASL :)

And we are the copyright holders ;)

From steve at hibernate.org  Thu Jan  7 07:23:06 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 07 Jan 2016 12:23:06 +0000
Subject: [hibernate-dev] Quoting JPA specs
In-Reply-To: <CADGJaX99yiKy1Lmd6=mcfqRBcbvCwr8P0X-8uGoFW+b-duPRmg@mail.gmail.com>
References: <CA+gWKMCKZVn6x-VZesGXmHcfRCUMeaFWDs+1jNH9uuvbneJ-Qw@mail.gmail.com>
	<CADGJaX9YWHXf85MFsdtj=o69Kd_9UJ9dFiY=Nvix5+Z1hdMzYQ@mail.gmail.com>
	<20160107102105.GA45178@Nineveh.local>
	<20160107111553.GD25193@hibernate.org>
	<CADGJaX99yiKy1Lmd6=mcfqRBcbvCwr8P0X-8uGoFW+b-duPRmg@mail.gmail.com>
Message-ID: <CAFdSV9uuHDmGbAKjqEqtgxaPP7U4=38ZCTL7uXkERQaP1G7+ew@mail.gmail.com>

Our quoting clearly falls under "fair use"[1][2][3].  Please do not remove
those quotes

Out of curiosity you bring up the JPA spec but not our quotes from Patterns
of Enterprise Application Architecture.  I find that fascinating.  Why?

[1] http://codes.lp.findlaw.com/uscode/17/1/107
[2]
http://www.nolo.com/legal-encyclopedia/fair-use-rule-copyright-material-30100.html
[3] https://en.wikipedia.org/wiki/Fair_use



On Thu, Jan 7, 2016 at 5:20 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> >> For what it's worth, I quote quite regularly from the Bean Validation
> spec
> >> when answering Validator/Bean Validation questions. As long as you make
> clear
> >> where it is coming from, I don't see a problem here.
> >
> > That and Bean Validation is actually ASL :)
>
> And we are the copyright holders ;)
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Jan  7 07:41:05 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 7 Jan 2016 14:41:05 +0200
Subject: [hibernate-dev] Quoting JPA specs
In-Reply-To: <CAFdSV9uuHDmGbAKjqEqtgxaPP7U4=38ZCTL7uXkERQaP1G7+ew@mail.gmail.com>
References: <CA+gWKMCKZVn6x-VZesGXmHcfRCUMeaFWDs+1jNH9uuvbneJ-Qw@mail.gmail.com>
	<CADGJaX9YWHXf85MFsdtj=o69Kd_9UJ9dFiY=Nvix5+Z1hdMzYQ@mail.gmail.com>
	<20160107102105.GA45178@Nineveh.local>
	<20160107111553.GD25193@hibernate.org>
	<CADGJaX99yiKy1Lmd6=mcfqRBcbvCwr8P0X-8uGoFW+b-duPRmg@mail.gmail.com>
	<CAFdSV9uuHDmGbAKjqEqtgxaPP7U4=38ZCTL7uXkERQaP1G7+ew@mail.gmail.com>
Message-ID: <CA+gWKMB1n9RUGKFi1PrkkGV_3HS6pcoYONeSdwOvD3bmtY2UuA@mail.gmail.com>

Hi,

I left those as-is.

The only thing used from "Patterns of Enterprise Application Architecture"
is just "Unit of work" which is not a quote but a name of a pattern (
http://martinfowler.com/eaaCatalog/unitOfWork.html ), which is also
mentioned in the wiki for database transactions (
https://en.wikipedia.org/wiki/Database_transaction ).

Vlad

On Thu, Jan 7, 2016 at 2:23 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Our quoting clearly falls under "fair use"[1][2][3].  Please do not remove
> those quotes
>
> Out of curiosity you bring up the JPA spec but not our quotes from
> Patterns of Enterprise Application Architecture.  I find that fascinating.
> Why?
>
> [1] http://codes.lp.findlaw.com/uscode/17/1/107
> [2]
> http://www.nolo.com/legal-encyclopedia/fair-use-rule-copyright-material-30100.html
> [3] https://en.wikipedia.org/wiki/Fair_use
>
>
>
> On Thu, Jan 7, 2016 at 5:20 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> >> For what it's worth, I quote quite regularly from the Bean Validation
>> spec
>> >> when answering Validator/Bean Validation questions. As long as you
>> make clear
>> >> where it is coming from, I don't see a problem here.
>> >
>> > That and Bean Validation is actually ASL :)
>>
>> And we are the copyright holders ;)
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Thu Jan  7 08:15:21 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 7 Jan 2016 14:15:21 +0100
Subject: [hibernate-dev] Attribute converters and dirty checks
Message-ID: <CADGJaX_yprrBEHoTahxGbiOHKV_zBsTiZGpMFeWbG3sJCO_T5w@mail.gmail.com>

Hi,

I have an entity with an attribute whose value is converted by means
of an attribute converter. The converter operations are not symmetric,
i.e. it's not guaranteed that

    value.equals( convertToEntityAttribute( convertToDatabaseColumn( value ) ) )

is true.

Question 1: Is such converter valid, or is it a requirement that its
operations are symmetric?

If this converter is valid, then I am curious whether the following
optimization could be applied.

Currently, the dirty checking is based on equality comparison of the
attribute value. During persist a deep copy of the entity attribute
array is made, which does the forth-and-back conversion above. If the
converter isn't symmetric, this may yield a value which is different
from the one in the entity attribute.

Then at dirty check, the entity attribute is compared to that value
resulting from deep-copying, causing the property to be considered
dirty, although the value to be stored in the database actually is the
same. Subsequently, an UPDATE will be issued which contains the same
column value as the previous INSERT.

So, question 2: Would it be feasible to do the dirty check based on
the converted value?

Thanks,

--Gunnar

From mihalcea.vlad at gmail.com  Thu Jan  7 08:32:36 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 7 Jan 2016 15:32:36 +0200
Subject: [hibernate-dev] Attribute converters and dirty checks
In-Reply-To: <CADGJaX_yprrBEHoTahxGbiOHKV_zBsTiZGpMFeWbG3sJCO_T5w@mail.gmail.com>
References: <CADGJaX_yprrBEHoTahxGbiOHKV_zBsTiZGpMFeWbG3sJCO_T5w@mail.gmail.com>
Message-ID: <CA+gWKMCduGft-DtaNim8y270v9hEh5JD-e4uzohZGkU4sHaY8w@mail.gmail.com>

Hi,

I think it should be symmetric because if that property takes part in the
Object equality (equals/hashCode),
then the entity will not be equal to itself after you persisted and loaded
it again from the database.

final Event event = doInJPA(entityManager -> {
    Event _event = new Event();
    entityManager.persist(_event);
    return event;
});

doInJPA(entityManager -> {
    assertEquals(event, entityManager.find(Event.class, event.getId()));
});

This can be a problem if the Entity is part of a Set/Map too.

Vlad

On Thu, Jan 7, 2016 at 3:15 PM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> I have an entity with an attribute whose value is converted by means
> of an attribute converter. The converter operations are not symmetric,
> i.e. it's not guaranteed that
>
>     value.equals( convertToEntityAttribute( convertToDatabaseColumn( value
> ) ) )
>
> is true.
>
> Question 1: Is such converter valid, or is it a requirement that its
> operations are symmetric?
>
> If this converter is valid, then I am curious whether the following
> optimization could be applied.
>
> Currently, the dirty checking is based on equality comparison of the
> attribute value. During persist a deep copy of the entity attribute
> array is made, which does the forth-and-back conversion above. If the
> converter isn't symmetric, this may yield a value which is different
> from the one in the entity attribute.
>
> Then at dirty check, the entity attribute is compared to that value
> resulting from deep-copying, causing the property to be considered
> dirty, although the value to be stored in the database actually is the
> same. Subsequently, an UPDATE will be issued which contains the same
> column value as the previous INSERT.
>
> So, question 2: Would it be feasible to do the dirty check based on
> the converted value?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Jan  7 08:42:35 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 7 Jan 2016 15:42:35 +0200
Subject: [hibernate-dev] The stable docs are outdated
Message-ID: <CA+gWKMDk=fP8TFfn7oqLEdtWo0fs6roHuZfOmqTxTJLD4Uj1Ng@mail.gmail.com>

Hi,

I realized that the stable docs reference is pointing to 4.0.1.Final

http://docs.jboss.org/hibernate/stable/core/javadocs/

and not to 5.0.6

https://docs.jboss.org/hibernate/orm/5.0/javadocs/

Shouldn't we update the stable docs to the latest reference?
This would be desirable if you choose to instruct Google to index the
stable docs only.

Vlad

From steve at hibernate.org  Thu Jan  7 09:17:29 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 07 Jan 2016 14:17:29 +0000
Subject: [hibernate-dev] The stable docs are outdated
In-Reply-To: <CA+gWKMDk=fP8TFfn7oqLEdtWo0fs6roHuZfOmqTxTJLD4Uj1Ng@mail.gmail.com>
References: <CA+gWKMDk=fP8TFfn7oqLEdtWo0fs6roHuZfOmqTxTJLD4Uj1Ng@mail.gmail.com>
Message-ID: <CAFdSV9sgDEPi_jcccA80QNbYG41VOETihBzGmH2pMeF_nCDeNA@mail.gmail.com>

First, that would indicate that something is wrong with the ORM release
task.  The `stageDocumentationForUpload` task does create a symlink for
stable pointing to 5.0.  Clearly something is broken there.

Second, is that really the intent for "stable"?  When we first starting
doing "stable" the intent was to have stable URLs for bookmarking etc.
What you describe, and how we actually handle it (at least on the ORM
side), is more of a "current".  As we fix google indexing and revamp the
ORM docs I think this is the perfect time to reconsider all of this.  Like
if this is really meant to point to current docs, why are we calling it
"stable" instead of "current" like the rest of the sane universe? ;)

Also in terms of ontology, I'd prefer to invert the URL pattern here a
bit.  So currently we have `hibernate/stable/{project}/...`.  This causes
problems in terms of releasing because every project's release has to do a
sftp/rsync to the root Hibernate directory (`hibernate/`) on the doc server
to update the "stable" symlink.  Which is dangerous.  I'd prefer that we
invert that to instead be `hibernate/{project}/stable` (or better yet
`hibernate/{project}/current`).  We can keep the
`hibernate/stable/{project}/...`
symlinks; they'd simply point to `hibernate/{project}/current` and never
even have to be updated.

So, using ORM e.g., we'd have:

* hibernate/orm/4.3 (real directory with docs)
* hibernate/orm/5.0 (real directory with docs)
* hibernate/orm/current (symlink currently pointing to hibernate/orm/5.0)
* hibernate/stable/core (static symlink pointing to hibernate/orm/current)

On Thu, Jan 7, 2016 at 7:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I realized that the stable docs reference is pointing to 4.0.1.Final
>
> http://docs.jboss.org/hibernate/stable/core/javadocs/
>
> and not to 5.0.6
>
> https://docs.jboss.org/hibernate/orm/5.0/javadocs/
>
> Shouldn't we update the stable docs to the latest reference?
> This would be desirable if you choose to instruct Google to index the
> stable docs only.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Jan  7 09:20:49 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 7 Jan 2016 16:20:49 +0200
Subject: [hibernate-dev] The stable docs are outdated
In-Reply-To: <CAFdSV9sgDEPi_jcccA80QNbYG41VOETihBzGmH2pMeF_nCDeNA@mail.gmail.com>
References: <CA+gWKMDk=fP8TFfn7oqLEdtWo0fs6roHuZfOmqTxTJLD4Uj1Ng@mail.gmail.com>
	<CAFdSV9sgDEPi_jcccA80QNbYG41VOETihBzGmH2pMeF_nCDeNA@mail.gmail.com>
Message-ID: <CA+gWKMAjA6COD=uoHYhXwj_Lpsh2rh=xafTtEPz2cxrDq=2MJQ@mail.gmail.com>

+1

Totally agree.

Vlad

On Thu, Jan 7, 2016 at 4:17 PM, Steve Ebersole <steve at hibernate.org> wrote:

> First, that would indicate that something is wrong with the ORM release
> task.  The `stageDocumentationForUpload` task does create a symlink for
> stable pointing to 5.0.  Clearly something is broken there.
>
> Second, is that really the intent for "stable"?  When we first starting
> doing "stable" the intent was to have stable URLs for bookmarking etc.
> What you describe, and how we actually handle it (at least on the ORM
> side), is more of a "current".  As we fix google indexing and revamp the
> ORM docs I think this is the perfect time to reconsider all of this.  Like
> if this is really meant to point to current docs, why are we calling it
> "stable" instead of "current" like the rest of the sane universe? ;)
>
> Also in terms of ontology, I'd prefer to invert the URL pattern here a
> bit.  So currently we have `hibernate/stable/{project}/...`.  This causes
> problems in terms of releasing because every project's release has to do a
> sftp/rsync to the root Hibernate directory (`hibernate/`) on the doc server
> to update the "stable" symlink.  Which is dangerous.  I'd prefer that we
> invert that to instead be `hibernate/{project}/stable` (or better yet
> `hibernate/{project}/current`).  We can keep the `hibernate/stable/{project}/...`
> symlinks; they'd simply point to `hibernate/{project}/current` and never
> even have to be updated.
>
> So, using ORM e.g., we'd have:
>
> * hibernate/orm/4.3 (real directory with docs)
> * hibernate/orm/5.0 (real directory with docs)
> * hibernate/orm/current (symlink currently pointing to hibernate/orm/5.0)
> * hibernate/stable/core (static symlink pointing to hibernate/orm/current)
>
> On Thu, Jan 7, 2016 at 7:42 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I realized that the stable docs reference is pointing to 4.0.1.Final
>>
>> http://docs.jboss.org/hibernate/stable/core/javadocs/
>>
>> and not to 5.0.6
>>
>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/
>>
>> Shouldn't we update the stable docs to the latest reference?
>> This would be desirable if you choose to instruct Google to index the
>> stable docs only.
>>
>> Vlad
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Thu Jan  7 09:25:08 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 07 Jan 2016 14:25:08 +0000
Subject: [hibernate-dev] Attribute converters and dirty checks
In-Reply-To: <CADGJaX_yprrBEHoTahxGbiOHKV_zBsTiZGpMFeWbG3sJCO_T5w@mail.gmail.com>
References: <CADGJaX_yprrBEHoTahxGbiOHKV_zBsTiZGpMFeWbG3sJCO_T5w@mail.gmail.com>
Message-ID: <CAFdSV9sGV3-EsZaiYts+3siYJc22HgJObYZ0ScYpq0hAgk6qTg@mail.gmail.com>

Well first you ask for this as an "optimization", but this is not an
optimization... it is a change in expectation.  In fact it is probably less
optimized (performant) to do what you ask.  I'd personally hate to add
performance overhead to everybody for edge cases.

We've recently done some work and had some discussion on a similar
converter concern regarding state mutability.  There, in fact, we did have
to add the performance overhead systemtically because we simply don't know
(usually) whether the value is mutable.  Much of that discussion applies
here as well.


On Thu, Jan 7, 2016 at 7:16 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> I have an entity with an attribute whose value is converted by means
> of an attribute converter. The converter operations are not symmetric,
> i.e. it's not guaranteed that
>
>     value.equals( convertToEntityAttribute( convertToDatabaseColumn( value
> ) ) )
>
> is true.
>
> Question 1: Is such converter valid, or is it a requirement that its
> operations are symmetric?
>
> If this converter is valid, then I am curious whether the following
> optimization could be applied.
>
> Currently, the dirty checking is based on equality comparison of the
> attribute value. During persist a deep copy of the entity attribute
> array is made, which does the forth-and-back conversion above. If the
> converter isn't symmetric, this may yield a value which is different
> from the one in the entity attribute.
>
> Then at dirty check, the entity attribute is compared to that value
> resulting from deep-copying, causing the property to be considered
> dirty, although the value to be stored in the database actually is the
> same. Subsequently, an UPDATE will be issued which contains the same
> column value as the previous INSERT.
>
> So, question 2: Would it be feasible to do the dirty check based on
> the converted value?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Jan  7 09:32:19 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 07 Jan 2016 14:32:19 +0000
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CADGJaX_Z9bNYfTi-KWLtybbM1K=1tGOWfAikFjMRW-wcHO3a0A@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
	<CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>
	<CA+gWKMAJNBQVaHJMWMQwLHjpZ0FnTJJ4wFp09UvXHP_JHL12+Q@mail.gmail.com>
	<CAFdSV9v4PVsCuPs=MGF4HabjparzxVf9qS5uKEv23E5r886nGg@mail.gmail.com>
	<CADGJaX8v=fq5K4ay7cyU8YkDikgKAtZXGUfFSKBzvO2OSUP1NA@mail.gmail.com>
	<CAFdSV9ugTqJ0NsMobBb3GGm=NnpSB6eYL-XQPT-WY6_YTu0T6A@mail.gmail.com>
	<CAFdSV9uj9RizkzsC7jiSqLtTs6H5K8kVa6ModAPXp3nh9tsvHA@mail.gmail.com>
	<CADGJaX_Z9bNYfTi-KWLtybbM1K=1tGOWfAikFjMRW-wcHO3a0A@mail.gmail.com>
Message-ID: <CAFdSV9u7EV--RM3tQQuQqGr7SuR9YkWpKyYeaBpm9CzDUVJVhg@mail.gmail.com>

Haha,  we'll agree to disagree on that I guess :)

On Wed, Jan 6, 2016 at 11:48 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> I'd prefer 1). The less dependencies I need, the better.
>
> 2016-01-06 18:36 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > I'll put it this way Gunnar, as a user would you prefer:
> >
> > 1) org.hibernate.Transaction#addCallback(
> org.hibernate.TransactionCallback
> > )
> > 2) org.hibernate.Transaction#addCallback(
> javax.transaction.Synchronization
> > )
> >
> > ?
> >
> >
> >
> > On Wed, Jan 6, 2016 at 11:34 AM Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> The JTA API is a tiny jar.  I am not so concerned with "users working
> with
> >> JDBC exclusively" being "surprised" that JTA is needed.  JTA's
> >> Synchronization is a well understood pattern.
> >>
> >> On Wed, Jan 6, 2016 at 11:22 AM Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >>>
> >>> I can see how users working with JDBC exclusively can be surprised by
> >>> the fact that the JTA API is still needed. I think it boils down to
> >>> these options:
> >>>
> >>> 1) Push back the need for JTA types to the case of actually using JTA
> >>> (e.g. by splitting up the CoreMessageLogger interface etc.)
> >>>
> >>> In my experience classes (such as org.hibernate.Transaction) can be
> >>> loaded also if they contain method signatures with absent types (e.g.
> >>> registerSynchronization()), as long as these methods are not accessed
> >>> (e.g. invoked or obtained via Class#getDeclaredMethods()). Plain
> >>> imports are irrelevant (I don't think they are even present a concept
> >>> in byte code), actual access of methods/fields with missing types will
> >>> cause errors. So this could be doable, assuming that ORM itself
> >>> doesn't work with JTA types in the case of JDBC-only.
> >>>
> >>> 2) If that's not feasible, JTA is non-optional really, leaving us to
> >>> decide whether a) to "suggest" a JTA API version by transitively
> >>> exposing it (which the user then still could replace) or b) always
> >>> require the user to provide it.
> >>>
> >>> My personal preference would be 1) (assuming it is sensibly doable),
> >>> followed by 2a) followed by 2b). Granted, 1) may be hard to test and
> >>> also I am not sure whether that behaviour I described is guaranteed by
> >>> the spec or only is exposed by specific JVMs.
> >>>
> >>> --Gunnar
> >>>
> >>>
> >>>
> >>> 2016-01-06 17:59 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >>> > There is nothing "EE AS" specific in any of those jars I mentioned.
> >>> > They
> >>> > are all simply different jars of the JTA API.  Every EE spec has the
> >>> > same
> >>> > problem.  That is the point you are missing.
> >>> >
> >>> > TBH I forget the history as to why the JBoss's JTA jar (again,
> nothing
> >>> > JBoss specific there, just the JTA API) was used rather than
> >>> > javax.transaction:jta.  That predates our move to git and would
> require
> >>> > some digging.  Later we moved from the JBoss JTA jar to the Geronimo
> >>> > version because the JBoss one had some problem in its OSGi metadata
> >>> > (the javax.transaction:jta
> >>> > jar provides zero OSGi metadata btw).
> >>> >
> >>> >
> >>> >
> >>> > On Wed, Jan 6, 2016 at 10:44 AM Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >>> > wrote:
> >>> >
> >>> >> I thought it was just the javax dependency.
> >>> >> Supplying all those Java EE AS dependency is something else, as you
> >>> >> pointed out.
> >>> >>
> >>> >> Adding some separate modules with those dependencies is not an
> option
> >>> >> either: hibernate-wildfly, hibernate-geronimo, etc?
> >>> >>
> >>> >> Vlad
> >>> >>
> >>> >> On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <steve at hibernate.org
> >
> >>> >> wrote:
> >>> >>
> >>> >>> Vlad, the issue is not "someone doesn't want it".  In fact, for the
> >>> >>> most
> >>> >>> part because of our decision to use the JTA contracts in our API
> >>> >>> "(not)
> >>> >>> wanting it" is not really an option.
> >>> >>>
> >>> >>> The issue here is the proliferation of JTA jars (maven coords).  We
> >>> >>> have
> >>> >>> the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns is
> >>> >>> when
> >>> >>> someone wants to use one of the jars other than the one we provide
> >>> >>> transitively.  Yes, the result is the same: they still need to
> >>> >>> exclude the
> >>> >>> one we provide transitively.
> >>> >>>
> >>> >>> I have argued this for ages... I think this is a fundamental
> missing
> >>> >>> construct in Maven dependency mappings: the ability to say "remap"
> >>> >>> all
> >>> >>> references to a particular spec jar coord to another.  Gradle
> luckily
> >>> >>> allows users to do that (granted somewhat verbosely), Maven simply
> >>> >>> does not.
> >>> >>>
> >>> >>>
> >>> >>> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea
> >>> >>> <mihalcea.vlad at gmail.com>
> >>> >>> wrote:
> >>> >>>
> >>> >>>> Hi,
> >>> >>>>
> >>> >>>> Since the Hibernate core relies on the JTA dependency, I think we
> >>> >>>> shouldn't provide that dependency.
> >>> >>>> When someone doesn't want it he should explicitly mark that (e.g.
> >>> >>>> Maven
> >>> >>>> exclude).
> >>> >>>> This way we can also address the parent issue:
> >>> >>>> https://hibernate.atlassian.net/browse/HHH-10178
> >>> >>>>
> >>> >>>> Vlad
> >>> >>>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <
> steve at hibernate.org>
> >>> >>>> wrote:
> >>> >>>>
> >>> >>>>> HHH-10307[1] is another issue we need to get some consensus on.
> >>> >>>>> Initially
> >>> >>>>> we had removed JTA as a transitive dependency, but that is not
> >>> >>>>> really
> >>> >>>>> valid.  We need to discuss alternatives and options.
> >>> >>>>>
> >>> >>>>> [1] https://hibernate.atlassian.net/browse/HHH-10307
> >>> >>>>>
> >>> >>>> _______________________________________________
> >>> >>>>> 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 Jan  7 09:34:13 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 07 Jan 2016 14:34:13 +0000
Subject: [hibernate-dev] HHH-10307 - JTA dependency
In-Reply-To: <CAFdSV9u7EV--RM3tQQuQqGr7SuR9YkWpKyYeaBpm9CzDUVJVhg@mail.gmail.com>
References: <CAFdSV9uNBeLNu90rXUmaYs+u1x8xM7jvMzNkv52CduanMdWDnw@mail.gmail.com>
	<CA+gWKMDGMVBAX0V=BeYeUw3BRG=GSHgvqcivE6fY6_bfO5i4dQ@mail.gmail.com>
	<CAFdSV9tSPhrXOQAGzPbhB9oUHGjOfC3S7XU4y1A9nZYX134EXw@mail.gmail.com>
	<CA+gWKMAJNBQVaHJMWMQwLHjpZ0FnTJJ4wFp09UvXHP_JHL12+Q@mail.gmail.com>
	<CAFdSV9v4PVsCuPs=MGF4HabjparzxVf9qS5uKEv23E5r886nGg@mail.gmail.com>
	<CADGJaX8v=fq5K4ay7cyU8YkDikgKAtZXGUfFSKBzvO2OSUP1NA@mail.gmail.com>
	<CAFdSV9ugTqJ0NsMobBb3GGm=NnpSB6eYL-XQPT-WY6_YTu0T6A@mail.gmail.com>
	<CAFdSV9uj9RizkzsC7jiSqLtTs6H5K8kVa6ModAPXp3nh9tsvHA@mail.gmail.com>
	<CADGJaX_Z9bNYfTi-KWLtybbM1K=1tGOWfAikFjMRW-wcHO3a0A@mail.gmail.com>
	<CAFdSV9u7EV--RM3tQQuQqGr7SuR9YkWpKyYeaBpm9CzDUVJVhg@mail.gmail.com>
Message-ID: <CAFdSV9u_88ToFnQSbrpxLJ05poF2XbBvY37HBP-74NMsCuPkSQ@mail.gmail.com>

Scott Marlow... do you have any idea why we'd not just use
javax.transaction:jta ?

Brett Meyer... ^^ maybe something OSGi-related (because of manifests)?

On Thu, Jan 7, 2016 at 8:32 AM Steve Ebersole <steve at hibernate.org> wrote:

> Haha,  we'll agree to disagree on that I guess :)
>
> On Wed, Jan 6, 2016 at 11:48 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> I'd prefer 1). The less dependencies I need, the better.
>>
>> 2016-01-06 18:36 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > I'll put it this way Gunnar, as a user would you prefer:
>> >
>> > 1) org.hibernate.Transaction#addCallback(
>> org.hibernate.TransactionCallback
>> > )
>> > 2) org.hibernate.Transaction#addCallback(
>> javax.transaction.Synchronization
>> > )
>> >
>> > ?
>> >
>> >
>> >
>> > On Wed, Jan 6, 2016 at 11:34 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >>
>> >> The JTA API is a tiny jar.  I am not so concerned with "users working
>> with
>> >> JDBC exclusively" being "surprised" that JTA is needed.  JTA's
>> >> Synchronization is a well understood pattern.
>> >>
>> >> On Wed, Jan 6, 2016 at 11:22 AM Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >>>
>> >>> I can see how users working with JDBC exclusively can be surprised by
>> >>> the fact that the JTA API is still needed. I think it boils down to
>> >>> these options:
>> >>>
>> >>> 1) Push back the need for JTA types to the case of actually using JTA
>> >>> (e.g. by splitting up the CoreMessageLogger interface etc.)
>> >>>
>> >>> In my experience classes (such as org.hibernate.Transaction) can be
>> >>> loaded also if they contain method signatures with absent types (e.g.
>> >>> registerSynchronization()), as long as these methods are not accessed
>> >>> (e.g. invoked or obtained via Class#getDeclaredMethods()). Plain
>> >>> imports are irrelevant (I don't think they are even present a concept
>> >>> in byte code), actual access of methods/fields with missing types will
>> >>> cause errors. So this could be doable, assuming that ORM itself
>> >>> doesn't work with JTA types in the case of JDBC-only.
>> >>>
>> >>> 2) If that's not feasible, JTA is non-optional really, leaving us to
>> >>> decide whether a) to "suggest" a JTA API version by transitively
>> >>> exposing it (which the user then still could replace) or b) always
>> >>> require the user to provide it.
>> >>>
>> >>> My personal preference would be 1) (assuming it is sensibly doable),
>> >>> followed by 2a) followed by 2b). Granted, 1) may be hard to test and
>> >>> also I am not sure whether that behaviour I described is guaranteed by
>> >>> the spec or only is exposed by specific JVMs.
>> >>>
>> >>> --Gunnar
>> >>>
>> >>>
>> >>>
>> >>> 2016-01-06 17:59 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >>> > There is nothing "EE AS" specific in any of those jars I mentioned.
>> >>> > They
>> >>> > are all simply different jars of the JTA API.  Every EE spec has the
>> >>> > same
>> >>> > problem.  That is the point you are missing.
>> >>> >
>> >>> > TBH I forget the history as to why the JBoss's JTA jar (again,
>> nothing
>> >>> > JBoss specific there, just the JTA API) was used rather than
>> >>> > javax.transaction:jta.  That predates our move to git and would
>> require
>> >>> > some digging.  Later we moved from the JBoss JTA jar to the Geronimo
>> >>> > version because the JBoss one had some problem in its OSGi metadata
>> >>> > (the javax.transaction:jta
>> >>> > jar provides zero OSGi metadata btw).
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Wed, Jan 6, 2016 at 10:44 AM Vlad Mihalcea <
>> mihalcea.vlad at gmail.com>
>> >>> > wrote:
>> >>> >
>> >>> >> I thought it was just the javax dependency.
>> >>> >> Supplying all those Java EE AS dependency is something else, as you
>> >>> >> pointed out.
>> >>> >>
>> >>> >> Adding some separate modules with those dependencies is not an
>> option
>> >>> >> either: hibernate-wildfly, hibernate-geronimo, etc?
>> >>> >>
>> >>> >> Vlad
>> >>> >>
>> >>> >> On Wed, Jan 6, 2016 at 6:36 PM, Steve Ebersole <
>> steve at hibernate.org>
>> >>> >> wrote:
>> >>> >>
>> >>> >>> Vlad, the issue is not "someone doesn't want it".  In fact, for
>> the
>> >>> >>> most
>> >>> >>> part because of our decision to use the JTA contracts in our API
>> >>> >>> "(not)
>> >>> >>> wanting it" is not really an option.
>> >>> >>>
>> >>> >>> The issue here is the proliferation of JTA jars (maven coords).
>> We
>> >>> >>> have
>> >>> >>> the Geronimo jars, the JBoss/WildFly jars, etc.  So the concerns
>> is
>> >>> >>> when
>> >>> >>> someone wants to use one of the jars other than the one we provide
>> >>> >>> transitively.  Yes, the result is the same: they still need to
>> >>> >>> exclude the
>> >>> >>> one we provide transitively.
>> >>> >>>
>> >>> >>> I have argued this for ages... I think this is a fundamental
>> missing
>> >>> >>> construct in Maven dependency mappings: the ability to say "remap"
>> >>> >>> all
>> >>> >>> references to a particular spec jar coord to another.  Gradle
>> luckily
>> >>> >>> allows users to do that (granted somewhat verbosely), Maven simply
>> >>> >>> does not.
>> >>> >>>
>> >>> >>>
>> >>> >>> On Wed, Jan 6, 2016 at 10:30 AM Vlad Mihalcea
>> >>> >>> <mihalcea.vlad at gmail.com>
>> >>> >>> wrote:
>> >>> >>>
>> >>> >>>> Hi,
>> >>> >>>>
>> >>> >>>> Since the Hibernate core relies on the JTA dependency, I think we
>> >>> >>>> shouldn't provide that dependency.
>> >>> >>>> When someone doesn't want it he should explicitly mark that (e.g.
>> >>> >>>> Maven
>> >>> >>>> exclude).
>> >>> >>>> This way we can also address the parent issue:
>> >>> >>>> https://hibernate.atlassian.net/browse/HHH-10178
>> >>> >>>>
>> >>> >>>> Vlad
>> >>> >>>> On Wed, Jan 6, 2016 at 5:12 PM, Steve Ebersole <
>> steve at hibernate.org>
>> >>> >>>> wrote:
>> >>> >>>>
>> >>> >>>>> HHH-10307[1] is another issue we need to get some consensus on.
>> >>> >>>>> Initially
>> >>> >>>>> we had removed JTA as a transitive dependency, but that is not
>> >>> >>>>> really
>> >>> >>>>> valid.  We need to discuss alternatives and options.
>> >>> >>>>>
>> >>> >>>>> [1] https://hibernate.atlassian.net/browse/HHH-10307
>> >>> >>>>>
>> >>> >>>> _______________________________________________
>> >>> >>>>> hibernate-dev mailing list
>> >>> >>>>> hibernate-dev at lists.jboss.org
>> >>> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> >>>>>
>> >>> >>>>
>> >>> >>
>> >>> > _______________________________________________
>> >>> > hibernate-dev mailing list
>> >>> > hibernate-dev at lists.jboss.org
>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From gunnar at hibernate.org  Thu Jan  7 10:22:22 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 7 Jan 2016 16:22:22 +0100
Subject: [hibernate-dev] Attribute converters and dirty checks
In-Reply-To: <CAFdSV9sGV3-EsZaiYts+3siYJc22HgJObYZ0ScYpq0hAgk6qTg@mail.gmail.com>
References: <CADGJaX_yprrBEHoTahxGbiOHKV_zBsTiZGpMFeWbG3sJCO_T5w@mail.gmail.com>
	<CAFdSV9sGV3-EsZaiYts+3siYJc22HgJObYZ0ScYpq0hAgk6qTg@mail.gmail.com>
Message-ID: <CADGJaX8-PizEHnhLYtGgmG-tRkgC7+otVZtEbVm=DZUf82iGFw@mail.gmail.com>

2016-01-07 15:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> Well first you ask for this as an "optimization", but this is not an
> optimization... it is a change in expectation.  In fact it is probably less
> optimized (performant) to do what you ask.  I'd personally hate to add
> performance overhead to everybody for edge cases.

Sure, I agree to that.

Where do you see the overhead being added? If there is overhead in the
common case (I suppose from the fact that the current order allows to
abort before doing type conversion?) it's not worth doing.

>
> We've recently done some work and had some discussion on a similar converter
> concern regarding state mutability.  There, in fact, we did have to add the
> performance overhead systemtically because we simply don't know (usually)
> whether the value is mutable.  Much of that discussion applies here as well.
>
>
> On Thu, Jan 7, 2016 at 7:16 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi,
>>
>> I have an entity with an attribute whose value is converted by means
>> of an attribute converter. The converter operations are not symmetric,
>> i.e. it's not guaranteed that
>>
>>     value.equals( convertToEntityAttribute( convertToDatabaseColumn( value
>> ) ) )
>>
>> is true.
>>
>> Question 1: Is such converter valid, or is it a requirement that its
>> operations are symmetric?
>>
>> If this converter is valid, then I am curious whether the following
>> optimization could be applied.
>>
>> Currently, the dirty checking is based on equality comparison of the
>> attribute value. During persist a deep copy of the entity attribute
>> array is made, which does the forth-and-back conversion above. If the
>> converter isn't symmetric, this may yield a value which is different
>> from the one in the entity attribute.
>>
>> Then at dirty check, the entity attribute is compared to that value
>> resulting from deep-copying, causing the property to be considered
>> dirty, although the value to be stored in the database actually is the
>> same. Subsequently, an UPDATE will be issued which contains the same
>> column value as the previous INSERT.
>>
>> So, question 2: Would it be feasible to do the dirty check based on
>> the converted value?
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From hardy at hibernate.org  Fri Jan  8 05:08:11 2016
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 8 Jan 2016 11:08:11 +0100
Subject: [hibernate-dev] The stable docs are outdated
In-Reply-To: <CAFdSV9sgDEPi_jcccA80QNbYG41VOETihBzGmH2pMeF_nCDeNA@mail.gmail.com>
References: <CA+gWKMDk=fP8TFfn7oqLEdtWo0fs6roHuZfOmqTxTJLD4Uj1Ng@mail.gmail.com>
	<CAFdSV9sgDEPi_jcccA80QNbYG41VOETihBzGmH2pMeF_nCDeNA@mail.gmail.com>
Message-ID: <20160108100811.GA54034@Nineveh.local>

Hi,

On Thu, Jan 07, 2016 at 02:17:29PM +0000, Steve Ebersole wrote:

> Second, is that really the intent for "stable"?  When we first starting
> doing "stable" the intent was to have stable URLs for bookmarking etc.
> What you describe, and how we actually handle it (at least on the ORM
> side), is more of a "current"

Right, I think for Validator and Search "stable" was always equivalent to
"current". The latest production release.

> As we fix google indexing and revamp the
> ORM docs I think this is the perfect time to reconsider all of this.  Like
> if this is really meant to point to current docs, why are we calling it
> "stable" instead of "current" like the rest of the sane universe? ;)

Personally I don't mind "stable". I think it is almost better than "current" 
which is admittedly used more often. That said, Openshift uses latest as well -
https://docs.openshift.org/latest/welcome/index.html ;-) 

> Also in terms of ontology, I'd prefer to invert the URL pattern here a
> bit.  So currently we have `hibernate/stable/{project}/...`.  This causes
> problems in terms of releasing because every project's release has to do a
> sftp/rsync to the root Hibernate directory (`hibernate/`) on the doc server
> to update the "stable" symlink.  Which is dangerous.  I'd prefer that we
> invert that to instead be `hibernate/{project}/stable` (or better yet
> `hibernate/{project}/current`).  We can keep the
> `hibernate/stable/{project}/...`
> symlinks; they'd simply point to `hibernate/{project}/current` and never
> even have to be updated.

That is true, I have been wondering many times why there was a shared "stable"
link. Having the stable link under the project itself together with the various 
available version seems more natural. If we rectify this we just need to make sure
that we put proper redirects into place.

--Hardy

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

From sanne at hibernate.org  Fri Jan  8 08:17:27 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 8 Jan 2016 13:17:27 +0000
Subject: [hibernate-dev] should immutable entities in the second level
 cache be invalidated when they are removed from the database?
In-Reply-To: <568CD347.1080108@redhat.com>
References: <568BE2AB.7000103@redhat.com>
	<CAFdSV9uCLnNbb=Z=XaZEs9RDNFeWYyrkQ+1UE0RkOf=TsUKJDg@mail.gmail.com>
	<568C0296.8000009@redhat.com> <568CD347.1080108@redhat.com>
Message-ID: <CAFm4XO3hP25Ek9vtwS=koNUzqs3EHyY9g_omtAwUDf7s8bh8kw@mail.gmail.com>

Since one can delete an immutable entity, and then create (insert) a
new one to replace it, from the point of view of the Cache the entry
is not immutable and needs to be treated with the usual safety and
consistency concerns.

As Radim suggests, optimizations like using a local cache might make
sense in many practical use cases as the application developer might
take advantage of knowing that he's not doing such a an update, but
this shouldn't be automagically enabled by default as Hibernate can't
tell if it's safe.

Sanne


On 6 January 2016 at 08:41, Radim Vansa <rvansa at redhat.com> wrote:
> On 01/05/2016 06:51 PM, Scott Marlow wrote:
>> On 01/05/2016 12:36 PM, Steve Ebersole wrote:
>>> Sorry Scott, I am not sure I understand exactly what you are asking.  I
>>> will try to answer what I think you are asking as best I can..
>>>
>>>
>>> On Tue, Jan 5, 2016 at 9:35 AM Scott Marlow <smarlow at redhat.com
>>> <mailto:smarlow at redhat.com>> wrote:
>>>
>>>      I missed adding the WildFly clustering configuration for the Hibernate
>>>      immutable-entity cache.  I opened WFLY-5923 [1] for adding the cache but
>>>      am unsure of whether org.hibernate.annotations.Immutable means that the
>>>      application handles clearing the 2lc of stale immutable entities or if
>>>      that should happen automagically when immutable entities are removed
>>>      from the database.
>>>
>>>
>>> Perhaps there is a confusion that an immutable entity can in fact be
>>> created and deleted?  Immutable simply means the state of an existing
>>> entity cannot be changed.  In SQL terms, if you will, we can have an
>>> INSERT or a DELETE but never an UPDATE.
>> Thanks for the answer, this is exactly what I needed to know.
>>
>>> If an application has asked that Hibernate cache data, the expectation
>>> is that Hibernate would handle the caching of that data not the
>>> application *so long as it knows about changes to the cached data*.  Now
>>> if by "when immutable entities are removed from the database" you are
>>> asking what should happen when cached data is changed in the database
>>> directly, that answer is always the same and the question of
>>> (im)mutablity is completely irrelevant there: if the underlying data is
>>> changed directly in the database it is up to the application to make
>>> sure that the cache is consistent with those outside changes.
>>>
>>>      In a cluster, I expect that the performance of caching
>>>      immutable-entities, would be faster if we assume they will not be
>>>      invalidated from the 2lc (e.g. let applications clear them from the
>>>      cache).
>>>
>>>
>>> I think really this comes down to the question of what "invalidated"
>>> means to the underlying cache and how a deletion of data correlates to
>>> that.  But my guess is that the invalidation still needs to handled (and
>>> propagated) to properly handle the removal case.
>> Yes, I agree (based on your explanation).
>>
>>>      Since we are using Infinispan for the 2lc in WildFly, I would like to
>>>      use an Infinispan simple-cache for immutable-entities, which does no
>>>      invalidation.  However, just because I would like to do this, doesn't
>>>      make it right. :-)  Which is why I'm asking, what the design intention
>>>      is, so I can configure the WildFly clustering configuration (for
>>>      immutable entities), to align with the intent.
>>>
>>>
>>> Right, which is what I am trying to describe I guess in my previous
>>> paragraph.  Based on my (granted, very limited) understanding of
>>> Infinispan I assume we still need the invalidation.  One possible option
>>> is to allow the application to configure whether they expect removals
>>> from an immutable dataset.
>> This would be a nice performance enhancement for clustered environments,
>> as the (no removals allowed) immutable-entities cache would not need to
>> be cluster aware.
>
> ATM in Infinispan 2LC there's no optimization for Immutable entities,
> because the necessary handling of removals does not differ much from
> updates.
> In the past, the immutable-entities configuration was added as Galder
> suggested that in 4.x implementation these can use non-transactional
> cache, but in the end the implementation had flaws causing inconsistencies.
>
> For Immutable and never removed entities, you can AFAIK safely use local
> cache. However I am not aware of any means that would mark entity as
> never removed, or relax the consistency for removals.
>
> Radim
>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri Jan  8 08:39:54 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 8 Jan 2016 13:39:54 +0000
Subject: [hibernate-dev] Not letting Jenkins auto-close PRs upon build
	failures
In-Reply-To: <B02E01A4-B6C4-43A3-80B2-D61F9701FE60@hibernate.org>
References: <CADGJaX8w2NitAT+KR7pk+iUF16uq=BF=qh5Sv8R0B7+9mvA-EQ@mail.gmail.com>
	<B02E01A4-B6C4-43A3-80B2-D61F9701FE60@hibernate.org>
Message-ID: <CAFm4XO3dFXUyewGOqSpkcebwpAeQE2rJnaaoYF3Js+748syHJg@mail.gmail.com>

Do you have an example of such a PR being closed?

For sure that was never our intention, but be aware that such options
can be set globally on the ci server as project detaults, but can be
overriden in a specific build task. So I'd check the build task which
did this as for example Search PRs seem fine.

In my experience every time we upgrade Jenkins plugins there are such
issues like changes of defaults, or sometimes the plugin configuration
formats change so we lose some details.

I didn't update plugins recently, but a service crash - AFAIR it was
the 24th of December - had me restart the server. At that point I also
installed system (security) patches, but while this might have
triggered a micro update of Jenkins itself for some security reason,
it shouldn't have affected plugins.
Another option I can think of is that someone had previously requested
the update, but didn't reboot the service so the update was only
applied during my reboot.




On 5 January 2016 at 13:02, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> +1, but I don?t know how ;)
>
>> On 05 Jan 2016, at 13:55, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi,
>>
>> Not sure whether that's a new behaviour, but it's super annoying that
>> the pull request builder automatically closes pull requests if there
>> is a build failure. Can we change this so the PR stays open, please?
>>
>> The current behaviour is highly frustrating, you need to re-open the
>> PR again after fixes, and in the worst case a PR falls through the
>> cracks because it's moved out to the "Closed" tab right away. It's
>> especially bad for contributor PRs where the failure is caused by
>> ourselves, e.g. build environment issues.
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Fri Jan  8 09:56:27 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 8 Jan 2016 15:56:27 +0100
Subject: [hibernate-dev] Not letting Jenkins auto-close PRs upon build
	failures
In-Reply-To: <CAFm4XO3dFXUyewGOqSpkcebwpAeQE2rJnaaoYF3Js+748syHJg@mail.gmail.com>
References: <CADGJaX8w2NitAT+KR7pk+iUF16uq=BF=qh5Sv8R0B7+9mvA-EQ@mail.gmail.com>
	<B02E01A4-B6C4-43A3-80B2-D61F9701FE60@hibernate.org>
	<CAFm4XO3dFXUyewGOqSpkcebwpAeQE2rJnaaoYF3Js+748syHJg@mail.gmail.com>
Message-ID: <CADGJaX8Dep1_XTaDxmEME43MTon1BCuRU07650O2vRF-d_2E0g@mail.gmail.com>

2016-01-08 14:39 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> Do you have an example of such a PR being closed?

Yes, https://github.com/hibernate/hibernate-ogm/pull/610 whose
auto-closing half a dozen times nearly drove me nuts ;)

>
> For sure that was never our intention, but be aware that such options
> can be set globally on the ci server as project detaults, but can be
> overriden in a specific build task. So I'd check the build task which
> did this as for example Search PRs seem fine.

It's the OGM PR builder, maybe you could check this one?

>
> In my experience every time we upgrade Jenkins plugins there are such
> issues like changes of defaults, or sometimes the plugin configuration
> formats change so we lose some details.
>
> I didn't update plugins recently, but a service crash - AFAIR it was
> the 24th of December - had me restart the server. At that point I also
> installed system (security) patches, but while this might have
> triggered a micro update of Jenkins itself for some security reason,
> it shouldn't have affected plugins.
> Another option I can think of is that someone had previously requested
> the update, but didn't reboot the service so the update was only
> applied during my reboot.
>
>
>
>
> On 5 January 2016 at 13:02, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> +1, but I don?t know how ;)
>>
>>> On 05 Jan 2016, at 13:55, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>
>>> Hi,
>>>
>>> Not sure whether that's a new behaviour, but it's super annoying that
>>> the pull request builder automatically closes pull requests if there
>>> is a build failure. Can we change this so the PR stays open, please?
>>>
>>> The current behaviour is highly frustrating, you need to re-open the
>>> PR again after fixes, and in the worst case a PR falls through the
>>> cracks because it's moved out to the "Closed" tab right away. It's
>>> especially bad for contributor PRs where the failure is caused by
>>> ourselves, e.g. build environment issues.
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Fri Jan  8 10:08:20 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 08 Jan 2016 15:08:20 +0000
Subject: [hibernate-dev] 5.1 tentative release date
Message-ID: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>

Just a heads up that I tentatively set Jan 27th as the release date for
5.1.  Please let me know if that does not work for anyone.  Also please
keep that date in mind if there is anything you want to get into 5.1.

From mihalcea.vlad at gmail.com  Fri Jan  8 10:08:56 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 8 Jan 2016 17:08:56 +0200
Subject: [hibernate-dev] Is the the optional=false @OneToOne lazy retrieval
	still relevant
Message-ID: <CA+gWKMDUxqMm8hfRkp9fWc_+KiaFvS_Le3uQmJuaH2dNMuNqsA@mail.gmail.com>

Hi,

I remember that for a bidirectional @OneToOne relationship, the optional =
false attribute could instruct Hibernate to always generate a Proxy
(because this association cannot be null),
so, if the fetch is LAZY, it would not generate a secondary query upon
fetching the parent-side entity.

I tested it with the latest Hibernate, and when fetching the parent entity
it always generates the secondary select for the child entity too.

Is this optimization not relevant anymore or is it an issue?

Vlad

From steve at hibernate.org  Fri Jan  8 10:45:43 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 08 Jan 2016 15:45:43 +0000
Subject: [hibernate-dev] Is the the optional=false @OneToOne lazy
 retrieval still relevant
In-Reply-To: <CA+gWKMDUxqMm8hfRkp9fWc_+KiaFvS_Le3uQmJuaH2dNMuNqsA@mail.gmail.com>
References: <CA+gWKMDUxqMm8hfRkp9fWc_+KiaFvS_Le3uQmJuaH2dNMuNqsA@mail.gmail.com>
Message-ID: <CAFdSV9ubz6NUR39XEjOfS=1dt7irEgTMR86G6rHLXMimTeXkGA@mail.gmail.com>

Depending on exactly how you are testing that, that sounds like a bug.  Are
you (inadvertently) using bytecode enhancement?


On Fri, Jan 8, 2016 at 9:09 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I remember that for a bidirectional @OneToOne relationship, the optional =
> false attribute could instruct Hibernate to always generate a Proxy
> (because this association cannot be null),
> so, if the fetch is LAZY, it would not generate a secondary query upon
> fetching the parent-side entity.
>
> I tested it with the latest Hibernate, and when fetching the parent entity
> it always generates the secondary select for the child entity too.
>
> Is this optimization not relevant anymore or is it an issue?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Jan  8 13:02:14 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 08 Jan 2016 18:02:14 +0000
Subject: [hibernate-dev] HHH-9491 - Global quoting and "column definitions"
Message-ID: <CAFdSV9vCJ=yBHWy=TgFewbDewkf9b_8R-VJXHsNkD_8Po4Keog@mail.gmail.com>

HHH-9491[1] is a report that discusses problems when requesting global
quoting (what JPA calls delimited identifiers).  My last comment[2]
discusses 2 options for handling this.  I'd like to get others thoughts.

[1] https://hibernate.atlassian.net/browse/HHH-9491
[2]
https://hibernate.atlassian.net/browse/HHH-9491?focusedCommentId=74575&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-74575

From smarlow at redhat.com  Fri Jan  8 14:35:54 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 8 Jan 2016 14:35:54 -0500
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
Message-ID: <56900F9A.2010305@redhat.com>

Should we upgrade to javassist latest in 5.1 still?

On 01/08/2016 10:08 AM, Steve Ebersole wrote:
> Just a heads up that I tentatively set Jan 27th as the release date for
> 5.1.  Please let me know if that does not work for anyone.  Also please
> keep that date in mind if there is anything you want to get into 5.1.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Jan  8 14:49:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 08 Jan 2016 19:49:47 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <56900F9A.2010305@redhat.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
Message-ID: <CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>

I don't see a Jira to upgrade Javassist as part of 5.1...


On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com> wrote:

> Should we upgrade to javassist latest in 5.1 still?
>
> On 01/08/2016 10:08 AM, Steve Ebersole wrote:
> > Just a heads up that I tentatively set Jan 27th as the release date for
> > 5.1.  Please let me know if that does not work for anyone.  Also please
> > keep that date in mind if there is anything you want to get into 5.1.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From smarlow at redhat.com  Fri Jan  8 22:00:51 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 8 Jan 2016 22:00:51 -0500
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
Message-ID: <569077E3.9070201@redhat.com>

I'll create a jira for the Javassist to be part of 5.1.

Should we also look at changing Hibernate to not require Javassist 
classes be on the deployment classpath?  This might require cloning some 
Javassist runtime classes so that we don't get CNFE on 
javassist.util.proxy.ProxyObject (and whatever else is required by 
enhanced entity classes).

[1] contains one of the CNFE's that I see with WildFly during deployment 
time (only if WildFly is hacked to not inject Javassist into the 
application classpath).  I am seeing 
org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the 
entity class with references to Javassist classes (see disassembled 
bytecode output [2]).  The generated class extends 
javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. + 
javassist.util.proxy.RuntimeSupport + javassist.util.proxy.SerializedProxy.

I'm sure that there are other Javassist classes that we probably also 
generate bytecode to depend on, in other places in Hibernate.

I have no idea exactly how to resolve this.  I'm not sure if it would 
entail cloning the above javassist runtime classes into javassist.  Or 
separating them into a different (Javassist) library, so at least the 
application doesn't include the other Javassist classes.

Sanne had some ideas that he mentioned [3].  By only exposing the needed 
classloaders to the deployment, I think he meant the above idea of 
separating Javassist into different jars.  Or something like that.

Jason Greene also liked Sanne's suggestion of not requiring applications 
to have Javassist on their classpath, as applications might also include 
their own copy of Javassist because they want to generate some bytecode 
also.

What do others think about the idea of not requiring Javassist to be on 
the Hibernate application classpath?  Again, I'm not sure if this only a 
problem on WildFly.  If it is, I'm not sure why. :)

Scott

[1] 
https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1

[2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e

[3] https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801

On 01/08/2016 02:49 PM, Steve Ebersole wrote:
> I don't see a Jira to upgrade Javassist as part of 5.1...
>
>
> On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     Should we upgrade to javassist latest in 5.1 still?
>
>     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>      > Just a heads up that I tentatively set Jan 27th as the release
>     date for
>      > 5.1.  Please let me know if that does not work for anyone.  Also
>     please
>      > keep that date in mind if there is anything you want to get into 5.1.
>      > _______________________________________________
>      > hibernate-dev mailing list
>      > hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >
>

From paranoiabla at gmail.com  Sat Jan  9 04:25:27 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Sat, 9 Jan 2016 11:25:27 +0200
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <569077E3.9070201@redhat.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
Message-ID: <CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>

Hello all,

I just saw ehcache 3.0.Alpha is already out. Any chance to have the
hibernate-ehcache module updated in 5.1?

2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:

> I'll create a jira for the Javassist to be part of 5.1.
>
> Should we also look at changing Hibernate to not require Javassist
> classes be on the deployment classpath?  This might require cloning some
> Javassist runtime classes so that we don't get CNFE on
> javassist.util.proxy.ProxyObject (and whatever else is required by
> enhanced entity classes).
>
> [1] contains one of the CNFE's that I see with WildFly during deployment
> time (only if WildFly is hacked to not inject Javassist into the
> application classpath).  I am seeing
> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
> entity class with references to Javassist classes (see disassembled
> bytecode output [2]).  The generated class extends
> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. +
> javassist.util.proxy.RuntimeSupport + javassist.util.proxy.SerializedProxy.
>
> I'm sure that there are other Javassist classes that we probably also
> generate bytecode to depend on, in other places in Hibernate.
>
> I have no idea exactly how to resolve this.  I'm not sure if it would
> entail cloning the above javassist runtime classes into javassist.  Or
> separating them into a different (Javassist) library, so at least the
> application doesn't include the other Javassist classes.
>
> Sanne had some ideas that he mentioned [3].  By only exposing the needed
> classloaders to the deployment, I think he meant the above idea of
> separating Javassist into different jars.  Or something like that.
>
> Jason Greene also liked Sanne's suggestion of not requiring applications
> to have Javassist on their classpath, as applications might also include
> their own copy of Javassist because they want to generate some bytecode
> also.
>
> What do others think about the idea of not requiring Javassist to be on
> the Hibernate application classpath?  Again, I'm not sure if this only a
> problem on WildFly.  If it is, I'm not sure why. :)
>
> Scott
>
> [1]
>
> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
>
> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>
> [3] https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>
> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
> > I don't see a Jira to upgrade Javassist as part of 5.1...
> >
> >
> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
> > <mailto:smarlow at redhat.com>> wrote:
> >
> >     Should we upgrade to javassist latest in 5.1 still?
> >
> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
> >      > Just a heads up that I tentatively set Jan 27th as the release
> >     date for
> >      > 5.1.  Please let me know if that does not work for anyone.  Also
> >     please
> >      > keep that date in mind if there is anything you want to get into
> 5.1.
> >      > _______________________________________________
> >      > hibernate-dev mailing list
> >      > hibernate-dev at lists.jboss.org <mailto:
> hibernate-dev at lists.jboss.org>
> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >      >
> >
> _______________________________________________
> 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:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From martijn.dashorst at gmail.com  Sun Jan 10 10:20:58 2016
From: martijn.dashorst at gmail.com (Martijn Dashorst)
Date: Sun, 10 Jan 2016 16:20:58 +0100
Subject: [hibernate-dev] Is the the optional=false @OneToOne lazy
 retrieval still relevant
In-Reply-To: <CA+gWKMDUxqMm8hfRkp9fWc_+KiaFvS_Le3uQmJuaH2dNMuNqsA@mail.gmail.com>
References: <CA+gWKMDUxqMm8hfRkp9fWc_+KiaFvS_Le3uQmJuaH2dNMuNqsA@mail.gmail.com>
Message-ID: <CAB63Y-cOYO1n8YFyVXP+FMj8cf8KrrLZ1m6cQHxchdujkXytqQ@mail.gmail.com>

You just ran into a long standing bug with Hibernate, reported over 5 years ago:

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

Martijn


On Fri, Jan 8, 2016 at 4:08 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> I remember that for a bidirectional @OneToOne relationship, the optional =
> false attribute could instruct Hibernate to always generate a Proxy
> (because this association cannot be null),
> so, if the fetch is LAZY, it would not generate a secondary query upon
> fetching the parent-side entity.
>
> I tested it with the latest Hibernate, and when fetching the parent entity
> it always generates the secondary select for the child entity too.
>
> Is this optimization not relevant anymore or is it an issue?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com

From mihalcea.vlad at gmail.com  Sun Jan 10 11:17:48 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sun, 10 Jan 2016 18:17:48 +0200
Subject: [hibernate-dev] Is the the optional=false @OneToOne lazy
 retrieval still relevant
In-Reply-To: <CAB63Y-cOYO1n8YFyVXP+FMj8cf8KrrLZ1m6cQHxchdujkXytqQ@mail.gmail.com>
References: <CA+gWKMDUxqMm8hfRkp9fWc_+KiaFvS_Le3uQmJuaH2dNMuNqsA@mail.gmail.com>
	<CAB63Y-cOYO1n8YFyVXP+FMj8cf8KrrLZ1m6cQHxchdujkXytqQ@mail.gmail.com>
Message-ID: <CA+gWKMAHODHo8wsKJzUWWbzVyJ4Aih-xyAtNjCf-m72c_-68JQ@mail.gmail.com>

Hi Martijn,

I've given more thought to this, and even when the optional=true is
supplied and Hibernate knows there cannot be a null FK on the child-side,
the Persistence Context still needs the child identifier.
Once an entity is managed even if it is a Proxy and not an actual entity,
Hibernate needs the entity identifier to later fetch the association lazily.

In this case the only workaround is to use bytecode instrumentation and
make the parent entity a Proxy so that the child entity is only assigned
upon first access.

The optional=true is also only a JPA hint and Hibernate uses it to validate
that the child entity is set upon persisting, so it doesn't really target
this particular use case only.

Vlad

On Sun, Jan 10, 2016 at 5:20 PM, Martijn Dashorst <
martijn.dashorst at gmail.com> wrote:

> You just ran into a long standing bug with Hibernate, reported over 5
> years ago:
>
> https://hibernate.atlassian.net/browse/HHH-3930
>
> Martijn
>
>
> On Fri, Jan 8, 2016 at 4:08 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > Hi,
> >
> > I remember that for a bidirectional @OneToOne relationship, the optional
> =
> > false attribute could instruct Hibernate to always generate a Proxy
> > (because this association cannot be null),
> > so, if the fetch is LAZY, it would not generate a secondary query upon
> > fetching the parent-side entity.
> >
> > I tested it with the latest Hibernate, and when fetching the parent
> entity
> > it always generates the secondary select for the child entity too.
> >
> > Is this optimization not relevant anymore or is it an issue?
> >
> > Vlad
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon Jan 11 08:53:53 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 11 Jan 2016 13:53:53 +0000
Subject: [hibernate-dev] Not letting Jenkins auto-close PRs upon build
	failures
In-Reply-To: <CADGJaX8Dep1_XTaDxmEME43MTon1BCuRU07650O2vRF-d_2E0g@mail.gmail.com>
References: <CADGJaX8w2NitAT+KR7pk+iUF16uq=BF=qh5Sv8R0B7+9mvA-EQ@mail.gmail.com>
	<B02E01A4-B6C4-43A3-80B2-D61F9701FE60@hibernate.org>
	<CAFm4XO3dFXUyewGOqSpkcebwpAeQE2rJnaaoYF3Js+748syHJg@mail.gmail.com>
	<CADGJaX8Dep1_XTaDxmEME43MTon1BCuRU07650O2vRF-d_2E0g@mail.gmail.com>
Message-ID: <CAFm4XO3QDM2s3q3TrdOZedLMUbZV-U7PtM_EYawGrf1_HSeT_w@mail.gmail.com>

This is finally fixed. Had to upgrade the plugin too, let's keep an eye on
it for other possible regressions.
On 8 Jan 2016 14:56, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> 2016-01-08 14:39 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> > Do you have an example of such a PR being closed?
>
> Yes, https://github.com/hibernate/hibernate-ogm/pull/610 whose
> auto-closing half a dozen times nearly drove me nuts ;)
>
> >
> > For sure that was never our intention, but be aware that such options
> > can be set globally on the ci server as project detaults, but can be
> > overriden in a specific build task. So I'd check the build task which
> > did this as for example Search PRs seem fine.
>
> It's the OGM PR builder, maybe you could check this one?
>
> >
> > In my experience every time we upgrade Jenkins plugins there are such
> > issues like changes of defaults, or sometimes the plugin configuration
> > formats change so we lose some details.
> >
> > I didn't update plugins recently, but a service crash - AFAIR it was
> > the 24th of December - had me restart the server. At that point I also
> > installed system (security) patches, but while this might have
> > triggered a micro update of Jenkins itself for some security reason,
> > it shouldn't have affected plugins.
> > Another option I can think of is that someone had previously requested
> > the update, but didn't reboot the service so the update was only
> > applied during my reboot.
> >
> >
> >
> >
> > On 5 January 2016 at 13:02, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >> +1, but I don?t know how ;)
> >>
> >>> On 05 Jan 2016, at 13:55, Gunnar Morling <gunnar at hibernate.org> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Not sure whether that's a new behaviour, but it's super annoying that
> >>> the pull request builder automatically closes pull requests if there
> >>> is a build failure. Can we change this so the PR stays open, please?
> >>>
> >>> The current behaviour is highly frustrating, you need to re-open the
> >>> PR again after fixes, and in the worst case a PR falls through the
> >>> cracks because it's moved out to the "Closed" tab right away. It's
> >>> especially bad for contributor PRs where the failure is caused by
> >>> ourselves, e.g. build environment issues.
> >>>
> >>> Thanks,
> >>>
> >>> --Gunnar
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From smarlow at redhat.com  Mon Jan 11 10:54:53 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 11 Jan 2016 10:54:53 -0500
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
Message-ID: <5693D04D.3030208@redhat.com>

Do we have any feedback from the Infinispan team, as to what version of 
Infinispan should be included in ORM 5.1?  From the WildFly perspective, 
we are currently using Infinispan 8.1.0.Final in WildFly 10 but I have 
no idea which version will be used in WildFly 11.0.

On 01/08/2016 10:08 AM, Steve Ebersole wrote:
> Just a heads up that I tentatively set Jan 27th as the release date for
> 5.1.  Please let me know if that does not work for anyone.  Also please
> keep that date in mind if there is anything you want to get into 5.1.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jan 11 11:00:40 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 11 Jan 2016 16:00:40 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>
Message-ID: <CAFdSV9sp-7uYMyZGFTOwdBkErCaqwwzFfFK-6b2xGFQ4jhWKbw@mail.gmail.com>

Petar, Alex Snaps (in CC) has been doing some work to update the version of
Ehcache used in Hibernate ORM.  Alex, any updates?  As I understood it
though Ehcache 3.x was not part of that effort, but Alex can of course say
for sure.



On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla at gmail.com> wrote:

> Hello all,
>
> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
> hibernate-ehcache module updated in 5.1?
>
> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>
>> I'll create a jira for the Javassist to be part of 5.1.
>>
>> Should we also look at changing Hibernate to not require Javassist
>> classes be on the deployment classpath?  This might require cloning some
>> Javassist runtime classes so that we don't get CNFE on
>> javassist.util.proxy.ProxyObject (and whatever else is required by
>> enhanced entity classes).
>>
>> [1] contains one of the CNFE's that I see with WildFly during deployment
>> time (only if WildFly is hacked to not inject Javassist into the
>> application classpath).  I am seeing
>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
>> entity class with references to Javassist classes (see disassembled
>> bytecode output [2]).  The generated class extends
>> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. +
>> javassist.util.proxy.RuntimeSupport +
>> javassist.util.proxy.SerializedProxy.
>>
>> I'm sure that there are other Javassist classes that we probably also
>> generate bytecode to depend on, in other places in Hibernate.
>>
>> I have no idea exactly how to resolve this.  I'm not sure if it would
>> entail cloning the above javassist runtime classes into javassist.  Or
>> separating them into a different (Javassist) library, so at least the
>> application doesn't include the other Javassist classes.
>>
>> Sanne had some ideas that he mentioned [3].  By only exposing the needed
>> classloaders to the deployment, I think he meant the above idea of
>> separating Javassist into different jars.  Or something like that.
>>
>> Jason Greene also liked Sanne's suggestion of not requiring applications
>> to have Javassist on their classpath, as applications might also include
>> their own copy of Javassist because they want to generate some bytecode
>> also.
>>
>> What do others think about the idea of not requiring Javassist to be on
>> the Hibernate application classpath?  Again, I'm not sure if this only a
>> problem on WildFly.  If it is, I'm not sure why. :)
>>
>> Scott
>>
>> [1]
>>
>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
>>
>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>
>> [3] https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>>
>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>> >
>> >
>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
>> > <mailto:smarlow at redhat.com>> wrote:
>> >
>> >     Should we upgrade to javassist latest in 5.1 still?
>> >
>> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>> >      > Just a heads up that I tentatively set Jan 27th as the release
>> >     date for
>> >      > 5.1.  Please let me know if that does not work for anyone.  Also
>> >     please
>> >      > keep that date in mind if there is anything you want to get into
>> 5.1.
>> >      > _______________________________________________
>> >      > hibernate-dev mailing list
>> >      > hibernate-dev at lists.jboss.org <mailto:
>> hibernate-dev at lists.jboss.org>
>>
> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >      >
>> >
>> _______________________________________________
>> 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:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From steve at hibernate.org  Mon Jan 11 11:04:05 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 11 Jan 2016 16:04:05 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <569077E3.9070201@redhat.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
Message-ID: <CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>

On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow <smarlow at redhat.com> wrote:

> Should we also look at changing Hibernate to not require Javassist
> classes be on the deployment classpath?


I just don't see how that is ever going to be realistically possible.  If
you have specific suggestions, we are all ears ;)

From alex.snaps at gmail.com  Mon Jan 11 11:50:10 2016
From: alex.snaps at gmail.com (Alex Snaps)
Date: Mon, 11 Jan 2016 16:50:10 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9sp-7uYMyZGFTOwdBkErCaqwwzFfFK-6b2xGFQ4jhWKbw@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>
	<CAFdSV9sp-7uYMyZGFTOwdBkErCaqwwzFfFK-6b2xGFQ4jhWKbw@mail.gmail.com>
Message-ID: <CAKux6paaEgXAjQTOTjRuWP5G3xKGTcNC7zHmPth1B17zzS++3g@mail.gmail.com>

Right, there was no plan to provide something for Ehcache3 quite yet.
That being said, I wonder whether we ever will. I have a 107 compliant H2LC
implementation. I also went over it with Sanne during Javaone and we think
it can be made into something suiting for bunch of providers.
Now, small caveat, while I still plan to work on this, as of this year I'm
not working for Terracotta anymore... Basically, that's whenever I'll find
time to do so.
cc'ed Louis, in case some he wants to provide some more formal stance...
Alex

On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve at hibernate.org> wrote:

> Petar, Alex Snaps (in CC) has been doing some work to update the version
> of Ehcache used in Hibernate ORM.  Alex, any updates?  As I understood it
> though Ehcache 3.x was not part of that effort, but Alex can of course say
> for sure.
>
>
>
> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Hello all,
>>
>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
>> hibernate-ehcache module updated in 5.1?
>>
>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>>
>>> I'll create a jira for the Javassist to be part of 5.1.
>>>
>>> Should we also look at changing Hibernate to not require Javassist
>>> classes be on the deployment classpath?  This might require cloning some
>>> Javassist runtime classes so that we don't get CNFE on
>>> javassist.util.proxy.ProxyObject (and whatever else is required by
>>> enhanced entity classes).
>>>
>>> [1] contains one of the CNFE's that I see with WildFly during deployment
>>> time (only if WildFly is hacked to not inject Javassist into the
>>> application classpath).  I am seeing
>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
>>> entity class with references to Javassist classes (see disassembled
>>> bytecode output [2]).  The generated class extends
>>> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. +
>>> javassist.util.proxy.RuntimeSupport +
>>> javassist.util.proxy.SerializedProxy.
>>>
>>> I'm sure that there are other Javassist classes that we probably also
>>> generate bytecode to depend on, in other places in Hibernate.
>>>
>>> I have no idea exactly how to resolve this.  I'm not sure if it would
>>> entail cloning the above javassist runtime classes into javassist.  Or
>>> separating them into a different (Javassist) library, so at least the
>>> application doesn't include the other Javassist classes.
>>>
>>> Sanne had some ideas that he mentioned [3].  By only exposing the needed
>>> classloaders to the deployment, I think he meant the above idea of
>>> separating Javassist into different jars.  Or something like that.
>>>
>>> Jason Greene also liked Sanne's suggestion of not requiring applications
>>> to have Javassist on their classpath, as applications might also include
>>> their own copy of Javassist because they want to generate some bytecode
>>> also.
>>>
>>> What do others think about the idea of not requiring Javassist to be on
>>> the Hibernate application classpath?  Again, I'm not sure if this only a
>>> problem on WildFly.  If it is, I'm not sure why. :)
>>>
>>> Scott
>>>
>>> [1]
>>>
>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
>>>
>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>>
>>> [3] https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>>>
>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>>> >
>>> >
>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
>>> > <mailto:smarlow at redhat.com>> wrote:
>>> >
>>> >     Should we upgrade to javassist latest in 5.1 still?
>>> >
>>> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>>> >      > Just a heads up that I tentatively set Jan 27th as the release
>>> >     date for
>>> >      > 5.1.  Please let me know if that does not work for anyone.  Also
>>> >     please
>>> >      > keep that date in mind if there is anything you want to get
>>> into 5.1.
>>> >      > _______________________________________________
>>> >      > hibernate-dev mailing list
>>> >      > hibernate-dev at lists.jboss.org <mailto:
>>> hibernate-dev at lists.jboss.org>
>>>
>> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >      >
>>> >
>>> _______________________________________________
>>> 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:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>

From sanne at hibernate.org  Mon Jan 11 11:57:11 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 11 Jan 2016 16:57:11 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAKux6paaEgXAjQTOTjRuWP5G3xKGTcNC7zHmPth1B17zzS++3g@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>
	<CAFdSV9sp-7uYMyZGFTOwdBkErCaqwwzFfFK-6b2xGFQ4jhWKbw@mail.gmail.com>
	<CAKux6paaEgXAjQTOTjRuWP5G3xKGTcNC7zHmPth1B17zzS++3g@mail.gmail.com>
Message-ID: <CAFm4XO1Sra2ybDK_mGQoxc-PO1A9xu0zhYiP18M+4ebvAFoHwg@mail.gmail.com>

Hi Alex!
I'm not expecting you to be able to work much on that 107 based
cache.. if you can that's great of course, but realistically if you
could just make it good enough for a PR then I think we should be able
to help finish that. The "extension points" we discussed can certainly
wait to be implemented as second step, later by some other volunteer.

Thanks,
Sanne


On 11 January 2016 at 16:50, Alex Snaps <alex.snaps at gmail.com> wrote:
> Right, there was no plan to provide something for Ehcache3 quite yet.
> That being said, I wonder whether we ever will. I have a 107 compliant H2LC
> implementation. I also went over it with Sanne during Javaone and we think
> it can be made into something suiting for bunch of providers.
> Now, small caveat, while I still plan to work on this, as of this year I'm
> not working for Terracotta anymore... Basically, that's whenever I'll find
> time to do so.
> cc'ed Louis, in case some he wants to provide some more formal stance...
> Alex
>
> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Petar, Alex Snaps (in CC) has been doing some work to update the version
>> of Ehcache used in Hibernate ORM.  Alex, any updates?  As I understood it
>> though Ehcache 3.x was not part of that effort, but Alex can of course say
>> for sure.
>>
>>
>>
>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Hello all,
>>>
>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
>>> hibernate-ehcache module updated in 5.1?
>>>
>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>>>
>>>> I'll create a jira for the Javassist to be part of 5.1.
>>>>
>>>> Should we also look at changing Hibernate to not require Javassist
>>>> classes be on the deployment classpath?  This might require cloning some
>>>> Javassist runtime classes so that we don't get CNFE on
>>>> javassist.util.proxy.ProxyObject (and whatever else is required by
>>>> enhanced entity classes).
>>>>
>>>> [1] contains one of the CNFE's that I see with WildFly during deployment
>>>> time (only if WildFly is hacked to not inject Javassist into the
>>>> application classpath).  I am seeing
>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
>>>> entity class with references to Javassist classes (see disassembled
>>>> bytecode output [2]).  The generated class extends
>>>> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. +
>>>> javassist.util.proxy.RuntimeSupport +
>>>> javassist.util.proxy.SerializedProxy.
>>>>
>>>> I'm sure that there are other Javassist classes that we probably also
>>>> generate bytecode to depend on, in other places in Hibernate.
>>>>
>>>> I have no idea exactly how to resolve this.  I'm not sure if it would
>>>> entail cloning the above javassist runtime classes into javassist.  Or
>>>> separating them into a different (Javassist) library, so at least the
>>>> application doesn't include the other Javassist classes.
>>>>
>>>> Sanne had some ideas that he mentioned [3].  By only exposing the needed
>>>> classloaders to the deployment, I think he meant the above idea of
>>>> separating Javassist into different jars.  Or something like that.
>>>>
>>>> Jason Greene also liked Sanne's suggestion of not requiring applications
>>>> to have Javassist on their classpath, as applications might also include
>>>> their own copy of Javassist because they want to generate some bytecode
>>>> also.
>>>>
>>>> What do others think about the idea of not requiring Javassist to be on
>>>> the Hibernate application classpath?  Again, I'm not sure if this only a
>>>> problem on WildFly.  If it is, I'm not sure why. :)
>>>>
>>>> Scott
>>>>
>>>> [1]
>>>>
>>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
>>>>
>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>>>
>>>> [3] https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>>>>
>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>>>> >
>>>> >
>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
>>>> > <mailto:smarlow at redhat.com>> wrote:
>>>> >
>>>> >     Should we upgrade to javassist latest in 5.1 still?
>>>> >
>>>> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>>>> >      > Just a heads up that I tentatively set Jan 27th as the release
>>>> >     date for
>>>> >      > 5.1.  Please let me know if that does not work for anyone.  Also
>>>> >     please
>>>> >      > keep that date in mind if there is anything you want to get
>>>> into 5.1.
>>>> >      > _______________________________________________
>>>> >      > hibernate-dev mailing list
>>>> >      > hibernate-dev at lists.jboss.org <mailto:
>>>> hibernate-dev at lists.jboss.org>
>>>>
>>> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >      >
>>>> >
>>>> _______________________________________________
>>>> 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:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=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 steve at hibernate.org  Mon Jan 11 13:49:56 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 11 Jan 2016 18:49:56 +0000
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
Message-ID: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>

The use of Java 8 features in Hibernate ORM is starting to expand.  Luckily
it is still constrained to just tests.

However these usages make development in an IDE more and more difficult.
Previously this was isolated to hibernate-infinispan.  Now[1] this has
crept into hibernate-entitymanager.  We need to have a plan here.  Either
we stop using Java 8 anywhere, or we move to Java 8 and rely on
AnimalSniffer to make sure we are still compatible.

Votes?  Other options?

[1]
https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101

From gunnar at hibernate.org  Mon Jan 11 16:33:03 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 11 Jan 2016 22:33:03 +0100
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
Message-ID: <CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>

Hey,

> or we move to Java 8 and rely on
> AnimalSniffer to make sure we are still compatible.

WDYM by "move to Java8" exactly? Requiring it at Hibernate's build
time, or also at runtime in user apps?


2016-01-11 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> The use of Java 8 features in Hibernate ORM is starting to expand.  Luckily
> it is still constrained to just tests.
>
> However these usages make development in an IDE more and more difficult.
> Previously this was isolated to hibernate-infinispan.  Now[1] this has
> crept into hibernate-entitymanager.  We need to have a plan here.  Either
> we stop using Java 8 anywhere, or we move to Java 8 and rely on
> AnimalSniffer to make sure we are still compatible.
>
> Votes?  Other options?
>
> [1]
> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Jan 11 16:35:23 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 11 Jan 2016 21:35:23 +0000
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
Message-ID: <CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>

The former.  People commit things that already assume the move to Java 8
locally to build (and test).  But at the moment we have not formalized
that, and so that causes problems when we import into an IDE - the imported
IDE project is built for 1.6 compliance and so everything we try in the IDE
fails.

On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hey,
>
> > or we move to Java 8 and rely on
> > AnimalSniffer to make sure we are still compatible.
>
> WDYM by "move to Java8" exactly? Requiring it at Hibernate's build
> time, or also at runtime in user apps?
>
>
> 2016-01-11 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > The use of Java 8 features in Hibernate ORM is starting to expand.
> Luckily
> > it is still constrained to just tests.
> >
> > However these usages make development in an IDE more and more difficult.
> > Previously this was isolated to hibernate-infinispan.  Now[1] this has
> > crept into hibernate-entitymanager.  We need to have a plan here.  Either
> > we stop using Java 8 anywhere, or we move to Java 8 and rely on
> > AnimalSniffer to make sure we are still compatible.
> >
> > Votes?  Other options?
> >
> > [1]
> >
> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Tue Jan 12 02:55:14 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 12 Jan 2016 09:55:14 +0200
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
Message-ID: <CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>

I used Java 8 syntax in the User Guide tests as I remembered that tests can
use it, but I also agree that this is a rather strange move.
Since we need to support Java 1.6, maybe it's a better idea to use the
latest JDK just in the modules where we have no other choice.
For testing, I think that 1.6 is just fine and I could easily change those
tests to remove the 1.8 dependency.

So I vote for using the same JDK for both main and test in a particular
module.

Vlad

On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> The former.  People commit things that already assume the move to Java 8
> locally to build (and test).  But at the moment we have not formalized
> that, and so that causes problems when we import into an IDE - the imported
> IDE project is built for 1.6 compliance and so everything we try in the IDE
> fails.
>
> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
> > Hey,
> >
> > > or we move to Java 8 and rely on
> > > AnimalSniffer to make sure we are still compatible.
> >
> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's build
> > time, or also at runtime in user apps?
> >
> >
> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > > The use of Java 8 features in Hibernate ORM is starting to expand.
> > Luckily
> > > it is still constrained to just tests.
> > >
> > > However these usages make development in an IDE more and more
> difficult.
> > > Previously this was isolated to hibernate-infinispan.  Now[1] this has
> > > crept into hibernate-entitymanager.  We need to have a plan here.
> Either
> > > we stop using Java 8 anywhere, or we move to Java 8 and rely on
> > > AnimalSniffer to make sure we are still compatible.
> > >
> > > Votes?  Other options?
> > >
> > > [1]
> > >
> >
> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
> > > _______________________________________________
> > > 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  Tue Jan 12 04:51:20 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 12 Jan 2016 09:51:20 +0000
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
Message-ID: <CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>

+1 for Vlad's proposal to use the same JDK for tests and main code in
a given module.

Infinispan requires Java8 at runtime too, so that module should be the
only one to use Java8?

On 12 January 2016 at 07:55, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> I used Java 8 syntax in the User Guide tests as I remembered that tests can
> use it, but I also agree that this is a rather strange move.
> Since we need to support Java 1.6, maybe it's a better idea to use the
> latest JDK just in the modules where we have no other choice.
> For testing, I think that 1.6 is just fine and I could easily change those
> tests to remove the 1.8 dependency.
>
> So I vote for using the same JDK for both main and test in a particular
> module.
>
> Vlad
>
> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> The former.  People commit things that already assume the move to Java 8
>> locally to build (and test).  But at the moment we have not formalized
>> that, and so that causes problems when we import into an IDE - the imported
>> IDE project is built for 1.6 compliance and so everything we try in the IDE
>> fails.
>>
>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>> > Hey,
>> >
>> > > or we move to Java 8 and rely on
>> > > AnimalSniffer to make sure we are still compatible.
>> >
>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's build
>> > time, or also at runtime in user apps?
>> >
>> >
>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > > The use of Java 8 features in Hibernate ORM is starting to expand.
>> > Luckily
>> > > it is still constrained to just tests.
>> > >
>> > > However these usages make development in an IDE more and more
>> difficult.
>> > > Previously this was isolated to hibernate-infinispan.  Now[1] this has
>> > > crept into hibernate-entitymanager.  We need to have a plan here.
>> Either
>> > > we stop using Java 8 anywhere, or we move to Java 8 and rely on
>> > > AnimalSniffer to make sure we are still compatible.
>> > >
>> > > Votes?  Other options?
>> > >
>> > > [1]
>> > >
>> >
>> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
>> > > _______________________________________________
>> > > 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  Tue Jan 12 05:07:51 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 12 Jan 2016 11:07:51 +0100
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
Message-ID: <CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>

@Vlad, what Java 8 syntax specifically are you using in the user guide
tests (examples?)?

I like the idea of using a current syntax in usage examples, to give
the guide a current look and show that our APIs play well with current
Java versions (while staying compatible with older ones).



2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> +1 for Vlad's proposal to use the same JDK for tests and main code in
> a given module.
>
> Infinispan requires Java8 at runtime too, so that module should be the
> only one to use Java8?
>
> On 12 January 2016 at 07:55, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>> I used Java 8 syntax in the User Guide tests as I remembered that tests can
>> use it, but I also agree that this is a rather strange move.
>> Since we need to support Java 1.6, maybe it's a better idea to use the
>> latest JDK just in the modules where we have no other choice.
>> For testing, I think that 1.6 is just fine and I could easily change those
>> tests to remove the 1.8 dependency.
>>
>> So I vote for using the same JDK for both main and test in a particular
>> module.
>>
>> Vlad
>>
>> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> The former.  People commit things that already assume the move to Java 8
>>> locally to build (and test).  But at the moment we have not formalized
>>> that, and so that causes problems when we import into an IDE - the imported
>>> IDE project is built for 1.6 compliance and so everything we try in the IDE
>>> fails.
>>>
>>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>> > Hey,
>>> >
>>> > > or we move to Java 8 and rely on
>>> > > AnimalSniffer to make sure we are still compatible.
>>> >
>>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's build
>>> > time, or also at runtime in user apps?
>>> >
>>> >
>>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>>> > > The use of Java 8 features in Hibernate ORM is starting to expand.
>>> > Luckily
>>> > > it is still constrained to just tests.
>>> > >
>>> > > However these usages make development in an IDE more and more
>>> difficult.
>>> > > Previously this was isolated to hibernate-infinispan.  Now[1] this has
>>> > > crept into hibernate-entitymanager.  We need to have a plan here.
>>> Either
>>> > > we stop using Java 8 anywhere, or we move to Java 8 and rely on
>>> > > AnimalSniffer to make sure we are still compatible.
>>> > >
>>> > > Votes?  Other options?
>>> > >
>>> > > [1]
>>> > >
>>> >
>>> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
>>> > > _______________________________________________
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Tue Jan 12 05:56:05 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 12 Jan 2016 11:56:05 +0100
Subject: [hibernate-dev] Issue a warning if field and getter annotation
	styles are mixed?
Message-ID: <CADGJaX8kyj9G48yiYthqfPTpvOio=CqaVFTCAy03CFCA-nY+UQ@mail.gmail.com>

Hi,

Would it be feasible to raise a warning or error in cases where
mapping annotations are given on an element not matching the default
access type for that entity and @Access has not been given explicitly
either?

The most common case of this issue which I saw several times happen is
where @Id is given at the field level but some other mapping
annotations are given on property getters. The latter are silently
ignored in that case, resulting in mapping errors tough to understand
for those not super-deep into the details of access type retrieval. A
warning might help them.

Any thoughts?

--Gunnar

From dreborier at gmail.com  Tue Jan 12 05:56:50 2016
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 12 Jan 2016 10:56:50 +0000
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
Message-ID: <CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>

I'm not against the use of Java 8 letting AnimalSniffer guarding for
compatibility,
but I understand this can cause some problems so I'm ok with removing Java
8 usage from tests.

On 12 January 2016 at 10:07, Gunnar Morling <gunnar at hibernate.org> wrote:

> @Vlad, what Java 8 syntax specifically are you using in the user guide
> tests (examples?)?
>
> I like the idea of using a current syntax in usage examples, to give
> the guide a current look and show that our APIs play well with current
> Java versions (while staying compatible with older ones).
>
>
>
> 2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> > +1 for Vlad's proposal to use the same JDK for tests and main code in
> > a given module.
> >
> > Infinispan requires Java8 at runtime too, so that module should be the
> > only one to use Java8?
> >
> > On 12 January 2016 at 07:55, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> >> I used Java 8 syntax in the User Guide tests as I remembered that tests
> can
> >> use it, but I also agree that this is a rather strange move.
> >> Since we need to support Java 1.6, maybe it's a better idea to use the
> >> latest JDK just in the modules where we have no other choice.
> >> For testing, I think that 1.6 is just fine and I could easily change
> those
> >> tests to remove the 1.8 dependency.
> >>
> >> So I vote for using the same JDK for both main and test in a particular
> >> module.
> >>
> >> Vlad
> >>
> >> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> The former.  People commit things that already assume the move to Java
> 8
> >>> locally to build (and test).  But at the moment we have not formalized
> >>> that, and so that causes problems when we import into an IDE - the
> imported
> >>> IDE project is built for 1.6 compliance and so everything we try in
> the IDE
> >>> fails.
> >>>
> >>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling <gunnar at hibernate.org>
> >>> wrote:
> >>>
> >>> > Hey,
> >>> >
> >>> > > or we move to Java 8 and rely on
> >>> > > AnimalSniffer to make sure we are still compatible.
> >>> >
> >>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's build
> >>> > time, or also at runtime in user apps?
> >>> >
> >>> >
> >>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >>> > > The use of Java 8 features in Hibernate ORM is starting to expand.
> >>> > Luckily
> >>> > > it is still constrained to just tests.
> >>> > >
> >>> > > However these usages make development in an IDE more and more
> >>> difficult.
> >>> > > Previously this was isolated to hibernate-infinispan.  Now[1] this
> has
> >>> > > crept into hibernate-entitymanager.  We need to have a plan here.
> >>> Either
> >>> > > we stop using Java 8 anywhere, or we move to Java 8 and rely on
> >>> > > AnimalSniffer to make sure we are still compatible.
> >>> > >
> >>> > > Votes?  Other options?
> >>> > >
> >>> > > [1]
> >>> > >
> >>> >
> >>>
> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
> >>> > > _______________________________________________
> >>> > > hibernate-dev mailing list
> >>> > > hibernate-dev at lists.jboss.org
> >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Tue Jan 12 06:49:06 2016
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 12 Jan 2016 12:49:06 +0100
Subject: [hibernate-dev] Issue a warning if field and getter annotation
 styles are mixed?
In-Reply-To: <CADGJaX8kyj9G48yiYthqfPTpvOio=CqaVFTCAy03CFCA-nY+UQ@mail.gmail.com>
References: <CADGJaX8kyj9G48yiYthqfPTpvOio=CqaVFTCAy03CFCA-nY+UQ@mail.gmail.com>
Message-ID: <20160112114906.GA89561@Nineveh.local>

Hi,

> Would it be feasible to raise a warning or error in cases where
> mapping annotations are given on an element not matching the default
> access type for that entity and @Access has not been given explicitly
> either?

Sure, but I think it would need some doing. AFAIR the code determines the access type
and from then on just reflects on either fields or methods. Maybe as a performance 
optimisation as well. Not sure. I agree having some warning for the case you describe 
is a good idea, but don't expect this to be a one lines in the code.

That said, things would be easier with Jandex. There it would be easier to determine 
inconsistent configuration. I seem to vaguely recall that I might even have done though
when working in the metamodel branch. 

Personally I'd probably address this in conjunction with a re-write of the mapping code
and switch to Jandex. I think that is still somewhere on the horizon.

If not, it is for sure feasible, just take quite some effort.

> The most common case of this issue which I saw several times happen is
> where @Id is given at the field level but some other mapping
> annotations are given on property getters

Right, that's a usual mistake.

> for those not super-deep into the details of access type retrieval.

I don't think you need to be super-deep into ORM/JPA to understand that.
There are warnings and notes about this everywhere.

> A warning might help them.

For sure, but as said, I'd tackle this as part of a bigger refactoring. 

--Hardy

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

From sanne at hibernate.org  Tue Jan 12 06:56:35 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 12 Jan 2016 11:56:35 +0000
Subject: [hibernate-dev] Issue a warning if field and getter annotation
 styles are mixed?
In-Reply-To: <20160112114906.GA89561@Nineveh.local>
References: <CADGJaX8kyj9G48yiYthqfPTpvOio=CqaVFTCAy03CFCA-nY+UQ@mail.gmail.com>
	<20160112114906.GA89561@Nineveh.local>
Message-ID: <CAFm4XO248Qu1EaiZpmoTvu1T_+2PM1DwY-845mCyx1d4e_admQ@mail.gmail.com>

+1 this is a very common mistake for beginners.

But I'm with Hardy in not trying to shoehorn such support in our
current metadata handling, but rather to keep it in mind when moving
it all to Jandex. (how to remember that?)

On 12 January 2016 at 11:49, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
>> Would it be feasible to raise a warning or error in cases where
>> mapping annotations are given on an element not matching the default
>> access type for that entity and @Access has not been given explicitly
>> either?
>
> Sure, but I think it would need some doing. AFAIR the code determines the access type
> and from then on just reflects on either fields or methods. Maybe as a performance
> optimisation as well. Not sure. I agree having some warning for the case you describe
> is a good idea, but don't expect this to be a one lines in the code.
>
> That said, things would be easier with Jandex. There it would be easier to determine
> inconsistent configuration. I seem to vaguely recall that I might even have done though
> when working in the metamodel branch.
>
> Personally I'd probably address this in conjunction with a re-write of the mapping code
> and switch to Jandex. I think that is still somewhere on the horizon.
>
> If not, it is for sure feasible, just take quite some effort.
>
>> The most common case of this issue which I saw several times happen is
>> where @Id is given at the field level but some other mapping
>> annotations are given on property getters
>
> Right, that's a usual mistake.
>
>> for those not super-deep into the details of access type retrieval.
>
> I don't think you need to be super-deep into ORM/JPA to understand that.
> There are warnings and notes about this everywhere.
>
>> A warning might help them.
>
> For sure, but as said, I'd tackle this as part of a bigger refactoring.
>
> --Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Tue Jan 12 10:08:35 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 12 Jan 2016 15:08:35 +0000
Subject: [hibernate-dev] Issue a warning if field and getter annotation
 styles are mixed?
In-Reply-To: <CAFm4XO248Qu1EaiZpmoTvu1T_+2PM1DwY-845mCyx1d4e_admQ@mail.gmail.com>
References: <CADGJaX8kyj9G48yiYthqfPTpvOio=CqaVFTCAy03CFCA-nY+UQ@mail.gmail.com>
	<20160112114906.GA89561@Nineveh.local>
	<CAFm4XO248Qu1EaiZpmoTvu1T_+2PM1DwY-845mCyx1d4e_admQ@mail.gmail.com>
Message-ID: <CAFdSV9sgHkLnzykCuB0bLq39uMWQ-PZtECV-e4_=fLP6ivFAEw@mail.gmail.com>

Create the issue and use the 'jandex-binding' version in Jira

On Tue, Jan 12, 2016 at 5:57 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> +1 this is a very common mistake for beginners.
>
> But I'm with Hardy in not trying to shoehorn such support in our
> current metadata handling, but rather to keep it in mind when moving
> it all to Jandex. (how to remember that?)
>
> On 12 January 2016 at 11:49, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> > Hi,
> >
> >> Would it be feasible to raise a warning or error in cases where
> >> mapping annotations are given on an element not matching the default
> >> access type for that entity and @Access has not been given explicitly
> >> either?
> >
> > Sure, but I think it would need some doing. AFAIR the code determines
> the access type
> > and from then on just reflects on either fields or methods. Maybe as a
> performance
> > optimisation as well. Not sure. I agree having some warning for the case
> you describe
> > is a good idea, but don't expect this to be a one lines in the code.
> >
> > That said, things would be easier with Jandex. There it would be easier
> to determine
> > inconsistent configuration. I seem to vaguely recall that I might even
> have done though
> > when working in the metamodel branch.
> >
> > Personally I'd probably address this in conjunction with a re-write of
> the mapping code
> > and switch to Jandex. I think that is still somewhere on the horizon.
> >
> > If not, it is for sure feasible, just take quite some effort.
> >
> >> The most common case of this issue which I saw several times happen is
> >> where @Id is given at the field level but some other mapping
> >> annotations are given on property getters
> >
> > Right, that's a usual mistake.
> >
> >> for those not super-deep into the details of access type retrieval.
> >
> > I don't think you need to be super-deep into ORM/JPA to understand that.
> > There are warnings and notes about this everywhere.
> >
> >> A warning might help them.
> >
> > For sure, but as said, I'd tackle this as part of a bigger refactoring.
> >
> > --Hardy
> >
> >
> > _______________________________________________
> > 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  Tue Jan 12 10:15:06 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 12 Jan 2016 15:15:06 +0000
Subject: [hibernate-dev] Oracle running on CI
Message-ID: <CAFm4XO1JQdZkgj8tTTgj4GY45rgUZKdhw6LkW5msSUeoieig7g@mail.gmail.com>

Hi Steve,
when explicitly setting the Dialect to an empty string I have several
failures; when leaving it as-is I believe this run was valid though,
at least that's the feeling I'm getting from the kind of failures:

http://ci.hibernate.org/view/ORM/job/hibernate_orm_master_oracle/ws/hibernate-core/target/matrix/oracle/reports/index.html

Some tests are failing, but a significant amount is passing just fine
and the logs seem to indicate that it's using the Oracle testing
instance.

Also, setting the dialect seems consistent with other matrix configurations?

Thanks,
Sanne

From steve at hibernate.org  Tue Jan 12 10:30:15 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 12 Jan 2016 15:30:15 +0000
Subject: [hibernate-dev] Oracle running on CI
In-Reply-To: <CAFm4XO1JQdZkgj8tTTgj4GY45rgUZKdhw6LkW5msSUeoieig7g@mail.gmail.com>
References: <CAFm4XO1JQdZkgj8tTTgj4GY45rgUZKdhw6LkW5msSUeoieig7g@mail.gmail.com>
Message-ID: <CAFdSV9u-kNcV0iG-hdFhAo8bFAdvswoPEo87nE+Pj=AZrn0rsA@mail.gmail.com>

I was just guessing about leaving it blank.  I do not know for sure whether
the matrix plugin allows to not specify the Dialect explicitly.  That is a
worthwhile feature (to test Dialect resolution), but it would certainly
seem like the plugin does not handle it well now.  So yes, leave it
explicitly specified.

On Tue, Jan 12, 2016 at 9:15 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Steve,
> when explicitly setting the Dialect to an empty string I have several
> failures; when leaving it as-is I believe this run was valid though,
> at least that's the feeling I'm getting from the kind of failures:
>
>
> http://ci.hibernate.org/view/ORM/job/hibernate_orm_master_oracle/ws/hibernate-core/target/matrix/oracle/reports/index.html
>
> Some tests are failing, but a significant amount is passing just fine
> and the logs seem to indicate that it's using the Oracle testing
> instance.
>
> Also, setting the dialect seems consistent with other matrix
> configurations?
>
> Thanks,
> Sanne
>

From smarlow at redhat.com  Tue Jan 12 11:08:56 2016
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 12 Jan 2016 11:08:56 -0500
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
Message-ID: <56952518.4090700@redhat.com>



On 01/11/2016 11:04 AM, Steve Ebersole wrote:
> On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     Should we also look at changing Hibernate to not require Javassist
>     classes be on the deployment classpath?
>
>
> I just don't see how that is ever going to be realistically possible.
> If you have specific suggestions, we are all ears ;)

I'm thinking that we should defer the Javassist upgrade until we figure 
out what we want to do exactly to address this problem.  I would expect 
that other modular classloading environments besides WildFly may also 
need a fix.

For a possible workaround (for proxies), if we were able to clone the 
needed Javassist runtime classes, into the application classloader and 
generate proxies that use the cloned copies, I think that could help. 
We would have to clone them into a private package name (e.g. something 
like org.hibernate.javassist.runtime.*).  We would also have to generate 
the proxies using the cloned classes.

There may be other ways to change Hibernate applications to not depend 
on the Javassist runtime classes.  For example if we change the bytecode 
that we generate, to not reference the Javassist runtime classes, that 
also would address this.

From guillaume.smet at gmail.com  Tue Jan 12 12:35:09 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Tue, 12 Jan 2016 18:35:09 +0100
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <56952518.4090700@redhat.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
Message-ID: <CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>

Hi Steve and al.

Any chance we could make progress on HHH-7610
<https://hibernate.atlassian.net/browse/HHH-7610> and
https://github.com/hibernate/hibernate-orm/pull/1080 for 5.1?

I'll revisit the PR tomorrow to fix the conflicts.

-- 
Guillaume

On Tue, Jan 12, 2016 at 5:08 PM, Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 01/11/2016 11:04 AM, Steve Ebersole wrote:
> > On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow <smarlow at redhat.com
> > <mailto:smarlow at redhat.com>> wrote:
> >
> >     Should we also look at changing Hibernate to not require Javassist
> >     classes be on the deployment classpath?
> >
> >
> > I just don't see how that is ever going to be realistically possible.
> > If you have specific suggestions, we are all ears ;)
>
> I'm thinking that we should defer the Javassist upgrade until we figure
> out what we want to do exactly to address this problem.  I would expect
> that other modular classloading environments besides WildFly may also
> need a fix.
>
> For a possible workaround (for proxies), if we were able to clone the
> needed Javassist runtime classes, into the application classloader and
> generate proxies that use the cloned copies, I think that could help.
> We would have to clone them into a private package name (e.g. something
> like org.hibernate.javassist.runtime.*).  We would also have to generate
> the proxies using the cloned classes.
>
> There may be other ways to change Hibernate applications to not depend
> on the Javassist runtime classes.  For example if we change the bytecode
> that we generate, to not reference the Javassist runtime classes, that
> also would address this.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jan 12 12:40:58 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 12 Jan 2016 17:40:58 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
Message-ID: <CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>

If you clean up the conflicts I can look for 5.1

On Tue, Jan 12, 2016 at 11:35 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi Steve and al.
>
> Any chance we could make progress on HHH-7610
> <https://hibernate.atlassian.net/browse/HHH-7610> and
> https://github.com/hibernate/hibernate-orm/pull/1080 for 5.1?
>
> I'll revisit the PR tomorrow to fix the conflicts.
>
> --
> Guillaume
>
> On Tue, Jan 12, 2016 at 5:08 PM, Scott Marlow <smarlow at redhat.com> wrote:
>
>>
>>
>> On 01/11/2016 11:04 AM, Steve Ebersole wrote:
>> > On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow <smarlow at redhat.com
>> > <mailto:smarlow at redhat.com>> wrote:
>> >
>> >     Should we also look at changing Hibernate to not require Javassist
>> >     classes be on the deployment classpath?
>> >
>> >
>> > I just don't see how that is ever going to be realistically possible.
>> > If you have specific suggestions, we are all ears ;)
>>
>> I'm thinking that we should defer the Javassist upgrade until we figure
>> out what we want to do exactly to address this problem.  I would expect
>> that other modular classloading environments besides WildFly may also
>> need a fix.
>>
>> For a possible workaround (for proxies), if we were able to clone the
>> needed Javassist runtime classes, into the application classloader and
>> generate proxies that use the cloned copies, I think that could help.
>> We would have to clone them into a private package name (e.g. something
>> like org.hibernate.javassist.runtime.*).  We would also have to generate
>> the proxies using the cloned classes.
>>
>> There may be other ways to change Hibernate applications to not depend
>> on the Javassist runtime classes.  For example if we change the bytecode
>> that we generate, to not reference the Javassist runtime classes, that
>> also would address this.
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Wed Jan 13 03:47:12 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 13 Jan 2016 09:47:12 +0100
Subject: [hibernate-dev] Issue a warning if field and getter annotation
 styles are mixed?
In-Reply-To: <CAFdSV9sgHkLnzykCuB0bLq39uMWQ-PZtECV-e4_=fLP6ivFAEw@mail.gmail.com>
References: <CADGJaX8kyj9G48yiYthqfPTpvOio=CqaVFTCAy03CFCA-nY+UQ@mail.gmail.com>
	<20160112114906.GA89561@Nineveh.local>
	<CAFm4XO248Qu1EaiZpmoTvu1T_+2PM1DwY-845mCyx1d4e_admQ@mail.gmail.com>
	<CAFdSV9sgHkLnzykCuB0bLq39uMWQ-PZtECV-e4_=fLP6ivFAEw@mail.gmail.com>
Message-ID: <CADGJaX8fFn-qG6cgJ2CDiqJyhkaHkgjRZvUn18dgJiOvkUTMbA@mail.gmail.com>

There you go: https://hibernate.atlassian.net/browse/HHH-10440

2016-01-12 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> Create the issue and use the 'jandex-binding' version in Jira
>
> On Tue, Jan 12, 2016 at 5:57 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>
>> +1 this is a very common mistake for beginners.
>>
>> But I'm with Hardy in not trying to shoehorn such support in our
>> current metadata handling, but rather to keep it in mind when moving
>> it all to Jandex. (how to remember that?)
>>
>> On 12 January 2016 at 11:49, Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>> > Hi,
>> >
>> >> Would it be feasible to raise a warning or error in cases where
>> >> mapping annotations are given on an element not matching the default
>> >> access type for that entity and @Access has not been given explicitly
>> >> either?
>> >
>> > Sure, but I think it would need some doing. AFAIR the code determines
>> the access type
>> > and from then on just reflects on either fields or methods. Maybe as a
>> performance
>> > optimisation as well. Not sure. I agree having some warning for the case
>> you describe
>> > is a good idea, but don't expect this to be a one lines in the code.
>> >
>> > That said, things would be easier with Jandex. There it would be easier
>> to determine
>> > inconsistent configuration. I seem to vaguely recall that I might even
>> have done though
>> > when working in the metamodel branch.
>> >
>> > Personally I'd probably address this in conjunction with a re-write of
>> the mapping code
>> > and switch to Jandex. I think that is still somewhere on the horizon.
>> >
>> > If not, it is for sure feasible, just take quite some effort.
>> >
>> >> The most common case of this issue which I saw several times happen is
>> >> where @Id is given at the field level but some other mapping
>> >> annotations are given on property getters
>> >
>> > Right, that's a usual mistake.
>> >
>> >> for those not super-deep into the details of access type retrieval.
>> >
>> > I don't think you need to be super-deep into ORM/JPA to understand that.
>> > There are warnings and notes about this everywhere.
>> >
>> >> A warning might help them.
>> >
>> > For sure, but as said, I'd tackle this as part of a bigger refactoring.
>> >
>> > --Hardy
>> >
>> >
>> > _______________________________________________
>> > 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 guillaume.smet at gmail.com  Wed Jan 13 08:10:54 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 13 Jan 2016 14:10:54 +0100
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
Message-ID: <CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>

On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve at hibernate.org> wrote:

> If you clean up the conflicts I can look for 5.1
>

Done!

-- 
Guillaume

From steve at hibernate.org  Wed Jan 13 09:09:03 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 14:09:03 +0000
Subject: [hibernate-dev] Issue a warning if field and getter annotation
 styles are mixed?
In-Reply-To: <CADGJaX8fFn-qG6cgJ2CDiqJyhkaHkgjRZvUn18dgJiOvkUTMbA@mail.gmail.com>
References: <CADGJaX8kyj9G48yiYthqfPTpvOio=CqaVFTCAy03CFCA-nY+UQ@mail.gmail.com>
	<20160112114906.GA89561@Nineveh.local>
	<CAFm4XO248Qu1EaiZpmoTvu1T_+2PM1DwY-845mCyx1d4e_admQ@mail.gmail.com>
	<CAFdSV9sgHkLnzykCuB0bLq39uMWQ-PZtECV-e4_=fLP6ivFAEw@mail.gmail.com>
	<CADGJaX8fFn-qG6cgJ2CDiqJyhkaHkgjRZvUn18dgJiOvkUTMbA@mail.gmail.com>
Message-ID: <CAFdSV9u2J2oqv5HqknHcK+pwDGVR=oRu+TddASovoM1fM4jceA@mail.gmail.com>

Thanks.

BTW, https://github.com/sebersole/hibernate-core/commits/jandex-binding is
the branch where I am working on that Jandex migration.  The
PersistentAttributeMemberResolver is in place there if you wanted to check
whether that code handles this already.


On Wed, Jan 13, 2016 at 2:47 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> There you go: https://hibernate.atlassian.net/browse/HHH-10440
>
> 2016-01-12 16:08 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > Create the issue and use the 'jandex-binding' version in Jira
> >
> > On Tue, Jan 12, 2016 at 5:57 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >
> >> +1 this is a very common mistake for beginners.
> >>
> >> But I'm with Hardy in not trying to shoehorn such support in our
> >> current metadata handling, but rather to keep it in mind when moving
> >> it all to Jandex. (how to remember that?)
> >>
> >> On 12 January 2016 at 11:49, Hardy Ferentschik <hardy at hibernate.org>
> >> wrote:
> >> > Hi,
> >> >
> >> >> Would it be feasible to raise a warning or error in cases where
> >> >> mapping annotations are given on an element not matching the default
> >> >> access type for that entity and @Access has not been given explicitly
> >> >> either?
> >> >
> >> > Sure, but I think it would need some doing. AFAIR the code determines
> >> the access type
> >> > and from then on just reflects on either fields or methods. Maybe as a
> >> performance
> >> > optimisation as well. Not sure. I agree having some warning for the
> case
> >> you describe
> >> > is a good idea, but don't expect this to be a one lines in the code.
> >> >
> >> > That said, things would be easier with Jandex. There it would be
> easier
> >> to determine
> >> > inconsistent configuration. I seem to vaguely recall that I might even
> >> have done though
> >> > when working in the metamodel branch.
> >> >
> >> > Personally I'd probably address this in conjunction with a re-write of
> >> the mapping code
> >> > and switch to Jandex. I think that is still somewhere on the horizon.
> >> >
> >> > If not, it is for sure feasible, just take quite some effort.
> >> >
> >> >> The most common case of this issue which I saw several times happen
> is
> >> >> where @Id is given at the field level but some other mapping
> >> >> annotations are given on property getters
> >> >
> >> > Right, that's a usual mistake.
> >> >
> >> >> for those not super-deep into the details of access type retrieval.
> >> >
> >> > I don't think you need to be super-deep into ORM/JPA to understand
> that.
> >> > There are warnings and notes about this everywhere.
> >> >
> >> >> A warning might help them.
> >> >
> >> > For sure, but as said, I'd tackle this as part of a bigger
> refactoring.
> >> >
> >> > --Hardy
> >> >
> >> >
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jan 13 09:12:20 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 14:12:20 +0000
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
Message-ID: <CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>

Vlad, I see you created a PR for moving your new tests out of
hibernate-entitymanager into documentation.  I guess that depends on the
intent.  Are they meant as illustrations?  And if so, how are you expecting
people will see them?  And if they are meant as real tests rather than as
illustrations, I think moving them is not appropriate.

On Tue, Jan 12, 2016 at 4:57 AM andrea boriero <dreborier at gmail.com> wrote:

> I'm not against the use of Java 8 letting AnimalSniffer guarding for
> compatibility,
> but I understand this can cause some problems so I'm ok with removing Java
> 8 usage from tests.
>
> On 12 January 2016 at 10:07, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > @Vlad, what Java 8 syntax specifically are you using in the user guide
> > tests (examples?)?
> >
> > I like the idea of using a current syntax in usage examples, to give
> > the guide a current look and show that our APIs play well with current
> > Java versions (while staying compatible with older ones).
> >
> >
> >
> > 2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> > > +1 for Vlad's proposal to use the same JDK for tests and main code in
> > > a given module.
> > >
> > > Infinispan requires Java8 at runtime too, so that module should be the
> > > only one to use Java8?
> > >
> > > On 12 January 2016 at 07:55, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> > >> I used Java 8 syntax in the User Guide tests as I remembered that
> tests
> > can
> > >> use it, but I also agree that this is a rather strange move.
> > >> Since we need to support Java 1.6, maybe it's a better idea to use the
> > >> latest JDK just in the modules where we have no other choice.
> > >> For testing, I think that 1.6 is just fine and I could easily change
> > those
> > >> tests to remove the 1.8 dependency.
> > >>
> > >> So I vote for using the same JDK for both main and test in a
> particular
> > >> module.
> > >>
> > >> Vlad
> > >>
> > >> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole <steve at hibernate.org
> >
> > >> wrote:
> > >>
> > >>> The former.  People commit things that already assume the move to
> Java
> > 8
> > >>> locally to build (and test).  But at the moment we have not
> formalized
> > >>> that, and so that causes problems when we import into an IDE - the
> > imported
> > >>> IDE project is built for 1.6 compliance and so everything we try in
> > the IDE
> > >>> fails.
> > >>>
> > >>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling <gunnar at hibernate.org
> >
> > >>> wrote:
> > >>>
> > >>> > Hey,
> > >>> >
> > >>> > > or we move to Java 8 and rely on
> > >>> > > AnimalSniffer to make sure we are still compatible.
> > >>> >
> > >>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's build
> > >>> > time, or also at runtime in user apps?
> > >>> >
> > >>> >
> > >>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > >>> > > The use of Java 8 features in Hibernate ORM is starting to
> expand.
> > >>> > Luckily
> > >>> > > it is still constrained to just tests.
> > >>> > >
> > >>> > > However these usages make development in an IDE more and more
> > >>> difficult.
> > >>> > > Previously this was isolated to hibernate-infinispan.  Now[1]
> this
> > has
> > >>> > > crept into hibernate-entitymanager.  We need to have a plan here.
> > >>> Either
> > >>> > > we stop using Java 8 anywhere, or we move to Java 8 and rely on
> > >>> > > AnimalSniffer to make sure we are still compatible.
> > >>> > >
> > >>> > > Votes?  Other options?
> > >>> > >
> > >>> > > [1]
> > >>> > >
> > >>> >
> > >>>
> >
> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
> > >>> > > _______________________________________________
> > >>> > > hibernate-dev mailing list
> > >>> > > hibernate-dev at lists.jboss.org
> > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>> >
> > >>> _______________________________________________
> > >>> hibernate-dev mailing list
> > >>> hibernate-dev at lists.jboss.org
> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >>>
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Wed Jan 13 09:30:16 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 13 Jan 2016 16:30:16 +0200
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
	<CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
Message-ID: <CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>

Hi Steve,

The User Guide illustrations are snippets of code that go into the extras
folder, which stays right next to every chapter.
That's in the main folder.

The tests are now located in the test folder of the documentation folder,
so that we can update/evolve them in future.
They are also a proof that the code snippets work.
There was a time when I realized that an example was not really ok, and I
had to change that.
I change the test first to see how it worked, and only then I updated the
Guide.
They are also a form of regression testing, so that we are alerted if some
future change will break the expectations we made while writing the
documentation code snippets.

The reader can fork the repo and try them, if he wishes.

Vlad

On Wed, Jan 13, 2016 at 4:12 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Vlad, I see you created a PR for moving your new tests out of
> hibernate-entitymanager into documentation.  I guess that depends on the
> intent.  Are they meant as illustrations?  And if so, how are you expecting
> people will see them?  And if they are meant as real tests rather than as
> illustrations, I think moving them is not appropriate.
>
> On Tue, Jan 12, 2016 at 4:57 AM andrea boriero <dreborier at gmail.com>
> wrote:
>
> > I'm not against the use of Java 8 letting AnimalSniffer guarding for
> > compatibility,
> > but I understand this can cause some problems so I'm ok with removing
> Java
> > 8 usage from tests.
> >
> > On 12 January 2016 at 10:07, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >
> > > @Vlad, what Java 8 syntax specifically are you using in the user guide
> > > tests (examples?)?
> > >
> > > I like the idea of using a current syntax in usage examples, to give
> > > the guide a current look and show that our APIs play well with current
> > > Java versions (while staying compatible with older ones).
> > >
> > >
> > >
> > > 2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> > > > +1 for Vlad's proposal to use the same JDK for tests and main code in
> > > > a given module.
> > > >
> > > > Infinispan requires Java8 at runtime too, so that module should be
> the
> > > > only one to use Java8?
> > > >
> > > > On 12 January 2016 at 07:55, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > > wrote:
> > > >> I used Java 8 syntax in the User Guide tests as I remembered that
> > tests
> > > can
> > > >> use it, but I also agree that this is a rather strange move.
> > > >> Since we need to support Java 1.6, maybe it's a better idea to use
> the
> > > >> latest JDK just in the modules where we have no other choice.
> > > >> For testing, I think that 1.6 is just fine and I could easily change
> > > those
> > > >> tests to remove the 1.8 dependency.
> > > >>
> > > >> So I vote for using the same JDK for both main and test in a
> > particular
> > > >> module.
> > > >>
> > > >> Vlad
> > > >>
> > > >> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole <
> steve at hibernate.org
> > >
> > > >> wrote:
> > > >>
> > > >>> The former.  People commit things that already assume the move to
> > Java
> > > 8
> > > >>> locally to build (and test).  But at the moment we have not
> > formalized
> > > >>> that, and so that causes problems when we import into an IDE - the
> > > imported
> > > >>> IDE project is built for 1.6 compliance and so everything we try in
> > > the IDE
> > > >>> fails.
> > > >>>
> > > >>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling <
> gunnar at hibernate.org
> > >
> > > >>> wrote:
> > > >>>
> > > >>> > Hey,
> > > >>> >
> > > >>> > > or we move to Java 8 and rely on
> > > >>> > > AnimalSniffer to make sure we are still compatible.
> > > >>> >
> > > >>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's
> build
> > > >>> > time, or also at runtime in user apps?
> > > >>> >
> > > >>> >
> > > >>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > > >>> > > The use of Java 8 features in Hibernate ORM is starting to
> > expand.
> > > >>> > Luckily
> > > >>> > > it is still constrained to just tests.
> > > >>> > >
> > > >>> > > However these usages make development in an IDE more and more
> > > >>> difficult.
> > > >>> > > Previously this was isolated to hibernate-infinispan.  Now[1]
> > this
> > > has
> > > >>> > > crept into hibernate-entitymanager.  We need to have a plan
> here.
> > > >>> Either
> > > >>> > > we stop using Java 8 anywhere, or we move to Java 8 and rely on
> > > >>> > > AnimalSniffer to make sure we are still compatible.
> > > >>> > >
> > > >>> > > Votes?  Other options?
> > > >>> > >
> > > >>> > > [1]
> > > >>> > >
> > > >>> >
> > > >>>
> > >
> >
> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
> > > >>> > > _______________________________________________
> > > >>> > > hibernate-dev mailing list
> > > >>> > > hibernate-dev at lists.jboss.org
> > > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >>> >
> > > >>> _______________________________________________
> > > >>> hibernate-dev mailing list
> > > >>> hibernate-dev at lists.jboss.org
> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >>>
> > > >> _______________________________________________
> > > >> hibernate-dev mailing list
> > > >> hibernate-dev at lists.jboss.org
> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Jan 13 09:47:19 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 13 Jan 2016 15:47:19 +0100
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
	<CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
	<CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>
Message-ID: <CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>

Hey Vlad,

slightly related and just in case you are not aware of this feature
yet: You can include (parts of) actual source code files straight into
AsciiDoc documents. We do that in the HV reference guide, e.g. at [1].
That way you are 100% sure your examples actually compile (and pass
tests) and you don't need to copy & paste them.

Cheers,

--Gunnar

[1] https://raw.githubusercontent.com/hibernate/hibernate-validator/master/documentation/src/main/asciidoc/ch11.asciidoc


2016-01-13 15:30 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> Hi Steve,
>
> The User Guide illustrations are snippets of code that go into the extras
> folder, which stays right next to every chapter.
> That's in the main folder.
>
> The tests are now located in the test folder of the documentation folder, so
> that we can update/evolve them in future.
> They are also a proof that the code snippets work.
> There was a time when I realized that an example was not really ok, and I
> had to change that.
> I change the test first to see how it worked, and only then I updated the
> Guide.
> They are also a form of regression testing, so that we are alerted if some
> future change will break the expectations we made while writing the
> documentation code snippets.
>
> The reader can fork the repo and try them, if he wishes.
>
> Vlad
>
> On Wed, Jan 13, 2016 at 4:12 PM, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> Vlad, I see you created a PR for moving your new tests out of
>> hibernate-entitymanager into documentation.  I guess that depends on the
>> intent.  Are they meant as illustrations?  And if so, how are you
>> expecting
>> people will see them?  And if they are meant as real tests rather than as
>> illustrations, I think moving them is not appropriate.
>>
>> On Tue, Jan 12, 2016 at 4:57 AM andrea boriero <dreborier at gmail.com>
>> wrote:
>>
>> > I'm not against the use of Java 8 letting AnimalSniffer guarding for
>> > compatibility,
>> > but I understand this can cause some problems so I'm ok with removing
>> > Java
>> > 8 usage from tests.
>> >
>> > On 12 January 2016 at 10:07, Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >
>> > > @Vlad, what Java 8 syntax specifically are you using in the user guide
>> > > tests (examples?)?
>> > >
>> > > I like the idea of using a current syntax in usage examples, to give
>> > > the guide a current look and show that our APIs play well with current
>> > > Java versions (while staying compatible with older ones).
>> > >
>> > >
>> > >
>> > > 2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> > > > +1 for Vlad's proposal to use the same JDK for tests and main code
>> > > > in
>> > > > a given module.
>> > > >
>> > > > Infinispan requires Java8 at runtime too, so that module should be
>> > > > the
>> > > > only one to use Java8?
>> > > >
>> > > > On 12 January 2016 at 07:55, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> > > wrote:
>> > > >> I used Java 8 syntax in the User Guide tests as I remembered that
>> > tests
>> > > can
>> > > >> use it, but I also agree that this is a rather strange move.
>> > > >> Since we need to support Java 1.6, maybe it's a better idea to use
>> > > >> the
>> > > >> latest JDK just in the modules where we have no other choice.
>> > > >> For testing, I think that 1.6 is just fine and I could easily
>> > > >> change
>> > > those
>> > > >> tests to remove the 1.8 dependency.
>> > > >>
>> > > >> So I vote for using the same JDK for both main and test in a
>> > particular
>> > > >> module.
>> > > >>
>> > > >> Vlad
>> > > >>
>> > > >> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole
>> > > >> <steve at hibernate.org
>> > >
>> > > >> wrote:
>> > > >>
>> > > >>> The former.  People commit things that already assume the move to
>> > Java
>> > > 8
>> > > >>> locally to build (and test).  But at the moment we have not
>> > formalized
>> > > >>> that, and so that causes problems when we import into an IDE - the
>> > > imported
>> > > >>> IDE project is built for 1.6 compliance and so everything we try
>> > > >>> in
>> > > the IDE
>> > > >>> fails.
>> > > >>>
>> > > >>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling
>> > > >>> <gunnar at hibernate.org
>> > >
>> > > >>> wrote:
>> > > >>>
>> > > >>> > Hey,
>> > > >>> >
>> > > >>> > > or we move to Java 8 and rely on
>> > > >>> > > AnimalSniffer to make sure we are still compatible.
>> > > >>> >
>> > > >>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's
>> > > >>> > build
>> > > >>> > time, or also at runtime in user apps?
>> > > >>> >
>> > > >>> >
>> > > >>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > > >>> > > The use of Java 8 features in Hibernate ORM is starting to
>> > expand.
>> > > >>> > Luckily
>> > > >>> > > it is still constrained to just tests.
>> > > >>> > >
>> > > >>> > > However these usages make development in an IDE more and more
>> > > >>> difficult.
>> > > >>> > > Previously this was isolated to hibernate-infinispan.  Now[1]
>> > this
>> > > has
>> > > >>> > > crept into hibernate-entitymanager.  We need to have a plan
>> > > >>> > > here.
>> > > >>> Either
>> > > >>> > > we stop using Java 8 anywhere, or we move to Java 8 and rely
>> > > >>> > > on
>> > > >>> > > AnimalSniffer to make sure we are still compatible.
>> > > >>> > >
>> > > >>> > > Votes?  Other options?
>> > > >>> > >
>> > > >>> > > [1]
>> > > >>> > >
>> > > >>> >
>> > > >>>
>> > >
>> >
>> > https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
>> > > >>> > > _______________________________________________
>> > > >>> > > hibernate-dev mailing list
>> > > >>> > > hibernate-dev at lists.jboss.org
>> > > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > >>> >
>> > > >>> _______________________________________________
>> > > >>> hibernate-dev mailing list
>> > > >>> hibernate-dev at lists.jboss.org
>> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > >>>
>> > > >> _______________________________________________
>> > > >> hibernate-dev mailing list
>> > > >> hibernate-dev at lists.jboss.org
>> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > > _______________________________________________
>> > > > hibernate-dev mailing list
>> > > > hibernate-dev at lists.jboss.org
>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Wed Jan 13 09:52:52 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 14:52:52 +0000
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
	<CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
	<CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>
	<CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
Message-ID: <CAFdSV9tAdN5pr46WCjCLbGYK3wjmzjtJhRyb5-OgvQfMj__c9g@mail.gmail.com>

Gunnar, that's very awesome.  You mention being able to include snippets of
an actual source file.  Do you have pointers to an explanation of the
snippets/portion part of that?

On Wed, Jan 13, 2016 at 8:47 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hey Vlad,
>
> slightly related and just in case you are not aware of this feature
> yet: You can include (parts of) actual source code files straight into
> AsciiDoc documents. We do that in the HV reference guide, e.g. at [1].
> That way you are 100% sure your examples actually compile (and pass
> tests) and you don't need to copy & paste them.
>
> Cheers,
>
> --Gunnar
>
> [1]
> https://raw.githubusercontent.com/hibernate/hibernate-validator/master/documentation/src/main/asciidoc/ch11.asciidoc
>
>
> 2016-01-13 15:30 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> > Hi Steve,
> >
> > The User Guide illustrations are snippets of code that go into the extras
> > folder, which stays right next to every chapter.
> > That's in the main folder.
> >
> > The tests are now located in the test folder of the documentation
> folder, so
> > that we can update/evolve them in future.
> > They are also a proof that the code snippets work.
> > There was a time when I realized that an example was not really ok, and I
> > had to change that.
> > I change the test first to see how it worked, and only then I updated the
> > Guide.
> > They are also a form of regression testing, so that we are alerted if
> some
> > future change will break the expectations we made while writing the
> > documentation code snippets.
> >
> > The reader can fork the repo and try them, if he wishes.
> >
> > Vlad
> >
> > On Wed, Jan 13, 2016 at 4:12 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> Vlad, I see you created a PR for moving your new tests out of
> >> hibernate-entitymanager into documentation.  I guess that depends on the
> >> intent.  Are they meant as illustrations?  And if so, how are you
> >> expecting
> >> people will see them?  And if they are meant as real tests rather than
> as
> >> illustrations, I think moving them is not appropriate.
> >>
> >> On Tue, Jan 12, 2016 at 4:57 AM andrea boriero <dreborier at gmail.com>
> >> wrote:
> >>
> >> > I'm not against the use of Java 8 letting AnimalSniffer guarding for
> >> > compatibility,
> >> > but I understand this can cause some problems so I'm ok with removing
> >> > Java
> >> > 8 usage from tests.
> >> >
> >> > On 12 January 2016 at 10:07, Gunnar Morling <gunnar at hibernate.org>
> >> > wrote:
> >> >
> >> > > @Vlad, what Java 8 syntax specifically are you using in the user
> guide
> >> > > tests (examples?)?
> >> > >
> >> > > I like the idea of using a current syntax in usage examples, to give
> >> > > the guide a current look and show that our APIs play well with
> current
> >> > > Java versions (while staying compatible with older ones).
> >> > >
> >> > >
> >> > >
> >> > > 2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> > > > +1 for Vlad's proposal to use the same JDK for tests and main code
> >> > > > in
> >> > > > a given module.
> >> > > >
> >> > > > Infinispan requires Java8 at runtime too, so that module should be
> >> > > > the
> >> > > > only one to use Java8?
> >> > > >
> >> > > > On 12 January 2016 at 07:55, Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >> > > wrote:
> >> > > >> I used Java 8 syntax in the User Guide tests as I remembered that
> >> > tests
> >> > > can
> >> > > >> use it, but I also agree that this is a rather strange move.
> >> > > >> Since we need to support Java 1.6, maybe it's a better idea to
> use
> >> > > >> the
> >> > > >> latest JDK just in the modules where we have no other choice.
> >> > > >> For testing, I think that 1.6 is just fine and I could easily
> >> > > >> change
> >> > > those
> >> > > >> tests to remove the 1.8 dependency.
> >> > > >>
> >> > > >> So I vote for using the same JDK for both main and test in a
> >> > particular
> >> > > >> module.
> >> > > >>
> >> > > >> Vlad
> >> > > >>
> >> > > >> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole
> >> > > >> <steve at hibernate.org
> >> > >
> >> > > >> wrote:
> >> > > >>
> >> > > >>> The former.  People commit things that already assume the move
> to
> >> > Java
> >> > > 8
> >> > > >>> locally to build (and test).  But at the moment we have not
> >> > formalized
> >> > > >>> that, and so that causes problems when we import into an IDE -
> the
> >> > > imported
> >> > > >>> IDE project is built for 1.6 compliance and so everything we try
> >> > > >>> in
> >> > > the IDE
> >> > > >>> fails.
> >> > > >>>
> >> > > >>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling
> >> > > >>> <gunnar at hibernate.org
> >> > >
> >> > > >>> wrote:
> >> > > >>>
> >> > > >>> > Hey,
> >> > > >>> >
> >> > > >>> > > or we move to Java 8 and rely on
> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
> >> > > >>> >
> >> > > >>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's
> >> > > >>> > build
> >> > > >>> > time, or also at runtime in user apps?
> >> > > >>> >
> >> > > >>> >
> >> > > >>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <
> steve at hibernate.org>:
> >> > > >>> > > The use of Java 8 features in Hibernate ORM is starting to
> >> > expand.
> >> > > >>> > Luckily
> >> > > >>> > > it is still constrained to just tests.
> >> > > >>> > >
> >> > > >>> > > However these usages make development in an IDE more and
> more
> >> > > >>> difficult.
> >> > > >>> > > Previously this was isolated to hibernate-infinispan.
> Now[1]
> >> > this
> >> > > has
> >> > > >>> > > crept into hibernate-entitymanager.  We need to have a plan
> >> > > >>> > > here.
> >> > > >>> Either
> >> > > >>> > > we stop using Java 8 anywhere, or we move to Java 8 and rely
> >> > > >>> > > on
> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
> >> > > >>> > >
> >> > > >>> > > Votes?  Other options?
> >> > > >>> > >
> >> > > >>> > > [1]
> >> > > >>> > >
> >> > > >>> >
> >> > > >>>
> >> > >
> >> >
> >> >
> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
> >> > > >>> > > _______________________________________________
> >> > > >>> > > hibernate-dev mailing list
> >> > > >>> > > hibernate-dev at lists.jboss.org
> >> > > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > > >>> >
> >> > > >>> _______________________________________________
> >> > > >>> hibernate-dev mailing list
> >> > > >>> hibernate-dev at lists.jboss.org
> >> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > > >>>
> >> > > >> _______________________________________________
> >> > > >> hibernate-dev mailing list
> >> > > >> hibernate-dev at lists.jboss.org
> >> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > > > _______________________________________________
> >> > > > hibernate-dev mailing list
> >> > > > hibernate-dev at lists.jboss.org
> >> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > > _______________________________________________
> >> > > hibernate-dev mailing list
> >> > > hibernate-dev at lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From mihalcea.vlad at gmail.com  Wed Jan 13 09:54:10 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 13 Jan 2016 16:54:10 +0200
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
	<CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
	<CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>
	<CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
Message-ID: <CA+gWKMBbXy5_zWqTG0c_HSWtYf5W7Yf3S5tXJPinY-2V-tSnmg@mail.gmail.com>

Hi Gunnar,

That's really cool, I didn't know that.
We have the old code snippets as they were copied from the docbook folder
and there are also some new tests that I wrote for the new content.
I could really use this approach for the new snippets.

Vlad

On Wed, Jan 13, 2016 at 4:47 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hey Vlad,
>
> slightly related and just in case you are not aware of this feature
> yet: You can include (parts of) actual source code files straight into
> AsciiDoc documents. We do that in the HV reference guide, e.g. at [1].
> That way you are 100% sure your examples actually compile (and pass
> tests) and you don't need to copy & paste them.
>
> Cheers,
>
> --Gunnar
>
> [1]
> https://raw.githubusercontent.com/hibernate/hibernate-validator/master/documentation/src/main/asciidoc/ch11.asciidoc
>
>
> 2016-01-13 15:30 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> > Hi Steve,
> >
> > The User Guide illustrations are snippets of code that go into the extras
> > folder, which stays right next to every chapter.
> > That's in the main folder.
> >
> > The tests are now located in the test folder of the documentation
> folder, so
> > that we can update/evolve them in future.
> > They are also a proof that the code snippets work.
> > There was a time when I realized that an example was not really ok, and I
> > had to change that.
> > I change the test first to see how it worked, and only then I updated the
> > Guide.
> > They are also a form of regression testing, so that we are alerted if
> some
> > future change will break the expectations we made while writing the
> > documentation code snippets.
> >
> > The reader can fork the repo and try them, if he wishes.
> >
> > Vlad
> >
> > On Wed, Jan 13, 2016 at 4:12 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> Vlad, I see you created a PR for moving your new tests out of
> >> hibernate-entitymanager into documentation.  I guess that depends on the
> >> intent.  Are they meant as illustrations?  And if so, how are you
> >> expecting
> >> people will see them?  And if they are meant as real tests rather than
> as
> >> illustrations, I think moving them is not appropriate.
> >>
> >> On Tue, Jan 12, 2016 at 4:57 AM andrea boriero <dreborier at gmail.com>
> >> wrote:
> >>
> >> > I'm not against the use of Java 8 letting AnimalSniffer guarding for
> >> > compatibility,
> >> > but I understand this can cause some problems so I'm ok with removing
> >> > Java
> >> > 8 usage from tests.
> >> >
> >> > On 12 January 2016 at 10:07, Gunnar Morling <gunnar at hibernate.org>
> >> > wrote:
> >> >
> >> > > @Vlad, what Java 8 syntax specifically are you using in the user
> guide
> >> > > tests (examples?)?
> >> > >
> >> > > I like the idea of using a current syntax in usage examples, to give
> >> > > the guide a current look and show that our APIs play well with
> current
> >> > > Java versions (while staying compatible with older ones).
> >> > >
> >> > >
> >> > >
> >> > > 2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> >> > > > +1 for Vlad's proposal to use the same JDK for tests and main code
> >> > > > in
> >> > > > a given module.
> >> > > >
> >> > > > Infinispan requires Java8 at runtime too, so that module should be
> >> > > > the
> >> > > > only one to use Java8?
> >> > > >
> >> > > > On 12 January 2016 at 07:55, Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >> > > wrote:
> >> > > >> I used Java 8 syntax in the User Guide tests as I remembered that
> >> > tests
> >> > > can
> >> > > >> use it, but I also agree that this is a rather strange move.
> >> > > >> Since we need to support Java 1.6, maybe it's a better idea to
> use
> >> > > >> the
> >> > > >> latest JDK just in the modules where we have no other choice.
> >> > > >> For testing, I think that 1.6 is just fine and I could easily
> >> > > >> change
> >> > > those
> >> > > >> tests to remove the 1.8 dependency.
> >> > > >>
> >> > > >> So I vote for using the same JDK for both main and test in a
> >> > particular
> >> > > >> module.
> >> > > >>
> >> > > >> Vlad
> >> > > >>
> >> > > >> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole
> >> > > >> <steve at hibernate.org
> >> > >
> >> > > >> wrote:
> >> > > >>
> >> > > >>> The former.  People commit things that already assume the move
> to
> >> > Java
> >> > > 8
> >> > > >>> locally to build (and test).  But at the moment we have not
> >> > formalized
> >> > > >>> that, and so that causes problems when we import into an IDE -
> the
> >> > > imported
> >> > > >>> IDE project is built for 1.6 compliance and so everything we try
> >> > > >>> in
> >> > > the IDE
> >> > > >>> fails.
> >> > > >>>
> >> > > >>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling
> >> > > >>> <gunnar at hibernate.org
> >> > >
> >> > > >>> wrote:
> >> > > >>>
> >> > > >>> > Hey,
> >> > > >>> >
> >> > > >>> > > or we move to Java 8 and rely on
> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
> >> > > >>> >
> >> > > >>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's
> >> > > >>> > build
> >> > > >>> > time, or also at runtime in user apps?
> >> > > >>> >
> >> > > >>> >
> >> > > >>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <
> steve at hibernate.org>:
> >> > > >>> > > The use of Java 8 features in Hibernate ORM is starting to
> >> > expand.
> >> > > >>> > Luckily
> >> > > >>> > > it is still constrained to just tests.
> >> > > >>> > >
> >> > > >>> > > However these usages make development in an IDE more and
> more
> >> > > >>> difficult.
> >> > > >>> > > Previously this was isolated to hibernate-infinispan.
> Now[1]
> >> > this
> >> > > has
> >> > > >>> > > crept into hibernate-entitymanager.  We need to have a plan
> >> > > >>> > > here.
> >> > > >>> Either
> >> > > >>> > > we stop using Java 8 anywhere, or we move to Java 8 and rely
> >> > > >>> > > on
> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
> >> > > >>> > >
> >> > > >>> > > Votes?  Other options?
> >> > > >>> > >
> >> > > >>> > > [1]
> >> > > >>> > >
> >> > > >>> >
> >> > > >>>
> >> > >
> >> >
> >> >
> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
> >> > > >>> > > _______________________________________________
> >> > > >>> > > hibernate-dev mailing list
> >> > > >>> > > hibernate-dev at lists.jboss.org
> >> > > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > > >>> >
> >> > > >>> _______________________________________________
> >> > > >>> hibernate-dev mailing list
> >> > > >>> hibernate-dev at lists.jboss.org
> >> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > > >>>
> >> > > >> _______________________________________________
> >> > > >> hibernate-dev mailing list
> >> > > >> hibernate-dev at lists.jboss.org
> >> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > > > _______________________________________________
> >> > > > hibernate-dev mailing list
> >> > > > hibernate-dev at lists.jboss.org
> >> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > > _______________________________________________
> >> > > hibernate-dev mailing list
> >> > > hibernate-dev at lists.jboss.org
> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From mihalcea.vlad at gmail.com  Wed Jan 13 09:57:14 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 13 Jan 2016 16:57:14 +0200
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CAFdSV9tAdN5pr46WCjCLbGYK3wjmzjtJhRyb5-OgvQfMj__c9g@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
	<CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
	<CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>
	<CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
	<CAFdSV9tAdN5pr46WCjCLbGYK3wjmzjtJhRyb5-OgvQfMj__c9g@mail.gmail.com>
Message-ID: <CA+gWKMAoGQBenvV8ZPhRM_fcmK65rL0fq7OBQgkEvJ6jDUyMoA@mail.gmail.com>

This is how you mark an anchor in the source code:


//tag::constraintMapping[]HibernateValidatorConfiguration configuration =
Validation        .byProvider( HibernateValidator.class )
.configure();
ConstraintMapping constraintMapping =
configuration.createConstraintMapping();
constraintMapping    .type( Car.class )        .property( "manufacturer",
FIELD )            .constraint( new NotNullDef() )        .property(
"licensePlate", FIELD )            .ignoreAnnotations()
.constraint( new NotNullDef() )            .constraint( new SizeDef().min(
2 ).max( 14 ) )    .type( RentalCar.class )        .property(
"rentalStation", METHOD )            .constraint( new NotNullDef() );
Validator validator = configuration.addMapping( constraintMapping )
.buildValidatorFactory()        .getValidator();

//end::constraintMapping[]

The start/end comments allow to describe what goes in a snippet.
Now that's another reason for having the tests in the documentation folder.

Vlad


On Wed, Jan 13, 2016 at 4:52 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Gunnar, that's very awesome.  You mention being able to include snippets
> of an actual source file.  Do you have pointers to an explanation of the
> snippets/portion part of that?
>
> On Wed, Jan 13, 2016 at 8:47 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hey Vlad,
>>
>> slightly related and just in case you are not aware of this feature
>> yet: You can include (parts of) actual source code files straight into
>> AsciiDoc documents. We do that in the HV reference guide, e.g. at [1].
>> That way you are 100% sure your examples actually compile (and pass
>> tests) and you don't need to copy & paste them.
>>
>> Cheers,
>>
>> --Gunnar
>>
>> [1]
>> https://raw.githubusercontent.com/hibernate/hibernate-validator/master/documentation/src/main/asciidoc/ch11.asciidoc
>>
>>
>> 2016-01-13 15:30 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>> > Hi Steve,
>> >
>> > The User Guide illustrations are snippets of code that go into the
>> extras
>> > folder, which stays right next to every chapter.
>> > That's in the main folder.
>> >
>> > The tests are now located in the test folder of the documentation
>> folder, so
>> > that we can update/evolve them in future.
>> > They are also a proof that the code snippets work.
>> > There was a time when I realized that an example was not really ok, and
>> I
>> > had to change that.
>> > I change the test first to see how it worked, and only then I updated
>> the
>> > Guide.
>> > They are also a form of regression testing, so that we are alerted if
>> some
>> > future change will break the expectations we made while writing the
>> > documentation code snippets.
>> >
>> > The reader can fork the repo and try them, if he wishes.
>> >
>> > Vlad
>> >
>> > On Wed, Jan 13, 2016 at 4:12 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >>
>> >> Vlad, I see you created a PR for moving your new tests out of
>> >> hibernate-entitymanager into documentation.  I guess that depends on
>> the
>> >> intent.  Are they meant as illustrations?  And if so, how are you
>> >> expecting
>> >> people will see them?  And if they are meant as real tests rather than
>> as
>> >> illustrations, I think moving them is not appropriate.
>> >>
>> >> On Tue, Jan 12, 2016 at 4:57 AM andrea boriero <dreborier at gmail.com>
>> >> wrote:
>> >>
>> >> > I'm not against the use of Java 8 letting AnimalSniffer guarding for
>> >> > compatibility,
>> >> > but I understand this can cause some problems so I'm ok with removing
>> >> > Java
>> >> > 8 usage from tests.
>> >> >
>> >> > On 12 January 2016 at 10:07, Gunnar Morling <gunnar at hibernate.org>
>> >> > wrote:
>> >> >
>> >> > > @Vlad, what Java 8 syntax specifically are you using in the user
>> guide
>> >> > > tests (examples?)?
>> >> > >
>> >> > > I like the idea of using a current syntax in usage examples, to
>> give
>> >> > > the guide a current look and show that our APIs play well with
>> current
>> >> > > Java versions (while staying compatible with older ones).
>> >> > >
>> >> > >
>> >> > >
>> >> > > 2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> >> > > > +1 for Vlad's proposal to use the same JDK for tests and main
>> code
>> >> > > > in
>> >> > > > a given module.
>> >> > > >
>> >> > > > Infinispan requires Java8 at runtime too, so that module should
>> be
>> >> > > > the
>> >> > > > only one to use Java8?
>> >> > > >
>> >> > > > On 12 January 2016 at 07:55, Vlad Mihalcea <
>> mihalcea.vlad at gmail.com>
>> >> > > wrote:
>> >> > > >> I used Java 8 syntax in the User Guide tests as I remembered
>> that
>> >> > tests
>> >> > > can
>> >> > > >> use it, but I also agree that this is a rather strange move.
>> >> > > >> Since we need to support Java 1.6, maybe it's a better idea to
>> use
>> >> > > >> the
>> >> > > >> latest JDK just in the modules where we have no other choice.
>> >> > > >> For testing, I think that 1.6 is just fine and I could easily
>> >> > > >> change
>> >> > > those
>> >> > > >> tests to remove the 1.8 dependency.
>> >> > > >>
>> >> > > >> So I vote for using the same JDK for both main and test in a
>> >> > particular
>> >> > > >> module.
>> >> > > >>
>> >> > > >> Vlad
>> >> > > >>
>> >> > > >> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole
>> >> > > >> <steve at hibernate.org
>> >> > >
>> >> > > >> wrote:
>> >> > > >>
>> >> > > >>> The former.  People commit things that already assume the move
>> to
>> >> > Java
>> >> > > 8
>> >> > > >>> locally to build (and test).  But at the moment we have not
>> >> > formalized
>> >> > > >>> that, and so that causes problems when we import into an IDE -
>> the
>> >> > > imported
>> >> > > >>> IDE project is built for 1.6 compliance and so everything we
>> try
>> >> > > >>> in
>> >> > > the IDE
>> >> > > >>> fails.
>> >> > > >>>
>> >> > > >>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling
>> >> > > >>> <gunnar at hibernate.org
>> >> > >
>> >> > > >>> wrote:
>> >> > > >>>
>> >> > > >>> > Hey,
>> >> > > >>> >
>> >> > > >>> > > or we move to Java 8 and rely on
>> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
>> >> > > >>> >
>> >> > > >>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's
>> >> > > >>> > build
>> >> > > >>> > time, or also at runtime in user apps?
>> >> > > >>> >
>> >> > > >>> >
>> >> > > >>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <
>> steve at hibernate.org>:
>> >> > > >>> > > The use of Java 8 features in Hibernate ORM is starting to
>> >> > expand.
>> >> > > >>> > Luckily
>> >> > > >>> > > it is still constrained to just tests.
>> >> > > >>> > >
>> >> > > >>> > > However these usages make development in an IDE more and
>> more
>> >> > > >>> difficult.
>> >> > > >>> > > Previously this was isolated to hibernate-infinispan.
>> Now[1]
>> >> > this
>> >> > > has
>> >> > > >>> > > crept into hibernate-entitymanager.  We need to have a plan
>> >> > > >>> > > here.
>> >> > > >>> Either
>> >> > > >>> > > we stop using Java 8 anywhere, or we move to Java 8 and
>> rely
>> >> > > >>> > > on
>> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
>> >> > > >>> > >
>> >> > > >>> > > Votes?  Other options?
>> >> > > >>> > >
>> >> > > >>> > > [1]
>> >> > > >>> > >
>> >> > > >>> >
>> >> > > >>>
>> >> > >
>> >> >
>> >> >
>> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
>> >> > > >>> > > _______________________________________________
>> >> > > >>> > > hibernate-dev mailing list
>> >> > > >>> > > hibernate-dev at lists.jboss.org
>> >> > > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > > >>> >
>> >> > > >>> _______________________________________________
>> >> > > >>> hibernate-dev mailing list
>> >> > > >>> hibernate-dev at lists.jboss.org
>> >> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > > >>>
>> >> > > >> _______________________________________________
>> >> > > >> hibernate-dev mailing list
>> >> > > >> hibernate-dev at lists.jboss.org
>> >> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > > > _______________________________________________
>> >> > > > hibernate-dev mailing list
>> >> > > > hibernate-dev at lists.jboss.org
>> >> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > > _______________________________________________
>> >> > > hibernate-dev mailing list
>> >> > > hibernate-dev at lists.jboss.org
>> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > >
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>>
>

From gunnar at hibernate.org  Wed Jan 13 10:07:00 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 13 Jan 2016 16:07:00 +0100
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CA+gWKMAoGQBenvV8ZPhRM_fcmK65rL0fq7OBQgkEvJ6jDUyMoA@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
	<CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
	<CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>
	<CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
	<CAFdSV9tAdN5pr46WCjCLbGYK3wjmzjtJhRyb5-OgvQfMj__c9g@mail.gmail.com>
	<CA+gWKMAoGQBenvV8ZPhRM_fcmK65rL0fq7OBQgkEvJ6jDUyMoA@mail.gmail.com>
Message-ID: <CADGJaX-WOuiFZ8FnYm86r8=g0pGY9UPpjCVyHPZgqoFgrwhwzg@mail.gmail.com>

Right; you also can use the same tag several times if you want several
distinct snippets from a file to end up in one listing in the docs:
https://github.com/hibernate/hibernate-validator/blob/master/documentation/src/test/java/org/hibernate/validator/referenceguide/chapter11/failfast/Car.java
.

The usage in the docs is like so:
https://github.com/hibernate/hibernate-validator/blame/master/documentation/src/main/asciidoc/ch11.asciidoc#L206..L213
.

I am very happy with this in general, the only (minor) downside is that it
naturally adds a bit of build time for compiling/testing the source. But I
think it's well spent and of course one can skip it for quick docs
rendering during authoring.


2016-01-13 15:57 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:

> This is how you mark an anchor in the source code:
>
>
> //tag::constraintMapping[]HibernateValidatorConfiguration configuration =
> Validation        .byProvider( HibernateValidator.class )
> .configure();
> ConstraintMapping constraintMapping =
> configuration.createConstraintMapping();
> constraintMapping    .type( Car.class )        .property( "manufacturer",
> FIELD )            .constraint( new NotNullDef() )        .property(
> "licensePlate", FIELD )            .ignoreAnnotations()
> .constraint( new NotNullDef() )            .constraint( new
> SizeDef().min( 2 ).max( 14 ) )    .type( RentalCar.class )
> .property( "rentalStation", METHOD )            .constraint( new
> NotNullDef() );
> Validator validator = configuration.addMapping( constraintMapping )
>   .buildValidatorFactory()        .getValidator();
>
> //end::constraintMapping[]
>
> The start/end comments allow to describe what goes in a snippet.
> Now that's another reason for having the tests in the documentation folder.
>
> Vlad
>
>
> On Wed, Jan 13, 2016 at 4:52 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Gunnar, that's very awesome.  You mention being able to include snippets
>> of an actual source file.  Do you have pointers to an explanation of the
>> snippets/portion part of that?
>>
>> On Wed, Jan 13, 2016 at 8:47 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>
>>> Hey Vlad,
>>>
>>> slightly related and just in case you are not aware of this feature
>>> yet: You can include (parts of) actual source code files straight into
>>> AsciiDoc documents. We do that in the HV reference guide, e.g. at [1].
>>> That way you are 100% sure your examples actually compile (and pass
>>> tests) and you don't need to copy & paste them.
>>>
>>> Cheers,
>>>
>>> --Gunnar
>>>
>>> [1]
>>> https://raw.githubusercontent.com/hibernate/hibernate-validator/master/documentation/src/main/asciidoc/ch11.asciidoc
>>>
>>>
>>> 2016-01-13 15:30 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>>> > Hi Steve,
>>> >
>>> > The User Guide illustrations are snippets of code that go into the
>>> extras
>>> > folder, which stays right next to every chapter.
>>> > That's in the main folder.
>>> >
>>> > The tests are now located in the test folder of the documentation
>>> folder, so
>>> > that we can update/evolve them in future.
>>> > They are also a proof that the code snippets work.
>>> > There was a time when I realized that an example was not really ok,
>>> and I
>>> > had to change that.
>>> > I change the test first to see how it worked, and only then I updated
>>> the
>>> > Guide.
>>> > They are also a form of regression testing, so that we are alerted if
>>> some
>>> > future change will break the expectations we made while writing the
>>> > documentation code snippets.
>>> >
>>> > The reader can fork the repo and try them, if he wishes.
>>> >
>>> > Vlad
>>> >
>>> > On Wed, Jan 13, 2016 at 4:12 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>> >>
>>> >> Vlad, I see you created a PR for moving your new tests out of
>>> >> hibernate-entitymanager into documentation.  I guess that depends on
>>> the
>>> >> intent.  Are they meant as illustrations?  And if so, how are you
>>> >> expecting
>>> >> people will see them?  And if they are meant as real tests rather
>>> than as
>>> >> illustrations, I think moving them is not appropriate.
>>> >>
>>> >> On Tue, Jan 12, 2016 at 4:57 AM andrea boriero <dreborier at gmail.com>
>>> >> wrote:
>>> >>
>>> >> > I'm not against the use of Java 8 letting AnimalSniffer guarding for
>>> >> > compatibility,
>>> >> > but I understand this can cause some problems so I'm ok with
>>> removing
>>> >> > Java
>>> >> > 8 usage from tests.
>>> >> >
>>> >> > On 12 January 2016 at 10:07, Gunnar Morling <gunnar at hibernate.org>
>>> >> > wrote:
>>> >> >
>>> >> > > @Vlad, what Java 8 syntax specifically are you using in the user
>>> guide
>>> >> > > tests (examples?)?
>>> >> > >
>>> >> > > I like the idea of using a current syntax in usage examples, to
>>> give
>>> >> > > the guide a current look and show that our APIs play well with
>>> current
>>> >> > > Java versions (while staying compatible with older ones).
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > 2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> >> > > > +1 for Vlad's proposal to use the same JDK for tests and main
>>> code
>>> >> > > > in
>>> >> > > > a given module.
>>> >> > > >
>>> >> > > > Infinispan requires Java8 at runtime too, so that module should
>>> be
>>> >> > > > the
>>> >> > > > only one to use Java8?
>>> >> > > >
>>> >> > > > On 12 January 2016 at 07:55, Vlad Mihalcea <
>>> mihalcea.vlad at gmail.com>
>>> >> > > wrote:
>>> >> > > >> I used Java 8 syntax in the User Guide tests as I remembered
>>> that
>>> >> > tests
>>> >> > > can
>>> >> > > >> use it, but I also agree that this is a rather strange move.
>>> >> > > >> Since we need to support Java 1.6, maybe it's a better idea to
>>> use
>>> >> > > >> the
>>> >> > > >> latest JDK just in the modules where we have no other choice.
>>> >> > > >> For testing, I think that 1.6 is just fine and I could easily
>>> >> > > >> change
>>> >> > > those
>>> >> > > >> tests to remove the 1.8 dependency.
>>> >> > > >>
>>> >> > > >> So I vote for using the same JDK for both main and test in a
>>> >> > particular
>>> >> > > >> module.
>>> >> > > >>
>>> >> > > >> Vlad
>>> >> > > >>
>>> >> > > >> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole
>>> >> > > >> <steve at hibernate.org
>>> >> > >
>>> >> > > >> wrote:
>>> >> > > >>
>>> >> > > >>> The former.  People commit things that already assume the
>>> move to
>>> >> > Java
>>> >> > > 8
>>> >> > > >>> locally to build (and test).  But at the moment we have not
>>> >> > formalized
>>> >> > > >>> that, and so that causes problems when we import into an IDE
>>> - the
>>> >> > > imported
>>> >> > > >>> IDE project is built for 1.6 compliance and so everything we
>>> try
>>> >> > > >>> in
>>> >> > > the IDE
>>> >> > > >>> fails.
>>> >> > > >>>
>>> >> > > >>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling
>>> >> > > >>> <gunnar at hibernate.org
>>> >> > >
>>> >> > > >>> wrote:
>>> >> > > >>>
>>> >> > > >>> > Hey,
>>> >> > > >>> >
>>> >> > > >>> > > or we move to Java 8 and rely on
>>> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
>>> >> > > >>> >
>>> >> > > >>> > WDYM by "move to Java8" exactly? Requiring it at Hibernate's
>>> >> > > >>> > build
>>> >> > > >>> > time, or also at runtime in user apps?
>>> >> > > >>> >
>>> >> > > >>> >
>>> >> > > >>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <
>>> steve at hibernate.org>:
>>> >> > > >>> > > The use of Java 8 features in Hibernate ORM is starting to
>>> >> > expand.
>>> >> > > >>> > Luckily
>>> >> > > >>> > > it is still constrained to just tests.
>>> >> > > >>> > >
>>> >> > > >>> > > However these usages make development in an IDE more and
>>> more
>>> >> > > >>> difficult.
>>> >> > > >>> > > Previously this was isolated to hibernate-infinispan.
>>> Now[1]
>>> >> > this
>>> >> > > has
>>> >> > > >>> > > crept into hibernate-entitymanager.  We need to have a
>>> plan
>>> >> > > >>> > > here.
>>> >> > > >>> Either
>>> >> > > >>> > > we stop using Java 8 anywhere, or we move to Java 8 and
>>> rely
>>> >> > > >>> > > on
>>> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
>>> >> > > >>> > >
>>> >> > > >>> > > Votes?  Other options?
>>> >> > > >>> > >
>>> >> > > >>> > > [1]
>>> >> > > >>> > >
>>> >> > > >>> >
>>> >> > > >>>
>>> >> > >
>>> >> >
>>> >> >
>>> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
>>> >> > > >>> > > _______________________________________________
>>> >> > > >>> > > hibernate-dev mailing list
>>> >> > > >>> > > hibernate-dev at lists.jboss.org
>>> >> > > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> > > >>> >
>>> >> > > >>> _______________________________________________
>>> >> > > >>> hibernate-dev mailing list
>>> >> > > >>> hibernate-dev at lists.jboss.org
>>> >> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> > > >>>
>>> >> > > >> _______________________________________________
>>> >> > > >> hibernate-dev mailing list
>>> >> > > >> hibernate-dev at lists.jboss.org
>>> >> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> > > > _______________________________________________
>>> >> > > > hibernate-dev mailing list
>>> >> > > > hibernate-dev at lists.jboss.org
>>> >> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> > > _______________________________________________
>>> >> > > hibernate-dev mailing list
>>> >> > > hibernate-dev at lists.jboss.org
>>> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> > >
>>> >> > _______________________________________________
>>> >> > hibernate-dev mailing list
>>> >> > hibernate-dev at lists.jboss.org
>>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >> >
>>> >> _______________________________________________
>>> >> hibernate-dev mailing list
>>> >> hibernate-dev at lists.jboss.org
>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> >
>>>
>>
>

From mihalcea.vlad at gmail.com  Wed Jan 13 10:11:10 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 13 Jan 2016 17:11:10 +0200
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CADGJaX-WOuiFZ8FnYm86r8=g0pGY9UPpjCVyHPZgqoFgrwhwzg@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
	<CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
	<CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>
	<CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
	<CAFdSV9tAdN5pr46WCjCLbGYK3wjmzjtJhRyb5-OgvQfMj__c9g@mail.gmail.com>
	<CA+gWKMAoGQBenvV8ZPhRM_fcmK65rL0fq7OBQgkEvJ6jDUyMoA@mail.gmail.com>
	<CADGJaX-WOuiFZ8FnYm86r8=g0pGY9UPpjCVyHPZgqoFgrwhwzg@mail.gmail.com>
Message-ID: <CA+gWKMDbXocsSTOAYq3hJut93V10WmabDa6yqknUknU5VXBTew@mail.gmail.com>

It's quite flexible.
I'll have to use it as soon as we agree with the tests that were moved into
the doc folder.

Vlad

On Wed, Jan 13, 2016 at 5:07 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Right; you also can use the same tag several times if you want several
> distinct snippets from a file to end up in one listing in the docs:
>
> https://github.com/hibernate/hibernate-validator/blob/master/documentation/src/test/java/org/hibernate/validator/referenceguide/chapter11/failfast/Car.java
> .
>
> The usage in the docs is like so:
> https://github.com/hibernate/hibernate-validator/blame/master/documentation/src/main/asciidoc/ch11.asciidoc#L206..L213
> .
>
> I am very happy with this in general, the only (minor) downside is that it
> naturally adds a bit of build time for compiling/testing the source. But I
> think it's well spent and of course one can skip it for quick docs
> rendering during authoring.
>
>
> 2016-01-13 15:57 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>
>> This is how you mark an anchor in the source code:
>>
>>
>> //tag::constraintMapping[]HibernateValidatorConfiguration configuration
>> = Validation        .byProvider( HibernateValidator.class )
>> .configure();
>> ConstraintMapping constraintMapping =
>> configuration.createConstraintMapping();
>> constraintMapping    .type( Car.class )        .property(
>> "manufacturer", FIELD )            .constraint( new NotNullDef() )
>>   .property( "licensePlate", FIELD )            .ignoreAnnotations()
>>         .constraint( new NotNullDef() )            .constraint( new
>> SizeDef().min( 2 ).max( 14 ) )    .type( RentalCar.class )
>> .property( "rentalStation", METHOD )            .constraint( new
>> NotNullDef() );
>> Validator validator = configuration.addMapping( constraintMapping )
>>   .buildValidatorFactory()        .getValidator();
>>
>> //end::constraintMapping[]
>>
>> The start/end comments allow to describe what goes in a snippet.
>> Now that's another reason for having the tests in the documentation
>> folder.
>>
>> Vlad
>>
>>
>> On Wed, Jan 13, 2016 at 4:52 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Gunnar, that's very awesome.  You mention being able to include snippets
>>> of an actual source file.  Do you have pointers to an explanation of the
>>> snippets/portion part of that?
>>>
>>> On Wed, Jan 13, 2016 at 8:47 AM Gunnar Morling <gunnar at hibernate.org>
>>> wrote:
>>>
>>>> Hey Vlad,
>>>>
>>>> slightly related and just in case you are not aware of this feature
>>>> yet: You can include (parts of) actual source code files straight into
>>>> AsciiDoc documents. We do that in the HV reference guide, e.g. at [1].
>>>> That way you are 100% sure your examples actually compile (and pass
>>>> tests) and you don't need to copy & paste them.
>>>>
>>>> Cheers,
>>>>
>>>> --Gunnar
>>>>
>>>> [1]
>>>> https://raw.githubusercontent.com/hibernate/hibernate-validator/master/documentation/src/main/asciidoc/ch11.asciidoc
>>>>
>>>>
>>>> 2016-01-13 15:30 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
>>>> > Hi Steve,
>>>> >
>>>> > The User Guide illustrations are snippets of code that go into the
>>>> extras
>>>> > folder, which stays right next to every chapter.
>>>> > That's in the main folder.
>>>> >
>>>> > The tests are now located in the test folder of the documentation
>>>> folder, so
>>>> > that we can update/evolve them in future.
>>>> > They are also a proof that the code snippets work.
>>>> > There was a time when I realized that an example was not really ok,
>>>> and I
>>>> > had to change that.
>>>> > I change the test first to see how it worked, and only then I updated
>>>> the
>>>> > Guide.
>>>> > They are also a form of regression testing, so that we are alerted if
>>>> some
>>>> > future change will break the expectations we made while writing the
>>>> > documentation code snippets.
>>>> >
>>>> > The reader can fork the repo and try them, if he wishes.
>>>> >
>>>> > Vlad
>>>> >
>>>> > On Wed, Jan 13, 2016 at 4:12 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>> >>
>>>> >> Vlad, I see you created a PR for moving your new tests out of
>>>> >> hibernate-entitymanager into documentation.  I guess that depends on
>>>> the
>>>> >> intent.  Are they meant as illustrations?  And if so, how are you
>>>> >> expecting
>>>> >> people will see them?  And if they are meant as real tests rather
>>>> than as
>>>> >> illustrations, I think moving them is not appropriate.
>>>> >>
>>>> >> On Tue, Jan 12, 2016 at 4:57 AM andrea boriero <dreborier at gmail.com>
>>>> >> wrote:
>>>> >>
>>>> >> > I'm not against the use of Java 8 letting AnimalSniffer guarding
>>>> for
>>>> >> > compatibility,
>>>> >> > but I understand this can cause some problems so I'm ok with
>>>> removing
>>>> >> > Java
>>>> >> > 8 usage from tests.
>>>> >> >
>>>> >> > On 12 January 2016 at 10:07, Gunnar Morling <gunnar at hibernate.org>
>>>> >> > wrote:
>>>> >> >
>>>> >> > > @Vlad, what Java 8 syntax specifically are you using in the user
>>>> guide
>>>> >> > > tests (examples?)?
>>>> >> > >
>>>> >> > > I like the idea of using a current syntax in usage examples, to
>>>> give
>>>> >> > > the guide a current look and show that our APIs play well with
>>>> current
>>>> >> > > Java versions (while staying compatible with older ones).
>>>> >> > >
>>>> >> > >
>>>> >> > >
>>>> >> > > 2016-01-12 10:51 GMT+01:00 Sanne Grinovero <sanne at hibernate.org
>>>> >:
>>>> >> > > > +1 for Vlad's proposal to use the same JDK for tests and main
>>>> code
>>>> >> > > > in
>>>> >> > > > a given module.
>>>> >> > > >
>>>> >> > > > Infinispan requires Java8 at runtime too, so that module
>>>> should be
>>>> >> > > > the
>>>> >> > > > only one to use Java8?
>>>> >> > > >
>>>> >> > > > On 12 January 2016 at 07:55, Vlad Mihalcea <
>>>> mihalcea.vlad at gmail.com>
>>>> >> > > wrote:
>>>> >> > > >> I used Java 8 syntax in the User Guide tests as I remembered
>>>> that
>>>> >> > tests
>>>> >> > > can
>>>> >> > > >> use it, but I also agree that this is a rather strange move.
>>>> >> > > >> Since we need to support Java 1.6, maybe it's a better idea
>>>> to use
>>>> >> > > >> the
>>>> >> > > >> latest JDK just in the modules where we have no other choice.
>>>> >> > > >> For testing, I think that 1.6 is just fine and I could easily
>>>> >> > > >> change
>>>> >> > > those
>>>> >> > > >> tests to remove the 1.8 dependency.
>>>> >> > > >>
>>>> >> > > >> So I vote for using the same JDK for both main and test in a
>>>> >> > particular
>>>> >> > > >> module.
>>>> >> > > >>
>>>> >> > > >> Vlad
>>>> >> > > >>
>>>> >> > > >> On Mon, Jan 11, 2016 at 11:35 PM, Steve Ebersole
>>>> >> > > >> <steve at hibernate.org
>>>> >> > >
>>>> >> > > >> wrote:
>>>> >> > > >>
>>>> >> > > >>> The former.  People commit things that already assume the
>>>> move to
>>>> >> > Java
>>>> >> > > 8
>>>> >> > > >>> locally to build (and test).  But at the moment we have not
>>>> >> > formalized
>>>> >> > > >>> that, and so that causes problems when we import into an IDE
>>>> - the
>>>> >> > > imported
>>>> >> > > >>> IDE project is built for 1.6 compliance and so everything we
>>>> try
>>>> >> > > >>> in
>>>> >> > > the IDE
>>>> >> > > >>> fails.
>>>> >> > > >>>
>>>> >> > > >>> On Mon, Jan 11, 2016 at 3:33 PM Gunnar Morling
>>>> >> > > >>> <gunnar at hibernate.org
>>>> >> > >
>>>> >> > > >>> wrote:
>>>> >> > > >>>
>>>> >> > > >>> > Hey,
>>>> >> > > >>> >
>>>> >> > > >>> > > or we move to Java 8 and rely on
>>>> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
>>>> >> > > >>> >
>>>> >> > > >>> > WDYM by "move to Java8" exactly? Requiring it at
>>>> Hibernate's
>>>> >> > > >>> > build
>>>> >> > > >>> > time, or also at runtime in user apps?
>>>> >> > > >>> >
>>>> >> > > >>> >
>>>> >> > > >>> > 2016-01-11 19:49 GMT+01:00 Steve Ebersole <
>>>> steve at hibernate.org>:
>>>> >> > > >>> > > The use of Java 8 features in Hibernate ORM is starting
>>>> to
>>>> >> > expand.
>>>> >> > > >>> > Luckily
>>>> >> > > >>> > > it is still constrained to just tests.
>>>> >> > > >>> > >
>>>> >> > > >>> > > However these usages make development in an IDE more and
>>>> more
>>>> >> > > >>> difficult.
>>>> >> > > >>> > > Previously this was isolated to hibernate-infinispan.
>>>> Now[1]
>>>> >> > this
>>>> >> > > has
>>>> >> > > >>> > > crept into hibernate-entitymanager.  We need to have a
>>>> plan
>>>> >> > > >>> > > here.
>>>> >> > > >>> Either
>>>> >> > > >>> > > we stop using Java 8 anywhere, or we move to Java 8 and
>>>> rely
>>>> >> > > >>> > > on
>>>> >> > > >>> > > AnimalSniffer to make sure we are still compatible.
>>>> >> > > >>> > >
>>>> >> > > >>> > > Votes?  Other options?
>>>> >> > > >>> > >
>>>> >> > > >>> > > [1]
>>>> >> > > >>> > >
>>>> >> > > >>> >
>>>> >> > > >>>
>>>> >> > >
>>>> >> >
>>>> >> >
>>>> https://github.com/hibernate/hibernate-orm/commit/c2ece0108ed52d5e3a227ed0150cfb5cb1a76101
>>>> >> > > >>> > > _______________________________________________
>>>> >> > > >>> > > hibernate-dev mailing list
>>>> >> > > >>> > > hibernate-dev at lists.jboss.org
>>>> >> > > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >> > > >>> >
>>>> >> > > >>> _______________________________________________
>>>> >> > > >>> hibernate-dev mailing list
>>>> >> > > >>> hibernate-dev at lists.jboss.org
>>>> >> > > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >> > > >>>
>>>> >> > > >> _______________________________________________
>>>> >> > > >> hibernate-dev mailing list
>>>> >> > > >> hibernate-dev at lists.jboss.org
>>>> >> > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >> > > > _______________________________________________
>>>> >> > > > hibernate-dev mailing list
>>>> >> > > > hibernate-dev at lists.jboss.org
>>>> >> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >> > > _______________________________________________
>>>> >> > > hibernate-dev mailing list
>>>> >> > > hibernate-dev at lists.jboss.org
>>>> >> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >> > >
>>>> >> > _______________________________________________
>>>> >> > hibernate-dev mailing list
>>>> >> > hibernate-dev at lists.jboss.org
>>>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >> >
>>>> >> _______________________________________________
>>>> >> hibernate-dev mailing list
>>>> >> hibernate-dev at lists.jboss.org
>>>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >
>>>> >
>>>>
>>>
>>
>

From hardy at hibernate.org  Wed Jan 13 11:32:05 2016
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 13 Jan 2016 17:32:05 +0100
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
	<CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
	<CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>
	<CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
Message-ID: <20160113163205.GE6750@Nineveh.local>

Hi,

> slightly related and just in case you are not aware of this feature
> yet: You can include (parts of) actual source code files straight into
> AsciiDoc documents. We do that in the HV reference guide, e.g. at [1].
> That way you are 100% sure your examples actually compile (and pass
> tests) and you don't need to copy & paste them.

Damn you beat me to it, I just wanted to write the same thing :-)
To me, this is the best approach. By using actual test which run as part of
the documentation build you know that your examples really work and via
the include syntax you can include the bits and pieces you need into the docs.
Obviously more effort, but I think worth it. IMO examples in the docs should be
as much as possible sourced from actual running tests. 

BTW, this is pretty much what Christian always wanted as part of 
this docbook tooling. Not sure whether he ever completed his tool to achieve this.

--Hardy

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

From steve at hibernate.org  Wed Jan 13 11:38:07 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 16:38:07 +0000
Subject: [hibernate-dev] Hibernate ORM and Java 8 usage
In-Reply-To: <20160113163205.GE6750@Nineveh.local>
References: <CAFdSV9tVH76bpfpo1QbELULEywC3rC20FA0p4FpTaPRLqHRRrQ@mail.gmail.com>
	<CADGJaX_i5J4h+kEF3RmFOW3nKPVt9o8tNFrmctJD7D+TZ1emsg@mail.gmail.com>
	<CAFdSV9sigJJGeT7LfBvkGq=e+SLTD3=51a_hjzeW7BtQyXSSAw@mail.gmail.com>
	<CA+gWKMAAj9CQrQChqCLkp_WXU0u-ut6WcJW7tcUzm50urP96kg@mail.gmail.com>
	<CAFm4XO1BvzphzmazwiSgX6K+HcSmY+S=m=zn1pm_83-kq2NQXA@mail.gmail.com>
	<CADGJaX-5_A0JEgAvAt0bu1ezZVOB96h8tki=YhCJCKgh9M=p-A@mail.gmail.com>
	<CAL00eSSLNSXf--H1L7zSNEke4LBWXynWVtWFprY9KG73dACz7g@mail.gmail.com>
	<CAFdSV9stoHKGdbWzCzU_+un_HBZxwF60zM0XAgRiiahyAPjSAA@mail.gmail.com>
	<CA+gWKMA9B6mhYsXnevrs7qtiByHCSsyJAfNBFGcwezf=XQpMwg@mail.gmail.com>
	<CADGJaX8YDt=VNeon3KgAJOc8x11tBcMT-zB+GN3n30-=D-DMtQ@mail.gmail.com>
	<20160113163205.GE6750@Nineveh.local>
Message-ID: <CAFdSV9uYDNxYBb--pwmQ9PmGEym6oa114Mhd8b+HkjHO8RYCbA@mail.gmail.com>

I agree completely with this.

And yes he did, but then we are moving to Asciidoc :)



On Wed, Jan 13, 2016 at 10:32 AM Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> > slightly related and just in case you are not aware of this feature
> > yet: You can include (parts of) actual source code files straight into
> > AsciiDoc documents. We do that in the HV reference guide, e.g. at [1].
> > That way you are 100% sure your examples actually compile (and pass
> > tests) and you don't need to copy & paste them.
>
> Damn you beat me to it, I just wanted to write the same thing :-)
> To me, this is the best approach. By using actual test which run as part of
> the documentation build you know that your examples really work and via
> the include syntax you can include the bits and pieces you need into the
> docs.
> Obviously more effort, but I think worth it. IMO examples in the docs
> should be
> as much as possible sourced from actual running tests.
>
> BTW, this is pretty much what Christian always wanted as part of
> this docbook tooling. Not sure whether he ever completed his tool to
> achieve this.
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Jan 13 14:26:40 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 19:26:40 +0000
Subject: [hibernate-dev] staging Blog site
Message-ID: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>

Trying to push and verify my announcement blog post for 5.0.7 release, but
Jenkins fails to build it[1].  Apparently command `rake` not found.

So what now?

[1] - http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/

From sanne at hibernate.org  Wed Jan 13 14:32:16 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 13 Jan 2016 19:32:16 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
Message-ID: <CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>

Could you try again now please?

On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org> wrote:
> Trying to push and verify my announcement blog post for 5.0.7 release, but
> Jenkins fails to build it[1].  Apparently command `rake` not found.
>
> So what now?
>
> [1] - http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Wed Jan 13 14:45:39 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 19:45:39 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
	<CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
Message-ID: <CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>

Whatever you did seems to have done the trick:
http://ci.hibernate.org/view/Website/job/staging.in.relation.to/146/

Thanks


On Wed, Jan 13, 2016 at 1:32 PM Sanne Grinovero <sanne at hibernate.org> wrote:

> Could you try again now please?
>
> On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org> wrote:
> > Trying to push and verify my announcement blog post for 5.0.7 release,
> but
> > Jenkins fails to build it[1].  Apparently command `rake` not found.
> >
> > So what now?
> >
> > [1] -
> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jan 13 14:50:51 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 19:50:51 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
	<CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
Message-ID: <CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>

Sorry, spoke too soon...

RROR: Running Awestruct failed.
/mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:104:in
`run_awestruct'
/mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:71:in
`block in <top (required)>'
Tasks: TOP => gen
(See full trace by running task with --trace)



On Wed, Jan 13, 2016 at 1:45 PM Steve Ebersole <steve at hibernate.org> wrote:

> Whatever you did seems to have done the trick:
> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/146/
>
> Thanks
>
>
> On Wed, Jan 13, 2016 at 1:32 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Could you try again now please?
>>
>> On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org> wrote:
>> > Trying to push and verify my announcement blog post for 5.0.7 release,
>> but
>> > Jenkins fails to build it[1].  Apparently command `rake` not found.
>> >
>> > So what now?
>> >
>> > [1] -
>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Jan 13 15:17:17 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 20:17:17 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
	<CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
Message-ID: <CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>

Per Hardy this might be due to a bad post uploaded to staging by Max.  I
just deleted that file from staging and am trying build again

On Wed, Jan 13, 2016 at 1:50 PM Steve Ebersole <steve at hibernate.org> wrote:

> Sorry, spoke too soon...
>
> RROR: Running Awestruct failed.
> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:104:in `run_awestruct'
> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:71:in `block in <top (required)>'
> Tasks: TOP => gen
> (See full trace by running task with --trace)
>
>
>
> On Wed, Jan 13, 2016 at 1:45 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Whatever you did seems to have done the trick:
>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/146/
>>
>> Thanks
>>
>>
>> On Wed, Jan 13, 2016 at 1:32 PM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> Could you try again now please?
>>>
>>> On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org> wrote:
>>> > Trying to push and verify my announcement blog post for 5.0.7 release,
>>> but
>>> > Jenkins fails to build it[1].  Apparently command `rake` not found.
>>> >
>>> > So what now?
>>> >
>>> > [1] -
>>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>

From steve at hibernate.org  Wed Jan 13 15:22:08 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 20:22:08 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
	<CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
Message-ID: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>

Ok, that fixed this last problem

On Wed, Jan 13, 2016 at 2:17 PM Steve Ebersole <steve at hibernate.org> wrote:

> Per Hardy this might be due to a bad post uploaded to staging by Max.  I
> just deleted that file from staging and am trying build again
>
> On Wed, Jan 13, 2016 at 1:50 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Sorry, spoke too soon...
>>
>> RROR: Running Awestruct failed.
>> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:104:in `run_awestruct'
>> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:71:in `block in <top (required)>'
>> Tasks: TOP => gen
>> (See full trace by running task with --trace)
>>
>>
>>
>> On Wed, Jan 13, 2016 at 1:45 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Whatever you did seems to have done the trick:
>>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/146/
>>>
>>> Thanks
>>>
>>>
>>> On Wed, Jan 13, 2016 at 1:32 PM Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>
>>>> Could you try again now please?
>>>>
>>>> On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>> > Trying to push and verify my announcement blog post for 5.0.7
>>>> release, but
>>>> > Jenkins fails to build it[1].  Apparently command `rake` not found.
>>>> >
>>>> > So what now?
>>>> >
>>>> > [1] -
>>>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
>>>> > _______________________________________________
>>>> > hibernate-dev mailing list
>>>> > hibernate-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>

From dreborier at gmail.com  Wed Jan 13 15:33:40 2016
From: dreborier at gmail.com (andrea boriero)
Date: Wed, 13 Jan 2016 20:33:40 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
	<CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
Message-ID: <CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>

the problem seems related with the file name

/2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v..erb

instead of

/2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v.*html*
.erb

On 13 January 2016 at 20:22, Steve Ebersole <steve at hibernate.org> wrote:

> Ok, that fixed this last problem
>
> On Wed, Jan 13, 2016 at 2:17 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > Per Hardy this might be due to a bad post uploaded to staging by Max.  I
> > just deleted that file from staging and am trying build again
> >
> > On Wed, Jan 13, 2016 at 1:50 PM Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> Sorry, spoke too soon...
> >>
> >> RROR: Running Awestruct failed.
> >> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:104:in
> `run_awestruct'
> >> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:71:in
> `block in <top (required)>'
> >> Tasks: TOP => gen
> >> (See full trace by running task with --trace)
> >>
> >>
> >>
> >> On Wed, Jan 13, 2016 at 1:45 PM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> Whatever you did seems to have done the trick:
> >>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/146/
> >>>
> >>> Thanks
> >>>
> >>>
> >>> On Wed, Jan 13, 2016 at 1:32 PM Sanne Grinovero <sanne at hibernate.org>
> >>> wrote:
> >>>
> >>>> Could you try again now please?
> >>>>
> >>>> On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org>
> >>>> wrote:
> >>>> > Trying to push and verify my announcement blog post for 5.0.7
> >>>> release, but
> >>>> > Jenkins fails to build it[1].  Apparently command `rake` not found.
> >>>> >
> >>>> > So what now?
> >>>> >
> >>>> > [1] -
> >>>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
> >>>> > _______________________________________________
> >>>> > hibernate-dev mailing list
> >>>> > hibernate-dev at lists.jboss.org
> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>
> >>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed Jan 13 15:37:27 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 Jan 2016 20:37:27 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
	<CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
Message-ID: <CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>

Ok, on to the next...

staging.hibernate.org build fails now:

rsync error: some files/attrs were not transferred (see previous
errors) (code 23) at main.c(1165) [sender=3.1.1]



On Wed, Jan 13, 2016 at 2:34 PM andrea boriero <dreborier at gmail.com> wrote:

> the problem seems related with the file name
>
> /2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v..erb
>
> instead of
>
> /2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v.*html*
> .erb
>
> On 13 January 2016 at 20:22, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Ok, that fixed this last problem
>>
>> On Wed, Jan 13, 2016 at 2:17 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > Per Hardy this might be due to a bad post uploaded to staging by Max.  I
>> > just deleted that file from staging and am trying build again
>> >
>> > On Wed, Jan 13, 2016 at 1:50 PM Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >
>> >> Sorry, spoke too soon...
>> >>
>> >> RROR: Running Awestruct failed.
>> >> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:104:in
>> `run_awestruct'
>> >> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:71:in
>> `block in <top (required)>'
>> >> Tasks: TOP => gen
>> >> (See full trace by running task with --trace)
>> >>
>> >>
>> >>
>> >> On Wed, Jan 13, 2016 at 1:45 PM Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >>
>> >>> Whatever you did seems to have done the trick:
>> >>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/146/
>> >>>
>> >>> Thanks
>> >>>
>> >>>
>> >>> On Wed, Jan 13, 2016 at 1:32 PM Sanne Grinovero <sanne at hibernate.org>
>> >>> wrote:
>> >>>
>> >>>> Could you try again now please?
>> >>>>
>> >>>> On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org>
>> >>>> wrote:
>> >>>> > Trying to push and verify my announcement blog post for 5.0.7
>> >>>> release, but
>> >>>> > Jenkins fails to build it[1].  Apparently command `rake` not found.
>> >>>> >
>> >>>> > So what now?
>> >>>> >
>> >>>> > [1] -
>> >>>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
>> >>>> > _______________________________________________
>> >>>> > hibernate-dev mailing list
>> >>>> > hibernate-dev at lists.jboss.org
>> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>
>> >>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Wed Jan 13 21:21:06 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 Jan 2016 02:21:06 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
	<CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
Message-ID: <CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>

Ok, next problem... :(

http://ci.hibernate.org/view/Website/job/www.hibernate.org/ This job has
been stuck in "pending?ci-slave-4 is offline" for hours now.


On Wed, Jan 13, 2016 at 2:37 PM Steve Ebersole <steve at hibernate.org> wrote:

> Ok, on to the next...
>
> staging.hibernate.org build fails now:
>
> rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.1]
>
>
>
> On Wed, Jan 13, 2016 at 2:34 PM andrea boriero <dreborier at gmail.com>
> wrote:
>
>> the problem seems related with the file name
>>
>> /2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v..erb
>>
>> instead of
>>
>> /2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v.
>> *html*.erb
>>
>> On 13 January 2016 at 20:22, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> Ok, that fixed this last problem
>>>
>>> On Wed, Jan 13, 2016 at 2:17 PM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>> > Per Hardy this might be due to a bad post uploaded to staging by Max.
>>> I
>>> > just deleted that file from staging and am trying build again
>>> >
>>> > On Wed, Jan 13, 2016 at 1:50 PM Steve Ebersole <steve at hibernate.org>
>>> > wrote:
>>> >
>>> >> Sorry, spoke too soon...
>>> >>
>>> >> RROR: Running Awestruct failed.
>>> >> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:104:in
>>> `run_awestruct'
>>> >> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:71:in
>>> `block in <top (required)>'
>>> >> Tasks: TOP => gen
>>> >> (See full trace by running task with --trace)
>>> >>
>>> >>
>>> >>
>>> >> On Wed, Jan 13, 2016 at 1:45 PM Steve Ebersole <steve at hibernate.org>
>>> >> wrote:
>>> >>
>>> >>> Whatever you did seems to have done the trick:
>>> >>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/146/
>>> >>>
>>> >>> Thanks
>>> >>>
>>> >>>
>>> >>> On Wed, Jan 13, 2016 at 1:32 PM Sanne Grinovero <sanne at hibernate.org
>>> >
>>> >>> wrote:
>>> >>>
>>> >>>> Could you try again now please?
>>> >>>>
>>> >>>> On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org>
>>> >>>> wrote:
>>> >>>> > Trying to push and verify my announcement blog post for 5.0.7
>>> >>>> release, but
>>> >>>> > Jenkins fails to build it[1].  Apparently command `rake` not
>>> found.
>>> >>>> >
>>> >>>> > So what now?
>>> >>>> >
>>> >>>> > [1] -
>>> >>>>
>>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
>>> >>>> > _______________________________________________
>>> >>>> > hibernate-dev mailing list
>>> >>>> > hibernate-dev at lists.jboss.org
>>> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >>>>
>>> >>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From gunnar at hibernate.org  Thu Jan 14 01:46:48 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 14 Jan 2016 07:46:48 +0100
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
	<CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
Message-ID: <CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>

Davide, since Dec 21st this job is configured to run on slave4 only
(which is offline). Is there a specific reason for this or can it be
changed to run on any node again?

2016-01-14 3:21 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> Ok, next problem... :(
>
> http://ci.hibernate.org/view/Website/job/www.hibernate.org/ This job has
> been stuck in "pending?ci-slave-4 is offline" for hours now.
>
>
> On Wed, Jan 13, 2016 at 2:37 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> Ok, on to the next...
>>
>> staging.hibernate.org build fails now:
>>
>> rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.1]
>>
>>
>>
>> On Wed, Jan 13, 2016 at 2:34 PM andrea boriero <dreborier at gmail.com>
>> wrote:
>>
>>> the problem seems related with the file name
>>>
>>> /2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v..erb
>>>
>>> instead of
>>>
>>> /2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v.
>>> *html*.erb
>>>
>>> On 13 January 2016 at 20:22, Steve Ebersole <steve at hibernate.org> wrote:
>>>
>>>> Ok, that fixed this last problem
>>>>
>>>> On Wed, Jan 13, 2016 at 2:17 PM Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>> > Per Hardy this might be due to a bad post uploaded to staging by Max.
>>>> I
>>>> > just deleted that file from staging and am trying build again
>>>> >
>>>> > On Wed, Jan 13, 2016 at 1:50 PM Steve Ebersole <steve at hibernate.org>
>>>> > wrote:
>>>> >
>>>> >> Sorry, spoke too soon...
>>>> >>
>>>> >> RROR: Running Awestruct failed.
>>>> >> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:104:in
>>>> `run_awestruct'
>>>> >> /mnt/jenkins-workdir/workspace/staging.in.relation.to/Rakefile:71:in
>>>> `block in <top (required)>'
>>>> >> Tasks: TOP => gen
>>>> >> (See full trace by running task with --trace)
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Wed, Jan 13, 2016 at 1:45 PM Steve Ebersole <steve at hibernate.org>
>>>> >> wrote:
>>>> >>
>>>> >>> Whatever you did seems to have done the trick:
>>>> >>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/146/
>>>> >>>
>>>> >>> Thanks
>>>> >>>
>>>> >>>
>>>> >>> On Wed, Jan 13, 2016 at 1:32 PM Sanne Grinovero <sanne at hibernate.org
>>>> >
>>>> >>> wrote:
>>>> >>>
>>>> >>>> Could you try again now please?
>>>> >>>>
>>>> >>>> On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org>
>>>> >>>> wrote:
>>>> >>>> > Trying to push and verify my announcement blog post for 5.0.7
>>>> >>>> release, but
>>>> >>>> > Jenkins fails to build it[1].  Apparently command `rake` not
>>>> found.
>>>> >>>> >
>>>> >>>> > So what now?
>>>> >>>> >
>>>> >>>> > [1] -
>>>> >>>>
>>>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
>>>> >>>> > _______________________________________________
>>>> >>>> > hibernate-dev mailing list
>>>> >>>> > hibernate-dev at lists.jboss.org
>>>> >>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >>>>
>>>> >>>
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From gunnar at hibernate.org  Thu Jan 14 02:02:03 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 14 Jan 2016 08:02:03 +0100
Subject: [hibernate-dev] JIRA: Activity dashboard not accessible for
	anonymous users
Message-ID: <CADGJaX8Sd2Xh5-4FLZUibZOFMKb44dv-aB=oNYK_ex2rroaNBQ@mail.gmail.com>

Hi,

When not being logged into JIRA, I am getting an error when opening
the "Activity" view in JIRA, e.g. at
https://hibernate.atlassian.net/projects/HV/summary:

    "This gadget cannot be displayed on your dashboard. This could be
due to a licensing problem or an application error."

Anyone knows whether/how this can be fixed on our side? Or is it
something for which we need to reach out to Atlassian to get it fixed?

Thanks,

--Gunnar

From mihalcea.vlad at gmail.com  Thu Jan 14 02:04:58 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 14 Jan 2016 09:04:58 +0200
Subject: [hibernate-dev] JIRA: Activity dashboard not accessible for
 anonymous users
In-Reply-To: <CADGJaX8Sd2Xh5-4FLZUibZOFMKb44dv-aB=oNYK_ex2rroaNBQ@mail.gmail.com>
References: <CADGJaX8Sd2Xh5-4FLZUibZOFMKb44dv-aB=oNYK_ex2rroaNBQ@mail.gmail.com>
Message-ID: <CA+gWKMBSmWwJM5sdbgDzGj=nuqaum0cHk9PTviAHOG7V-udNxw@mail.gmail.com>

Although not related to the issue, can someone add more rights to my JIRA
account, at least to edit my own posts.

Vlad

On Thu, Jan 14, 2016 at 9:02 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi,
>
> When not being logged into JIRA, I am getting an error when opening
> the "Activity" view in JIRA, e.g. at
> https://hibernate.atlassian.net/projects/HV/summary:
>
>     "This gadget cannot be displayed on your dashboard. This could be
> due to a licensing problem or an application error."
>
> Anyone knows whether/how this can be fixed on our side? Or is it
> something for which we need to reach out to Atlassian to get it fixed?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From mihalcea.vlad at gmail.com  Thu Jan 14 03:37:42 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 14 Jan 2016 10:37:42 +0200
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
References: <CAFdSV9u_JZUYzvyh_htnCH-rMxCchZeyqhBq3KYe1U2wPoLPOg@mail.gmail.com>
	<CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
Message-ID: <CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>

I see that the production and the staging are out of sync now and trying to
merge the upstream production leads to a merge commit.

How do we normally handle the cases when the production branch history
diverges from staging?

Vlad


On Thu, Jan 14, 2016 at 8:46 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Davide, since Dec 21st this job is configured to run on slave4 only
> (which is offline). Is there a specific reason for this or can it be
> changed to run on any node again?
>
> 2016-01-14 3:21 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > Ok, next problem... :(
> >
> > http://ci.hibernate.org/view/Website/job/www.hibernate.org/ This job has
> > been stuck in "pending?ci-slave-4 is offline" for hours now.
> >
> >
> > On Wed, Jan 13, 2016 at 2:37 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> Ok, on to the next...
> >>
> >> staging.hibernate.org build fails now:
> >>
> >> rsync error: some files/attrs were not transferred (see previous
> errors) (code 23) at main.c(1165) [sender=3.1.1]
> >>
> >>
> >>
> >> On Wed, Jan 13, 2016 at 2:34 PM andrea boriero <dreborier at gmail.com>
> >> wrote:
> >>
> >>> the problem seems related with the file name
> >>>
> >>>
> /2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v..erb
> >>>
> >>> instead of
> >>>
> >>> /2016-01-12-jboss-community-asylum-hibernate-strikes-back-episode-v.
> >>> *html*.erb
> >>>
> >>> On 13 January 2016 at 20:22, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>>
> >>>> Ok, that fixed this last problem
> >>>>
> >>>> On Wed, Jan 13, 2016 at 2:17 PM Steve Ebersole <steve at hibernate.org>
> >>>> wrote:
> >>>>
> >>>> > Per Hardy this might be due to a bad post uploaded to staging by
> Max.
> >>>> I
> >>>> > just deleted that file from staging and am trying build again
> >>>> >
> >>>> > On Wed, Jan 13, 2016 at 1:50 PM Steve Ebersole <steve at hibernate.org
> >
> >>>> > wrote:
> >>>> >
> >>>> >> Sorry, spoke too soon...
> >>>> >>
> >>>> >> RROR: Running Awestruct failed.
> >>>> >> /mnt/jenkins-workdir/workspace/
> staging.in.relation.to/Rakefile:104:in
> >>>> `run_awestruct'
> >>>> >> /mnt/jenkins-workdir/workspace/
> staging.in.relation.to/Rakefile:71:in
> >>>> `block in <top (required)>'
> >>>> >> Tasks: TOP => gen
> >>>> >> (See full trace by running task with --trace)
> >>>> >>
> >>>> >>
> >>>> >>
> >>>> >> On Wed, Jan 13, 2016 at 1:45 PM Steve Ebersole <
> steve at hibernate.org>
> >>>> >> wrote:
> >>>> >>
> >>>> >>> Whatever you did seems to have done the trick:
> >>>> >>>
> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/146/
> >>>> >>>
> >>>> >>> Thanks
> >>>> >>>
> >>>> >>>
> >>>> >>> On Wed, Jan 13, 2016 at 1:32 PM Sanne Grinovero <
> sanne at hibernate.org
> >>>> >
> >>>> >>> wrote:
> >>>> >>>
> >>>> >>>> Could you try again now please?
> >>>> >>>>
> >>>> >>>> On 13 January 2016 at 19:26, Steve Ebersole <steve at hibernate.org
> >
> >>>> >>>> wrote:
> >>>> >>>> > Trying to push and verify my announcement blog post for 5.0.7
> >>>> >>>> release, but
> >>>> >>>> > Jenkins fails to build it[1].  Apparently command `rake` not
> >>>> found.
> >>>> >>>> >
> >>>> >>>> > So what now?
> >>>> >>>> >
> >>>> >>>> > [1] -
> >>>> >>>>
> >>>> http://ci.hibernate.org/view/Website/job/staging.in.relation.to/145/
> >>>> >>>> > _______________________________________________
> >>>> >>>> > 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 hardy at hibernate.org  Thu Jan 14 03:56:50 2016
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 14 Jan 2016 09:56:50 +0100
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
References: <CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
Message-ID: <20160114085650.GA16437@Nineveh.local>

Hi,

On Thu, Jan 14, 2016 at 10:37:42AM +0200, Vlad Mihalcea wrote:
> I see that the production and the staging are out of sync now and trying to
> merge the upstream production leads to a merge commit.
> 
> How do we normally handle the cases when the production branch history
> diverges from staging?

You force push production to staging. There is no strong requirement for staging being
in sync with production. Staging is also there to test changes in the sites L&F or HTML
fixes. It is quite common that staging and production are out of sync.

For that reason it is important that when you want to blog you base your work on top of
production and not staging. Staging is just a convenient place to try changes to the site.
A forced push is perfectly ok. 

Personally I always pull from production and create "blog" branches from this branch.
Then when I want to preview the changes life, I do a forced push to the staging branch.
If I am happy with the result I push to production.

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

From mihalcea.vlad at gmail.com  Thu Jan 14 04:21:05 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 14 Jan 2016 11:21:05 +0200
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <20160114085650.GA16437@Nineveh.local>
References: <CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
Message-ID: <CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>

Hi,

Thanks for the clarifications. I thought that forced push is disabled, but
that might be true for the ORM, OGM, etc projects only.
I was also using a separate branch for every post, but I was branching from
staging because that was the default branch I got when forking the repo.

I thought those must be in-sync, like in a typical QA and production
environment where you push changes from develop -> qa -> production
I'm now writing a new post and push it to both staging and production when
I'm done.

Vlad

On Thu, Jan 14, 2016 at 10:56 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> On Thu, Jan 14, 2016 at 10:37:42AM +0200, Vlad Mihalcea wrote:
> > I see that the production and the staging are out of sync now and trying
> to
> > merge the upstream production leads to a merge commit.
> >
> > How do we normally handle the cases when the production branch history
> > diverges from staging?
>
> You force push production to staging. There is no strong requirement for
> staging being
> in sync with production. Staging is also there to test changes in the
> sites L&F or HTML
> fixes. It is quite common that staging and production are out of sync.
>
> For that reason it is important that when you want to blog you base your
> work on top of
> production and not staging. Staging is just a convenient place to try
> changes to the site.
> A forced push is perfectly ok.
>
> Personally I always pull from production and create "blog" branches from
> this branch.
> Then when I want to preview the changes life, I do a forced push to the
> staging branch.
> If I am happy with the result I push to production.
>
> --Hardy
>
>

From gunnar at hibernate.org  Thu Jan 14 04:31:28 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 14 Jan 2016 10:31:28 +0100
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
References: <CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
Message-ID: <CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>

> I thought those must be in-sync, like in a typical QA and production
> environment where you push changes from develop -> qa -> production

Staging can differ from production (usually be ahead) for previewing
changes. Then "releasing" is just a fast-forward merge from staging to
production. We don't enforce any specific workflow, though (like only
merges from staging are legit to production or so).

Personally, when using staging, I always try to leave it set to (or
fast-forwardable to) production when I am done with a given authoring
job. So the next guy coming after me doesn't have to care about any
non-published commits on staging.


2016-01-14 10:21 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> Hi,
>
> Thanks for the clarifications. I thought that forced push is disabled, but
> that might be true for the ORM, OGM, etc projects only.
> I was also using a separate branch for every post, but I was branching from
> staging because that was the default branch I got when forking the repo.
>
> I thought those must be in-sync, like in a typical QA and production
> environment where you push changes from develop -> qa -> production
> I'm now writing a new post and push it to both staging and production when
> I'm done.
>
> Vlad
>
> On Thu, Jan 14, 2016 at 10:56 AM, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>>
>> Hi,
>>
>> On Thu, Jan 14, 2016 at 10:37:42AM +0200, Vlad Mihalcea wrote:
>> > I see that the production and the staging are out of sync now and trying
>> > to
>> > merge the upstream production leads to a merge commit.
>> >
>> > How do we normally handle the cases when the production branch history
>> > diverges from staging?
>>
>> You force push production to staging. There is no strong requirement for
>> staging being
>> in sync with production. Staging is also there to test changes in the
>> sites L&F or HTML
>> fixes. It is quite common that staging and production are out of sync.
>>
>> For that reason it is important that when you want to blog you base your
>> work on top of
>> production and not staging. Staging is just a convenient place to try
>> changes to the site.
>> A forced push is perfectly ok.
>>
>> Personally I always pull from production and create "blog" branches from
>> this branch.
>> Then when I want to preview the changes life, I do a forced push to the
>> staging branch.
>> If I am happy with the result I push to production.
>>
>> --Hardy
>>
>

From daltodavide at gmail.com  Thu Jan 14 05:19:11 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Thu, 14 Jan 2016 10:19:11 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
References: <CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
Message-ID: <CANoTJYNj2ByOo8H4Z+3SYM82Ay2SfQCHnZ78n8nJ=H2ZWMTgQg@mail.gmail.com>

The hibernate.org job is working now.
I probably changed the label to slave4 when doing some maintenance work and
forgot to put it back to OS1.






On Thu, Jan 14, 2016 at 9:31 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> > I thought those must be in-sync, like in a typical QA and production
> > environment where you push changes from develop -> qa -> production
>
> Staging can differ from production (usually be ahead) for previewing
> changes. Then "releasing" is just a fast-forward merge from staging to
> production. We don't enforce any specific workflow, though (like only
> merges from staging are legit to production or so).
>
> Personally, when using staging, I always try to leave it set to (or
> fast-forwardable to) production when I am done with a given authoring
> job. So the next guy coming after me doesn't have to care about any
> non-published commits on staging.
>
>
> 2016-01-14 10:21 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> > Hi,
> >
> > Thanks for the clarifications. I thought that forced push is disabled,
> but
> > that might be true for the ORM, OGM, etc projects only.
> > I was also using a separate branch for every post, but I was branching
> from
> > staging because that was the default branch I got when forking the repo.
> >
> > I thought those must be in-sync, like in a typical QA and production
> > environment where you push changes from develop -> qa -> production
> > I'm now writing a new post and push it to both staging and production
> when
> > I'm done.
> >
> > Vlad
> >
> > On Thu, Jan 14, 2016 at 10:56 AM, Hardy Ferentschik <hardy at hibernate.org
> >
> > wrote:
> >>
> >> Hi,
> >>
> >> On Thu, Jan 14, 2016 at 10:37:42AM +0200, Vlad Mihalcea wrote:
> >> > I see that the production and the staging are out of sync now and
> trying
> >> > to
> >> > merge the upstream production leads to a merge commit.
> >> >
> >> > How do we normally handle the cases when the production branch history
> >> > diverges from staging?
> >>
> >> You force push production to staging. There is no strong requirement for
> >> staging being
> >> in sync with production. Staging is also there to test changes in the
> >> sites L&F or HTML
> >> fixes. It is quite common that staging and production are out of sync.
> >>
> >> For that reason it is important that when you want to blog you base your
> >> work on top of
> >> production and not staging. Staging is just a convenient place to try
> >> changes to the site.
> >> A forced push is perfectly ok.
> >>
> >> Personally I always pull from production and create "blog" branches from
> >> this branch.
> >> Then when I want to preview the changes life, I do a forced push to the
> >> staging branch.
> >> If I am happy with the result I push to production.
> >>
> >> --Hardy
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Thu Jan 14 05:38:40 2016
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 14 Jan 2016 11:38:40 +0100
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
References: <CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
Message-ID: <20160114103840.GA27298@Nineveh.local>

Hi,

> Personally, when using staging, I always try to leave it set to (or
> fast-forwardable to) production when I am done with a given authoring
> job. So the next guy coming after me doesn't have to care about any
> non-published commits on staging.

You are such a nice guy ;-)

--Hardy

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

From mihalcea.vlad at gmail.com  Thu Jan 14 06:00:29 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 14 Jan 2016 13:00:29 +0200
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
References: <CAFm4XO1ryM98AZcv4_SB8oy0_Junw4Wrvt_-+w4-ij+qRdyCiw@mail.gmail.com>
	<CAFdSV9tFrw5qOsshvQVz5-FRDAXY8XXnkO7_dJ-qCuDa=y30jA@mail.gmail.com>
	<CAFdSV9uPCyR5F-8pJ-osF9k_Sab0Q-DAxLwdHoFWmFykbx3szw@mail.gmail.com>
	<CAFdSV9vH0Kkd_84NqdGdSPwP5eC58LKPj1tntt6jtYCT6AB2eg@mail.gmail.com>
	<CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
Message-ID: <CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>

That'd what I also aim for, but now because the staging and the production
are out-of-sync and I was branching from staging, I cherry picked from my
feature branch into production.
How do we handle this out-of-sync issue?

Do we have to rewrite the staging history to match production and force
push it?

Vlad

On Thu, Jan 14, 2016 at 11:31 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> > I thought those must be in-sync, like in a typical QA and production
> > environment where you push changes from develop -> qa -> production
>
> Staging can differ from production (usually be ahead) for previewing
> changes. Then "releasing" is just a fast-forward merge from staging to
> production. We don't enforce any specific workflow, though (like only
> merges from staging are legit to production or so).
>
> Personally, when using staging, I always try to leave it set to (or
> fast-forwardable to) production when I am done with a given authoring
> job. So the next guy coming after me doesn't have to care about any
> non-published commits on staging.
>
>
> 2016-01-14 10:21 GMT+01:00 Vlad Mihalcea <mihalcea.vlad at gmail.com>:
> > Hi,
> >
> > Thanks for the clarifications. I thought that forced push is disabled,
> but
> > that might be true for the ORM, OGM, etc projects only.
> > I was also using a separate branch for every post, but I was branching
> from
> > staging because that was the default branch I got when forking the repo.
> >
> > I thought those must be in-sync, like in a typical QA and production
> > environment where you push changes from develop -> qa -> production
> > I'm now writing a new post and push it to both staging and production
> when
> > I'm done.
> >
> > Vlad
> >
> > On Thu, Jan 14, 2016 at 10:56 AM, Hardy Ferentschik <hardy at hibernate.org
> >
> > wrote:
> >>
> >> Hi,
> >>
> >> On Thu, Jan 14, 2016 at 10:37:42AM +0200, Vlad Mihalcea wrote:
> >> > I see that the production and the staging are out of sync now and
> trying
> >> > to
> >> > merge the upstream production leads to a merge commit.
> >> >
> >> > How do we normally handle the cases when the production branch history
> >> > diverges from staging?
> >>
> >> You force push production to staging. There is no strong requirement for
> >> staging being
> >> in sync with production. Staging is also there to test changes in the
> >> sites L&F or HTML
> >> fixes. It is quite common that staging and production are out of sync.
> >>
> >> For that reason it is important that when you want to blog you base your
> >> work on top of
> >> production and not staging. Staging is just a convenient place to try
> >> changes to the site.
> >> A forced push is perfectly ok.
> >>
> >> Personally I always pull from production and create "blog" branches from
> >> this branch.
> >> Then when I want to preview the changes life, I do a forced push to the
> >> staging branch.
> >> If I am happy with the result I push to production.
> >>
> >> --Hardy
> >>
> >
>

From mihalcea.vlad at gmail.com  Thu Jan 14 06:18:20 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 14 Jan 2016 13:18:20 +0200
Subject: [hibernate-dev] Activate URL links on blog
Message-ID: <CA+gWKMDtcB-kPyOEerrF6PsqzO7aR18PtF_gXt+_6xMDsSEpfw@mail.gmail.com>

Hi,

Since we are now moderating the forum and disallow new users from posting,
we can activate links on the forum to increase user experience.
What do you think?

Vlad

From hardy at hibernate.org  Thu Jan 14 07:22:46 2016
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 14 Jan 2016 13:22:46 +0100
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>
References: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
	<CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>
Message-ID: <20160114122246.GA31833@Nineveh.local>

Hi, 

> Do we have to rewrite the staging history to match production and force
> push it?

If you want staging to look like production, just push the production branch onto staging. 

$ git push -f origin production:staging

--Hardy

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

From mihalcea.vlad at gmail.com  Thu Jan 14 08:15:30 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 14 Jan 2016 15:15:30 +0200
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <20160114122246.GA31833@Nineveh.local>
References: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
	<CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>
	<20160114122246.GA31833@Nineveh.local>
Message-ID: <CA+gWKMB_wZ07RpfqF-CMKkM_+SQxaJ3et1rCiP1=0+6CbCsqNA@mail.gmail.com>

Thanks. The two branches are now in-sync.

Vlad

On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> > Do we have to rewrite the staging history to match production and force
> > push it?
>
> If you want staging to look like production, just push the production
> branch onto staging.
>
> $ git push -f origin production:staging
>
> --Hardy
>
>

From sanne at hibernate.org  Thu Jan 14 08:17:40 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 14 Jan 2016 13:17:40 +0000
Subject: [hibernate-dev] Activate URL links on blog
In-Reply-To: <CA+gWKMDtcB-kPyOEerrF6PsqzO7aR18PtF_gXt+_6xMDsSEpfw@mail.gmail.com>
References: <CA+gWKMDtcB-kPyOEerrF6PsqzO7aR18PtF_gXt+_6xMDsSEpfw@mail.gmail.com>
Message-ID: <CAFm4XO0kHRJEHmVBVvi9VEU2B4hy4OrCFUq=kzCKEwkVD6urVQ@mail.gmail.com>

+1


On Thu, 14 Jan 2016 11:18 Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> Hi,
>
> Since we are now moderating the forum and disallow new users from posting,
> we can activate links on the forum to increase user experience.
> What do you think?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Thu Jan 14 08:44:37 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 14 Jan 2016 14:44:37 +0100
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
Message-ID: <CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>

Hi Steve,

One thing useful to have for OGM would be a generalization of the
hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
all of them are "schemaless", e.g. Cassandra works with a fixed
schema, and while MongoDB largely is schemaless, we still want to
create stuff like indexes in the database.

I took a look and found that SchemaManagementTool as a pluggable
service already goes halfway into that direction. The issue with it is
that I cannot replace the list of exporters used by SchemaExport nor
the list of tool targets used by SchemaUpdate. Having a pluggable
service allowing me to customize that with an OGM-specific
implementation should do the trick.

As per some comments in the code, SchemaExport seems to be in some
intermediary state, where the ops are not executed directly through
the targets passed to SchemaCreator/Dropper but are read into String
arrays which are then passed on to separate exporters. I suppose part
of that work should be to consolidate this and basically follow the
same approach as used in SchemaUpdate?

Another facet is that for some OGM grid dialects we'd need another
representation of commands than Strings, as not all the backends have
a DDL but expect API invocations for that purpose. For that it'd be
required to change Target#accept(String) into accept(Object) so we can
pass some kind of command object. File exports would only work in a
limited fashion, but we could live with that. Schema creation/dropping
bound to the SF lifecycle is what I am after here.

I'd be willing to work on this once we agree on the general approach.

Any thoughts?

Thanks,

--Gunnar



2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:
> On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve at hibernate.org> wrote:
>
>> If you clean up the conflicts I can look for 5.1
>>
>
> Done!
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Jan 14 08:45:50 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 Jan 2016 13:45:50 +0000
Subject: [hibernate-dev] Hibernate ORM 5.0.7 release
Message-ID: <CAFdSV9tGhH7HT5-VkgHsr_r-kJxi4HsWQfAd2M8+ZQhrdsk07w@mail.gmail.com>

The 7th bug fix release for ORM 5.0 has been released. For information, see
http://in.relation.to/2016/01/13/hibernate-orm-507-final-release/

From daltodavide at gmail.com  Thu Jan 14 08:51:51 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Thu, 14 Jan 2016 13:51:51 +0000
Subject: [hibernate-dev] Activate URL links on blog
In-Reply-To: <CAFm4XO0kHRJEHmVBVvi9VEU2B4hy4OrCFUq=kzCKEwkVD6urVQ@mail.gmail.com>
References: <CA+gWKMDtcB-kPyOEerrF6PsqzO7aR18PtF_gXt+_6xMDsSEpfw@mail.gmail.com>
	<CAFm4XO0kHRJEHmVBVvi9VEU2B4hy4OrCFUq=kzCKEwkVD6urVQ@mail.gmail.com>
Message-ID: <CANoTJYMGUZiXbZkidpbYnvb-+HvcwF4WW=umX-njPT3fUL79rA@mail.gmail.com>

+1

If they get abused we can always revert to the current state

On Thu, Jan 14, 2016 at 1:17 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> +1
>
>
> On Thu, 14 Jan 2016 11:18 Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>
> > Hi,
> >
> > Since we are now moderating the forum and disallow new users from
> posting,
> > we can activate links on the forum to increase user experience.
> > What do you think?
> >
> > Vlad
> > _______________________________________________
> > 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 Jan 14 09:31:16 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 Jan 2016 14:31:16 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAKux6paaEgXAjQTOTjRuWP5G3xKGTcNC7zHmPth1B17zzS++3g@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>
	<CAFdSV9sp-7uYMyZGFTOwdBkErCaqwwzFfFK-6b2xGFQ4jhWKbw@mail.gmail.com>
	<CAKux6paaEgXAjQTOTjRuWP5G3xKGTcNC7zHmPth1B17zzS++3g@mail.gmail.com>
Message-ID: <CAFdSV9sTPDyT7Cxz5zB+A1ypDPSZ0py5mHGVqgJLqKH5oAdQzw@mail.gmail.com>

So then it sounds like "no" to this, which is fine.  We already have
updated to a much newer Ehcache and as pointed out earlier the stability in
the Ehcache API actually used in the integration means any 2.x version of
Ehcache should be fine to drop in.

Ehcache 3.x support will be based on that JSR 107 work...

On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps at gmail.com> wrote:

> Right, there was no plan to provide something for Ehcache3 quite yet.
> That being said, I wonder whether we ever will. I have a 107 compliant
> H2LC implementation. I also went over it with Sanne during Javaone and we
> think it can be made into something suiting for bunch of providers.
> Now, small caveat, while I still plan to work on this, as of this year I'm
> not working for Terracotta anymore... Basically, that's whenever I'll find
> time to do so.
> cc'ed Louis, in case some he wants to provide some more formal stance...
> Alex
>
>
> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Petar, Alex Snaps (in CC) has been doing some work to update the version
>> of Ehcache used in Hibernate ORM.  Alex, any updates?  As I understood it
>> though Ehcache 3.x was not part of that effort, but Alex can of course say
>> for sure.
>>
>>
>>
>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Hello all,
>>>
>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
>>> hibernate-ehcache module updated in 5.1?
>>>
>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>>>
>>>> I'll create a jira for the Javassist to be part of 5.1.
>>>>
>>>> Should we also look at changing Hibernate to not require Javassist
>>>> classes be on the deployment classpath?  This might require cloning some
>>>> Javassist runtime classes so that we don't get CNFE on
>>>> javassist.util.proxy.ProxyObject (and whatever else is required by
>>>> enhanced entity classes).
>>>>
>>>> [1] contains one of the CNFE's that I see with WildFly during deployment
>>>> time (only if WildFly is hacked to not inject Javassist into the
>>>> application classpath).  I am seeing
>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
>>>> entity class with references to Javassist classes (see disassembled
>>>> bytecode output [2]).  The generated class extends
>>>> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler. +
>>>> javassist.util.proxy.RuntimeSupport +
>>>> javassist.util.proxy.SerializedProxy.
>>>>
>>>> I'm sure that there are other Javassist classes that we probably also
>>>> generate bytecode to depend on, in other places in Hibernate.
>>>>
>>>> I have no idea exactly how to resolve this.  I'm not sure if it would
>>>> entail cloning the above javassist runtime classes into javassist.  Or
>>>> separating them into a different (Javassist) library, so at least the
>>>> application doesn't include the other Javassist classes.
>>>>
>>>> Sanne had some ideas that he mentioned [3].  By only exposing the needed
>>>> classloaders to the deployment, I think he meant the above idea of
>>>> separating Javassist into different jars.  Or something like that.
>>>>
>>>> Jason Greene also liked Sanne's suggestion of not requiring applications
>>>> to have Javassist on their classpath, as applications might also include
>>>> their own copy of Javassist because they want to generate some bytecode
>>>> also.
>>>>
>>>> What do others think about the idea of not requiring Javassist to be on
>>>> the Hibernate application classpath?  Again, I'm not sure if this only a
>>>> problem on WildFly.  If it is, I'm not sure why. :)
>>>>
>>>> Scott
>>>>
>>>> [1]
>>>>
>>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
>>>>
>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>>>
>>>> [3] https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>>>>
>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>>>> >
>>>> >
>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
>>>> > <mailto:smarlow at redhat.com>> wrote:
>>>> >
>>>> >     Should we upgrade to javassist latest in 5.1 still?
>>>> >
>>>> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>>>> >      > Just a heads up that I tentatively set Jan 27th as the release
>>>> >     date for
>>>> >      > 5.1.  Please let me know if that does not work for anyone.
>>>> Also
>>>> >     please
>>>> >      > keep that date in mind if there is anything you want to get
>>>> into 5.1.
>>>> >      > _______________________________________________
>>>> >      > hibernate-dev mailing list
>>>> >      > hibernate-dev at lists.jboss.org <mailto:
>>>> hibernate-dev at lists.jboss.org>
>>>>
>>> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> >      >
>>>> >
>>>> _______________________________________________
>>>> 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:
>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>

From paranoiabla at gmail.com  Thu Jan 14 09:45:30 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 14 Jan 2016 16:45:30 +0200
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9sTPDyT7Cxz5zB+A1ypDPSZ0py5mHGVqgJLqKH5oAdQzw@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>
	<CAFdSV9sp-7uYMyZGFTOwdBkErCaqwwzFfFK-6b2xGFQ4jhWKbw@mail.gmail.com>
	<CAKux6paaEgXAjQTOTjRuWP5G3xKGTcNC7zHmPth1B17zzS++3g@mail.gmail.com>
	<CAFdSV9sTPDyT7Cxz5zB+A1ypDPSZ0py5mHGVqgJLqKH5oAdQzw@mail.gmail.com>
Message-ID: <CAKnbemU4G8RgYxYMKc9H4VfjC_FU+C9cPMDe7kP2C+SmmU1p7g@mail.gmail.com>

Exactly,

I'm struggling to find a JSR-107 second-level cache to plug in my project.
EHCache 3.x does not integrate with hibernate yet, neither does hazelcast -
they have a PR, but they'll merge it in the next couple of months. Oracle
Coherence I think is paid, so is IBM extremescale and Grigain. JCS has a
one-year old beta release, which I'm not sure is jcache compliant, and
Infinispan, as I understand, works as a separate service, and I want to
have it embedded in my spring project. This is really embarrassing - a
cache is essential to any application and seems like there is no free,
robust, open-source, embeddable, JSR-107-compatible cache implementation.

2016-01-14 16:31 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> So then it sounds like "no" to this, which is fine.  We already have
> updated to a much newer Ehcache and as pointed out earlier the stability in
> the Ehcache API actually used in the integration means any 2.x version of
> Ehcache should be fine to drop in.
>
> Ehcache 3.x support will be based on that JSR 107 work...
>
>
> On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps at gmail.com> wrote:
>
>> Right, there was no plan to provide something for Ehcache3 quite yet.
>> That being said, I wonder whether we ever will. I have a 107 compliant
>> H2LC implementation. I also went over it with Sanne during Javaone and we
>> think it can be made into something suiting for bunch of providers.
>> Now, small caveat, while I still plan to work on this, as of this year
>> I'm not working for Terracotta anymore... Basically, that's whenever I'll
>> find time to do so.
>> cc'ed Louis, in case some he wants to provide some more formal stance...
>> Alex
>>
>>
>> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Petar, Alex Snaps (in CC) has been doing some work to update the version
>>> of Ehcache used in Hibernate ORM.  Alex, any updates?  As I understood it
>>> though Ehcache 3.x was not part of that effort, but Alex can of course say
>>> for sure.
>>>
>>>
>>>
>>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>> Hello all,
>>>>
>>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
>>>> hibernate-ehcache module updated in 5.1?
>>>>
>>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>>>>
>>>>> I'll create a jira for the Javassist to be part of 5.1.
>>>>>
>>>>> Should we also look at changing Hibernate to not require Javassist
>>>>> classes be on the deployment classpath?  This might require cloning
>>>>> some
>>>>> Javassist runtime classes so that we don't get CNFE on
>>>>> javassist.util.proxy.ProxyObject (and whatever else is required by
>>>>> enhanced entity classes).
>>>>>
>>>>> [1] contains one of the CNFE's that I see with WildFly during
>>>>> deployment
>>>>> time (only if WildFly is hacked to not inject Javassist into the
>>>>> application classpath).  I am seeing
>>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
>>>>> entity class with references to Javassist classes (see disassembled
>>>>> bytecode output [2]).  The generated class extends
>>>>> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler.
>>>>> +
>>>>> javassist.util.proxy.RuntimeSupport +
>>>>> javassist.util.proxy.SerializedProxy.
>>>>>
>>>>> I'm sure that there are other Javassist classes that we probably also
>>>>> generate bytecode to depend on, in other places in Hibernate.
>>>>>
>>>>> I have no idea exactly how to resolve this.  I'm not sure if it would
>>>>> entail cloning the above javassist runtime classes into javassist.  Or
>>>>> separating them into a different (Javassist) library, so at least the
>>>>> application doesn't include the other Javassist classes.
>>>>>
>>>>> Sanne had some ideas that he mentioned [3].  By only exposing the
>>>>> needed
>>>>> classloaders to the deployment, I think he meant the above idea of
>>>>> separating Javassist into different jars.  Or something like that.
>>>>>
>>>>> Jason Greene also liked Sanne's suggestion of not requiring
>>>>> applications
>>>>> to have Javassist on their classpath, as applications might also
>>>>> include
>>>>> their own copy of Javassist because they want to generate some bytecode
>>>>> also.
>>>>>
>>>>> What do others think about the idea of not requiring Javassist to be on
>>>>> the Hibernate application classpath?  Again, I'm not sure if this only
>>>>> a
>>>>> problem on WildFly.  If it is, I'm not sure why. :)
>>>>>
>>>>> Scott
>>>>>
>>>>> [1]
>>>>>
>>>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
>>>>>
>>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>>>>
>>>>> [3]
>>>>> https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>>>>>
>>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>>>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>>>>> >
>>>>> >
>>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
>>>>> > <mailto:smarlow at redhat.com>> wrote:
>>>>> >
>>>>> >     Should we upgrade to javassist latest in 5.1 still?
>>>>> >
>>>>> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>>>>> >      > Just a heads up that I tentatively set Jan 27th as the release
>>>>> >     date for
>>>>> >      > 5.1.  Please let me know if that does not work for anyone.
>>>>> Also
>>>>> >     please
>>>>> >      > keep that date in mind if there is anything you want to get
>>>>> into 5.1.
>>>>> >      > _______________________________________________
>>>>> >      > hibernate-dev mailing list
>>>>> >      > hibernate-dev at lists.jboss.org <mailto:
>>>>> hibernate-dev at lists.jboss.org>
>>>>>
>>>> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>> >      >
>>>>> >
>>>>> _______________________________________________
>>>>> 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:
>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>
>>>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From steve at hibernate.org  Thu Jan 14 09:51:14 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 Jan 2016 14:51:14 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
Message-ID: <CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>

I am not sure I am a big fan of The String->Object change specifically.  In
theory it sounds great.  But there is a major premise in schema tooling
around the idea of the actions being reduce-able to Strings.  That's
important not just for SQL, but for the idea of writing to a file as well.
It also affects the whole concept of Exporter/Exportable.

The ultimate design goal here is to unify schema creation and dropping
across native and JPA requirements.  I just simply have not had the time to
work on that.  This would all happen "behind" SchemaManagementTool and
friends.  SchemaExport, etc are actually just controllers responsible for
coordinating the calls into the SchemaManagementTool delegates.  The main
problem at the moment IMO is that Target gets passed into these
SchemaManagementTool delegates.  Ideally, and certainly this would fit with
your case, I think we want SchemaManagementTool or its delegates to handle
interpreting the "arguments".  This was part of the intent of developing
the "CommandLineArgs" stuff that is used inside SchemaExport, etc now; the
idea was to encapsulate the settings each tool needs to operate and isolate
the process of building/interpreting those args.

The next step I wanted to look at there was to morph CommandLineArgs into a
more generic "parameter object" for initializing the actual
SchemaManagementTool delegates.

The idea is that the more we can push into SchemaManagementTool and its
delegates the more pluggable this entire process becomes.  Ultimately, as I
mentioned above, I just do not think it is feasible for ORM and OGM to
share all of these implementation contracts.  Forcing a switch from String
(the DDL) arguments to some amorphic Object reinforces that in my mind.
But that would not stop OGM from completely swapping SchemaManagementTool
and its delegates and simply not using Target, Exporters, etc.


On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Steve,
>
> One thing useful to have for OGM would be a generalization of the
> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
> all of them are "schemaless", e.g. Cassandra works with a fixed
> schema, and while MongoDB largely is schemaless, we still want to
> create stuff like indexes in the database.
>
> I took a look and found that SchemaManagementTool as a pluggable
> service already goes halfway into that direction. The issue with it is
> that I cannot replace the list of exporters used by SchemaExport nor
> the list of tool targets used by SchemaUpdate. Having a pluggable
> service allowing me to customize that with an OGM-specific
> implementation should do the trick.
>
> As per some comments in the code, SchemaExport seems to be in some
> intermediary state, where the ops are not executed directly through
> the targets passed to SchemaCreator/Dropper but are read into String
> arrays which are then passed on to separate exporters. I suppose part
> of that work should be to consolidate this and basically follow the
> same approach as used in SchemaUpdate?
>
> Another facet is that for some OGM grid dialects we'd need another
> representation of commands than Strings, as not all the backends have
> a DDL but expect API invocations for that purpose. For that it'd be
> required to change Target#accept(String) into accept(Object) so we can
> pass some kind of command object. File exports would only work in a
> limited fashion, but we could live with that. Schema creation/dropping
> bound to the SF lifecycle is what I am after here.
>
> I'd be willing to work on this once we agree on the general approach.
>
> Any thoughts?
>
> Thanks,
>
> --Gunnar
>
>
>
> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:
> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> If you clean up the conflicts I can look for 5.1
> >>
> >
> > Done!
> >
> > --
> > Guillaume
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Jan 14 09:53:43 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 Jan 2016 14:53:43 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
Message-ID: <CAFdSV9uXfpiDKLsaZSaij=scUYQ-gc8K8ynRqYXeERTu3EofyA@mail.gmail.com>

Ehcache is all of those things iiuc.  You are more than welcome to
help Louis, Alex, Sanne and the rest of us work on that JSR-107 based
integration to get it integrated sooner since its so important for you and
since its such a travesty ;)


On Thu, Jan 14, 2016 at 8:51 AM Steve Ebersole <steve at hibernate.org> wrote:

> I am not sure I am a big fan of The String->Object change specifically.
> In theory it sounds great.  But there is a major premise in schema tooling
> around the idea of the actions being reduce-able to Strings.  That's
> important not just for SQL, but for the idea of writing to a file as well.
> It also affects the whole concept of Exporter/Exportable.
>
> The ultimate design goal here is to unify schema creation and dropping
> across native and JPA requirements.  I just simply have not had the time to
> work on that.  This would all happen "behind" SchemaManagementTool and
> friends.  SchemaExport, etc are actually just controllers responsible for
> coordinating the calls into the SchemaManagementTool delegates.  The main
> problem at the moment IMO is that Target gets passed into these
> SchemaManagementTool delegates.  Ideally, and certainly this would fit with
> your case, I think we want SchemaManagementTool or its delegates to handle
> interpreting the "arguments".  This was part of the intent of developing
> the "CommandLineArgs" stuff that is used inside SchemaExport, etc now; the
> idea was to encapsulate the settings each tool needs to operate and isolate
> the process of building/interpreting those args.
>
> The next step I wanted to look at there was to morph CommandLineArgs into
> a more generic "parameter object" for initializing the actual
> SchemaManagementTool delegates.
>
> The idea is that the more we can push into SchemaManagementTool and its
> delegates the more pluggable this entire process becomes.  Ultimately, as I
> mentioned above, I just do not think it is feasible for ORM and OGM to
> share all of these implementation contracts.  Forcing a switch from String
> (the DDL) arguments to some amorphic Object reinforces that in my mind.
> But that would not stop OGM from completely swapping SchemaManagementTool
> and its delegates and simply not using Target, Exporters, etc.
>
>
> On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Hi Steve,
>>
>> One thing useful to have for OGM would be a generalization of the
>> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
>> all of them are "schemaless", e.g. Cassandra works with a fixed
>> schema, and while MongoDB largely is schemaless, we still want to
>> create stuff like indexes in the database.
>>
>> I took a look and found that SchemaManagementTool as a pluggable
>> service already goes halfway into that direction. The issue with it is
>> that I cannot replace the list of exporters used by SchemaExport nor
>> the list of tool targets used by SchemaUpdate. Having a pluggable
>> service allowing me to customize that with an OGM-specific
>> implementation should do the trick.
>>
>> As per some comments in the code, SchemaExport seems to be in some
>> intermediary state, where the ops are not executed directly through
>> the targets passed to SchemaCreator/Dropper but are read into String
>> arrays which are then passed on to separate exporters. I suppose part
>> of that work should be to consolidate this and basically follow the
>> same approach as used in SchemaUpdate?
>>
>> Another facet is that for some OGM grid dialects we'd need another
>> representation of commands than Strings, as not all the backends have
>> a DDL but expect API invocations for that purpose. For that it'd be
>> required to change Target#accept(String) into accept(Object) so we can
>> pass some kind of command object. File exports would only work in a
>> limited fashion, but we could live with that. Schema creation/dropping
>> bound to the SF lifecycle is what I am after here.
>>
>> I'd be willing to work on this once we agree on the general approach.
>>
>> Any thoughts?
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>>
>> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:
>> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> If you clean up the conflicts I can look for 5.1
>> >>
>> >
>> > Done!
>> >
>> > --
>> > Guillaume
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Thu Jan 14 09:59:24 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 14 Jan 2016 14:59:24 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAKnbemU4G8RgYxYMKc9H4VfjC_FU+C9cPMDe7kP2C+SmmU1p7g@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>
	<CAFdSV9sp-7uYMyZGFTOwdBkErCaqwwzFfFK-6b2xGFQ4jhWKbw@mail.gmail.com>
	<CAKux6paaEgXAjQTOTjRuWP5G3xKGTcNC7zHmPth1B17zzS++3g@mail.gmail.com>
	<CAFdSV9sTPDyT7Cxz5zB+A1ypDPSZ0py5mHGVqgJLqKH5oAdQzw@mail.gmail.com>
	<CAKnbemU4G8RgYxYMKc9H4VfjC_FU+C9cPMDe7kP2C+SmmU1p7g@mail.gmail.com>
Message-ID: <CAFm4XO1oZg2-+BET_0AQ-w3RbhyEr0-zyyk9Hh_9tuBT1a8pzQ@mail.gmail.com>

Hi Petar,
Infinispan can work as a separate service, but that's not the default.
It's primarily designed for embedded caching, is OSS, implements
JSR-107 and also has integration helpers for Spring.

There are several other OSS implementations too; AFAIR cache2k is a
good one and also implements JSR-107.

That said, you can use EHcache 2 as well? It doesn't have to be
JSR-107 compliant to be used as Hibernate 2nd level cache, since the
integration with JSR-107 wan't released yet.

Sanne

On 14 January 2016 at 14:45, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> Exactly,
>
> I'm struggling to find a JSR-107 second-level cache to plug in my project.
> EHCache 3.x does not integrate with hibernate yet, neither does hazelcast -
> they have a PR, but they'll merge it in the next couple of months. Oracle
> Coherence I think is paid, so is IBM extremescale and Grigain. JCS has a
> one-year old beta release, which I'm not sure is jcache compliant, and
> Infinispan, as I understand, works as a separate service, and I want to
> have it embedded in my spring project. This is really embarrassing - a
> cache is essential to any application and seems like there is no free,
> robust, open-source, embeddable, JSR-107-compatible cache implementation.
>
> 2016-01-14 16:31 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> So then it sounds like "no" to this, which is fine.  We already have
>> updated to a much newer Ehcache and as pointed out earlier the stability in
>> the Ehcache API actually used in the integration means any 2.x version of
>> Ehcache should be fine to drop in.
>>
>> Ehcache 3.x support will be based on that JSR 107 work...
>>
>>
>> On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps at gmail.com> wrote:
>>
>>> Right, there was no plan to provide something for Ehcache3 quite yet.
>>> That being said, I wonder whether we ever will. I have a 107 compliant
>>> H2LC implementation. I also went over it with Sanne during Javaone and we
>>> think it can be made into something suiting for bunch of providers.
>>> Now, small caveat, while I still plan to work on this, as of this year
>>> I'm not working for Terracotta anymore... Basically, that's whenever I'll
>>> find time to do so.
>>> cc'ed Louis, in case some he wants to provide some more formal stance...
>>> Alex
>>>
>>>
>>> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> Petar, Alex Snaps (in CC) has been doing some work to update the version
>>>> of Ehcache used in Hibernate ORM.  Alex, any updates?  As I understood it
>>>> though Ehcache 3.x was not part of that effort, but Alex can of course say
>>>> for sure.
>>>>
>>>>
>>>>
>>>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
>>>>> hibernate-ehcache module updated in 5.1?
>>>>>
>>>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>>>>>
>>>>>> I'll create a jira for the Javassist to be part of 5.1.
>>>>>>
>>>>>> Should we also look at changing Hibernate to not require Javassist
>>>>>> classes be on the deployment classpath?  This might require cloning
>>>>>> some
>>>>>> Javassist runtime classes so that we don't get CNFE on
>>>>>> javassist.util.proxy.ProxyObject (and whatever else is required by
>>>>>> enhanced entity classes).
>>>>>>
>>>>>> [1] contains one of the CNFE's that I see with WildFly during
>>>>>> deployment
>>>>>> time (only if WildFly is hacked to not inject Javassist into the
>>>>>> application classpath).  I am seeing
>>>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
>>>>>> entity class with references to Javassist classes (see disassembled
>>>>>> bytecode output [2]).  The generated class extends
>>>>>> javassist.util.proxy.ProxyObject + javassist.util.proxy.MethodHandler.
>>>>>> +
>>>>>> javassist.util.proxy.RuntimeSupport +
>>>>>> javassist.util.proxy.SerializedProxy.
>>>>>>
>>>>>> I'm sure that there are other Javassist classes that we probably also
>>>>>> generate bytecode to depend on, in other places in Hibernate.
>>>>>>
>>>>>> I have no idea exactly how to resolve this.  I'm not sure if it would
>>>>>> entail cloning the above javassist runtime classes into javassist.  Or
>>>>>> separating them into a different (Javassist) library, so at least the
>>>>>> application doesn't include the other Javassist classes.
>>>>>>
>>>>>> Sanne had some ideas that he mentioned [3].  By only exposing the
>>>>>> needed
>>>>>> classloaders to the deployment, I think he meant the above idea of
>>>>>> separating Javassist into different jars.  Or something like that.
>>>>>>
>>>>>> Jason Greene also liked Sanne's suggestion of not requiring
>>>>>> applications
>>>>>> to have Javassist on their classpath, as applications might also
>>>>>> include
>>>>>> their own copy of Javassist because they want to generate some bytecode
>>>>>> also.
>>>>>>
>>>>>> What do others think about the idea of not requiring Javassist to be on
>>>>>> the Hibernate application classpath?  Again, I'm not sure if this only
>>>>>> a
>>>>>> problem on WildFly.  If it is, I'm not sure why. :)
>>>>>>
>>>>>> Scott
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
>>>>>>
>>>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>>>>>
>>>>>> [3]
>>>>>> https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>>>>>>
>>>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>>>>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>>>>>> >
>>>>>> >
>>>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
>>>>>> > <mailto:smarlow at redhat.com>> wrote:
>>>>>> >
>>>>>> >     Should we upgrade to javassist latest in 5.1 still?
>>>>>> >
>>>>>> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>>>>>> >      > Just a heads up that I tentatively set Jan 27th as the release
>>>>>> >     date for
>>>>>> >      > 5.1.  Please let me know if that does not work for anyone.
>>>>>> Also
>>>>>> >     please
>>>>>> >      > keep that date in mind if there is anything you want to get
>>>>>> into 5.1.
>>>>>> >      > _______________________________________________
>>>>>> >      > hibernate-dev mailing list
>>>>>> >      > hibernate-dev at lists.jboss.org <mailto:
>>>>>> hibernate-dev at lists.jboss.org>
>>>>>>
>>>>> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>> >      >
>>>>>> >
>>>>>> _______________________________________________
>>>>>> 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:
>>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>
>>>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=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  Thu Jan 14 10:16:25 2016
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 14 Jan 2016 17:16:25 +0200
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFm4XO1oZg2-+BET_0AQ-w3RbhyEr0-zyyk9Hh_9tuBT1a8pzQ@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>
	<CAFdSV9sp-7uYMyZGFTOwdBkErCaqwwzFfFK-6b2xGFQ4jhWKbw@mail.gmail.com>
	<CAKux6paaEgXAjQTOTjRuWP5G3xKGTcNC7zHmPth1B17zzS++3g@mail.gmail.com>
	<CAFdSV9sTPDyT7Cxz5zB+A1ypDPSZ0py5mHGVqgJLqKH5oAdQzw@mail.gmail.com>
	<CAKnbemU4G8RgYxYMKc9H4VfjC_FU+C9cPMDe7kP2C+SmmU1p7g@mail.gmail.com>
	<CAFm4XO1oZg2-+BET_0AQ-w3RbhyEr0-zyyk9Hh_9tuBT1a8pzQ@mail.gmail.com>
Message-ID: <CAKnbemUQUU8Qsxr+qBUMVWudycAchX9obL7e9O3Xm72_DxSi4A@mail.gmail.com>

Hi all,

I don't think it's a travesty - I actually use ehcache 2.x now :)
Thanks Sanne - I'll research infinispan more. One other thing - I see
there's a module hibernate-infinispan here:

http://repo1.maven.org/maven2/org/hibernate/hibernate-infinispan/

and inside I see they are using the 7.2.1.Final version.

Here's an idea - is it possible the hibernate team to provide a BOM with
all the versions definied. Just like the Drools team
and the Spring team has provided. This way if I want to upgrade the
hibernate version, I would simply upgrade the Bom
version and this will eventually upgrade the EHCache, Infinispan,
jboss-logger, hikaricp, c3p0 or any other module to a compatible
version. I think this would help a lot, not just me but also any other
users out there.

Thanks.

2016-01-14 16:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi Petar,
> Infinispan can work as a separate service, but that's not the default.
> It's primarily designed for embedded caching, is OSS, implements
> JSR-107 and also has integration helpers for Spring.
>
> There are several other OSS implementations too; AFAIR cache2k is a
> good one and also implements JSR-107.
>
> That said, you can use EHcache 2 as well? It doesn't have to be
> JSR-107 compliant to be used as Hibernate 2nd level cache, since the
> integration with JSR-107 wan't released yet.
>
> Sanne
>
> On 14 January 2016 at 14:45, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> > Exactly,
> >
> > I'm struggling to find a JSR-107 second-level cache to plug in my
> project.
> > EHCache 3.x does not integrate with hibernate yet, neither does
> hazelcast -
> > they have a PR, but they'll merge it in the next couple of months. Oracle
> > Coherence I think is paid, so is IBM extremescale and Grigain. JCS has a
> > one-year old beta release, which I'm not sure is jcache compliant, and
> > Infinispan, as I understand, works as a separate service, and I want to
> > have it embedded in my spring project. This is really embarrassing - a
> > cache is essential to any application and seems like there is no free,
> > robust, open-source, embeddable, JSR-107-compatible cache implementation.
> >
> > 2016-01-14 16:31 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >
> >> So then it sounds like "no" to this, which is fine.  We already have
> >> updated to a much newer Ehcache and as pointed out earlier the
> stability in
> >> the Ehcache API actually used in the integration means any 2.x version
> of
> >> Ehcache should be fine to drop in.
> >>
> >> Ehcache 3.x support will be based on that JSR 107 work...
> >>
> >>
> >> On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps at gmail.com>
> wrote:
> >>
> >>> Right, there was no plan to provide something for Ehcache3 quite yet.
> >>> That being said, I wonder whether we ever will. I have a 107 compliant
> >>> H2LC implementation. I also went over it with Sanne during Javaone and
> we
> >>> think it can be made into something suiting for bunch of providers.
> >>> Now, small caveat, while I still plan to work on this, as of this year
> >>> I'm not working for Terracotta anymore... Basically, that's whenever
> I'll
> >>> find time to do so.
> >>> cc'ed Louis, in case some he wants to provide some more formal
> stance...
> >>> Alex
> >>>
> >>>
> >>> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve at hibernate.org>
> >>> wrote:
> >>>
> >>>> Petar, Alex Snaps (in CC) has been doing some work to update the
> version
> >>>> of Ehcache used in Hibernate ORM.  Alex, any updates?  As I
> understood it
> >>>> though Ehcache 3.x was not part of that effort, but Alex can of
> course say
> >>>> for sure.
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hello all,
> >>>>>
> >>>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
> >>>>> hibernate-ehcache module updated in 5.1?
> >>>>>
> >>>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
> >>>>>
> >>>>>> I'll create a jira for the Javassist to be part of 5.1.
> >>>>>>
> >>>>>> Should we also look at changing Hibernate to not require Javassist
> >>>>>> classes be on the deployment classpath?  This might require cloning
> >>>>>> some
> >>>>>> Javassist runtime classes so that we don't get CNFE on
> >>>>>> javassist.util.proxy.ProxyObject (and whatever else is required by
> >>>>>> enhanced entity classes).
> >>>>>>
> >>>>>> [1] contains one of the CNFE's that I see with WildFly during
> >>>>>> deployment
> >>>>>> time (only if WildFly is hacked to not inject Javassist into the
> >>>>>> application classpath).  I am seeing
> >>>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
> >>>>>> entity class with references to Javassist classes (see disassembled
> >>>>>> bytecode output [2]).  The generated class extends
> >>>>>> javassist.util.proxy.ProxyObject +
> javassist.util.proxy.MethodHandler.
> >>>>>> +
> >>>>>> javassist.util.proxy.RuntimeSupport +
> >>>>>> javassist.util.proxy.SerializedProxy.
> >>>>>>
> >>>>>> I'm sure that there are other Javassist classes that we probably
> also
> >>>>>> generate bytecode to depend on, in other places in Hibernate.
> >>>>>>
> >>>>>> I have no idea exactly how to resolve this.  I'm not sure if it
> would
> >>>>>> entail cloning the above javassist runtime classes into javassist.
> Or
> >>>>>> separating them into a different (Javassist) library, so at least
> the
> >>>>>> application doesn't include the other Javassist classes.
> >>>>>>
> >>>>>> Sanne had some ideas that he mentioned [3].  By only exposing the
> >>>>>> needed
> >>>>>> classloaders to the deployment, I think he meant the above idea of
> >>>>>> separating Javassist into different jars.  Or something like that.
> >>>>>>
> >>>>>> Jason Greene also liked Sanne's suggestion of not requiring
> >>>>>> applications
> >>>>>> to have Javassist on their classpath, as applications might also
> >>>>>> include
> >>>>>> their own copy of Javassist because they want to generate some
> bytecode
> >>>>>> also.
> >>>>>>
> >>>>>> What do others think about the idea of not requiring Javassist to
> be on
> >>>>>> the Hibernate application classpath?  Again, I'm not sure if this
> only
> >>>>>> a
> >>>>>> problem on WildFly.  If it is, I'm not sure why. :)
> >>>>>>
> >>>>>> Scott
> >>>>>>
> >>>>>> [1]
> >>>>>>
> >>>>>>
> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
> >>>>>>
> >>>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
> >>>>>>
> >>>>>> [3]
> >>>>>> https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
> >>>>>>
> >>>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
> >>>>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
> >>>>>> >
> >>>>>> >
> >>>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
> >>>>>> > <mailto:smarlow at redhat.com>> wrote:
> >>>>>> >
> >>>>>> >     Should we upgrade to javassist latest in 5.1 still?
> >>>>>> >
> >>>>>> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
> >>>>>> >      > Just a heads up that I tentatively set Jan 27th as the
> release
> >>>>>> >     date for
> >>>>>> >      > 5.1.  Please let me know if that does not work for anyone.
> >>>>>> Also
> >>>>>> >     please
> >>>>>> >      > keep that date in mind if there is anything you want to get
> >>>>>> into 5.1.
> >>>>>> >      > _______________________________________________
> >>>>>> >      > hibernate-dev mailing list
> >>>>>> >      > hibernate-dev at lists.jboss.org <mailto:
> >>>>>> hibernate-dev at lists.jboss.org>
> >>>>>>
> >>>>> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>> >      >
> >>>>>> >
> >>>>>> _______________________________________________
> >>>>>> 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:
> >>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >>>>>
> >>>>
> >
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=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:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From daltodavide at gmail.com  Thu Jan 14 11:50:55 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Thu, 14 Jan 2016 16:50:55 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CA+gWKMB_wZ07RpfqF-CMKkM_+SQxaJ3et1rCiP1=0+6CbCsqNA@mail.gmail.com>
References: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
	<CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>
	<20160114122246.GA31833@Nineveh.local>
	<CA+gWKMB_wZ07RpfqF-CMKkM_+SQxaJ3et1rCiP1=0+6CbCsqNA@mail.gmail.com>
Message-ID: <CANoTJYPzv0e8niNT1d7Yue4E7T2GJQvepBeN8JoMRSoEdHsd1w@mail.gmail.com>

The staging.hibernate.org should now work again,
It was a problem of permissions, the owner of the folder with the site
changed (not sure why) and the rsync script wasn't able to update it.

Davide

On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Thanks. The two branches are now in-sync.
>
> Vlad
>
> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
> > Hi,
> >
> > > Do we have to rewrite the staging history to match production and force
> > > push it?
> >
> > If you want staging to look like production, just push the production
> > branch onto staging.
> >
> > $ git push -f origin production:staging
> >
> > --Hardy
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From davide at hibernate.org  Thu Jan 14 11:53:44 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 14 Jan 2016 16:53:44 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CANoTJYPzv0e8niNT1d7Yue4E7T2GJQvepBeN8JoMRSoEdHsd1w@mail.gmail.com>
References: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
	<CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>
	<20160114122246.GA31833@Nineveh.local>
	<CA+gWKMB_wZ07RpfqF-CMKkM_+SQxaJ3et1rCiP1=0+6CbCsqNA@mail.gmail.com>
	<CANoTJYPzv0e8niNT1d7Yue4E7T2GJQvepBeN8JoMRSoEdHsd1w@mail.gmail.com>
Message-ID: <CANoTJYP2sL44MS0pBtHbwNmUqSOsN7na+T_bPmUoLGGtoiQVUQ@mail.gmail.com>

By the way, is there a way to recognize the staging website from the
production one?

If not we should probably add a timestamp somewhere and maybe a watermark
on some images.


On Thu, Jan 14, 2016 at 4:50 PM, Davide D'Alto <daltodavide at gmail.com>
wrote:

> The staging.hibernate.org should now work again,
> It was a problem of permissions, the owner of the folder with the site
> changed (not sure why) and the rsync script wasn't able to update it.
>
> Davide
>
> On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Thanks. The two branches are now in-sync.
>>
>> Vlad
>>
>> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>>
>> > Hi,
>> >
>> > > Do we have to rewrite the staging history to match production and
>> force
>> > > push it?
>> >
>> > If you want staging to look like production, just push the production
>> > branch onto staging.
>> >
>> > $ git push -f origin production:staging
>> >
>> > --Hardy
>> >
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Thu Jan 14 12:36:28 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 14 Jan 2016 18:36:28 +0100
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CANoTJYP2sL44MS0pBtHbwNmUqSOsN7na+T_bPmUoLGGtoiQVUQ@mail.gmail.com>
References: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
	<CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>
	<20160114122246.GA31833@Nineveh.local>
	<CA+gWKMB_wZ07RpfqF-CMKkM_+SQxaJ3et1rCiP1=0+6CbCsqNA@mail.gmail.com>
	<CANoTJYPzv0e8niNT1d7Yue4E7T2GJQvepBeN8JoMRSoEdHsd1w@mail.gmail.com>
	<CANoTJYP2sL44MS0pBtHbwNmUqSOsN7na+T_bPmUoLGGtoiQVUQ@mail.gmail.com>
Message-ID: <CADGJaX8Z42icy0dtBS3aeXY6XnXmfu1TgNX_Q51W+yjMMijMKw@mail.gmail.com>

WDYM by "recognize the staging website from the production one?" Are
you looking for something else than the different URLs?


2016-01-14 17:53 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
> By the way, is there a way to recognize the staging website from the
> production one?
>
> If not we should probably add a timestamp somewhere and maybe a watermark
> on some images.
>
>
> On Thu, Jan 14, 2016 at 4:50 PM, Davide D'Alto <daltodavide at gmail.com>
> wrote:
>
>> The staging.hibernate.org should now work again,
>> It was a problem of permissions, the owner of the folder with the site
>> changed (not sure why) and the rsync script wasn't able to update it.
>>
>> Davide
>>
>> On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> Thanks. The two branches are now in-sync.
>>>
>>> Vlad
>>>
>>> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik <hardy at hibernate.org>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > > Do we have to rewrite the staging history to match production and
>>> force
>>> > > push it?
>>> >
>>> > If you want staging to look like production, just push the production
>>> > branch onto staging.
>>> >
>>> > $ git push -f origin production:staging
>>> >
>>> > --Hardy
>>> >
>>> >
>>> _______________________________________________
>>> 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 davide at hibernate.org  Thu Jan 14 12:45:36 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 14 Jan 2016 17:45:36 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CADGJaX8Z42icy0dtBS3aeXY6XnXmfu1TgNX_Q51W+yjMMijMKw@mail.gmail.com>
References: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
	<CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>
	<20160114122246.GA31833@Nineveh.local>
	<CA+gWKMB_wZ07RpfqF-CMKkM_+SQxaJ3et1rCiP1=0+6CbCsqNA@mail.gmail.com>
	<CANoTJYPzv0e8niNT1d7Yue4E7T2GJQvepBeN8JoMRSoEdHsd1w@mail.gmail.com>
	<CANoTJYP2sL44MS0pBtHbwNmUqSOsN7na+T_bPmUoLGGtoiQVUQ@mail.gmail.com>
	<CADGJaX8Z42icy0dtBS3aeXY6XnXmfu1TgNX_Q51W+yjMMijMKw@mail.gmail.com>
Message-ID: <CANoTJYMgQwjr-c0YSh78p0susZkRsYxse_YmRFYPh5AViJuf8g@mail.gmail.com>

> you looking for something else than the different URLs?

Yes, something different than the URL.


On Thu, Jan 14, 2016 at 5:36 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> WDYM by "recognize the staging website from the production one?" Are
> you looking for something else than the different URLs?
>
>
> 2016-01-14 17:53 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
> > By the way, is there a way to recognize the staging website from the
> > production one?
> >
> > If not we should probably add a timestamp somewhere and maybe a watermark
> > on some images.
> >
> >
> > On Thu, Jan 14, 2016 at 4:50 PM, Davide D'Alto <daltodavide at gmail.com>
> > wrote:
> >
> >> The staging.hibernate.org should now work again,
> >> It was a problem of permissions, the owner of the folder with the site
> >> changed (not sure why) and the rsync script wasn't able to update it.
> >>
> >> Davide
> >>
> >> On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com
> >
> >> wrote:
> >>
> >>> Thanks. The two branches are now in-sync.
> >>>
> >>> Vlad
> >>>
> >>> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik <
> hardy at hibernate.org>
> >>> wrote:
> >>>
> >>> > Hi,
> >>> >
> >>> > > Do we have to rewrite the staging history to match production and
> >>> force
> >>> > > push it?
> >>> >
> >>> > If you want staging to look like production, just push the production
> >>> > branch onto staging.
> >>> >
> >>> > $ git push -f origin production:staging
> >>> >
> >>> > --Hardy
> >>> >
> >>> >
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Thu Jan 14 12:47:30 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 14 Jan 2016 18:47:30 +0100
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CANoTJYMgQwjr-c0YSh78p0susZkRsYxse_YmRFYPh5AViJuf8g@mail.gmail.com>
References: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
	<CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>
	<20160114122246.GA31833@Nineveh.local>
	<CA+gWKMB_wZ07RpfqF-CMKkM_+SQxaJ3et1rCiP1=0+6CbCsqNA@mail.gmail.com>
	<CANoTJYPzv0e8niNT1d7Yue4E7T2GJQvepBeN8JoMRSoEdHsd1w@mail.gmail.com>
	<CANoTJYP2sL44MS0pBtHbwNmUqSOsN7na+T_bPmUoLGGtoiQVUQ@mail.gmail.com>
	<CADGJaX8Z42icy0dtBS3aeXY6XnXmfu1TgNX_Q51W+yjMMijMKw@mail.gmail.com>
	<CANoTJYMgQwjr-c0YSh78p0susZkRsYxse_YmRFYPh5AViJuf8g@mail.gmail.com>
Message-ID: <CADGJaX-qY9_eP=3DbsFcJ3J+04Xy9HcDCV0X0jovP=oWPYr3ag@mail.gmail.com>

Ok, what for?

2016-01-14 18:45 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
>> you looking for something else than the different URLs?
>
> Yes, something different than the URL.
>
>
> On Thu, Jan 14, 2016 at 5:36 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> WDYM by "recognize the staging website from the production one?" Are
>> you looking for something else than the different URLs?
>>
>>
>> 2016-01-14 17:53 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
>> > By the way, is there a way to recognize the staging website from the
>> > production one?
>> >
>> > If not we should probably add a timestamp somewhere and maybe a
>> > watermark
>> > on some images.
>> >
>> >
>> > On Thu, Jan 14, 2016 at 4:50 PM, Davide D'Alto <daltodavide at gmail.com>
>> > wrote:
>> >
>> >> The staging.hibernate.org should now work again,
>> >> It was a problem of permissions, the owner of the folder with the site
>> >> changed (not sure why) and the rsync script wasn't able to update it.
>> >>
>> >> Davide
>> >>
>> >> On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea
>> >> <mihalcea.vlad at gmail.com>
>> >> wrote:
>> >>
>> >>> Thanks. The two branches are now in-sync.
>> >>>
>> >>> Vlad
>> >>>
>> >>> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik
>> >>> <hardy at hibernate.org>
>> >>> wrote:
>> >>>
>> >>> > Hi,
>> >>> >
>> >>> > > Do we have to rewrite the staging history to match production and
>> >>> force
>> >>> > > push it?
>> >>> >
>> >>> > If you want staging to look like production, just push the
>> >>> > production
>> >>> > branch onto staging.
>> >>> >
>> >>> > $ git push -f origin production:staging
>> >>> >
>> >>> > --Hardy
>> >>> >
>> >>> >
>> >>> _______________________________________________
>> >>> 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 davide at hibernate.org  Thu Jan 14 13:03:44 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 14 Jan 2016 18:03:44 +0000
Subject: [hibernate-dev] staging Blog site
In-Reply-To: <CADGJaX-qY9_eP=3DbsFcJ3J+04Xy9HcDCV0X0jovP=oWPYr3ag@mail.gmail.com>
References: <CAFdSV9uo=dZBo-p5aP7MZtoTSYhpuxEGnsK-a0SDaOgFTvNvfg@mail.gmail.com>
	<CAL00eSR56GCiwfNL3cJ5LNxUqa7X0fvOg2+6qyMqTeszvxNPqA@mail.gmail.com>
	<CAFdSV9sXksSh2SYS3Hq5Bvo6z4bmEM2LdSmBVWeeE4xBcgZa_Q@mail.gmail.com>
	<CAFdSV9uNEXVjBJhVZQtY9cJWuZJOAzbiVkfEifTnW0wiZY3tZQ@mail.gmail.com>
	<CADGJaX_uRXxSLB+tXAcAV_zMYFDy-8wYk--=+6vH9cBD8wf0Pg@mail.gmail.com>
	<CA+gWKMCxfd9FTr0u+340D+D_Tx+gyps9OGkk=XXyhPPbmH1A3Q@mail.gmail.com>
	<20160114085650.GA16437@Nineveh.local>
	<CA+gWKMAdu82G3e8R8=qQMyw1=Q1NQY98b88NuGoubZ_Du1KxaQ@mail.gmail.com>
	<CADGJaX9LWvbuTpgfvT3-RzNnOQR4jYwufg-eF7_Jp6Zkhswk4g@mail.gmail.com>
	<CA+gWKMDTa_gPCarfMA-ueLqEWnvUY6FXWjBCjRioSANXEDSnBw@mail.gmail.com>
	<20160114122246.GA31833@Nineveh.local>
	<CA+gWKMB_wZ07RpfqF-CMKkM_+SQxaJ3et1rCiP1=0+6CbCsqNA@mail.gmail.com>
	<CANoTJYPzv0e8niNT1d7Yue4E7T2GJQvepBeN8JoMRSoEdHsd1w@mail.gmail.com>
	<CANoTJYP2sL44MS0pBtHbwNmUqSOsN7na+T_bPmUoLGGtoiQVUQ@mail.gmail.com>
	<CADGJaX8Z42icy0dtBS3aeXY6XnXmfu1TgNX_Q51W+yjMMijMKw@mail.gmail.com>
	<CANoTJYMgQwjr-c0YSh78p0susZkRsYxse_YmRFYPh5AViJuf8g@mail.gmail.com>
	<CADGJaX-qY9_eP=3DbsFcJ3J+04Xy9HcDCV0X0jovP=oWPYr3ag@mail.gmail.com>
Message-ID: <CANoTJYOsC3pLn__BP=DFJj+h+ZEC7NDmrFkuZ9ibZ-BkfT4Q3Q@mail.gmail.com>

> Ok, what for?

Right, not so useful in the end.

The idea is to make
make sure that one is publishing the right branch/rake[profile] in the
right url when the site is generated.


On Thu, Jan 14, 2016 at 5:47 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Ok, what for?
>
> 2016-01-14 18:45 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
> >> you looking for something else than the different URLs?
> >
> > Yes, something different than the URL.
> >
> >
> > On Thu, Jan 14, 2016 at 5:36 PM, Gunnar Morling <gunnar at hibernate.org>
> > wrote:
> >>
> >> WDYM by "recognize the staging website from the production one?" Are
> >> you looking for something else than the different URLs?
> >>
> >>
> >> 2016-01-14 17:53 GMT+01:00 Davide D'Alto <davide at hibernate.org>:
> >> > By the way, is there a way to recognize the staging website from the
> >> > production one?
> >> >
> >> > If not we should probably add a timestamp somewhere and maybe a
> >> > watermark
> >> > on some images.
> >> >
> >> >
> >> > On Thu, Jan 14, 2016 at 4:50 PM, Davide D'Alto <daltodavide at gmail.com
> >
> >> > wrote:
> >> >
> >> >> The staging.hibernate.org should now work again,
> >> >> It was a problem of permissions, the owner of the folder with the
> site
> >> >> changed (not sure why) and the rsync script wasn't able to update it.
> >> >>
> >> >> Davide
> >> >>
> >> >> On Thu, Jan 14, 2016 at 1:15 PM, Vlad Mihalcea
> >> >> <mihalcea.vlad at gmail.com>
> >> >> wrote:
> >> >>
> >> >>> Thanks. The two branches are now in-sync.
> >> >>>
> >> >>> Vlad
> >> >>>
> >> >>> On Thu, Jan 14, 2016 at 2:22 PM, Hardy Ferentschik
> >> >>> <hardy at hibernate.org>
> >> >>> wrote:
> >> >>>
> >> >>> > Hi,
> >> >>> >
> >> >>> > > Do we have to rewrite the staging history to match production
> and
> >> >>> force
> >> >>> > > push it?
> >> >>> >
> >> >>> > If you want staging to look like production, just push the
> >> >>> > production
> >> >>> > branch onto staging.
> >> >>> >
> >> >>> > $ git push -f origin production:staging
> >> >>> >
> >> >>> > --Hardy
> >> >>> >
> >> >>> >
> >> >>> _______________________________________________
> >> >>> 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  Thu Jan 14 15:35:23 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 14 Jan 2016 20:35:23 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAKnbemUQUU8Qsxr+qBUMVWudycAchX9obL7e9O3Xm72_DxSi4A@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAKnbemUadmCctiyqov_rRZ9dmcF4NSzLhgchDCw9o3fT7vpaGw@mail.gmail.com>
	<CAFdSV9sp-7uYMyZGFTOwdBkErCaqwwzFfFK-6b2xGFQ4jhWKbw@mail.gmail.com>
	<CAKux6paaEgXAjQTOTjRuWP5G3xKGTcNC7zHmPth1B17zzS++3g@mail.gmail.com>
	<CAFdSV9sTPDyT7Cxz5zB+A1ypDPSZ0py5mHGVqgJLqKH5oAdQzw@mail.gmail.com>
	<CAKnbemU4G8RgYxYMKc9H4VfjC_FU+C9cPMDe7kP2C+SmmU1p7g@mail.gmail.com>
	<CAFm4XO1oZg2-+BET_0AQ-w3RbhyEr0-zyyk9Hh_9tuBT1a8pzQ@mail.gmail.com>
	<CAKnbemUQUU8Qsxr+qBUMVWudycAchX9obL7e9O3Xm72_DxSi4A@mail.gmail.com>
Message-ID: <CAFm4XO1+nzMTf8yYUkHv4txbNqc2UrRMFgZH_8a_Th+fsFhO5g@mail.gmail.com>

On 14 January 2016 at 15:16, Petar Tahchiev <paranoiabla at gmail.com> wrote:
> Hi all,
>
> I don't think it's a travesty - I actually use ehcache 2.x now :)
> Thanks Sanne - I'll research infinispan more. One other thing - I see
> there's a module hibernate-infinispan here:
>
> http://repo1.maven.org/maven2/org/hibernate/hibernate-infinispan/
>
> and inside I see they are using the 7.2.1.Final version.
>
> Here's an idea - is it possible the hibernate team to provide a BOM with all
> the versions definied. Just like the Drools team
> and the Spring team has provided. This way if I want to upgrade the
> hibernate version, I would simply upgrade the Bom
> version and this will eventually upgrade the EHCache, Infinispan,
> jboss-logger, hikaricp, c3p0 or any other module to a compatible
> version. I think this would help a lot, not just me but also any other users
> out there.

I don't think a BOM would help you in this case.
you just need to depend on :
org.hibernate:hibernate-core:5.0.7.Final
org.hibernate:hibernate-infinispan:5.0.7.Final

and use the dependencies that these provide.
The only thing you have to be careful about is this '5.0.7.Final' is
the same for all your libraries from Hibernate ORM, but that's easily
done with a property.

Thanks,
Sanne


>
> Thanks.
>
> 2016-01-14 16:59 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Hi Petar,
>> Infinispan can work as a separate service, but that's not the default.
>> It's primarily designed for embedded caching, is OSS, implements
>> JSR-107 and also has integration helpers for Spring.
>>
>> There are several other OSS implementations too; AFAIR cache2k is a
>> good one and also implements JSR-107.
>>
>> That said, you can use EHcache 2 as well? It doesn't have to be
>> JSR-107 compliant to be used as Hibernate 2nd level cache, since the
>> integration with JSR-107 wan't released yet.
>>
>> Sanne
>>
>> On 14 January 2016 at 14:45, Petar Tahchiev <paranoiabla at gmail.com> wrote:
>> > Exactly,
>> >
>> > I'm struggling to find a JSR-107 second-level cache to plug in my
>> > project.
>> > EHCache 3.x does not integrate with hibernate yet, neither does
>> > hazelcast -
>> > they have a PR, but they'll merge it in the next couple of months.
>> > Oracle
>> > Coherence I think is paid, so is IBM extremescale and Grigain. JCS has a
>> > one-year old beta release, which I'm not sure is jcache compliant, and
>> > Infinispan, as I understand, works as a separate service, and I want to
>> > have it embedded in my spring project. This is really embarrassing - a
>> > cache is essential to any application and seems like there is no free,
>> > robust, open-source, embeddable, JSR-107-compatible cache
>> > implementation.
>> >
>> > 2016-01-14 16:31 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>> >
>> >> So then it sounds like "no" to this, which is fine.  We already have
>> >> updated to a much newer Ehcache and as pointed out earlier the
>> >> stability in
>> >> the Ehcache API actually used in the integration means any 2.x version
>> >> of
>> >> Ehcache should be fine to drop in.
>> >>
>> >> Ehcache 3.x support will be based on that JSR 107 work...
>> >>
>> >>
>> >> On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps at gmail.com>
>> >> wrote:
>> >>
>> >>> Right, there was no plan to provide something for Ehcache3 quite yet.
>> >>> That being said, I wonder whether we ever will. I have a 107 compliant
>> >>> H2LC implementation. I also went over it with Sanne during Javaone and
>> >>> we
>> >>> think it can be made into something suiting for bunch of providers.
>> >>> Now, small caveat, while I still plan to work on this, as of this year
>> >>> I'm not working for Terracotta anymore... Basically, that's whenever
>> >>> I'll
>> >>> find time to do so.
>> >>> cc'ed Louis, in case some he wants to provide some more formal
>> >>> stance...
>> >>> Alex
>> >>>
>> >>>
>> >>> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve at hibernate.org>
>> >>> wrote:
>> >>>
>> >>>> Petar, Alex Snaps (in CC) has been doing some work to update the
>> >>>> version
>> >>>> of Ehcache used in Hibernate ORM.  Alex, any updates?  As I
>> >>>> understood it
>> >>>> though Ehcache 3.x was not part of that effort, but Alex can of
>> >>>> course say
>> >>>> for sure.
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla at gmail.com>
>> >>>> wrote:
>> >>>>
>> >>>>> Hello all,
>> >>>>>
>> >>>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
>> >>>>> hibernate-ehcache module updated in 5.1?
>> >>>>>
>> >>>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow at redhat.com>:
>> >>>>>
>> >>>>>> I'll create a jira for the Javassist to be part of 5.1.
>> >>>>>>
>> >>>>>> Should we also look at changing Hibernate to not require Javassist
>> >>>>>> classes be on the deployment classpath?  This might require cloning
>> >>>>>> some
>> >>>>>> Javassist runtime classes so that we don't get CNFE on
>> >>>>>> javassist.util.proxy.ProxyObject (and whatever else is required by
>> >>>>>> enhanced entity classes).
>> >>>>>>
>> >>>>>> [1] contains one of the CNFE's that I see with WildFly during
>> >>>>>> deployment
>> >>>>>> time (only if WildFly is hacked to not inject Javassist into the
>> >>>>>> application classpath).  I am seeing
>> >>>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance
>> >>>>>> the
>> >>>>>> entity class with references to Javassist classes (see disassembled
>> >>>>>> bytecode output [2]).  The generated class extends
>> >>>>>> javassist.util.proxy.ProxyObject +
>> >>>>>> javassist.util.proxy.MethodHandler.
>> >>>>>> +
>> >>>>>> javassist.util.proxy.RuntimeSupport +
>> >>>>>> javassist.util.proxy.SerializedProxy.
>> >>>>>>
>> >>>>>> I'm sure that there are other Javassist classes that we probably
>> >>>>>> also
>> >>>>>> generate bytecode to depend on, in other places in Hibernate.
>> >>>>>>
>> >>>>>> I have no idea exactly how to resolve this.  I'm not sure if it
>> >>>>>> would
>> >>>>>> entail cloning the above javassist runtime classes into javassist.
>> >>>>>> Or
>> >>>>>> separating them into a different (Javassist) library, so at least
>> >>>>>> the
>> >>>>>> application doesn't include the other Javassist classes.
>> >>>>>>
>> >>>>>> Sanne had some ideas that he mentioned [3].  By only exposing the
>> >>>>>> needed
>> >>>>>> classloaders to the deployment, I think he meant the above idea of
>> >>>>>> separating Javassist into different jars.  Or something like that.
>> >>>>>>
>> >>>>>> Jason Greene also liked Sanne's suggestion of not requiring
>> >>>>>> applications
>> >>>>>> to have Javassist on their classpath, as applications might also
>> >>>>>> include
>> >>>>>> their own copy of Javassist because they want to generate some
>> >>>>>> bytecode
>> >>>>>> also.
>> >>>>>>
>> >>>>>> What do others think about the idea of not requiring Javassist to
>> >>>>>> be on
>> >>>>>> the Hibernate application classpath?  Again, I'm not sure if this
>> >>>>>> only
>> >>>>>> a
>> >>>>>> problem on WildFly.  If it is, I'm not sure why. :)
>> >>>>>>
>> >>>>>> Scott
>> >>>>>>
>> >>>>>> [1]
>> >>>>>>
>> >>>>>>
>> >>>>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-txt-L1
>> >>>>>>
>> >>>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>> >>>>>>
>> >>>>>> [3]
>> >>>>>> https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>> >>>>>>
>> >>>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>> >>>>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>> >>>>>> >
>> >>>>>> >
>> >>>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow at redhat.com
>> >>>>>> > <mailto:smarlow at redhat.com>> wrote:
>> >>>>>> >
>> >>>>>> >     Should we upgrade to javassist latest in 5.1 still?
>> >>>>>> >
>> >>>>>> >     On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>> >>>>>> >      > Just a heads up that I tentatively set Jan 27th as the
>> >>>>>> > release
>> >>>>>> >     date for
>> >>>>>> >      > 5.1.  Please let me know if that does not work for anyone.
>> >>>>>> Also
>> >>>>>> >     please
>> >>>>>> >      > keep that date in mind if there is anything you want to
>> >>>>>> > get
>> >>>>>> into 5.1.
>> >>>>>> >      > _______________________________________________
>> >>>>>> >      > hibernate-dev mailing list
>> >>>>>> >      > hibernate-dev at lists.jboss.org <mailto:
>> >>>>>> hibernate-dev at lists.jboss.org>
>> >>>>>>
>> >>>>> >      > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>>>> >      >
>> >>>>>> >
>> >>>>>> _______________________________________________
>> >>>>>> 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:
>> >>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> >>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> >>>>>
>> >>>>
>> >
>> >
>> > --
>> > Regards, Petar!
>> > Karlovo, Bulgaria.
>> > ---
>> > Public PGP Key at:
>> > http://pgp.mit.edu:11371/pks/lookup?op=get&search=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:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From gbadner at redhat.com  Thu Jan 14 17:08:22 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 14 Jan 2016 14:08:22 -0800
Subject: [hibernate-dev] Oracle12cDialect identity support
In-Reply-To: <CAFDzhiQGtkV8pOvi3nhFSXZrqy=JDgLWHXygg+v7hS=hv=Kksg@mail.gmail.com>
References: <CAFDzhiTAB2VZ0TuGmKeffBYcC_E4G46hQjup80Xsr2K3eQ7wKA@mail.gmail.com>
	<5630A09D-94CC-4077-8C6F-8C34CC42D14F@hibernate.org>
	<CAFdSV9v5knGMmXRVjJLUXKbaSSe4+VbvLw7W0eojiDgXuD49Gw@mail.gmail.com>
	<CAFDzhiT4ZcRh4toSjQGC08PPEK32jA2HS3J_dAWsgx616SCGCQ@mail.gmail.com>
	<CAFdSV9sCSPgfY-ovZf+q202hu_r3p5va=EzCsQNfao-bNf80Hw@mail.gmail.com>
	<CAFDzhiQGtkV8pOvi3nhFSXZrqy=JDgLWHXygg+v7hS=hv=Kksg@mail.gmail.com>
Message-ID: <CAFDzhiQk31jPLoEmW=UBmvpfr_m2uFGZHz5VELwNOKbjUGrG1w@mail.gmail.com>

Just to bring everyone up-to-date, the following were fixed in Hibernate
ORM 5.0.7:
* HHH-10421: "native" ID generator for Oracle12cDialect changed to
SequenceStyleGenerator; this change make the "native" ID generator for
Oracle12cDialect consistent with earlier Oracle dialects;
* HHH-10422: fix identity IDs using Oracle12cDialect.

HHH-10421 includes deprecation of the following dialect methods in 5.0:
supportsIdentityColumns()
supportsInsertSelectIdentity()
hasDataTypeInIdentityColumn()
appendIdentitySelectToInsert(String insertString)
getIdentitySelectString(String table, String column, int type)
getIdentityColumnString(int type)
getIdentityInsertString()

These method are removed from master.

On Tue, Jan 5, 2016 at 6:52 PM, Gail Badner <gbadner at redhat.com> wrote:

> I was mistaken when I said that an IDENTITY ID will be created when using
> @GeneratedValue or @GeneratedValue(strategy= GenerationType.AUTO). With
> hibernate.id.new_generator_mappings set to true by default in 5.0 and 5.1,
> a SequenceStyleGenerator will be used instead.
>
> Currently, the default for "native" ID generator mapped in hbm.xml uses an
> IDENTITY if the dialect supports an IDENTITY. This will be overridden in
> Oracle12cDialect as we've been discussing.
>
> On Tue, Jan 5, 2016 at 9:46 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>>
>>
>> On Tue, Jan 5, 2016 at 12:42 AM Gail Badner <gbadner at redhat.com> wrote:
>>
>>>
>>>
>>>>  Native is a Hibernate-only concept and so we can really choose
>>>> whatever we want for native generators.  Also native is an outdated
>>>> concept, replaced by AUTO and SequenceStyleGenerator.  IMO we should never
>>>> be choosing IDENTITY for identifier generation unless a user explicitly
>>>> asks for it.
>>>>
>>>
>>> Just to make sure I understand, are you saying we should not be choosing
>>> IDENTITY by default for *new* dialects only?
>>>
>>
>> Well in an ideal world where we can time-travel and retroactively apply
>> our gained 20/20 hindsight I would change that everywhere.  However we
>> don't have that luxury :)  So, yes, I would do that just for new Dialects.
>>
>> So moving forward, any new Dialect should never chose {"native" ->
>> IDENTITY} and should never chose {AUTO -> IDENTITY}.
>>
>>
>>
>>>
>>>
>>>> So for the first piece, Oracle12cDialect should
>>>> override getNativeIdentifierGeneratorClass to
>>>> return SequenceStyleGenerator.  The Dialect implementation
>>>> of getNativeIdentifierGeneratorClass really assumes databases which support
>>>> IDENTITY but not SEQUENCE.
>>>>
>>>
>>> Thanks for clarifying that. I was wondering about that.
>>>
>>>
>>>> Oracle12cDialect is the first case we have had where a database that
>>>> historically supported SEQUENCES has added support for IDENTITY and we just
>>>> did not account for that properly.  In fact, the "proper" solution would be
>>>> to go into the base Oracle Dialect(s) and override
>>>> getNativeIdentifierGeneratorClass to just always
>>>> return SequenceStyleGenerator.  But doing that in SequenceStyleGenerator
>>>> only is viable too.
>>>>
>>>
>>> Did you mean, "doing that in Oracle12cDialect only is viable too"?
>>>
>>
>> Yes.  Considering I typed that on my phone I am shocked that was my only
>> typo :)
>>
>>
>>>
>>>>
>>>> As for how to get IDENTITY generation to work consistently with Oracle,
>>>> that I cannot say.  I asked Oscar (the reporter of HHH-9983) for find out
>>>> the way to get IDENTITY generation to work with Oracle 12c *via JDBC*.
>>>>  "Via JDBC" is the operative part.  All of the Oracle documentation and
>>>> google hits at that time only discussed using IDENTITY via command told
>>>> (SQLPlus, etc).  According to his findings we seem to have to correct.
>>>>
>>>
>>> I believe Oracle12cDialect identity support is working properly in
>>> master now.
>>>
>>> IIUC you are saying that the problem is porting that from 5.1 (master)
>>>> to 5.0?  Due to an SPI change?  What exactly is the SPI that changed?  We
>>>> did make lots of changes to "IdentityColumnSupport" (adding that as a
>>>> first-class contract), but that is really just cosmetic grouping of stuff
>>>> already available on Dialect.  So what change specifically stops you from
>>>> porting those changes to 5.0?
>>>>
>>>
>>> I've looked over the changes again and I think the main problem is that
>>> the refactoring done for HHH-10084 [1] will break custom dialects that
>>> override the Dialect methods that are deprecated for 5.1. The deprecated
>>> Dialect methods are no longer used; Hibernate obtains the identity support
>>> information from Dialect#getIdentityColumnSupport only.
>>>
>>
>> Then the deprecated Dialect methods ought to be removed.  Leaving them
>> only causes confusion
>>
>>
>>>
>>> I've created a test to illustrate: [2].
>>>
>>> Custom dialects will need to be modified to override
>>> getIdentityColumnSupport() to work. Would this type of breaking change be
>>> OK for 5.1 (I'm guessing no...). IMO, it is not OK to introduce this
>>> breaking change in 5.0.
>>>
>>
>> I am not sure what you are asking when you say "Would this type of
>> breaking change be OK for 5.1"
>>
>>
>>
>>>
>>> HHH-10084 ([1]) changed the deprecated Dialect methods to delegate to
>>> the IdentityColumnSupport. It also extracted the overridden methods from
>>> Dialect subclasses into dialect-specific IdentityColumnSupport classes.
>>>
>>> If I backport HHH-9983 to 5.0, I think I would only backport part of
>>> HHH-10084. I would change IdentityColumnSupportImpl methods to delegate to
>>> the deprecated Dialect methods; I would not extract the overridden methods
>>> into dialect-specific IdentityColumnSupport classes. That way, custom
>>> dialects would not be broken.
>>>
>>
>> This kind of multi-dispatch makes my head hurt.  And I bet users don't
>> find it any less confusing...
>>
>>
>
>

From rvansa at redhat.com  Fri Jan 15 04:47:45 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 15 Jan 2016 10:47:45 +0100
Subject: [hibernate-dev] 2LC docs
Message-ID: <5698C041.8060904@redhat.com>

Hi,

I was about to fill some gaps in 2LC docs regarding improvements in 
5.0/5.1, but when I took a look into 5.0 docs [1] there's close to 
nothing; is it by purpose? In 4.3 docs [2], there's much more on this 
subject. Am I looking in a wrong place?

Radim

[1] 
http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
[2] 
http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From mihalcea.vlad at gmail.com  Fri Jan 15 05:57:23 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Fri, 15 Jan 2016 12:57:23 +0200
Subject: [hibernate-dev] Forum database banned emails issue
Message-ID: <CA+gWKMDwq+yB5w7zBWL9apNX5hAJLGyeJa0qWCm9oe0JEg5gFg@mail.gmail.com>

Hi,

I tried to import the last 24 hour forum spam emails form
https://www.stopforumspam.com/, which is around 50k email entries.

The email were imported, but now the banned email page of the forum doesn't
load anymore.
The problem is related to how phpBB renders the page since there's a
dropdown where all emails must listed.

Could someone delete a part of those entries or give me access to the DB so
I can remove them myself?

Vlad

From steve at hibernate.org  Fri Jan 15 17:09:20 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 15 Jan 2016 22:09:20 +0000
Subject: [hibernate-dev] Forum database banned emails issue
In-Reply-To: <CA+gWKMDwq+yB5w7zBWL9apNX5hAJLGyeJa0qWCm9oe0JEg5gFg@mail.gmail.com>
References: <CA+gWKMDwq+yB5w7zBWL9apNX5hAJLGyeJa0qWCm9oe0JEg5gFg@mail.gmail.com>
Message-ID: <CAFdSV9tGxO7BuZzJbFFYcQQnJdkeP2puR+NujvtTbqQy=SJ0Kw@mail.gmail.com>

Sorry, I have no idea.  That information is not listed in our private wiki
area.  For anyone who knows this information, could you also update that
resources page?

On Fri, Jan 15, 2016 at 4:57 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I tried to import the last 24 hour forum spam emails form
> https://www.stopforumspam.com/, which is around 50k email entries.
>
> The email were imported, but now the banned email page of the forum doesn't
> load anymore.
> The problem is related to how phpBB renders the page since there's a
> dropdown where all emails must listed.
>
> Could someone delete a part of those entries or give me access to the DB so
> I can remove them myself?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Jan 15 18:10:39 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 15 Jan 2016 23:10:39 +0000
Subject: [hibernate-dev] Jenkins notification misfire
	"hibernate-orm-master-h2-infinispan8"
Message-ID: <CAFm4XO0Q8W6wbNA=8XtYc7B539uDv5-8ZJWzy2-kz8-kZ2YE4g@mail.gmail.com>

Hello all,

today I enabled an old build job on ci.hibernate.org named
"hibernate-orm-master-h2-infinispan8" and when it failed it
automatically sent a complaint to many, many of you.

Apologies, that was not intentional but a misconfiguration of the job.
It shouldn't happen again, or if it happens it should be for good
reason like a failure of a patch you contributed, or because you're
responsible for the component's quality.

That wasn't the case today, so please ignore that single but annoying
notification.

Thanks,
Sanne

From mihalcea.vlad at gmail.com  Sat Jan 16 04:58:24 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 16 Jan 2016 11:58:24 +0200
Subject: [hibernate-dev] Keyset pagination support
Message-ID: <CA+gWKMA4aB1utBzAvzg1FcTsxR=x5MDme-CtbkwTf=Qf5U03zg@mail.gmail.com>

Hi,

I think it will be useful to consider adding support for Keyset pagination:

http://use-the-index-luke.com/no-offset

This could be a very strong feature that would set us apart from our
competition.

Vlad

From sanne at hibernate.org  Sat Jan 16 06:15:46 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 16 Jan 2016 11:15:46 +0000
Subject: [hibernate-dev] Keyset pagination support
In-Reply-To: <CA+gWKMA4aB1utBzAvzg1FcTsxR=x5MDme-CtbkwTf=Qf5U03zg@mail.gmail.com>
References: <CA+gWKMA4aB1utBzAvzg1FcTsxR=x5MDme-CtbkwTf=Qf5U03zg@mail.gmail.com>
Message-ID: <CAFm4XO3MR3xRbU1EaEKZjNMYfJ5wjxHgUS1oVxpM0q65bQMPjw@mail.gmail.com>

I would love that. We actually discussed such an approach a couple of
years ago, but the context was not to implement pagination correctly
but to improve the performance of the Hibernate Search mass-indexer (a
batch process which iterates through all entities to rebuild the
Lucene index).

We eventually resolved that issue we had with transactions, but I
still wonder if using comparable keys would give us better
performance. The limitation is though that they need to be
comparable.. is that always the case, and if not do you think we can
figure it out easily from the SQL types?

BTW, the article you point to seems to imply that without this feature
it's impossible to do correct pagination, but while I'm not sure how
people use Hibernate nowadays, when I used it for something similar
within the JBoss Seam framework one would simply keep the
repeatable-read transaction going so there would be no
inconsistencies.

This makes me think though that it might be useful for Hibernate
Search users to be able to "freeze" the index view temporarily:
https://hibernate.atlassian.net/browse/HSEARCH-2080


On 16 January 2016 at 09:58, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Hi,
>
> I think it will be useful to consider adding support for Keyset pagination:
>
> http://use-the-index-luke.com/no-offset
>
> This could be a very strong feature that would set us apart from our
> competition.
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Sat Jan 16 06:25:24 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 16 Jan 2016 11:25:24 +0000
Subject: [hibernate-dev] Forum database banned emails issue
In-Reply-To: <CAFdSV9tGxO7BuZzJbFFYcQQnJdkeP2puR+NujvtTbqQy=SJ0Kw@mail.gmail.com>
References: <CA+gWKMDwq+yB5w7zBWL9apNX5hAJLGyeJa0qWCm9oe0JEg5gFg@mail.gmail.com>
	<CAFdSV9tGxO7BuZzJbFFYcQQnJdkeP2puR+NujvtTbqQy=SJ0Kw@mail.gmail.com>
Message-ID: <CAFm4XO1LYe0guz9VK=SLzNC7zS4uqpj6tv9LV4MQRVhqy9DY_Q@mail.gmail.com>

It is documented here:
 - https://developer.jboss.org/wiki/ForumsAdministrationAccess

However as you can see it's not easy to get to. You need to hop around
several security checks and get authorization from each party.

I can help with this as I already have access - if I remember the
whole process ;-) - but you'll have to describe what you want me to do
exactly. Do I need to wipe a large amount of data from a table? And do
you have some example data to help me make sure I'm wiping the right
table? Also please let me know if this is urgent: seems like a quite
delicate matter and since I'm having a bit of fever now I'm afraid I'd
mess up with the production db :)

Sanne

On 15 January 2016 at 22:09, Steve Ebersole <steve at hibernate.org> wrote:
> Sorry, I have no idea.  That information is not listed in our private wiki
> area.  For anyone who knows this information, could you also update that
> resources page?
>
> On Fri, Jan 15, 2016 at 4:57 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Hi,
>>
>> I tried to import the last 24 hour forum spam emails form
>> https://www.stopforumspam.com/, which is around 50k email entries.
>>
>> The email were imported, but now the banned email page of the forum doesn't
>> load anymore.
>> The problem is related to how phpBB renders the page since there's a
>> dropdown where all emails must listed.
>>
>> Could someone delete a part of those entries or give me access to the DB so
>> I can remove them myself?
>>
>> Vlad
>> _______________________________________________
>> 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 mihalcea.vlad at gmail.com  Sat Jan 16 06:42:57 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 16 Jan 2016 13:42:57 +0200
Subject: [hibernate-dev] Forum database banned emails issue
In-Reply-To: <CAFm4XO1LYe0guz9VK=SLzNC7zS4uqpj6tv9LV4MQRVhqy9DY_Q@mail.gmail.com>
References: <CA+gWKMDwq+yB5w7zBWL9apNX5hAJLGyeJa0qWCm9oe0JEg5gFg@mail.gmail.com>
	<CAFdSV9tGxO7BuZzJbFFYcQQnJdkeP2puR+NujvtTbqQy=SJ0Kw@mail.gmail.com>
	<CAFm4XO1LYe0guz9VK=SLzNC7zS4uqpj6tv9LV4MQRVhqy9DY_Q@mail.gmail.com>
Message-ID: <CA+gWKMAqXbYThS-5YKc1M+eoqGZU0iAP3YJx0dFfW6=yuy+sqw@mail.gmail.com>

Thanks Sanne,

In the Administration Control Panel -> Maintenance, there's the Admin log.
You can see there the emails that I added to the ban, along with the date
they were submitted: Fri Jan 15, 2016 9:16 am

I was thinking of deleting 5k emails from the ban list that were added at
that date.
I hope the DB records the time-stamp info, or at least we can use the Ids.

I added those progressively and when there were 40k/45k entries, the page
was still loading.

Vlad

On Sat, Jan 16, 2016 at 1:25 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> It is documented here:
>  - https://developer.jboss.org/wiki/ForumsAdministrationAccess
>
> However as you can see it's not easy to get to. You need to hop around
> several security checks and get authorization from each party.
>
> I can help with this as I already have access - if I remember the
> whole process ;-) - but you'll have to describe what you want me to do
> exactly. Do I need to wipe a large amount of data from a table? And do
> you have some example data to help me make sure I'm wiping the right
> table? Also please let me know if this is urgent: seems like a quite
> delicate matter and since I'm having a bit of fever now I'm afraid I'd
> mess up with the production db :)
>
> Sanne
>
> On 15 January 2016 at 22:09, Steve Ebersole <steve at hibernate.org> wrote:
> > Sorry, I have no idea.  That information is not listed in our private
> wiki
> > area.  For anyone who knows this information, could you also update that
> > resources page?
> >
> > On Fri, Jan 15, 2016 at 4:57 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> >
> >> Hi,
> >>
> >> I tried to import the last 24 hour forum spam emails form
> >> https://www.stopforumspam.com/, which is around 50k email entries.
> >>
> >> The email were imported, but now the banned email page of the forum
> doesn't
> >> load anymore.
> >> The problem is related to how phpBB renders the page since there's a
> >> dropdown where all emails must listed.
> >>
> >> Could someone delete a part of those entries or give me access to the
> DB so
> >> I can remove them myself?
> >>
> >> Vlad
> >> _______________________________________________
> >> 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  Sat Jan 16 08:05:20 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 16 Jan 2016 13:05:20 +0000
Subject: [hibernate-dev] Forum database banned emails issue
In-Reply-To: <CA+gWKMAqXbYThS-5YKc1M+eoqGZU0iAP3YJx0dFfW6=yuy+sqw@mail.gmail.com>
References: <CA+gWKMDwq+yB5w7zBWL9apNX5hAJLGyeJa0qWCm9oe0JEg5gFg@mail.gmail.com>
	<CAFdSV9tGxO7BuZzJbFFYcQQnJdkeP2puR+NujvtTbqQy=SJ0Kw@mail.gmail.com>
	<CAFm4XO1LYe0guz9VK=SLzNC7zS4uqpj6tv9LV4MQRVhqy9DY_Q@mail.gmail.com>
	<CA+gWKMAqXbYThS-5YKc1M+eoqGZU0iAP3YJx0dFfW6=yuy+sqw@mail.gmail.com>
Message-ID: <CAFm4XO2=fgYqB9728jvnh_eX5DhSYziUtXoqAxXxDkH7W9_-6w@mail.gmail.com>

I Vlad,
I'm sorry, it seems my credentials expired. I opened a ticket, it
might take some time though.
You might want to open a ticket to get credentials too.

Sanne

On 16 January 2016 at 11:42, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> Thanks Sanne,
>
> In the Administration Control Panel -> Maintenance, there's the Admin log.
> You can see there the emails that I added to the ban, along with the date
> they were submitted: Fri Jan 15, 2016 9:16 am
>
> I was thinking of deleting 5k emails from the ban list that were added at
> that date.
> I hope the DB records the time-stamp info, or at least we can use the Ids.
>
> I added those progressively and when there were 40k/45k entries, the page
> was still loading.
>
> Vlad
>
> On Sat, Jan 16, 2016 at 1:25 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> It is documented here:
>>  - https://developer.jboss.org/wiki/ForumsAdministrationAccess
>>
>> However as you can see it's not easy to get to. You need to hop around
>> several security checks and get authorization from each party.
>>
>> I can help with this as I already have access - if I remember the
>> whole process ;-) - but you'll have to describe what you want me to do
>> exactly. Do I need to wipe a large amount of data from a table? And do
>> you have some example data to help me make sure I'm wiping the right
>> table? Also please let me know if this is urgent: seems like a quite
>> delicate matter and since I'm having a bit of fever now I'm afraid I'd
>> mess up with the production db :)
>>
>> Sanne
>>
>> On 15 January 2016 at 22:09, Steve Ebersole <steve at hibernate.org> wrote:
>> > Sorry, I have no idea.  That information is not listed in our private
>> > wiki
>> > area.  For anyone who knows this information, could you also update that
>> > resources page?
>> >
>> > On Fri, Jan 15, 2016 at 4:57 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> I tried to import the last 24 hour forum spam emails form
>> >> https://www.stopforumspam.com/, which is around 50k email entries.
>> >>
>> >> The email were imported, but now the banned email page of the forum
>> >> doesn't
>> >> load anymore.
>> >> The problem is related to how phpBB renders the page since there's a
>> >> dropdown where all emails must listed.
>> >>
>> >> Could someone delete a part of those entries or give me access to the
>> >> DB so
>> >> I can remove them myself?
>> >>
>> >> Vlad
>> >> _______________________________________________
>> >> 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 mihalcea.vlad at gmail.com  Sat Jan 16 08:18:36 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Sat, 16 Jan 2016 15:18:36 +0200
Subject: [hibernate-dev] Forum database banned emails issue
In-Reply-To: <CAFm4XO2=fgYqB9728jvnh_eX5DhSYziUtXoqAxXxDkH7W9_-6w@mail.gmail.com>
References: <CA+gWKMDwq+yB5w7zBWL9apNX5hAJLGyeJa0qWCm9oe0JEg5gFg@mail.gmail.com>
	<CAFdSV9tGxO7BuZzJbFFYcQQnJdkeP2puR+NujvtTbqQy=SJ0Kw@mail.gmail.com>
	<CAFm4XO1LYe0guz9VK=SLzNC7zS4uqpj6tv9LV4MQRVhqy9DY_Q@mail.gmail.com>
	<CA+gWKMAqXbYThS-5YKc1M+eoqGZU0iAP3YJx0dFfW6=yuy+sqw@mail.gmail.com>
	<CAFm4XO2=fgYqB9728jvnh_eX5DhSYziUtXoqAxXxDkH7W9_-6w@mail.gmail.com>
Message-ID: <CA+gWKMAp-SQQ81ekcRwny_bFX5n2PQ-Q_O5eyp+Be9-FWkizsQ@mail.gmail.com>

I tried to access this page:

https://developer.jboss.org/wiki/ForumsAdministrationAccess

But I get:

Unauthorized


Access to this place or content is restricted. If you think this is a
mistake, please contact your administrator or the person who directed you
here.

On Sat, Jan 16, 2016 at 3:05 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I Vlad,
> I'm sorry, it seems my credentials expired. I opened a ticket, it
> might take some time though.
> You might want to open a ticket to get credentials too.
>
> Sanne
>
> On 16 January 2016 at 11:42, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> > Thanks Sanne,
> >
> > In the Administration Control Panel -> Maintenance, there's the Admin
> log.
> > You can see there the emails that I added to the ban, along with the date
> > they were submitted: Fri Jan 15, 2016 9:16 am
> >
> > I was thinking of deleting 5k emails from the ban list that were added at
> > that date.
> > I hope the DB records the time-stamp info, or at least we can use the
> Ids.
> >
> > I added those progressively and when there were 40k/45k entries, the page
> > was still loading.
> >
> > Vlad
> >
> > On Sat, Jan 16, 2016 at 1:25 PM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> It is documented here:
> >>  - https://developer.jboss.org/wiki/ForumsAdministrationAccess
> >>
> >> However as you can see it's not easy to get to. You need to hop around
> >> several security checks and get authorization from each party.
> >>
> >> I can help with this as I already have access - if I remember the
> >> whole process ;-) - but you'll have to describe what you want me to do
> >> exactly. Do I need to wipe a large amount of data from a table? And do
> >> you have some example data to help me make sure I'm wiping the right
> >> table? Also please let me know if this is urgent: seems like a quite
> >> delicate matter and since I'm having a bit of fever now I'm afraid I'd
> >> mess up with the production db :)
> >>
> >> Sanne
> >>
> >> On 15 January 2016 at 22:09, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> > Sorry, I have no idea.  That information is not listed in our private
> >> > wiki
> >> > area.  For anyone who knows this information, could you also update
> that
> >> > resources page?
> >> >
> >> > On Fri, Jan 15, 2016 at 4:57 AM Vlad Mihalcea <
> mihalcea.vlad at gmail.com>
> >> > wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> I tried to import the last 24 hour forum spam emails form
> >> >> https://www.stopforumspam.com/, which is around 50k email entries.
> >> >>
> >> >> The email were imported, but now the banned email page of the forum
> >> >> doesn't
> >> >> load anymore.
> >> >> The problem is related to how phpBB renders the page since there's a
> >> >> dropdown where all emails must listed.
> >> >>
> >> >> Could someone delete a part of those entries or give me access to the
> >> >> DB so
> >> >> I can remove them myself?
> >> >>
> >> >> Vlad
> >> >> _______________________________________________
> >> >> 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  Mon Jan 18 21:44:14 2016
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 18 Jan 2016 18:44:14 -0800
Subject: [hibernate-dev] hbm mapping files and EntityManager
Message-ID: <CAFDzhiQS4QC5+j7NvcQCK1LPuh1RQwFw9t6LHXSQDeuhztpQQA@mail.gmail.com>

By default, hbm mapping files are detected when building Hibernate
EntityManager.

Is that expected?

I see that it is possible to override this behavior by setting
hibernate.archive.autodetection="".

I was surprised by the default. I would have thought that an application
using EntityManager would need to explicitly opt-in to use hbm files.

Thanks,
Gail

From gunnar at hibernate.org  Tue Jan 19 09:41:02 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 19 Jan 2016 15:41:02 +0100
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
Message-ID: <CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>

Hi Steve,

As discussed on IRC, I tried plugging in my own SchemaManagementTool
and delegates and letting them do the initialization work required for
OGM.

I am hitting a wall though when it comes to the usage in the
SchemaExport controller: As it's invoking doCreate() and doDrop()
right in the constructor with a "fake" target for delegating the SQL
statements, I am bitten by the fact that SchemaExport is instantiated
twice in SessionFactoryImpl (once for create, once for drop at
shutdown), so I see to invocations to doCreate() and doDrop(). Also I
am lacking the knowledge of what's passed as Target for the controller
invocation.

So I went ahead and changed SchemaExport to invoke SchemaCreator and
-Dropper only in execute(), passing them actual Target implementations
as it's done in SchemaUpdate, too. It's not yet what you described as
the ultimate goal (not looping back to Target), but IMO it's a step
into the right direction, not the least making things consistent
between SchemaExport and SchemaUpdate and also leaving APIs largely
unchanged for the time being. With that I should be able to do it on
the OGM side as you suggested, essentially ignoring the
Target/Exporter stuff.

I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231
for the change. Let me know what you think.

Cheers,

--Gunnar


2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> I am not sure I am a big fan of The String->Object change specifically.  In
> theory it sounds great.  But there is a major premise in schema tooling
> around the idea of the actions being reduce-able to Strings.  That's
> important not just for SQL, but for the idea of writing to a file as well.
> It also affects the whole concept of Exporter/Exportable.
>
> The ultimate design goal here is to unify schema creation and dropping
> across native and JPA requirements.  I just simply have not had the time to
> work on that.  This would all happen "behind" SchemaManagementTool and
> friends.  SchemaExport, etc are actually just controllers responsible for
> coordinating the calls into the SchemaManagementTool delegates.  The main
> problem at the moment IMO is that Target gets passed into these
> SchemaManagementTool delegates.  Ideally, and certainly this would fit with
> your case, I think we want SchemaManagementTool or its delegates to handle
> interpreting the "arguments".  This was part of the intent of developing
> the "CommandLineArgs" stuff that is used inside SchemaExport, etc now; the
> idea was to encapsulate the settings each tool needs to operate and isolate
> the process of building/interpreting those args.
>
> The next step I wanted to look at there was to morph CommandLineArgs into a
> more generic "parameter object" for initializing the actual
> SchemaManagementTool delegates.
>
> The idea is that the more we can push into SchemaManagementTool and its
> delegates the more pluggable this entire process becomes.  Ultimately, as I
> mentioned above, I just do not think it is feasible for ORM and OGM to
> share all of these implementation contracts.  Forcing a switch from String
> (the DDL) arguments to some amorphic Object reinforces that in my mind.
> But that would not stop OGM from completely swapping SchemaManagementTool
> and its delegates and simply not using Target, Exporters, etc.
>
>
> On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Hi Steve,
>>
>> One thing useful to have for OGM would be a generalization of the
>> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
>> all of them are "schemaless", e.g. Cassandra works with a fixed
>> schema, and while MongoDB largely is schemaless, we still want to
>> create stuff like indexes in the database.
>>
>> I took a look and found that SchemaManagementTool as a pluggable
>> service already goes halfway into that direction. The issue with it is
>> that I cannot replace the list of exporters used by SchemaExport nor
>> the list of tool targets used by SchemaUpdate. Having a pluggable
>> service allowing me to customize that with an OGM-specific
>> implementation should do the trick.
>>
>> As per some comments in the code, SchemaExport seems to be in some
>> intermediary state, where the ops are not executed directly through
>> the targets passed to SchemaCreator/Dropper but are read into String
>> arrays which are then passed on to separate exporters. I suppose part
>> of that work should be to consolidate this and basically follow the
>> same approach as used in SchemaUpdate?
>>
>> Another facet is that for some OGM grid dialects we'd need another
>> representation of commands than Strings, as not all the backends have
>> a DDL but expect API invocations for that purpose. For that it'd be
>> required to change Target#accept(String) into accept(Object) so we can
>> pass some kind of command object. File exports would only work in a
>> limited fashion, but we could live with that. Schema creation/dropping
>> bound to the SF lifecycle is what I am after here.
>>
>> I'd be willing to work on this once we agree on the general approach.
>>
>> Any thoughts?
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>>
>> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:
>> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> If you clean up the conflicts I can look for 5.1
>> >>
>> >
>> > Done!
>> >
>> > --
>> > Guillaume
>> > _______________________________________________
>> > 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 mihalcea.vlad at gmail.com  Tue Jan 19 10:16:20 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 19 Jan 2016 17:16:20 +0200
Subject: [hibernate-dev] The stable docs
Message-ID: <CA+gWKMBmKA2by8vo3v6HtO5veFO_nwahXeZmTYLz0bggp9zkNg@mail.gmail.com>

Hi,

I remember that the stable docs were fixed and they were pointing to 5.0.6,
but now, they are referring 4.0.1:

http://docs.jboss.org/hibernate/stable/core/javadocs/

Does the project release procedure copy the old docs onto the stable folder?

Vlad

From steve at hibernate.org  Tue Jan 19 10:17:45 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 Jan 2016 15:17:45 +0000
Subject: [hibernate-dev] The stable docs
In-Reply-To: <CA+gWKMBmKA2by8vo3v6HtO5veFO_nwahXeZmTYLz0bggp9zkNg@mail.gmail.com>
References: <CA+gWKMBmKA2by8vo3v6HtO5veFO_nwahXeZmTYLz0bggp9zkNg@mail.gmail.com>
Message-ID: <CAFdSV9u0GY-pV12HsxGpwdoLSXTpNCH0EHnV9wBZPLBWbrY5EQ@mail.gmail.com>

'stable' is just symlinks

On Tue, Jan 19, 2016 at 9:17 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi,
>
> I remember that the stable docs were fixed and they were pointing to 5.0.6,
> but now, they are referring 4.0.1:
>
> http://docs.jboss.org/hibernate/stable/core/javadocs/
>
> Does the project release procedure copy the old docs onto the stable
> folder?
>
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jan 19 10:18:29 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 Jan 2016 15:18:29 +0000
Subject: [hibernate-dev] hbm mapping files and EntityManager
In-Reply-To: <CAFDzhiQS4QC5+j7NvcQCK1LPuh1RQwFw9t6LHXSQDeuhztpQQA@mail.gmail.com>
References: <CAFDzhiQS4QC5+j7NvcQCK1LPuh1RQwFw9t6LHXSQDeuhztpQQA@mail.gmail.com>
Message-ID: <CAFdSV9vsDEUbA_KZDGiWdiGb7oM3JgH9iKzx1nxpyRk+1v835g@mail.gmail.com>

I am fairly certain this what Hibernate has always done.

On Mon, Jan 18, 2016 at 8:44 PM Gail Badner <gbadner at redhat.com> wrote:

> By default, hbm mapping files are detected when building Hibernate
> EntityManager.
>
> Is that expected?
>
> I see that it is possible to override this behavior by setting
> hibernate.archive.autodetection="".
>
> I was surprised by the default. I would have thought that an application
> using EntityManager would need to explicitly opt-in to use hbm files.
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jan 19 10:25:09 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 Jan 2016 15:25:09 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
Message-ID: <CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>

I'd like to get this work into 5.1.  But, as much as possible, I'd like to
get the ProperSolution in place rather than just a
StepInTheRightDirection.  If we need to push this date 2-4 weeks I am ok
with that.  That would help us coordinate with Infinispan 8.2 schedule
(iiuc) for hibernate-infinispan, not to mention I still have to review the
work Vlad has done on the docs again as well as polish the load-by-multi-id
API[1].

[1] Sanne still waiting on your feedback to the open question of internal
routing of those calls.

On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Steve,
>
> As discussed on IRC, I tried plugging in my own SchemaManagementTool
> and delegates and letting them do the initialization work required for
> OGM.
>
> I am hitting a wall though when it comes to the usage in the
> SchemaExport controller: As it's invoking doCreate() and doDrop()
> right in the constructor with a "fake" target for delegating the SQL
> statements, I am bitten by the fact that SchemaExport is instantiated
> twice in SessionFactoryImpl (once for create, once for drop at
> shutdown), so I see to invocations to doCreate() and doDrop(). Also I
> am lacking the knowledge of what's passed as Target for the controller
> invocation.
>
> So I went ahead and changed SchemaExport to invoke SchemaCreator and
> -Dropper only in execute(), passing them actual Target implementations
> as it's done in SchemaUpdate, too. It's not yet what you described as
> the ultimate goal (not looping back to Target), but IMO it's a step
> into the right direction, not the least making things consistent
> between SchemaExport and SchemaUpdate and also leaving APIs largely
> unchanged for the time being. With that I should be able to do it on
> the OGM side as you suggested, essentially ignoring the
> Target/Exporter stuff.
>
> I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231
> for the change. Let me know what you think.
>
> Cheers,
>
> --Gunnar
>
>
> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > I am not sure I am a big fan of The String->Object change specifically.
> In
> > theory it sounds great.  But there is a major premise in schema tooling
> > around the idea of the actions being reduce-able to Strings.  That's
> > important not just for SQL, but for the idea of writing to a file as
> well.
> > It also affects the whole concept of Exporter/Exportable.
> >
> > The ultimate design goal here is to unify schema creation and dropping
> > across native and JPA requirements.  I just simply have not had the time
> to
> > work on that.  This would all happen "behind" SchemaManagementTool and
> > friends.  SchemaExport, etc are actually just controllers responsible for
> > coordinating the calls into the SchemaManagementTool delegates.  The main
> > problem at the moment IMO is that Target gets passed into these
> > SchemaManagementTool delegates.  Ideally, and certainly this would fit
> with
> > your case, I think we want SchemaManagementTool or its delegates to
> handle
> > interpreting the "arguments".  This was part of the intent of developing
> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now;
> the
> > idea was to encapsulate the settings each tool needs to operate and
> isolate
> > the process of building/interpreting those args.
> >
> > The next step I wanted to look at there was to morph CommandLineArgs
> into a
> > more generic "parameter object" for initializing the actual
> > SchemaManagementTool delegates.
> >
> > The idea is that the more we can push into SchemaManagementTool and its
> > delegates the more pluggable this entire process becomes.  Ultimately,
> as I
> > mentioned above, I just do not think it is feasible for ORM and OGM to
> > share all of these implementation contracts.  Forcing a switch from
> String
> > (the DDL) arguments to some amorphic Object reinforces that in my mind.
> > But that would not stop OGM from completely swapping SchemaManagementTool
> > and its delegates and simply not using Target, Exporters, etc.
> >
> >
> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >
> >> Hi Steve,
> >>
> >> One thing useful to have for OGM would be a generalization of the
> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
> >> all of them are "schemaless", e.g. Cassandra works with a fixed
> >> schema, and while MongoDB largely is schemaless, we still want to
> >> create stuff like indexes in the database.
> >>
> >> I took a look and found that SchemaManagementTool as a pluggable
> >> service already goes halfway into that direction. The issue with it is
> >> that I cannot replace the list of exporters used by SchemaExport nor
> >> the list of tool targets used by SchemaUpdate. Having a pluggable
> >> service allowing me to customize that with an OGM-specific
> >> implementation should do the trick.
> >>
> >> As per some comments in the code, SchemaExport seems to be in some
> >> intermediary state, where the ops are not executed directly through
> >> the targets passed to SchemaCreator/Dropper but are read into String
> >> arrays which are then passed on to separate exporters. I suppose part
> >> of that work should be to consolidate this and basically follow the
> >> same approach as used in SchemaUpdate?
> >>
> >> Another facet is that for some OGM grid dialects we'd need another
> >> representation of commands than Strings, as not all the backends have
> >> a DDL but expect API invocations for that purpose. For that it'd be
> >> required to change Target#accept(String) into accept(Object) so we can
> >> pass some kind of command object. File exports would only work in a
> >> limited fashion, but we could live with that. Schema creation/dropping
> >> bound to the SF lifecycle is what I am after here.
> >>
> >> I'd be willing to work on this once we agree on the general approach.
> >>
> >> Any thoughts?
> >>
> >> Thanks,
> >>
> >> --Gunnar
> >>
> >>
> >>
> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:
> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >> >
> >> >> If you clean up the conflicts I can look for 5.1
> >> >>
> >> >
> >> > Done!
> >> >
> >> > --
> >> > Guillaume
> >> > _______________________________________________
> >> > 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  Tue Jan 19 10:31:10 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 19 Jan 2016 15:31:10 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
Message-ID: <CAFm4XO34XWeVCbs+2-a05XERaA_AO9Aq8FeKZu6Mqxvvp0m6mw@mail.gmail.com>

On 19 January 2016 at 15:25, Steve Ebersole <steve at hibernate.org> wrote:
> I'd like to get this work into 5.1.  But, as much as possible, I'd like to
> get the ProperSolution in place rather than just a
> StepInTheRightDirection.  If we need to push this date 2-4 weeks I am ok
> with that.  That would help us coordinate with Infinispan 8.2 schedule
> (iiuc) for hibernate-infinispan, not to mention I still have to review the
> work Vlad has done on the docs again as well as polish the load-by-multi-id
> API[1].
>
> [1] Sanne still waiting on your feedback to the open question of internal
> routing of those calls.

Hi Steve,
sorry I'm not sure what the question is. Do you have a link?

Thanks,
Sanne

From steve at hibernate.org  Tue Jan 19 13:04:11 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 Jan 2016 18:04:11 +0000
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <5698C041.8060904@redhat.com>
References: <5698C041.8060904@redhat.com>
Message-ID: <CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>

The docs are in a state of flux for 5.1.  For now your best bet is the
source: documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc

On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa <rvansa at redhat.com> wrote:

> Hi,
>
> I was about to fill some gaps in 2LC docs regarding improvements in
> 5.0/5.1, but when I took a look into 5.0 docs [1] there's close to
> nothing; is it by purpose? In 4.3 docs [2], there's much more on this
> subject. Am I looking in a wrong place?
>
> Radim
>
> [1]
>
> http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
> [2]
>
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue Jan 19 13:53:28 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 Jan 2016 18:53:28 +0000
Subject: [hibernate-dev] SQM and Query#getReturnTypes
Message-ID: <CAFdSV9tKJRMQwNspxvwcUmkyfmxp2-QFpto5LThCcHp4c_fVhA@mail.gmail.com>

There are a few reasons I want to remove Query#getReturnTypes.  At least in
its current form.  Currently it simply returns the Hibernate Type(s) that
the query will return.

One of the big reasons I want to remove this method is that it is simply
not expressive enough to handle some not-so-edge-cases like dynamic
instantiation queries (we'd have no idea about a Type for the
instantiation).

So the main question is whether to simply remove that method or whether
some representation of the Query return(s) is valuable.  If this
information is deemed valuable, the idea would be to develop a contract
that caters to both "normal selections" and dynamic instantiations.

From gbadner at redhat.com  Tue Jan 19 15:28:30 2016
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 19 Jan 2016 12:28:30 -0800
Subject: [hibernate-dev] hbm mapping files and EntityManager
In-Reply-To: <CAFdSV9vsDEUbA_KZDGiWdiGb7oM3JgH9iKzx1nxpyRk+1v835g@mail.gmail.com>
References: <CAFDzhiQS4QC5+j7NvcQCK1LPuh1RQwFw9t6LHXSQDeuhztpQQA@mail.gmail.com>
	<CAFdSV9vsDEUbA_KZDGiWdiGb7oM3JgH9iKzx1nxpyRk+1v835g@mail.gmail.com>
Message-ID: <CAFDzhiSLTmoYoo7KJsF-vxxjHuB1_em4AqJvUigUSt=naa=hNw@mail.gmail.com>

I see what happened. In 4.2, when exclude-unlisted-classes is true, hbm
files are not detected. [1]

This got broken in 4.3 and is still broken in 5.0. [2]

I've created HHH-10461 to fix this.

[1]
https://github.com/hibernate/hibernate-orm/blob/4.2/hibernate-entitymanager/src/main/java/org/hibernate/ejb/Ejb3Configuration.java#L829
[2]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/boot/archive/scan/internal/StandardScanOptions.java#L23

On Tue, Jan 19, 2016 at 7:18 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I am fairly certain this what Hibernate has always done.
>
> On Mon, Jan 18, 2016 at 8:44 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> By default, hbm mapping files are detected when building Hibernate
>> EntityManager.
>>
>> Is that expected?
>>
>> I see that it is possible to override this behavior by setting
>> hibernate.archive.autodetection="".
>>
>> I was surprised by the default. I would have thought that an application
>> using EntityManager would need to explicitly opt-in to use hbm files.
>>
>> Thanks,
>> Gail
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Tue Jan 19 17:30:30 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 Jan 2016 22:30:30 +0000
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
Message-ID: <CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>

Sanne, Gunnar any thoughts/input here?


On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk at gmail.com>
wrote:

> Hello, yes, you are absolutely right, the main concern here is that with
> new MultipleLoad API we got inconsistent behavior for loading using
> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
>
>
> What regarding my case, it is loading data from EAV model, with predefined
> scenarios.
>
>
> We have 3 tables:
>
>
> Objects[id ? pk, name, type_id, parent]
> Params[attr_id, value, object_id (fk to objects), show_order]
> References[ attr_id, reference, object_id( fk to objects), show_order]
>
>
> Also we have a data loading scenario configuration based on type_id,
> identifying set of params\references Entities and Object Entities
> referenced by References entity to be Eager load during loading Object
> Entities.
>
>
> We have more than 1k attributes and more than 100Gb of data in
> Object\Params\References entities
>
>
> So it is simple recursive loading task, as per me, the best place for it
> persister.load with optimized loader (at least without query hardparse on
> each multiloading, this could be done using custom Oracle\PostgreSQL
> datatype to pass array of ids as a bind variable in case of bulk load by
> Ids)
>
>
> PostgreSQL ex.:
> Select * from objects where id = any(?);
>
>
> If you could advise better solution to implement such scenario based on
> EAV Eager loading I will be very appreciated to you.
>
> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
>
>> Personally I think its a questions of semantics; to me a multi-id load
>> already implies/indicates a certain loading strategy (Loader).  You are
>> saying you'd like the ability to still decide a specific loading strategy
>> for multi-id loads.  I seriously doubt that is really what you want, but I
>> do understand the desire for consistency.  Maybe some others will chime in;
>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in terms
>> of integrating this with Search.
>>
>> Also, that was not the question I asked.  Specifically, what is it you
>> want to do that you cannot do given the current call chain?
>>
>>
>>
>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov <bulanovk at gmail.com>
>> wrote:
>>
>>> Hello Steve, as you asked moving our discussion about HHH-7572 in dev
>>> mail
>>> list.
>>>
>>>
>>>
>>> Regarding you question, in current architecture and implementation we
>>> have
>>> the following point to perform entity persistence customization.
>>>
>>> Annotation:
>>>
>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>>> which allows us to specify our own implementation of
>>>
>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>>> .
>>>
>>>
>>> One of its methods is:
>>>
>>>
>>>
>>> Object load(Serializable id,
>>>
>>>             Object optionalObject,
>>>
>>>             LockMode lockMode,
>>>
>>>             SessionImplementor session)
>>>
>>>      throws HibernateException
>>>
>>>
>>>
>>> Load an instance of the persistent class.
>>>
>>>
>>>
>>> and
>>>
>>>
>>>
>>> Object load(Serializable id,
>>>
>>>             Object optionalObject,
>>>
>>>             LockOptions lockOptions,
>>>
>>>             SessionImplementor session)
>>>
>>>      throws HibernateException
>>>
>>>
>>>
>>> Load an instance of the persistent class.
>>>
>>>
>>>
>>> These two methods allows to specify you own Loader implementation to load
>>> Entity by IDS,
>>>
>>> in mentioned issue this part of contract was ignored by changing call
>>> sequence on loading by multiple ids.
>>>
>>>
>>>
>>> By Single id;
>>>
>>>
>>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>>>
>>>
>>>
>>> By Multiple id:
>>>
>>>
>>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>>>
>>>
>>>
>>> So in new API for multiple load we lose at least 2 possible extension
>>> points: onLoadEvent, Persister.load (here we could customize loader -
>>> specify our own instead hardcoded one)
>>>
>>>
>>>
>>> From my point of view there should be the same approach to get entities
>>> by
>>> ID(independent multiple or single).
>>>
>>>
>>> So which one approach is correct and future-proof for Single id or
>>> Multiple
>>> Ids?
>>>
>>>
>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
>>> notifications at github.com> ???????:
>>>
>>> > Customize how? Loader still calls into the persister. Persisters and
>>> > Loaders have a back-and-forth synergy.
>>> >
>>> > Also please discuss this on the hibernate-dev mailing list so others
>>> can be
>>> > involved.
>>> >
>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>>> > notifications at github.com>
>>> > wrote:
>>> >
>>> > > Hello Steve, could you be so kind to advice why we have different
>>> > behavior
>>> > > for loading by single id and multiple ids?
>>> > >
>>> > > In Case of single id, loading is going through
>>> > > session->IdentifierLoadAccess->event->persister->Loader
>>> > > In Case of multiple ids, loading is going through
>>> > > session->MultiIdentifierLoadAccess->Loader
>>> > >
>>> > > So in case of load by single id it is possible to cutomize loading of
>>> > > Entify using persister, but in new introduced API we lost this
>>> > posibility.
>>> > >
>>> > > ?
>>> > > Reply to this email directly or view it on GitHub
>>> > > <
>>> >
>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>>> > >
>>> > > .
>>> > >
>>> >
>>> > ?
>>> > Reply to this email directly or view it on GitHub
>>> > <
>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>>> >
>>> > .
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>

From steve at hibernate.org  Tue Jan 19 17:45:57 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 Jan 2016 22:45:57 +0000
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
	<CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
Message-ID: <CAFdSV9uHxEEaxv3un8+-eYXK051uvexgkKN6jarzqUJEoJLbfw@mail.gmail.com>

Konstantin, I am not sure what you are asking exactly, mainly in your last
email..

>From your first reply it sounded like you just wanted the call stack here
to route through EntityPersister (MultiIdentifierLoadAccess ->
EntityPersister -> [some-multi-id-load-loader]) rather than directly going
to DynamicBatchingEntityLoader (MultiIdentifierLoadAccess ->
DynamicBatchingEntityLoader).
That is certainly something I am willing to consider.

You had mentioned LoadEvent(Listener); personally I don't see the argument
for having a new event/listener for this.  It would be consistent,
certainly, but I am just not sure what we'd gain.

So I can specifically see the calls here going MultiIdentifierLoadAccess ->
(*) EntityPersister#multiLoad -> (*) MultiIdentifierLoader#multiLoad


[*] - new method/contract




On Tue, Jan 19, 2016 at 4:30 PM Steve Ebersole <steve at hibernate.org> wrote:

> Sanne, Gunnar any thoughts/input here?
>
>
> On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk at gmail.com>
> wrote:
>
>> Hello, yes, you are absolutely right, the main concern here is that with
>> new MultipleLoad API we got inconsistent behavior for loading using
>> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
>>
>>
>> What regarding my case, it is loading data from EAV model, with
>> predefined scenarios.
>>
>>
>> We have 3 tables:
>>
>>
>> Objects[id ? pk, name, type_id, parent]
>> Params[attr_id, value, object_id (fk to objects), show_order]
>> References[ attr_id, reference, object_id( fk to objects), show_order]
>>
>>
>> Also we have a data loading scenario configuration based on type_id,
>> identifying set of params\references Entities and Object Entities
>> referenced by References entity to be Eager load during loading Object
>> Entities.
>>
>>
>> We have more than 1k attributes and more than 100Gb of data in
>> Object\Params\References entities
>>
>>
>> So it is simple recursive loading task, as per me, the best place for it
>> persister.load with optimized loader (at least without query hardparse on
>> each multiloading, this could be done using custom Oracle\PostgreSQL
>> datatype to pass array of ids as a bind variable in case of bulk load by
>> Ids)
>>
>>
>> PostgreSQL ex.:
>> Select * from objects where id = any(?);
>>
>>
>> If you could advise better solution to implement such scenario based on
>> EAV Eager loading I will be very appreciated to you.
>>
>> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Personally I think its a questions of semantics; to me a multi-id load
>>> already implies/indicates a certain loading strategy (Loader).  You are
>>> saying you'd like the ability to still decide a specific loading strategy
>>> for multi-id loads.  I seriously doubt that is really what you want, but I
>>> do understand the desire for consistency.  Maybe some others will chime in;
>>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in terms
>>> of integrating this with Search.
>>>
>>> Also, that was not the question I asked.  Specifically, what is it you
>>> want to do that you cannot do given the current call chain?
>>>
>>>
>>>
>>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov <bulanovk at gmail.com>
>>> wrote:
>>>
>>>> Hello Steve, as you asked moving our discussion about HHH-7572 in dev
>>>> mail
>>>> list.
>>>>
>>>>
>>>>
>>>> Regarding you question, in current architecture and implementation we
>>>> have
>>>> the following point to perform entity persistence customization.
>>>>
>>>> Annotation:
>>>>
>>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>>>> which allows us to specify our own implementation of
>>>>
>>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>>>> .
>>>>
>>>>
>>>> One of its methods is:
>>>>
>>>>
>>>>
>>>> Object load(Serializable id,
>>>>
>>>>             Object optionalObject,
>>>>
>>>>             LockMode lockMode,
>>>>
>>>>             SessionImplementor session)
>>>>
>>>>      throws HibernateException
>>>>
>>>>
>>>>
>>>> Load an instance of the persistent class.
>>>>
>>>>
>>>>
>>>> and
>>>>
>>>>
>>>>
>>>> Object load(Serializable id,
>>>>
>>>>             Object optionalObject,
>>>>
>>>>             LockOptions lockOptions,
>>>>
>>>>             SessionImplementor session)
>>>>
>>>>      throws HibernateException
>>>>
>>>>
>>>>
>>>> Load an instance of the persistent class.
>>>>
>>>>
>>>>
>>>> These two methods allows to specify you own Loader implementation to
>>>> load
>>>> Entity by IDS,
>>>>
>>>> in mentioned issue this part of contract was ignored by changing call
>>>> sequence on loading by multiple ids.
>>>>
>>>>
>>>>
>>>> By Single id;
>>>>
>>>>
>>>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>>>>
>>>>
>>>>
>>>> By Multiple id:
>>>>
>>>>
>>>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>>>>
>>>>
>>>>
>>>> So in new API for multiple load we lose at least 2 possible extension
>>>> points: onLoadEvent, Persister.load (here we could customize loader -
>>>> specify our own instead hardcoded one)
>>>>
>>>>
>>>>
>>>> From my point of view there should be the same approach to get entities
>>>> by
>>>> ID(independent multiple or single).
>>>>
>>>>
>>>> So which one approach is correct and future-proof for Single id or
>>>> Multiple
>>>> Ids?
>>>>
>>>>
>>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
>>>> notifications at github.com> ???????:
>>>>
>>>> > Customize how? Loader still calls into the persister. Persisters and
>>>> > Loaders have a back-and-forth synergy.
>>>> >
>>>> > Also please discuss this on the hibernate-dev mailing list so others
>>>> can be
>>>> > involved.
>>>> >
>>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>>>> > notifications at github.com>
>>>> > wrote:
>>>> >
>>>> > > Hello Steve, could you be so kind to advice why we have different
>>>> > behavior
>>>> > > for loading by single id and multiple ids?
>>>> > >
>>>> > > In Case of single id, loading is going through
>>>> > > session->IdentifierLoadAccess->event->persister->Loader
>>>> > > In Case of multiple ids, loading is going through
>>>> > > session->MultiIdentifierLoadAccess->Loader
>>>> > >
>>>> > > So in case of load by single id it is possible to cutomize loading
>>>> of
>>>> > > Entify using persister, but in new introduced API we lost this
>>>> > posibility.
>>>> > >
>>>> > > ?
>>>> > > Reply to this email directly or view it on GitHub
>>>> > > <
>>>> >
>>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>>>> > >
>>>> > > .
>>>> > >
>>>> >
>>>> > ?
>>>> > Reply to this email directly or view it on GitHub
>>>> > <
>>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>>>> >
>>>> > .
>>>> >
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>

From bulanovk at gmail.com  Wed Jan 20 03:16:28 2016
From: bulanovk at gmail.com (Konstantin Bulanov)
Date: Wed, 20 Jan 2016 12:16:28 +0400
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFdSV9uHxEEaxv3un8+-eYXK051uvexgkKN6jarzqUJEoJLbfw@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
	<CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
	<CAFdSV9uHxEEaxv3un8+-eYXK051uvexgkKN6jarzqUJEoJLbfw@mail.gmail.com>
Message-ID: <CAHsorq6FkkeoS_Xpa1XizMbVAsRRu0xiYyWcnLBqRBd6XmY6FQ@mail.gmail.com>

Hello, Steve,


I absolutely agree with you regarding LoadEvent, but if LoadEvent will be
omitted and it will be possible to implement custom MultiIdentifierLoader,  it
is better to move L2 and L1 cache support to one place, for example to
MultiIdentifierLoadAccess (right now I couldn?t find where multiLoad stack
works with L2 cache ).


So if we a goes with proposed version (MultiIdentifierLoadAccess -> (*)
EntityPersister#multiLoad -> (*) MultiIdentifierLoader#multiLoad) it will
give a possibility to use same(customized) loader as for loading by single
id and restore framework consistent behavior.

2016-01-20 2:45 GMT+04:00 Steve Ebersole <steve at hibernate.org>:

> Konstantin, I am not sure what you are asking exactly, mainly in your last
> email..
>
> From your first reply it sounded like you just wanted the call stack here
> to route through EntityPersister (MultiIdentifierLoadAccess ->
> EntityPersister -> [some-multi-id-load-loader]) rather than directly going
> to DynamicBatchingEntityLoader (MultiIdentifierLoadAccess -> DynamicBatchingEntityLoader).
> That is certainly something I am willing to consider.
>
> You had mentioned LoadEvent(Listener); personally I don't see the argument
> for having a new event/listener for this.  It would be consistent,
> certainly, but I am just not sure what we'd gain.
>
> So I can specifically see the calls here going MultiIdentifierLoadAccess
> -> (*) EntityPersister#multiLoad -> (*) MultiIdentifierLoader#multiLoad
>
>
> [*] - new method/contract
>
>
>
>
> On Tue, Jan 19, 2016 at 4:30 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Sanne, Gunnar any thoughts/input here?
>>
>>
>> On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk at gmail.com>
>> wrote:
>>
>>> Hello, yes, you are absolutely right, the main concern here is that with
>>> new MultipleLoad API we got inconsistent behavior for loading using
>>> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
>>>
>>>
>>> What regarding my case, it is loading data from EAV model, with
>>> predefined scenarios.
>>>
>>>
>>> We have 3 tables:
>>>
>>>
>>> Objects[id ? pk, name, type_id, parent]
>>> Params[attr_id, value, object_id (fk to objects), show_order]
>>> References[ attr_id, reference, object_id( fk to objects), show_order]
>>>
>>>
>>> Also we have a data loading scenario configuration based on type_id,
>>> identifying set of params\references Entities and Object Entities
>>> referenced by References entity to be Eager load during loading Object
>>> Entities.
>>>
>>>
>>> We have more than 1k attributes and more than 100Gb of data in
>>> Object\Params\References entities
>>>
>>>
>>> So it is simple recursive loading task, as per me, the best place for it
>>> persister.load with optimized loader (at least without query hardparse on
>>> each multiloading, this could be done using custom Oracle\PostgreSQL
>>> datatype to pass array of ids as a bind variable in case of bulk load by
>>> Ids)
>>>
>>>
>>> PostgreSQL ex.:
>>> Select * from objects where id = any(?);
>>>
>>>
>>> If you could advise better solution to implement such scenario based on
>>> EAV Eager loading I will be very appreciated to you.
>>>
>>> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> Personally I think its a questions of semantics; to me a multi-id load
>>>> already implies/indicates a certain loading strategy (Loader).  You are
>>>> saying you'd like the ability to still decide a specific loading strategy
>>>> for multi-id loads.  I seriously doubt that is really what you want, but I
>>>> do understand the desire for consistency.  Maybe some others will chime in;
>>>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in terms
>>>> of integrating this with Search.
>>>>
>>>> Also, that was not the question I asked.  Specifically, what is it you
>>>> want to do that you cannot do given the current call chain?
>>>>
>>>>
>>>>
>>>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov <bulanovk at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello Steve, as you asked moving our discussion about HHH-7572 in dev
>>>>> mail
>>>>> list.
>>>>>
>>>>>
>>>>>
>>>>> Regarding you question, in current architecture and implementation we
>>>>> have
>>>>> the following point to perform entity persistence customization.
>>>>>
>>>>> Annotation:
>>>>>
>>>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>>>>> which allows us to specify our own implementation of
>>>>>
>>>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>>>>> .
>>>>>
>>>>>
>>>>> One of its methods is:
>>>>>
>>>>>
>>>>>
>>>>> Object load(Serializable id,
>>>>>
>>>>>             Object optionalObject,
>>>>>
>>>>>             LockMode lockMode,
>>>>>
>>>>>             SessionImplementor session)
>>>>>
>>>>>      throws HibernateException
>>>>>
>>>>>
>>>>>
>>>>> Load an instance of the persistent class.
>>>>>
>>>>>
>>>>>
>>>>> and
>>>>>
>>>>>
>>>>>
>>>>> Object load(Serializable id,
>>>>>
>>>>>             Object optionalObject,
>>>>>
>>>>>             LockOptions lockOptions,
>>>>>
>>>>>             SessionImplementor session)
>>>>>
>>>>>      throws HibernateException
>>>>>
>>>>>
>>>>>
>>>>> Load an instance of the persistent class.
>>>>>
>>>>>
>>>>>
>>>>> These two methods allows to specify you own Loader implementation to
>>>>> load
>>>>> Entity by IDS,
>>>>>
>>>>> in mentioned issue this part of contract was ignored by changing call
>>>>> sequence on loading by multiple ids.
>>>>>
>>>>>
>>>>>
>>>>> By Single id;
>>>>>
>>>>>
>>>>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>>>>>
>>>>>
>>>>>
>>>>> By Multiple id:
>>>>>
>>>>>
>>>>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>>>>>
>>>>>
>>>>>
>>>>> So in new API for multiple load we lose at least 2 possible extension
>>>>> points: onLoadEvent, Persister.load (here we could customize loader -
>>>>> specify our own instead hardcoded one)
>>>>>
>>>>>
>>>>>
>>>>> From my point of view there should be the same approach to get
>>>>> entities by
>>>>> ID(independent multiple or single).
>>>>>
>>>>>
>>>>> So which one approach is correct and future-proof for Single id or
>>>>> Multiple
>>>>> Ids?
>>>>>
>>>>>
>>>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
>>>>> notifications at github.com> ???????:
>>>>>
>>>>> > Customize how? Loader still calls into the persister. Persisters and
>>>>> > Loaders have a back-and-forth synergy.
>>>>> >
>>>>> > Also please discuss this on the hibernate-dev mailing list so others
>>>>> can be
>>>>> > involved.
>>>>> >
>>>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>>>>> > notifications at github.com>
>>>>> > wrote:
>>>>> >
>>>>> > > Hello Steve, could you be so kind to advice why we have different
>>>>> > behavior
>>>>> > > for loading by single id and multiple ids?
>>>>> > >
>>>>> > > In Case of single id, loading is going through
>>>>> > > session->IdentifierLoadAccess->event->persister->Loader
>>>>> > > In Case of multiple ids, loading is going through
>>>>> > > session->MultiIdentifierLoadAccess->Loader
>>>>> > >
>>>>> > > So in case of load by single id it is possible to cutomize loading
>>>>> of
>>>>> > > Entify using persister, but in new introduced API we lost this
>>>>> > posibility.
>>>>> > >
>>>>> > > ?
>>>>> > > Reply to this email directly or view it on GitHub
>>>>> > > <
>>>>> >
>>>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>>>>> > >
>>>>> > > .
>>>>> > >
>>>>> >
>>>>> > ?
>>>>> > Reply to this email directly or view it on GitHub
>>>>> > <
>>>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>>>>> >
>>>>> > .
>>>>> >
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>>>

From rvansa at redhat.com  Wed Jan 20 04:32:43 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Wed, 20 Jan 2016 10:32:43 +0100
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
Message-ID: <569F543B.7090304@redhat.com>

I would say that the best source is 4.x docs, since the cited source is 
what I describe by 'close to nothing'.

I understand that for 5.1 the transformation might be unfinished, but I 
was surprised by the same for 5.0 - missing information that's written, 
maybe just not formatted properly for asciiidoc. In such case, link to 
appropriate chapter in older docs would be useful.

Radim

On 01/19/2016 07:04 PM, Steve Ebersole wrote:
> The docs are in a state of flux for 5.1.  For now your best bet is the 
> source: documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc
>
> On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     Hi,
>
>     I was about to fill some gaps in 2LC docs regarding improvements in
>     5.0/5.1, but when I took a look into 5.0 docs [1] there's close to
>     nothing; is it by purpose? In 4.3 docs [2], there's much more on this
>     subject. Am I looking in a wrong place?
>
>     Radim
>
>     [1]
>     http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
>     [2]
>     http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
>
>     --
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From gunnar at hibernate.org  Wed Jan 20 04:42:24 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 20 Jan 2016 10:42:24 +0100
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
	<CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
Message-ID: <CADGJaX_cHBYjm8As6yV6hoZzpT2AQNbmXXxmRsX715VHvACxtQ@mail.gmail.com>

The direct link to DynamicBatchingEntityLoaderBuilder makes it fail
with OGM; So yes, going through EntityPersister for obtaining the
right loader would be great so we can make multi-id-load work with
OGM.

2016-01-19 23:30 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> Sanne, Gunnar any thoughts/input here?
>
>
> On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk at gmail.com>
> wrote:
>
>> Hello, yes, you are absolutely right, the main concern here is that with
>> new MultipleLoad API we got inconsistent behavior for loading using
>> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
>>
>>
>> What regarding my case, it is loading data from EAV model, with predefined
>> scenarios.
>>
>>
>> We have 3 tables:
>>
>>
>> Objects[id ? pk, name, type_id, parent]
>> Params[attr_id, value, object_id (fk to objects), show_order]
>> References[ attr_id, reference, object_id( fk to objects), show_order]
>>
>>
>> Also we have a data loading scenario configuration based on type_id,
>> identifying set of params\references Entities and Object Entities
>> referenced by References entity to be Eager load during loading Object
>> Entities.
>>
>>
>> We have more than 1k attributes and more than 100Gb of data in
>> Object\Params\References entities
>>
>>
>> So it is simple recursive loading task, as per me, the best place for it
>> persister.load with optimized loader (at least without query hardparse on
>> each multiloading, this could be done using custom Oracle\PostgreSQL
>> datatype to pass array of ids as a bind variable in case of bulk load by
>> Ids)
>>
>>
>> PostgreSQL ex.:
>> Select * from objects where id = any(?);
>>
>>
>> If you could advise better solution to implement such scenario based on
>> EAV Eager loading I will be very appreciated to you.
>>
>> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Personally I think its a questions of semantics; to me a multi-id load
>>> already implies/indicates a certain loading strategy (Loader).  You are
>>> saying you'd like the ability to still decide a specific loading strategy
>>> for multi-id loads.  I seriously doubt that is really what you want, but I
>>> do understand the desire for consistency.  Maybe some others will chime in;
>>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in terms
>>> of integrating this with Search.
>>>
>>> Also, that was not the question I asked.  Specifically, what is it you
>>> want to do that you cannot do given the current call chain?
>>>
>>>
>>>
>>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov <bulanovk at gmail.com>
>>> wrote:
>>>
>>>> Hello Steve, as you asked moving our discussion about HHH-7572 in dev
>>>> mail
>>>> list.
>>>>
>>>>
>>>>
>>>> Regarding you question, in current architecture and implementation we
>>>> have
>>>> the following point to perform entity persistence customization.
>>>>
>>>> Annotation:
>>>>
>>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>>>> which allows us to specify our own implementation of
>>>>
>>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>>>> .
>>>>
>>>>
>>>> One of its methods is:
>>>>
>>>>
>>>>
>>>> Object load(Serializable id,
>>>>
>>>>             Object optionalObject,
>>>>
>>>>             LockMode lockMode,
>>>>
>>>>             SessionImplementor session)
>>>>
>>>>      throws HibernateException
>>>>
>>>>
>>>>
>>>> Load an instance of the persistent class.
>>>>
>>>>
>>>>
>>>> and
>>>>
>>>>
>>>>
>>>> Object load(Serializable id,
>>>>
>>>>             Object optionalObject,
>>>>
>>>>             LockOptions lockOptions,
>>>>
>>>>             SessionImplementor session)
>>>>
>>>>      throws HibernateException
>>>>
>>>>
>>>>
>>>> Load an instance of the persistent class.
>>>>
>>>>
>>>>
>>>> These two methods allows to specify you own Loader implementation to load
>>>> Entity by IDS,
>>>>
>>>> in mentioned issue this part of contract was ignored by changing call
>>>> sequence on loading by multiple ids.
>>>>
>>>>
>>>>
>>>> By Single id;
>>>>
>>>>
>>>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>>>>
>>>>
>>>>
>>>> By Multiple id:
>>>>
>>>>
>>>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>>>>
>>>>
>>>>
>>>> So in new API for multiple load we lose at least 2 possible extension
>>>> points: onLoadEvent, Persister.load (here we could customize loader -
>>>> specify our own instead hardcoded one)
>>>>
>>>>
>>>>
>>>> From my point of view there should be the same approach to get entities
>>>> by
>>>> ID(independent multiple or single).
>>>>
>>>>
>>>> So which one approach is correct and future-proof for Single id or
>>>> Multiple
>>>> Ids?
>>>>
>>>>
>>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
>>>> notifications at github.com> ???????:
>>>>
>>>> > Customize how? Loader still calls into the persister. Persisters and
>>>> > Loaders have a back-and-forth synergy.
>>>> >
>>>> > Also please discuss this on the hibernate-dev mailing list so others
>>>> can be
>>>> > involved.
>>>> >
>>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>>>> > notifications at github.com>
>>>> > wrote:
>>>> >
>>>> > > Hello Steve, could you be so kind to advice why we have different
>>>> > behavior
>>>> > > for loading by single id and multiple ids?
>>>> > >
>>>> > > In Case of single id, loading is going through
>>>> > > session->IdentifierLoadAccess->event->persister->Loader
>>>> > > In Case of multiple ids, loading is going through
>>>> > > session->MultiIdentifierLoadAccess->Loader
>>>> > >
>>>> > > So in case of load by single id it is possible to cutomize loading of
>>>> > > Entify using persister, but in new introduced API we lost this
>>>> > posibility.
>>>> > >
>>>> > > ?
>>>> > > Reply to this email directly or view it on GitHub
>>>> > > <
>>>> >
>>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>>>> > >
>>>> > > .
>>>> > >
>>>> >
>>>> > ?
>>>> > Reply to this email directly or view it on GitHub
>>>> > <
>>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>>>> >
>>>> > .
>>>> >
>>>> _______________________________________________
>>>> 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 Jan 20 04:46:00 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 20 Jan 2016 09:46:00 +0000
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
	<CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
Message-ID: <CAFm4XO2VNfKJgmcbj-TK8eXj3sNfdw92H9Yj72kmnJ6MJerBuw@mail.gmail.com>

Hi Steve,
Hibernate Search doesn't customize the loaders: if any we want to make
sure that whatever customization has been defined is being used by
Search as well.
Hibernate OGM does of course replace the default loaders; I'm not sure
how nicely that interacts with the user wanting to override it.

-- Sanne

On 19 January 2016 at 22:30, Steve Ebersole <steve at hibernate.org> wrote:
> Sanne, Gunnar any thoughts/input here?
>
>
> On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk at gmail.com>
> wrote:
>
>> Hello, yes, you are absolutely right, the main concern here is that with
>> new MultipleLoad API we got inconsistent behavior for loading using
>> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
>>
>>
>> What regarding my case, it is loading data from EAV model, with predefined
>> scenarios.
>>
>>
>> We have 3 tables:
>>
>>
>> Objects[id ? pk, name, type_id, parent]
>> Params[attr_id, value, object_id (fk to objects), show_order]
>> References[ attr_id, reference, object_id( fk to objects), show_order]
>>
>>
>> Also we have a data loading scenario configuration based on type_id,
>> identifying set of params\references Entities and Object Entities
>> referenced by References entity to be Eager load during loading Object
>> Entities.
>>
>>
>> We have more than 1k attributes and more than 100Gb of data in
>> Object\Params\References entities
>>
>>
>> So it is simple recursive loading task, as per me, the best place for it
>> persister.load with optimized loader (at least without query hardparse on
>> each multiloading, this could be done using custom Oracle\PostgreSQL
>> datatype to pass array of ids as a bind variable in case of bulk load by
>> Ids)
>>
>>
>> PostgreSQL ex.:
>> Select * from objects where id = any(?);
>>
>>
>> If you could advise better solution to implement such scenario based on
>> EAV Eager loading I will be very appreciated to you.
>>
>> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Personally I think its a questions of semantics; to me a multi-id load
>>> already implies/indicates a certain loading strategy (Loader).  You are
>>> saying you'd like the ability to still decide a specific loading strategy
>>> for multi-id loads.  I seriously doubt that is really what you want, but I
>>> do understand the desire for consistency.  Maybe some others will chime in;
>>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in terms
>>> of integrating this with Search.
>>>
>>> Also, that was not the question I asked.  Specifically, what is it you
>>> want to do that you cannot do given the current call chain?
>>>
>>>
>>>
>>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov <bulanovk at gmail.com>
>>> wrote:
>>>
>>>> Hello Steve, as you asked moving our discussion about HHH-7572 in dev
>>>> mail
>>>> list.
>>>>
>>>>
>>>>
>>>> Regarding you question, in current architecture and implementation we
>>>> have
>>>> the following point to perform entity persistence customization.
>>>>
>>>> Annotation:
>>>>
>>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>>>> which allows us to specify our own implementation of
>>>>
>>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>>>> .
>>>>
>>>>
>>>> One of its methods is:
>>>>
>>>>
>>>>
>>>> Object load(Serializable id,
>>>>
>>>>             Object optionalObject,
>>>>
>>>>             LockMode lockMode,
>>>>
>>>>             SessionImplementor session)
>>>>
>>>>      throws HibernateException
>>>>
>>>>
>>>>
>>>> Load an instance of the persistent class.
>>>>
>>>>
>>>>
>>>> and
>>>>
>>>>
>>>>
>>>> Object load(Serializable id,
>>>>
>>>>             Object optionalObject,
>>>>
>>>>             LockOptions lockOptions,
>>>>
>>>>             SessionImplementor session)
>>>>
>>>>      throws HibernateException
>>>>
>>>>
>>>>
>>>> Load an instance of the persistent class.
>>>>
>>>>
>>>>
>>>> These two methods allows to specify you own Loader implementation to load
>>>> Entity by IDS,
>>>>
>>>> in mentioned issue this part of contract was ignored by changing call
>>>> sequence on loading by multiple ids.
>>>>
>>>>
>>>>
>>>> By Single id;
>>>>
>>>>
>>>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>>>>
>>>>
>>>>
>>>> By Multiple id:
>>>>
>>>>
>>>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>>>>
>>>>
>>>>
>>>> So in new API for multiple load we lose at least 2 possible extension
>>>> points: onLoadEvent, Persister.load (here we could customize loader -
>>>> specify our own instead hardcoded one)
>>>>
>>>>
>>>>
>>>> From my point of view there should be the same approach to get entities
>>>> by
>>>> ID(independent multiple or single).
>>>>
>>>>
>>>> So which one approach is correct and future-proof for Single id or
>>>> Multiple
>>>> Ids?
>>>>
>>>>
>>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
>>>> notifications at github.com> ???????:
>>>>
>>>> > Customize how? Loader still calls into the persister. Persisters and
>>>> > Loaders have a back-and-forth synergy.
>>>> >
>>>> > Also please discuss this on the hibernate-dev mailing list so others
>>>> can be
>>>> > involved.
>>>> >
>>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>>>> > notifications at github.com>
>>>> > wrote:
>>>> >
>>>> > > Hello Steve, could you be so kind to advice why we have different
>>>> > behavior
>>>> > > for loading by single id and multiple ids?
>>>> > >
>>>> > > In Case of single id, loading is going through
>>>> > > session->IdentifierLoadAccess->event->persister->Loader
>>>> > > In Case of multiple ids, loading is going through
>>>> > > session->MultiIdentifierLoadAccess->Loader
>>>> > >
>>>> > > So in case of load by single id it is possible to cutomize loading of
>>>> > > Entify using persister, but in new introduced API we lost this
>>>> > posibility.
>>>> > >
>>>> > > ?
>>>> > > Reply to this email directly or view it on GitHub
>>>> > > <
>>>> >
>>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>>>> > >
>>>> > > .
>>>> > >
>>>> >
>>>> > ?
>>>> > Reply to this email directly or view it on GitHub
>>>> > <
>>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>>>> >
>>>> > .
>>>> >
>>>> _______________________________________________
>>>> 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 mihalcea.vlad at gmail.com  Wed Jan 20 04:57:51 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 20 Jan 2016 11:57:51 +0200
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <569F543B.7090304@redhat.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
Message-ID: <CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>

Hi Radim,

I'm now filling in the missing sections on the Caching chapter in the 5.1
User Guide.

Vlad

On Wed, Jan 20, 2016 at 11:32 AM, Radim Vansa <rvansa at redhat.com> wrote:

> I would say that the best source is 4.x docs, since the cited source is
> what I describe by 'close to nothing'.
>
> I understand that for 5.1 the transformation might be unfinished, but I
> was surprised by the same for 5.0 - missing information that's written,
> maybe just not formatted properly for asciiidoc. In such case, link to
> appropriate chapter in older docs would be useful.
>
> Radim
>
> On 01/19/2016 07:04 PM, Steve Ebersole wrote:
> > The docs are in a state of flux for 5.1.  For now your best bet is the
> > source:
> documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc
> >
> > On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa <rvansa at redhat.com
> > <mailto:rvansa at redhat.com>> wrote:
> >
> >     Hi,
> >
> >     I was about to fill some gaps in 2LC docs regarding improvements in
> >     5.0/5.1, but when I took a look into 5.0 docs [1] there's close to
> >     nothing; is it by purpose? In 4.3 docs [2], there's much more on this
> >     subject. Am I looking in a wrong place?
> >
> >     Radim
> >
> >     [1]
> >
> http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
> >     [2]
> >
> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
> >
> >     --
> >     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
> >     JBoss Performance Team
> >
> >     _______________________________________________
> >     hibernate-dev mailing list
> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed Jan 20 05:36:52 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 20 Jan 2016 10:36:52 +0000
Subject: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI job
Message-ID: <CAFm4XO0VhAa7exaqH6z4D4TgE7FhXfYKMYMicVJSXF4p67wsoA@mail.gmail.com>

I'm puzzled.
There seems to be a javax.validation related issue which is failing
the integration tests running on Arquillian / WildFly for the
Hibernate Search / WildFly tests on JDK9.

http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console

But more importantly.. anyone has a clue on why the build is marked as
"SUCCESS" ?

You actually have to notice the failures in the logs to figure out
that it's not successful at all;
search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.

Sanne

From daltodavide at gmail.com  Wed Jan 20 06:11:23 2016
From: daltodavide at gmail.com (Davide D'Alto)
Date: Wed, 20 Jan 2016 11:11:23 +0000
Subject: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI
	job
In-Reply-To: <CAFm4XO0VhAa7exaqH6z4D4TgE7FhXfYKMYMicVJSXF4p67wsoA@mail.gmail.com>
References: <CAFm4XO0VhAa7exaqH6z4D4TgE7FhXfYKMYMicVJSXF4p67wsoA@mail.gmail.com>
Message-ID: <CANoTJYMzq-f3R5rj1uZHoGV2p3SWVz3mtS7eUg1zxfWb2Zvf2g@mail.gmail.com>

I wonder if it's a problem of integration between Jenkins and the maven
failsafe plugin

On Wed, Jan 20, 2016 at 10:36 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I'm puzzled.
> There seems to be a javax.validation related issue which is failing
> the integration tests running on Arquillian / WildFly for the
> Hibernate Search / WildFly tests on JDK9.
>
>
> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>
> But more importantly.. anyone has a clue on why the build is marked as
> "SUCCESS" ?
>
> You actually have to notice the failures in the logs to figure out
> that it's not successful at all;
> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Jan 20 06:35:30 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 20 Jan 2016 12:35:30 +0100
Subject: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI
	job
In-Reply-To: <CAFm4XO0VhAa7exaqH6z4D4TgE7FhXfYKMYMicVJSXF4p67wsoA@mail.gmail.com>
References: <CAFm4XO0VhAa7exaqH6z4D4TgE7FhXfYKMYMicVJSXF4p67wsoA@mail.gmail.com>
Message-ID: <CADGJaX85SsQJ_dz08YkZqvsY+nOBK5gXxoasR4FMO8DuxNzwsQ@mail.gmail.com>

Concerning the original error, we are bitten by the changed version
number scheme in JDK 9 (we evaluate the Java version to enable
specific code when running on JDK 8 or later): We are expecting a
dot-separated version string such as "1.8.0", but JDK 9 returns only
"9" as proposed by JEP 223 [1].

I've filed HV-1048 [2] for that.

Regarding the Maven/Jenkins issue I am not fully sure, the FailSafe
plug-in detects "There are test failures" during the verify phase but
for some reason it doesn't fail the build. It's an issue on the Maven
side, not Jenkins; Test failure just mark a build (of Maven job type)
as unstable (yellow), not as failed (red). Maybe you try the latest
FailSafe version (2.19.1)?

--Gunnar

[1] http://openjdk.java.net/jeps/223
[2] https://hibernate.atlassian.net/browse/HV-1048


2016-01-20 11:36 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> I'm puzzled.
> There seems to be a javax.validation related issue which is failing
> the integration tests running on Arquillian / WildFly for the
> Hibernate Search / WildFly tests on JDK9.
>
> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>
> But more importantly.. anyone has a clue on why the build is marked as
> "SUCCESS" ?
>
> You actually have to notice the failures in the logs to figure out
> that it's not successful at all;
> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Jan 20 06:39:25 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 20 Jan 2016 12:39:25 +0100
Subject: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI
	job
In-Reply-To: <CADGJaX85SsQJ_dz08YkZqvsY+nOBK5gXxoasR4FMO8DuxNzwsQ@mail.gmail.com>
References: <CAFm4XO0VhAa7exaqH6z4D4TgE7FhXfYKMYMicVJSXF4p67wsoA@mail.gmail.com>
	<CADGJaX85SsQJ_dz08YkZqvsY+nOBK5gXxoasR4FMO8DuxNzwsQ@mail.gmail.com>
Message-ID: <CADGJaX9sX8wFaQZZntkDMaE4Wrm=YPUwEjk=Y_-1LQ+gkBAT=Q@mail.gmail.com>

Maybe you hit that one: "Failsafe project does not fail in verify
phase when a test case object errors during initialization" [1]. Fixed
in 2.19.

--Gunnar

[1] https://issues.apache.org/jira/browse/SUREFIRE-1127



2016-01-20 12:35 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
> Concerning the original error, we are bitten by the changed version
> number scheme in JDK 9 (we evaluate the Java version to enable
> specific code when running on JDK 8 or later): We are expecting a
> dot-separated version string such as "1.8.0", but JDK 9 returns only
> "9" as proposed by JEP 223 [1].
>
> I've filed HV-1048 [2] for that.
>
> Regarding the Maven/Jenkins issue I am not fully sure, the FailSafe
> plug-in detects "There are test failures" during the verify phase but
> for some reason it doesn't fail the build. It's an issue on the Maven
> side, not Jenkins; Test failure just mark a build (of Maven job type)
> as unstable (yellow), not as failed (red). Maybe you try the latest
> FailSafe version (2.19.1)?
>
> --Gunnar
>
> [1] http://openjdk.java.net/jeps/223
> [2] https://hibernate.atlassian.net/browse/HV-1048
>
>
> 2016-01-20 11:36 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>> I'm puzzled.
>> There seems to be a javax.validation related issue which is failing
>> the integration tests running on Arquillian / WildFly for the
>> Hibernate Search / WildFly tests on JDK9.
>>
>> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>>
>> But more importantly.. anyone has a clue on why the build is marked as
>> "SUCCESS" ?
>>
>> You actually have to notice the failures in the logs to figure out
>> that it's not successful at all;
>> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>>
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Jan 20 07:13:51 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 20 Jan 2016 13:13:51 +0100
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
Message-ID: <CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>

I went for the proposed intermediary step to avoid breaking the API of
SchemaManagementTool and its delegates. If you have a way for not
breaking the API or think breaking it is alright, then +1 for doing
the ProperSolution? in 5.1.

What would it comprise, changing the delegate methods such as
doCreate() to expect a single parameter object providing all the
required info? Target could be a part of this, just an enum probably,
based on wich delegates would do their thing. If it's that, I can try
and help out with it.

Regarding the release schedule, I'd personally be fine with pushing it
a bit back, but then I don't know whether there are any other hard
timelines to be met.


2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> I'd like to get this work into 5.1.  But, as much as possible, I'd like to
> get the ProperSolution in place rather than just a StepInTheRightDirection.
> If we need to push this date 2-4 weeks I am ok with that.  That would help
> us coordinate with Infinispan 8.2 schedule (iiuc) for hibernate-infinispan,
> not to mention I still have to review the work Vlad has done on the docs
> again as well as polish the load-by-multi-id API[1].
>
> [1] Sanne still waiting on your feedback to the open question of internal
> routing of those calls.
>
> On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>> Hi Steve,
>>
>> As discussed on IRC, I tried plugging in my own SchemaManagementTool
>> and delegates and letting them do the initialization work required for
>> OGM.
>>
>> I am hitting a wall though when it comes to the usage in the
>> SchemaExport controller: As it's invoking doCreate() and doDrop()
>> right in the constructor with a "fake" target for delegating the SQL
>> statements, I am bitten by the fact that SchemaExport is instantiated
>> twice in SessionFactoryImpl (once for create, once for drop at
>> shutdown), so I see to invocations to doCreate() and doDrop(). Also I
>> am lacking the knowledge of what's passed as Target for the controller
>> invocation.
>>
>> So I went ahead and changed SchemaExport to invoke SchemaCreator and
>> -Dropper only in execute(), passing them actual Target implementations
>> as it's done in SchemaUpdate, too. It's not yet what you described as
>> the ultimate goal (not looping back to Target), but IMO it's a step
>> into the right direction, not the least making things consistent
>> between SchemaExport and SchemaUpdate and also leaving APIs largely
>> unchanged for the time being. With that I should be able to do it on
>> the OGM side as you suggested, essentially ignoring the
>> Target/Exporter stuff.
>>
>> I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231
>> for the change. Let me know what you think.
>>
>> Cheers,
>>
>> --Gunnar
>>
>>
>> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > I am not sure I am a big fan of The String->Object change specifically.
>> > In
>> > theory it sounds great.  But there is a major premise in schema tooling
>> > around the idea of the actions being reduce-able to Strings.  That's
>> > important not just for SQL, but for the idea of writing to a file as
>> > well.
>> > It also affects the whole concept of Exporter/Exportable.
>> >
>> > The ultimate design goal here is to unify schema creation and dropping
>> > across native and JPA requirements.  I just simply have not had the time
>> > to
>> > work on that.  This would all happen "behind" SchemaManagementTool and
>> > friends.  SchemaExport, etc are actually just controllers responsible
>> > for
>> > coordinating the calls into the SchemaManagementTool delegates.  The
>> > main
>> > problem at the moment IMO is that Target gets passed into these
>> > SchemaManagementTool delegates.  Ideally, and certainly this would fit
>> > with
>> > your case, I think we want SchemaManagementTool or its delegates to
>> > handle
>> > interpreting the "arguments".  This was part of the intent of developing
>> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now;
>> > the
>> > idea was to encapsulate the settings each tool needs to operate and
>> > isolate
>> > the process of building/interpreting those args.
>> >
>> > The next step I wanted to look at there was to morph CommandLineArgs
>> > into a
>> > more generic "parameter object" for initializing the actual
>> > SchemaManagementTool delegates.
>> >
>> > The idea is that the more we can push into SchemaManagementTool and its
>> > delegates the more pluggable this entire process becomes.  Ultimately,
>> > as I
>> > mentioned above, I just do not think it is feasible for ORM and OGM to
>> > share all of these implementation contracts.  Forcing a switch from
>> > String
>> > (the DDL) arguments to some amorphic Object reinforces that in my mind.
>> > But that would not stop OGM from completely swapping
>> > SchemaManagementTool
>> > and its delegates and simply not using Target, Exporters, etc.
>> >
>> >
>> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >
>> >> Hi Steve,
>> >>
>> >> One thing useful to have for OGM would be a generalization of the
>> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
>> >> all of them are "schemaless", e.g. Cassandra works with a fixed
>> >> schema, and while MongoDB largely is schemaless, we still want to
>> >> create stuff like indexes in the database.
>> >>
>> >> I took a look and found that SchemaManagementTool as a pluggable
>> >> service already goes halfway into that direction. The issue with it is
>> >> that I cannot replace the list of exporters used by SchemaExport nor
>> >> the list of tool targets used by SchemaUpdate. Having a pluggable
>> >> service allowing me to customize that with an OGM-specific
>> >> implementation should do the trick.
>> >>
>> >> As per some comments in the code, SchemaExport seems to be in some
>> >> intermediary state, where the ops are not executed directly through
>> >> the targets passed to SchemaCreator/Dropper but are read into String
>> >> arrays which are then passed on to separate exporters. I suppose part
>> >> of that work should be to consolidate this and basically follow the
>> >> same approach as used in SchemaUpdate?
>> >>
>> >> Another facet is that for some OGM grid dialects we'd need another
>> >> representation of commands than Strings, as not all the backends have
>> >> a DDL but expect API invocations for that purpose. For that it'd be
>> >> required to change Target#accept(String) into accept(Object) so we can
>> >> pass some kind of command object. File exports would only work in a
>> >> limited fashion, but we could live with that. Schema creation/dropping
>> >> bound to the SF lifecycle is what I am after here.
>> >>
>> >> I'd be willing to work on this once we agree on the general approach.
>> >>
>> >> Any thoughts?
>> >>
>> >> Thanks,
>> >>
>> >> --Gunnar
>> >>
>> >>
>> >>
>> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:
>> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >> >
>> >> >> If you clean up the conflicts I can look for 5.1
>> >> >>
>> >> >
>> >> > Done!
>> >> >
>> >> > --
>> >> > Guillaume
>> >> > _______________________________________________
>> >> > 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 Jan 20 08:40:43 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 20 Jan 2016 13:40:43 +0000
Subject: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI
	job
In-Reply-To: <CADGJaX9sX8wFaQZZntkDMaE4Wrm=YPUwEjk=Y_-1LQ+gkBAT=Q@mail.gmail.com>
References: <CAFm4XO0VhAa7exaqH6z4D4TgE7FhXfYKMYMicVJSXF4p67wsoA@mail.gmail.com>
	<CADGJaX85SsQJ_dz08YkZqvsY+nOBK5gXxoasR4FMO8DuxNzwsQ@mail.gmail.com>
	<CADGJaX9sX8wFaQZZntkDMaE4Wrm=YPUwEjk=Y_-1LQ+gkBAT=Q@mail.gmail.com>
Message-ID: <CAFm4XO16aicZbFMKH4G6GMU_EjUJVUQ4TDBX=vnoJq9i8aABWQ@mail.gmail.com>

Thanks for identifying HV-1048 !

About the failsafe plugin: I'll run some tests, but I'm not sure if
it's just a maven problem as when running it locally it "fails as
expected".
Does it work for you all when running locally?

Sanne

On 20 January 2016 at 11:39, Gunnar Morling <gunnar at hibernate.org> wrote:
> Maybe you hit that one: "Failsafe project does not fail in verify
> phase when a test case object errors during initialization" [1]. Fixed
> in 2.19.
>
> --Gunnar
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1127
>
>
>
> 2016-01-20 12:35 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
>> Concerning the original error, we are bitten by the changed version
>> number scheme in JDK 9 (we evaluate the Java version to enable
>> specific code when running on JDK 8 or later): We are expecting a
>> dot-separated version string such as "1.8.0", but JDK 9 returns only
>> "9" as proposed by JEP 223 [1].
>>
>> I've filed HV-1048 [2] for that.
>>
>> Regarding the Maven/Jenkins issue I am not fully sure, the FailSafe
>> plug-in detects "There are test failures" during the verify phase but
>> for some reason it doesn't fail the build. It's an issue on the Maven
>> side, not Jenkins; Test failure just mark a build (of Maven job type)
>> as unstable (yellow), not as failed (red). Maybe you try the latest
>> FailSafe version (2.19.1)?
>>
>> --Gunnar
>>
>> [1] http://openjdk.java.net/jeps/223
>> [2] https://hibernate.atlassian.net/browse/HV-1048
>>
>>
>> 2016-01-20 11:36 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> I'm puzzled.
>>> There seems to be a javax.validation related issue which is failing
>>> the integration tests running on Arquillian / WildFly for the
>>> Hibernate Search / WildFly tests on JDK9.
>>>
>>> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>>>
>>> But more importantly.. anyone has a clue on why the build is marked as
>>> "SUCCESS" ?
>>>
>>> You actually have to notice the failures in the logs to figure out
>>> that it's not successful at all;
>>> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>>>
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed Jan 20 09:33:36 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 20 Jan 2016 15:33:36 +0100
Subject: [hibernate-dev] JDK9 / WildFly / Validator issue with Search CI
	job
In-Reply-To: <CAFm4XO16aicZbFMKH4G6GMU_EjUJVUQ4TDBX=vnoJq9i8aABWQ@mail.gmail.com>
References: <CAFm4XO0VhAa7exaqH6z4D4TgE7FhXfYKMYMicVJSXF4p67wsoA@mail.gmail.com>
	<CADGJaX85SsQJ_dz08YkZqvsY+nOBK5gXxoasR4FMO8DuxNzwsQ@mail.gmail.com>
	<CADGJaX9sX8wFaQZZntkDMaE4Wrm=YPUwEjk=Y_-1LQ+gkBAT=Q@mail.gmail.com>
	<CAFm4XO16aicZbFMKH4G6GMU_EjUJVUQ4TDBX=vnoJq9i8aABWQ@mail.gmail.com>
Message-ID: <CADGJaX_cpT6=ojEBZHCq+uCH9WnZrWtaZPrr51Fhg51MkFR=xw@mail.gmail.com>

Yes, indeed it's properly failing locally. Anyways, have you tried the
latest FailSafe version on CI?

2016-01-20 14:40 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
> Thanks for identifying HV-1048 !
>
> About the failsafe plugin: I'll run some tests, but I'm not sure if
> it's just a maven problem as when running it locally it "fails as
> expected".
> Does it work for you all when running locally?
>
> Sanne
>
> On 20 January 2016 at 11:39, Gunnar Morling <gunnar at hibernate.org> wrote:
>> Maybe you hit that one: "Failsafe project does not fail in verify
>> phase when a test case object errors during initialization" [1]. Fixed
>> in 2.19.
>>
>> --Gunnar
>>
>> [1] https://issues.apache.org/jira/browse/SUREFIRE-1127
>>
>>
>>
>> 2016-01-20 12:35 GMT+01:00 Gunnar Morling <gunnar at hibernate.org>:
>>> Concerning the original error, we are bitten by the changed version
>>> number scheme in JDK 9 (we evaluate the Java version to enable
>>> specific code when running on JDK 8 or later): We are expecting a
>>> dot-separated version string such as "1.8.0", but JDK 9 returns only
>>> "9" as proposed by JEP 223 [1].
>>>
>>> I've filed HV-1048 [2] for that.
>>>
>>> Regarding the Maven/Jenkins issue I am not fully sure, the FailSafe
>>> plug-in detects "There are test failures" during the verify phase but
>>> for some reason it doesn't fail the build. It's an issue on the Maven
>>> side, not Jenkins; Test failure just mark a build (of Maven job type)
>>> as unstable (yellow), not as failed (red). Maybe you try the latest
>>> FailSafe version (2.19.1)?
>>>
>>> --Gunnar
>>>
>>> [1] http://openjdk.java.net/jeps/223
>>> [2] https://hibernate.atlassian.net/browse/HV-1048
>>>
>>>
>>> 2016-01-20 11:36 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>>> I'm puzzled.
>>>> There seems to be a javax.validation related issue which is failing
>>>> the integration tests running on Arquillian / WildFly for the
>>>> Hibernate Search / WildFly tests on JDK9.
>>>>
>>>> http://ci.hibernate.org/view/JDK9/job/hibernate-search-master-jdk9/291/console
>>>>
>>>> But more importantly.. anyone has a clue on why the build is marked as
>>>> "SUCCESS" ?
>>>>
>>>> You actually have to notice the failures in the logs to figure out
>>>> that it's not successful at all;
>>>> search for "java.lang.ArrayIndexOutOfBoundsException" in the console logs.
>>>>
>>>> Sanne
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Thu Jan 21 06:25:04 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 21 Jan 2016 12:25:04 +0100
Subject: [hibernate-dev] Statements issued for unidirectional one-to-many
	with @JoinColumn
Message-ID: <CADGJaX9EH-7rRTSUmjuV86B1huUOpLrtdzORaubysBt8PxUMCA@mail.gmail.com>

Steve, all,

I have a model with two entities, Parent and Child, and an
unidirectional one-to-many association from the former to the latter.

Via @JoinColumn on the association it is ensured that the Parent FK is
stored in the Child table, i.e. without a separate join table. When
inserting a Parent and several Child entities, I see the following
statements:

    INSERT INTO parent (id, name) VALUES (?,?)

    INSERT INTO child (id, childname) VALUES (?,?)
    INSERT INTO child (id, childname) values (?,?)

    UPDATE CHILD SET Parent_id=? WHERE id=?
    UPDATE CHILD SET Parent_id=? WHERE id=?

Why is it that the FK is propagated through separate updates instead
of doing it as part of the Child insert?

Thanks,

--Gunnar

From davide at hibernate.org  Thu Jan 21 06:29:21 2016
From: davide at hibernate.org (Davide D'Alto)
Date: Thu, 21 Jan 2016 11:29:21 +0000
Subject: [hibernate-dev] [OGM] How to get the transaction id
Message-ID: <CANoTJYNsOjpBfKSn7FtyPM7Ztz1kfv_HqnL+mLZLoWOq8TFopQ@mail.gmail.com>

Hi,

for the implementation of the Neo4j remote dialect I need to get the
identifier of the transaction.
I suppose this is something that we will need for other dialect as well in
the future.
What's the proper way to get the transaction id or the transaction? Is it
via the TransactionDriver?

Once I have the transaction id, one possible solution is to pass it to the
method of the GridDialect interface using an addtional parameter,
TransactionContext, that could contain information about the running
transaction.

Thanks,
Davide

From mihalcea.vlad at gmail.com  Thu Jan 21 10:17:57 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 21 Jan 2016 17:17:57 +0200
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
Message-ID: <CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>

Hi Radim,

I've just committed the updated version of the Caching chapter.
To build it, you need to:

1. go to the documentation folder
2. run gradle rUG
3. The new user guide is located under:
documentation/target/asciidoc/userguide/html/Hibernate_User_Guide.html

Let me know what you think.

Vlad

On Wed, Jan 20, 2016 at 11:57 AM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Hi Radim,
>
> I'm now filling in the missing sections on the Caching chapter in the 5.1
> User Guide.
>
> Vlad
>
> On Wed, Jan 20, 2016 at 11:32 AM, Radim Vansa <rvansa at redhat.com> wrote:
>
>> I would say that the best source is 4.x docs, since the cited source is
>> what I describe by 'close to nothing'.
>>
>> I understand that for 5.1 the transformation might be unfinished, but I
>> was surprised by the same for 5.0 - missing information that's written,
>> maybe just not formatted properly for asciiidoc. In such case, link to
>> appropriate chapter in older docs would be useful.
>>
>> Radim
>>
>> On 01/19/2016 07:04 PM, Steve Ebersole wrote:
>> > The docs are in a state of flux for 5.1.  For now your best bet is the
>> > source:
>> documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc
>> >
>> > On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa <rvansa at redhat.com
>> > <mailto:rvansa at redhat.com>> wrote:
>> >
>> >     Hi,
>> >
>> >     I was about to fill some gaps in 2LC docs regarding improvements in
>> >     5.0/5.1, but when I took a look into 5.0 docs [1] there's close to
>> >     nothing; is it by purpose? In 4.3 docs [2], there's much more on
>> this
>> >     subject. Am I looking in a wrong place?
>> >
>> >     Radim
>> >
>> >     [1]
>> >
>> http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
>> >     [2]
>> >
>> http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
>> >
>> >     --
>> >     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>> >     JBoss Performance Team
>> >
>> >     _______________________________________________
>> >     hibernate-dev mailing list
>> >     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org
>> >
>> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>>
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From rvansa at redhat.com  Thu Jan 21 10:34:54 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Thu, 21 Jan 2016 16:34:54 +0100
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
Message-ID: <56A0FA9E.9020606@redhat.com>

Seems much more comprehensive, though I can't find e.g. 
'Cache-provider/concurrency-strategy compatibility' table (already 
out-of-date). Nevertheless, thanks!

I'll try to find some timeslot for updating it early next week.

Radim

On 01/21/2016 04:17 PM, Vlad Mihalcea wrote:
> Hi Radim,
>
> I've just committed the updated version of the Caching chapter.
> To build it, you need to:
>
> 1. go to the documentation folder
> 2. run gradle rUG
> 3. The new user guide is located under: 
> documentation/target/asciidoc/userguide/html/Hibernate_User_Guide.html
>
> Let me know what you think.
>
> Vlad
>
> On Wed, Jan 20, 2016 at 11:57 AM, Vlad Mihalcea 
> <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>> wrote:
>
>     Hi Radim,
>
>     I'm now filling in the missing sections on the Caching chapter in
>     the 5.1 User Guide.
>
>     Vlad
>
>     On Wed, Jan 20, 2016 at 11:32 AM, Radim Vansa <rvansa at redhat.com
>     <mailto:rvansa at redhat.com>> wrote:
>
>         I would say that the best source is 4.x docs, since the cited
>         source is
>         what I describe by 'close to nothing'.
>
>         I understand that for 5.1 the transformation might be
>         unfinished, but I
>         was surprised by the same for 5.0 - missing information that's
>         written,
>         maybe just not formatted properly for asciiidoc. In such case,
>         link to
>         appropriate chapter in older docs would be useful.
>
>         Radim
>
>         On 01/19/2016 07:04 PM, Steve Ebersole wrote:
>         > The docs are in a state of flux for 5.1. For now your best
>         bet is the
>         > source:
>         documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc
>         >
>         > On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa
>         <rvansa at redhat.com <mailto:rvansa at redhat.com>
>         > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
>         >
>         >     Hi,
>         >
>         >     I was about to fill some gaps in 2LC docs regarding
>         improvements in
>         >     5.0/5.1, but when I took a look into 5.0 docs [1]
>         there's close to
>         >     nothing; is it by purpose? In 4.3 docs [2], there's much
>         more on this
>         >     subject. Am I looking in a wrong place?
>         >
>         >     Radim
>         >
>         >     [1]
>         >
>         http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
>         >     [2]
>         >
>         http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
>         >
>         >     --
>         >     Radim Vansa <rvansa at redhat.com
>         <mailto:rvansa at redhat.com> <mailto:rvansa at redhat.com
>         <mailto:rvansa at redhat.com>>>
>         >     JBoss Performance Team
>         >
>         >  _______________________________________________
>         >     hibernate-dev mailing list
>         > hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>         <mailto:hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>>
>         > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>         >
>
>
>         --
>         Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>         JBoss Performance Team
>
>         _______________________________________________
>         hibernate-dev mailing list
>         hibernate-dev at lists.jboss.org
>         <mailto:hibernate-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From gbadner at redhat.com  Thu Jan 21 16:09:33 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 21 Jan 2016 13:09:33 -0800
Subject: [hibernate-dev] Statements issued for unidirectional
 one-to-many with @JoinColumn
In-Reply-To: <CADGJaX9EH-7rRTSUmjuV86B1huUOpLrtdzORaubysBt8PxUMCA@mail.gmail.com>
References: <CADGJaX9EH-7rRTSUmjuV86B1huUOpLrtdzORaubysBt8PxUMCA@mail.gmail.com>
Message-ID: <CAFDzhiR-fujZYgH3=qoyb8JWbHh9kKqEK0EwOyfq3u6D8K60Zw@mail.gmail.com>

Hi Gunnar,

Can you try using this pull request for HHH-9979 [1] to see if the extra
updates go away?

This pull request is already closed because I am going to use new
OperationContext functionality to fix HHH-9979. I know this pull request
does get rid of some updates, and the future one will as well.

Thanks,
Gail

[1] https://github.com/hibernate/hibernate-orm/pull/1067


On Thu, Jan 21, 2016 at 3:25 AM, Gunnar Morling <gunnar at hibernate.org>
wrote:

> Steve, all,
>
> I have a model with two entities, Parent and Child, and an
> unidirectional one-to-many association from the former to the latter.
>
> Via @JoinColumn on the association it is ensured that the Parent FK is
> stored in the Child table, i.e. without a separate join table. When
> inserting a Parent and several Child entities, I see the following
> statements:
>
>     INSERT INTO parent (id, name) VALUES (?,?)
>
>     INSERT INTO child (id, childname) VALUES (?,?)
>     INSERT INTO child (id, childname) values (?,?)
>
>     UPDATE CHILD SET Parent_id=? WHERE id=?
>     UPDATE CHILD SET Parent_id=? WHERE id=?
>
> Why is it that the FK is propagated through separate updates instead
> of doing it as part of the Child insert?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Thu Jan 21 16:50:26 2016
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 21 Jan 2016 13:50:26 -0800
Subject: [hibernate-dev] Statements issued for unidirectional
 one-to-many with @JoinColumn
In-Reply-To: <CAFDzhiR-fujZYgH3=qoyb8JWbHh9kKqEK0EwOyfq3u6D8K60Zw@mail.gmail.com>
References: <CADGJaX9EH-7rRTSUmjuV86B1huUOpLrtdzORaubysBt8PxUMCA@mail.gmail.com>
	<CAFDzhiR-fujZYgH3=qoyb8JWbHh9kKqEK0EwOyfq3u6D8K60Zw@mail.gmail.com>
Message-ID: <CAFDzhiRzpFoyuXwtSH2wTRv2E6wzPGU9F3Xq8s_3yTJqMGYL5Q@mail.gmail.com>

Actually, that pull request will only affect merging transient entities.
Are you seeing the extra updates when merging?

On Thu, Jan 21, 2016 at 1:09 PM, Gail Badner <gbadner at redhat.com> wrote:

> Hi Gunnar,
>
> Can you try using this pull request for HHH-9979 [1] to see if the extra
> updates go away?
>
> This pull request is already closed because I am going to use new
> OperationContext functionality to fix HHH-9979. I know this pull request
> does get rid of some updates, and the future one will as well.
>
> Thanks,
> Gail
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1067
>
>
> On Thu, Jan 21, 2016 at 3:25 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> Steve, all,
>>
>> I have a model with two entities, Parent and Child, and an
>> unidirectional one-to-many association from the former to the latter.
>>
>> Via @JoinColumn on the association it is ensured that the Parent FK is
>> stored in the Child table, i.e. without a separate join table. When
>> inserting a Parent and several Child entities, I see the following
>> statements:
>>
>>     INSERT INTO parent (id, name) VALUES (?,?)
>>
>>     INSERT INTO child (id, childname) VALUES (?,?)
>>     INSERT INTO child (id, childname) values (?,?)
>>
>>     UPDATE CHILD SET Parent_id=? WHERE id=?
>>     UPDATE CHILD SET Parent_id=? WHERE id=?
>>
>> Why is it that the FK is propagated through separate updates instead
>> of doing it as part of the Child insert?
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Fri Jan 22 04:37:12 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 22 Jan 2016 10:37:12 +0100
Subject: [hibernate-dev] Statements issued for unidirectional
 one-to-many with @JoinColumn
In-Reply-To: <CAFDzhiRzpFoyuXwtSH2wTRv2E6wzPGU9F3Xq8s_3yTJqMGYL5Q@mail.gmail.com>
References: <CADGJaX9EH-7rRTSUmjuV86B1huUOpLrtdzORaubysBt8PxUMCA@mail.gmail.com>
	<CAFDzhiR-fujZYgH3=qoyb8JWbHh9kKqEK0EwOyfq3u6D8K60Zw@mail.gmail.com>
	<CAFDzhiRzpFoyuXwtSH2wTRv2E6wzPGU9F3Xq8s_3yTJqMGYL5Q@mail.gmail.com>
Message-ID: <CADGJaX8BVS52toXYgw=QML=XDu8xgoSSfYAi4VvCPYKUr7AamA@mail.gmail.com>

Hi Gail,

Also with that PR I am still seeing the extra updates during insert.
Regarding merging, which case exactly do you mean? If I add another
element to the Parent#children association, I see INSERT+UPDATE for
that, too. Is it that what you mean?

--Gunnar


2016-01-21 22:50 GMT+01:00 Gail Badner <gbadner at redhat.com>:
> Actually, that pull request will only affect merging transient entities. Are
> you seeing the extra updates when merging?
>
> On Thu, Jan 21, 2016 at 1:09 PM, Gail Badner <gbadner at redhat.com> wrote:
>>
>> Hi Gunnar,
>>
>> Can you try using this pull request for HHH-9979 [1] to see if the extra
>> updates go away?
>>
>> This pull request is already closed because I am going to use new
>> OperationContext functionality to fix HHH-9979. I know this pull request
>> does get rid of some updates, and the future one will as well.
>>
>> Thanks,
>> Gail
>>
>> [1] https://github.com/hibernate/hibernate-orm/pull/1067
>>
>>
>> On Thu, Jan 21, 2016 at 3:25 AM, Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>>>
>>> Steve, all,
>>>
>>> I have a model with two entities, Parent and Child, and an
>>> unidirectional one-to-many association from the former to the latter.
>>>
>>> Via @JoinColumn on the association it is ensured that the Parent FK is
>>> stored in the Child table, i.e. without a separate join table. When
>>> inserting a Parent and several Child entities, I see the following
>>> statements:
>>>
>>>     INSERT INTO parent (id, name) VALUES (?,?)
>>>
>>>     INSERT INTO child (id, childname) VALUES (?,?)
>>>     INSERT INTO child (id, childname) values (?,?)
>>>
>>>     UPDATE CHILD SET Parent_id=? WHERE id=?
>>>     UPDATE CHILD SET Parent_id=? WHERE id=?
>>>
>>> Why is it that the FK is propagated through separate updates instead
>>> of doing it as part of the Child insert?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>

From rvansa at redhat.com  Fri Jan 22 08:20:55 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 22 Jan 2016 14:20:55 +0100
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <56A0FA9E.9020606@redhat.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com>
Message-ID: <56A22CB7.2060404@redhat.com>

I'd like to ask for some details on these (probably Steve):

read-write::
    If the application needs to update data, a read-write cache might be appropriate.
    This cache strategy should never be used if serializable transaction isolation level is required.
    If the cache is used in a JTA environment, you must specify the `hibernate.transaction.jta.platform` property.
    In other environments, you should ensure that the transaction is completed when `Session.close()` or `Session.disconnect()` is called.
    If you want to use this strategy in a cluster, you should ensure that the underlying cache implementation supports locking.
nonstrict-read-write::
    If the application only occasionally needs to update data
    (e.g. if it is extremely unlikely that two transactions would try to update the same item simultaneously)
    and strict transaction isolation is not required, a nonstrict-read-write cache might be appropriate.
    If the cache is used in a JTA environment, you must specify the `hibernate.transaction.jta.platform` property.
    In other environments, you should ensure that the transaction is completed when `Session.close()` or `Session.disconnect()` is called.


Why should the strategy 'never be used if serializable transaction 
isolation level is required'? What guarantees it gives, and what in ORM 
core depends on this?
When I've asked the last time, Steve said that all modes but the 
nonstrict one require that the 2LC is absolutely transparent 
(consistency-wise), so you always get the same answer as if you were 
directly talking to DB.

I also don't really see what's the meaning of 'underlying cache 
implementation supports locking' - IMO it's implementation detail how 
the application achieves required level of consistency. The 'locking' 
term itself is a bit vague.

Does the ' you should ensure that the transaction is completed when 
`Session.close()` or `Session.disconnect()` is called' still hold, or 
does the transactional rework in 5.0 somehow obsolete this info?

Thanks

Radim

On 01/21/2016 04:34 PM, Radim Vansa wrote:
> Seems much more comprehensive, though I can't find e.g.
> 'Cache-provider/concurrency-strategy compatibility' table (already
> out-of-date). Nevertheless, thanks!
>
> I'll try to find some timeslot for updating it early next week.
>
> Radim
>
> On 01/21/2016 04:17 PM, Vlad Mihalcea wrote:
>> Hi Radim,
>>
>> I've just committed the updated version of the Caching chapter.
>> To build it, you need to:
>>
>> 1. go to the documentation folder
>> 2. run gradle rUG
>> 3. The new user guide is located under:
>> documentation/target/asciidoc/userguide/html/Hibernate_User_Guide.html
>>
>> Let me know what you think.
>>
>> Vlad
>>
>> On Wed, Jan 20, 2016 at 11:57 AM, Vlad Mihalcea
>> <mihalcea.vlad at gmail.com <mailto:mihalcea.vlad at gmail.com>> wrote:
>>
>>      Hi Radim,
>>
>>      I'm now filling in the missing sections on the Caching chapter in
>>      the 5.1 User Guide.
>>
>>      Vlad
>>
>>      On Wed, Jan 20, 2016 at 11:32 AM, Radim Vansa <rvansa at redhat.com
>>      <mailto:rvansa at redhat.com>> wrote:
>>
>>          I would say that the best source is 4.x docs, since the cited
>>          source is
>>          what I describe by 'close to nothing'.
>>
>>          I understand that for 5.1 the transformation might be
>>          unfinished, but I
>>          was surprised by the same for 5.0 - missing information that's
>>          written,
>>          maybe just not formatted properly for asciiidoc. In such case,
>>          link to
>>          appropriate chapter in older docs would be useful.
>>
>>          Radim
>>
>>          On 01/19/2016 07:04 PM, Steve Ebersole wrote:
>>          > The docs are in a state of flux for 5.1. For now your best
>>          bet is the
>>          > source:
>>          documentation/src/main/asciidoc/userguide/chapters/caching/Caching.adoc
>>          >
>>          > On Fri, Jan 15, 2016 at 3:48 AM Radim Vansa
>>          <rvansa at redhat.com <mailto:rvansa at redhat.com>
>>          > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
>>          >
>>          >     Hi,
>>          >
>>          >     I was about to fill some gaps in 2LC docs regarding
>>          improvements in
>>          >     5.0/5.1, but when I took a look into 5.0 docs [1]
>>          there's close to
>>          >     nothing; is it by purpose? In 4.3 docs [2], there's much
>>          more on this
>>          >     subject. Am I looking in a wrong place?
>>          >
>>          >     Radim
>>          >
>>          >     [1]
>>          >
>>          http://docs.jboss.org/hibernate/orm/5.0/userGuide/en-US/html_single/#caching
>>          >     [2]
>>          >
>>          http://docs.jboss.org/hibernate/orm/4.3/manual/en-US/html_single/#performance-cache
>>          >
>>          >     --
>>          >     Radim Vansa <rvansa at redhat.com
>>          <mailto:rvansa at redhat.com> <mailto:rvansa at redhat.com
>>          <mailto:rvansa at redhat.com>>>
>>          >     JBoss Performance Team
>>          >
>>          >  _______________________________________________
>>          >     hibernate-dev mailing list
>>          > hibernate-dev at lists.jboss.org
>>          <mailto:hibernate-dev at lists.jboss.org>
>>          <mailto:hibernate-dev at lists.jboss.org
>>          <mailto:hibernate-dev at lists.jboss.org>>
>>          > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>          >
>>
>>
>>          --
>>          Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>>          JBoss Performance Team
>>
>>          _______________________________________________
>>          hibernate-dev mailing list
>>          hibernate-dev at lists.jboss.org
>>          <mailto:hibernate-dev at lists.jboss.org>
>>          https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From steve at hibernate.org  Fri Jan 22 09:11:37 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jan 2016 14:11:37 +0000
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <56A22CB7.2060404@redhat.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com> <56A22CB7.2060404@redhat.com>
Message-ID: <CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>

On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <rvansa at redhat.com> wrote:

> Why should the strategy 'never be used if serializable transaction
> isolation level is required'? What guarantees it gives, and what in ORM
> core depends on this?  When I've asked the last time, Steve said that all
> modes but the

nonstrict one require that the 2LC is absolutely transparent
> (consistency-wise), so you always get the same answer as if you were
> directly talking to DB.
>

I would guess this is talking about "serializable isolation" at the
application layer.  Yes extended across both the application and database.
In our original implementations we had no L2 cache providers that would
support serializable isolation.  Does hibernate-infinispan?  If we ask for
a certain entry from the cache in T1, T2 adds that entry and commits, and
then we ask for it again in T1 do we still see it as "not existing"?  I'd
highly doubt it, but if it does then lets make note of that.

Could this wording be cleaned up?  For sure.  Feel free to make some
suggested edits



> I also don't really see what's the meaning of 'underlying cache
> implementation supports locking' - IMO it's implementation detail how
> the application achieves required level of consistency. The 'locking'
> term itself is a bit vague.
>

No idea what that is supposed to mean.  I did not write that, but I would
guess the intent is to say that the being conveyed is that of consistency
across the nodes of the cluster.


Does the ' you should ensure that the transaction is completed when
> `Session.close()` or `Session.disconnect()` is called' still hold, or
> does the transactional rework in 5.0 somehow obsolete this info?
>

I cannot say why this is discussed in a chapter on caching.
Session#disconnect is largely deprecated (its main use case is handled much
more transparently now).  IMO it's always a good idea to make sure a
transaction against a resource is completed prior to closing that
transaction.  That's no different for a Hibernate Session then it is for a
JDBC Connection, etc.

Basically this passage is a poorly worded hint.  What it is trying to
convey is that for "asynchronous" cache access what drives the interactions
with the Cache is the Hibernate transaction, and in these case the user
should take extra care to make sure that the transaction is handled
properly.  That still holds true.

As a refresher, the idea of "synchronous" versus "asynchronous" is simply
cache access that is driven by JTA ("synchronous") versus those that are
driven by local transactions ("asynchronous").

From steve at hibernate.org  Fri Jan 22 09:17:01 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jan 2016 14:17:01 +0000
Subject: [hibernate-dev] Statements issued for unidirectional
 one-to-many with @JoinColumn
In-Reply-To: <CADGJaX8BVS52toXYgw=QML=XDu8xgoSSfYAi4VvCPYKUr7AamA@mail.gmail.com>
References: <CADGJaX9EH-7rRTSUmjuV86B1huUOpLrtdzORaubysBt8PxUMCA@mail.gmail.com>
	<CAFDzhiR-fujZYgH3=qoyb8JWbHh9kKqEK0EwOyfq3u6D8K60Zw@mail.gmail.com>
	<CAFDzhiRzpFoyuXwtSH2wTRv2E6wzPGU9F3Xq8s_3yTJqMGYL5Q@mail.gmail.com>
	<CADGJaX8BVS52toXYgw=QML=XDu8xgoSSfYAi4VvCPYKUr7AamA@mail.gmail.com>
Message-ID: <CAFdSV9stUQPAsOYCotw7rFkrMnNnop+5SsfyL_GcDO6cqy=HnQ@mail.gmail.com>

I would look at 2 things as I mentioned on HipChat yesterday...

1) Hibernate does have some capacity to do what you are expecting.  There
are definitely some limitations to it.  But the idea is called a
"backref".  When building the metamodel for this, Hibernate should inject 2
synthetic backref properties.  One, org.hibernate.mapping.Backref, is meant
to handle the FK.  The other, org.hibernate.mapping.IndexBackref, is meant
to handle the list/map/array index.  It is possible something got screwed
up in modeling this.  So the first thing I would check is whether these
backref synthetic properties are properly built into the metamodel.  If
they are, then we should make sure they are still handled properly in the
persisters.

2) There has recently been a lot of piecemeal rework of delayed operation
handling.  I wonder if those changes might be coming into play.

I'd suggest looking at (1) first.


On Fri, Jan 22, 2016 at 3:37 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi Gail,
>
> Also with that PR I am still seeing the extra updates during insert.
> Regarding merging, which case exactly do you mean? If I add another
> element to the Parent#children association, I see INSERT+UPDATE for
> that, too. Is it that what you mean?
>
> --Gunnar
>
>
> 2016-01-21 22:50 GMT+01:00 Gail Badner <gbadner at redhat.com>:
> > Actually, that pull request will only affect merging transient entities.
> Are
> > you seeing the extra updates when merging?
> >
> > On Thu, Jan 21, 2016 at 1:09 PM, Gail Badner <gbadner at redhat.com> wrote:
> >>
> >> Hi Gunnar,
> >>
> >> Can you try using this pull request for HHH-9979 [1] to see if the extra
> >> updates go away?
> >>
> >> This pull request is already closed because I am going to use new
> >> OperationContext functionality to fix HHH-9979. I know this pull request
> >> does get rid of some updates, and the future one will as well.
> >>
> >> Thanks,
> >> Gail
> >>
> >> [1] https://github.com/hibernate/hibernate-orm/pull/1067
> >>
> >>
> >> On Thu, Jan 21, 2016 at 3:25 AM, Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >>>
> >>> Steve, all,
> >>>
> >>> I have a model with two entities, Parent and Child, and an
> >>> unidirectional one-to-many association from the former to the latter.
> >>>
> >>> Via @JoinColumn on the association it is ensured that the Parent FK is
> >>> stored in the Child table, i.e. without a separate join table. When
> >>> inserting a Parent and several Child entities, I see the following
> >>> statements:
> >>>
> >>>     INSERT INTO parent (id, name) VALUES (?,?)
> >>>
> >>>     INSERT INTO child (id, childname) VALUES (?,?)
> >>>     INSERT INTO child (id, childname) values (?,?)
> >>>
> >>>     UPDATE CHILD SET Parent_id=? WHERE id=?
> >>>     UPDATE CHILD SET Parent_id=? WHERE id=?
> >>>
> >>> Why is it that the FK is propagated through separate updates instead
> >>> of doing it as part of the Child insert?
> >>>
> >>> Thanks,
> >>>
> >>> --Gunnar
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri Jan 22 10:16:02 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jan 2016 15:16:02 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
	<CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
Message-ID: <CAFdSV9uQV3_s2Pwv5KC-+rfoJDz1svt3cVNcfokZKkUhkQXe=w@mail.gmail.com>

I just pushed 5.1 back to Feb 10th in order to get all this work in.

On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> I went for the proposed intermediary step to avoid breaking the API of
> SchemaManagementTool and its delegates. If you have a way for not
> breaking the API or think breaking it is alright, then +1 for doing
> the ProperSolution? in 5.1.
>
> What would it comprise, changing the delegate methods such as
> doCreate() to expect a single parameter object providing all the
> required info? Target could be a part of this, just an enum probably,
> based on wich delegates would do their thing. If it's that, I can try
> and help out with it.
>
> Regarding the release schedule, I'd personally be fine with pushing it
> a bit back, but then I don't know whether there are any other hard
> timelines to be met.
>
>
> 2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > I'd like to get this work into 5.1.  But, as much as possible, I'd like
> to
> > get the ProperSolution in place rather than just a
> StepInTheRightDirection.
> > If we need to push this date 2-4 weeks I am ok with that.  That would
> help
> > us coordinate with Infinispan 8.2 schedule (iiuc) for
> hibernate-infinispan,
> > not to mention I still have to review the work Vlad has done on the docs
> > again as well as polish the load-by-multi-id API[1].
> >
> > [1] Sanne still waiting on your feedback to the open question of internal
> > routing of those calls.
> >
> > On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> Hi Steve,
> >>
> >> As discussed on IRC, I tried plugging in my own SchemaManagementTool
> >> and delegates and letting them do the initialization work required for
> >> OGM.
> >>
> >> I am hitting a wall though when it comes to the usage in the
> >> SchemaExport controller: As it's invoking doCreate() and doDrop()
> >> right in the constructor with a "fake" target for delegating the SQL
> >> statements, I am bitten by the fact that SchemaExport is instantiated
> >> twice in SessionFactoryImpl (once for create, once for drop at
> >> shutdown), so I see to invocations to doCreate() and doDrop(). Also I
> >> am lacking the knowledge of what's passed as Target for the controller
> >> invocation.
> >>
> >> So I went ahead and changed SchemaExport to invoke SchemaCreator and
> >> -Dropper only in execute(), passing them actual Target implementations
> >> as it's done in SchemaUpdate, too. It's not yet what you described as
> >> the ultimate goal (not looping back to Target), but IMO it's a step
> >> into the right direction, not the least making things consistent
> >> between SchemaExport and SchemaUpdate and also leaving APIs largely
> >> unchanged for the time being. With that I should be able to do it on
> >> the OGM side as you suggested, essentially ignoring the
> >> Target/Exporter stuff.
> >>
> >> I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231
> >> for the change. Let me know what you think.
> >>
> >> Cheers,
> >>
> >> --Gunnar
> >>
> >>
> >> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> > I am not sure I am a big fan of The String->Object change
> specifically.
> >> > In
> >> > theory it sounds great.  But there is a major premise in schema
> tooling
> >> > around the idea of the actions being reduce-able to Strings.  That's
> >> > important not just for SQL, but for the idea of writing to a file as
> >> > well.
> >> > It also affects the whole concept of Exporter/Exportable.
> >> >
> >> > The ultimate design goal here is to unify schema creation and dropping
> >> > across native and JPA requirements.  I just simply have not had the
> time
> >> > to
> >> > work on that.  This would all happen "behind" SchemaManagementTool and
> >> > friends.  SchemaExport, etc are actually just controllers responsible
> >> > for
> >> > coordinating the calls into the SchemaManagementTool delegates.  The
> >> > main
> >> > problem at the moment IMO is that Target gets passed into these
> >> > SchemaManagementTool delegates.  Ideally, and certainly this would fit
> >> > with
> >> > your case, I think we want SchemaManagementTool or its delegates to
> >> > handle
> >> > interpreting the "arguments".  This was part of the intent of
> developing
> >> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now;
> >> > the
> >> > idea was to encapsulate the settings each tool needs to operate and
> >> > isolate
> >> > the process of building/interpreting those args.
> >> >
> >> > The next step I wanted to look at there was to morph CommandLineArgs
> >> > into a
> >> > more generic "parameter object" for initializing the actual
> >> > SchemaManagementTool delegates.
> >> >
> >> > The idea is that the more we can push into SchemaManagementTool and
> its
> >> > delegates the more pluggable this entire process becomes.  Ultimately,
> >> > as I
> >> > mentioned above, I just do not think it is feasible for ORM and OGM to
> >> > share all of these implementation contracts.  Forcing a switch from
> >> > String
> >> > (the DDL) arguments to some amorphic Object reinforces that in my
> mind.
> >> > But that would not stop OGM from completely swapping
> >> > SchemaManagementTool
> >> > and its delegates and simply not using Target, Exporters, etc.
> >> >
> >> >
> >> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar at hibernate.org>
> >> > wrote:
> >> >
> >> >> Hi Steve,
> >> >>
> >> >> One thing useful to have for OGM would be a generalization of the
> >> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
> >> >> all of them are "schemaless", e.g. Cassandra works with a fixed
> >> >> schema, and while MongoDB largely is schemaless, we still want to
> >> >> create stuff like indexes in the database.
> >> >>
> >> >> I took a look and found that SchemaManagementTool as a pluggable
> >> >> service already goes halfway into that direction. The issue with it
> is
> >> >> that I cannot replace the list of exporters used by SchemaExport nor
> >> >> the list of tool targets used by SchemaUpdate. Having a pluggable
> >> >> service allowing me to customize that with an OGM-specific
> >> >> implementation should do the trick.
> >> >>
> >> >> As per some comments in the code, SchemaExport seems to be in some
> >> >> intermediary state, where the ops are not executed directly through
> >> >> the targets passed to SchemaCreator/Dropper but are read into String
> >> >> arrays which are then passed on to separate exporters. I suppose part
> >> >> of that work should be to consolidate this and basically follow the
> >> >> same approach as used in SchemaUpdate?
> >> >>
> >> >> Another facet is that for some OGM grid dialects we'd need another
> >> >> representation of commands than Strings, as not all the backends have
> >> >> a DDL but expect API invocations for that purpose. For that it'd be
> >> >> required to change Target#accept(String) into accept(Object) so we
> can
> >> >> pass some kind of command object. File exports would only work in a
> >> >> limited fashion, but we could live with that. Schema
> creation/dropping
> >> >> bound to the SF lifecycle is what I am after here.
> >> >>
> >> >> I'd be willing to work on this once we agree on the general approach.
> >> >>
> >> >> Any thoughts?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> --Gunnar
> >> >>
> >> >>
> >> >>
> >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com
> >:
> >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <
> steve at hibernate.org>
> >> >> wrote:
> >> >> >
> >> >> >> If you clean up the conflicts I can look for 5.1
> >> >> >>
> >> >> >
> >> >> > Done!
> >> >> >
> >> >> > --
> >> >> > Guillaume
> >> >> > _______________________________________________
> >> >> > 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  Fri Jan 22 10:16:32 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jan 2016 15:16:32 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CAFdSV9uQV3_s2Pwv5KC-+rfoJDz1svt3cVNcfokZKkUhkQXe=w@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
	<CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
	<CAFdSV9uQV3_s2Pwv5KC-+rfoJDz1svt3cVNcfokZKkUhkQXe=w@mail.gmail.com>
Message-ID: <CAFdSV9tA+aJvcFSu9NiFweTUGSsKVgy41t9VQ9_BLGMAueM6EA@mail.gmail.com>

And please let's not take that to mean "let's add more tasks to 5.1 now..."
;)

On Fri, Jan 22, 2016 at 9:16 AM Steve Ebersole <steve at hibernate.org> wrote:

> I just pushed 5.1 back to Feb 10th in order to get all this work in.
>
> On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> I went for the proposed intermediary step to avoid breaking the API of
>> SchemaManagementTool and its delegates. If you have a way for not
>> breaking the API or think breaking it is alright, then +1 for doing
>> the ProperSolution? in 5.1.
>>
>> What would it comprise, changing the delegate methods such as
>> doCreate() to expect a single parameter object providing all the
>> required info? Target could be a part of this, just an enum probably,
>> based on wich delegates would do their thing. If it's that, I can try
>> and help out with it.
>>
>> Regarding the release schedule, I'd personally be fine with pushing it
>> a bit back, but then I don't know whether there are any other hard
>> timelines to be met.
>>
>>
>> 2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > I'd like to get this work into 5.1.  But, as much as possible, I'd like
>> to
>> > get the ProperSolution in place rather than just a
>> StepInTheRightDirection.
>> > If we need to push this date 2-4 weeks I am ok with that.  That would
>> help
>> > us coordinate with Infinispan 8.2 schedule (iiuc) for
>> hibernate-infinispan,
>> > not to mention I still have to review the work Vlad has done on the docs
>> > again as well as polish the load-by-multi-id API[1].
>> >
>> > [1] Sanne still waiting on your feedback to the open question of
>> internal
>> > routing of those calls.
>> >
>> > On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >>
>> >> Hi Steve,
>> >>
>> >> As discussed on IRC, I tried plugging in my own SchemaManagementTool
>> >> and delegates and letting them do the initialization work required for
>> >> OGM.
>> >>
>> >> I am hitting a wall though when it comes to the usage in the
>> >> SchemaExport controller: As it's invoking doCreate() and doDrop()
>> >> right in the constructor with a "fake" target for delegating the SQL
>> >> statements, I am bitten by the fact that SchemaExport is instantiated
>> >> twice in SessionFactoryImpl (once for create, once for drop at
>> >> shutdown), so I see to invocations to doCreate() and doDrop(). Also I
>> >> am lacking the knowledge of what's passed as Target for the controller
>> >> invocation.
>> >>
>> >> So I went ahead and changed SchemaExport to invoke SchemaCreator and
>> >> -Dropper only in execute(), passing them actual Target implementations
>> >> as it's done in SchemaUpdate, too. It's not yet what you described as
>> >> the ultimate goal (not looping back to Target), but IMO it's a step
>> >> into the right direction, not the least making things consistent
>> >> between SchemaExport and SchemaUpdate and also leaving APIs largely
>> >> unchanged for the time being. With that I should be able to do it on
>> >> the OGM side as you suggested, essentially ignoring the
>> >> Target/Exporter stuff.
>> >>
>> >> I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231
>> >> for the change. Let me know what you think.
>> >>
>> >> Cheers,
>> >>
>> >> --Gunnar
>> >>
>> >>
>> >> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >> > I am not sure I am a big fan of The String->Object change
>> specifically.
>> >> > In
>> >> > theory it sounds great.  But there is a major premise in schema
>> tooling
>> >> > around the idea of the actions being reduce-able to Strings.  That's
>> >> > important not just for SQL, but for the idea of writing to a file as
>> >> > well.
>> >> > It also affects the whole concept of Exporter/Exportable.
>> >> >
>> >> > The ultimate design goal here is to unify schema creation and
>> dropping
>> >> > across native and JPA requirements.  I just simply have not had the
>> time
>> >> > to
>> >> > work on that.  This would all happen "behind" SchemaManagementTool
>> and
>> >> > friends.  SchemaExport, etc are actually just controllers responsible
>> >> > for
>> >> > coordinating the calls into the SchemaManagementTool delegates.  The
>> >> > main
>> >> > problem at the moment IMO is that Target gets passed into these
>> >> > SchemaManagementTool delegates.  Ideally, and certainly this would
>> fit
>> >> > with
>> >> > your case, I think we want SchemaManagementTool or its delegates to
>> >> > handle
>> >> > interpreting the "arguments".  This was part of the intent of
>> developing
>> >> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc
>> now;
>> >> > the
>> >> > idea was to encapsulate the settings each tool needs to operate and
>> >> > isolate
>> >> > the process of building/interpreting those args.
>> >> >
>> >> > The next step I wanted to look at there was to morph CommandLineArgs
>> >> > into a
>> >> > more generic "parameter object" for initializing the actual
>> >> > SchemaManagementTool delegates.
>> >> >
>> >> > The idea is that the more we can push into SchemaManagementTool and
>> its
>> >> > delegates the more pluggable this entire process becomes.
>> Ultimately,
>> >> > as I
>> >> > mentioned above, I just do not think it is feasible for ORM and OGM
>> to
>> >> > share all of these implementation contracts.  Forcing a switch from
>> >> > String
>> >> > (the DDL) arguments to some amorphic Object reinforces that in my
>> mind.
>> >> > But that would not stop OGM from completely swapping
>> >> > SchemaManagementTool
>> >> > and its delegates and simply not using Target, Exporters, etc.
>> >> >
>> >> >
>> >> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar at hibernate.org
>> >
>> >> > wrote:
>> >> >
>> >> >> Hi Steve,
>> >> >>
>> >> >> One thing useful to have for OGM would be a generalization of the
>> >> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases.
>> Not
>> >> >> all of them are "schemaless", e.g. Cassandra works with a fixed
>> >> >> schema, and while MongoDB largely is schemaless, we still want to
>> >> >> create stuff like indexes in the database.
>> >> >>
>> >> >> I took a look and found that SchemaManagementTool as a pluggable
>> >> >> service already goes halfway into that direction. The issue with it
>> is
>> >> >> that I cannot replace the list of exporters used by SchemaExport nor
>> >> >> the list of tool targets used by SchemaUpdate. Having a pluggable
>> >> >> service allowing me to customize that with an OGM-specific
>> >> >> implementation should do the trick.
>> >> >>
>> >> >> As per some comments in the code, SchemaExport seems to be in some
>> >> >> intermediary state, where the ops are not executed directly through
>> >> >> the targets passed to SchemaCreator/Dropper but are read into String
>> >> >> arrays which are then passed on to separate exporters. I suppose
>> part
>> >> >> of that work should be to consolidate this and basically follow the
>> >> >> same approach as used in SchemaUpdate?
>> >> >>
>> >> >> Another facet is that for some OGM grid dialects we'd need another
>> >> >> representation of commands than Strings, as not all the backends
>> have
>> >> >> a DDL but expect API invocations for that purpose. For that it'd be
>> >> >> required to change Target#accept(String) into accept(Object) so we
>> can
>> >> >> pass some kind of command object. File exports would only work in a
>> >> >> limited fashion, but we could live with that. Schema
>> creation/dropping
>> >> >> bound to the SF lifecycle is what I am after here.
>> >> >>
>> >> >> I'd be willing to work on this once we agree on the general
>> approach.
>> >> >>
>> >> >> Any thoughts?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> --Gunnar
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com
>> >:
>> >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <
>> steve at hibernate.org>
>> >> >> wrote:
>> >> >> >
>> >> >> >> If you clean up the conflicts I can look for 5.1
>> >> >> >>
>> >> >> >
>> >> >> > Done!
>> >> >> >
>> >> >> > --
>> >> >> > Guillaume
>> >> >> > _______________________________________________
>> >> >> > 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 rvansa at redhat.com  Fri Jan 22 10:30:02 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 22 Jan 2016 16:30:02 +0100
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com> <56A22CB7.2060404@redhat.com>
	<CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>
Message-ID: <56A24AFA.7030902@redhat.com>

On 01/22/2016 03:11 PM, Steve Ebersole wrote:
> On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     Why should the strategy 'never be used if serializable transaction
>     isolation level is required'? What guarantees it gives, and what
>     in ORM
>     core depends on this?  When I've asked the last time, Steve said
>     that all modes but the
>
>     nonstrict one require that the 2LC is absolutely transparent
>     (consistency-wise), so you always get the same answer as if you were
>     directly talking to DB.
>
>
> I would guess this is talking about "serializable isolation" at the 
> application layer.  Yes extended across both the application and 
> database.  In our original implementations we had no L2 cache 
> providers that would support serializable isolation.  Does 
> hibernate-infinispan? If we ask for a certain entry from the cache in 
> T1, T2 adds that entry and commits, and then we ask for it again in T1 
> do we still see it as "not existing"?  I'd highly doubt it, but if it 
> does then lets make note of that.

No, without a transactional cache, it does not. Thanks for the example. 
But will the request get to 2LC, or will it be served already from 
Session cache?

>
> Could this wording be cleaned up?  For sure.  Feel free to make some 
> suggested edits

That's why I am writing this mail, I want to clean it up and update.

>
>     I also don't really see what's the meaning of 'underlying cache
>     implementation supports locking' - IMO it's implementation detail how
>     the application achieves required level of consistency. The 'locking'
>     term itself is a bit vague.
>
>
> No idea what that is supposed to mean.  I did not write that, but I 
> would guess the intent is to say that the being conveyed is that of 
> consistency across the nodes of the cluster.
>
>     Does the ' you should ensure that the transaction is completed when
>     `Session.close()` or `Session.disconnect()` is called' still hold, or
>     does the transactional rework in 5.0 somehow obsolete this info?
>
>
> I cannot say why this is discussed in a chapter on caching.   
> Session#disconnect is largely deprecated (its main use case is handled 
> much more transparently now).  IMO it's always a good idea to make 
> sure a transaction against a resource is completed prior to closing 
> that transaction. That's no different for a Hibernate Session then it 
> is for a JDBC Connection, etc.

Did you meant 'commit the transaction before closing the session'? If 
the Session.close() is called with tx open, will the transaction be 
committed? But any way, this should be really the same as without 2LC.

>
> Basically this passage is a poorly worded hint.  What it is trying to 
> convey is that for "asynchronous" cache access what drives the 
> interactions with the Cache is the Hibernate transaction, and in these 
> case the user should take extra care to make sure that the transaction 
> is handled properly. That still holds true.
>
> As a refresher, the idea of "synchronous" versus "asynchronous" is 
> simply cache access that is driven by JTA ("synchronous") versus those 
> that are driven by local transactions ("asynchronous").
>

Eh, I probably don't get the exact meaning of 'driving the access' :-/ 
And I can't find any reference to 'async' in user guide.

Thanks for consulting this with me!

Radim


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From steve at hibernate.org  Fri Jan 22 11:26:14 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jan 2016 16:26:14 +0000
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <56A24AFA.7030902@redhat.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com> <56A22CB7.2060404@redhat.com>
	<CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>
	<56A24AFA.7030902@redhat.com>
Message-ID: <CAFdSV9tLsMq6Jb=+gO+DqqQy4927qQKkwyS5An6-8ivgMdgbvg@mail.gmail.com>

On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa at redhat.com> wrote:

> On 01/22/2016 03:11 PM, Steve Ebersole wrote:
> > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <rvansa at redhat.com
> > <mailto:rvansa at redhat.com>> wrote:
> >
> >     Why should the strategy 'never be used if serializable transaction
> >     isolation level is required'? What guarantees it gives, and what
> >     in ORM
> >     core depends on this?  When I've asked the last time, Steve said
> >     that all modes but the
> >
> >     nonstrict one require that the 2LC is absolutely transparent
> >     (consistency-wise), so you always get the same answer as if you were
> >     directly talking to DB.
> >
> >
> > I would guess this is talking about "serializable isolation" at the
> > application layer.  Yes extended across both the application and
> > database.  In our original implementations we had no L2 cache
> > providers that would support serializable isolation.  Does
> > hibernate-infinispan? If we ask for a certain entry from the cache in
> > T1, T2 adds that entry and commits, and then we ask for it again in T1
> > do we still see it as "not existing"?  I'd highly doubt it, but if it
> > does then lets make note of that.
>
> No, without a transactional cache, it does not. Thanks for the example.
> But will the request get to 2LC, or will it be served already from
> Session cache?
>

It won't work even with a transactional cache I believe.  It won't work
with Infinispan e.g. I do not think.  Hibernate does not keep reference to
"non-existing" entities.  That's the only way the Session could "serve" the
fact that the first T1 lookup found nothing.  Again, this gets right back
to that idea of consistency.  Without L2 caching, in this scenario with
serializable isolation the database would return me "no row" in both T1
SELECTs.


>     Does the ' you should ensure that the transaction is completed when
> >     `Session.close()` or `Session.disconnect()` is called' still hold, or
> >     does the transactional rework in 5.0 somehow obsolete this info?
> >
> >
> > I cannot say why this is discussed in a chapter on caching.
> > Session#disconnect is largely deprecated (its main use case is handled
> > much more transparently now).  IMO it's always a good idea to make
> > sure a transaction against a resource is completed prior to closing
> > that transaction. That's no different for a Hibernate Session then it
> > is for a JDBC Connection, etc.
>
> Did you meant 'commit the transaction before closing the session'? If
> the Session.close() is called with tx open, will the transaction be
> committed? But any way, this should be really the same as without 2LC.
>

I meant to say " make sure a transaction against a resource is completed
prior to closing that resource".  Saying "complete the transaction" !=
"commit the transaction".  Completion might be either commit or rollback.
But the idea is that it is in a definitive state.

Historically what a stranded transaction at the time of Session#close meant
depended on the JDBC driver.  Most drivers rollback back on a stranded
transaction; Oracle has always been the notable exception as they would
commit a stranded transaction.  But regardless in terms of Session locks
etc in the cache that would strand the locks as well iirc.

In developing 5.0 and the new transaction handling I know we talked about
making this more deterministic, specifically always handling this as if a
rollback had been called.  But to be honest, that's not what I am seeing in
the code.  Andrea, do you remember?  If not, we should definitely add some
tests for this to see what happens atm and make sure its really what we
want to have happen moving forward.


> Basically this passage is a poorly worded hint.  What it is trying to
> > convey is that for "asynchronous" cache access what drives the
> > interactions with the Cache is the Hibernate transaction, and in these
> > case the user should take extra care to make sure that the transaction
> > is handled properly. That still holds true.
> >
> > As a refresher, the idea of "synchronous" versus "asynchronous" is
> > simply cache access that is driven by JTA ("synchronous") versus those
> > that are driven by local transactions ("asynchronous").


> Eh, I probably don't get the exact meaning of 'driving the access' :-/
> And I can't find any reference to 'async' in user guide.
>

I keep pointing y'all to
org.hibernate.cache.spi.access.EntityRegionAccessStrategy,
org.hibernate.cache.spi.access.CollectionRegionAccessStrategy, etc as the
best source for this information.  I spent a lot of time  documenting
(javadoc) these contracts as I developed them.  sync/async is discussed
there.  No need for it to be discussed in the user guide IMO, its a concept
for developers of cache implementations to understand not users.

From steve at hibernate.org  Fri Jan 22 16:28:38 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jan 2016 21:28:38 +0000
Subject: [hibernate-dev] HHH-8076 - CDI-capable entity listeners
Message-ID: <CAFdSV9tD2jK9rZiY596m-UrVHPYNA3+kpd8Y3anUtOg9HtpdYg@mail.gmail.com>

As part of the work on HHH-8076 for ORM 5.1 I am going to have to change
up, in some fashion, some or all of the following internal/spi contracts :

* org.hibernate.jpa.event.spi.jpa.Callback
* org.hibernate.jpa.event.spi.jpa.CallbackRegistry
* org.hibernate.jpa.event.spi.jpa.ListenerFactory
* org.hibernate.jpa.event.internal.jpa.CallbackProcessor

I need to know whether any integrations either use any of these or provide
custom impls for any of them.

From steve at hibernate.org  Fri Jan 22 16:38:02 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jan 2016 21:38:02 +0000
Subject: [hibernate-dev] HHH-8076 - CDI-capable entity listeners
In-Reply-To: <CAFdSV9tD2jK9rZiY596m-UrVHPYNA3+kpd8Y3anUtOg9HtpdYg@mail.gmail.com>
References: <CAFdSV9tD2jK9rZiY596m-UrVHPYNA3+kpd8Y3anUtOg9HtpdYg@mail.gmail.com>
Message-ID: <CAFdSV9v6uWNZhvtTgv5GrSCmH1-bWR6Ljj=EbHF5xf0D1UKVaQ@mail.gmail.com>

If it matters, my plan is as follows...

Currently JpaIntegrator is the central point for this processing.  The
general premise is that it builds a CallbackRegistry, a ListenerFactory and
a CallbackProcessor.  It then uses the CallbackProcessor and ListenerFactory
to populate the CallbackRegistry.  This part is the crux of the problem
with HHH-8076 as after this JpaIntegrator call it is expected that
CallbackRegistry
be fully initialized (all Callbacks resolved and ready to go).

So the plan is to instead invert these relationships to where we build
a CallbackRegistry
that is aware of the ListenerFactory and CallbackProcessor (actually I
think CallbackProcessor can go away).  This is the point in the suggested
solution described for HHH-8076 where we'd check the BeanManager to see if
it is a BeanManagerExtension and decide whether to delay the
initialization.  If that plan causes trouble for anyone, please speak up
asap.  If not, I'll proceed.

Thanks!

On Fri, Jan 22, 2016 at 3:28 PM Steve Ebersole <steve at hibernate.org> wrote:

> As part of the work on HHH-8076 for ORM 5.1 I am going to have to change
> up, in some fashion, some or all of the following internal/spi contracts :
>
> * org.hibernate.jpa.event.spi.jpa.Callback
> * org.hibernate.jpa.event.spi.jpa.CallbackRegistry
> * org.hibernate.jpa.event.spi.jpa.ListenerFactory
> * org.hibernate.jpa.event.internal.jpa.CallbackProcessor
>
> I need to know whether any integrations either use any of these or provide
> custom impls for any of them.
>

From steve at hibernate.org  Fri Jan 22 18:58:18 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 22 Jan 2016 23:58:18 +0000
Subject: [hibernate-dev] HHH-8076 - CDI-capable entity listeners
In-Reply-To: <CAFdSV9v6uWNZhvtTgv5GrSCmH1-bWR6Ljj=EbHF5xf0D1UKVaQ@mail.gmail.com>
References: <CAFdSV9tD2jK9rZiY596m-UrVHPYNA3+kpd8Y3anUtOg9HtpdYg@mail.gmail.com>
	<CAFdSV9v6uWNZhvtTgv5GrSCmH1-bWR6Ljj=EbHF5xf0D1UKVaQ@mail.gmail.com>
Message-ID: <CAFdSV9s+fwrZ9Fn1k9nAQmGQv9-TGaJMK966RiHUdm-7bHnKCg@mail.gmail.com>

Anyone remember the back-story
on org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor#useAnnotationAnnotatedByListener?

If I read it correctly, it is looking at annotations on the entity seeing
if any of those annotations are in turn annotated with @EntityListeners.

On Fri, Jan 22, 2016 at 3:38 PM Steve Ebersole <steve at hibernate.org> wrote:

> If it matters, my plan is as follows...
>
> Currently JpaIntegrator is the central point for this processing.  The
> general premise is that it builds a CallbackRegistry, a ListenerFactory
> and a CallbackProcessor.  It then uses the CallbackProcessor and ListenerFactory
> to populate the CallbackRegistry.  This part is the crux of the problem
> with HHH-8076 as after this JpaIntegrator call it is expected that CallbackRegistry
> be fully initialized (all Callbacks resolved and ready to go).
>
> So the plan is to instead invert these relationships to where we build a CallbackRegistry
> that is aware of the ListenerFactory and CallbackProcessor (actually I
> think CallbackProcessor can go away).  This is the point in the suggested
> solution described for HHH-8076 where we'd check the BeanManager to see if
> it is a BeanManagerExtension and decide whether to delay the
> initialization.  If that plan causes trouble for anyone, please speak up
> asap.  If not, I'll proceed.
>
> Thanks!
>
> On Fri, Jan 22, 2016 at 3:28 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> As part of the work on HHH-8076 for ORM 5.1 I am going to have to change
>> up, in some fashion, some or all of the following internal/spi contracts :
>>
>> * org.hibernate.jpa.event.spi.jpa.Callback
>> * org.hibernate.jpa.event.spi.jpa.CallbackRegistry
>> * org.hibernate.jpa.event.spi.jpa.ListenerFactory
>> * org.hibernate.jpa.event.internal.jpa.CallbackProcessor
>>
>> I need to know whether any integrations either use any of these or
>> provide custom impls for any of them.
>>
>

From steve at hibernate.org  Sat Jan 23 14:01:41 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 23 Jan 2016 19:01:41 +0000
Subject: [hibernate-dev] 5.1 tentative release date
In-Reply-To: <CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
Message-ID: <CAFdSV9uFiC5HC0juZOU8fMSyvHyfybmuW81ztxi18aAVvx6gWQ@mail.gmail.com>

Gillaume, I am still seeing conflicts....


On Wed, Jan 13, 2016 at 7:10 AM Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> If you clean up the conflicts I can look for 5.1
>>
>
> Done!
>
> --
> Guillaume
>

From rvansa at redhat.com  Mon Jan 25 05:48:36 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 25 Jan 2016 11:48:36 +0100
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <CAFdSV9tLsMq6Jb=+gO+DqqQy4927qQKkwyS5An6-8ivgMdgbvg@mail.gmail.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com> <56A22CB7.2060404@redhat.com>
	<CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>
	<56A24AFA.7030902@redhat.com>
	<CAFdSV9tLsMq6Jb=+gO+DqqQy4927qQKkwyS5An6-8ivgMdgbvg@mail.gmail.com>
Message-ID: <56A5FD84.20601@redhat.com>

On 01/22/2016 05:26 PM, Steve Ebersole wrote:
> On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     On 01/22/2016 03:11 PM, Steve Ebersole wrote:
>     > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <rvansa at redhat.com
>     <mailto:rvansa at redhat.com>
>     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
>     >
>     >     Why should the strategy 'never be used if serializable
>     transaction
>     >     isolation level is required'? What guarantees it gives, and what
>     >     in ORM
>     >     core depends on this?  When I've asked the last time, Steve said
>     >     that all modes but the
>     >
>     >     nonstrict one require that the 2LC is absolutely transparent
>     >     (consistency-wise), so you always get the same answer as if
>     you were
>     >     directly talking to DB.
>     >
>     >
>     > I would guess this is talking about "serializable isolation" at the
>     > application layer.  Yes extended across both the application and
>     > database.  In our original implementations we had no L2 cache
>     > providers that would support serializable isolation. Does
>     > hibernate-infinispan? If we ask for a certain entry from the
>     cache in
>     > T1, T2 adds that entry and commits, and then we ask for it again
>     in T1
>     > do we still see it as "not existing"?  I'd highly doubt it, but
>     if it
>     > does then lets make note of that.
>
>     No, without a transactional cache, it does not. Thanks for the
>     example.
>     But will the request get to 2LC, or will it be served already from
>     Session cache?
>
>
> It won't work even with a transactional cache I believe. It won't work 
> with Infinispan e.g. I do not think. Hibernate does not keep reference 
> to "non-existing" entities.  That's the only way the Session could 
> "serve" the fact that the first T1 lookup found nothing.  Again, this 
> gets right back to that idea of consistency.  Without L2 caching, in 
> this scenario with serializable isolation the database would return me 
> "no row" in both T1 SELECTs.

Infinispan keeps 'transactional context' for the current transaction and 
stores all reads there, even if this is a null read. However, as I've 
checked the distribution code, it still does the remote lookup (which 
escapes the transaction) and the value could get there even with 
so-called repeatable reads. I'll check infinispan-dev why.

>
>     >  Does the ' you should ensure that the transaction is completed when
>     >     `Session.close()` or `Session.disconnect()` is called' still
>     hold, or
>     >     does the transactional rework in 5.0 somehow obsolete this info?
>     >
>     >
>     > I cannot say why this is discussed in a chapter on caching.
>     > Session#disconnect is largely deprecated (its main use case is
>     handled
>     > much more transparently now).  IMO it's always a good idea to make
>     > sure a transaction against a resource is completed prior to closing
>     > that transaction. That's no different for a Hibernate Session
>     then it
>     > is for a JDBC Connection, etc.
>
>     Did you meant 'commit the transaction before closing the session'? If
>     the Session.close() is called with tx open, will the transaction be
>     committed? But any way, this should be really the same as without 2LC.
>
>
> I meant to say " make sure a transaction against a resource is 
> completed prior to closing that resource". Saying "complete the 
> transaction" != "commit the transaction".  Completion might be either 
> commit or rollback.  But the idea is that it is in a definitive state.
>
> Historically what a stranded transaction at the time of Session#close 
> meant depended on the JDBC driver.  Most drivers rollback back on a 
> stranded transaction; Oracle has always been the notable exception as 
> they would commit a stranded transaction.  But regardless in terms of 
> Session locks etc in the cache that would strand the locks as well iirc.
>
> In developing 5.0 and the new transaction handling I know we talked 
> about making this more deterministic, specifically always handling 
> this as if a rollback had been called.  But to be honest, that's not 
> what I am seeing in the code. Andrea, do you remember?  If not, we 
> should definitely add some tests for this to see what happens atm and 
> make sure its really what we want to have happen moving forward.
>
>
>     > Basically this passage is a poorly worded hint.  What it is
>     trying to
>     > convey is that for "asynchronous" cache access what drives the
>     > interactions with the Cache is the Hibernate transaction, and in
>     these
>     > case the user should take extra care to make sure that the
>     transaction
>     > is handled properly. That still holds true.
>     >
>     > As a refresher, the idea of "synchronous" versus "asynchronous" is
>     > simply cache access that is driven by JTA ("synchronous") versus
>     those
>     > that are driven by local transactions ("asynchronous"). 
>
>
>     Eh, I probably don't get the exact meaning of 'driving the access' :-/
>     And I can't find any reference to 'async' in user guide.
>
>
> I keep pointing y'all to 
> org.hibernate.cache.spi.access.EntityRegionAccessStrategy, 
> org.hibernate.cache.spi.access.CollectionRegionAccessStrategy, etc as 
> the best source for this information.  I spent a lot of time 
>  documenting (javadoc) these contracts as I developed them. 
>  sync/async is discussed there.  No need for it to be discussed in the 
> user guide IMO, its a concept for developers of cache implementations 
> to understand not users.

Okay, this sync/async. Sure, then it makes sense that it's not in user 
guide. But pardon my confusion, that class documents which methods are 
used by sync/async strategies, and what's the order of method 
invocation, but I never got what is the idea behind the sync/async 
strategy differentiation. As I've started messing with ORM only after 
the 5.0 tx rework, I always considered the difference between JTA and 
local transactions just an implementation detail orthogonal to 2LC.

Radim

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From mihalcea.vlad at gmail.com  Mon Jan 25 05:55:24 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 25 Jan 2016 12:55:24 +0200
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <56A5FD84.20601@redhat.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com> <56A22CB7.2060404@redhat.com>
	<CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>
	<56A24AFA.7030902@redhat.com>
	<CAFdSV9tLsMq6Jb=+gO+DqqQy4927qQKkwyS5An6-8ivgMdgbvg@mail.gmail.com>
	<56A5FD84.20601@redhat.com>
Message-ID: <CA+gWKMCostU3jJ=rQeU0cE7MLx1bkZagwC0c9KfL4TSF+gieuQ@mail.gmail.com>

Hi,

I have some sequence diagrams depicting the async/sync behavior if you are
interested:

For async: NONSTREICT_READ_WRITE and READ_WRITE:

http://vladmihalcea.com/2015/05/18/how-does-hibernate-nonstrict_read_write-cacheconcurrencystrategy-work/
http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/

For sync: TRANSACTIONAL

http://vladmihalcea.com/2015/06/01/how-does-hibernate-transactional-cacheconcurrencystrategy-work/

Only the region strategy differs since it's not Ehcache, but everything
else is from Hibernate API.

Vlad

On Mon, Jan 25, 2016 at 12:48 PM, Radim Vansa <rvansa at redhat.com> wrote:

> On 01/22/2016 05:26 PM, Steve Ebersole wrote:
> > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa at redhat.com
> > <mailto:rvansa at redhat.com>> wrote:
> >
> >     On 01/22/2016 03:11 PM, Steve Ebersole wrote:
> >     > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <rvansa at redhat.com
> >     <mailto:rvansa at redhat.com>
> >     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
> >     >
> >     >     Why should the strategy 'never be used if serializable
> >     transaction
> >     >     isolation level is required'? What guarantees it gives, and
> what
> >     >     in ORM
> >     >     core depends on this?  When I've asked the last time, Steve
> said
> >     >     that all modes but the
> >     >
> >     >     nonstrict one require that the 2LC is absolutely transparent
> >     >     (consistency-wise), so you always get the same answer as if
> >     you were
> >     >     directly talking to DB.
> >     >
> >     >
> >     > I would guess this is talking about "serializable isolation" at the
> >     > application layer.  Yes extended across both the application and
> >     > database.  In our original implementations we had no L2 cache
> >     > providers that would support serializable isolation. Does
> >     > hibernate-infinispan? If we ask for a certain entry from the
> >     cache in
> >     > T1, T2 adds that entry and commits, and then we ask for it again
> >     in T1
> >     > do we still see it as "not existing"?  I'd highly doubt it, but
> >     if it
> >     > does then lets make note of that.
> >
> >     No, without a transactional cache, it does not. Thanks for the
> >     example.
> >     But will the request get to 2LC, or will it be served already from
> >     Session cache?
> >
> >
> > It won't work even with a transactional cache I believe. It won't work
> > with Infinispan e.g. I do not think. Hibernate does not keep reference
> > to "non-existing" entities.  That's the only way the Session could
> > "serve" the fact that the first T1 lookup found nothing.  Again, this
> > gets right back to that idea of consistency.  Without L2 caching, in
> > this scenario with serializable isolation the database would return me
> > "no row" in both T1 SELECTs.
>
> Infinispan keeps 'transactional context' for the current transaction and
> stores all reads there, even if this is a null read. However, as I've
> checked the distribution code, it still does the remote lookup (which
> escapes the transaction) and the value could get there even with
> so-called repeatable reads. I'll check infinispan-dev why.
>
> >
> >     >  Does the ' you should ensure that the transaction is completed
> when
> >     >     `Session.close()` or `Session.disconnect()` is called' still
> >     hold, or
> >     >     does the transactional rework in 5.0 somehow obsolete this
> info?
> >     >
> >     >
> >     > I cannot say why this is discussed in a chapter on caching.
> >     > Session#disconnect is largely deprecated (its main use case is
> >     handled
> >     > much more transparently now).  IMO it's always a good idea to make
> >     > sure a transaction against a resource is completed prior to closing
> >     > that transaction. That's no different for a Hibernate Session
> >     then it
> >     > is for a JDBC Connection, etc.
> >
> >     Did you meant 'commit the transaction before closing the session'? If
> >     the Session.close() is called with tx open, will the transaction be
> >     committed? But any way, this should be really the same as without
> 2LC.
> >
> >
> > I meant to say " make sure a transaction against a resource is
> > completed prior to closing that resource". Saying "complete the
> > transaction" != "commit the transaction".  Completion might be either
> > commit or rollback.  But the idea is that it is in a definitive state.
> >
> > Historically what a stranded transaction at the time of Session#close
> > meant depended on the JDBC driver.  Most drivers rollback back on a
> > stranded transaction; Oracle has always been the notable exception as
> > they would commit a stranded transaction.  But regardless in terms of
> > Session locks etc in the cache that would strand the locks as well iirc.
> >
> > In developing 5.0 and the new transaction handling I know we talked
> > about making this more deterministic, specifically always handling
> > this as if a rollback had been called.  But to be honest, that's not
> > what I am seeing in the code. Andrea, do you remember?  If not, we
> > should definitely add some tests for this to see what happens atm and
> > make sure its really what we want to have happen moving forward.
> >
> >
> >     > Basically this passage is a poorly worded hint.  What it is
> >     trying to
> >     > convey is that for "asynchronous" cache access what drives the
> >     > interactions with the Cache is the Hibernate transaction, and in
> >     these
> >     > case the user should take extra care to make sure that the
> >     transaction
> >     > is handled properly. That still holds true.
> >     >
> >     > As a refresher, the idea of "synchronous" versus "asynchronous" is
> >     > simply cache access that is driven by JTA ("synchronous") versus
> >     those
> >     > that are driven by local transactions ("asynchronous").
> >
> >
> >     Eh, I probably don't get the exact meaning of 'driving the access'
> :-/
> >     And I can't find any reference to 'async' in user guide.
> >
> >
> > I keep pointing y'all to
> > org.hibernate.cache.spi.access.EntityRegionAccessStrategy,
> > org.hibernate.cache.spi.access.CollectionRegionAccessStrategy, etc as
> > the best source for this information.  I spent a lot of time
> >  documenting (javadoc) these contracts as I developed them.
> >  sync/async is discussed there.  No need for it to be discussed in the
> > user guide IMO, its a concept for developers of cache implementations
> > to understand not users.
>
> Okay, this sync/async. Sure, then it makes sense that it's not in user
> guide. But pardon my confusion, that class documents which methods are
> used by sync/async strategies, and what's the order of method
> invocation, but I never got what is the idea behind the sync/async
> strategy differentiation. As I've started messing with ORM only after
> the 5.0 tx rework, I always considered the difference between JTA and
> local transactions just an implementation detail orthogonal to 2LC.
>
> Radim
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From rvansa at redhat.com  Mon Jan 25 06:46:57 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 25 Jan 2016 12:46:57 +0100
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <CA+gWKMCostU3jJ=rQeU0cE7MLx1bkZagwC0c9KfL4TSF+gieuQ@mail.gmail.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com> <56A22CB7.2060404@redhat.com>
	<CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>
	<56A24AFA.7030902@redhat.com>
	<CAFdSV9tLsMq6Jb=+gO+DqqQy4927qQKkwyS5An6-8ivgMdgbvg@mail.gmail.com>
	<56A5FD84.20601@redhat.com>
	<CA+gWKMCostU3jJ=rQeU0cE7MLx1bkZagwC0c9KfL4TSF+gieuQ@mail.gmail.com>
Message-ID: <56A60B31.5010200@redhat.com>

I wish the docs were as descriptive as your blog - thanks Vlad! (so, I 
should make that happen).

So I (hopefully) finally understand what you mean by sync/async:
* sync implements only certain methods from the *RegionAccessStrategy 
and the two-phase commit requires TM calling 2LC directly (either by 
registering itself as XAResource or Synchronization)
* async implements all methods and does not need to interact with TM at all.

However, this is just an implementation detail which should not relate 
to cache concurrency strategy, should it? CCS should define only the 
isolation level achieved, and that is:
* nonstrict-read-write: read committed with short window for stale reads 
during commit
* read-write: read committed
* transactional: serializable

Radim

On 01/25/2016 11:55 AM, Vlad Mihalcea wrote:
> Hi,
>
> I have some sequence diagrams depicting the async/sync behavior if you 
> are interested:
>
> For async: NONSTREICT_READ_WRITE and READ_WRITE:
>
> http://vladmihalcea.com/2015/05/18/how-does-hibernate-nonstrict_read_write-cacheconcurrencystrategy-work/
> http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/
>
> For sync: TRANSACTIONAL
>
> http://vladmihalcea.com/2015/06/01/how-does-hibernate-transactional-cacheconcurrencystrategy-work/
>
> Only the region strategy differs since it's not Ehcache, but 
> everything else is from Hibernate API.
>
> Vlad
>
> On Mon, Jan 25, 2016 at 12:48 PM, Radim Vansa <rvansa at redhat.com 
> <mailto:rvansa at redhat.com>> wrote:
>
>     On 01/22/2016 05:26 PM, Steve Ebersole wrote:
>     > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa at redhat.com
>     <mailto:rvansa at redhat.com>
>     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
>     >
>     >     On 01/22/2016 03:11 PM, Steve Ebersole wrote:
>     >     > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa
>     <rvansa at redhat.com <mailto:rvansa at redhat.com>
>     >     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     >     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>
>     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>>> wrote:
>     >     >
>     >     >     Why should the strategy 'never be used if serializable
>     >     transaction
>     >     >     isolation level is required'? What guarantees it
>     gives, and what
>     >     >     in ORM
>     >     >     core depends on this?  When I've asked the last time,
>     Steve said
>     >     >     that all modes but the
>     >     >
>     >     >     nonstrict one require that the 2LC is absolutely
>     transparent
>     >     >     (consistency-wise), so you always get the same answer
>     as if
>     >     you were
>     >     >     directly talking to DB.
>     >     >
>     >     >
>     >     > I would guess this is talking about "serializable
>     isolation" at the
>     >     > application layer.  Yes extended across both the
>     application and
>     >     > database.  In our original implementations we had no L2 cache
>     >     > providers that would support serializable isolation. Does
>     >     > hibernate-infinispan? If we ask for a certain entry from the
>     >     cache in
>     >     > T1, T2 adds that entry and commits, and then we ask for it
>     again
>     >     in T1
>     >     > do we still see it as "not existing"?  I'd highly doubt
>     it, but
>     >     if it
>     >     > does then lets make note of that.
>     >
>     >     No, without a transactional cache, it does not. Thanks for the
>     >     example.
>     >     But will the request get to 2LC, or will it be served
>     already from
>     >     Session cache?
>     >
>     >
>     > It won't work even with a transactional cache I believe. It
>     won't work
>     > with Infinispan e.g. I do not think. Hibernate does not keep
>     reference
>     > to "non-existing" entities.  That's the only way the Session could
>     > "serve" the fact that the first T1 lookup found nothing.  Again,
>     this
>     > gets right back to that idea of consistency. Without L2 caching, in
>     > this scenario with serializable isolation the database would
>     return me
>     > "no row" in both T1 SELECTs.
>
>     Infinispan keeps 'transactional context' for the current
>     transaction and
>     stores all reads there, even if this is a null read. However, as I've
>     checked the distribution code, it still does the remote lookup (which
>     escapes the transaction) and the value could get there even with
>     so-called repeatable reads. I'll check infinispan-dev why.
>
>     >
>     >     >  Does the ' you should ensure that the transaction is
>     completed when
>     >     >     `Session.close()` or `Session.disconnect()` is called'
>     still
>     >     hold, or
>     >     >     does the transactional rework in 5.0 somehow obsolete
>     this info?
>     >     >
>     >     >
>     >     > I cannot say why this is discussed in a chapter on caching.
>     >     > Session#disconnect is largely deprecated (its main use case is
>     >     handled
>     >     > much more transparently now).  IMO it's always a good idea
>     to make
>     >     > sure a transaction against a resource is completed prior
>     to closing
>     >     > that transaction. That's no different for a Hibernate Session
>     >     then it
>     >     > is for a JDBC Connection, etc.
>     >
>     >     Did you meant 'commit the transaction before closing the
>     session'? If
>     >     the Session.close() is called with tx open, will the
>     transaction be
>     >     committed? But any way, this should be really the same as
>     without 2LC.
>     >
>     >
>     > I meant to say " make sure a transaction against a resource is
>     > completed prior to closing that resource". Saying "complete the
>     > transaction" != "commit the transaction". Completion might be either
>     > commit or rollback.  But the idea is that it is in a definitive
>     state.
>     >
>     > Historically what a stranded transaction at the time of
>     Session#close
>     > meant depended on the JDBC driver.  Most drivers rollback back on a
>     > stranded transaction; Oracle has always been the notable
>     exception as
>     > they would commit a stranded transaction.  But regardless in
>     terms of
>     > Session locks etc in the cache that would strand the locks as
>     well iirc.
>     >
>     > In developing 5.0 and the new transaction handling I know we talked
>     > about making this more deterministic, specifically always handling
>     > this as if a rollback had been called.  But to be honest, that's not
>     > what I am seeing in the code. Andrea, do you remember?  If not, we
>     > should definitely add some tests for this to see what happens
>     atm and
>     > make sure its really what we want to have happen moving forward.
>     >
>     >
>     >     > Basically this passage is a poorly worded hint.  What it is
>     >     trying to
>     >     > convey is that for "asynchronous" cache access what drives the
>     >     > interactions with the Cache is the Hibernate transaction,
>     and in
>     >     these
>     >     > case the user should take extra care to make sure that the
>     >     transaction
>     >     > is handled properly. That still holds true.
>     >     >
>     >     > As a refresher, the idea of "synchronous" versus
>     "asynchronous" is
>     >     > simply cache access that is driven by JTA ("synchronous")
>     versus
>     >     those
>     >     > that are driven by local transactions ("asynchronous").
>     >
>     >
>     >     Eh, I probably don't get the exact meaning of 'driving the
>     access' :-/
>     >     And I can't find any reference to 'async' in user guide.
>     >
>     >
>     > I keep pointing y'all to
>     > org.hibernate.cache.spi.access.EntityRegionAccessStrategy,
>     > org.hibernate.cache.spi.access.CollectionRegionAccessStrategy,
>     etc as
>     > the best source for this information.  I spent a lot of time
>     >  documenting (javadoc) these contracts as I developed them.
>     >  sync/async is discussed there.  No need for it to be discussed
>     in the
>     > user guide IMO, its a concept for developers of cache
>     implementations
>     > to understand not users.
>
>     Okay, this sync/async. Sure, then it makes sense that it's not in user
>     guide. But pardon my confusion, that class documents which methods are
>     used by sync/async strategies, and what's the order of method
>     invocation, but I never got what is the idea behind the sync/async
>     strategy differentiation. As I've started messing with ORM only after
>     the 5.0 tx rework, I always considered the difference between JTA and
>     local transactions just an implementation detail orthogonal to 2LC.
>
>     Radim
>
>     --
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From rvansa at redhat.com  Mon Jan 25 07:05:59 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 25 Jan 2016 13:05:59 +0100
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <56A5FD84.20601@redhat.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com> <56A22CB7.2060404@redhat.com>
	<CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>
	<56A24AFA.7030902@redhat.com>
	<CAFdSV9tLsMq6Jb=+gO+DqqQy4927qQKkwyS5An6-8ivgMdgbvg@mail.gmail.com>
	<56A5FD84.20601@redhat.com>
Message-ID: <56A60FA7.5000205@redhat.com>

On 01/25/2016 11:48 AM, Radim Vansa wrote:
> On 01/22/2016 05:26 PM, Steve Ebersole wrote:
>> On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa at redhat.com 
>> <mailto:rvansa at redhat.com>> wrote:
>>
>>     On 01/22/2016 03:11 PM, Steve Ebersole wrote:
>>     > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa <rvansa at redhat.com
>>     <mailto:rvansa at redhat.com>
>>     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
>>     >
>>     >     Why should the strategy 'never be used if serializable
>>     transaction
>>     >     isolation level is required'? What guarantees it gives, and 
>> what
>>     >     in ORM
>>     >     core depends on this?  When I've asked the last time, Steve 
>> said
>>     >     that all modes but the
>>     >
>>     >     nonstrict one require that the 2LC is absolutely transparent
>>     >     (consistency-wise), so you always get the same answer as if
>>     you were
>>     >     directly talking to DB.
>>     >
>>     >
>>     > I would guess this is talking about "serializable isolation" at 
>> the
>>     > application layer.  Yes extended across both the application and
>>     > database.  In our original implementations we had no L2 cache
>>     > providers that would support serializable isolation. Does
>>     > hibernate-infinispan? If we ask for a certain entry from the
>>     cache in
>>     > T1, T2 adds that entry and commits, and then we ask for it again
>>     in T1
>>     > do we still see it as "not existing"?  I'd highly doubt it, but
>>     if it
>>     > does then lets make note of that.
>>
>>     No, without a transactional cache, it does not. Thanks for the
>>     example.
>>     But will the request get to 2LC, or will it be served already from
>>     Session cache?
>>
>>
>> It won't work even with a transactional cache I believe. It won't 
>> work with Infinispan e.g. I do not think. Hibernate does not keep 
>> reference to "non-existing" entities.  That's the only way the 
>> Session could "serve" the fact that the first T1 lookup found 
>> nothing.  Again, this gets right back to that idea of consistency.  
>> Without L2 caching, in this scenario with serializable isolation the 
>> database would return me "no row" in both T1 SELECTs.
>
> Infinispan keeps 'transactional context' for the current transaction 
> and stores all reads there, even if this is a null read. However, as 
> I've checked the distribution code, it still does the remote lookup 
> (which escapes the transaction) and the value could get there even 
> with so-called repeatable reads. I'll check infinispan-dev why.

So it seems that Infinispan handles repeatable reads of null correctly.

>
>>
>>     >  Does the ' you should ensure that the transaction is completed 
>> when
>>     >     `Session.close()` or `Session.disconnect()` is called' still
>>     hold, or
>>     >     does the transactional rework in 5.0 somehow obsolete this 
>> info?
>>     >
>>     >
>>     > I cannot say why this is discussed in a chapter on caching.
>>     > Session#disconnect is largely deprecated (its main use case is
>>     handled
>>     > much more transparently now).  IMO it's always a good idea to make
>>     > sure a transaction against a resource is completed prior to 
>> closing
>>     > that transaction. That's no different for a Hibernate Session
>>     then it
>>     > is for a JDBC Connection, etc.
>>
>>     Did you meant 'commit the transaction before closing the 
>> session'? If
>>     the Session.close() is called with tx open, will the transaction be
>>     committed? But any way, this should be really the same as without 
>> 2LC.
>>
>>
>> I meant to say " make sure a transaction against a resource is 
>> completed prior to closing that resource". Saying "complete the 
>> transaction" != "commit the transaction".  Completion might be either 
>> commit or rollback.  But the idea is that it is in a definitive state.
>>
>> Historically what a stranded transaction at the time of Session#close 
>> meant depended on the JDBC driver.  Most drivers rollback back on a 
>> stranded transaction; Oracle has always been the notable exception as 
>> they would commit a stranded transaction.  But regardless in terms of 
>> Session locks etc in the cache that would strand the locks as well iirc.
>>
>> In developing 5.0 and the new transaction handling I know we talked 
>> about making this more deterministic, specifically always handling 
>> this as if a rollback had been called.  But to be honest, that's not 
>> what I am seeing in the code. Andrea, do you remember?  If not, we 
>> should definitely add some tests for this to see what happens atm and 
>> make sure its really what we want to have happen moving forward.
>>
>>
>>     > Basically this passage is a poorly worded hint.  What it is
>>     trying to
>>     > convey is that for "asynchronous" cache access what drives the
>>     > interactions with the Cache is the Hibernate transaction, and in
>>     these
>>     > case the user should take extra care to make sure that the
>>     transaction
>>     > is handled properly. That still holds true.
>>     >
>>     > As a refresher, the idea of "synchronous" versus "asynchronous" is
>>     > simply cache access that is driven by JTA ("synchronous") versus
>>     those
>>     > that are driven by local transactions ("asynchronous").
>>
>>     Eh, I probably don't get the exact meaning of 'driving the 
>> access' :-/
>>     And I can't find any reference to 'async' in user guide.
>>
>>
>> I keep pointing y'all to 
>> org.hibernate.cache.spi.access.EntityRegionAccessStrategy, 
>> org.hibernate.cache.spi.access.CollectionRegionAccessStrategy, etc as 
>> the best source for this information.  I spent a lot of time 
>>  documenting (javadoc) these contracts as I developed them. 
>>  sync/async is discussed there.  No need for it to be discussed in 
>> the user guide IMO, its a concept for developers of cache 
>> implementations to understand not users.
>
> Okay, this sync/async. Sure, then it makes sense that it's not in user 
> guide. But pardon my confusion, that class documents which methods are 
> used by sync/async strategies, and what's the order of method 
> invocation, but I never got what is the idea behind the sync/async 
> strategy differentiation. As I've started messing with ORM only after 
> the 5.0 tx rework, I always considered the difference between JTA and 
> local transactions just an implementation detail orthogonal to 2LC.
>
> Radim
>


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From mihalcea.vlad at gmail.com  Mon Jan 25 07:22:30 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Mon, 25 Jan 2016 14:22:30 +0200
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <56A60B31.5010200@redhat.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com> <56A22CB7.2060404@redhat.com>
	<CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>
	<56A24AFA.7030902@redhat.com>
	<CAFdSV9tLsMq6Jb=+gO+DqqQy4927qQKkwyS5An6-8ivgMdgbvg@mail.gmail.com>
	<56A5FD84.20601@redhat.com>
	<CA+gWKMCostU3jJ=rQeU0cE7MLx1bkZagwC0c9KfL4TSF+gieuQ@mail.gmail.com>
	<56A60B31.5010200@redhat.com>
Message-ID: <CA+gWKMCAmS4Q=-cTxNn+a5EAjyMt5L2oq9HHAn1+TjKGms869A@mail.gmail.com>

Thanks. Well, the User Guide must detail the API and focus on general usage.
We don't want to scare users with internal details that are more useful in
a Developer Guide or Integrator Guide.
So we must find the right balance for what info we supply in the User Guide.


Vlad

On Mon, Jan 25, 2016 at 1:46 PM, Radim Vansa <rvansa at redhat.com> wrote:

> I wish the docs were as descriptive as your blog - thanks Vlad! (so, I
> should make that happen).
>
> So I (hopefully) finally understand what you mean by sync/async:
> * sync implements only certain methods from the *RegionAccessStrategy and
> the two-phase commit requires TM calling 2LC directly (either by
> registering itself as XAResource or Synchronization)
> * async implements all methods and does not need to interact with TM at
> all.
>
> However, this is just an implementation detail which should not relate to
> cache concurrency strategy, should it? CCS should define only the isolation
> level achieved, and that is:
> * nonstrict-read-write: read committed with short window for stale reads
> during commit
> * read-write: read committed
> * transactional: serializable
>
> Radim
>
> On 01/25/2016 11:55 AM, Vlad Mihalcea wrote:
>
>> Hi,
>>
>> I have some sequence diagrams depicting the async/sync behavior if you
>> are interested:
>>
>> For async: NONSTREICT_READ_WRITE and READ_WRITE:
>>
>>
>> http://vladmihalcea.com/2015/05/18/how-does-hibernate-nonstrict_read_write-cacheconcurrencystrategy-work/
>>
>> http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/
>>
>> For sync: TRANSACTIONAL
>>
>>
>> http://vladmihalcea.com/2015/06/01/how-does-hibernate-transactional-cacheconcurrencystrategy-work/
>>
>> Only the region strategy differs since it's not Ehcache, but everything
>> else is from Hibernate API.
>>
>> Vlad
>>
>> On Mon, Jan 25, 2016 at 12:48 PM, Radim Vansa <rvansa at redhat.com <mailto:
>> rvansa at redhat.com>> wrote:
>>
>>     On 01/22/2016 05:26 PM, Steve Ebersole wrote:
>>     > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa at redhat.com
>>     <mailto:rvansa at redhat.com>
>>     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
>>     >
>>     >     On 01/22/2016 03:11 PM, Steve Ebersole wrote:
>>     >     > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa
>>     <rvansa at redhat.com <mailto:rvansa at redhat.com>
>>     >     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>
>>     >     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>
>>     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>>> wrote:
>>     >     >
>>     >     >     Why should the strategy 'never be used if serializable
>>     >     transaction
>>     >     >     isolation level is required'? What guarantees it
>>     gives, and what
>>     >     >     in ORM
>>     >     >     core depends on this?  When I've asked the last time,
>>     Steve said
>>     >     >     that all modes but the
>>     >     >
>>     >     >     nonstrict one require that the 2LC is absolutely
>>     transparent
>>     >     >     (consistency-wise), so you always get the same answer
>>     as if
>>     >     you were
>>     >     >     directly talking to DB.
>>     >     >
>>     >     >
>>     >     > I would guess this is talking about "serializable
>>     isolation" at the
>>     >     > application layer.  Yes extended across both the
>>     application and
>>     >     > database.  In our original implementations we had no L2 cache
>>     >     > providers that would support serializable isolation. Does
>>     >     > hibernate-infinispan? If we ask for a certain entry from the
>>     >     cache in
>>     >     > T1, T2 adds that entry and commits, and then we ask for it
>>     again
>>     >     in T1
>>     >     > do we still see it as "not existing"?  I'd highly doubt
>>     it, but
>>     >     if it
>>     >     > does then lets make note of that.
>>     >
>>     >     No, without a transactional cache, it does not. Thanks for the
>>     >     example.
>>     >     But will the request get to 2LC, or will it be served
>>     already from
>>     >     Session cache?
>>     >
>>     >
>>     > It won't work even with a transactional cache I believe. It
>>     won't work
>>     > with Infinispan e.g. I do not think. Hibernate does not keep
>>     reference
>>     > to "non-existing" entities.  That's the only way the Session could
>>     > "serve" the fact that the first T1 lookup found nothing.  Again,
>>     this
>>     > gets right back to that idea of consistency. Without L2 caching, in
>>     > this scenario with serializable isolation the database would
>>     return me
>>     > "no row" in both T1 SELECTs.
>>
>>     Infinispan keeps 'transactional context' for the current
>>     transaction and
>>     stores all reads there, even if this is a null read. However, as I've
>>     checked the distribution code, it still does the remote lookup (which
>>     escapes the transaction) and the value could get there even with
>>     so-called repeatable reads. I'll check infinispan-dev why.
>>
>>     >
>>     >     >  Does the ' you should ensure that the transaction is
>>     completed when
>>     >     >     `Session.close()` or `Session.disconnect()` is called'
>>     still
>>     >     hold, or
>>     >     >     does the transactional rework in 5.0 somehow obsolete
>>     this info?
>>     >     >
>>     >     >
>>     >     > I cannot say why this is discussed in a chapter on caching.
>>     >     > Session#disconnect is largely deprecated (its main use case is
>>     >     handled
>>     >     > much more transparently now).  IMO it's always a good idea
>>     to make
>>     >     > sure a transaction against a resource is completed prior
>>     to closing
>>     >     > that transaction. That's no different for a Hibernate Session
>>     >     then it
>>     >     > is for a JDBC Connection, etc.
>>     >
>>     >     Did you meant 'commit the transaction before closing the
>>     session'? If
>>     >     the Session.close() is called with tx open, will the
>>     transaction be
>>     >     committed? But any way, this should be really the same as
>>     without 2LC.
>>     >
>>     >
>>     > I meant to say " make sure a transaction against a resource is
>>     > completed prior to closing that resource". Saying "complete the
>>     > transaction" != "commit the transaction". Completion might be either
>>     > commit or rollback.  But the idea is that it is in a definitive
>>     state.
>>     >
>>     > Historically what a stranded transaction at the time of
>>     Session#close
>>     > meant depended on the JDBC driver.  Most drivers rollback back on a
>>     > stranded transaction; Oracle has always been the notable
>>     exception as
>>     > they would commit a stranded transaction.  But regardless in
>>     terms of
>>     > Session locks etc in the cache that would strand the locks as
>>     well iirc.
>>     >
>>     > In developing 5.0 and the new transaction handling I know we talked
>>     > about making this more deterministic, specifically always handling
>>     > this as if a rollback had been called.  But to be honest, that's not
>>     > what I am seeing in the code. Andrea, do you remember?  If not, we
>>     > should definitely add some tests for this to see what happens
>>     atm and
>>     > make sure its really what we want to have happen moving forward.
>>     >
>>     >
>>     >     > Basically this passage is a poorly worded hint.  What it is
>>     >     trying to
>>     >     > convey is that for "asynchronous" cache access what drives the
>>     >     > interactions with the Cache is the Hibernate transaction,
>>     and in
>>     >     these
>>     >     > case the user should take extra care to make sure that the
>>     >     transaction
>>     >     > is handled properly. That still holds true.
>>     >     >
>>     >     > As a refresher, the idea of "synchronous" versus
>>     "asynchronous" is
>>     >     > simply cache access that is driven by JTA ("synchronous")
>>     versus
>>     >     those
>>     >     > that are driven by local transactions ("asynchronous").
>>     >
>>     >
>>     >     Eh, I probably don't get the exact meaning of 'driving the
>>     access' :-/
>>     >     And I can't find any reference to 'async' in user guide.
>>     >
>>     >
>>     > I keep pointing y'all to
>>     > org.hibernate.cache.spi.access.EntityRegionAccessStrategy,
>>     > org.hibernate.cache.spi.access.CollectionRegionAccessStrategy,
>>     etc as
>>     > the best source for this information.  I spent a lot of time
>>     >  documenting (javadoc) these contracts as I developed them.
>>     >  sync/async is discussed there.  No need for it to be discussed
>>     in the
>>     > user guide IMO, its a concept for developers of cache
>>     implementations
>>     > to understand not users.
>>
>>     Okay, this sync/async. Sure, then it makes sense that it's not in user
>>     guide. But pardon my confusion, that class documents which methods are
>>     used by sync/async strategies, and what's the order of method
>>     invocation, but I never got what is the idea behind the sync/async
>>     strategy differentiation. As I've started messing with ORM only after
>>     the 5.0 tx rework, I always considered the difference between JTA and
>>     local transactions just an implementation detail orthogonal to 2LC.
>>
>>     Radim
>>
>>     --
>>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>>     JBoss Performance Team
>>
>>     _______________________________________________
>>     hibernate-dev mailing list
>>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
>

From steve at hibernate.org  Mon Jan 25 12:16:05 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jan 2016 17:16:05 +0000
Subject: [hibernate-dev] HHH-9993 - IsolationDelegate + no-Connection
Message-ID: <CAFdSV9s-JeUQQA=9XKen4QR=UFRk5Owf=an1m-+TR6qyAjKDMA@mail.gmail.com>

HHH-9993[1] is a request to extend IsolationDelegate to cater for
transaction hooks which do not need access to a JDBC Connection.

A quick primer for those unfamiliar, IsolationDelegate is a contract to
allow work to be done in a fashion that makes sure it is isolated from the
main Session transaction.  We have implementations of this to fit JTA and
JDBC scenarios.  Additionally, it allows to indicate that the isolated work
should itself be transacted or not.  In the JDBC-transaction scenario
(which HHH-9993 deals with) transacted-isolated work is achieved by passing
in a separate Connection to use since that is the only way to achieve a new
transaction in JDBC (JDBC has no "suspend/resume" transaction
functionality).

HHH-9993 is again about this isolated, transacted scenario under the
JDBC-transaction handling.  Specifically for hibernate-infinispan call
backs there is no need to obtain the second Connection.  So HHH-9993 is
about reducing the overhead of this call by allowing it a way to say "I
need to do some isolated, transacted work but I do not need the Connection".

For this particular use case that is fine: hibernate-infinispan will never
access the Connection.  I do worry however about this general use-case.  My
concern is specifically that some use cases will attempt to call back into
the Session.  At the moment we do not "protect" against that.

I'd like to get some opinions on this.


[1] https://hibernate.atlassian.net/browse/HHH-9993

From sanne at hibernate.org  Mon Jan 25 12:41:06 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 25 Jan 2016 17:41:06 +0000
Subject: [hibernate-dev] HHH-8076 - CDI-capable entity listeners
In-Reply-To: <CAFdSV9s+fwrZ9Fn1k9nAQmGQv9-TGaJMK966RiHUdm-7bHnKCg@mail.gmail.com>
References: <CAFdSV9tD2jK9rZiY596m-UrVHPYNA3+kpd8Y3anUtOg9HtpdYg@mail.gmail.com>
	<CAFdSV9v6uWNZhvtTgv5GrSCmH1-bWR6Ljj=EbHF5xf0D1UKVaQ@mail.gmail.com>
	<CAFdSV9s+fwrZ9Fn1k9nAQmGQv9-TGaJMK966RiHUdm-7bHnKCg@mail.gmail.com>
Message-ID: <CAFm4XO0TTxcHnFhhiHePS7vwNSh-nR878cAwx5pvAnbeHBx0JA@mail.gmail.com>

I checked :
 - Hibernate OGM
 - Hibernate Search
 - Hibernate Validator
 - WildFly

And none are using the listeners you listed. In the case of WildFly, I
don't know of course about all the frameworks which are included in
there.

Sanne

On 22 January 2016 at 23:58, Steve Ebersole <steve at hibernate.org> wrote:
> Anyone remember the back-story
> on org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor#useAnnotationAnnotatedByListener?
>
> If I read it correctly, it is looking at annotations on the entity seeing
> if any of those annotations are in turn annotated with @EntityListeners.
>
> On Fri, Jan 22, 2016 at 3:38 PM Steve Ebersole <steve at hibernate.org> wrote:
>
>> If it matters, my plan is as follows...
>>
>> Currently JpaIntegrator is the central point for this processing.  The
>> general premise is that it builds a CallbackRegistry, a ListenerFactory
>> and a CallbackProcessor.  It then uses the CallbackProcessor and ListenerFactory
>> to populate the CallbackRegistry.  This part is the crux of the problem
>> with HHH-8076 as after this JpaIntegrator call it is expected that CallbackRegistry
>> be fully initialized (all Callbacks resolved and ready to go).
>>
>> So the plan is to instead invert these relationships to where we build a CallbackRegistry
>> that is aware of the ListenerFactory and CallbackProcessor (actually I
>> think CallbackProcessor can go away).  This is the point in the suggested
>> solution described for HHH-8076 where we'd check the BeanManager to see if
>> it is a BeanManagerExtension and decide whether to delay the
>> initialization.  If that plan causes trouble for anyone, please speak up
>> asap.  If not, I'll proceed.
>>
>> Thanks!
>>
>> On Fri, Jan 22, 2016 at 3:28 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> As part of the work on HHH-8076 for ORM 5.1 I am going to have to change
>>> up, in some fashion, some or all of the following internal/spi contracts :
>>>
>>> * org.hibernate.jpa.event.spi.jpa.Callback
>>> * org.hibernate.jpa.event.spi.jpa.CallbackRegistry
>>> * org.hibernate.jpa.event.spi.jpa.ListenerFactory
>>> * org.hibernate.jpa.event.internal.jpa.CallbackProcessor
>>>
>>> I need to know whether any integrations either use any of these or
>>> provide custom impls for any of them.
>>>
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Mon Jan 25 12:56:54 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jan 2016 17:56:54 +0000
Subject: [hibernate-dev] HHH-9548 - StoredProcedureQuery and
	parameter-specific hints
Message-ID: <CAFdSV9uLEhknBBtZSA8VTn-Lr6a=UpeBSNk5TBhrimVhHdX=8w@mail.gmail.com>

HHH-9548[1] handles the question of what to do with null/unset parameter
values in regards to calls to stored-procedures via
JPA's StoredProcedureQuery contract.

Do we just want to live with the overhead that comes from my last
comment[2]?  Another option I see would be an extension
to javax.persistence.Parameter to return from the
StoredProcedureQuery-defined access to parameter objects.

Any other thoughts?

[1] https://hibernate.atlassian.net/browse/HHH-9548
[2]
https://hibernate.atlassian.net/browse/HHH-9548?focusedCommentId=74853&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-74853

From steve at hibernate.org  Mon Jan 25 13:02:10 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jan 2016 18:02:10 +0000
Subject: [hibernate-dev] HHH-8076 - CDI-capable entity listeners
In-Reply-To: <CAFm4XO0TTxcHnFhhiHePS7vwNSh-nR878cAwx5pvAnbeHBx0JA@mail.gmail.com>
References: <CAFdSV9tD2jK9rZiY596m-UrVHPYNA3+kpd8Y3anUtOg9HtpdYg@mail.gmail.com>
	<CAFdSV9v6uWNZhvtTgv5GrSCmH1-bWR6Ljj=EbHF5xf0D1UKVaQ@mail.gmail.com>
	<CAFdSV9s+fwrZ9Fn1k9nAQmGQv9-TGaJMK966RiHUdm-7bHnKCg@mail.gmail.com>
	<CAFm4XO0TTxcHnFhhiHePS7vwNSh-nR878cAwx5pvAnbeHBx0JA@mail.gmail.com>
Message-ID: <CAFdSV9sbP-smxyq11Owcfbwq83HzrnOEWHgaL0tu+Qj3JufgOQ@mail.gmail.com>

I have been in constant discussion with Scott about this.  I developed
proposal after my discussions with him.

Ultimately we believe the solution is an extension to CDI.  I developed
this with that in my mind's eye.  Scott will be taking my work so far and
trying to finish it (do the WildFly piece) this afternoon.  After we are
all done we will suggest this as an extension to CDI proper.

On Mon, Jan 25, 2016 at 11:41 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> I checked :
>  - Hibernate OGM
>  - Hibernate Search
>  - Hibernate Validator
>  - WildFly
>
> And none are using the listeners you listed. In the case of WildFly, I
> don't know of course about all the frameworks which are included in
> there.
>
> Sanne
>
> On 22 January 2016 at 23:58, Steve Ebersole <steve at hibernate.org> wrote:
> > Anyone remember the back-story
> > on
> org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor#useAnnotationAnnotatedByListener?
> >
> > If I read it correctly, it is looking at annotations on the entity seeing
> > if any of those annotations are in turn annotated with @EntityListeners.
> >
> > On Fri, Jan 22, 2016 at 3:38 PM Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> If it matters, my plan is as follows...
> >>
> >> Currently JpaIntegrator is the central point for this processing.  The
> >> general premise is that it builds a CallbackRegistry, a ListenerFactory
> >> and a CallbackProcessor.  It then uses the CallbackProcessor and
> ListenerFactory
> >> to populate the CallbackRegistry.  This part is the crux of the problem
> >> with HHH-8076 as after this JpaIntegrator call it is expected that
> CallbackRegistry
> >> be fully initialized (all Callbacks resolved and ready to go).
> >>
> >> So the plan is to instead invert these relationships to where we build
> a CallbackRegistry
> >> that is aware of the ListenerFactory and CallbackProcessor (actually I
> >> think CallbackProcessor can go away).  This is the point in the
> suggested
> >> solution described for HHH-8076 where we'd check the BeanManager to see
> if
> >> it is a BeanManagerExtension and decide whether to delay the
> >> initialization.  If that plan causes trouble for anyone, please speak up
> >> asap.  If not, I'll proceed.
> >>
> >> Thanks!
> >>
> >> On Fri, Jan 22, 2016 at 3:28 PM Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>
> >>> As part of the work on HHH-8076 for ORM 5.1 I am going to have to
> change
> >>> up, in some fashion, some or all of the following internal/spi
> contracts :
> >>>
> >>> * org.hibernate.jpa.event.spi.jpa.Callback
> >>> * org.hibernate.jpa.event.spi.jpa.CallbackRegistry
> >>> * org.hibernate.jpa.event.spi.jpa.ListenerFactory
> >>> * org.hibernate.jpa.event.internal.jpa.CallbackProcessor
> >>>
> >>> I need to know whether any integrations either use any of these or
> >>> provide custom impls for any of them.
> >>>
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jan 25 13:02:45 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jan 2016 18:02:45 +0000
Subject: [hibernate-dev] 2LC docs
In-Reply-To: <CA+gWKMCAmS4Q=-cTxNn+a5EAjyMt5L2oq9HHAn1+TjKGms869A@mail.gmail.com>
References: <5698C041.8060904@redhat.com>
	<CAFdSV9tTX0yVF6kEimsm2LiRBv0StaxvoSnCkmwhvqKLyYVVrA@mail.gmail.com>
	<569F543B.7090304@redhat.com>
	<CA+gWKMAOXLRNNoPt9V7fEbJ3MF3x-DpwrMnpQ0icTWO1OEHmcw@mail.gmail.com>
	<CA+gWKMCkOZ9BoFcEpCtiYn3jGGOu1Zus_7bHq42pckp6=tr-ew@mail.gmail.com>
	<56A0FA9E.9020606@redhat.com> <56A22CB7.2060404@redhat.com>
	<CAFdSV9uv=Oc=Y9vdFL0sR3n3wfiTF6=sLm65YZ2LDdWksB069w@mail.gmail.com>
	<56A24AFA.7030902@redhat.com>
	<CAFdSV9tLsMq6Jb=+gO+DqqQy4927qQKkwyS5An6-8ivgMdgbvg@mail.gmail.com>
	<56A5FD84.20601@redhat.com>
	<CA+gWKMCostU3jJ=rQeU0cE7MLx1bkZagwC0c9KfL4TSF+gieuQ@mail.gmail.com>
	<56A60B31.5010200@redhat.com>
	<CA+gWKMCAmS4Q=-cTxNn+a5EAjyMt5L2oq9HHAn1+TjKGms869A@mail.gmail.com>
Message-ID: <CAFdSV9vwLKA=t7U4qFBFLaPz=_yVNJ=wHKwRuDf8cOnJJ=EQZQ@mail.gmail.com>

+1.  I think we need to generally understand a user guide and an
integration guide.  Very different audiences.

On Mon, Jan 25, 2016 at 6:22 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Thanks. Well, the User Guide must detail the API and focus on general
> usage.
> We don't want to scare users with internal details that are more useful in
> a Developer Guide or Integrator Guide.
> So we must find the right balance for what info we supply in the User
> Guide.
>
>
> Vlad
>
> On Mon, Jan 25, 2016 at 1:46 PM, Radim Vansa <rvansa at redhat.com> wrote:
>
>> I wish the docs were as descriptive as your blog - thanks Vlad! (so, I
>> should make that happen).
>>
>> So I (hopefully) finally understand what you mean by sync/async:
>> * sync implements only certain methods from the *RegionAccessStrategy and
>> the two-phase commit requires TM calling 2LC directly (either by
>> registering itself as XAResource or Synchronization)
>> * async implements all methods and does not need to interact with TM at
>> all.
>>
>> However, this is just an implementation detail which should not relate to
>> cache concurrency strategy, should it? CCS should define only the isolation
>> level achieved, and that is:
>> * nonstrict-read-write: read committed with short window for stale reads
>> during commit
>> * read-write: read committed
>> * transactional: serializable
>>
>> Radim
>>
>> On 01/25/2016 11:55 AM, Vlad Mihalcea wrote:
>>
>>> Hi,
>>>
>>> I have some sequence diagrams depicting the async/sync behavior if you
>>> are interested:
>>>
>>> For async: NONSTREICT_READ_WRITE and READ_WRITE:
>>>
>>>
>>> http://vladmihalcea.com/2015/05/18/how-does-hibernate-nonstrict_read_write-cacheconcurrencystrategy-work/
>>>
>>> http://vladmihalcea.com/2015/05/25/how-does-hibernate-read_write-cacheconcurrencystrategy-work/
>>>
>>> For sync: TRANSACTIONAL
>>>
>>>
>>> http://vladmihalcea.com/2015/06/01/how-does-hibernate-transactional-cacheconcurrencystrategy-work/
>>>
>>> Only the region strategy differs since it's not Ehcache, but everything
>>> else is from Hibernate API.
>>>
>>> Vlad
>>>
>>> On Mon, Jan 25, 2016 at 12:48 PM, Radim Vansa <rvansa at redhat.com
>>> <mailto:rvansa at redhat.com>> wrote:
>>>
>>>     On 01/22/2016 05:26 PM, Steve Ebersole wrote:
>>>     > On Fri, Jan 22, 2016 at 9:30 AM Radim Vansa <rvansa at redhat.com
>>>     <mailto:rvansa at redhat.com>
>>>     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>> wrote:
>>>     >
>>>     >     On 01/22/2016 03:11 PM, Steve Ebersole wrote:
>>>     >     > On Fri, Jan 22, 2016 at 7:21 AM Radim Vansa
>>>     <rvansa at redhat.com <mailto:rvansa at redhat.com>
>>>     >     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>
>>>     >     > <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>
>>>     <mailto:rvansa at redhat.com <mailto:rvansa at redhat.com>>>> wrote:
>>>     >     >
>>>     >     >     Why should the strategy 'never be used if serializable
>>>     >     transaction
>>>     >     >     isolation level is required'? What guarantees it
>>>     gives, and what
>>>     >     >     in ORM
>>>     >     >     core depends on this?  When I've asked the last time,
>>>     Steve said
>>>     >     >     that all modes but the
>>>     >     >
>>>     >     >     nonstrict one require that the 2LC is absolutely
>>>     transparent
>>>     >     >     (consistency-wise), so you always get the same answer
>>>     as if
>>>     >     you were
>>>     >     >     directly talking to DB.
>>>     >     >
>>>     >     >
>>>     >     > I would guess this is talking about "serializable
>>>     isolation" at the
>>>     >     > application layer.  Yes extended across both the
>>>     application and
>>>     >     > database.  In our original implementations we had no L2 cache
>>>     >     > providers that would support serializable isolation. Does
>>>     >     > hibernate-infinispan? If we ask for a certain entry from the
>>>     >     cache in
>>>     >     > T1, T2 adds that entry and commits, and then we ask for it
>>>     again
>>>     >     in T1
>>>     >     > do we still see it as "not existing"?  I'd highly doubt
>>>     it, but
>>>     >     if it
>>>     >     > does then lets make note of that.
>>>     >
>>>     >     No, without a transactional cache, it does not. Thanks for the
>>>     >     example.
>>>     >     But will the request get to 2LC, or will it be served
>>>     already from
>>>     >     Session cache?
>>>     >
>>>     >
>>>     > It won't work even with a transactional cache I believe. It
>>>     won't work
>>>     > with Infinispan e.g. I do not think. Hibernate does not keep
>>>     reference
>>>     > to "non-existing" entities.  That's the only way the Session could
>>>     > "serve" the fact that the first T1 lookup found nothing.  Again,
>>>     this
>>>     > gets right back to that idea of consistency. Without L2 caching, in
>>>     > this scenario with serializable isolation the database would
>>>     return me
>>>     > "no row" in both T1 SELECTs.
>>>
>>>     Infinispan keeps 'transactional context' for the current
>>>     transaction and
>>>     stores all reads there, even if this is a null read. However, as I've
>>>     checked the distribution code, it still does the remote lookup (which
>>>     escapes the transaction) and the value could get there even with
>>>     so-called repeatable reads. I'll check infinispan-dev why.
>>>
>>>     >
>>>     >     >  Does the ' you should ensure that the transaction is
>>>     completed when
>>>     >     >     `Session.close()` or `Session.disconnect()` is called'
>>>     still
>>>     >     hold, or
>>>     >     >     does the transactional rework in 5.0 somehow obsolete
>>>     this info?
>>>     >     >
>>>     >     >
>>>     >     > I cannot say why this is discussed in a chapter on caching.
>>>     >     > Session#disconnect is largely deprecated (its main use case
>>> is
>>>     >     handled
>>>     >     > much more transparently now).  IMO it's always a good idea
>>>     to make
>>>     >     > sure a transaction against a resource is completed prior
>>>     to closing
>>>     >     > that transaction. That's no different for a Hibernate Session
>>>     >     then it
>>>     >     > is for a JDBC Connection, etc.
>>>     >
>>>     >     Did you meant 'commit the transaction before closing the
>>>     session'? If
>>>     >     the Session.close() is called with tx open, will the
>>>     transaction be
>>>     >     committed? But any way, this should be really the same as
>>>     without 2LC.
>>>     >
>>>     >
>>>     > I meant to say " make sure a transaction against a resource is
>>>     > completed prior to closing that resource". Saying "complete the
>>>     > transaction" != "commit the transaction". Completion might be
>>> either
>>>     > commit or rollback.  But the idea is that it is in a definitive
>>>     state.
>>>     >
>>>     > Historically what a stranded transaction at the time of
>>>     Session#close
>>>     > meant depended on the JDBC driver.  Most drivers rollback back on a
>>>     > stranded transaction; Oracle has always been the notable
>>>     exception as
>>>     > they would commit a stranded transaction.  But regardless in
>>>     terms of
>>>     > Session locks etc in the cache that would strand the locks as
>>>     well iirc.
>>>     >
>>>     > In developing 5.0 and the new transaction handling I know we talked
>>>     > about making this more deterministic, specifically always handling
>>>     > this as if a rollback had been called.  But to be honest, that's
>>> not
>>>     > what I am seeing in the code. Andrea, do you remember?  If not, we
>>>     > should definitely add some tests for this to see what happens
>>>     atm and
>>>     > make sure its really what we want to have happen moving forward.
>>>     >
>>>     >
>>>     >     > Basically this passage is a poorly worded hint.  What it is
>>>     >     trying to
>>>     >     > convey is that for "asynchronous" cache access what drives
>>> the
>>>     >     > interactions with the Cache is the Hibernate transaction,
>>>     and in
>>>     >     these
>>>     >     > case the user should take extra care to make sure that the
>>>     >     transaction
>>>     >     > is handled properly. That still holds true.
>>>     >     >
>>>     >     > As a refresher, the idea of "synchronous" versus
>>>     "asynchronous" is
>>>     >     > simply cache access that is driven by JTA ("synchronous")
>>>     versus
>>>     >     those
>>>     >     > that are driven by local transactions ("asynchronous").
>>>     >
>>>     >
>>>     >     Eh, I probably don't get the exact meaning of 'driving the
>>>     access' :-/
>>>     >     And I can't find any reference to 'async' in user guide.
>>>     >
>>>     >
>>>     > I keep pointing y'all to
>>>     > org.hibernate.cache.spi.access.EntityRegionAccessStrategy,
>>>     > org.hibernate.cache.spi.access.CollectionRegionAccessStrategy,
>>>     etc as
>>>     > the best source for this information.  I spent a lot of time
>>>     >  documenting (javadoc) these contracts as I developed them.
>>>     >  sync/async is discussed there.  No need for it to be discussed
>>>     in the
>>>     > user guide IMO, its a concept for developers of cache
>>>     implementations
>>>     > to understand not users.
>>>
>>>     Okay, this sync/async. Sure, then it makes sense that it's not in
>>> user
>>>     guide. But pardon my confusion, that class documents which methods
>>> are
>>>     used by sync/async strategies, and what's the order of method
>>>     invocation, but I never got what is the idea behind the sync/async
>>>     strategy differentiation. As I've started messing with ORM only after
>>>     the 5.0 tx rework, I always considered the difference between JTA and
>>>     local transactions just an implementation detail orthogonal to 2LC.
>>>
>>>     Radim
>>>
>>>     --
>>>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>>>     JBoss Performance Team
>>>
>>>     _______________________________________________
>>>     hibernate-dev mailing list
>>>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>>
>>
>> --
>> Radim Vansa <rvansa at redhat.com>
>> JBoss Performance Team
>>
>>
>

From steve at hibernate.org  Mon Jan 25 13:21:16 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jan 2016 18:21:16 +0000
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFm4XO2VNfKJgmcbj-TK8eXj3sNfdw92H9Yj72kmnJ6MJerBuw@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
	<CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
	<CAFm4XO2VNfKJgmcbj-TK8eXj3sNfdw92H9Yj72kmnJ6MJerBuw@mail.gmail.com>
Message-ID: <CAFdSV9tQCHyoxL-MAEiqTR-a8O9OjiBN=UEdDBBptRa5qpbD+Q@mail.gmail.com>

Minor detail wrt method naming...

Actually performing a org.hibernate.MultiIdentifierLoadAccess is currently
achieved via a method named `#multiLoad`.  The name was chose because
originally I wanted this to live on IdentifierLoadAccess and so the `multi`
part was needed to distinguish it from the singular load form.

Now that this has been split off into a new contract, is maybe
MultiIdentifierLoadAccess#load
preferable over MultiIdentifierLoadAccess#multiLoad?

On Wed, Jan 20, 2016 at 3:46 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Steve,
> Hibernate Search doesn't customize the loaders: if any we want to make
> sure that whatever customization has been defined is being used by
> Search as well.
> Hibernate OGM does of course replace the default loaders; I'm not sure
> how nicely that interacts with the user wanting to override it.
>
> -- Sanne
>
> On 19 January 2016 at 22:30, Steve Ebersole <steve at hibernate.org> wrote:
> > Sanne, Gunnar any thoughts/input here?
> >
> >
> > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk at gmail.com>
> > wrote:
> >
> >> Hello, yes, you are absolutely right, the main concern here is that with
> >> new MultipleLoad API we got inconsistent behavior for loading using
> >> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
> >>
> >>
> >> What regarding my case, it is loading data from EAV model, with
> predefined
> >> scenarios.
> >>
> >>
> >> We have 3 tables:
> >>
> >>
> >> Objects[id ? pk, name, type_id, parent]
> >> Params[attr_id, value, object_id (fk to objects), show_order]
> >> References[ attr_id, reference, object_id( fk to objects), show_order]
> >>
> >>
> >> Also we have a data loading scenario configuration based on type_id,
> >> identifying set of params\references Entities and Object Entities
> >> referenced by References entity to be Eager load during loading Object
> >> Entities.
> >>
> >>
> >> We have more than 1k attributes and more than 100Gb of data in
> >> Object\Params\References entities
> >>
> >>
> >> So it is simple recursive loading task, as per me, the best place for it
> >> persister.load with optimized loader (at least without query hardparse
> on
> >> each multiloading, this could be done using custom Oracle\PostgreSQL
> >> datatype to pass array of ids as a bind variable in case of bulk load by
> >> Ids)
> >>
> >>
> >> PostgreSQL ex.:
> >> Select * from objects where id = any(?);
> >>
> >>
> >> If you could advise better solution to implement such scenario based on
> >> EAV Eager loading I will be very appreciated to you.
> >>
> >> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
> >>
> >>> Personally I think its a questions of semantics; to me a multi-id load
> >>> already implies/indicates a certain loading strategy (Loader).  You are
> >>> saying you'd like the ability to still decide a specific loading
> strategy
> >>> for multi-id loads.  I seriously doubt that is really what you want,
> but I
> >>> do understand the desire for consistency.  Maybe some others will
> chime in;
> >>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in
> terms
> >>> of integrating this with Search.
> >>>
> >>> Also, that was not the question I asked.  Specifically, what is it you
> >>> want to do that you cannot do given the current call chain?
> >>>
> >>>
> >>>
> >>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov <bulanovk at gmail.com
> >
> >>> wrote:
> >>>
> >>>> Hello Steve, as you asked moving our discussion about HHH-7572 in dev
> >>>> mail
> >>>> list.
> >>>>
> >>>>
> >>>>
> >>>> Regarding you question, in current architecture and implementation we
> >>>> have
> >>>> the following point to perform entity persistence customization.
> >>>>
> >>>> Annotation:
> >>>>
> >>>>
> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
> >>>> which allows us to specify our own implementation of
> >>>>
> >>>>
> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
> >>>> .
> >>>>
> >>>>
> >>>> One of its methods is:
> >>>>
> >>>>
> >>>>
> >>>> Object load(Serializable id,
> >>>>
> >>>>             Object optionalObject,
> >>>>
> >>>>             LockMode lockMode,
> >>>>
> >>>>             SessionImplementor session)
> >>>>
> >>>>      throws HibernateException
> >>>>
> >>>>
> >>>>
> >>>> Load an instance of the persistent class.
> >>>>
> >>>>
> >>>>
> >>>> and
> >>>>
> >>>>
> >>>>
> >>>> Object load(Serializable id,
> >>>>
> >>>>             Object optionalObject,
> >>>>
> >>>>             LockOptions lockOptions,
> >>>>
> >>>>             SessionImplementor session)
> >>>>
> >>>>      throws HibernateException
> >>>>
> >>>>
> >>>>
> >>>> Load an instance of the persistent class.
> >>>>
> >>>>
> >>>>
> >>>> These two methods allows to specify you own Loader implementation to
> load
> >>>> Entity by IDS,
> >>>>
> >>>> in mentioned issue this part of contract was ignored by changing call
> >>>> sequence on loading by multiple ids.
> >>>>
> >>>>
> >>>>
> >>>> By Single id;
> >>>>
> >>>>
> >>>>
> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
> >>>>
> >>>>
> >>>>
> >>>> By Multiple id:
> >>>>
> >>>>
> >>>>
> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
> >>>>
> >>>>
> >>>>
> >>>> So in new API for multiple load we lose at least 2 possible extension
> >>>> points: onLoadEvent, Persister.load (here we could customize loader -
> >>>> specify our own instead hardcoded one)
> >>>>
> >>>>
> >>>>
> >>>> From my point of view there should be the same approach to get
> entities
> >>>> by
> >>>> ID(independent multiple or single).
> >>>>
> >>>>
> >>>> So which one approach is correct and future-proof for Single id or
> >>>> Multiple
> >>>> Ids?
> >>>>
> >>>>
> >>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
> >>>> notifications at github.com> ???????:
> >>>>
> >>>> > Customize how? Loader still calls into the persister. Persisters and
> >>>> > Loaders have a back-and-forth synergy.
> >>>> >
> >>>> > Also please discuss this on the hibernate-dev mailing list so others
> >>>> can be
> >>>> > involved.
> >>>> >
> >>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
> >>>> > notifications at github.com>
> >>>> > wrote:
> >>>> >
> >>>> > > Hello Steve, could you be so kind to advice why we have different
> >>>> > behavior
> >>>> > > for loading by single id and multiple ids?
> >>>> > >
> >>>> > > In Case of single id, loading is going through
> >>>> > > session->IdentifierLoadAccess->event->persister->Loader
> >>>> > > In Case of multiple ids, loading is going through
> >>>> > > session->MultiIdentifierLoadAccess->Loader
> >>>> > >
> >>>> > > So in case of load by single id it is possible to cutomize
> loading of
> >>>> > > Entify using persister, but in new introduced API we lost this
> >>>> > posibility.
> >>>> > >
> >>>> > > ?
> >>>> > > Reply to this email directly or view it on GitHub
> >>>> > > <
> >>>> >
> >>>>
> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
> >>>> > >
> >>>> > > .
> >>>> > >
> >>>> >
> >>>> > ?
> >>>> > Reply to this email directly or view it on GitHub
> >>>> > <
> >>>>
> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
> >>>> >
> >>>> > .
> >>>> >
> >>>> _______________________________________________
> >>>> 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  Mon Jan 25 13:29:43 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 25 Jan 2016 18:29:43 +0000
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFdSV9tQCHyoxL-MAEiqTR-a8O9OjiBN=UEdDBBptRa5qpbD+Q@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
	<CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
	<CAFm4XO2VNfKJgmcbj-TK8eXj3sNfdw92H9Yj72kmnJ6MJerBuw@mail.gmail.com>
	<CAFdSV9tQCHyoxL-MAEiqTR-a8O9OjiBN=UEdDBBptRa5qpbD+Q@mail.gmail.com>
Message-ID: <CAFm4XO3FEO7XJm5nnL2JNfwfifRUuGY5Ozt7Sdq_htCGFkRu9A@mail.gmail.com>

I like "multiLoad". Makes the intent more explicit, as the method
could be abused by passing lists of singleton identifiers.

On 25 January 2016 at 18:21, Steve Ebersole <steve at hibernate.org> wrote:
> Minor detail wrt method naming...
>
> Actually performing a org.hibernate.MultiIdentifierLoadAccess is currently
> achieved via a method named `#multiLoad`.  The name was chose because
> originally I wanted this to live on IdentifierLoadAccess and so the `multi`
> part was needed to distinguish it from the singular load form.
>
> Now that this has been split off into a new contract, is maybe
> MultiIdentifierLoadAccess#load preferable over
> MultiIdentifierLoadAccess#multiLoad?
>
> On Wed, Jan 20, 2016 at 3:46 AM Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Steve,
>> Hibernate Search doesn't customize the loaders: if any we want to make
>> sure that whatever customization has been defined is being used by
>> Search as well.
>> Hibernate OGM does of course replace the default loaders; I'm not sure
>> how nicely that interacts with the user wanting to override it.
>>
>> -- Sanne
>>
>> On 19 January 2016 at 22:30, Steve Ebersole <steve at hibernate.org> wrote:
>> > Sanne, Gunnar any thoughts/input here?
>> >
>> >
>> > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <bulanovk at gmail.com>
>> > wrote:
>> >
>> >> Hello, yes, you are absolutely right, the main concern here is that
>> >> with
>> >> new MultipleLoad API we got inconsistent behavior for loading using
>> >> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
>> >>
>> >>
>> >> What regarding my case, it is loading data from EAV model, with
>> >> predefined
>> >> scenarios.
>> >>
>> >>
>> >> We have 3 tables:
>> >>
>> >>
>> >> Objects[id ? pk, name, type_id, parent]
>> >> Params[attr_id, value, object_id (fk to objects), show_order]
>> >> References[ attr_id, reference, object_id( fk to objects), show_order]
>> >>
>> >>
>> >> Also we have a data loading scenario configuration based on type_id,
>> >> identifying set of params\references Entities and Object Entities
>> >> referenced by References entity to be Eager load during loading Object
>> >> Entities.
>> >>
>> >>
>> >> We have more than 1k attributes and more than 100Gb of data in
>> >> Object\Params\References entities
>> >>
>> >>
>> >> So it is simple recursive loading task, as per me, the best place for
>> >> it
>> >> persister.load with optimized loader (at least without query hardparse
>> >> on
>> >> each multiloading, this could be done using custom Oracle\PostgreSQL
>> >> datatype to pass array of ids as a bind variable in case of bulk load
>> >> by
>> >> Ids)
>> >>
>> >>
>> >> PostgreSQL ex.:
>> >> Select * from objects where id = any(?);
>> >>
>> >>
>> >> If you could advise better solution to implement such scenario based on
>> >> EAV Eager loading I will be very appreciated to you.
>> >>
>> >> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
>> >>
>> >>> Personally I think its a questions of semantics; to me a multi-id load
>> >>> already implies/indicates a certain loading strategy (Loader).  You
>> >>> are
>> >>> saying you'd like the ability to still decide a specific loading
>> >>> strategy
>> >>> for multi-id loads.  I seriously doubt that is really what you want,
>> >>> but I
>> >>> do understand the desire for consistency.  Maybe some others will
>> >>> chime in;
>> >>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in
>> >>> terms
>> >>> of integrating this with Search.
>> >>>
>> >>> Also, that was not the question I asked.  Specifically, what is it you
>> >>> want to do that you cannot do given the current call chain?
>> >>>
>> >>>
>> >>>
>> >>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov
>> >>> <bulanovk at gmail.com>
>> >>> wrote:
>> >>>
>> >>>> Hello Steve, as you asked moving our discussion about HHH-7572 in dev
>> >>>> mail
>> >>>> list.
>> >>>>
>> >>>>
>> >>>>
>> >>>> Regarding you question, in current architecture and implementation we
>> >>>> have
>> >>>> the following point to perform entity persistence customization.
>> >>>>
>> >>>> Annotation:
>> >>>>
>> >>>>
>> >>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>> >>>> which allows us to specify our own implementation of
>> >>>>
>> >>>>
>> >>>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>> >>>> .
>> >>>>
>> >>>>
>> >>>> One of its methods is:
>> >>>>
>> >>>>
>> >>>>
>> >>>> Object load(Serializable id,
>> >>>>
>> >>>>             Object optionalObject,
>> >>>>
>> >>>>             LockMode lockMode,
>> >>>>
>> >>>>             SessionImplementor session)
>> >>>>
>> >>>>      throws HibernateException
>> >>>>
>> >>>>
>> >>>>
>> >>>> Load an instance of the persistent class.
>> >>>>
>> >>>>
>> >>>>
>> >>>> and
>> >>>>
>> >>>>
>> >>>>
>> >>>> Object load(Serializable id,
>> >>>>
>> >>>>             Object optionalObject,
>> >>>>
>> >>>>             LockOptions lockOptions,
>> >>>>
>> >>>>             SessionImplementor session)
>> >>>>
>> >>>>      throws HibernateException
>> >>>>
>> >>>>
>> >>>>
>> >>>> Load an instance of the persistent class.
>> >>>>
>> >>>>
>> >>>>
>> >>>> These two methods allows to specify you own Loader implementation to
>> >>>> load
>> >>>> Entity by IDS,
>> >>>>
>> >>>> in mentioned issue this part of contract was ignored by changing call
>> >>>> sequence on loading by multiple ids.
>> >>>>
>> >>>>
>> >>>>
>> >>>> By Single id;
>> >>>>
>> >>>>
>> >>>>
>> >>>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>> >>>>
>> >>>>
>> >>>>
>> >>>> By Multiple id:
>> >>>>
>> >>>>
>> >>>>
>> >>>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>> >>>>
>> >>>>
>> >>>>
>> >>>> So in new API for multiple load we lose at least 2 possible extension
>> >>>> points: onLoadEvent, Persister.load (here we could customize loader -
>> >>>> specify our own instead hardcoded one)
>> >>>>
>> >>>>
>> >>>>
>> >>>> From my point of view there should be the same approach to get
>> >>>> entities
>> >>>> by
>> >>>> ID(independent multiple or single).
>> >>>>
>> >>>>
>> >>>> So which one approach is correct and future-proof for Single id or
>> >>>> Multiple
>> >>>> Ids?
>> >>>>
>> >>>>
>> >>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
>> >>>> notifications at github.com> ???????:
>> >>>>
>> >>>> > Customize how? Loader still calls into the persister. Persisters
>> >>>> > and
>> >>>> > Loaders have a back-and-forth synergy.
>> >>>> >
>> >>>> > Also please discuss this on the hibernate-dev mailing list so
>> >>>> > others
>> >>>> can be
>> >>>> > involved.
>> >>>> >
>> >>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>> >>>> > notifications at github.com>
>> >>>> > wrote:
>> >>>> >
>> >>>> > > Hello Steve, could you be so kind to advice why we have different
>> >>>> > behavior
>> >>>> > > for loading by single id and multiple ids?
>> >>>> > >
>> >>>> > > In Case of single id, loading is going through
>> >>>> > > session->IdentifierLoadAccess->event->persister->Loader
>> >>>> > > In Case of multiple ids, loading is going through
>> >>>> > > session->MultiIdentifierLoadAccess->Loader
>> >>>> > >
>> >>>> > > So in case of load by single id it is possible to cutomize
>> >>>> > > loading of
>> >>>> > > Entify using persister, but in new introduced API we lost this
>> >>>> > posibility.
>> >>>> > >
>> >>>> > > ?
>> >>>> > > Reply to this email directly or view it on GitHub
>> >>>> > > <
>> >>>> >
>> >>>>
>> >>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>> >>>> > >
>> >>>> > > .
>> >>>> > >
>> >>>> >
>> >>>> > ?
>> >>>> > Reply to this email directly or view it on GitHub
>> >>>> > <
>> >>>>
>> >>>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>> >>>> >
>> >>>> > .
>> >>>> >
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> hibernate-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>
>> >>>
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev


From dreborier at gmail.com  Mon Jan 25 13:41:29 2016
From: dreborier at gmail.com (andrea boriero)
Date: Mon, 25 Jan 2016 18:41:29 +0000
Subject: [hibernate-dev] HHH-9548 - StoredProcedureQuery and
 parameter-specific hints
In-Reply-To: <CAFdSV9uLEhknBBtZSA8VTn-Lr6a=UpeBSNk5TBhrimVhHdX=8w@mail.gmail.com>
References: <CAFdSV9uLEhknBBtZSA8VTn-Lr6a=UpeBSNk5TBhrimVhHdX=8w@mail.gmail.com>
Message-ID: <CAL00eSQzJEJQpzvuRQKW2_OEgoiMcmmKU1m+YzwK20Nb1cVdzQ@mail.gmail.com>

do you mean to extend javax.persistence.Parameter with a sort
of enablePassingNulls() method?

On 25 January 2016 at 17:56, Steve Ebersole <steve at hibernate.org> wrote:

> HHH-9548[1] handles the question of what to do with null/unset parameter
> values in regards to calls to stored-procedures via
> JPA's StoredProcedureQuery contract.
>
> Do we just want to live with the overhead that comes from my last
> comment[2]?  Another option I see would be an extension
> to javax.persistence.Parameter to return from the
> StoredProcedureQuery-defined access to parameter objects.
>
> Any other thoughts?
>
> [1] https://hibernate.atlassian.net/browse/HHH-9548
> [2]
>
> https://hibernate.atlassian.net/browse/HHH-9548?focusedCommentId=74853&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-74853
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon Jan 25 13:50:31 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jan 2016 18:50:31 +0000
Subject: [hibernate-dev] HHH-9548 - StoredProcedureQuery and
 parameter-specific hints
In-Reply-To: <CAL00eSQzJEJQpzvuRQKW2_OEgoiMcmmKU1m+YzwK20Nb1cVdzQ@mail.gmail.com>
References: <CAFdSV9uLEhknBBtZSA8VTn-Lr6a=UpeBSNk5TBhrimVhHdX=8w@mail.gmail.com>
	<CAL00eSQzJEJQpzvuRQKW2_OEgoiMcmmKU1m+YzwK20Nb1cVdzQ@mail.gmail.com>
Message-ID: <CAFdSV9udJ=ixiTubyFaHZQkBE4S4XM+RfUsmsDy4QJWnsHgMXQ@mail.gmail.com>

Right

On Mon, Jan 25, 2016 at 12:41 PM andrea boriero <dreborier at gmail.com> wrote:

> do you mean to extend javax.persistence.Parameter with a sort
> of enablePassingNulls() method?
>
> On 25 January 2016 at 17:56, Steve Ebersole <steve at hibernate.org> wrote:
>
>> HHH-9548[1] handles the question of what to do with null/unset parameter
>> values in regards to calls to stored-procedures via
>> JPA's StoredProcedureQuery contract.
>>
>> Do we just want to live with the overhead that comes from my last
>> comment[2]?  Another option I see would be an extension
>> to javax.persistence.Parameter to return from the
>> StoredProcedureQuery-defined access to parameter objects.
>>
>> Any other thoughts?
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-9548
>> [2]
>>
>> https://hibernate.atlassian.net/browse/HHH-9548?focusedCommentId=74853&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-74853
>>
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From dreborier at gmail.com  Mon Jan 25 13:52:08 2016
From: dreborier at gmail.com (andrea boriero)
Date: Mon, 25 Jan 2016 18:52:08 +0000
Subject: [hibernate-dev] HHH-9548 - StoredProcedureQuery and
 parameter-specific hints
In-Reply-To: <CAFdSV9udJ=ixiTubyFaHZQkBE4S4XM+RfUsmsDy4QJWnsHgMXQ@mail.gmail.com>
References: <CAFdSV9uLEhknBBtZSA8VTn-Lr6a=UpeBSNk5TBhrimVhHdX=8w@mail.gmail.com>
	<CAL00eSQzJEJQpzvuRQKW2_OEgoiMcmmKU1m+YzwK20Nb1cVdzQ@mail.gmail.com>
	<CAFdSV9udJ=ixiTubyFaHZQkBE4S4XM+RfUsmsDy4QJWnsHgMXQ@mail.gmail.com>
Message-ID: <CAL00eSRUSbT5Zh5k=3UoRaPgVQU_4U66qFs4C7r67p0avFi4Aw@mail.gmail.com>

I like it

On 25 January 2016 at 18:50, Steve Ebersole <steve at hibernate.org> wrote:

> Right
>
> On Mon, Jan 25, 2016 at 12:41 PM andrea boriero <dreborier at gmail.com>
> wrote:
>
>> do you mean to extend javax.persistence.Parameter with a sort
>> of enablePassingNulls() method?
>>
>> On 25 January 2016 at 17:56, Steve Ebersole <steve at hibernate.org> wrote:
>>
>>> HHH-9548[1] handles the question of what to do with null/unset parameter
>>> values in regards to calls to stored-procedures via
>>> JPA's StoredProcedureQuery contract.
>>>
>>> Do we just want to live with the overhead that comes from my last
>>> comment[2]?  Another option I see would be an extension
>>> to javax.persistence.Parameter to return from the
>>> StoredProcedureQuery-defined access to parameter objects.
>>>
>>> Any other thoughts?
>>>
>>> [1] https://hibernate.atlassian.net/browse/HHH-9548
>>> [2]
>>>
>>> https://hibernate.atlassian.net/browse/HHH-9548?focusedCommentId=74853&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-74853
>>>
>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>

From steve at hibernate.org  Mon Jan 25 14:09:58 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jan 2016 19:09:58 +0000
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFm4XO3FEO7XJm5nnL2JNfwfifRUuGY5Ozt7Sdq_htCGFkRu9A@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
	<CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
	<CAFm4XO2VNfKJgmcbj-TK8eXj3sNfdw92H9Yj72kmnJ6MJerBuw@mail.gmail.com>
	<CAFdSV9tQCHyoxL-MAEiqTR-a8O9OjiBN=UEdDBBptRa5qpbD+Q@mail.gmail.com>
	<CAFm4XO3FEO7XJm5nnL2JNfwfifRUuGY5Ozt7Sdq_htCGFkRu9A@mail.gmail.com>
Message-ID: <CAFdSV9tG=380Ff1Ys0gjanaV5o3w7aiTmtPJnOHtXEFtFWJGZw@mail.gmail.com>

I am about to push all this upstream.  It now includes a hook through
EntityPersister via a newly added method and "parameter object":

List multiLoad(Serializable[] ids, SessionImplementor session,
MultiLoadOptions loadOptions);

MultiLoadOptions encapsulates the information configured
on MultiIdentifierLoadAccess.

At this point, I am calling this work done.

On Mon, Jan 25, 2016 at 12:30 PM Sanne Grinovero <sanne at hibernate.org>
wrote:

> I like "multiLoad". Makes the intent more explicit, as the method
> could be abused by passing lists of singleton identifiers.
>
> On 25 January 2016 at 18:21, Steve Ebersole <steve at hibernate.org> wrote:
> > Minor detail wrt method naming...
> >
> > Actually performing a org.hibernate.MultiIdentifierLoadAccess is
> currently
> > achieved via a method named `#multiLoad`.  The name was chose because
> > originally I wanted this to live on IdentifierLoadAccess and so the
> `multi`
> > part was needed to distinguish it from the singular load form.
> >
> > Now that this has been split off into a new contract, is maybe
> > MultiIdentifierLoadAccess#load preferable over
> > MultiIdentifierLoadAccess#multiLoad?
> >
> > On Wed, Jan 20, 2016 at 3:46 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> Hi Steve,
> >> Hibernate Search doesn't customize the loaders: if any we want to make
> >> sure that whatever customization has been defined is being used by
> >> Search as well.
> >> Hibernate OGM does of course replace the default loaders; I'm not sure
> >> how nicely that interacts with the user wanting to override it.
> >>
> >> -- Sanne
> >>
> >> On 19 January 2016 at 22:30, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> > Sanne, Gunnar any thoughts/input here?
> >> >
> >> >
> >> > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <
> bulanovk at gmail.com>
> >> > wrote:
> >> >
> >> >> Hello, yes, you are absolutely right, the main concern here is that
> >> >> with
> >> >> new MultipleLoad API we got inconsistent behavior for loading using
> >> >> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
> >> >>
> >> >>
> >> >> What regarding my case, it is loading data from EAV model, with
> >> >> predefined
> >> >> scenarios.
> >> >>
> >> >>
> >> >> We have 3 tables:
> >> >>
> >> >>
> >> >> Objects[id ? pk, name, type_id, parent]
> >> >> Params[attr_id, value, object_id (fk to objects), show_order]
> >> >> References[ attr_id, reference, object_id( fk to objects),
> show_order]
> >> >>
> >> >>
> >> >> Also we have a data loading scenario configuration based on type_id,
> >> >> identifying set of params\references Entities and Object Entities
> >> >> referenced by References entity to be Eager load during loading
> Object
> >> >> Entities.
> >> >>
> >> >>
> >> >> We have more than 1k attributes and more than 100Gb of data in
> >> >> Object\Params\References entities
> >> >>
> >> >>
> >> >> So it is simple recursive loading task, as per me, the best place for
> >> >> it
> >> >> persister.load with optimized loader (at least without query
> hardparse
> >> >> on
> >> >> each multiloading, this could be done using custom Oracle\PostgreSQL
> >> >> datatype to pass array of ids as a bind variable in case of bulk load
> >> >> by
> >> >> Ids)
> >> >>
> >> >>
> >> >> PostgreSQL ex.:
> >> >> Select * from objects where id = any(?);
> >> >>
> >> >>
> >> >> If you could advise better solution to implement such scenario based
> on
> >> >> EAV Eager loading I will be very appreciated to you.
> >> >>
> >> >> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
> >> >>
> >> >>> Personally I think its a questions of semantics; to me a multi-id
> load
> >> >>> already implies/indicates a certain loading strategy (Loader).  You
> >> >>> are
> >> >>> saying you'd like the ability to still decide a specific loading
> >> >>> strategy
> >> >>> for multi-id loads.  I seriously doubt that is really what you want,
> >> >>> but I
> >> >>> do understand the desire for consistency.  Maybe some others will
> >> >>> chime in;
> >> >>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in
> >> >>> terms
> >> >>> of integrating this with Search.
> >> >>>
> >> >>> Also, that was not the question I asked.  Specifically, what is it
> you
> >> >>> want to do that you cannot do given the current call chain?
> >> >>>
> >> >>>
> >> >>>
> >> >>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov
> >> >>> <bulanovk at gmail.com>
> >> >>> wrote:
> >> >>>
> >> >>>> Hello Steve, as you asked moving our discussion about HHH-7572 in
> dev
> >> >>>> mail
> >> >>>> list.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> Regarding you question, in current architecture and implementation
> we
> >> >>>> have
> >> >>>> the following point to perform entity persistence customization.
> >> >>>>
> >> >>>> Annotation:
> >> >>>>
> >> >>>>
> >> >>>>
> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
> >> >>>> which allows us to specify our own implementation of
> >> >>>>
> >> >>>>
> >> >>>>
> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
> >> >>>> .
> >> >>>>
> >> >>>>
> >> >>>> One of its methods is:
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> Object load(Serializable id,
> >> >>>>
> >> >>>>             Object optionalObject,
> >> >>>>
> >> >>>>             LockMode lockMode,
> >> >>>>
> >> >>>>             SessionImplementor session)
> >> >>>>
> >> >>>>      throws HibernateException
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> Load an instance of the persistent class.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> and
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> Object load(Serializable id,
> >> >>>>
> >> >>>>             Object optionalObject,
> >> >>>>
> >> >>>>             LockOptions lockOptions,
> >> >>>>
> >> >>>>             SessionImplementor session)
> >> >>>>
> >> >>>>      throws HibernateException
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> Load an instance of the persistent class.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> These two methods allows to specify you own Loader implementation
> to
> >> >>>> load
> >> >>>> Entity by IDS,
> >> >>>>
> >> >>>> in mentioned issue this part of contract was ignored by changing
> call
> >> >>>> sequence on loading by multiple ids.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> By Single id;
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> By Multiple id:
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> So in new API for multiple load we lose at least 2 possible
> extension
> >> >>>> points: onLoadEvent, Persister.load (here we could customize
> loader -
> >> >>>> specify our own instead hardcoded one)
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> From my point of view there should be the same approach to get
> >> >>>> entities
> >> >>>> by
> >> >>>> ID(independent multiple or single).
> >> >>>>
> >> >>>>
> >> >>>> So which one approach is correct and future-proof for Single id or
> >> >>>> Multiple
> >> >>>> Ids?
> >> >>>>
> >> >>>>
> >> >>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
> >> >>>> notifications at github.com> ???????:
> >> >>>>
> >> >>>> > Customize how? Loader still calls into the persister. Persisters
> >> >>>> > and
> >> >>>> > Loaders have a back-and-forth synergy.
> >> >>>> >
> >> >>>> > Also please discuss this on the hibernate-dev mailing list so
> >> >>>> > others
> >> >>>> can be
> >> >>>> > involved.
> >> >>>> >
> >> >>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
> >> >>>> > notifications at github.com>
> >> >>>> > wrote:
> >> >>>> >
> >> >>>> > > Hello Steve, could you be so kind to advice why we have
> different
> >> >>>> > behavior
> >> >>>> > > for loading by single id and multiple ids?
> >> >>>> > >
> >> >>>> > > In Case of single id, loading is going through
> >> >>>> > > session->IdentifierLoadAccess->event->persister->Loader
> >> >>>> > > In Case of multiple ids, loading is going through
> >> >>>> > > session->MultiIdentifierLoadAccess->Loader
> >> >>>> > >
> >> >>>> > > So in case of load by single id it is possible to cutomize
> >> >>>> > > loading of
> >> >>>> > > Entify using persister, but in new introduced API we lost this
> >> >>>> > posibility.
> >> >>>> > >
> >> >>>> > > ?
> >> >>>> > > Reply to this email directly or view it on GitHub
> >> >>>> > > <
> >> >>>> >
> >> >>>>
> >> >>>>
> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
> >> >>>> > >
> >> >>>> > > .
> >> >>>> > >
> >> >>>> >
> >> >>>> > ?
> >> >>>> > Reply to this email directly or view it on GitHub
> >> >>>> > <
> >> >>>>
> >> >>>>
> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
> >> >>>> >
> >> >>>> > .
> >> >>>> >
> >> >>>> _______________________________________________
> >> >>>> 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  Mon Jan 25 14:22:23 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 25 Jan 2016 19:22:23 +0000
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFdSV9tG=380Ff1Ys0gjanaV5o3w7aiTmtPJnOHtXEFtFWJGZw@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
	<CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
	<CAFm4XO2VNfKJgmcbj-TK8eXj3sNfdw92H9Yj72kmnJ6MJerBuw@mail.gmail.com>
	<CAFdSV9tQCHyoxL-MAEiqTR-a8O9OjiBN=UEdDBBptRa5qpbD+Q@mail.gmail.com>
	<CAFm4XO3FEO7XJm5nnL2JNfwfifRUuGY5Ozt7Sdq_htCGFkRu9A@mail.gmail.com>
	<CAFdSV9tG=380Ff1Ys0gjanaV5o3w7aiTmtPJnOHtXEFtFWJGZw@mail.gmail.com>
Message-ID: <CAFm4XO2aPc+qs205FT+kcO42s8pbZyULXT9B69Og3GsQFnG75Q@mail.gmail.com>

Looks good! Time for us to put it to good use..
Thanks

On Mon, 25 Jan 2016 19:10 Steve Ebersole <steve at hibernate.org> wrote:

> I am about to push all this upstream.  It now includes a hook through
> EntityPersister via a newly added method and "parameter object":
>
> List multiLoad(Serializable[] ids, SessionImplementor session,
> MultiLoadOptions loadOptions);
>
> MultiLoadOptions encapsulates the information configured
> on MultiIdentifierLoadAccess.
>
> At this point, I am calling this work done.
>
> On Mon, Jan 25, 2016 at 12:30 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> I like "multiLoad". Makes the intent more explicit, as the method
>> could be abused by passing lists of singleton identifiers.
>>
>> On 25 January 2016 at 18:21, Steve Ebersole <steve at hibernate.org> wrote:
>> > Minor detail wrt method naming...
>> >
>> > Actually performing a org.hibernate.MultiIdentifierLoadAccess is
>> currently
>> > achieved via a method named `#multiLoad`.  The name was chose because
>> > originally I wanted this to live on IdentifierLoadAccess and so the
>> `multi`
>> > part was needed to distinguish it from the singular load form.
>> >
>> > Now that this has been split off into a new contract, is maybe
>> > MultiIdentifierLoadAccess#load preferable over
>> > MultiIdentifierLoadAccess#multiLoad?
>> >
>> > On Wed, Jan 20, 2016 at 3:46 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> >>
>> >> Hi Steve,
>> >> Hibernate Search doesn't customize the loaders: if any we want to make
>> >> sure that whatever customization has been defined is being used by
>> >> Search as well.
>> >> Hibernate OGM does of course replace the default loaders; I'm not sure
>> >> how nicely that interacts with the user wanting to override it.
>> >>
>> >> -- Sanne
>> >>
>> >> On 19 January 2016 at 22:30, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >> > Sanne, Gunnar any thoughts/input here?
>> >> >
>> >> >
>> >> > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <
>> bulanovk at gmail.com>
>> >> > wrote:
>> >> >
>> >> >> Hello, yes, you are absolutely right, the main concern here is that
>> >> >> with
>> >> >> new MultipleLoad API we got inconsistent behavior for loading using
>> >> >> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
>> >> >>
>> >> >>
>> >> >> What regarding my case, it is loading data from EAV model, with
>> >> >> predefined
>> >> >> scenarios.
>> >> >>
>> >> >>
>> >> >> We have 3 tables:
>> >> >>
>> >> >>
>> >> >> Objects[id ? pk, name, type_id, parent]
>> >> >> Params[attr_id, value, object_id (fk to objects), show_order]
>> >> >> References[ attr_id, reference, object_id( fk to objects),
>> show_order]
>> >> >>
>> >> >>
>> >> >> Also we have a data loading scenario configuration based on type_id,
>> >> >> identifying set of params\references Entities and Object Entities
>> >> >> referenced by References entity to be Eager load during loading
>> Object
>> >> >> Entities.
>> >> >>
>> >> >>
>> >> >> We have more than 1k attributes and more than 100Gb of data in
>> >> >> Object\Params\References entities
>> >> >>
>> >> >>
>> >> >> So it is simple recursive loading task, as per me, the best place
>> for
>> >> >> it
>> >> >> persister.load with optimized loader (at least without query
>> hardparse
>> >> >> on
>> >> >> each multiloading, this could be done using custom Oracle\PostgreSQL
>> >> >> datatype to pass array of ids as a bind variable in case of bulk
>> load
>> >> >> by
>> >> >> Ids)
>> >> >>
>> >> >>
>> >> >> PostgreSQL ex.:
>> >> >> Select * from objects where id = any(?);
>> >> >>
>> >> >>
>> >> >> If you could advise better solution to implement such scenario
>> based on
>> >> >> EAV Eager loading I will be very appreciated to you.
>> >> >>
>> >> >> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
>> >> >>
>> >> >>> Personally I think its a questions of semantics; to me a multi-id
>> load
>> >> >>> already implies/indicates a certain loading strategy (Loader).  You
>> >> >>> are
>> >> >>> saying you'd like the ability to still decide a specific loading
>> >> >>> strategy
>> >> >>> for multi-id loads.  I seriously doubt that is really what you
>> want,
>> >> >>> but I
>> >> >>> do understand the desire for consistency.  Maybe some others will
>> >> >>> chime in;
>> >> >>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in
>> >> >>> terms
>> >> >>> of integrating this with Search.
>> >> >>>
>> >> >>> Also, that was not the question I asked.  Specifically, what is it
>> you
>> >> >>> want to do that you cannot do given the current call chain?
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov
>> >> >>> <bulanovk at gmail.com>
>> >> >>> wrote:
>> >> >>>
>> >> >>>> Hello Steve, as you asked moving our discussion about HHH-7572 in
>> dev
>> >> >>>> mail
>> >> >>>> list.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Regarding you question, in current architecture and
>> implementation we
>> >> >>>> have
>> >> >>>> the following point to perform entity persistence customization.
>> >> >>>>
>> >> >>>> Annotation:
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>> >> >>>> which allows us to specify our own implementation of
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>> >> >>>> .
>> >> >>>>
>> >> >>>>
>> >> >>>> One of its methods is:
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Object load(Serializable id,
>> >> >>>>
>> >> >>>>             Object optionalObject,
>> >> >>>>
>> >> >>>>             LockMode lockMode,
>> >> >>>>
>> >> >>>>             SessionImplementor session)
>> >> >>>>
>> >> >>>>      throws HibernateException
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Load an instance of the persistent class.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> and
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Object load(Serializable id,
>> >> >>>>
>> >> >>>>             Object optionalObject,
>> >> >>>>
>> >> >>>>             LockOptions lockOptions,
>> >> >>>>
>> >> >>>>             SessionImplementor session)
>> >> >>>>
>> >> >>>>      throws HibernateException
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Load an instance of the persistent class.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> These two methods allows to specify you own Loader implementation
>> to
>> >> >>>> load
>> >> >>>> Entity by IDS,
>> >> >>>>
>> >> >>>> in mentioned issue this part of contract was ignored by changing
>> call
>> >> >>>> sequence on loading by multiple ids.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> By Single id;
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> By Multiple id:
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> So in new API for multiple load we lose at least 2 possible
>> extension
>> >> >>>> points: onLoadEvent, Persister.load (here we could customize
>> loader -
>> >> >>>> specify our own instead hardcoded one)
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> From my point of view there should be the same approach to get
>> >> >>>> entities
>> >> >>>> by
>> >> >>>> ID(independent multiple or single).
>> >> >>>>
>> >> >>>>
>> >> >>>> So which one approach is correct and future-proof for Single id or
>> >> >>>> Multiple
>> >> >>>> Ids?
>> >> >>>>
>> >> >>>>
>> >> >>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
>> >> >>>> notifications at github.com> ???????:
>> >> >>>>
>> >> >>>> > Customize how? Loader still calls into the persister. Persisters
>> >> >>>> > and
>> >> >>>> > Loaders have a back-and-forth synergy.
>> >> >>>> >
>> >> >>>> > Also please discuss this on the hibernate-dev mailing list so
>> >> >>>> > others
>> >> >>>> can be
>> >> >>>> > involved.
>> >> >>>> >
>> >> >>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>> >> >>>> > notifications at github.com>
>> >> >>>> > wrote:
>> >> >>>> >
>> >> >>>> > > Hello Steve, could you be so kind to advice why we have
>> different
>> >> >>>> > behavior
>> >> >>>> > > for loading by single id and multiple ids?
>> >> >>>> > >
>> >> >>>> > > In Case of single id, loading is going through
>> >> >>>> > > session->IdentifierLoadAccess->event->persister->Loader
>> >> >>>> > > In Case of multiple ids, loading is going through
>> >> >>>> > > session->MultiIdentifierLoadAccess->Loader
>> >> >>>> > >
>> >> >>>> > > So in case of load by single id it is possible to cutomize
>> >> >>>> > > loading of
>> >> >>>> > > Entify using persister, but in new introduced API we lost this
>> >> >>>> > posibility.
>> >> >>>> > >
>> >> >>>> > > ?
>> >> >>>> > > Reply to this email directly or view it on GitHub
>> >> >>>> > > <
>> >> >>>> >
>> >> >>>>
>> >> >>>>
>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>> >> >>>> > >
>> >> >>>> > > .
>> >> >>>> > >
>> >> >>>> >
>> >> >>>> > ?
>> >> >>>> > Reply to this email directly or view it on GitHub
>> >> >>>> > <
>> >> >>>>
>> >> >>>>
>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>> >> >>>> >
>> >> >>>> > .
>> >> >>>> >
>> >> >>>> _______________________________________________
>> >> >>>> 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 Jan 25 14:28:01 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 25 Jan 2016 19:28:01 +0000
Subject: [hibernate-dev] HHH-8076 - CDI-capable entity listeners
In-Reply-To: <CAFdSV9sbP-smxyq11Owcfbwq83HzrnOEWHgaL0tu+Qj3JufgOQ@mail.gmail.com>
References: <CAFdSV9tD2jK9rZiY596m-UrVHPYNA3+kpd8Y3anUtOg9HtpdYg@mail.gmail.com>
	<CAFdSV9v6uWNZhvtTgv5GrSCmH1-bWR6Ljj=EbHF5xf0D1UKVaQ@mail.gmail.com>
	<CAFdSV9s+fwrZ9Fn1k9nAQmGQv9-TGaJMK966RiHUdm-7bHnKCg@mail.gmail.com>
	<CAFm4XO0TTxcHnFhhiHePS7vwNSh-nR878cAwx5pvAnbeHBx0JA@mail.gmail.com>
	<CAFdSV9sbP-smxyq11Owcfbwq83HzrnOEWHgaL0tu+Qj3JufgOQ@mail.gmail.com>
Message-ID: <CAFdSV9ucevS30cV4iXPmhubsY+HCX1QitOo=Xrt60-XSUs3Fsg@mail.gmail.com>

BTW... there is also discussion of a delayed approach that would be based
on a setting.

This setting would essentially tell Hibernate to delay CDI access until
first use of a Listener.  I had resisted this approach because it delays
"deployment errors" (exceptions that really ought to stop the deployment)
until runtime.

The "win" for this approach however is that it would work in both 5.0 and
5.1.

So I think I will add that option, unless anyone has objections.


On Mon, Jan 25, 2016 at 12:02 PM Steve Ebersole <steve at hibernate.org> wrote:

> I have been in constant discussion with Scott about this.  I developed
> proposal after my discussions with him.
>
> Ultimately we believe the solution is an extension to CDI.  I developed
> this with that in my mind's eye.  Scott will be taking my work so far and
> trying to finish it (do the WildFly piece) this afternoon.  After we are
> all done we will suggest this as an extension to CDI proper.
>
> On Mon, Jan 25, 2016 at 11:41 AM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> I checked :
>>  - Hibernate OGM
>>  - Hibernate Search
>>  - Hibernate Validator
>>  - WildFly
>>
>> And none are using the listeners you listed. In the case of WildFly, I
>> don't know of course about all the frameworks which are included in
>> there.
>>
>> Sanne
>>
>> On 22 January 2016 at 23:58, Steve Ebersole <steve at hibernate.org> wrote:
>> > Anyone remember the back-story
>> > on
>> org.hibernate.jpa.event.internal.jpa.LegacyCallbackProcessor#useAnnotationAnnotatedByListener?
>> >
>> > If I read it correctly, it is looking at annotations on the entity
>> seeing
>> > if any of those annotations are in turn annotated with @EntityListeners.
>> >
>> > On Fri, Jan 22, 2016 at 3:38 PM Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >
>> >> If it matters, my plan is as follows...
>> >>
>> >> Currently JpaIntegrator is the central point for this processing.  The
>> >> general premise is that it builds a CallbackRegistry, a ListenerFactory
>> >> and a CallbackProcessor.  It then uses the CallbackProcessor and
>> ListenerFactory
>> >> to populate the CallbackRegistry.  This part is the crux of the problem
>> >> with HHH-8076 as after this JpaIntegrator call it is expected that
>> CallbackRegistry
>> >> be fully initialized (all Callbacks resolved and ready to go).
>> >>
>> >> So the plan is to instead invert these relationships to where we build
>> a CallbackRegistry
>> >> that is aware of the ListenerFactory and CallbackProcessor (actually I
>> >> think CallbackProcessor can go away).  This is the point in the
>> suggested
>> >> solution described for HHH-8076 where we'd check the BeanManager to
>> see if
>> >> it is a BeanManagerExtension and decide whether to delay the
>> >> initialization.  If that plan causes trouble for anyone, please speak
>> up
>> >> asap.  If not, I'll proceed.
>> >>
>> >> Thanks!
>> >>
>> >> On Fri, Jan 22, 2016 at 3:28 PM Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >>
>> >>> As part of the work on HHH-8076 for ORM 5.1 I am going to have to
>> change
>> >>> up, in some fashion, some or all of the following internal/spi
>> contracts :
>> >>>
>> >>> * org.hibernate.jpa.event.spi.jpa.Callback
>> >>> * org.hibernate.jpa.event.spi.jpa.CallbackRegistry
>> >>> * org.hibernate.jpa.event.spi.jpa.ListenerFactory
>> >>> * org.hibernate.jpa.event.internal.jpa.CallbackProcessor
>> >>>
>> >>> I need to know whether any integrations either use any of these or
>> >>> provide custom impls for any of them.
>> >>>
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From bulanovk at gmail.com  Tue Jan 26 02:14:43 2016
From: bulanovk at gmail.com (Konstantin Bulanov)
Date: Tue, 26 Jan 2016 11:14:43 +0400
Subject: [hibernate-dev] [hibernate-orm] HHH-7572 - Develop API for
 load-by-multiple-ids (#1136)
In-Reply-To: <CAFdSV9tG=380Ff1Ys0gjanaV5o3w7aiTmtPJnOHtXEFtFWJGZw@mail.gmail.com>
References: <hibernate/hibernate-orm/pull/1136@github.com>
	<hibernate/hibernate-orm/pull/1136/c158413356@github.com>
	<CAHsorq5vcvfEY5Y3Dv9h5RcBpY1Zt2i-b4BBg2qQh+VfAYDi1w@mail.gmail.com>
	<CAFdSV9uouG3C=utbhkMaa3sgAYMZhr1WhYd-=eYniL9PKd0c+g@mail.gmail.com>
	<CAHsorq78+bCk8-szQWhwkWLxCL=24grttuc9ghun5Ki8vw3GHw@mail.gmail.com>
	<CAFdSV9t2SWJdmW=PTytttVAYXKTjOXZKQO4jpYDkZvN9Y88Arg@mail.gmail.com>
	<CAFm4XO2VNfKJgmcbj-TK8eXj3sNfdw92H9Yj72kmnJ6MJerBuw@mail.gmail.com>
	<CAFdSV9tQCHyoxL-MAEiqTR-a8O9OjiBN=UEdDBBptRa5qpbD+Q@mail.gmail.com>
	<CAFm4XO3FEO7XJm5nnL2JNfwfifRUuGY5Ozt7Sdq_htCGFkRu9A@mail.gmail.com>
	<CAFdSV9tG=380Ff1Ys0gjanaV5o3w7aiTmtPJnOHtXEFtFWJGZw@mail.gmail.com>
Message-ID: <CAHsorq5TN7dyLooHh6ncuHd0Ne8mQcU26NK9uLy=MKK83MXZcw@mail.gmail.com>

Hello Steve, now it looks great.

Thank you.

2016-01-25 23:09 GMT+04:00 Steve Ebersole <steve at hibernate.org>:

> I am about to push all this upstream.  It now includes a hook through
> EntityPersister via a newly added method and "parameter object":
>
> List multiLoad(Serializable[] ids, SessionImplementor session,
> MultiLoadOptions loadOptions);
>
> MultiLoadOptions encapsulates the information configured
> on MultiIdentifierLoadAccess.
>
> At this point, I am calling this work done.
>
> On Mon, Jan 25, 2016 at 12:30 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> I like "multiLoad". Makes the intent more explicit, as the method
>> could be abused by passing lists of singleton identifiers.
>>
>> On 25 January 2016 at 18:21, Steve Ebersole <steve at hibernate.org> wrote:
>> > Minor detail wrt method naming...
>> >
>> > Actually performing a org.hibernate.MultiIdentifierLoadAccess is
>> currently
>> > achieved via a method named `#multiLoad`.  The name was chose because
>> > originally I wanted this to live on IdentifierLoadAccess and so the
>> `multi`
>> > part was needed to distinguish it from the singular load form.
>> >
>> > Now that this has been split off into a new contract, is maybe
>> > MultiIdentifierLoadAccess#load preferable over
>> > MultiIdentifierLoadAccess#multiLoad?
>> >
>> > On Wed, Jan 20, 2016 at 3:46 AM Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> >>
>> >> Hi Steve,
>> >> Hibernate Search doesn't customize the loaders: if any we want to make
>> >> sure that whatever customization has been defined is being used by
>> >> Search as well.
>> >> Hibernate OGM does of course replace the default loaders; I'm not sure
>> >> how nicely that interacts with the user wanting to override it.
>> >>
>> >> -- Sanne
>> >>
>> >> On 19 January 2016 at 22:30, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >> > Sanne, Gunnar any thoughts/input here?
>> >> >
>> >> >
>> >> > On Tue, Nov 24, 2015 at 2:11 AM Konstantin Bulanov <
>> bulanovk at gmail.com>
>> >> > wrote:
>> >> >
>> >> >> Hello, yes, you are absolutely right, the main concern here is that
>> >> >> with
>> >> >> new MultipleLoad API we got inconsistent behavior for loading using
>> >> >> IdentifierLoadAccessImpl and MultiIdentifierLoadAccessImpl.
>> >> >>
>> >> >>
>> >> >> What regarding my case, it is loading data from EAV model, with
>> >> >> predefined
>> >> >> scenarios.
>> >> >>
>> >> >>
>> >> >> We have 3 tables:
>> >> >>
>> >> >>
>> >> >> Objects[id ? pk, name, type_id, parent]
>> >> >> Params[attr_id, value, object_id (fk to objects), show_order]
>> >> >> References[ attr_id, reference, object_id( fk to objects),
>> show_order]
>> >> >>
>> >> >>
>> >> >> Also we have a data loading scenario configuration based on type_id,
>> >> >> identifying set of params\references Entities and Object Entities
>> >> >> referenced by References entity to be Eager load during loading
>> Object
>> >> >> Entities.
>> >> >>
>> >> >>
>> >> >> We have more than 1k attributes and more than 100Gb of data in
>> >> >> Object\Params\References entities
>> >> >>
>> >> >>
>> >> >> So it is simple recursive loading task, as per me, the best place
>> for
>> >> >> it
>> >> >> persister.load with optimized loader (at least without query
>> hardparse
>> >> >> on
>> >> >> each multiloading, this could be done using custom Oracle\PostgreSQL
>> >> >> datatype to pass array of ids as a bind variable in case of bulk
>> load
>> >> >> by
>> >> >> Ids)
>> >> >>
>> >> >>
>> >> >> PostgreSQL ex.:
>> >> >> Select * from objects where id = any(?);
>> >> >>
>> >> >>
>> >> >> If you could advise better solution to implement such scenario
>> based on
>> >> >> EAV Eager loading I will be very appreciated to you.
>> >> >>
>> >> >> 2015-11-23 23:31 GMT+04:00 Steve Ebersole <steve at hibernate.org>:
>> >> >>
>> >> >>> Personally I think its a questions of semantics; to me a multi-id
>> load
>> >> >>> already implies/indicates a certain loading strategy (Loader).  You
>> >> >>> are
>> >> >>> saying you'd like the ability to still decide a specific loading
>> >> >>> strategy
>> >> >>> for multi-id loads.  I seriously doubt that is really what you
>> want,
>> >> >>> but I
>> >> >>> do understand the desire for consistency.  Maybe some others will
>> >> >>> chime in;
>> >> >>> tbh I'm surprised Gunnar and Sanne did not bring this up as well in
>> >> >>> terms
>> >> >>> of integrating this with Search.
>> >> >>>
>> >> >>> Also, that was not the question I asked.  Specifically, what is it
>> you
>> >> >>> want to do that you cannot do given the current call chain?
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Mon, Nov 23, 2015 at 2:07 AM Konstantin Bulanov
>> >> >>> <bulanovk at gmail.com>
>> >> >>> wrote:
>> >> >>>
>> >> >>>> Hello Steve, as you asked moving our discussion about HHH-7572 in
>> dev
>> >> >>>> mail
>> >> >>>> list.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Regarding you question, in current architecture and
>> implementation we
>> >> >>>> have
>> >> >>>> the following point to perform entity persistence customization.
>> >> >>>>
>> >> >>>> Annotation:
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/annotations/Persister.html
>> >> >>>> which allows us to specify our own implementation of
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> https://docs.jboss.org/hibernate/orm/5.0/javadocs/org/hibernate/persister/entity/EntityPersister.html
>> >> >>>> .
>> >> >>>>
>> >> >>>>
>> >> >>>> One of its methods is:
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Object load(Serializable id,
>> >> >>>>
>> >> >>>>             Object optionalObject,
>> >> >>>>
>> >> >>>>             LockMode lockMode,
>> >> >>>>
>> >> >>>>             SessionImplementor session)
>> >> >>>>
>> >> >>>>      throws HibernateException
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Load an instance of the persistent class.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> and
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Object load(Serializable id,
>> >> >>>>
>> >> >>>>             Object optionalObject,
>> >> >>>>
>> >> >>>>             LockOptions lockOptions,
>> >> >>>>
>> >> >>>>             SessionImplementor session)
>> >> >>>>
>> >> >>>>      throws HibernateException
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> Load an instance of the persistent class.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> These two methods allows to specify you own Loader implementation
>> to
>> >> >>>> load
>> >> >>>> Entity by IDS,
>> >> >>>>
>> >> >>>> in mentioned issue this part of contract was ignored by changing
>> call
>> >> >>>> sequence on loading by multiple ids.
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> By Single id;
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> org.hibernate.internal.SessionImpl#get->IdentifierLoadAccessImpl->org.hibernate.internal.SessionImpl.IdentifierLoadAccessImpl#load->org.hibernate.event.spi.LoadEventListener#onLoad->org.hibernate.event.internal.DefaultLoadEventListener#loadFromDatasource->org.hibernate.persister.entity.EntityPersister#load
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> By Multiple id:
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> org.hibernate.internal.SessionImpl#byMultipleIds->org.hibernate.internal.SessionImpl.MultiIdentifierLoadAccessImpl#multiLoad->org.hibernate.loader.entity.DynamicBatchingEntityLoaderBuilder#multiLoad
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> So in new API for multiple load we lose at least 2 possible
>> extension
>> >> >>>> points: onLoadEvent, Persister.load (here we could customize
>> loader -
>> >> >>>> specify our own instead hardcoded one)
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> From my point of view there should be the same approach to get
>> >> >>>> entities
>> >> >>>> by
>> >> >>>> ID(independent multiple or single).
>> >> >>>>
>> >> >>>>
>> >> >>>> So which one approach is correct and future-proof for Single id or
>> >> >>>> Multiple
>> >> >>>> Ids?
>> >> >>>>
>> >> >>>>
>> >> >>>> 20 ????. 2015 ?. 18:19 ???????????? "Steve Ebersole" <
>> >> >>>> notifications at github.com> ???????:
>> >> >>>>
>> >> >>>> > Customize how? Loader still calls into the persister. Persisters
>> >> >>>> > and
>> >> >>>> > Loaders have a back-and-forth synergy.
>> >> >>>> >
>> >> >>>> > Also please discuss this on the hibernate-dev mailing list so
>> >> >>>> > others
>> >> >>>> can be
>> >> >>>> > involved.
>> >> >>>> >
>> >> >>>> > On Fri, Nov 20, 2015 at 7:15 AM Konstantin Bulanov <
>> >> >>>> > notifications at github.com>
>> >> >>>> > wrote:
>> >> >>>> >
>> >> >>>> > > Hello Steve, could you be so kind to advice why we have
>> different
>> >> >>>> > behavior
>> >> >>>> > > for loading by single id and multiple ids?
>> >> >>>> > >
>> >> >>>> > > In Case of single id, loading is going through
>> >> >>>> > > session->IdentifierLoadAccess->event->persister->Loader
>> >> >>>> > > In Case of multiple ids, loading is going through
>> >> >>>> > > session->MultiIdentifierLoadAccess->Loader
>> >> >>>> > >
>> >> >>>> > > So in case of load by single id it is possible to cutomize
>> >> >>>> > > loading of
>> >> >>>> > > Entify using persister, but in new introduced API we lost this
>> >> >>>> > posibility.
>> >> >>>> > >
>> >> >>>> > > ?
>> >> >>>> > > Reply to this email directly or view it on GitHub
>> >> >>>> > > <
>> >> >>>> >
>> >> >>>>
>> >> >>>>
>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158400273
>> >> >>>> > >
>> >> >>>> > > .
>> >> >>>> > >
>> >> >>>> >
>> >> >>>> > ?
>> >> >>>> > Reply to this email directly or view it on GitHub
>> >> >>>> > <
>> >> >>>>
>> >> >>>>
>> https://github.com/hibernate/hibernate-orm/pull/1136#issuecomment-158413356
>> >> >>>> >
>> >> >>>> > .
>> >> >>>> >
>> >> >>>> _______________________________________________
>> >> >>>> hibernate-dev mailing list
>> >> >>>> hibernate-dev at lists.jboss.org
>> >> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >>>
>> >> >>>
>> >> >>
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Tue Jan 26 10:10:16 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 Jan 2016 15:10:16 +0000
Subject: [hibernate-dev] Fwd: Build failed in Jenkins:
	hibernate-orm-master-h2 #1316
In-Reply-To: <1683980319.44.1453802940886.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
References: <1829318955.43.1453785257420.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<1683980319.44.1453802940886.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
Message-ID: <CAFdSV9varZ78OZm9mhYPHBNMyCXq=voWjhedx-9VK4PBadGi=Q@mail.gmail.com>

Anyone know what is up with this Javadoc tool failure in these jobs?  We've
had the same failure for the last few builds...

---------- Forwarded message ---------
From: Hibernate CI <ci at hibernate.org>
Date: Tue, Jan 26, 2016 at 4:09 AM
Subject: Build failed in Jenkins: hibernate-orm-master-h2 #1316
To: <steve at hibernate.org>, <mih_vlad at yahoo.com>


See <http://ci.hibernate.org/job/hibernate-orm-master-h2/1316/changes>

Changes:

[mih_vlad] Move User Guide Bootstrap chapter code snippets from extras to
test

------------------------------------------
[...truncated 1048 lines...]
FindBugs rule violations were found. See the report at:
file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/main.xml
:hibernate-osgi:findbugsTest
FindBugs rule violations were found. See the report at:
file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/test.xml
:hibernate-osgi:buildDashboard
:hibernate-proxool:compileJava
Starting AnimalSniffer checks using [java16-1.0.signature] against
[sourceSets.main]
:hibernate-proxool:processResources
:hibernate-proxool:classes
:hibernate-proxool:compileTestJava
:hibernate-proxool:processTestResources
:hibernate-proxool:testClasses
:hibernate-proxool:test
:hibernate-proxool:checkstyleMain
:hibernate-proxool:findbugsMain
FindBugs rule violations were found. See the report at:
file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/main.xml
:hibernate-proxool:findbugsTest
FindBugs rule violations were found. See the report at:
file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/test.xml
:hibernate-proxool:buildDashboard
:hibernate-spatial:compileJavaNote:
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/src/main/java/org/hibernate/spatial/integration/SpatialService.java
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

Starting AnimalSniffer checks using [java16-1.0.signature] against
[sourceSets.main]
:hibernate-spatial:processResources
:hibernate-spatial:classes
:hibernate-spatial:compileTestJavaNote: Some input files use or override a
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:hibernate-spatial:processTestResources
:hibernate-spatial:testClasses
:hibernate-spatial:test
:hibernate-spatial:checkstyleMain
:hibernate-spatial:findbugsMain
:hibernate-spatial:findbugsTest
FindBugs rule violations were found. See the report at:
file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/target/reports/findbugs/test.xml
:hibernate-spatial:buildDashboard
:hibernate-testing:compileTestJava
:hibernate-testing:processTestResources UP-TO-DATE
:hibernate-testing:testClasses
:hibernate-testing:test
:hibernate-testing:checkstyleMain
:hibernate-testing:findbugsMain
FindBugs rule violations were found. See the report at:
file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-testing/target/reports/findbugs/main.xml
:hibernate-testing:findbugsTest
:hibernate-testing:buildDashboard
:documentation:check
:hibernate-c3p0:check
:hibernate-core:check
:hibernate-ehcache:check
:hibernate-enhance-maven-plugin:check
:hibernate-entitymanager:check
:hibernate-envers:check
:hibernate-gradle-plugin:check
:hibernate-hikaricp:check
:hibernate-infinispan:check
:hibernate-java8:check
:hibernate-jpamodelgen:check
:hibernate-osgi:check
:hibernate-proxool:check
:hibernate-spatial:check
:hibernate-testing:check
:release:check UP-TO-DATE
:documentation:aggregateJavadocs/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/exec/internal/AliasResolutionContextImpl.java:174:
warning - Tag @link: can't find #resolveCollectionReferenceAliases(String)
in org.hibernate.loader.plan.exec.internal.AliasResolutionContextImpl
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
warning - Tag @link: reference not found: Disposition#COLLECTION_INITIALIZER
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
warning - Tag @link: reference not found: Disposition#MIXED
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
warning - Tag @link: reference not found: Disposition#COLLECTION_INITIALIZER
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
warning - Tag @link: reference not found: Disposition#MIXED
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/spi/BidirectionalEntityReference.java:42:
warning - Tag @link: can't find
getTargetEntityReference()#getQuerySpaceUid() in
org.hibernate.loader.plan.spi.BidirectionalEntityReference
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/tuple/IdentifierProperty.java:41:
warning - @param argument "node" is not a parameter name.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:283:
warning - Tag @link: reference not found: this
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:309:
warning - Tag @link: reference not found: this
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:328:
warning - Tag @link: reference not found: this
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:36:
warning - Tag @link: reference not found: NaturalIdResolutionCache
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
warning - Tag @link: reference not found:
PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
warning - Tag @link: reference not found:
PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/spi/PersistenceContext.java:489:
warning - @return tag has no arguments.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/persister/entity/AbstractEntityPersister.java:2299:
warning - @return tag has no arguments.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
warning - Tag @see:illegal character: "123" in "{@link
#buildSQLExceptionConversionDelegate()}"
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
warning - Tag @see:illegal character: "64" in "{@link
#buildSQLExceptionConversionDelegate()}"
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:2712:
warning - @return tag has no arguments.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/jdbc/spi/JdbcServices.java:28:
warning - @return tag has no arguments.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/PropertyHolder.java:95:
warning - @return tag has no arguments.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/ExternalSessionFactoryConfig.java:25:
warning - Tag @link: reference not found:
org.hibernate.jmx.HibernateService JMX
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/NamingStrategy.java:27:
warning - Tag @link: reference not found:
org.hibernate.cfg.naming.NamingStrategyDelegator
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
warning - Tag @see:illegal character: "123" in "{@link
#nullifyTransientReferencesIfNotAlready}"
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
warning - Tag @see:illegal character: "64" in "{@link
#nullifyTransientReferencesIfNotAlready}"
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
warning - Tag @see:illegal character: "123" in "{@link #makeEntityManaged()
}"
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
warning - Tag @see:illegal character: "64" in "{@link #makeEntityManaged()
}"
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
warning - Tag @see: reference not found: {@link
#nullifyTransientReferencesIfNotAlready}
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
warning - Tag @see: reference not found: {@link #makeEntityManaged() }
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - @propertyDescription is an unknown tag.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - @propertyDescription is an unknown tag.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - @propertyDescription is an unknown tag.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - @propertyDescription is an unknown tag.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - @propertyDescription is an unknown tag.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - @propertyDescription is an unknown tag.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/MapEntryNode.java:34:
warning - Tag @link: reference not found: Map.Entry
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
warning - Tags @propertyGetter, @propertySetter and @propertyDescription
can only be used in JavaFX properties getters and setters.
java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl cannot be
cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
        at
com.sun.tools.javadoc.DocEnv.getAnnotationTypeElementDoc(DocEnv.java:721)
        at
com.sun.tools.javadoc.AnnotationTypeDocImpl.elements(AnnotationTypeDocImpl.java:97)
        at
com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.filter(VisibleMemberMap.java:492)
        at
com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.getClassMembers(VisibleMemberMap.java:442)
        at
com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.addMembers(VisibleMemberMap.java:372)
        at
com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:346)
        at
com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:351)
        at
com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.build(VisibleMemberMap.java:341)
        at
com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.access$100(VisibleMemberMap.java:291)
        at
com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap.<init>(VisibleMemberMap.java:127)
        at
com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.<init>(MemberSummaryBuilder.java:82)
        at
com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.getInstance(MemberSummaryBuilder.java:101)
        at
com.sun.tools.doclets.internal.toolkit.builders.BuilderFactory.getMemberSummaryBuilder(BuilderFactory.java:278)
        at
com.sun.tools.doclets.formats.html.ClassWriterImpl.getNavSummaryLinks(ClassWriterImpl.java:641)
        at
com.sun.tools.doclets.formats.html.ClassWriterImpl.addSummaryDetailLinks(ClassWriterImpl.java:622)
        at
com.sun.tools.doclets.formats.html.HtmlDocletWriter.addNavLinks(HtmlDocletWriter.java:560)
        at
com.sun.tools.doclets.formats.html.ClassWriterImpl.getHeader(ClassWriterImpl.java:165)
        at
com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:145)
        at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at
com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.invokeMethod(AbstractBuilder.java:180)
        at
com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:135)
        at
com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:120)
        at
com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:189)
        at
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:205)
        at
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:189)
        at
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:137)
        at
com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:82)
        at
com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:80)
        at com.sun.tools.doclets.standard.Standard.start(Standard.java:39)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at
com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
        at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
        at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
        at com.sun.tools.javadoc.Start.begin(Start.java:219)
        at com.sun.tools.javadoc.Start.begin(Start.java:205)
        at com.sun.tools.javadoc.Main.execute(Main.java:64)
        at com.sun.tools.javadoc.Main.main(Main.java:54)

1 error
100 warnings
javadoc: error - java.lang.ClassCastException:
com.sun.tools.javadoc.MethodDocImpl cannot be cast to
com.sun.tools.javadoc.AnnotationTypeElementDocImpl
:documentation:aggregateJavadocs FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':documentation:aggregateJavadocs'.
> Javadoc generation failed. Generated Javadoc options file (useful for
troubleshooting):
'/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/documentation/target/tmp/aggregateJavadocs/javadoc.options'

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

BUILD FAILED

Total time: 50 mins 9.575 secs
Build step 'Execute shell' marked build as failure
[CHECKSTYLE] Collecting checkstyle analysis files...
[CHECKSTYLE] Finding all files that match the pattern
**/target/reports/checkstyle/*.xml
[CHECKSTYLE] Parsing 14 files in <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/>
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/target/reports/checkstyle/main.xml>
with 2 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/target/reports/checkstyle/main.xml>
with 2391 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/target/reports/checkstyle/main.xml>
with 2416 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entitymanager/target/reports/checkstyle/main.xml>
with 2734 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-envers/target/reports/checkstyle/main.xml>
with 2798 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-hikaricp/target/reports/checkstyle/main.xml>
with 2801 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-infinispan/target/reports/checkstyle/main.xml>
with 3331 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-java8/target/reports/checkstyle/main.xml>
with 3334 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-osgi/target/reports/checkstyle/main.xml>
with 3346 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-proxool/target/reports/checkstyle/main.xml>
with 3347 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-spatial/target/reports/checkstyle/main.xml>
with 3357 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-testing/target/reports/checkstyle/main.xml>
with 3450 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/hibernate-enhance-maven-plugin/target/reports/checkstyle/main.xml>
with 3451 unique warnings and 0 duplicates.
[CHECKSTYLE] Successfully parsed file <
http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/metamodel-generator/target/reports/checkstyle/main.xml>
with 3456 unique warnings and 0 duplicates.
[CHECKSTYLE] Computing warning deltas based on reference build #1314
[FINDBUGS] Skipping publisher since build result is FAILURE
[TASKS] Skipping publisher since build result is FAILURE
Recording test results
Publishing Javadoc

From mihalcea.vlad at gmail.com  Tue Jan 26 10:55:49 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Tue, 26 Jan 2016 17:55:49 +0200
Subject: [hibernate-dev] Fwd: Build failed in Jenkins:
 hibernate-orm-master-h2 #1316
In-Reply-To: <CAFdSV9varZ78OZm9mhYPHBNMyCXq=voWjhedx-9VK4PBadGi=Q@mail.gmail.com>
References: <1829318955.43.1453785257420.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<1683980319.44.1453802940886.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<CAFdSV9varZ78OZm9mhYPHBNMyCXq=voWjhedx-9VK4PBadGi=Q@mail.gmail.com>
Message-ID: <CA+gWKMCG7JQRpvg5cQvJzDBVgAXWTcqJNZTTcqgf=dpTNJ35GA@mail.gmail.com>

I could replicate it on my local machine too:

javadoc: error - java.lang.ClassCastException:
com.sun.tools.javadoc.MethodDocImpl cannot be cast to
com.sun.tools.javadoc.AnnotationTypeElementDocImpl
:documentation:aggregateJavadocs FAILED

http://stackoverflow.com/questions/44853/why-am-i-getting-a-classcastexception-when-generating-javadocs

I'll need to dig into it further

Vlad

On Tue, Jan 26, 2016 at 5:10 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Anyone know what is up with this Javadoc tool failure in these jobs?  We've
> had the same failure for the last few builds...
>
> ---------- Forwarded message ---------
> From: Hibernate CI <ci at hibernate.org>
> Date: Tue, Jan 26, 2016 at 4:09 AM
> Subject: Build failed in Jenkins: hibernate-orm-master-h2 #1316
> To: <steve at hibernate.org>, <mih_vlad at yahoo.com>
>
>
> See <http://ci.hibernate.org/job/hibernate-orm-master-h2/1316/changes>
>
> Changes:
>
> [mih_vlad] Move User Guide Bootstrap chapter code snippets from extras to
> test
>
> ------------------------------------------
> [...truncated 1048 lines...]
> FindBugs rule violations were found. See the report at:
>
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/main.xml
> :hibernate-osgi:findbugsTest
> FindBugs rule violations were found. See the report at:
>
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/test.xml
> :hibernate-osgi:buildDashboard
> :hibernate-proxool:compileJava
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-proxool:processResources
> :hibernate-proxool:classes
> :hibernate-proxool:compileTestJava
> :hibernate-proxool:processTestResources
> :hibernate-proxool:testClasses
> :hibernate-proxool:test
> :hibernate-proxool:checkstyleMain
> :hibernate-proxool:findbugsMain
> FindBugs rule violations were found. See the report at:
>
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/main.xml
> :hibernate-proxool:findbugsTest
> FindBugs rule violations were found. See the report at:
>
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/test.xml
> :hibernate-proxool:buildDashboard
> :hibernate-spatial:compileJavaNote:
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/src/main/java/org/hibernate/spatial/integration/SpatialService.java
> uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-spatial:processResources
> :hibernate-spatial:classes
> :hibernate-spatial:compileTestJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :hibernate-spatial:processTestResources
> :hibernate-spatial:testClasses
> :hibernate-spatial:test
> :hibernate-spatial:checkstyleMain
> :hibernate-spatial:findbugsMain
> :hibernate-spatial:findbugsTest
> FindBugs rule violations were found. See the report at:
>
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/target/reports/findbugs/test.xml
> :hibernate-spatial:buildDashboard
> :hibernate-testing:compileTestJava
> :hibernate-testing:processTestResources UP-TO-DATE
> :hibernate-testing:testClasses
> :hibernate-testing:test
> :hibernate-testing:checkstyleMain
> :hibernate-testing:findbugsMain
> FindBugs rule violations were found. See the report at:
>
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-testing/target/reports/findbugs/main.xml
> :hibernate-testing:findbugsTest
> :hibernate-testing:buildDashboard
> :documentation:check
> :hibernate-c3p0:check
> :hibernate-core:check
> :hibernate-ehcache:check
> :hibernate-enhance-maven-plugin:check
> :hibernate-entitymanager:check
> :hibernate-envers:check
> :hibernate-gradle-plugin:check
> :hibernate-hikaricp:check
> :hibernate-infinispan:check
> :hibernate-java8:check
> :hibernate-jpamodelgen:check
> :hibernate-osgi:check
> :hibernate-proxool:check
> :hibernate-spatial:check
> :hibernate-testing:check
> :release:check UP-TO-DATE
>
> :documentation:aggregateJavadocs/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/exec/internal/AliasResolutionContextImpl.java:174:
> warning - Tag @link: can't find #resolveCollectionReferenceAliases(String)
> in org.hibernate.loader.plan.exec.internal.AliasResolutionContextImpl
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
> warning - Tag @link: reference not found:
> Disposition#COLLECTION_INITIALIZER
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
> warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
> warning - Tag @link: reference not found: Disposition#MIXED
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
> warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
> warning - Tag @link: reference not found:
> Disposition#COLLECTION_INITIALIZER
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
> warning - Tag @link: reference not found: Disposition#MIXED
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/spi/BidirectionalEntityReference.java:42:
> warning - Tag @link: can't find
> getTargetEntityReference()#getQuerySpaceUid() in
> org.hibernate.loader.plan.spi.BidirectionalEntityReference
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/tuple/IdentifierProperty.java:41:
> warning - @param argument "node" is not a parameter name.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:283:
> warning - Tag @link: reference not found: this
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:309:
> warning - Tag @link: reference not found: this
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:328:
> warning - Tag @link: reference not found: this
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:36:
> warning - Tag @link: reference not found: NaturalIdResolutionCache
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
> warning - Tag @link: reference not found:
> PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
> warning - Tag @link: reference not found:
> PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/spi/PersistenceContext.java:489:
> warning - @return tag has no arguments.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/persister/entity/AbstractEntityPersister.java:2299:
> warning - @return tag has no arguments.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
> warning - Tag @see:illegal character: "123" in "{@link
> #buildSQLExceptionConversionDelegate()}"
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
> warning - Tag @see:illegal character: "64" in "{@link
> #buildSQLExceptionConversionDelegate()}"
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:2712:
> warning - @return tag has no arguments.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/jdbc/spi/JdbcServices.java:28:
> warning - @return tag has no arguments.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/PropertyHolder.java:95:
> warning - @return tag has no arguments.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/ExternalSessionFactoryConfig.java:25:
> warning - Tag @link: reference not found:
> org.hibernate.jmx.HibernateService JMX
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/NamingStrategy.java:27:
> warning - Tag @link: reference not found:
> org.hibernate.cfg.naming.NamingStrategyDelegator
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
> warning - Tag @see:illegal character: "123" in "{@link
> #nullifyTransientReferencesIfNotAlready}"
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
> warning - Tag @see:illegal character: "64" in "{@link
> #nullifyTransientReferencesIfNotAlready}"
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
> warning - Tag @see:illegal character: "123" in "{@link #makeEntityManaged()
> }"
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
> warning - Tag @see:illegal character: "64" in "{@link #makeEntityManaged()
> }"
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
> warning - Tag @see: reference not found: {@link
> #nullifyTransientReferencesIfNotAlready}
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
> warning - Tag @see: reference not found: {@link #makeEntityManaged() }
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - @propertyDescription is an unknown tag.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - @propertyDescription is an unknown tag.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - @propertyDescription is an unknown tag.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - @propertyDescription is an unknown tag.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - @propertyDescription is an unknown tag.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - @propertyDescription is an unknown tag.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/MapEntryNode.java:34:
> warning - Tag @link: reference not found: Map.Entry
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
>
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> can only be used in JavaFX properties getters and setters.
> java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl cannot be
> cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>         at
> com.sun.tools.javadoc.DocEnv.getAnnotationTypeElementDoc(DocEnv.java:721)
>         at
>
> com.sun.tools.javadoc.AnnotationTypeDocImpl.elements(AnnotationTypeDocImpl.java:97)
>         at
>
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.filter(VisibleMemberMap.java:492)
>         at
>
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.getClassMembers(VisibleMemberMap.java:442)
>         at
>
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.addMembers(VisibleMemberMap.java:372)
>         at
>
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:346)
>         at
>
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:351)
>         at
>
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.build(VisibleMemberMap.java:341)
>         at
>
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.access$100(VisibleMemberMap.java:291)
>         at
>
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap.<init>(VisibleMemberMap.java:127)
>         at
>
> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.<init>(MemberSummaryBuilder.java:82)
>         at
>
> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.getInstance(MemberSummaryBuilder.java:101)
>         at
>
> com.sun.tools.doclets.internal.toolkit.builders.BuilderFactory.getMemberSummaryBuilder(BuilderFactory.java:278)
>         at
>
> com.sun.tools.doclets.formats.html.ClassWriterImpl.getNavSummaryLinks(ClassWriterImpl.java:641)
>         at
>
> com.sun.tools.doclets.formats.html.ClassWriterImpl.addSummaryDetailLinks(ClassWriterImpl.java:622)
>         at
>
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.addNavLinks(HtmlDocletWriter.java:560)
>         at
>
> com.sun.tools.doclets.formats.html.ClassWriterImpl.getHeader(ClassWriterImpl.java:165)
>         at
>
> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:145)
>         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>         at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:497)
>         at
>
> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.invokeMethod(AbstractBuilder.java:180)
>         at
>
> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:135)
>         at
>
> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:120)
>         at
>
> com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:189)
>         at
>
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:205)
>         at
>
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:189)
>         at
>
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:137)
>         at
>
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:82)
>         at
> com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:80)
>         at com.sun.tools.doclets.standard.Standard.start(Standard.java:39)
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at
>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>         at
>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.lang.reflect.Method.invoke(Method.java:497)
>         at
> com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
>         at
> com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
>         at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
>         at com.sun.tools.javadoc.Start.begin(Start.java:219)
>         at com.sun.tools.javadoc.Start.begin(Start.java:205)
>         at com.sun.tools.javadoc.Main.execute(Main.java:64)
>         at com.sun.tools.javadoc.Main.main(Main.java:54)
>
> 1 error
> 100 warnings
> javadoc: error - java.lang.ClassCastException:
> com.sun.tools.javadoc.MethodDocImpl cannot be cast to
> com.sun.tools.javadoc.AnnotationTypeElementDocImpl
> :documentation:aggregateJavadocs FAILED
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':documentation:aggregateJavadocs'.
> > Javadoc generation failed. Generated Javadoc options file (useful for
> troubleshooting):
>
> '/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/documentation/target/tmp/aggregateJavadocs/javadoc.options'
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output.
>
> BUILD FAILED
>
> Total time: 50 mins 9.575 secs
> Build step 'Execute shell' marked build as failure
> [CHECKSTYLE] Collecting checkstyle analysis files...
> [CHECKSTYLE] Finding all files that match the pattern
> **/target/reports/checkstyle/*.xml
> [CHECKSTYLE] Parsing 14 files in <
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/>
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/target/reports/checkstyle/main.xml
> >
> with 2 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/target/reports/checkstyle/main.xml
> >
> with 2391 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/target/reports/checkstyle/main.xml
> >
> with 2416 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entitymanager/target/reports/checkstyle/main.xml
> >
> with 2734 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-envers/target/reports/checkstyle/main.xml
> >
> with 2798 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-hikaricp/target/reports/checkstyle/main.xml
> >
> with 2801 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-infinispan/target/reports/checkstyle/main.xml
> >
> with 3331 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-java8/target/reports/checkstyle/main.xml
> >
> with 3334 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-osgi/target/reports/checkstyle/main.xml
> >
> with 3346 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-proxool/target/reports/checkstyle/main.xml
> >
> with 3347 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-spatial/target/reports/checkstyle/main.xml
> >
> with 3357 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-testing/target/reports/checkstyle/main.xml
> >
> with 3450 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/hibernate-enhance-maven-plugin/target/reports/checkstyle/main.xml
> >
> with 3451 unique warnings and 0 duplicates.
> [CHECKSTYLE] Successfully parsed file <
>
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/metamodel-generator/target/reports/checkstyle/main.xml
> >
> with 3456 unique warnings and 0 duplicates.
> [CHECKSTYLE] Computing warning deltas based on reference build #1314
> [FINDBUGS] Skipping publisher since build result is FAILURE
> [TASKS] Skipping publisher since build result is FAILURE
> Recording test results
> Publishing Javadoc
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From dreborier at gmail.com  Tue Jan 26 11:07:05 2016
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 26 Jan 2016 16:07:05 +0000
Subject: [hibernate-dev] Fwd: Build failed in Jenkins:
 hibernate-orm-master-h2 #1316
In-Reply-To: <CA+gWKMCG7JQRpvg5cQvJzDBVgAXWTcqJNZTTcqgf=dpTNJ35GA@mail.gmail.com>
References: <1829318955.43.1453785257420.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<1683980319.44.1453802940886.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<CAFdSV9varZ78OZm9mhYPHBNMyCXq=voWjhedx-9VK4PBadGi=Q@mail.gmail.com>
	<CA+gWKMCG7JQRpvg5cQvJzDBVgAXWTcqJNZTTcqgf=dpTNJ35GA@mail.gmail.com>
Message-ID: <CAL00eSQcyM-Qmx5J0Osi4q+D7GMv1Kq_hCmESMgUMRBf2j1nmA@mail.gmail.com>

the failure is caused by the javadoc of
AvailabeSettings#GLOBALLY_QUOTED_IDENTIFIERS_SKIP_COLUMN_DEFINITIONS
I'm fixing it

On 26 January 2016 at 15:55, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:

> I could replicate it on my local machine too:
>
> javadoc: error - java.lang.ClassCastException:
> com.sun.tools.javadoc.MethodDocImpl cannot be cast to
> com.sun.tools.javadoc.AnnotationTypeElementDocImpl
> :documentation:aggregateJavadocs FAILED
>
>
> http://stackoverflow.com/questions/44853/why-am-i-getting-a-classcastexception-when-generating-javadocs
>
> I'll need to dig into it further
>
> Vlad
>
> On Tue, Jan 26, 2016 at 5:10 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > Anyone know what is up with this Javadoc tool failure in these jobs?
> We've
> > had the same failure for the last few builds...
> >
> > ---------- Forwarded message ---------
> > From: Hibernate CI <ci at hibernate.org>
> > Date: Tue, Jan 26, 2016 at 4:09 AM
> > Subject: Build failed in Jenkins: hibernate-orm-master-h2 #1316
> > To: <steve at hibernate.org>, <mih_vlad at yahoo.com>
> >
> >
> > See <http://ci.hibernate.org/job/hibernate-orm-master-h2/1316/changes>
> >
> > Changes:
> >
> > [mih_vlad] Move User Guide Bootstrap chapter code snippets from extras to
> > test
> >
> > ------------------------------------------
> > [...truncated 1048 lines...]
> > FindBugs rule violations were found. See the report at:
> >
> >
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/main.xml
> > :hibernate-osgi:findbugsTest
> > FindBugs rule violations were found. See the report at:
> >
> >
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/test.xml
> > :hibernate-osgi:buildDashboard
> > :hibernate-proxool:compileJava
> > Starting AnimalSniffer checks using [java16-1.0.signature] against
> > [sourceSets.main]
> > :hibernate-proxool:processResources
> > :hibernate-proxool:classes
> > :hibernate-proxool:compileTestJava
> > :hibernate-proxool:processTestResources
> > :hibernate-proxool:testClasses
> > :hibernate-proxool:test
> > :hibernate-proxool:checkstyleMain
> > :hibernate-proxool:findbugsMain
> > FindBugs rule violations were found. See the report at:
> >
> >
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/main.xml
> > :hibernate-proxool:findbugsTest
> > FindBugs rule violations were found. See the report at:
> >
> >
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/test.xml
> > :hibernate-proxool:buildDashboard
> > :hibernate-spatial:compileJavaNote:
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/src/main/java/org/hibernate/spatial/integration/SpatialService.java
> > uses or overrides a deprecated API.
> > Note: Recompile with -Xlint:deprecation for details.
> > Note: Some input files use unchecked or unsafe operations.
> > Note: Recompile with -Xlint:unchecked for details.
> >
> > Starting AnimalSniffer checks using [java16-1.0.signature] against
> > [sourceSets.main]
> > :hibernate-spatial:processResources
> > :hibernate-spatial:classes
> > :hibernate-spatial:compileTestJavaNote: Some input files use or override
> a
> > deprecated API.
> > Note: Recompile with -Xlint:deprecation for details.
> > Note: Some input files use unchecked or unsafe operations.
> > Note: Recompile with -Xlint:unchecked for details.
> >
> > :hibernate-spatial:processTestResources
> > :hibernate-spatial:testClasses
> > :hibernate-spatial:test
> > :hibernate-spatial:checkstyleMain
> > :hibernate-spatial:findbugsMain
> > :hibernate-spatial:findbugsTest
> > FindBugs rule violations were found. See the report at:
> >
> >
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/target/reports/findbugs/test.xml
> > :hibernate-spatial:buildDashboard
> > :hibernate-testing:compileTestJava
> > :hibernate-testing:processTestResources UP-TO-DATE
> > :hibernate-testing:testClasses
> > :hibernate-testing:test
> > :hibernate-testing:checkstyleMain
> > :hibernate-testing:findbugsMain
> > FindBugs rule violations were found. See the report at:
> >
> >
> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-testing/target/reports/findbugs/main.xml
> > :hibernate-testing:findbugsTest
> > :hibernate-testing:buildDashboard
> > :documentation:check
> > :hibernate-c3p0:check
> > :hibernate-core:check
> > :hibernate-ehcache:check
> > :hibernate-enhance-maven-plugin:check
> > :hibernate-entitymanager:check
> > :hibernate-envers:check
> > :hibernate-gradle-plugin:check
> > :hibernate-hikaricp:check
> > :hibernate-infinispan:check
> > :hibernate-java8:check
> > :hibernate-jpamodelgen:check
> > :hibernate-osgi:check
> > :hibernate-proxool:check
> > :hibernate-spatial:check
> > :hibernate-testing:check
> > :release:check UP-TO-DATE
> >
> >
> :documentation:aggregateJavadocs/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/exec/internal/AliasResolutionContextImpl.java:174:
> > warning - Tag @link: can't find
> #resolveCollectionReferenceAliases(String)
> > in org.hibernate.loader.plan.exec.internal.AliasResolutionContextImpl
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
> > warning - Tag @link: reference not found:
> > Disposition#COLLECTION_INITIALIZER
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
> > warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
> > warning - Tag @link: reference not found: Disposition#MIXED
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
> > warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
> > warning - Tag @link: reference not found:
> > Disposition#COLLECTION_INITIALIZER
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
> > warning - Tag @link: reference not found: Disposition#MIXED
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/spi/BidirectionalEntityReference.java:42:
> > warning - Tag @link: can't find
> > getTargetEntityReference()#getQuerySpaceUid() in
> > org.hibernate.loader.plan.spi.BidirectionalEntityReference
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/tuple/IdentifierProperty.java:41:
> > warning - @param argument "node" is not a parameter name.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:283:
> > warning - Tag @link: reference not found: this
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:309:
> > warning - Tag @link: reference not found: this
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:328:
> > warning - Tag @link: reference not found: this
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:36:
> > warning - Tag @link: reference not found: NaturalIdResolutionCache
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
> > warning - Tag @link: reference not found:
> > PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
> > warning - Tag @link: reference not found:
> > PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/spi/PersistenceContext.java:489:
> > warning - @return tag has no arguments.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/persister/entity/AbstractEntityPersister.java:2299:
> > warning - @return tag has no arguments.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
> > warning - Tag @see:illegal character: "123" in "{@link
> > #buildSQLExceptionConversionDelegate()}"
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
> > warning - Tag @see:illegal character: "64" in "{@link
> > #buildSQLExceptionConversionDelegate()}"
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:2712:
> > warning - @return tag has no arguments.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/jdbc/spi/JdbcServices.java:28:
> > warning - @return tag has no arguments.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/PropertyHolder.java:95:
> > warning - @return tag has no arguments.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/ExternalSessionFactoryConfig.java:25:
> > warning - Tag @link: reference not found:
> > org.hibernate.jmx.HibernateService JMX
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/NamingStrategy.java:27:
> > warning - Tag @link: reference not found:
> > org.hibernate.cfg.naming.NamingStrategyDelegator
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
> > warning - Tag @see:illegal character: "123" in "{@link
> > #nullifyTransientReferencesIfNotAlready}"
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
> > warning - Tag @see:illegal character: "64" in "{@link
> > #nullifyTransientReferencesIfNotAlready}"
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
> > warning - Tag @see:illegal character: "123" in "{@link
> #makeEntityManaged()
> > }"
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
> > warning - Tag @see:illegal character: "64" in "{@link
> #makeEntityManaged()
> > }"
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
> > warning - Tag @see: reference not found: {@link
> > #nullifyTransientReferencesIfNotAlready}
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
> > warning - Tag @see: reference not found: {@link #makeEntityManaged() }
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - @propertyDescription is an unknown tag.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - @propertyDescription is an unknown tag.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - @propertyDescription is an unknown tag.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - @propertyDescription is an unknown tag.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - @propertyDescription is an unknown tag.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - @propertyDescription is an unknown tag.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/MapEntryNode.java:34:
> > warning - Tag @link: reference not found: Map.Entry
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> >
> >
> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
> > can only be used in JavaFX properties getters and setters.
> > java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl cannot
> be
> > cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
> >         at
> > com.sun.tools.javadoc.DocEnv.getAnnotationTypeElementDoc(DocEnv.java:721)
> >         at
> >
> >
> com.sun.tools.javadoc.AnnotationTypeDocImpl.elements(AnnotationTypeDocImpl.java:97)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.filter(VisibleMemberMap.java:492)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.getClassMembers(VisibleMemberMap.java:442)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.addMembers(VisibleMemberMap.java:372)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:346)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:351)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.build(VisibleMemberMap.java:341)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.access$100(VisibleMemberMap.java:291)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap.<init>(VisibleMemberMap.java:127)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.<init>(MemberSummaryBuilder.java:82)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.getInstance(MemberSummaryBuilder.java:101)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.builders.BuilderFactory.getMemberSummaryBuilder(BuilderFactory.java:278)
> >         at
> >
> >
> com.sun.tools.doclets.formats.html.ClassWriterImpl.getNavSummaryLinks(ClassWriterImpl.java:641)
> >         at
> >
> >
> com.sun.tools.doclets.formats.html.ClassWriterImpl.addSummaryDetailLinks(ClassWriterImpl.java:622)
> >         at
> >
> >
> com.sun.tools.doclets.formats.html.HtmlDocletWriter.addNavLinks(HtmlDocletWriter.java:560)
> >         at
> >
> >
> com.sun.tools.doclets.formats.html.ClassWriterImpl.getHeader(ClassWriterImpl.java:165)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:145)
> >         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> >         at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >         at java.lang.reflect.Method.invoke(Method.java:497)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.invokeMethod(AbstractBuilder.java:180)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:135)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:120)
> >         at
> >
> >
> com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:189)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:205)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:189)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:137)
> >         at
> >
> >
> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:82)
> >         at
> > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:80)
> >         at
> com.sun.tools.doclets.standard.Standard.start(Standard.java:39)
> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >         at
> >
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >         at
> >
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >         at java.lang.reflect.Method.invoke(Method.java:497)
> >         at
> > com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
> >         at
> > com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
> >         at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
> >         at com.sun.tools.javadoc.Start.begin(Start.java:219)
> >         at com.sun.tools.javadoc.Start.begin(Start.java:205)
> >         at com.sun.tools.javadoc.Main.execute(Main.java:64)
> >         at com.sun.tools.javadoc.Main.main(Main.java:54)
> >
> > 1 error
> > 100 warnings
> > javadoc: error - java.lang.ClassCastException:
> > com.sun.tools.javadoc.MethodDocImpl cannot be cast to
> > com.sun.tools.javadoc.AnnotationTypeElementDocImpl
> > :documentation:aggregateJavadocs FAILED
> >
> > FAILURE: Build failed with an exception.
> >
> > * What went wrong:
> > Execution failed for task ':documentation:aggregateJavadocs'.
> > > Javadoc generation failed. Generated Javadoc options file (useful for
> > troubleshooting):
> >
> >
> '/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/documentation/target/tmp/aggregateJavadocs/javadoc.options'
> >
> > * Try:
> > Run with --stacktrace option to get the stack trace. Run with --info or
> > --debug option to get more log output.
> >
> > BUILD FAILED
> >
> > Total time: 50 mins 9.575 secs
> > Build step 'Execute shell' marked build as failure
> > [CHECKSTYLE] Collecting checkstyle analysis files...
> > [CHECKSTYLE] Finding all files that match the pattern
> > **/target/reports/checkstyle/*.xml
> > [CHECKSTYLE] Parsing 14 files in <
> > http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/>
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/target/reports/checkstyle/main.xml
> > >
> > with 2 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/target/reports/checkstyle/main.xml
> > >
> > with 2391 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/target/reports/checkstyle/main.xml
> > >
> > with 2416 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entitymanager/target/reports/checkstyle/main.xml
> > >
> > with 2734 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-envers/target/reports/checkstyle/main.xml
> > >
> > with 2798 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-hikaricp/target/reports/checkstyle/main.xml
> > >
> > with 2801 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-infinispan/target/reports/checkstyle/main.xml
> > >
> > with 3331 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-java8/target/reports/checkstyle/main.xml
> > >
> > with 3334 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-osgi/target/reports/checkstyle/main.xml
> > >
> > with 3346 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-proxool/target/reports/checkstyle/main.xml
> > >
> > with 3347 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-spatial/target/reports/checkstyle/main.xml
> > >
> > with 3357 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-testing/target/reports/checkstyle/main.xml
> > >
> > with 3450 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/hibernate-enhance-maven-plugin/target/reports/checkstyle/main.xml
> > >
> > with 3451 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Successfully parsed file <
> >
> >
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/metamodel-generator/target/reports/checkstyle/main.xml
> > >
> > with 3456 unique warnings and 0 duplicates.
> > [CHECKSTYLE] Computing warning deltas based on reference build #1314
> > [FINDBUGS] Skipping publisher since build result is FAILURE
> > [TASKS] Skipping publisher since build result is FAILURE
> > Recording test results
> > Publishing Javadoc
> > _______________________________________________
> > 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  Tue Jan 26 11:10:33 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 26 Jan 2016 16:10:33 +0000
Subject: [hibernate-dev] Eclipse tools for Hibernate Search
Message-ID: <CAFm4XO2wL87dy7edd74+0k5r0zNj_1gd-wuOpFu+mJVJXcptFw@mail.gmail.com>

Hello all,
I'm thrilled to announce that there is now Eclipse tooling available
to help developers using Hibernate Search.

This was created by Dmitry Bocharov, started this summer as a GSOC
summer of code and still volunteering on it.

Better described in his own words on our blog:
 - http://in.relation.to/2016/01/22/EclipseToolsForHibernateSearch/

Thanks,
Sanne

From steve at hibernate.org  Tue Jan 26 11:14:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 Jan 2016 16:14:47 +0000
Subject: [hibernate-dev] Fwd: Build failed in Jenkins:
 hibernate-orm-master-h2 #1316
In-Reply-To: <CAL00eSQcyM-Qmx5J0Osi4q+D7GMv1Kq_hCmESMgUMRBf2j1nmA@mail.gmail.com>
References: <1829318955.43.1453785257420.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<1683980319.44.1453802940886.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<CAFdSV9varZ78OZm9mhYPHBNMyCXq=voWjhedx-9VK4PBadGi=Q@mail.gmail.com>
	<CA+gWKMCG7JQRpvg5cQvJzDBVgAXWTcqJNZTTcqgf=dpTNJ35GA@mail.gmail.com>
	<CAL00eSQcyM-Qmx5J0Osi4q+D7GMv1Kq_hCmESMgUMRBf2j1nmA@mail.gmail.com>
Message-ID: <CAFdSV9udH_9jc6XeN1Ga7apAWz6PvDr8NMc8UcjBJEtrE5NPZg@mail.gmail.com>

Yes, I just found that too.  But what specifically?  I found it by brute
force lol


On Tue, Jan 26, 2016 at 10:07 AM andrea boriero <dreborier at gmail.com> wrote:

> the failure is caused by the javadoc of
> AvailabeSettings#GLOBALLY_QUOTED_IDENTIFIERS_SKIP_COLUMN_DEFINITIONS
> I'm fixing it
>
> On 26 January 2016 at 15:55, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> I could replicate it on my local machine too:
>>
>> javadoc: error - java.lang.ClassCastException:
>> com.sun.tools.javadoc.MethodDocImpl cannot be cast to
>> com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>> :documentation:aggregateJavadocs FAILED
>>
>>
>> http://stackoverflow.com/questions/44853/why-am-i-getting-a-classcastexception-when-generating-javadocs
>>
>> I'll need to dig into it further
>>
>> Vlad
>>
>> On Tue, Jan 26, 2016 at 5:10 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>> > Anyone know what is up with this Javadoc tool failure in these jobs?
>> We've
>> > had the same failure for the last few builds...
>> >
>> > ---------- Forwarded message ---------
>> > From: Hibernate CI <ci at hibernate.org>
>> > Date: Tue, Jan 26, 2016 at 4:09 AM
>> > Subject: Build failed in Jenkins: hibernate-orm-master-h2 #1316
>> > To: <steve at hibernate.org>, <mih_vlad at yahoo.com>
>> >
>> >
>> > See <http://ci.hibernate.org/job/hibernate-orm-master-h2/1316/changes>
>> >
>> > Changes:
>> >
>> > [mih_vlad] Move User Guide Bootstrap chapter code snippets from extras
>> to
>> > test
>> >
>> > ------------------------------------------
>> > [...truncated 1048 lines...]
>> > FindBugs rule violations were found. See the report at:
>> >
>> >
>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/main.xml
>> > :hibernate-osgi:findbugsTest
>> > FindBugs rule violations were found. See the report at:
>> >
>> >
>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/test.xml
>> > :hibernate-osgi:buildDashboard
>> > :hibernate-proxool:compileJava
>> > Starting AnimalSniffer checks using [java16-1.0.signature] against
>> > [sourceSets.main]
>> > :hibernate-proxool:processResources
>> > :hibernate-proxool:classes
>> > :hibernate-proxool:compileTestJava
>> > :hibernate-proxool:processTestResources
>> > :hibernate-proxool:testClasses
>> > :hibernate-proxool:test
>> > :hibernate-proxool:checkstyleMain
>> > :hibernate-proxool:findbugsMain
>> > FindBugs rule violations were found. See the report at:
>> >
>> >
>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/main.xml
>> > :hibernate-proxool:findbugsTest
>> > FindBugs rule violations were found. See the report at:
>> >
>> >
>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/test.xml
>> > :hibernate-proxool:buildDashboard
>> > :hibernate-spatial:compileJavaNote:
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/src/main/java/org/hibernate/spatial/integration/SpatialService.java
>> > uses or overrides a deprecated API.
>> > Note: Recompile with -Xlint:deprecation for details.
>> > Note: Some input files use unchecked or unsafe operations.
>> > Note: Recompile with -Xlint:unchecked for details.
>> >
>> > Starting AnimalSniffer checks using [java16-1.0.signature] against
>> > [sourceSets.main]
>> > :hibernate-spatial:processResources
>> > :hibernate-spatial:classes
>> > :hibernate-spatial:compileTestJavaNote: Some input files use or
>> override a
>> > deprecated API.
>> > Note: Recompile with -Xlint:deprecation for details.
>> > Note: Some input files use unchecked or unsafe operations.
>> > Note: Recompile with -Xlint:unchecked for details.
>> >
>> > :hibernate-spatial:processTestResources
>> > :hibernate-spatial:testClasses
>> > :hibernate-spatial:test
>> > :hibernate-spatial:checkstyleMain
>> > :hibernate-spatial:findbugsMain
>> > :hibernate-spatial:findbugsTest
>> > FindBugs rule violations were found. See the report at:
>> >
>> >
>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/target/reports/findbugs/test.xml
>> > :hibernate-spatial:buildDashboard
>> > :hibernate-testing:compileTestJava
>> > :hibernate-testing:processTestResources UP-TO-DATE
>> > :hibernate-testing:testClasses
>> > :hibernate-testing:test
>> > :hibernate-testing:checkstyleMain
>> > :hibernate-testing:findbugsMain
>> > FindBugs rule violations were found. See the report at:
>> >
>> >
>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-testing/target/reports/findbugs/main.xml
>> > :hibernate-testing:findbugsTest
>> > :hibernate-testing:buildDashboard
>> > :documentation:check
>> > :hibernate-c3p0:check
>> > :hibernate-core:check
>> > :hibernate-ehcache:check
>> > :hibernate-enhance-maven-plugin:check
>> > :hibernate-entitymanager:check
>> > :hibernate-envers:check
>> > :hibernate-gradle-plugin:check
>> > :hibernate-hikaricp:check
>> > :hibernate-infinispan:check
>> > :hibernate-java8:check
>> > :hibernate-jpamodelgen:check
>> > :hibernate-osgi:check
>> > :hibernate-proxool:check
>> > :hibernate-spatial:check
>> > :hibernate-testing:check
>> > :release:check UP-TO-DATE
>> >
>> >
>> :documentation:aggregateJavadocs/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/exec/internal/AliasResolutionContextImpl.java:174:
>> > warning - Tag @link: can't find
>> #resolveCollectionReferenceAliases(String)
>> > in org.hibernate.loader.plan.exec.internal.AliasResolutionContextImpl
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
>> > warning - Tag @link: reference not found:
>> > Disposition#COLLECTION_INITIALIZER
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
>> > warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
>> > warning - Tag @link: reference not found: Disposition#MIXED
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
>> > warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
>> > warning - Tag @link: reference not found:
>> > Disposition#COLLECTION_INITIALIZER
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
>> > warning - Tag @link: reference not found: Disposition#MIXED
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/spi/BidirectionalEntityReference.java:42:
>> > warning - Tag @link: can't find
>> > getTargetEntityReference()#getQuerySpaceUid() in
>> > org.hibernate.loader.plan.spi.BidirectionalEntityReference
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/tuple/IdentifierProperty.java:41:
>> > warning - @param argument "node" is not a parameter name.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:283:
>> > warning - Tag @link: reference not found: this
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:309:
>> > warning - Tag @link: reference not found: this
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:328:
>> > warning - Tag @link: reference not found: this
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:36:
>> > warning - Tag @link: reference not found: NaturalIdResolutionCache
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
>> > warning - Tag @link: reference not found:
>> > PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
>> > warning - Tag @link: reference not found:
>> > PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/spi/PersistenceContext.java:489:
>> > warning - @return tag has no arguments.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/persister/entity/AbstractEntityPersister.java:2299:
>> > warning - @return tag has no arguments.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
>> > warning - Tag @see:illegal character: "123" in "{@link
>> > #buildSQLExceptionConversionDelegate()}"
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
>> > warning - Tag @see:illegal character: "64" in "{@link
>> > #buildSQLExceptionConversionDelegate()}"
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:2712:
>> > warning - @return tag has no arguments.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/jdbc/spi/JdbcServices.java:28:
>> > warning - @return tag has no arguments.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/PropertyHolder.java:95:
>> > warning - @return tag has no arguments.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/ExternalSessionFactoryConfig.java:25:
>> > warning - Tag @link: reference not found:
>> > org.hibernate.jmx.HibernateService JMX
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/NamingStrategy.java:27:
>> > warning - Tag @link: reference not found:
>> > org.hibernate.cfg.naming.NamingStrategyDelegator
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
>> > warning - Tag @see:illegal character: "123" in "{@link
>> > #nullifyTransientReferencesIfNotAlready}"
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
>> > warning - Tag @see:illegal character: "64" in "{@link
>> > #nullifyTransientReferencesIfNotAlready}"
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
>> > warning - Tag @see:illegal character: "123" in "{@link
>> #makeEntityManaged()
>> > }"
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
>> > warning - Tag @see:illegal character: "64" in "{@link
>> #makeEntityManaged()
>> > }"
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
>> > warning - Tag @see: reference not found: {@link
>> > #nullifyTransientReferencesIfNotAlready}
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
>> > warning - Tag @see: reference not found: {@link #makeEntityManaged() }
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - @propertyDescription is an unknown tag.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - @propertyDescription is an unknown tag.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - @propertyDescription is an unknown tag.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - @propertyDescription is an unknown tag.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - @propertyDescription is an unknown tag.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - @propertyDescription is an unknown tag.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/MapEntryNode.java:34:
>> > warning - Tag @link: reference not found: Map.Entry
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> >
>> >
>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>> > warning - Tags @propertyGetter, @propertySetter and @propertyDescription
>> > can only be used in JavaFX properties getters and setters.
>> > java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl
>> cannot be
>> > cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>> >         at
>> >
>> com.sun.tools.javadoc.DocEnv.getAnnotationTypeElementDoc(DocEnv.java:721)
>> >         at
>> >
>> >
>> com.sun.tools.javadoc.AnnotationTypeDocImpl.elements(AnnotationTypeDocImpl.java:97)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.filter(VisibleMemberMap.java:492)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.getClassMembers(VisibleMemberMap.java:442)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.addMembers(VisibleMemberMap.java:372)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:346)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:351)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.build(VisibleMemberMap.java:341)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.access$100(VisibleMemberMap.java:291)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap.<init>(VisibleMemberMap.java:127)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.<init>(MemberSummaryBuilder.java:82)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.getInstance(MemberSummaryBuilder.java:101)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.builders.BuilderFactory.getMemberSummaryBuilder(BuilderFactory.java:278)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.formats.html.ClassWriterImpl.getNavSummaryLinks(ClassWriterImpl.java:641)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.formats.html.ClassWriterImpl.addSummaryDetailLinks(ClassWriterImpl.java:622)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.formats.html.HtmlDocletWriter.addNavLinks(HtmlDocletWriter.java:560)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.formats.html.ClassWriterImpl.getHeader(ClassWriterImpl.java:165)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:145)
>> >         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>> >         at
>> >
>> >
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >         at java.lang.reflect.Method.invoke(Method.java:497)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.invokeMethod(AbstractBuilder.java:180)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:135)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:120)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:189)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:205)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:189)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:137)
>> >         at
>> >
>> >
>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:82)
>> >         at
>> > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:80)
>> >         at
>> com.sun.tools.doclets.standard.Standard.start(Standard.java:39)
>> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >         at
>> >
>> >
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> >         at
>> >
>> >
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >         at java.lang.reflect.Method.invoke(Method.java:497)
>> >         at
>> > com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
>> >         at
>> > com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
>> >         at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
>> >         at com.sun.tools.javadoc.Start.begin(Start.java:219)
>> >         at com.sun.tools.javadoc.Start.begin(Start.java:205)
>> >         at com.sun.tools.javadoc.Main.execute(Main.java:64)
>> >         at com.sun.tools.javadoc.Main.main(Main.java:54)
>> >
>> > 1 error
>> > 100 warnings
>> > javadoc: error - java.lang.ClassCastException:
>> > com.sun.tools.javadoc.MethodDocImpl cannot be cast to
>> > com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>> > :documentation:aggregateJavadocs FAILED
>> >
>> > FAILURE: Build failed with an exception.
>> >
>> > * What went wrong:
>> > Execution failed for task ':documentation:aggregateJavadocs'.
>> > > Javadoc generation failed. Generated Javadoc options file (useful for
>> > troubleshooting):
>> >
>> >
>> '/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/documentation/target/tmp/aggregateJavadocs/javadoc.options'
>> >
>> > * Try:
>> > Run with --stacktrace option to get the stack trace. Run with --info or
>> > --debug option to get more log output.
>> >
>> > BUILD FAILED
>> >
>> > Total time: 50 mins 9.575 secs
>> > Build step 'Execute shell' marked build as failure
>> > [CHECKSTYLE] Collecting checkstyle analysis files...
>> > [CHECKSTYLE] Finding all files that match the pattern
>> > **/target/reports/checkstyle/*.xml
>> > [CHECKSTYLE] Parsing 14 files in <
>> > http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/>
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/target/reports/checkstyle/main.xml
>> > >
>> > with 2 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/target/reports/checkstyle/main.xml
>> > >
>> > with 2391 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/target/reports/checkstyle/main.xml
>> > >
>> > with 2416 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entitymanager/target/reports/checkstyle/main.xml
>> > >
>> > with 2734 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-envers/target/reports/checkstyle/main.xml
>> > >
>> > with 2798 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-hikaricp/target/reports/checkstyle/main.xml
>> > >
>> > with 2801 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-infinispan/target/reports/checkstyle/main.xml
>> > >
>> > with 3331 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-java8/target/reports/checkstyle/main.xml
>> > >
>> > with 3334 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-osgi/target/reports/checkstyle/main.xml
>> > >
>> > with 3346 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-proxool/target/reports/checkstyle/main.xml
>> > >
>> > with 3347 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-spatial/target/reports/checkstyle/main.xml
>> > >
>> > with 3357 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-testing/target/reports/checkstyle/main.xml
>> > >
>> > with 3450 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/hibernate-enhance-maven-plugin/target/reports/checkstyle/main.xml
>> > >
>> > with 3451 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Successfully parsed file <
>> >
>> >
>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/metamodel-generator/target/reports/checkstyle/main.xml
>> > >
>> > with 3456 unique warnings and 0 duplicates.
>> > [CHECKSTYLE] Computing warning deltas based on reference build #1314
>> > [FINDBUGS] Skipping publisher since build result is FAILURE
>> > [TASKS] Skipping publisher since build result is FAILURE
>> > Recording test results
>> > Publishing Javadoc
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Tue Jan 26 12:48:31 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 Jan 2016 17:48:31 +0000
Subject: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in
	Oracle
In-Reply-To: <7d0a5d1d-3e3e-4b64-bc04-7afe4f71c43c@zmail01.collab.prod.int.phx2.redhat.com>
References: <4E9B2441.2000709@gmail.com>
	<7d0a5d1d-3e3e-4b64-bc04-7afe4f71c43c@zmail01.collab.prod.int.phx2.redhat.com>
Message-ID: <CAFdSV9sQTjvvCnTwis+qipHprg7=FR44GKAx5y9P-Mw4UdpwPg@mail.gmail.com>

This has come up again under HHH-10345[1].

The original request here claims that Oracle have deprecated LONG (
LONGVARCHAR) and LONG RAW (LONGVARBINARY).  It refers to the 9i release
notes as "proof" of that[2].  The 9i release notes do mention LONG
(LONGVARCHAR)
datatype being deprecated.  However, it does not mention LONG RAW.   The
next 2 references it links are from 10g and 11i; both of these do mention
LONG RAW specifically being deprecated.  So LONG was deprecated as of 9i.
It is a bit unclear exactly when LONG RAW was deprecated.

Unfortunately Oracle has issues with both LONG and LOB forms.  In fact the
list of restrictions for LONG and LONG RAW  is incredibly long.  As far as
I can tell newer Oracle releases have alleviated some of the crazier
"limitations" of LOB usage; but its unfortunately been many years since I
have "used Oracle in anger", so I do not really know the complete current
state of its LOB support.

While I personally agree that we should not be retroactively changing our
legacy Oracle-based dialects to map LONGVARCHAR to (N)CLOB and LONGVARBINARY
to BLOB, I do think that is something we want to change moving forward.
Specifically, I wonder if Oracle12cDialect is "foward".  We knew about
these deprecations when Oracle12cDialect was developed and clearly these
types are deprecated prior to Oracle 12c even if exactly when Oracle
deprecated them is a bit murky.  So specifically I wonder if, for 5.1, we
ought to make this change for Oracle12cDialect.  What do y'all think?


[1] - https://hibernate.atlassian.net/browse/HHH-10345
[2] -
http://docs.oracle.com/cd/A91202_01/901_doc/server.901/a90120/ch4_dep.htm#6690



On Mon, Oct 17, 2011 at 6:11 PM Gail Badner <gbadner at redhat.com> wrote:

> There is a discussion about direct binding (fast) and stream binding
> (slow) at [1]. I think it answers Scott's questions. Rather than repeating
> the info here, please take a look at the Oracle documentation (
> http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#autoId18
> ).
>
> After thinking about this more, I think we should keep the Oracle dialects
> as is. Here are my reasons:
> - Hibernate defines the text/image types consistent with how Oracle maps
> LONGVARCHAR/LONGVARBINARY;
> - the bug lies with Oracle;
> - Oracle has effectively deprecated valid SQL data types (LONGVARCHAR and
> LONGVARBINARY);
> - the migration from "text" to "materialized_clob" has already been
> documented since 3.5; "image" is a new type as of 3.6;
> - anyone actually using text/image with LONG/LONGRAW columns may run into
> new migration issues in Hibernate 4.0.0; more testing would need to be done
> to determine the true impact;
> - users can easily create a new dialect making the changes I mentioned
> earlier;
> - this avoids having to make a confusing recommendation (i.e., using
> Oracle11gDialect for accessing an Oracle 10g DB).
>
> Regarding Oracle tests, IMO, the tests using "text" and "image" should be
> disabled. If there is no similar test using clob/blob, it would be a good
> idea to add one.
>
> ----- Original Message -----
> > From: "?ukasz Antoniak" <lukasz.antoniak at gmail.com>
> > To: "Strong Liu" <stliu at hibernate.org>
> > Cc: "Scott Marlow" <smarlow at redhat.com>, "Gail Badner" <
> gbadner at redhat.com>, hibernate-dev at lists.jboss.org
> > Sent: Sunday, October 16, 2011 11:36:49 AM
> > Subject: Re: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in
> Oracle
> >
> > Currently Oracle supports database versions from 10.1 to 11.2 [1].
> > LONG
> > and LONG RAW data types are deprecated since version 8 and 8i
> > (released
> > before September 2000) [2]. Oracle keeps those column types only for
> > backward compatibility [3].
> >
> > I tried the following scenario (Oracle 10gR2):
> > 1. Create schema with "hibernate.hbm2ddl.auto" set to "create". The
> > LONG
> > column is created.
> > 2. Insert some data.
> > 3. Modify Oracle dialect as Gail suggested. Avoid setting
> > "hibernate.hbm2ddl.auto".
> > 4. Insert some data.
> > To my surprise the test actually passed :). However, I think that we
> > cannot guaranty the proper behavior in every situation.
> >
> > As for performance, ImageType is extracted by calling
> > ResultSet.getBytes() method, which fetches all data in one call [4].
> > I
> > don't suppose a major performance difference when data is streamed in
> > another call. oracle.jdbc.driver.LongRawAccessor.getBytes also
> > fetches
> > data by reading the stream.
> >
> > The bug reading LONG column affects JDBC drivers since version
> > 10.2.0.4.
> > I think that we have to choose between:
> > - changing Oracle10gDialect. Make a not about it in migration guide
> > to
> > 4.0 and update "5.2.2. Basic value types" chapter in Hibernate
> > documentation.
> > - introducing Oracle11gDialect. It can sound weird to access Oracle
> > 10g
> > database with Oracle 11g dialect.
> > - disabling execution of Hibernate tests that fail because of this
> > issue
> > with @SkipForDialect (and maybe develop another version of them with
> > CLOBs and BLOBs, @RequiresDialect). Hibernate is written correctly
> > according to "Default Mappings Between SQL Types and Java Types"
> > (referenced earlier by Gail) and this is more Oracle's JDBC
> > implementation issue. This option came to my mind, but it's weird :P.
> >
> > I would vote for the first option.
> >
> > Regards,
> > Lukasz Antoniak
> >
> > [1]
> >
> http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf
> > (page 4)
> > [2]
> >
> http://download.oracle.com/docs/cd/A91202_01/901_doc/server.901/a90120/ch4_dep.htm
> > [3]
> >
> http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm
> > [4] "Getting a LONG RAW Data Column with getBytes"
> >
> http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/jstreams.htm
> >
> > Strong Liu pisze:
> > > I think oracle 11g is the only one supported DB version by oracle,
> > > can we just introduce a new oracle dialect with suggested changes,
> > > and deprecate all other existed oracle dialects? this won't
> > > affects users app
> > >
> > > -----------
> > > Strong Liu <stliu at hibernate.org>
> > > http://hibernate.org
> > > http://github.com/stliu
> > >
> > > On Oct 15, 2011, at 11:14 AM, Scott Marlow wrote:
> > >
> > >> How does this impact existing applications?  Would they have to
> > >> convert
> > >> LONGs to CLOBs (and LONGRAWs to BLOBs) to keep the application
> > >> working?
> > >>
> > >> As far as the advantage of CLOB over TEXT, if you read every
> > >> character,
> > >> which one is really faster?  I would expect TEXT to be a little
> > >> faster,
> > >> since the server side will send the characters before they are
> > >> asked
> > >> for.  By faster, I mean from the application performance point of
> > >> view. :)
> > >>
> > >> Could this be changed in a custom Oracle dialect?   So new
> > >> applications/databases could perhaps use that and existing
> > >> applications
> > >> might use LONGs a bit longer via the existing Oracle dialect.
> > >>
> > >> On 10/14/2011 09:22 PM, Gail Badner wrote:
> > >>> In [1], I am seeing the following type mappings:
> > >>>
> > >>> Column type: LONG ->  java.sql.Types.LONGVARCHAR ->
> > >>>  java.lang.String
> > >>> Column type: LONGRAW ->  java.sql.Types.LONGVARBINARY ->  byte[]
> > >>>
> > >>> org.hibernate.type.TextType is consistent with the mapping for
> > >>> LONG.
> > >>>
> > >>> org.hibernate.type.ImageType is consistent with the mapping for
> > >>> LONGRAW.
> > >>>
> > >>> From this standpoint, the current settings are appropriate.
> > >>>
> > >>> I understand there are restrictions when LONG and LONGRAW are
> > >>> used and I see from your other message that there is Oracle
> > >>> documentation for migrating to CLOB and BLOB.
> > >>>
> > >>> I agree that changing column type registration as follows (for
> > >>> Oracle only) should fix this:
> > >>>           registerColumnType( Types.VARBINARY, 2000, "raw($l)" );
> > >>>           registerColumnType( Types.VARBINARY, "blob" );
> > >>>
> > >>>           registerColumnType( Types.LONGVARCHAR, "clob" );
> > >>>           registerColumnType( Types.LONGVARBINARY, "blob" );
> > >>>
> > >>>           registerColumnType( Types.VARCHAR, 4000, "varchar2($l
> char)" );
> > >>>           registerColumnType( Types.VARCHAR, "clob" );
> > >>>
> > >>> Steve, what do you think? Is it too late to make this change for
> > >>> 4.0.0?
> > >>>
> > >>> [1] Table 11-1 of Oracle? Database JDBC Developer's Guide and
> > >>> Reference, 11g Release 1 (11.1)
> > >>> (
> http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#g1028145
> )
> > >>> [2] Hibernate Core Migration Guide for 3.5
> > >>> (http://community.jboss.org/wiki/HibernateCoreMigrationGuide35)
> > >>> [3] Table 2-10 of Oracle? Database SQL Language Reference
> > >>> 11g Release 1 (11.1)
> > >>> (
> http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elements002.htm#g195937
> )
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "?ukasz Antoniak"<lukasz.antoniak at gmail.com>
> > >>>> To: hibernate-dev at lists.jboss.org
> > >>>> Sent: Thursday, October 13, 2011 12:50:13 PM
> > >>>> Subject: [hibernate-dev] HHH-6726 LONG and LONG RAW column types
> > >>>> in Oracle
> > >>>>
> > >>>> Welcome Community!
> > >>>>
> > >>>> I have just subscribed to the list and wanted to discuss
> > >>>> HHH-6726
> > >>>> JIRA
> > >>>> issue.
> > >>>>
> > >>>> Gail Badner wrote
> > >>>> (
> http://lists.jboss.org/pipermail/hibernate-dev/2011-October/007208.html):
> > >>>> HHH-6726 (Oracle : map TextType to clob and ImageType to blob)
> > >>>> https://hibernate.onjira.com/browse/HHH-6726
> > >>>> There have been a number of issues opened since the change was
> > >>>> made
> > >>>> to
> > >>>> map TextType (LONGVARCHAR) 'long' and ImageType (LONGVARBINARY)
> > >>>> to
> > >>>> 'long
> > >>>> raw'. This change was already documented in the migration notes.
> > >>>> Should
> > >>>> the mapping for Oracle (only) be changed back to clob and blob?
> > >>>>
> > >>>> HHH-6726 is caused by an issue in Oracle JDBC driver (version
> > >>>> 10.2.0.4
> > >>>> and later). This bug appears when LONG or LONG RAW columns are
> > >>>> accessed
> > >>>> not as first or last while processing SQL statement.
> > >>>>
> > >>>> I have discussed the topic of mapping TextType to CLOB and
> > >>>> ImageType
> > >>>> to
> > >>>> BLOB (only in Oracle dialect) with Strong Liu. Reasons for doing
> > >>>> so:
> > >>>> - Oracle allows only one LONG / LONG RAW column per table. This
> > >>>> might
> > >>>> be
> > >>>> the most important from Hibernate's perspective.
> > >>>> - LONG / LONG RAW - up to 2 GB, BLOB / CLOB - up to 4 GB.
> > >>>> - In PL/SQL using LOBs is more efficient (random access to
> > >>>> data).
> > >>>> LONG
> > >>>> only sequential.
> > >>>> - LONG and LONG RAW are deprecated.
> > >>>>
> > >>>> What is your opinion?
> > >>>>
> > >>>> Regards,
> > >>>> Lukasz Antoniak
> > >>>> _______________________________________________
> > >>>> 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 steve at hibernate.org  Tue Jan 26 17:33:59 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 Jan 2016 22:33:59 +0000
Subject: [hibernate-dev] [hibernate-announce] Eclipse tools for
	Hibernate Search
In-Reply-To: <CAFm4XO2wL87dy7edd74+0k5r0zNj_1gd-wuOpFu+mJVJXcptFw@mail.gmail.com>
References: <CAFm4XO2wL87dy7edd74+0k5r0zNj_1gd-wuOpFu+mJVJXcptFw@mail.gmail.com>
Message-ID: <CAFdSV9ufQCVGfN7CcHOdvabtfKm1Qbv-_sN2Ww58PYiFMqvhGA@mail.gmail.com>

Awesome!  Congrats everyone, very exciting!

On Tue, Jan 26, 2016 at 10:11 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hello all,
> I'm thrilled to announce that there is now Eclipse tooling available
> to help developers using Hibernate Search.
>
> This was created by Dmitry Bocharov, started this summer as a GSOC
> summer of code and still volunteering on it.
>
> Better described in his own words on our blog:
>  - http://in.relation.to/2016/01/22/EclipseToolsForHibernateSearch/
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-announce mailing list
> hibernate-announce at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-announce
>

From dreborier at gmail.com  Tue Jan 26 19:07:30 2016
From: dreborier at gmail.com (andrea boriero)
Date: Wed, 27 Jan 2016 00:07:30 +0000
Subject: [hibernate-dev] Fwd: Build failed in Jenkins:
 hibernate-orm-master-h2 #1316
In-Reply-To: <CAFdSV9udH_9jc6XeN1Ga7apAWz6PvDr8NMc8UcjBJEtrE5NPZg@mail.gmail.com>
References: <1829318955.43.1453785257420.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<1683980319.44.1453802940886.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<CAFdSV9varZ78OZm9mhYPHBNMyCXq=voWjhedx-9VK4PBadGi=Q@mail.gmail.com>
	<CA+gWKMCG7JQRpvg5cQvJzDBVgAXWTcqJNZTTcqgf=dpTNJ35GA@mail.gmail.com>
	<CAL00eSQcyM-Qmx5J0Osi4q+D7GMv1Kq_hCmESMgUMRBf2j1nmA@mail.gmail.com>
	<CAFdSV9udH_9jc6XeN1Ga7apAWz6PvDr8NMc8UcjBJEtrE5NPZg@mail.gmail.com>
Message-ID: <CAL00eSTsVcas5-Xwumq700hgZyjO7AbCQUtaU-yH403nDf=xxQ@mail.gmail.com>

the only solution i found is to use
 {@link javax.persistence.Column @Column(columnDefinition="...")}
and {@link javax.persistence.JoinColumn @JoinColumn(columnDefinition="..."}

but I wasn't able to find why it fails with

{@link javax.persistence.Column @Column#columnDefinition()} and  {@link
javax.persistence.JoinColumn#columnDefinition}

really frustrated :(

On 26 January 2016 at 16:14, Steve Ebersole <steve at hibernate.org> wrote:

> Yes, I just found that too.  But what specifically?  I found it by brute
> force lol
>
>
> On Tue, Jan 26, 2016 at 10:07 AM andrea boriero <dreborier at gmail.com>
> wrote:
>
>> the failure is caused by the javadoc of
>> AvailabeSettings#GLOBALLY_QUOTED_IDENTIFIERS_SKIP_COLUMN_DEFINITIONS
>> I'm fixing it
>>
>> On 26 January 2016 at 15:55, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> I could replicate it on my local machine too:
>>>
>>> javadoc: error - java.lang.ClassCastException:
>>> com.sun.tools.javadoc.MethodDocImpl cannot be cast to
>>> com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>>> :documentation:aggregateJavadocs FAILED
>>>
>>>
>>> http://stackoverflow.com/questions/44853/why-am-i-getting-a-classcastexception-when-generating-javadocs
>>>
>>> I'll need to dig into it further
>>>
>>> Vlad
>>>
>>> On Tue, Jan 26, 2016 at 5:10 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>> > Anyone know what is up with this Javadoc tool failure in these jobs?
>>> We've
>>> > had the same failure for the last few builds...
>>> >
>>> > ---------- Forwarded message ---------
>>> > From: Hibernate CI <ci at hibernate.org>
>>> > Date: Tue, Jan 26, 2016 at 4:09 AM
>>> > Subject: Build failed in Jenkins: hibernate-orm-master-h2 #1316
>>> > To: <steve at hibernate.org>, <mih_vlad at yahoo.com>
>>> >
>>> >
>>> > See <http://ci.hibernate.org/job/hibernate-orm-master-h2/1316/changes>
>>> >
>>> > Changes:
>>> >
>>> > [mih_vlad] Move User Guide Bootstrap chapter code snippets from extras
>>> to
>>> > test
>>> >
>>> > ------------------------------------------
>>> > [...truncated 1048 lines...]
>>> > FindBugs rule violations were found. See the report at:
>>> >
>>> >
>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/main.xml
>>> > :hibernate-osgi:findbugsTest
>>> > FindBugs rule violations were found. See the report at:
>>> >
>>> >
>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/test.xml
>>> > :hibernate-osgi:buildDashboard
>>> > :hibernate-proxool:compileJava
>>> > Starting AnimalSniffer checks using [java16-1.0.signature] against
>>> > [sourceSets.main]
>>> > :hibernate-proxool:processResources
>>> > :hibernate-proxool:classes
>>> > :hibernate-proxool:compileTestJava
>>> > :hibernate-proxool:processTestResources
>>> > :hibernate-proxool:testClasses
>>> > :hibernate-proxool:test
>>> > :hibernate-proxool:checkstyleMain
>>> > :hibernate-proxool:findbugsMain
>>> > FindBugs rule violations were found. See the report at:
>>> >
>>> >
>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/main.xml
>>> > :hibernate-proxool:findbugsTest
>>> > FindBugs rule violations were found. See the report at:
>>> >
>>> >
>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/test.xml
>>> > :hibernate-proxool:buildDashboard
>>> > :hibernate-spatial:compileJavaNote:
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/src/main/java/org/hibernate/spatial/integration/SpatialService.java
>>> > uses or overrides a deprecated API.
>>> > Note: Recompile with -Xlint:deprecation for details.
>>> > Note: Some input files use unchecked or unsafe operations.
>>> > Note: Recompile with -Xlint:unchecked for details.
>>> >
>>> > Starting AnimalSniffer checks using [java16-1.0.signature] against
>>> > [sourceSets.main]
>>> > :hibernate-spatial:processResources
>>> > :hibernate-spatial:classes
>>> > :hibernate-spatial:compileTestJavaNote: Some input files use or
>>> override a
>>> > deprecated API.
>>> > Note: Recompile with -Xlint:deprecation for details.
>>> > Note: Some input files use unchecked or unsafe operations.
>>> > Note: Recompile with -Xlint:unchecked for details.
>>> >
>>> > :hibernate-spatial:processTestResources
>>> > :hibernate-spatial:testClasses
>>> > :hibernate-spatial:test
>>> > :hibernate-spatial:checkstyleMain
>>> > :hibernate-spatial:findbugsMain
>>> > :hibernate-spatial:findbugsTest
>>> > FindBugs rule violations were found. See the report at:
>>> >
>>> >
>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/target/reports/findbugs/test.xml
>>> > :hibernate-spatial:buildDashboard
>>> > :hibernate-testing:compileTestJava
>>> > :hibernate-testing:processTestResources UP-TO-DATE
>>> > :hibernate-testing:testClasses
>>> > :hibernate-testing:test
>>> > :hibernate-testing:checkstyleMain
>>> > :hibernate-testing:findbugsMain
>>> > FindBugs rule violations were found. See the report at:
>>> >
>>> >
>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-testing/target/reports/findbugs/main.xml
>>> > :hibernate-testing:findbugsTest
>>> > :hibernate-testing:buildDashboard
>>> > :documentation:check
>>> > :hibernate-c3p0:check
>>> > :hibernate-core:check
>>> > :hibernate-ehcache:check
>>> > :hibernate-enhance-maven-plugin:check
>>> > :hibernate-entitymanager:check
>>> > :hibernate-envers:check
>>> > :hibernate-gradle-plugin:check
>>> > :hibernate-hikaricp:check
>>> > :hibernate-infinispan:check
>>> > :hibernate-java8:check
>>> > :hibernate-jpamodelgen:check
>>> > :hibernate-osgi:check
>>> > :hibernate-proxool:check
>>> > :hibernate-spatial:check
>>> > :hibernate-testing:check
>>> > :release:check UP-TO-DATE
>>> >
>>> >
>>> :documentation:aggregateJavadocs/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/exec/internal/AliasResolutionContextImpl.java:174:
>>> > warning - Tag @link: can't find
>>> #resolveCollectionReferenceAliases(String)
>>> > in org.hibernate.loader.plan.exec.internal.AliasResolutionContextImpl
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
>>> > warning - Tag @link: reference not found:
>>> > Disposition#COLLECTION_INITIALIZER
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
>>> > warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
>>> > warning - Tag @link: reference not found: Disposition#MIXED
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
>>> > warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
>>> > warning - Tag @link: reference not found:
>>> > Disposition#COLLECTION_INITIALIZER
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
>>> > warning - Tag @link: reference not found: Disposition#MIXED
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/spi/BidirectionalEntityReference.java:42:
>>> > warning - Tag @link: can't find
>>> > getTargetEntityReference()#getQuerySpaceUid() in
>>> > org.hibernate.loader.plan.spi.BidirectionalEntityReference
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/tuple/IdentifierProperty.java:41:
>>> > warning - @param argument "node" is not a parameter name.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:283:
>>> > warning - Tag @link: reference not found: this
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:309:
>>> > warning - Tag @link: reference not found: this
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:328:
>>> > warning - Tag @link: reference not found: this
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:36:
>>> > warning - Tag @link: reference not found: NaturalIdResolutionCache
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
>>> > warning - Tag @link: reference not found:
>>> > PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
>>> > warning - Tag @link: reference not found:
>>> > PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/spi/PersistenceContext.java:489:
>>> > warning - @return tag has no arguments.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/persister/entity/AbstractEntityPersister.java:2299:
>>> > warning - @return tag has no arguments.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
>>> > warning - Tag @see:illegal character: "123" in "{@link
>>> > #buildSQLExceptionConversionDelegate()}"
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
>>> > warning - Tag @see:illegal character: "64" in "{@link
>>> > #buildSQLExceptionConversionDelegate()}"
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:2712:
>>> > warning - @return tag has no arguments.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/jdbc/spi/JdbcServices.java:28:
>>> > warning - @return tag has no arguments.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/PropertyHolder.java:95:
>>> > warning - @return tag has no arguments.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/ExternalSessionFactoryConfig.java:25:
>>> > warning - Tag @link: reference not found:
>>> > org.hibernate.jmx.HibernateService JMX
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/NamingStrategy.java:27:
>>> > warning - Tag @link: reference not found:
>>> > org.hibernate.cfg.naming.NamingStrategyDelegator
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
>>> > warning - Tag @see:illegal character: "123" in "{@link
>>> > #nullifyTransientReferencesIfNotAlready}"
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
>>> > warning - Tag @see:illegal character: "64" in "{@link
>>> > #nullifyTransientReferencesIfNotAlready}"
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
>>> > warning - Tag @see:illegal character: "123" in "{@link
>>> #makeEntityManaged()
>>> > }"
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
>>> > warning - Tag @see:illegal character: "64" in "{@link
>>> #makeEntityManaged()
>>> > }"
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
>>> > warning - Tag @see: reference not found: {@link
>>> > #nullifyTransientReferencesIfNotAlready}
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
>>> > warning - Tag @see: reference not found: {@link #makeEntityManaged() }
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - @propertyDescription is an unknown tag.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - @propertyDescription is an unknown tag.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - @propertyDescription is an unknown tag.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - @propertyDescription is an unknown tag.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - @propertyDescription is an unknown tag.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - @propertyDescription is an unknown tag.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/MapEntryNode.java:34:
>>> > warning - Tag @link: reference not found: Map.Entry
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> >
>>> >
>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>> > warning - Tags @propertyGetter, @propertySetter and
>>> @propertyDescription
>>> > can only be used in JavaFX properties getters and setters.
>>> > java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl
>>> cannot be
>>> > cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>>> >         at
>>> >
>>> com.sun.tools.javadoc.DocEnv.getAnnotationTypeElementDoc(DocEnv.java:721)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.javadoc.AnnotationTypeDocImpl.elements(AnnotationTypeDocImpl.java:97)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.filter(VisibleMemberMap.java:492)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.getClassMembers(VisibleMemberMap.java:442)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.addMembers(VisibleMemberMap.java:372)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:346)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:351)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.build(VisibleMemberMap.java:341)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.access$100(VisibleMemberMap.java:291)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap.<init>(VisibleMemberMap.java:127)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.<init>(MemberSummaryBuilder.java:82)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.getInstance(MemberSummaryBuilder.java:101)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.builders.BuilderFactory.getMemberSummaryBuilder(BuilderFactory.java:278)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.formats.html.ClassWriterImpl.getNavSummaryLinks(ClassWriterImpl.java:641)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.formats.html.ClassWriterImpl.addSummaryDetailLinks(ClassWriterImpl.java:622)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.formats.html.HtmlDocletWriter.addNavLinks(HtmlDocletWriter.java:560)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.formats.html.ClassWriterImpl.getHeader(ClassWriterImpl.java:165)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:145)
>>> >         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>>> >         at
>>> >
>>> >
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> >         at java.lang.reflect.Method.invoke(Method.java:497)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.invokeMethod(AbstractBuilder.java:180)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:135)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:120)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:189)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:205)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:189)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:137)
>>> >         at
>>> >
>>> >
>>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:82)
>>> >         at
>>> > com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:80)
>>> >         at
>>> com.sun.tools.doclets.standard.Standard.start(Standard.java:39)
>>> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> >         at
>>> >
>>> >
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>> >         at
>>> >
>>> >
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> >         at java.lang.reflect.Method.invoke(Method.java:497)
>>> >         at
>>> > com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
>>> >         at
>>> > com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
>>> >         at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
>>> >         at com.sun.tools.javadoc.Start.begin(Start.java:219)
>>> >         at com.sun.tools.javadoc.Start.begin(Start.java:205)
>>> >         at com.sun.tools.javadoc.Main.execute(Main.java:64)
>>> >         at com.sun.tools.javadoc.Main.main(Main.java:54)
>>> >
>>> > 1 error
>>> > 100 warnings
>>> > javadoc: error - java.lang.ClassCastException:
>>> > com.sun.tools.javadoc.MethodDocImpl cannot be cast to
>>> > com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>>> > :documentation:aggregateJavadocs FAILED
>>> >
>>> > FAILURE: Build failed with an exception.
>>> >
>>> > * What went wrong:
>>> > Execution failed for task ':documentation:aggregateJavadocs'.
>>> > > Javadoc generation failed. Generated Javadoc options file (useful for
>>> > troubleshooting):
>>> >
>>> >
>>> '/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/documentation/target/tmp/aggregateJavadocs/javadoc.options'
>>> >
>>> > * Try:
>>> > Run with --stacktrace option to get the stack trace. Run with --info or
>>> > --debug option to get more log output.
>>> >
>>> > BUILD FAILED
>>> >
>>> > Total time: 50 mins 9.575 secs
>>> > Build step 'Execute shell' marked build as failure
>>> > [CHECKSTYLE] Collecting checkstyle analysis files...
>>> > [CHECKSTYLE] Finding all files that match the pattern
>>> > **/target/reports/checkstyle/*.xml
>>> > [CHECKSTYLE] Parsing 14 files in <
>>> > http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/>
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/target/reports/checkstyle/main.xml
>>> > >
>>> > with 2 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/target/reports/checkstyle/main.xml
>>> > >
>>> > with 2391 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/target/reports/checkstyle/main.xml
>>> > >
>>> > with 2416 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entitymanager/target/reports/checkstyle/main.xml
>>> > >
>>> > with 2734 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-envers/target/reports/checkstyle/main.xml
>>> > >
>>> > with 2798 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-hikaricp/target/reports/checkstyle/main.xml
>>> > >
>>> > with 2801 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-infinispan/target/reports/checkstyle/main.xml
>>> > >
>>> > with 3331 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-java8/target/reports/checkstyle/main.xml
>>> > >
>>> > with 3334 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-osgi/target/reports/checkstyle/main.xml
>>> > >
>>> > with 3346 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-proxool/target/reports/checkstyle/main.xml
>>> > >
>>> > with 3347 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-spatial/target/reports/checkstyle/main.xml
>>> > >
>>> > with 3357 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-testing/target/reports/checkstyle/main.xml
>>> > >
>>> > with 3450 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/hibernate-enhance-maven-plugin/target/reports/checkstyle/main.xml
>>> > >
>>> > with 3451 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Successfully parsed file <
>>> >
>>> >
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/metamodel-generator/target/reports/checkstyle/main.xml
>>> > >
>>> > with 3456 unique warnings and 0 duplicates.
>>> > [CHECKSTYLE] Computing warning deltas based on reference build #1314
>>> > [FINDBUGS] Skipping publisher since build result is FAILURE
>>> > [TASKS] Skipping publisher since build result is FAILURE
>>> > Recording test results
>>> > Publishing Javadoc
>>> > _______________________________________________
>>> > 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 smreddy2004 at gmail.com  Wed Jan 27 00:01:36 2016
From: smreddy2004 at gmail.com (Madhusudana Reddy Sunnapu)
Date: Wed, 27 Jan 2016 10:31:36 +0530
Subject: [hibernate-dev] Configuration to support batching (or sorting) of
	DELETE statements efficiently
Message-ID: <CAHWSuP-o7fu45AZNF7oeaA-90bWOj_U-z31JRW49ufLHATm3SQ@mail.gmail.com>

Hi,

Hibernate provides simple configuration properties to enable batch inserts
and updates using "hibernate.order_inserts" and "hibernate.order_updates"
respectively. These setting allow hibernate to sort the insert and update
statements and process them in batches efficiently.

But we don't have such a configuration to sort or batch delete statements
efficiently. Especially with CascadeType.DELETE we can see that delete
statements are not batched effectively and could result in extra network
calls to the database for deletion.(Refer:
http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/
)

So I am thinking wouldn't it be a good feature to have hibernate support
similar configuration, say "hibernate.order_deletes", to enable batch
deletes similar to updates and inserts.

Cheers,
Madhu.

From mihalcea.vlad at gmail.com  Wed Jan 27 01:03:45 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 27 Jan 2016 08:03:45 +0200
Subject: [hibernate-dev] Fwd: Build failed in Jenkins:
 hibernate-orm-master-h2 #1316
In-Reply-To: <CAL00eSTsVcas5-Xwumq700hgZyjO7AbCQUtaU-yH403nDf=xxQ@mail.gmail.com>
References: <1829318955.43.1453785257420.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<1683980319.44.1453802940886.JavaMail.jenkins@ip-172-30-1-248.ec2.internal>
	<CAFdSV9varZ78OZm9mhYPHBNMyCXq=voWjhedx-9VK4PBadGi=Q@mail.gmail.com>
	<CA+gWKMCG7JQRpvg5cQvJzDBVgAXWTcqJNZTTcqgf=dpTNJ35GA@mail.gmail.com>
	<CAL00eSQcyM-Qmx5J0Osi4q+D7GMv1Kq_hCmESMgUMRBf2j1nmA@mail.gmail.com>
	<CAFdSV9udH_9jc6XeN1Ga7apAWz6PvDr8NMc8UcjBJEtrE5NPZg@mail.gmail.com>
	<CAL00eSTsVcas5-Xwumq700hgZyjO7AbCQUtaU-yH403nDf=xxQ@mail.gmail.com>
Message-ID: <CA+gWKMDnjtFByGtdsUB4H5WVxtTgiuw2NE+-7bBXm-amMwVqjw@mail.gmail.com>

I think it's a Java bug because the same Javadoc entry is found in the
org.hibernate.engine.jdbc.env.spi.IdentifierHelper interface:

/**
 * Intended only for use in handling quoting requirements for {@code
column-definition}
 * as defined by {@link javax.persistence.Column#columnDefinition()},
 * {@link javax.persistence.JoinColumn#columnDefinition}, etc.  This
method should not
 * be called in any other scenario.
 * <p/>

I tried it with JDK 1.8 versions 31, 65 and 71 and it still fails, and
the only workaround is to use code instead of link:

{@code javax.persistence.Column#columnDefinition()}

Vlad


On Wed, Jan 27, 2016 at 2:07 AM, andrea boriero <dreborier at gmail.com> wrote:

> the only solution i found is to use
>  {@link javax.persistence.Column @Column(columnDefinition="...")}
> and {@link javax.persistence.JoinColumn @JoinColumn(columnDefinition="..."}
>
> but I wasn't able to find why it fails with
>
> {@link javax.persistence.Column @Column#columnDefinition()} and  {@link
> javax.persistence.JoinColumn#columnDefinition}
>
> really frustrated :(
>
> On 26 January 2016 at 16:14, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Yes, I just found that too.  But what specifically?  I found it by brute
>> force lol
>>
>>
>> On Tue, Jan 26, 2016 at 10:07 AM andrea boriero <dreborier at gmail.com>
>> wrote:
>>
>>> the failure is caused by the javadoc of
>>> AvailabeSettings#GLOBALLY_QUOTED_IDENTIFIERS_SKIP_COLUMN_DEFINITIONS
>>> I'm fixing it
>>>
>>> On 26 January 2016 at 15:55, Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> I could replicate it on my local machine too:
>>>>
>>>> javadoc: error - java.lang.ClassCastException:
>>>> com.sun.tools.javadoc.MethodDocImpl cannot be cast to
>>>> com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>>>> :documentation:aggregateJavadocs FAILED
>>>>
>>>>
>>>> http://stackoverflow.com/questions/44853/why-am-i-getting-a-classcastexception-when-generating-javadocs
>>>>
>>>> I'll need to dig into it further
>>>>
>>>> Vlad
>>>>
>>>> On Tue, Jan 26, 2016 at 5:10 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>> > Anyone know what is up with this Javadoc tool failure in these jobs?
>>>> We've
>>>> > had the same failure for the last few builds...
>>>> >
>>>> > ---------- Forwarded message ---------
>>>> > From: Hibernate CI <ci at hibernate.org>
>>>> > Date: Tue, Jan 26, 2016 at 4:09 AM
>>>> > Subject: Build failed in Jenkins: hibernate-orm-master-h2 #1316
>>>> > To: <steve at hibernate.org>, <mih_vlad at yahoo.com>
>>>> >
>>>> >
>>>> > See <http://ci.hibernate.org/job/hibernate-orm-master-h2/1316/changes
>>>> >
>>>> >
>>>> > Changes:
>>>> >
>>>> > [mih_vlad] Move User Guide Bootstrap chapter code snippets from
>>>> extras to
>>>> > test
>>>> >
>>>> > ------------------------------------------
>>>> > [...truncated 1048 lines...]
>>>> > FindBugs rule violations were found. See the report at:
>>>> >
>>>> >
>>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/main.xml
>>>> > :hibernate-osgi:findbugsTest
>>>> > FindBugs rule violations were found. See the report at:
>>>> >
>>>> >
>>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-osgi/target/reports/findbugs/test.xml
>>>> > :hibernate-osgi:buildDashboard
>>>> > :hibernate-proxool:compileJava
>>>> > Starting AnimalSniffer checks using [java16-1.0.signature] against
>>>> > [sourceSets.main]
>>>> > :hibernate-proxool:processResources
>>>> > :hibernate-proxool:classes
>>>> > :hibernate-proxool:compileTestJava
>>>> > :hibernate-proxool:processTestResources
>>>> > :hibernate-proxool:testClasses
>>>> > :hibernate-proxool:test
>>>> > :hibernate-proxool:checkstyleMain
>>>> > :hibernate-proxool:findbugsMain
>>>> > FindBugs rule violations were found. See the report at:
>>>> >
>>>> >
>>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/main.xml
>>>> > :hibernate-proxool:findbugsTest
>>>> > FindBugs rule violations were found. See the report at:
>>>> >
>>>> >
>>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-proxool/target/reports/findbugs/test.xml
>>>> > :hibernate-proxool:buildDashboard
>>>> > :hibernate-spatial:compileJavaNote:
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/src/main/java/org/hibernate/spatial/integration/SpatialService.java
>>>> > uses or overrides a deprecated API.
>>>> > Note: Recompile with -Xlint:deprecation for details.
>>>> > Note: Some input files use unchecked or unsafe operations.
>>>> > Note: Recompile with -Xlint:unchecked for details.
>>>> >
>>>> > Starting AnimalSniffer checks using [java16-1.0.signature] against
>>>> > [sourceSets.main]
>>>> > :hibernate-spatial:processResources
>>>> > :hibernate-spatial:classes
>>>> > :hibernate-spatial:compileTestJavaNote: Some input files use or
>>>> override a
>>>> > deprecated API.
>>>> > Note: Recompile with -Xlint:deprecation for details.
>>>> > Note: Some input files use unchecked or unsafe operations.
>>>> > Note: Recompile with -Xlint:unchecked for details.
>>>> >
>>>> > :hibernate-spatial:processTestResources
>>>> > :hibernate-spatial:testClasses
>>>> > :hibernate-spatial:test
>>>> > :hibernate-spatial:checkstyleMain
>>>> > :hibernate-spatial:findbugsMain
>>>> > :hibernate-spatial:findbugsTest
>>>> > FindBugs rule violations were found. See the report at:
>>>> >
>>>> >
>>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-spatial/target/reports/findbugs/test.xml
>>>> > :hibernate-spatial:buildDashboard
>>>> > :hibernate-testing:compileTestJava
>>>> > :hibernate-testing:processTestResources UP-TO-DATE
>>>> > :hibernate-testing:testClasses
>>>> > :hibernate-testing:test
>>>> > :hibernate-testing:checkstyleMain
>>>> > :hibernate-testing:findbugsMain
>>>> > FindBugs rule violations were found. See the report at:
>>>> >
>>>> >
>>>> file:///mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-testing/target/reports/findbugs/main.xml
>>>> > :hibernate-testing:findbugsTest
>>>> > :hibernate-testing:buildDashboard
>>>> > :documentation:check
>>>> > :hibernate-c3p0:check
>>>> > :hibernate-core:check
>>>> > :hibernate-ehcache:check
>>>> > :hibernate-enhance-maven-plugin:check
>>>> > :hibernate-entitymanager:check
>>>> > :hibernate-envers:check
>>>> > :hibernate-gradle-plugin:check
>>>> > :hibernate-hikaricp:check
>>>> > :hibernate-infinispan:check
>>>> > :hibernate-java8:check
>>>> > :hibernate-jpamodelgen:check
>>>> > :hibernate-osgi:check
>>>> > :hibernate-proxool:check
>>>> > :hibernate-spatial:check
>>>> > :hibernate-testing:check
>>>> > :release:check UP-TO-DATE
>>>> >
>>>> >
>>>> :documentation:aggregateJavadocs/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/exec/internal/AliasResolutionContextImpl.java:174:
>>>> > warning - Tag @link: can't find
>>>> #resolveCollectionReferenceAliases(String)
>>>> > in org.hibernate.loader.plan.exec.internal.AliasResolutionContextImpl
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
>>>> > warning - Tag @link: reference not found:
>>>> > Disposition#COLLECTION_INITIALIZER
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
>>>> > warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
>>>> > warning - Tag @link: reference not found: Disposition#MIXED
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:46:
>>>> > warning - Tag @link: reference not found: Disposition#ENTITY_LOADER
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:58:
>>>> > warning - Tag @link: reference not found:
>>>> > Disposition#COLLECTION_INITIALIZER
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/build/internal/LoadPlanImpl.java:76:
>>>> > warning - Tag @link: reference not found: Disposition#MIXED
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/loader/plan/spi/BidirectionalEntityReference.java:42:
>>>> > warning - Tag @link: can't find
>>>> > getTargetEntityReference()#getQuerySpaceUid() in
>>>> > org.hibernate.loader.plan.spi.BidirectionalEntityReference
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/tuple/IdentifierProperty.java:41:
>>>> > warning - @param argument "node" is not a parameter name.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:283:
>>>> > warning - Tag @link: reference not found: this
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:309:
>>>> > warning - Tag @link: reference not found: this
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/JoinSequence.java:328:
>>>> > warning - Tag @link: reference not found: this
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:36:
>>>> > warning - Tag @link: reference not found: NaturalIdResolutionCache
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
>>>> > warning - Tag @link: reference not found:
>>>> > PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/internal/NaturalIdXrefDelegate.java:205:
>>>> > warning - Tag @link: reference not found:
>>>> > PersistenceContext.NaturalIdHelper#INVALID_NATURAL_ID_REFERENCE
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/spi/PersistenceContext.java:489:
>>>> > warning - @return tag has no arguments.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/persister/entity/AbstractEntityPersister.java:2299:
>>>> > warning - @return tag has no arguments.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
>>>> > warning - Tag @see:illegal character: "123" in "{@link
>>>> > #buildSQLExceptionConversionDelegate()}"
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:1578:
>>>> > warning - Tag @see:illegal character: "64" in "{@link
>>>> > #buildSQLExceptionConversionDelegate()}"
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/dialect/Dialect.java:2712:
>>>> > warning - @return tag has no arguments.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/engine/jdbc/spi/JdbcServices.java:28:
>>>> > warning - @return tag has no arguments.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/PropertyHolder.java:95:
>>>> > warning - @return tag has no arguments.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/ExternalSessionFactoryConfig.java:25:
>>>> > warning - Tag @link: reference not found:
>>>> > org.hibernate.jmx.HibernateService JMX
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/cfg/NamingStrategy.java:27:
>>>> > warning - Tag @link: reference not found:
>>>> > org.hibernate.cfg.naming.NamingStrategyDelegator
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
>>>> > warning - Tag @see:illegal character: "123" in "{@link
>>>> > #nullifyTransientReferencesIfNotAlready}"
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
>>>> > warning - Tag @see:illegal character: "64" in "{@link
>>>> > #nullifyTransientReferencesIfNotAlready}"
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
>>>> > warning - Tag @see:illegal character: "123" in "{@link
>>>> #makeEntityManaged()
>>>> > }"
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
>>>> > warning - Tag @see:illegal character: "64" in "{@link
>>>> #makeEntityManaged()
>>>> > }"
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:72:
>>>> > warning - Tag @see: reference not found: {@link
>>>> > #nullifyTransientReferencesIfNotAlready}
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/action/internal/AbstractEntityInsertAction.java:111:
>>>> > warning - Tag @see: reference not found: {@link #makeEntityManaged() }
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - @propertyDescription is an unknown tag.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - @propertyDescription is an unknown tag.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - @propertyDescription is an unknown tag.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - @propertyDescription is an unknown tag.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - @propertyDescription is an unknown tag.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - @propertyDescription is an unknown tag.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/MapEntryNode.java:34:
>>>> > warning - Tag @link: reference not found: Map.Entry
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:321:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:668:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> >
>>>> >
>>>> /mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/hibernate-core/src/main/java/org/hibernate/hql/internal/ast/tree/FromElement.java:672:
>>>> > warning - Tags @propertyGetter, @propertySetter and
>>>> @propertyDescription
>>>> > can only be used in JavaFX properties getters and setters.
>>>> > java.lang.ClassCastException: com.sun.tools.javadoc.MethodDocImpl
>>>> cannot be
>>>> > cast to com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>>>> >         at
>>>> >
>>>> com.sun.tools.javadoc.DocEnv.getAnnotationTypeElementDoc(DocEnv.java:721)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.javadoc.AnnotationTypeDocImpl.elements(AnnotationTypeDocImpl.java:97)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.filter(VisibleMemberMap.java:492)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.getClassMembers(VisibleMemberMap.java:442)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.addMembers(VisibleMemberMap.java:372)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:346)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.mapClass(VisibleMemberMap.java:351)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.build(VisibleMemberMap.java:341)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap$ClassMembers.access$100(VisibleMemberMap.java:291)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.util.VisibleMemberMap.<init>(VisibleMemberMap.java:127)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.<init>(MemberSummaryBuilder.java:82)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.builders.MemberSummaryBuilder.getInstance(MemberSummaryBuilder.java:101)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.builders.BuilderFactory.getMemberSummaryBuilder(BuilderFactory.java:278)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.formats.html.ClassWriterImpl.getNavSummaryLinks(ClassWriterImpl.java:641)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.formats.html.ClassWriterImpl.addSummaryDetailLinks(ClassWriterImpl.java:622)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.formats.html.HtmlDocletWriter.addNavLinks(HtmlDocletWriter.java:560)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.formats.html.ClassWriterImpl.getHeader(ClassWriterImpl.java:165)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.buildClassDoc(ClassBuilder.java:145)
>>>> >         at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
>>>> >         at
>>>> >
>>>> >
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> >         at java.lang.reflect.Method.invoke(Method.java:497)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.invokeMethod(AbstractBuilder.java:180)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.builders.AbstractBuilder.build(AbstractBuilder.java:135)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.builders.ClassBuilder.build(ClassBuilder.java:120)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.formats.html.HtmlDoclet.generateClassFiles(HtmlDoclet.java:189)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:205)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.generateClassFiles(AbstractDoclet.java:189)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.startGeneration(AbstractDoclet.java:137)
>>>> >         at
>>>> >
>>>> >
>>>> com.sun.tools.doclets.internal.toolkit.AbstractDoclet.start(AbstractDoclet.java:82)
>>>> >         at
>>>> >
>>>> com.sun.tools.doclets.formats.html.HtmlDoclet.start(HtmlDoclet.java:80)
>>>> >         at
>>>> com.sun.tools.doclets.standard.Standard.start(Standard.java:39)
>>>> >         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>> >         at
>>>> >
>>>> >
>>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>>> >         at
>>>> >
>>>> >
>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>>> >         at java.lang.reflect.Method.invoke(Method.java:497)
>>>> >         at
>>>> > com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310)
>>>> >         at
>>>> > com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189)
>>>> >         at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366)
>>>> >         at com.sun.tools.javadoc.Start.begin(Start.java:219)
>>>> >         at com.sun.tools.javadoc.Start.begin(Start.java:205)
>>>> >         at com.sun.tools.javadoc.Main.execute(Main.java:64)
>>>> >         at com.sun.tools.javadoc.Main.main(Main.java:54)
>>>> >
>>>> > 1 error
>>>> > 100 warnings
>>>> > javadoc: error - java.lang.ClassCastException:
>>>> > com.sun.tools.javadoc.MethodDocImpl cannot be cast to
>>>> > com.sun.tools.javadoc.AnnotationTypeElementDocImpl
>>>> > :documentation:aggregateJavadocs FAILED
>>>> >
>>>> > FAILURE: Build failed with an exception.
>>>> >
>>>> > * What went wrong:
>>>> > Execution failed for task ':documentation:aggregateJavadocs'.
>>>> > > Javadoc generation failed. Generated Javadoc options file (useful
>>>> for
>>>> > troubleshooting):
>>>> >
>>>> >
>>>> '/mnt/jenkins-workdir/workspace/hibernate-orm-master-h2/documentation/target/tmp/aggregateJavadocs/javadoc.options'
>>>> >
>>>> > * Try:
>>>> > Run with --stacktrace option to get the stack trace. Run with --info
>>>> or
>>>> > --debug option to get more log output.
>>>> >
>>>> > BUILD FAILED
>>>> >
>>>> > Total time: 50 mins 9.575 secs
>>>> > Build step 'Execute shell' marked build as failure
>>>> > [CHECKSTYLE] Collecting checkstyle analysis files...
>>>> > [CHECKSTYLE] Finding all files that match the pattern
>>>> > **/target/reports/checkstyle/*.xml
>>>> > [CHECKSTYLE] Parsing 14 files in <
>>>> > http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/>
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 2 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 2391 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 2416 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entitymanager/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 2734 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-envers/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 2798 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-hikaricp/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 2801 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-infinispan/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 3331 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-java8/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 3334 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-osgi/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 3346 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-proxool/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 3347 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-spatial/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 3357 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-testing/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 3450 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/hibernate-enhance-maven-plugin/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 3451 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Successfully parsed file <
>>>> >
>>>> >
>>>> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/metamodel-generator/target/reports/checkstyle/main.xml
>>>> > >
>>>> > with 3456 unique warnings and 0 duplicates.
>>>> > [CHECKSTYLE] Computing warning deltas based on reference build #1314
>>>> > [FINDBUGS] Skipping publisher since build result is FAILURE
>>>> > [TASKS] Skipping publisher since build result is FAILURE
>>>> > Recording test results
>>>> > Publishing Javadoc
>>>> > _______________________________________________
>>>> > 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 mihalcea.vlad at gmail.com  Wed Jan 27 01:43:08 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 27 Jan 2016 08:43:08 +0200
Subject: [hibernate-dev] Configuration to support batching (or sorting)
 of DELETE statements efficiently
In-Reply-To: <CAHWSuP-o7fu45AZNF7oeaA-90bWOj_U-z31JRW49ufLHATm3SQ@mail.gmail.com>
References: <CAHWSuP-o7fu45AZNF7oeaA-90bWOj_U-z31JRW49ufLHATm3SQ@mail.gmail.com>
Message-ID: <CA+gWKMB8VD3DBYRAJG+YBfZaARvS+H_TNcB-8ZcC3r_B_cZoNA@mail.gmail.com>

This must be done like insert but in reverse order. With inserts, we need
to add parents first and children after, because of the foreign key
constraints.
For delete, we need to group children first and delete them prior to
deleting parents.

Is there something that prevents us from implementing this feature?

Vlad

On Wed, Jan 27, 2016 at 7:01 AM, Madhusudana Reddy Sunnapu <
smreddy2004 at gmail.com> wrote:

> Hi,
>
> Hibernate provides simple configuration properties to enable batch inserts
> and updates using "hibernate.order_inserts" and "hibernate.order_updates"
> respectively. These setting allow hibernate to sort the insert and update
> statements and process them in batches efficiently.
>
> But we don't have such a configuration to sort or batch delete statements
> efficiently. Especially with CascadeType.DELETE we can see that delete
> statements are not batched effectively and could result in extra network
> calls to the database for deletion.(Refer:
>
> http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/
> )
>
> So I am thinking wouldn't it be a good feature to have hibernate support
> similar configuration, say "hibernate.order_deletes", to enable batch
> deletes similar to updates and inserts.
>
> Cheers,
> Madhu.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Wed Jan 27 04:45:56 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 27 Jan 2016 10:45:56 +0100
Subject: [hibernate-dev] Friends with Java 9 - Hibernate Validator
	5.2.3.Final is out
Message-ID: <CADGJaX8cQb+TGOfrLsw0G=o-OkV3Oe+zY1XUiCjAORL1i_evYw@mail.gmail.com>

Hi,

It's my pleasure to announce the release of Hibernate Validator
5.2.3.Final. This fixes several bugs, most notably it allows to use HV
on Java 9. Check out the announcement for the details [1].

Cheers,

--Gunnar

[1] http://in.relation.to/2016/01/27/friends-with-java-9-hibernate-validator-523-out/

From steve at hibernate.org  Wed Jan 27 11:54:51 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 Jan 2016 16:54:51 +0000
Subject: [hibernate-dev] Configuration to support batching (or sorting)
 of DELETE statements efficiently
In-Reply-To: <CA+gWKMB8VD3DBYRAJG+YBfZaARvS+H_TNcB-8ZcC3r_B_cZoNA@mail.gmail.com>
References: <CAHWSuP-o7fu45AZNF7oeaA-90bWOj_U-z31JRW49ufLHATm3SQ@mail.gmail.com>
	<CA+gWKMB8VD3DBYRAJG+YBfZaARvS+H_TNcB-8ZcC3r_B_cZoNA@mail.gmail.com>
Message-ID: <CAFdSV9vTzQLhw2_npKC63W=UoYY8W1dNp7W2+huM3ftPhdLkug@mail.gmail.com>

Just pesky things like resources ;)

On Wed, Jan 27, 2016 at 12:43 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> This must be done like insert but in reverse order. With inserts, we need
> to add parents first and children after, because of the foreign key
> constraints.
> For delete, we need to group children first and delete them prior to
> deleting parents.
>
> Is there something that prevents us from implementing this feature?
>
> Vlad
>
> On Wed, Jan 27, 2016 at 7:01 AM, Madhusudana Reddy Sunnapu <
> smreddy2004 at gmail.com> wrote:
>
> > Hi,
> >
> > Hibernate provides simple configuration properties to enable batch
> inserts
> > and updates using "hibernate.order_inserts" and "hibernate.order_updates"
> > respectively. These setting allow hibernate to sort the insert and update
> > statements and process them in batches efficiently.
> >
> > But we don't have such a configuration to sort or batch delete statements
> > efficiently. Especially with CascadeType.DELETE we can see that delete
> > statements are not batched effectively and could result in extra network
> > calls to the database for deletion.(Refer:
> >
> >
> http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/
> > )
> >
> > So I am thinking wouldn't it be a good feature to have hibernate support
> > similar configuration, say "hibernate.order_deletes", to enable batch
> > deletes similar to updates and inserts.
> >
> > Cheers,
> > Madhu.
> > _______________________________________________
> > 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 mihalcea.vlad at gmail.com  Wed Jan 27 12:02:28 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Wed, 27 Jan 2016 19:02:28 +0200
Subject: [hibernate-dev] Configuration to support batching (or sorting)
 of DELETE statements efficiently
In-Reply-To: <CAFdSV9vTzQLhw2_npKC63W=UoYY8W1dNp7W2+huM3ftPhdLkug@mail.gmail.com>
References: <CAHWSuP-o7fu45AZNF7oeaA-90bWOj_U-z31JRW49ufLHATm3SQ@mail.gmail.com>
	<CA+gWKMB8VD3DBYRAJG+YBfZaARvS+H_TNcB-8ZcC3r_B_cZoNA@mail.gmail.com>
	<CAFdSV9vTzQLhw2_npKC63W=UoYY8W1dNp7W2+huM3ftPhdLkug@mail.gmail.com>
Message-ID: <CA+gWKMDS==-12PsCyEQE33py=7-5eyjZVehprdqPNEKA+ugT9w@mail.gmail.com>

Then we can add this task as a feature request and see when we have some
time to add support for it.

Vlad

On Wed, Jan 27, 2016 at 6:54 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Just pesky things like resources ;)
>
> On Wed, Jan 27, 2016 at 12:43 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> This must be done like insert but in reverse order. With inserts, we need
>> to add parents first and children after, because of the foreign key
>> constraints.
>> For delete, we need to group children first and delete them prior to
>> deleting parents.
>>
>> Is there something that prevents us from implementing this feature?
>>
>> Vlad
>>
>> On Wed, Jan 27, 2016 at 7:01 AM, Madhusudana Reddy Sunnapu <
>> smreddy2004 at gmail.com> wrote:
>>
>> > Hi,
>> >
>> > Hibernate provides simple configuration properties to enable batch
>> inserts
>> > and updates using "hibernate.order_inserts" and
>> "hibernate.order_updates"
>> > respectively. These setting allow hibernate to sort the insert and
>> update
>> > statements and process them in batches efficiently.
>> >
>> > But we don't have such a configuration to sort or batch delete
>> statements
>> > efficiently. Especially with CascadeType.DELETE we can see that delete
>> > statements are not batched effectively and could result in extra network
>> > calls to the database for deletion.(Refer:
>> >
>> >
>> http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/
>> > )
>> >
>> > So I am thinking wouldn't it be a good feature to have hibernate support
>> > similar configuration, say "hibernate.order_deletes", to enable batch
>> > deletes similar to updates and inserts.
>> >
>> > Cheers,
>> > Madhu.
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From steve at hibernate.org  Wed Jan 27 13:12:26 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 Jan 2016 18:12:26 +0000
Subject: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in
	Oracle
In-Reply-To: <CAFdSV9sQTjvvCnTwis+qipHprg7=FR44GKAx5y9P-Mw4UdpwPg@mail.gmail.com>
References: <4E9B2441.2000709@gmail.com>
	<7d0a5d1d-3e3e-4b64-bc04-7afe4f71c43c@zmail01.collab.prod.int.phx2.redhat.com>
	<CAFdSV9sQTjvvCnTwis+qipHprg7=FR44GKAx5y9P-Mw4UdpwPg@mail.gmail.com>
Message-ID: <CAFdSV9syD2MhdOaeMvJ_UjyKj-W0xLTXT_w5SL-FsJQDDVDWpw@mail.gmail.com>

Andrea and I discussed on IRC and since we were the only 2 involved and
both agreed, that constitutes a quorum! :)

So I am going to override Oracle12cDialect#contributeTypes (implicit Type
determination) such that:

   - recognize byte[] as MaterializedBlobType (Types#BLOB) rather than
   BinaryType (Types#LONGVARBINARY)
   - recognize Byte[] as WrappedMaterializedBlobType (Types#BLOB) rather
   than WrapperBinaryType (Types#LONGVARBINARY).

 I am a very leery about the VARCHAR, LONG, CLOB side of it mainly because
the approach to access data from a VARCHAR and a CLOB are so very different
and we'd have to account for that at some point based on size, etc.

Ultimately what I'd love to see is to expand the distinction
between SqlTypeDescriptor and
JavaTypeDescriptor and to piece them together (along with
AttributeConverter, MutabilityPLan, etc) into a BasicType "just in time".
The reason I bring this up in that this question is really a discussion
about the resolution for a SqlTypeDescriptor given just a
JavaTypeDescriptor.  That's fundamentally what BasicTypeRegistry is about.
But ultimately, breaking that down further and instead asking for the
SqlTypeDescriptor given a JavaTypeDescriptor is more flexible.  Especially
when you start to consider that that question can much more easily
incorporate size information and other "contextual" data.

Anyway, that's long term... For now I will override #contributeTypes
in Oracle12cDialect
to provide the new registrations mentioned above.  I will do this on master
(5.1).  IMO we should also consider backporting this, but wanted to get
everyone's (anyone) thoughts first.  Opinions?


On Tue, Jan 26, 2016 at 11:48 AM Steve Ebersole <steve at hibernate.org> wrote:

> This has come up again under HHH-10345[1].
>
> The original request here claims that Oracle have deprecated LONG (
> LONGVARCHAR) and LONG RAW (LONGVARBINARY).  It refers to the 9i release
> notes as "proof" of that[2].  The 9i release notes do mention LONG (LONGVARCHAR)
> datatype being deprecated.  However, it does not mention LONG RAW.   The
> next 2 references it links are from 10g and 11i; both of these do mention
> LONG RAW specifically being deprecated.  So LONG was deprecated as of 9i.
> It is a bit unclear exactly when LONG RAW was deprecated.
>
> Unfortunately Oracle has issues with both LONG and LOB forms.  In fact the
> list of restrictions for LONG and LONG RAW  is incredibly long.  As far as
> I can tell newer Oracle releases have alleviated some of the crazier
> "limitations" of LOB usage; but its unfortunately been many years since I
> have "used Oracle in anger", so I do not really know the complete current
> state of its LOB support.
>
> While I personally agree that we should not be retroactively changing our
> legacy Oracle-based dialects to map LONGVARCHAR to (N)CLOB and LONGVARBINARY
> to BLOB, I do think that is something we want to change moving forward.
> Specifically, I wonder if Oracle12cDialect is "foward".  We knew about
> these deprecations when Oracle12cDialect was developed and clearly these
> types are deprecated prior to Oracle 12c even if exactly when Oracle
> deprecated them is a bit murky.  So specifically I wonder if, for 5.1, we
> ought to make this change for Oracle12cDialect.  What do y'all think?
>
>
> [1] - https://hibernate.atlassian.net/browse/HHH-10345
> [2] -
> http://docs.oracle.com/cd/A91202_01/901_doc/server.901/a90120/ch4_dep.htm#6690
>
>
>
> On Mon, Oct 17, 2011 at 6:11 PM Gail Badner <gbadner at redhat.com> wrote:
>
>> There is a discussion about direct binding (fast) and stream binding
>> (slow) at [1]. I think it answers Scott's questions. Rather than repeating
>> the info here, please take a look at the Oracle documentation (
>> http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#autoId18
>> ).
>>
>> After thinking about this more, I think we should keep the Oracle
>> dialects as is. Here are my reasons:
>> - Hibernate defines the text/image types consistent with how Oracle maps
>> LONGVARCHAR/LONGVARBINARY;
>> - the bug lies with Oracle;
>> - Oracle has effectively deprecated valid SQL data types (LONGVARCHAR and
>> LONGVARBINARY);
>> - the migration from "text" to "materialized_clob" has already been
>> documented since 3.5; "image" is a new type as of 3.6;
>> - anyone actually using text/image with LONG/LONGRAW columns may run into
>> new migration issues in Hibernate 4.0.0; more testing would need to be done
>> to determine the true impact;
>> - users can easily create a new dialect making the changes I mentioned
>> earlier;
>> - this avoids having to make a confusing recommendation (i.e., using
>> Oracle11gDialect for accessing an Oracle 10g DB).
>>
>> Regarding Oracle tests, IMO, the tests using "text" and "image" should be
>> disabled. If there is no similar test using clob/blob, it would be a good
>> idea to add one.
>>
>> ----- Original Message -----
>> > From: "?ukasz Antoniak" <lukasz.antoniak at gmail.com>
>> > To: "Strong Liu" <stliu at hibernate.org>
>> > Cc: "Scott Marlow" <smarlow at redhat.com>, "Gail Badner" <
>> gbadner at redhat.com>, hibernate-dev at lists.jboss.org
>> > Sent: Sunday, October 16, 2011 11:36:49 AM
>> > Subject: Re: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in
>> Oracle
>> >
>> > Currently Oracle supports database versions from 10.1 to 11.2 [1].
>> > LONG
>> > and LONG RAW data types are deprecated since version 8 and 8i
>> > (released
>> > before September 2000) [2]. Oracle keeps those column types only for
>> > backward compatibility [3].
>> >
>> > I tried the following scenario (Oracle 10gR2):
>> > 1. Create schema with "hibernate.hbm2ddl.auto" set to "create". The
>> > LONG
>> > column is created.
>> > 2. Insert some data.
>> > 3. Modify Oracle dialect as Gail suggested. Avoid setting
>> > "hibernate.hbm2ddl.auto".
>> > 4. Insert some data.
>> > To my surprise the test actually passed :). However, I think that we
>> > cannot guaranty the proper behavior in every situation.
>> >
>> > As for performance, ImageType is extracted by calling
>> > ResultSet.getBytes() method, which fetches all data in one call [4].
>> > I
>> > don't suppose a major performance difference when data is streamed in
>> > another call. oracle.jdbc.driver.LongRawAccessor.getBytes also
>> > fetches
>> > data by reading the stream.
>> >
>> > The bug reading LONG column affects JDBC drivers since version
>> > 10.2.0.4.
>> > I think that we have to choose between:
>> > - changing Oracle10gDialect. Make a not about it in migration guide
>> > to
>> > 4.0 and update "5.2.2. Basic value types" chapter in Hibernate
>> > documentation.
>> > - introducing Oracle11gDialect. It can sound weird to access Oracle
>> > 10g
>> > database with Oracle 11g dialect.
>> > - disabling execution of Hibernate tests that fail because of this
>> > issue
>> > with @SkipForDialect (and maybe develop another version of them with
>> > CLOBs and BLOBs, @RequiresDialect). Hibernate is written correctly
>> > according to "Default Mappings Between SQL Types and Java Types"
>> > (referenced earlier by Gail) and this is more Oracle's JDBC
>> > implementation issue. This option came to my mind, but it's weird :P.
>> >
>> > I would vote for the first option.
>> >
>> > Regards,
>> > Lukasz Antoniak
>> >
>> > [1]
>> >
>> http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf
>> > (page 4)
>> > [2]
>> >
>> http://download.oracle.com/docs/cd/A91202_01/901_doc/server.901/a90120/ch4_dep.htm
>> > [3]
>> >
>> http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm
>> > [4] "Getting a LONG RAW Data Column with getBytes"
>> >
>> http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/jstreams.htm
>> >
>> > Strong Liu pisze:
>> > > I think oracle 11g is the only one supported DB version by oracle,
>> > > can we just introduce a new oracle dialect with suggested changes,
>> > > and deprecate all other existed oracle dialects? this won't
>> > > affects users app
>> > >
>> > > -----------
>> > > Strong Liu <stliu at hibernate.org>
>> > > http://hibernate.org
>> > > http://github.com/stliu
>> > >
>> > > On Oct 15, 2011, at 11:14 AM, Scott Marlow wrote:
>> > >
>> > >> How does this impact existing applications?  Would they have to
>> > >> convert
>> > >> LONGs to CLOBs (and LONGRAWs to BLOBs) to keep the application
>> > >> working?
>> > >>
>> > >> As far as the advantage of CLOB over TEXT, if you read every
>> > >> character,
>> > >> which one is really faster?  I would expect TEXT to be a little
>> > >> faster,
>> > >> since the server side will send the characters before they are
>> > >> asked
>> > >> for.  By faster, I mean from the application performance point of
>> > >> view. :)
>> > >>
>> > >> Could this be changed in a custom Oracle dialect?   So new
>> > >> applications/databases could perhaps use that and existing
>> > >> applications
>> > >> might use LONGs a bit longer via the existing Oracle dialect.
>> > >>
>> > >> On 10/14/2011 09:22 PM, Gail Badner wrote:
>> > >>> In [1], I am seeing the following type mappings:
>> > >>>
>> > >>> Column type: LONG ->  java.sql.Types.LONGVARCHAR ->
>> > >>>  java.lang.String
>> > >>> Column type: LONGRAW ->  java.sql.Types.LONGVARBINARY ->  byte[]
>> > >>>
>> > >>> org.hibernate.type.TextType is consistent with the mapping for
>> > >>> LONG.
>> > >>>
>> > >>> org.hibernate.type.ImageType is consistent with the mapping for
>> > >>> LONGRAW.
>> > >>>
>> > >>> From this standpoint, the current settings are appropriate.
>> > >>>
>> > >>> I understand there are restrictions when LONG and LONGRAW are
>> > >>> used and I see from your other message that there is Oracle
>> > >>> documentation for migrating to CLOB and BLOB.
>> > >>>
>> > >>> I agree that changing column type registration as follows (for
>> > >>> Oracle only) should fix this:
>> > >>>           registerColumnType( Types.VARBINARY, 2000, "raw($l)" );
>> > >>>           registerColumnType( Types.VARBINARY, "blob" );
>> > >>>
>> > >>>           registerColumnType( Types.LONGVARCHAR, "clob" );
>> > >>>           registerColumnType( Types.LONGVARBINARY, "blob" );
>> > >>>
>> > >>>           registerColumnType( Types.VARCHAR, 4000, "varchar2($l
>> char)" );
>> > >>>           registerColumnType( Types.VARCHAR, "clob" );
>> > >>>
>> > >>> Steve, what do you think? Is it too late to make this change for
>> > >>> 4.0.0?
>> > >>>
>> > >>> [1] Table 11-1 of Oracle? Database JDBC Developer's Guide and
>> > >>> Reference, 11g Release 1 (11.1)
>> > >>> (
>> http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#g1028145
>> )
>> > >>> [2] Hibernate Core Migration Guide for 3.5
>> > >>> (http://community.jboss.org/wiki/HibernateCoreMigrationGuide35)
>> > >>> [3] Table 2-10 of Oracle? Database SQL Language Reference
>> > >>> 11g Release 1 (11.1)
>> > >>> (
>> http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elements002.htm#g195937
>> )
>> > >>>
>> > >>> ----- Original Message -----
>> > >>>> From: "?ukasz Antoniak"<lukasz.antoniak at gmail.com>
>> > >>>> To: hibernate-dev at lists.jboss.org
>> > >>>> Sent: Thursday, October 13, 2011 12:50:13 PM
>> > >>>> Subject: [hibernate-dev] HHH-6726 LONG and LONG RAW column types
>> > >>>> in Oracle
>> > >>>>
>> > >>>> Welcome Community!
>> > >>>>
>> > >>>> I have just subscribed to the list and wanted to discuss
>> > >>>> HHH-6726
>> > >>>> JIRA
>> > >>>> issue.
>> > >>>>
>> > >>>> Gail Badner wrote
>> > >>>> (
>> http://lists.jboss.org/pipermail/hibernate-dev/2011-October/007208.html):
>> > >>>> HHH-6726 (Oracle : map TextType to clob and ImageType to blob)
>> > >>>> https://hibernate.onjira.com/browse/HHH-6726
>> > >>>> There have been a number of issues opened since the change was
>> > >>>> made
>> > >>>> to
>> > >>>> map TextType (LONGVARCHAR) 'long' and ImageType (LONGVARBINARY)
>> > >>>> to
>> > >>>> 'long
>> > >>>> raw'. This change was already documented in the migration notes.
>> > >>>> Should
>> > >>>> the mapping for Oracle (only) be changed back to clob and blob?
>> > >>>>
>> > >>>> HHH-6726 is caused by an issue in Oracle JDBC driver (version
>> > >>>> 10.2.0.4
>> > >>>> and later). This bug appears when LONG or LONG RAW columns are
>> > >>>> accessed
>> > >>>> not as first or last while processing SQL statement.
>> > >>>>
>> > >>>> I have discussed the topic of mapping TextType to CLOB and
>> > >>>> ImageType
>> > >>>> to
>> > >>>> BLOB (only in Oracle dialect) with Strong Liu. Reasons for doing
>> > >>>> so:
>> > >>>> - Oracle allows only one LONG / LONG RAW column per table. This
>> > >>>> might
>> > >>>> be
>> > >>>> the most important from Hibernate's perspective.
>> > >>>> - LONG / LONG RAW - up to 2 GB, BLOB / CLOB - up to 4 GB.
>> > >>>> - In PL/SQL using LOBs is more efficient (random access to
>> > >>>> data).
>> > >>>> LONG
>> > >>>> only sequential.
>> > >>>> - LONG and LONG RAW are deprecated.
>> > >>>>
>> > >>>> What is your opinion?
>> > >>>>
>> > >>>> Regards,
>> > >>>> Lukasz Antoniak
>> > >>>> _______________________________________________
>> > >>>> 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 guillaume.smet at gmail.com  Wed Jan 27 18:40:34 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 28 Jan 2016 00:40:34 +0100
Subject: [hibernate-dev] [Search] Travis support
Message-ID: <CALt0+o-D3h_xoZ52CC34BniDeuMVZUHHAH7u5aQmFPeGmZJG9g@mail.gmail.com>

Hi,

As mentioned in our last discussion, I explored adding Travis support to
Search.

The diff is here:
https://github.com/gsmet/hibernate-search/commit/cbd2c1fff05532974823da572795d53cb8b9d26a
(yes it's short but it was a long road :))

I had to raise a bit the JGroups timeout for one test and had to fix
TestRunnerStandalone
so that it effectively uses the configuration from the profile (this change
is not specific to Travis and should be committed anyway).

The result is here:
https://travis-ci.org/gsmet/hibernate-search

What I like in Travis:
- The CI configuration is code and is versioned
- Parallelization with a *lot* of resources
- The ability to build a test matrix very easily
- Complete isolation as each build is run in its own Docker container

What is less cool:
- The only way to get the logs is to ship them to AWS S3 - that said, I did
it and it's pretty straightforward as it's well integrated (I commented out
the code in the .travis.yml for now)
- It might seem less flexible as we are depending on the Travis
infrastructure (for instance, I created a ticket to ask for the support of
JDK 9: https://github.com/travis-ci/travis-ci/issues/5520) but in fact, you
can do whatever you want: see https://github.com/Blazebit/blaze-persistence
.travis.yml file for a comprehensive example

So if we move to Travis, I think the regular builds could run on Travis and
we could keep Jenkins for specific ones (deploy/release).

I'll take a look at OGM tomorrow. Travis supports out of the box most of
the NoSQL databases (https://docs.travis-ci.com/user/database-setup/) so
I'm pretty curious to see how it goes.

Thoughts?

-- 
Guillaume

From mihalcea.vlad at gmail.com  Thu Jan 28 00:25:49 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 28 Jan 2016 07:25:49 +0200
Subject: [hibernate-dev] JDBC warnings performance matter
Message-ID: <CA+gWKMD2J=2QCn8id9AniJqjEd6fi3SksDwSMaPCSkqyhJU+MQ@mail.gmail.com>

Hi,

The guys at Plumbr wrote an article about how MySQL JDBC warnings are
handled by Hibernate:

https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate

I remember seeing this issue on StackOverflow too and I was curious if you
want to tweak it a little bit.
I also agree that relying on the log levels to prevent fetching warnings
might come as a surprise to many users and we should document this behavior.

We could also have a hibernate.jdbc.log.warnings boolean property to
control whether we want to log those warnings or not.
This way, if users set the logger level to WARN, they will see the logs
generated by the framework stack and the JDBC warnings will be logged only
if this configuration property is true.

What do you think?

Vlad

From mihalcea.vlad at gmail.com  Thu Jan 28 00:48:19 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 28 Jan 2016 07:48:19 +0200
Subject: [hibernate-dev] Configuration to support batching (or sorting)
 of DELETE statements efficiently
In-Reply-To: <CA+gWKMDS==-12PsCyEQE33py=7-5eyjZVehprdqPNEKA+ugT9w@mail.gmail.com>
References: <CAHWSuP-o7fu45AZNF7oeaA-90bWOj_U-z31JRW49ufLHATm3SQ@mail.gmail.com>
	<CA+gWKMB8VD3DBYRAJG+YBfZaARvS+H_TNcB-8ZcC3r_B_cZoNA@mail.gmail.com>
	<CAFdSV9vTzQLhw2_npKC63W=UoYY8W1dNp7W2+huM3ftPhdLkug@mail.gmail.com>
	<CA+gWKMDS==-12PsCyEQE33py=7-5eyjZVehprdqPNEKA+ugT9w@mail.gmail.com>
Message-ID: <CA+gWKMC0YBdAs-J-hsA1oCTh-AMLen5g4SAFfeMB9Ti7VFPZqg@mail.gmail.com>

I created this JIRA issue for this:

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

Vlad

On Wed, Jan 27, 2016 at 7:02 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
wrote:

> Then we can add this task as a feature request and see when we have some
> time to add support for it.
>
> Vlad
>
> On Wed, Jan 27, 2016 at 6:54 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Just pesky things like resources ;)
>>
>> On Wed, Jan 27, 2016 at 12:43 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>> wrote:
>>
>>> This must be done like insert but in reverse order. With inserts, we need
>>> to add parents first and children after, because of the foreign key
>>> constraints.
>>> For delete, we need to group children first and delete them prior to
>>> deleting parents.
>>>
>>> Is there something that prevents us from implementing this feature?
>>>
>>> Vlad
>>>
>>> On Wed, Jan 27, 2016 at 7:01 AM, Madhusudana Reddy Sunnapu <
>>> smreddy2004 at gmail.com> wrote:
>>>
>>> > Hi,
>>> >
>>> > Hibernate provides simple configuration properties to enable batch
>>> inserts
>>> > and updates using "hibernate.order_inserts" and
>>> "hibernate.order_updates"
>>> > respectively. These setting allow hibernate to sort the insert and
>>> update
>>> > statements and process them in batches efficiently.
>>> >
>>> > But we don't have such a configuration to sort or batch delete
>>> statements
>>> > efficiently. Especially with CascadeType.DELETE we can see that delete
>>> > statements are not batched effectively and could result in extra
>>> network
>>> > calls to the database for deletion.(Refer:
>>> >
>>> >
>>> http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/
>>> > )
>>> >
>>> > So I am thinking wouldn't it be a good feature to have hibernate
>>> support
>>> > similar configuration, say "hibernate.order_deletes", to enable batch
>>> > deletes similar to updates and inserts.
>>> >
>>> > Cheers,
>>> > Madhu.
>>> > _______________________________________________
>>> > 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 mihalcea.vlad at gmail.com  Thu Jan 28 02:00:08 2016
From: mihalcea.vlad at gmail.com (Vlad Mihalcea)
Date: Thu, 28 Jan 2016 09:00:08 +0200
Subject: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in
	Oracle
In-Reply-To: <CAFdSV9syD2MhdOaeMvJ_UjyKj-W0xLTXT_w5SL-FsJQDDVDWpw@mail.gmail.com>
References: <4E9B2441.2000709@gmail.com>
	<7d0a5d1d-3e3e-4b64-bc04-7afe4f71c43c@zmail01.collab.prod.int.phx2.redhat.com>
	<CAFdSV9sQTjvvCnTwis+qipHprg7=FR44GKAx5y9P-Mw4UdpwPg@mail.gmail.com>
	<CAFdSV9syD2MhdOaeMvJ_UjyKj-W0xLTXT_w5SL-FsJQDDVDWpw@mail.gmail.com>
Message-ID: <CA+gWKMAcmkKtnK2jtX2S2=zWi+MSrj7x_BEwrL_ib7Je7xwnhA@mail.gmail.com>

Hi,

Shouldn't we use the database metadata to know what SQL column type we are
mapping to?

I don't think we should do heuristic determination of types:

Type result = metadata.getTypeResolver().heuristicType( typeName,
typeParameters
);

When Hibernate starts, we could inspect the underlying table JDBC metadata
and get the actual SQL data types.
This way we have both the Java type and the JDBC type and the entity
property can get a Hibernate Type according to these two.

Vlad

On Wed, Jan 27, 2016 at 8:12 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Andrea and I discussed on IRC and since we were the only 2 involved and
> both agreed, that constitutes a quorum! :)
>
> So I am going to override Oracle12cDialect#contributeTypes (implicit Type
> determination) such that:
>
>    - recognize byte[] as MaterializedBlobType (Types#BLOB) rather than
>    BinaryType (Types#LONGVARBINARY)
>    - recognize Byte[] as WrappedMaterializedBlobType (Types#BLOB) rather
>    than WrapperBinaryType (Types#LONGVARBINARY).
>
>  I am a very leery about the VARCHAR, LONG, CLOB side of it mainly because
> the approach to access data from a VARCHAR and a CLOB are so very different
> and we'd have to account for that at some point based on size, etc.
>
> Ultimately what I'd love to see is to expand the distinction
> between SqlTypeDescriptor and
> JavaTypeDescriptor and to piece them together (along with
> AttributeConverter, MutabilityPLan, etc) into a BasicType "just in time".
> The reason I bring this up in that this question is really a discussion
> about the resolution for a SqlTypeDescriptor given just a
> JavaTypeDescriptor.  That's fundamentally what BasicTypeRegistry is about.
> But ultimately, breaking that down further and instead asking for the
> SqlTypeDescriptor given a JavaTypeDescriptor is more flexible.  Especially
> when you start to consider that that question can much more easily
> incorporate size information and other "contextual" data.
>
> Anyway, that's long term... For now I will override #contributeTypes
> in Oracle12cDialect
> to provide the new registrations mentioned above.  I will do this on master
> (5.1).  IMO we should also consider backporting this, but wanted to get
> everyone's (anyone) thoughts first.  Opinions?
>
>
> On Tue, Jan 26, 2016 at 11:48 AM Steve Ebersole <steve at hibernate.org>
> wrote:
>
> > This has come up again under HHH-10345[1].
> >
> > The original request here claims that Oracle have deprecated LONG (
> > LONGVARCHAR) and LONG RAW (LONGVARBINARY).  It refers to the 9i release
> > notes as "proof" of that[2].  The 9i release notes do mention LONG
> (LONGVARCHAR)
> > datatype being deprecated.  However, it does not mention LONG RAW.   The
> > next 2 references it links are from 10g and 11i; both of these do mention
> > LONG RAW specifically being deprecated.  So LONG was deprecated as of 9i.
> > It is a bit unclear exactly when LONG RAW was deprecated.
> >
> > Unfortunately Oracle has issues with both LONG and LOB forms.  In fact
> the
> > list of restrictions for LONG and LONG RAW  is incredibly long.  As far
> as
> > I can tell newer Oracle releases have alleviated some of the crazier
> > "limitations" of LOB usage; but its unfortunately been many years since I
> > have "used Oracle in anger", so I do not really know the complete current
> > state of its LOB support.
> >
> > While I personally agree that we should not be retroactively changing our
> > legacy Oracle-based dialects to map LONGVARCHAR to (N)CLOB and
> LONGVARBINARY
> > to BLOB, I do think that is something we want to change moving forward.
> > Specifically, I wonder if Oracle12cDialect is "foward".  We knew about
> > these deprecations when Oracle12cDialect was developed and clearly these
> > types are deprecated prior to Oracle 12c even if exactly when Oracle
> > deprecated them is a bit murky.  So specifically I wonder if, for 5.1, we
> > ought to make this change for Oracle12cDialect.  What do y'all think?
> >
> >
> > [1] - https://hibernate.atlassian.net/browse/HHH-10345
> > [2] -
> >
> http://docs.oracle.com/cd/A91202_01/901_doc/server.901/a90120/ch4_dep.htm#6690
> >
> >
> >
> > On Mon, Oct 17, 2011 at 6:11 PM Gail Badner <gbadner at redhat.com> wrote:
> >
> >> There is a discussion about direct binding (fast) and stream binding
> >> (slow) at [1]. I think it answers Scott's questions. Rather than
> repeating
> >> the info here, please take a look at the Oracle documentation (
> >>
> http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#autoId18
> >> ).
> >>
> >> After thinking about this more, I think we should keep the Oracle
> >> dialects as is. Here are my reasons:
> >> - Hibernate defines the text/image types consistent with how Oracle maps
> >> LONGVARCHAR/LONGVARBINARY;
> >> - the bug lies with Oracle;
> >> - Oracle has effectively deprecated valid SQL data types (LONGVARCHAR
> and
> >> LONGVARBINARY);
> >> - the migration from "text" to "materialized_clob" has already been
> >> documented since 3.5; "image" is a new type as of 3.6;
> >> - anyone actually using text/image with LONG/LONGRAW columns may run
> into
> >> new migration issues in Hibernate 4.0.0; more testing would need to be
> done
> >> to determine the true impact;
> >> - users can easily create a new dialect making the changes I mentioned
> >> earlier;
> >> - this avoids having to make a confusing recommendation (i.e., using
> >> Oracle11gDialect for accessing an Oracle 10g DB).
> >>
> >> Regarding Oracle tests, IMO, the tests using "text" and "image" should
> be
> >> disabled. If there is no similar test using clob/blob, it would be a
> good
> >> idea to add one.
> >>
> >> ----- Original Message -----
> >> > From: "?ukasz Antoniak" <lukasz.antoniak at gmail.com>
> >> > To: "Strong Liu" <stliu at hibernate.org>
> >> > Cc: "Scott Marlow" <smarlow at redhat.com>, "Gail Badner" <
> >> gbadner at redhat.com>, hibernate-dev at lists.jboss.org
> >> > Sent: Sunday, October 16, 2011 11:36:49 AM
> >> > Subject: Re: [hibernate-dev] HHH-6726 LONG and LONG RAW column types
> in
> >> Oracle
> >> >
> >> > Currently Oracle supports database versions from 10.1 to 11.2 [1].
> >> > LONG
> >> > and LONG RAW data types are deprecated since version 8 and 8i
> >> > (released
> >> > before September 2000) [2]. Oracle keeps those column types only for
> >> > backward compatibility [3].
> >> >
> >> > I tried the following scenario (Oracle 10gR2):
> >> > 1. Create schema with "hibernate.hbm2ddl.auto" set to "create". The
> >> > LONG
> >> > column is created.
> >> > 2. Insert some data.
> >> > 3. Modify Oracle dialect as Gail suggested. Avoid setting
> >> > "hibernate.hbm2ddl.auto".
> >> > 4. Insert some data.
> >> > To my surprise the test actually passed :). However, I think that we
> >> > cannot guaranty the proper behavior in every situation.
> >> >
> >> > As for performance, ImageType is extracted by calling
> >> > ResultSet.getBytes() method, which fetches all data in one call [4].
> >> > I
> >> > don't suppose a major performance difference when data is streamed in
> >> > another call. oracle.jdbc.driver.LongRawAccessor.getBytes also
> >> > fetches
> >> > data by reading the stream.
> >> >
> >> > The bug reading LONG column affects JDBC drivers since version
> >> > 10.2.0.4.
> >> > I think that we have to choose between:
> >> > - changing Oracle10gDialect. Make a not about it in migration guide
> >> > to
> >> > 4.0 and update "5.2.2. Basic value types" chapter in Hibernate
> >> > documentation.
> >> > - introducing Oracle11gDialect. It can sound weird to access Oracle
> >> > 10g
> >> > database with Oracle 11g dialect.
> >> > - disabling execution of Hibernate tests that fail because of this
> >> > issue
> >> > with @SkipForDialect (and maybe develop another version of them with
> >> > CLOBs and BLOBs, @RequiresDialect). Hibernate is written correctly
> >> > according to "Default Mappings Between SQL Types and Java Types"
> >> > (referenced earlier by Gail) and this is more Oracle's JDBC
> >> > implementation issue. This option came to my mind, but it's weird :P.
> >> >
> >> > I would vote for the first option.
> >> >
> >> > Regards,
> >> > Lukasz Antoniak
> >> >
> >> > [1]
> >> >
> >>
> http://www.oracle.com/us/support/library/lifetime-support-technology-069183.pdf
> >> > (page 4)
> >> > [2]
> >> >
> >>
> http://download.oracle.com/docs/cd/A91202_01/901_doc/server.901/a90120/ch4_dep.htm
> >> > [3]
> >> >
> >>
> http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/datatype.htm
> >> > [4] "Getting a LONG RAW Data Column with getBytes"
> >> >
> >>
> http://download.oracle.com/docs/cd/B19306_01/java.102/b14355/jstreams.htm
> >> >
> >> > Strong Liu pisze:
> >> > > I think oracle 11g is the only one supported DB version by oracle,
> >> > > can we just introduce a new oracle dialect with suggested changes,
> >> > > and deprecate all other existed oracle dialects? this won't
> >> > > affects users app
> >> > >
> >> > > -----------
> >> > > Strong Liu <stliu at hibernate.org>
> >> > > http://hibernate.org
> >> > > http://github.com/stliu
> >> > >
> >> > > On Oct 15, 2011, at 11:14 AM, Scott Marlow wrote:
> >> > >
> >> > >> How does this impact existing applications?  Would they have to
> >> > >> convert
> >> > >> LONGs to CLOBs (and LONGRAWs to BLOBs) to keep the application
> >> > >> working?
> >> > >>
> >> > >> As far as the advantage of CLOB over TEXT, if you read every
> >> > >> character,
> >> > >> which one is really faster?  I would expect TEXT to be a little
> >> > >> faster,
> >> > >> since the server side will send the characters before they are
> >> > >> asked
> >> > >> for.  By faster, I mean from the application performance point of
> >> > >> view. :)
> >> > >>
> >> > >> Could this be changed in a custom Oracle dialect?   So new
> >> > >> applications/databases could perhaps use that and existing
> >> > >> applications
> >> > >> might use LONGs a bit longer via the existing Oracle dialect.
> >> > >>
> >> > >> On 10/14/2011 09:22 PM, Gail Badner wrote:
> >> > >>> In [1], I am seeing the following type mappings:
> >> > >>>
> >> > >>> Column type: LONG ->  java.sql.Types.LONGVARCHAR ->
> >> > >>>  java.lang.String
> >> > >>> Column type: LONGRAW ->  java.sql.Types.LONGVARBINARY ->  byte[]
> >> > >>>
> >> > >>> org.hibernate.type.TextType is consistent with the mapping for
> >> > >>> LONG.
> >> > >>>
> >> > >>> org.hibernate.type.ImageType is consistent with the mapping for
> >> > >>> LONGRAW.
> >> > >>>
> >> > >>> From this standpoint, the current settings are appropriate.
> >> > >>>
> >> > >>> I understand there are restrictions when LONG and LONGRAW are
> >> > >>> used and I see from your other message that there is Oracle
> >> > >>> documentation for migrating to CLOB and BLOB.
> >> > >>>
> >> > >>> I agree that changing column type registration as follows (for
> >> > >>> Oracle only) should fix this:
> >> > >>>           registerColumnType( Types.VARBINARY, 2000, "raw($l)" );
> >> > >>>           registerColumnType( Types.VARBINARY, "blob" );
> >> > >>>
> >> > >>>           registerColumnType( Types.LONGVARCHAR, "clob" );
> >> > >>>           registerColumnType( Types.LONGVARBINARY, "blob" );
> >> > >>>
> >> > >>>           registerColumnType( Types.VARCHAR, 4000, "varchar2($l
> >> char)" );
> >> > >>>           registerColumnType( Types.VARCHAR, "clob" );
> >> > >>>
> >> > >>> Steve, what do you think? Is it too late to make this change for
> >> > >>> 4.0.0?
> >> > >>>
> >> > >>> [1] Table 11-1 of Oracle? Database JDBC Developer's Guide and
> >> > >>> Reference, 11g Release 1 (11.1)
> >> > >>> (
> >>
> http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/datacc.htm#g1028145
> >> )
> >> > >>> [2] Hibernate Core Migration Guide for 3.5
> >> > >>> (http://community.jboss.org/wiki/HibernateCoreMigrationGuide35)
> >> > >>> [3] Table 2-10 of Oracle? Database SQL Language Reference
> >> > >>> 11g Release 1 (11.1)
> >> > >>> (
> >>
> http://download.oracle.com/docs/cd/B28359_01/server.111/b28286/sql_elements002.htm#g195937
> >> )
> >> > >>>
> >> > >>> ----- Original Message -----
> >> > >>>> From: "?ukasz Antoniak"<lukasz.antoniak at gmail.com>
> >> > >>>> To: hibernate-dev at lists.jboss.org
> >> > >>>> Sent: Thursday, October 13, 2011 12:50:13 PM
> >> > >>>> Subject: [hibernate-dev] HHH-6726 LONG and LONG RAW column types
> >> > >>>> in Oracle
> >> > >>>>
> >> > >>>> Welcome Community!
> >> > >>>>
> >> > >>>> I have just subscribed to the list and wanted to discuss
> >> > >>>> HHH-6726
> >> > >>>> JIRA
> >> > >>>> issue.
> >> > >>>>
> >> > >>>> Gail Badner wrote
> >> > >>>> (
> >> http://lists.jboss.org/pipermail/hibernate-dev/2011-October/007208.html
> ):
> >> > >>>> HHH-6726 (Oracle : map TextType to clob and ImageType to blob)
> >> > >>>> https://hibernate.onjira.com/browse/HHH-6726
> >> > >>>> There have been a number of issues opened since the change was
> >> > >>>> made
> >> > >>>> to
> >> > >>>> map TextType (LONGVARCHAR) 'long' and ImageType (LONGVARBINARY)
> >> > >>>> to
> >> > >>>> 'long
> >> > >>>> raw'. This change was already documented in the migration notes.
> >> > >>>> Should
> >> > >>>> the mapping for Oracle (only) be changed back to clob and blob?
> >> > >>>>
> >> > >>>> HHH-6726 is caused by an issue in Oracle JDBC driver (version
> >> > >>>> 10.2.0.4
> >> > >>>> and later). This bug appears when LONG or LONG RAW columns are
> >> > >>>> accessed
> >> > >>>> not as first or last while processing SQL statement.
> >> > >>>>
> >> > >>>> I have discussed the topic of mapping TextType to CLOB and
> >> > >>>> ImageType
> >> > >>>> to
> >> > >>>> BLOB (only in Oracle dialect) with Strong Liu. Reasons for doing
> >> > >>>> so:
> >> > >>>> - Oracle allows only one LONG / LONG RAW column per table. This
> >> > >>>> might
> >> > >>>> be
> >> > >>>> the most important from Hibernate's perspective.
> >> > >>>> - LONG / LONG RAW - up to 2 GB, BLOB / CLOB - up to 4 GB.
> >> > >>>> - In PL/SQL using LOBs is more efficient (random access to
> >> > >>>> data).
> >> > >>>> LONG
> >> > >>>> only sequential.
> >> > >>>> - LONG and LONG RAW are deprecated.
> >> > >>>>
> >> > >>>> What is your opinion?
> >> > >>>>
> >> > >>>> Regards,
> >> > >>>> Lukasz Antoniak
> >> > >>>> _______________________________________________
> >> > >>>> hibernate-dev mailing list
> >> > >>>> hibernate-dev at lists.jboss.org
> >> > >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >>>>
> >> > >>> _______________________________________________
> >> > >>> hibernate-dev mailing list
> >> > >>> hibernate-dev at lists.jboss.org
> >> > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >> _______________________________________________
> >> > >> hibernate-dev mailing list
> >> > >> hibernate-dev at lists.jboss.org
> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >
> >> >
> >> >
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Thu Jan 28 02:46:50 2016
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 28 Jan 2016 08:46:50 +0100
Subject: [hibernate-dev] JDBC warnings performance matter
In-Reply-To: <CA+gWKMD2J=2QCn8id9AniJqjEd6fi3SksDwSMaPCSkqyhJU+MQ@mail.gmail.com>
References: <CA+gWKMD2J=2QCn8id9AniJqjEd6fi3SksDwSMaPCSkqyhJU+MQ@mail.gmail.com>
Message-ID: <69A87977-39D9-46DC-8D22-36AE81BD5406@hibernate.org>

If that?s effectively widespread, I think indeed we should guard this feature with an explicit property.
It?s not necessarily easy to anticipate such consequences when designing things.
In insight, something more explicit looks better.

> On 28 Jan 2016, at 06:25, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> 
> Hi,
> 
> The guys at Plumbr wrote an article about how MySQL JDBC warnings are
> handled by Hibernate:
> 
> https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate
> 
> I remember seeing this issue on StackOverflow too and I was curious if you
> want to tweak it a little bit.
> I also agree that relying on the log levels to prevent fetching warnings
> might come as a surprise to many users and we should document this behavior.
> 
> We could also have a hibernate.jdbc.log.warnings boolean property to
> control whether we want to log those warnings or not.
> This way, if users set the logger level to WARN, they will see the logs
> generated by the framework stack and the JDBC warnings will be logged only
> if this configuration property is true.
> 
> What do you think?
> 
> Vlad
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From gunnar at hibernate.org  Thu Jan 28 02:59:10 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 28 Jan 2016 08:59:10 +0100
Subject: [hibernate-dev] JDBC warnings performance matter
In-Reply-To: <69A87977-39D9-46DC-8D22-36AE81BD5406@hibernate.org>
References: <CA+gWKMD2J=2QCn8id9AniJqjEd6fi3SksDwSMaPCSkqyhJU+MQ@mail.gmail.com>
	<69A87977-39D9-46DC-8D22-36AE81BD5406@hibernate.org>
Message-ID: <CADGJaX_J4jmm6NhRNXXUaU7+Kn8qibMN2XhGY+wKOjUp5VZjcg@mail.gmail.com>

Is the call also expensive if there are no SQL warnings (i.e. null is
returned, so no further walking is required)?

It'd be my hope that drivers should be able to fetch the first warning
- if any - upon statement execution without further round-trips. So
getWarnings() would be cheap if no warnings exist. In that case people
should IMHO actually fix the warnings instead of complaining that
reporting them takes time.

If it is a general perf issue also if no SQL warnings exist, +1 for
having a property for opting into logging them.

2016-01-28 8:46 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> If that?s effectively widespread, I think indeed we should guard this feature with an explicit property.
> It?s not necessarily easy to anticipate such consequences when designing things.
> In insight, something more explicit looks better.
>
>> On 28 Jan 2016, at 06:25, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
>>
>> Hi,
>>
>> The guys at Plumbr wrote an article about how MySQL JDBC warnings are
>> handled by Hibernate:
>>
>> https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate
>>
>> I remember seeing this issue on StackOverflow too and I was curious if you
>> want to tweak it a little bit.
>> I also agree that relying on the log levels to prevent fetching warnings
>> might come as a surprise to many users and we should document this behavior.
>>
>> We could also have a hibernate.jdbc.log.warnings boolean property to
>> control whether we want to log those warnings or not.
>> This way, if users set the logger level to WARN, they will see the logs
>> generated by the framework stack and the JDBC warnings will be logged only
>> if this configuration property is true.
>>
>> What do you think?
>>
>> Vlad
>> _______________________________________________
>> 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  Thu Jan 28 05:34:02 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 28 Jan 2016 10:34:02 +0000
Subject: [hibernate-dev] Configuration to support batching (or sorting)
 of DELETE statements efficiently
In-Reply-To: <CA+gWKMC0YBdAs-J-hsA1oCTh-AMLen5g4SAFfeMB9Ti7VFPZqg@mail.gmail.com>
References: <CAHWSuP-o7fu45AZNF7oeaA-90bWOj_U-z31JRW49ufLHATm3SQ@mail.gmail.com>
	<CA+gWKMB8VD3DBYRAJG+YBfZaARvS+H_TNcB-8ZcC3r_B_cZoNA@mail.gmail.com>
	<CAFdSV9vTzQLhw2_npKC63W=UoYY8W1dNp7W2+huM3ftPhdLkug@mail.gmail.com>
	<CA+gWKMDS==-12PsCyEQE33py=7-5eyjZVehprdqPNEKA+ugT9w@mail.gmail.com>
	<CA+gWKMC0YBdAs-J-hsA1oCTh-AMLen5g4SAFfeMB9Ti7VFPZqg@mail.gmail.com>
Message-ID: <CAFm4XO3Q1Oov-3g6DeHPkktgK+nJ4+D3g1z1Pn-+dwGrgMAjpA@mail.gmail.com>

Thanks! that looks like a very good idea.



On 28 January 2016 at 05:48, Vlad Mihalcea <mihalcea.vlad at gmail.com> wrote:
> I created this JIRA issue for this:
>
> https://hibernate.atlassian.net/browse/HHH-10483
>
> Vlad
>
> On Wed, Jan 27, 2016 at 7:02 PM, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
>
>> Then we can add this task as a feature request and see when we have some
>> time to add support for it.
>>
>> Vlad
>>
>> On Wed, Jan 27, 2016 at 6:54 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Just pesky things like resources ;)
>>>
>>> On Wed, Jan 27, 2016 at 12:43 AM Vlad Mihalcea <mihalcea.vlad at gmail.com>
>>> wrote:
>>>
>>>> This must be done like insert but in reverse order. With inserts, we need
>>>> to add parents first and children after, because of the foreign key
>>>> constraints.
>>>> For delete, we need to group children first and delete them prior to
>>>> deleting parents.
>>>>
>>>> Is there something that prevents us from implementing this feature?
>>>>
>>>> Vlad
>>>>
>>>> On Wed, Jan 27, 2016 at 7:01 AM, Madhusudana Reddy Sunnapu <
>>>> smreddy2004 at gmail.com> wrote:
>>>>
>>>> > Hi,
>>>> >
>>>> > Hibernate provides simple configuration properties to enable batch
>>>> inserts
>>>> > and updates using "hibernate.order_inserts" and
>>>> "hibernate.order_updates"
>>>> > respectively. These setting allow hibernate to sort the insert and
>>>> update
>>>> > statements and process them in batches efficiently.
>>>> >
>>>> > But we don't have such a configuration to sort or batch delete
>>>> statements
>>>> > efficiently. Especially with CascadeType.DELETE we can see that delete
>>>> > statements are not batched effectively and could result in extra
>>>> network
>>>> > calls to the database for deletion.(Refer:
>>>> >
>>>> >
>>>> http://vladmihalcea.com/2015/03/26/how-to-batch-delete-statements-with-hibernate/
>>>> > )
>>>> >
>>>> > So I am thinking wouldn't it be a good feature to have hibernate
>>>> support
>>>> > similar configuration, say "hibernate.order_deletes", to enable batch
>>>> > deletes similar to updates and inserts.
>>>> >
>>>> > Cheers,
>>>> > Madhu.
>>>> > _______________________________________________
>>>> > 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 dreborier at gmail.com  Thu Jan 28 07:13:34 2016
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 28 Jan 2016 12:13:34 +0000
Subject: [hibernate-dev] JDBC warnings performance matter
In-Reply-To: <CADGJaX_J4jmm6NhRNXXUaU7+Kn8qibMN2XhGY+wKOjUp5VZjcg@mail.gmail.com>
References: <CA+gWKMD2J=2QCn8id9AniJqjEd6fi3SksDwSMaPCSkqyhJU+MQ@mail.gmail.com>
	<69A87977-39D9-46DC-8D22-36AE81BD5406@hibernate.org>
	<CADGJaX_J4jmm6NhRNXXUaU7+Kn8qibMN2XhGY+wKOjUp5VZjcg@mail.gmail.com>
Message-ID: <CAL00eSRTuuj4ez79Bfe0Vef2r1hDDOX1=6jvNsADN0w83NGVSQ@mail.gmail.com>

I agree with providing a specific property to enable this behaviour.

I noticed also that handleAndClearWarnings(Connection
connection,WarningHandler handler) does the walking without checking for
the log level.




On 28 January 2016 at 07:59, Gunnar Morling <gunnar at hibernate.org> wrote:

> Is the call also expensive if there are no SQL warnings (i.e. null is
> returned, so no further walking is required)?
>
> It'd be my hope that drivers should be able to fetch the first warning
> - if any - upon statement execution without further round-trips. So
> getWarnings() would be cheap if no warnings exist. In that case people
> should IMHO actually fix the warnings instead of complaining that
> reporting them takes time.
>
> If it is a general perf issue also if no SQL warnings exist, +1 for
> having a property for opting into logging them.
>
> 2016-01-28 8:46 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > If that?s effectively widespread, I think indeed we should guard this
> feature with an explicit property.
> > It?s not necessarily easy to anticipate such consequences when designing
> things.
> > In insight, something more explicit looks better.
> >
> >> On 28 Jan 2016, at 06:25, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> wrote:
> >>
> >> Hi,
> >>
> >> The guys at Plumbr wrote an article about how MySQL JDBC warnings are
> >> handled by Hibernate:
> >>
> >>
> https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate
> >>
> >> I remember seeing this issue on StackOverflow too and I was curious if
> you
> >> want to tweak it a little bit.
> >> I also agree that relying on the log levels to prevent fetching warnings
> >> might come as a surprise to many users and we should document this
> behavior.
> >>
> >> We could also have a hibernate.jdbc.log.warnings boolean property to
> >> control whether we want to log those warnings or not.
> >> This way, if users set the logger level to WARN, they will see the logs
> >> generated by the framework stack and the JDBC warnings will be logged
> only
> >> if this configuration property is true.
> >>
> >> What do you think?
> >>
> >> Vlad
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu Jan 28 08:00:35 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 Jan 2016 13:00:35 +0000
Subject: [hibernate-dev] JDBC warnings performance matter
In-Reply-To: <CAL00eSRTuuj4ez79Bfe0Vef2r1hDDOX1=6jvNsADN0w83NGVSQ@mail.gmail.com>
References: <CA+gWKMD2J=2QCn8id9AniJqjEd6fi3SksDwSMaPCSkqyhJU+MQ@mail.gmail.com>
	<69A87977-39D9-46DC-8D22-36AE81BD5406@hibernate.org>
	<CADGJaX_J4jmm6NhRNXXUaU7+Kn8qibMN2XhGY+wKOjUp5VZjcg@mail.gmail.com>
	<CAL00eSRTuuj4ez79Bfe0Vef2r1hDDOX1=6jvNsADN0w83NGVSQ@mail.gmail.com>
Message-ID: <CAFdSV9uKfD0UtMuS7RFLcAc_kfyjPgRcm7qoseYJ8CsHZff3pA@mail.gmail.com>

+1 to allow a setting to control *logging* of SQLWarnings.  I find it silly
that MySQL handle it this way (I can only find reference to MySQL when I
google search for `JDBC getSQLWarnings performance`) in terms of it being
such a performance hit.

However I really do not like the idea of fencing the *clearing* of
SQLWarnings based on this setting.

On Thu, Jan 28, 2016 at 6:14 AM andrea boriero <dreborier at gmail.com> wrote:

> I agree with providing a specific property to enable this behaviour.
>
> I noticed also that handleAndClearWarnings(Connection
> connection,WarningHandler handler) does the walking without checking for
> the log level.
>
>
>
>
> On 28 January 2016 at 07:59, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > Is the call also expensive if there are no SQL warnings (i.e. null is
> > returned, so no further walking is required)?
> >
> > It'd be my hope that drivers should be able to fetch the first warning
> > - if any - upon statement execution without further round-trips. So
> > getWarnings() would be cheap if no warnings exist. In that case people
> > should IMHO actually fix the warnings instead of complaining that
> > reporting them takes time.
> >
> > If it is a general perf issue also if no SQL warnings exist, +1 for
> > having a property for opting into logging them.
> >
> > 2016-01-28 8:46 GMT+01:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> > > If that?s effectively widespread, I think indeed we should guard this
> > feature with an explicit property.
> > > It?s not necessarily easy to anticipate such consequences when
> designing
> > things.
> > > In insight, something more explicit looks better.
> > >
> > >> On 28 Jan 2016, at 06:25, Vlad Mihalcea <mihalcea.vlad at gmail.com>
> > wrote:
> > >>
> > >> Hi,
> > >>
> > >> The guys at Plumbr wrote an article about how MySQL JDBC warnings are
> > >> handled by Hibernate:
> > >>
> > >>
> >
> https://plumbr.eu/blog/io/how-we-accidentally-doubled-our-jdbc-traffic-with-hibernate
> > >>
> > >> I remember seeing this issue on StackOverflow too and I was curious if
> > you
> > >> want to tweak it a little bit.
> > >> I also agree that relying on the log levels to prevent fetching
> warnings
> > >> might come as a surprise to many users and we should document this
> > behavior.
> > >>
> > >> We could also have a hibernate.jdbc.log.warnings boolean property to
> > >> control whether we want to log those warnings or not.
> > >> This way, if users set the logger level to WARN, they will see the
> logs
> > >> generated by the framework stack and the JDBC warnings will be logged
> > only
> > >> if this configuration property is true.
> > >>
> > >> What do you think?
> > >>
> > >> Vlad
> > >> _______________________________________________
> > >> 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 steve at hibernate.org  Thu Jan 28 07:52:06 2016
From: steve at hibernate.org (sebersole)
Date: Thu, 28 Jan 2016 04:52:06 -0800 (PST)
Subject: [hibernate-dev] HHH-6726 LONG and LONG RAW column types in
 Oracle
In-Reply-To: <CA+gWKMAcmkKtnK2jtX2S2=zWi+MSrj7x_BEwrL_ib7Je7xwnhA@mail.gmail.com>
References: <CAFdSV9sQTjvvCnTwis+qipHprg7=FR44GKAx5y9P-Mw4UdpwPg@mail.gmail.com>
	<CAFdSV9syD2MhdOaeMvJ_UjyKj-W0xLTXT_w5SL-FsJQDDVDWpw@mail.gmail.com>
	<CA+gWKMAcmkKtnK2jtX2S2=zWi+MSrj7x_BEwrL_ib7Je7xwnhA@mail.gmail.com>
Message-ID: <1453985526907-1243.post@n6.nabble.com>

-1 for me. 



--
View this message in context: http://hibernate-development.74578.x6.nabble.com/Re-hibernate-dev-HHH-6726-LONG-and-LONG-RAW-column-types-in-Oracle-tp1224p1243.html
Sent from the Hibernate Development mailing list archive at Nabble.com.

From sanne at hibernate.org  Thu Jan 28 09:23:17 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 28 Jan 2016 14:23:17 +0000
Subject: [hibernate-dev] [Search] Travis support
In-Reply-To: <CALt0+o-D3h_xoZ52CC34BniDeuMVZUHHAH7u5aQmFPeGmZJG9g@mail.gmail.com>
References: <CALt0+o-D3h_xoZ52CC34BniDeuMVZUHHAH7u5aQmFPeGmZJG9g@mail.gmail.com>
Message-ID: <CAFm4XO3-+HtHHT7W8J8bviAM+R3G3U3q44i4RcYotf1i=dvPHA@mail.gmail.com>

Hi Guillaume,
I am a bit skeptical as we have CI working already on ci.hibernate.org
and having limited people we can't really afford to fix things which
already work.
That said, this does look good, and it's certainly positive that we
can get some free computation resources from travis.org as our AWS
bills are getting high.

Definitely positive that the build configurations are versioned; we
have auditing of configuration changes on Jenkins [ci.hibernate.org]
but having it in git looks very nice. I'm not entirely convinced about
having the job configurations within the repository itself though -
there should be some freedom in running different combinations, and
try new job configurations without having to send pull requests; not
least branches will go out of synch.
There is a jenkins plugin which will take the job configuration from
the repository if we think that is important: I played with it but it
didn't seem very mature when I tried the first Alpha release.

The Infinispan and WildFly teams have switched from Jenkins to
TeamCity and are very happy with it; one of the reasons for them to
prefer it over Jenkins is that it does a great job at tracking
evolution over time of failures of a specific test: you can examine
the build stability from various perspectives. But it's not OSS so it
loses some points there.

Another strong candidate which we discusses some times is to use
Atlassian's Bamboo. That seems another very strong product, and would
have the additional benefit of great integration with JIRA which I
think we all love, and we get excellent help from Atlassian as they
sponsor our JIRA installation. Using Bamboo could help us streamline
some aspects of the release process and I hear it's very easy to setup
and maintain.

Finally, from some reviews and documentation I honestly think that GO
is actually the best platform (although not having much experience
with all these I'm not counting my own opinion very strongly). And it
was recently open sourced.

To summarize what I like of Travis:
 - simple configuration
 - not much maintenance from our side
 - your recommendation counts
 - they pay the bills?
 - you say that it's very popular among Java developers.

About the popularity point, you surprised me. I honestly thought that
we should stay on Jenkins because that was the most popular one. Do
you have some data to back that nowadays people are more familiar with
Travis?

Finally I have been burned several times by not having "root access"
on the whole thing. I guess Docker might make this reasoning moot now,
but it's something to consider.
It's also quite important that we make sure our releases are created
in a reliable environment, so there's the trust issue of delegating
the keys to the kingdom to a third party. I'd even like it we could
start "signing" the artifacts we release as some users mentioned that
this would be important for them.

So I think that we might move some (several?) jobs to Travis but we'd
still want some job to run on our own platform - like the releases and
that implies jobs which test releases regularly - and then I'm not
sure if we want to have people necessarily familiarize with multiple
different UIs ?

Sorry to be skeptical, I didn't mean to stress the negative aspects
but to clarify that there are many aspects to consider for such a
move.
I'm definitely open to consider using it for a subset of jobs, like
you mentioned the PR review system might be a good fit.
It's also a good thing for sure to test in additional environments:
can it also run jobs on Windows and OSX ? We're missing that.. we
could fix the lack of Windows via AWS but that has a steep price tag..
I'll rather volunteer an old laptop from home.

Thanks,
Sanne

On 27 January 2016 at 23:40, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi,
>
> As mentioned in our last discussion, I explored adding Travis support to
> Search.
>
> The diff is here:
> https://github.com/gsmet/hibernate-search/commit/cbd2c1fff05532974823da572795d53cb8b9d26a
> (yes it's short but it was a long road :))
>
> I had to raise a bit the JGroups timeout for one test and had to fix
> TestRunnerStandalone
> so that it effectively uses the configuration from the profile (this change
> is not specific to Travis and should be committed anyway).
>
> The result is here:
> https://travis-ci.org/gsmet/hibernate-search
>
> What I like in Travis:
> - The CI configuration is code and is versioned
> - Parallelization with a *lot* of resources
> - The ability to build a test matrix very easily
> - Complete isolation as each build is run in its own Docker container
>
> What is less cool:
> - The only way to get the logs is to ship them to AWS S3 - that said, I did
> it and it's pretty straightforward as it's well integrated (I commented out
> the code in the .travis.yml for now)
> - It might seem less flexible as we are depending on the Travis
> infrastructure (for instance, I created a ticket to ask for the support of
> JDK 9: https://github.com/travis-ci/travis-ci/issues/5520) but in fact, you
> can do whatever you want: see https://github.com/Blazebit/blaze-persistence
> .travis.yml file for a comprehensive example
>
> So if we move to Travis, I think the regular builds could run on Travis and
> we could keep Jenkins for specific ones (deploy/release).
>
> I'll take a look at OGM tomorrow. Travis supports out of the box most of
> the NoSQL databases (https://docs.travis-ci.com/user/database-setup/) so
> I'm pretty curious to see how it goes.
>
> Thoughts?
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Jan 28 11:04:18 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 Jan 2016 16:04:18 +0000
Subject: [hibernate-dev] [Search] Travis support
In-Reply-To: <CAFm4XO3-+HtHHT7W8J8bviAM+R3G3U3q44i4RcYotf1i=dvPHA@mail.gmail.com>
References: <CALt0+o-D3h_xoZ52CC34BniDeuMVZUHHAH7u5aQmFPeGmZJG9g@mail.gmail.com>
	<CAFm4XO3-+HtHHT7W8J8bviAM+R3G3U3q44i4RcYotf1i=dvPHA@mail.gmail.com>
Message-ID: <CAFdSV9s5M0=H-Nyod_=Ze3gUdqMPCHUhJOFDWJn6n3UG=DH3dQ@mail.gmail.com>

I do not know how to quantify "popularity", but I do know I have seen lots
of projects using travis for commit validation.

TBH my only concern would be access to the results.  And that is more an
unknown.  As I have never used Travis CI I do not know how its UI works.
Guillaume do you have project in Travis you can point us to so that we can
see?

On Thu, Jan 28, 2016 at 8:24 AM Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Guillaume,
> I am a bit skeptical as we have CI working already on ci.hibernate.org
> and having limited people we can't really afford to fix things which
> already work.
> That said, this does look good, and it's certainly positive that we
> can get some free computation resources from travis.org as our AWS
> bills are getting high.
>
> Definitely positive that the build configurations are versioned; we
> have auditing of configuration changes on Jenkins [ci.hibernate.org]
> but having it in git looks very nice. I'm not entirely convinced about
> having the job configurations within the repository itself though -
> there should be some freedom in running different combinations, and
> try new job configurations without having to send pull requests; not
> least branches will go out of synch.
> There is a jenkins plugin which will take the job configuration from
> the repository if we think that is important: I played with it but it
> didn't seem very mature when I tried the first Alpha release.
>
> The Infinispan and WildFly teams have switched from Jenkins to
> TeamCity and are very happy with it; one of the reasons for them to
> prefer it over Jenkins is that it does a great job at tracking
> evolution over time of failures of a specific test: you can examine
> the build stability from various perspectives. But it's not OSS so it
> loses some points there.
>
> Another strong candidate which we discusses some times is to use
> Atlassian's Bamboo. That seems another very strong product, and would
> have the additional benefit of great integration with JIRA which I
> think we all love, and we get excellent help from Atlassian as they
> sponsor our JIRA installation. Using Bamboo could help us streamline
> some aspects of the release process and I hear it's very easy to setup
> and maintain.
>
> Finally, from some reviews and documentation I honestly think that GO
> is actually the best platform (although not having much experience
> with all these I'm not counting my own opinion very strongly). And it
> was recently open sourced.
>
> To summarize what I like of Travis:
>  - simple configuration
>  - not much maintenance from our side
>  - your recommendation counts
>  - they pay the bills?
>  - you say that it's very popular among Java developers.
>
> About the popularity point, you surprised me. I honestly thought that
> we should stay on Jenkins because that was the most popular one. Do
> you have some data to back that nowadays people are more familiar with
> Travis?
>
> Finally I have been burned several times by not having "root access"
> on the whole thing. I guess Docker might make this reasoning moot now,
> but it's something to consider.
> It's also quite important that we make sure our releases are created
> in a reliable environment, so there's the trust issue of delegating
> the keys to the kingdom to a third party. I'd even like it we could
> start "signing" the artifacts we release as some users mentioned that
> this would be important for them.
>
> So I think that we might move some (several?) jobs to Travis but we'd
> still want some job to run on our own platform - like the releases and
> that implies jobs which test releases regularly - and then I'm not
> sure if we want to have people necessarily familiarize with multiple
> different UIs ?
>
> Sorry to be skeptical, I didn't mean to stress the negative aspects
> but to clarify that there are many aspects to consider for such a
> move.
> I'm definitely open to consider using it for a subset of jobs, like
> you mentioned the PR review system might be a good fit.
> It's also a good thing for sure to test in additional environments:
> can it also run jobs on Windows and OSX ? We're missing that.. we
> could fix the lack of Windows via AWS but that has a steep price tag..
> I'll rather volunteer an old laptop from home.
>
> Thanks,
> Sanne
>
> On 27 January 2016 at 23:40, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
> > Hi,
> >
> > As mentioned in our last discussion, I explored adding Travis support to
> > Search.
> >
> > The diff is here:
> >
> https://github.com/gsmet/hibernate-search/commit/cbd2c1fff05532974823da572795d53cb8b9d26a
> > (yes it's short but it was a long road :))
> >
> > I had to raise a bit the JGroups timeout for one test and had to fix
> > TestRunnerStandalone
> > so that it effectively uses the configuration from the profile (this
> change
> > is not specific to Travis and should be committed anyway).
> >
> > The result is here:
> > https://travis-ci.org/gsmet/hibernate-search
> >
> > What I like in Travis:
> > - The CI configuration is code and is versioned
> > - Parallelization with a *lot* of resources
> > - The ability to build a test matrix very easily
> > - Complete isolation as each build is run in its own Docker container
> >
> > What is less cool:
> > - The only way to get the logs is to ship them to AWS S3 - that said, I
> did
> > it and it's pretty straightforward as it's well integrated (I commented
> out
> > the code in the .travis.yml for now)
> > - It might seem less flexible as we are depending on the Travis
> > infrastructure (for instance, I created a ticket to ask for the support
> of
> > JDK 9: https://github.com/travis-ci/travis-ci/issues/5520) but in fact,
> you
> > can do whatever you want: see
> https://github.com/Blazebit/blaze-persistence
> > .travis.yml file for a comprehensive example
> >
> > So if we move to Travis, I think the regular builds could run on Travis
> and
> > we could keep Jenkins for specific ones (deploy/release).
> >
> > I'll take a look at OGM tomorrow. Travis supports out of the box most of
> > the NoSQL databases (https://docs.travis-ci.com/user/database-setup/) so
> > I'm pretty curious to see how it goes.
> >
> > Thoughts?
> >
> > --
> > Guillaume
> > _______________________________________________
> > 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 guillaume.smet at gmail.com  Thu Jan 28 11:21:02 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 28 Jan 2016 17:21:02 +0100
Subject: [hibernate-dev] [Search] Travis support
In-Reply-To: <CAFdSV9s5M0=H-Nyod_=Ze3gUdqMPCHUhJOFDWJn6n3UG=DH3dQ@mail.gmail.com>
References: <CALt0+o-D3h_xoZ52CC34BniDeuMVZUHHAH7u5aQmFPeGmZJG9g@mail.gmail.com>
	<CAFm4XO3-+HtHHT7W8J8bviAM+R3G3U3q44i4RcYotf1i=dvPHA@mail.gmail.com>
	<CAFdSV9s5M0=H-Nyod_=Ze3gUdqMPCHUhJOFDWJn6n3UG=DH3dQ@mail.gmail.com>
Message-ID: <CALt0+o8NOS7JcrgtjzQmauK8qzDNEaqXowq-DcM=5r5v2ceNpw@mail.gmail.com>

Yep: https://travis-ci.org/gsmet/hibernate-search

As already mentioned, if you want to get the results of the test, you can
push them to an AWS S3 bucket.

-- 
Guillaume

From guillaume.smet at gmail.com  Thu Jan 28 12:16:12 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 28 Jan 2016 18:16:12 +0100
Subject: [hibernate-dev] [Search] ElasticSearch - DSL
Message-ID: <CALt0+o8epDrTwnnf6gb==Da-wYhQGvSFnWFTbJ+K4WwqpdVpXw@mail.gmail.com>

Hi all (and especially Gunnar),

I dug a bit in your ElasticSearch work today as I wanted to give a try to
the facet implementation and I was wondering if maybe we should use the
ElasticSearch DSL to build the queries instead of building raw JSON strings.

I experimented here:
https://github.com/gsmet/hibernate-search/commit/18737f720a1200b125adf2bb0465b52d5d2b3ca3

I think the code is a bit clearer now. I haven't changed all the queries in
the tests so I kept the fromJson method in ElasticSearchQueries but I think
we should remove it and rely on the DSL: I'll wait for your opinion as you
might have had a very good reason to not use the DSL.

One of the challenges waiting for us will be to transform the Lucene
Filters into proper Elastic Search queries.

-- 
Guillaume

From guillaume.smet at gmail.com  Thu Jan 28 12:26:06 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 28 Jan 2016 18:26:06 +0100
Subject: [hibernate-dev] [Search] Travis support
In-Reply-To: <CAFm4XO3-+HtHHT7W8J8bviAM+R3G3U3q44i4RcYotf1i=dvPHA@mail.gmail.com>
References: <CALt0+o-D3h_xoZ52CC34BniDeuMVZUHHAH7u5aQmFPeGmZJG9g@mail.gmail.com>
	<CAFm4XO3-+HtHHT7W8J8bviAM+R3G3U3q44i4RcYotf1i=dvPHA@mail.gmail.com>
Message-ID: <CALt0+o9zbFU5yeH-aPpq4MeRO4SU+EBNiNpbR_hHw2Ybwdh9pA@mail.gmail.com>

Hi Sanne,

On Thu, Jan 28, 2016 at 3:23 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I am a bit skeptical as we have CI working already on ci.hibernate.org
> and having limited people we can't really afford to fix things which
> already work.
>

I perfectly understand that. I wanted to experiment it without bothering
you about it.


> To summarize what I like of Travis:
>  - simple configuration
>  - not much maintenance from our side
>  - your recommendation counts
>  - they pay the bills?
>  - you say that it's very popular among Java developers.
>
> About the popularity point, you surprised me. I honestly thought that
> we should stay on Jenkins because that was the most popular one. Do
> you have some data to back that nowadays people are more familiar with
> Travis?
>

It's very widespread in the Open Source projects running on GitHub, either
in Java, Ruby, PHP, Python and so on.

HikariCP for instance uses Travis and there are a lot of others projects
using it: https://github.com/brettwooldridge/HikariCP .

We use Jenkins at my company too for our private projects but we use Travis
for our Open Source ones.


> Finally I have been burned several times by not having "root access"
> on the whole thing. I guess Docker might make this reasoning moot now,
> but it's something to consider.
> It's also quite important that we make sure our releases are created
> in a reliable environment, so there's the trust issue of delegating
> the keys to the kingdom to a third party. I'd even like it we could
> start "signing" the artifacts we release as some users mentioned that
> this would be important for them.
>

Yes, Travis won't replace the release tasks. I think it's good for the day
to day builds and PR builds and we should only use it for that - if we
decide to use it.


> Sorry to be skeptical, I didn't mean to stress the negative aspects
> but to clarify that there are many aspects to consider for such a
> move.
> I'm definitely open to consider using it for a subset of jobs, like
> you mentioned the PR review system might be a good fit.
> It's also a good thing for sure to test in additional environments:
> can it also run jobs on Windows and OSX ? We're missing that.. we
> could fix the lack of Windows via AWS but that has a steep price tag..
> I'll rather volunteer an old laptop from home.
>

They have OSX support but it's sparse. It's mostly here to test MacOS and
iOS apps. They don't have Windows support.

-- 
Guillaume

From gunnar at hibernate.org  Thu Jan 28 12:52:56 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 28 Jan 2016 18:52:56 +0100
Subject: [hibernate-dev] [Search] ElasticSearch - DSL
In-Reply-To: <CALt0+o8epDrTwnnf6gb==Da-wYhQGvSFnWFTbJ+K4WwqpdVpXw@mail.gmail.com>
References: <CALt0+o8epDrTwnnf6gb==Da-wYhQGvSFnWFTbJ+K4WwqpdVpXw@mail.gmail.com>
Message-ID: <CADGJaX_ACPB0rWDJiRxRUqm99Sn7X-epejxziAZXFCBXpgDHBw@mail.gmail.com>

Hi Guillaume,

Indeed there is a reason for not using the DSL: I wanted to avoid the
dependency to the ES libraries.

They in turn pull in Lucene in a version which potentially differs
from the Lucene version used by Hibernate Search itself. Also I wanted
to leave the door open for supporting multiple (potentially
incompatibly altered) versions of ES backends, say ES 2 and a future
ES 3.

All in all, these advantages outweigh the slightly simpler usage of
the DSL to me.

> One of the challenges waiting for us will be to transform the Lucene
> Filters into proper Elastic Search queries

I haven't looked into filters yet, but it's high on my agenda.

Do you think it's more difficult than transforming actual queries?
Btw. the ES PoC allows to pass in plain ES queries, at some point
these should be allowed to contain filter clauses, too (this might
even work already, haven't tried it).

Cheers,

--Gunnar



2016-01-28 18:16 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:
> Hi all (and especially Gunnar),
>
> I dug a bit in your ElasticSearch work today as I wanted to give a try to
> the facet implementation and I was wondering if maybe we should use the
> ElasticSearch DSL to build the queries instead of building raw JSON strings.
>
> I experimented here:
> https://github.com/gsmet/hibernate-search/commit/18737f720a1200b125adf2bb0465b52d5d2b3ca3
>
> I think the code is a bit clearer now. I haven't changed all the queries in
> the tests so I kept the fromJson method in ElasticSearchQueries but I think
> we should remove it and rely on the DSL: I'll wait for your opinion as you
> might have had a very good reason to not use the DSL.
>
> One of the challenges waiting for us will be to transform the Lucene
> Filters into proper Elastic Search queries.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu Jan 28 13:27:19 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 Jan 2016 18:27:19 +0000
Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re: 5.1
 tentative release date)
In-Reply-To: <CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
	<CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
Message-ID: <CAFdSV9t=XTi=uxU625oEKKRbK5=o7ikYXzP6bmN39MCrKR+ffQ@mail.gmail.com>

For this to work will require some significant changes.  The main one being
to combine JPA's support for schema generation along
with SchemaManagementTool.  The reason being simply that I will need to
encapsulate the interpretation of all these settings behind
the SchemaManagementTool facade in order for things to properly
replace SchemaManagementTool as Gunnar suggests.

I am starting this work now on top of the work Gunnar has already done on
the PR he sent[1].  But that work is just the tip of the iceberg.  So if
you have input to this, speak soon.


[1] https://github.com/hibernate/hibernate-orm/pull/1231

On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar at hibernate.org> wrote:

> I went for the proposed intermediary step to avoid breaking the API of
> SchemaManagementTool and its delegates. If you have a way for not
> breaking the API or think breaking it is alright, then +1 for doing
> the ProperSolution? in 5.1.
>
> What would it comprise, changing the delegate methods such as
> doCreate() to expect a single parameter object providing all the
> required info? Target could be a part of this, just an enum probably,
> based on wich delegates would do their thing. If it's that, I can try
> and help out with it.
>
> Regarding the release schedule, I'd personally be fine with pushing it
> a bit back, but then I don't know whether there are any other hard
> timelines to be met.
>
>
> 2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > I'd like to get this work into 5.1.  But, as much as possible, I'd like
> to
> > get the ProperSolution in place rather than just a
> StepInTheRightDirection.
> > If we need to push this date 2-4 weeks I am ok with that.  That would
> help
> > us coordinate with Infinispan 8.2 schedule (iiuc) for
> hibernate-infinispan,
> > not to mention I still have to review the work Vlad has done on the docs
> > again as well as polish the load-by-multi-id API[1].
> >
> > [1] Sanne still waiting on your feedback to the open question of internal
> > routing of those calls.
> >
> > On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >>
> >> Hi Steve,
> >>
> >> As discussed on IRC, I tried plugging in my own SchemaManagementTool
> >> and delegates and letting them do the initialization work required for
> >> OGM.
> >>
> >> I am hitting a wall though when it comes to the usage in the
> >> SchemaExport controller: As it's invoking doCreate() and doDrop()
> >> right in the constructor with a "fake" target for delegating the SQL
> >> statements, I am bitten by the fact that SchemaExport is instantiated
> >> twice in SessionFactoryImpl (once for create, once for drop at
> >> shutdown), so I see to invocations to doCreate() and doDrop(). Also I
> >> am lacking the knowledge of what's passed as Target for the controller
> >> invocation.
> >>
> >> So I went ahead and changed SchemaExport to invoke SchemaCreator and
> >> -Dropper only in execute(), passing them actual Target implementations
> >> as it's done in SchemaUpdate, too. It's not yet what you described as
> >> the ultimate goal (not looping back to Target), but IMO it's a step
> >> into the right direction, not the least making things consistent
> >> between SchemaExport and SchemaUpdate and also leaving APIs largely
> >> unchanged for the time being. With that I should be able to do it on
> >> the OGM side as you suggested, essentially ignoring the
> >> Target/Exporter stuff.
> >>
> >> I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231
> >> for the change. Let me know what you think.
> >>
> >> Cheers,
> >>
> >> --Gunnar
> >>
> >>
> >> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> > I am not sure I am a big fan of The String->Object change
> specifically.
> >> > In
> >> > theory it sounds great.  But there is a major premise in schema
> tooling
> >> > around the idea of the actions being reduce-able to Strings.  That's
> >> > important not just for SQL, but for the idea of writing to a file as
> >> > well.
> >> > It also affects the whole concept of Exporter/Exportable.
> >> >
> >> > The ultimate design goal here is to unify schema creation and dropping
> >> > across native and JPA requirements.  I just simply have not had the
> time
> >> > to
> >> > work on that.  This would all happen "behind" SchemaManagementTool and
> >> > friends.  SchemaExport, etc are actually just controllers responsible
> >> > for
> >> > coordinating the calls into the SchemaManagementTool delegates.  The
> >> > main
> >> > problem at the moment IMO is that Target gets passed into these
> >> > SchemaManagementTool delegates.  Ideally, and certainly this would fit
> >> > with
> >> > your case, I think we want SchemaManagementTool or its delegates to
> >> > handle
> >> > interpreting the "arguments".  This was part of the intent of
> developing
> >> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now;
> >> > the
> >> > idea was to encapsulate the settings each tool needs to operate and
> >> > isolate
> >> > the process of building/interpreting those args.
> >> >
> >> > The next step I wanted to look at there was to morph CommandLineArgs
> >> > into a
> >> > more generic "parameter object" for initializing the actual
> >> > SchemaManagementTool delegates.
> >> >
> >> > The idea is that the more we can push into SchemaManagementTool and
> its
> >> > delegates the more pluggable this entire process becomes.  Ultimately,
> >> > as I
> >> > mentioned above, I just do not think it is feasible for ORM and OGM to
> >> > share all of these implementation contracts.  Forcing a switch from
> >> > String
> >> > (the DDL) arguments to some amorphic Object reinforces that in my
> mind.
> >> > But that would not stop OGM from completely swapping
> >> > SchemaManagementTool
> >> > and its delegates and simply not using Target, Exporters, etc.
> >> >
> >> >
> >> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar at hibernate.org>
> >> > wrote:
> >> >
> >> >> Hi Steve,
> >> >>
> >> >> One thing useful to have for OGM would be a generalization of the
> >> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
> >> >> all of them are "schemaless", e.g. Cassandra works with a fixed
> >> >> schema, and while MongoDB largely is schemaless, we still want to
> >> >> create stuff like indexes in the database.
> >> >>
> >> >> I took a look and found that SchemaManagementTool as a pluggable
> >> >> service already goes halfway into that direction. The issue with it
> is
> >> >> that I cannot replace the list of exporters used by SchemaExport nor
> >> >> the list of tool targets used by SchemaUpdate. Having a pluggable
> >> >> service allowing me to customize that with an OGM-specific
> >> >> implementation should do the trick.
> >> >>
> >> >> As per some comments in the code, SchemaExport seems to be in some
> >> >> intermediary state, where the ops are not executed directly through
> >> >> the targets passed to SchemaCreator/Dropper but are read into String
> >> >> arrays which are then passed on to separate exporters. I suppose part
> >> >> of that work should be to consolidate this and basically follow the
> >> >> same approach as used in SchemaUpdate?
> >> >>
> >> >> Another facet is that for some OGM grid dialects we'd need another
> >> >> representation of commands than Strings, as not all the backends have
> >> >> a DDL but expect API invocations for that purpose. For that it'd be
> >> >> required to change Target#accept(String) into accept(Object) so we
> can
> >> >> pass some kind of command object. File exports would only work in a
> >> >> limited fashion, but we could live with that. Schema
> creation/dropping
> >> >> bound to the SF lifecycle is what I am after here.
> >> >>
> >> >> I'd be willing to work on this once we agree on the general approach.
> >> >>
> >> >> Any thoughts?
> >> >>
> >> >> Thanks,
> >> >>
> >> >> --Gunnar
> >> >>
> >> >>
> >> >>
> >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com
> >:
> >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <
> steve at hibernate.org>
> >> >> wrote:
> >> >> >
> >> >> >> If you clean up the conflicts I can look for 5.1
> >> >> >>
> >> >> >
> >> >> > Done!
> >> >> >
> >> >> > --
> >> >> > Guillaume
> >> >> > _______________________________________________
> >> >> > 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 guillaume.smet at gmail.com  Thu Jan 28 14:17:29 2016
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 28 Jan 2016 20:17:29 +0100
Subject: [hibernate-dev] [Search] ElasticSearch - DSL
In-Reply-To: <CADGJaX_ACPB0rWDJiRxRUqm99Sn7X-epejxziAZXFCBXpgDHBw@mail.gmail.com>
References: <CALt0+o8epDrTwnnf6gb==Da-wYhQGvSFnWFTbJ+K4WwqpdVpXw@mail.gmail.com>
	<CADGJaX_ACPB0rWDJiRxRUqm99Sn7X-epejxziAZXFCBXpgDHBw@mail.gmail.com>
Message-ID: <CALt0+o9VRWNdpsf6C2i_MejBQ4GaB=WMMtr=Z8FXsG-WosecVQ@mail.gmail.com>

Hey Gunnar,

On Thu, Jan 28, 2016 at 6:52 PM, Gunnar Morling <gunnar at hibernate.org>
wrote:
>
> They in turn pull in Lucene in a version which potentially differs
> from the Lucene version used by Hibernate Search itself. Also I wanted
> to leave the door open for supporting multiple (potentially
> incompatibly altered) versions of ES backends, say ES 2 and a future
> ES 3.
>
> All in all, these advantages outweigh the slightly simpler usage of
> the DSL to me.


Yeah, I understand your concerns. Apart from the more complicated usage,
I'm afraid building raw JSON is going to be harder to maintain. We only do
simple things atm and I don't find the JSON manipulation very readable nor
very solid. It's going to be worse when we will add aggregations for
faceting and so on.

As for the dependencies, I could take a look at shading the necessary
classes for the builders and see if we can come up with something clean? I
don't know if it's something acceptable for an Hibernate project.

It doesn't solve the multi versions thingy but if they change the API, it's
going to be quite ugly to generate different JSON queries anyway, don't you
think?


> > One of the challenges waiting for us will be to transform the Lucene
> > Filters into proper Elastic Search queries
>
> I haven't looked into filters yet, but it's high on my agenda.
>
> Do you think it's more difficult than transforming actual queries?
> Btw. the ES PoC allows to pass in plain ES queries, at some point
> these should be allowed to contain filter clauses, too (this might
> even work already, haven't tried it).
>

Yeah I saw you could inject native ES queries and that's also something
that worries me with the raw JSON approach. I find it much more
user-friendly to provide an API to build the queries.

(Using these various discussions to adjust how I work and be more compliant
with the Hibernate way of life :))

-- 
Guillaume

From gunnar at hibernate.org  Thu Jan 28 16:10:58 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 28 Jan 2016 22:10:58 +0100
Subject: [hibernate-dev] [Search] ElasticSearch - DSL
In-Reply-To: <CALt0+o9VRWNdpsf6C2i_MejBQ4GaB=WMMtr=Z8FXsG-WosecVQ@mail.gmail.com>
References: <CALt0+o8epDrTwnnf6gb==Da-wYhQGvSFnWFTbJ+K4WwqpdVpXw@mail.gmail.com>
	<CADGJaX_ACPB0rWDJiRxRUqm99Sn7X-epejxziAZXFCBXpgDHBw@mail.gmail.com>
	<CALt0+o9VRWNdpsf6C2i_MejBQ4GaB=WMMtr=Z8FXsG-WosecVQ@mail.gmail.com>
Message-ID: <CADGJaX8EemLhRFAAY4XAYe_3_t75Cx47+i2TSaWpVfrr16NE0Q@mail.gmail.com>

2016-01-28 20:17 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com>:
> Hey Gunnar,
>
> On Thu, Jan 28, 2016 at 6:52 PM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> They in turn pull in Lucene in a version which potentially differs
>> from the Lucene version used by Hibernate Search itself. Also I wanted
>> to leave the door open for supporting multiple (potentially
>> incompatibly altered) versions of ES backends, say ES 2 and a future
>> ES 3.
>>
>> All in all, these advantages outweigh the slightly simpler usage of
>> the DSL to me.
>
>
> Yeah, I understand your concerns. Apart from the more complicated usage, I'm
> afraid building raw JSON is going to be harder to maintain. We only do
> simple things atm and I don't find the JSON manipulation very readable nor
> very solid. It's going to be worse when we will add aggregations for
> faceting and so on.

I don't find too bad what we have atm. :) If becomes too much of a
burden at some point in the future, we still may reconsider.

A general credo we have is to make things as good for the user as
possible also if it means some more trouble for us internally. I think
sparing the user from dependency issues is worth the JSON crafting on
our side.

>
> As for the dependencies, I could take a look at shading the necessary
> classes for the builders and see if we can come up with something clean? I
> don't know if it's something acceptable for an Hibernate project.

Our experiences with shading are mixed; I think most don't like it.

It might work, but the issue remains that the ES JAR depends on a
specific Lucene version. We may be lucky and the query builder stuff
is nicely isolated from that so that there would be no problem by HS
itself using a different version. Still it'd appear as a potential
source of trouble to me.

The loose coupling via JSON is more practical IMHO. I'd not exclude
the builder stuff for all times, but right now it seems not worth it.

Btw. - I should have mentioned that in my first reply - our vision
regarding queries is to modify and generalize the HSEARCH query
builder DSL so it can emit queries for the backend du jour, be it
plain Lucene, ES or Solr. We just didn't get there yet :)

>
> It doesn't solve the multi versions thingy but if they change the API, it's
> going to be quite ugly to generate different JSON queries anyway, don't you
> think?

See above, I think some internal ugliness is ok if it helps the user
in a reasonable way.

>
>>
>> > One of the challenges waiting for us will be to transform the Lucene
>> > Filters into proper Elastic Search queries
>>
>> I haven't looked into filters yet, but it's high on my agenda.
>>
>> Do you think it's more difficult than transforming actual queries?
>> Btw. the ES PoC allows to pass in plain ES queries, at some point
>> these should be allowed to contain filter clauses, too (this might
>> even work already, haven't tried it).
>
>
> Yeah I saw you could inject native ES queries and that's also something that
> worries me with the raw JSON approach. I find it much more user-friendly to
> provide an API to build the queries.

Yes, fully agreed, hence the idea to enable the HSEARCH query DSL for
that. The native ES query injection is something I built to have
something functional quickly and it also might be helpful for people
giving HSEARCH a quick try.

>
> (Using these various discussions to adjust how I work and be more compliant
> with the Hibernate way of life :))

+1 Keep them coming :)

>
> --
> Guillaume

From gunnar at hibernate.org  Fri Jan 29 11:15:20 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 29 Jan 2016 17:15:20 +0100
Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re:
 5.1 tentative release date)
In-Reply-To: <CAFdSV9t=XTi=uxU625oEKKRbK5=o7ikYXzP6bmN39MCrKR+ffQ@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
	<CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
	<CAFdSV9t=XTi=uxU625oEKKRbK5=o7ikYXzP6bmN39MCrKR+ffQ@mail.gmail.com>
Message-ID: <CADGJaX88QHvuO8AJo47F=5nqq-HOsuRH_9dX4XyCkZVPFAr4ww@mail.gmail.com>

Hi Steve,

What you suggest sounds good. I've added a comment to
https://hibernate.atlassian.net/browse/HHH-10458 itself.

The reason why I didn't go for this from the beginning just was that I
didn't want to break the contract of SchemaCreator and the other
delegates.

--Gunnar




2016-01-28 19:27 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> For this to work will require some significant changes.  The main one being
> to combine JPA's support for schema generation along
> with SchemaManagementTool.  The reason being simply that I will need to
> encapsulate the interpretation of all these settings behind
> the SchemaManagementTool facade in order for things to properly
> replace SchemaManagementTool as Gunnar suggests.
>
> I am starting this work now on top of the work Gunnar has already done on
> the PR he sent[1].  But that work is just the tip of the iceberg.  So if
> you have input to this, speak soon.
>
>
> [1] https://github.com/hibernate/hibernate-orm/pull/1231
>
> On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> I went for the proposed intermediary step to avoid breaking the API of
>> SchemaManagementTool and its delegates. If you have a way for not
>> breaking the API or think breaking it is alright, then +1 for doing
>> the ProperSolution? in 5.1.
>>
>> What would it comprise, changing the delegate methods such as
>> doCreate() to expect a single parameter object providing all the
>> required info? Target could be a part of this, just an enum probably,
>> based on wich delegates would do their thing. If it's that, I can try
>> and help out with it.
>>
>> Regarding the release schedule, I'd personally be fine with pushing it
>> a bit back, but then I don't know whether there are any other hard
>> timelines to be met.
>>
>>
>> 2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > I'd like to get this work into 5.1.  But, as much as possible, I'd like
>> to
>> > get the ProperSolution in place rather than just a
>> StepInTheRightDirection.
>> > If we need to push this date 2-4 weeks I am ok with that.  That would
>> help
>> > us coordinate with Infinispan 8.2 schedule (iiuc) for
>> hibernate-infinispan,
>> > not to mention I still have to review the work Vlad has done on the docs
>> > again as well as polish the load-by-multi-id API[1].
>> >
>> > [1] Sanne still waiting on your feedback to the open question of internal
>> > routing of those calls.
>> >
>> > On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar at hibernate.org>
>> wrote:
>> >>
>> >> Hi Steve,
>> >>
>> >> As discussed on IRC, I tried plugging in my own SchemaManagementTool
>> >> and delegates and letting them do the initialization work required for
>> >> OGM.
>> >>
>> >> I am hitting a wall though when it comes to the usage in the
>> >> SchemaExport controller: As it's invoking doCreate() and doDrop()
>> >> right in the constructor with a "fake" target for delegating the SQL
>> >> statements, I am bitten by the fact that SchemaExport is instantiated
>> >> twice in SessionFactoryImpl (once for create, once for drop at
>> >> shutdown), so I see to invocations to doCreate() and doDrop(). Also I
>> >> am lacking the knowledge of what's passed as Target for the controller
>> >> invocation.
>> >>
>> >> So I went ahead and changed SchemaExport to invoke SchemaCreator and
>> >> -Dropper only in execute(), passing them actual Target implementations
>> >> as it's done in SchemaUpdate, too. It's not yet what you described as
>> >> the ultimate goal (not looping back to Target), but IMO it's a step
>> >> into the right direction, not the least making things consistent
>> >> between SchemaExport and SchemaUpdate and also leaving APIs largely
>> >> unchanged for the time being. With that I should be able to do it on
>> >> the OGM side as you suggested, essentially ignoring the
>> >> Target/Exporter stuff.
>> >>
>> >> I've filed ORM PR https://github.com/hibernate/hibernate-orm/pull/1231
>> >> for the change. Let me know what you think.
>> >>
>> >> Cheers,
>> >>
>> >> --Gunnar
>> >>
>> >>
>> >> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >> > I am not sure I am a big fan of The String->Object change
>> specifically.
>> >> > In
>> >> > theory it sounds great.  But there is a major premise in schema
>> tooling
>> >> > around the idea of the actions being reduce-able to Strings.  That's
>> >> > important not just for SQL, but for the idea of writing to a file as
>> >> > well.
>> >> > It also affects the whole concept of Exporter/Exportable.
>> >> >
>> >> > The ultimate design goal here is to unify schema creation and dropping
>> >> > across native and JPA requirements.  I just simply have not had the
>> time
>> >> > to
>> >> > work on that.  This would all happen "behind" SchemaManagementTool and
>> >> > friends.  SchemaExport, etc are actually just controllers responsible
>> >> > for
>> >> > coordinating the calls into the SchemaManagementTool delegates.  The
>> >> > main
>> >> > problem at the moment IMO is that Target gets passed into these
>> >> > SchemaManagementTool delegates.  Ideally, and certainly this would fit
>> >> > with
>> >> > your case, I think we want SchemaManagementTool or its delegates to
>> >> > handle
>> >> > interpreting the "arguments".  This was part of the intent of
>> developing
>> >> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc now;
>> >> > the
>> >> > idea was to encapsulate the settings each tool needs to operate and
>> >> > isolate
>> >> > the process of building/interpreting those args.
>> >> >
>> >> > The next step I wanted to look at there was to morph CommandLineArgs
>> >> > into a
>> >> > more generic "parameter object" for initializing the actual
>> >> > SchemaManagementTool delegates.
>> >> >
>> >> > The idea is that the more we can push into SchemaManagementTool and
>> its
>> >> > delegates the more pluggable this entire process becomes.  Ultimately,
>> >> > as I
>> >> > mentioned above, I just do not think it is feasible for ORM and OGM to
>> >> > share all of these implementation contracts.  Forcing a switch from
>> >> > String
>> >> > (the DDL) arguments to some amorphic Object reinforces that in my
>> mind.
>> >> > But that would not stop OGM from completely swapping
>> >> > SchemaManagementTool
>> >> > and its delegates and simply not using Target, Exporters, etc.
>> >> >
>> >> >
>> >> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <gunnar at hibernate.org>
>> >> > wrote:
>> >> >
>> >> >> Hi Steve,
>> >> >>
>> >> >> One thing useful to have for OGM would be a generalization of the
>> >> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases. Not
>> >> >> all of them are "schemaless", e.g. Cassandra works with a fixed
>> >> >> schema, and while MongoDB largely is schemaless, we still want to
>> >> >> create stuff like indexes in the database.
>> >> >>
>> >> >> I took a look and found that SchemaManagementTool as a pluggable
>> >> >> service already goes halfway into that direction. The issue with it
>> is
>> >> >> that I cannot replace the list of exporters used by SchemaExport nor
>> >> >> the list of tool targets used by SchemaUpdate. Having a pluggable
>> >> >> service allowing me to customize that with an OGM-specific
>> >> >> implementation should do the trick.
>> >> >>
>> >> >> As per some comments in the code, SchemaExport seems to be in some
>> >> >> intermediary state, where the ops are not executed directly through
>> >> >> the targets passed to SchemaCreator/Dropper but are read into String
>> >> >> arrays which are then passed on to separate exporters. I suppose part
>> >> >> of that work should be to consolidate this and basically follow the
>> >> >> same approach as used in SchemaUpdate?
>> >> >>
>> >> >> Another facet is that for some OGM grid dialects we'd need another
>> >> >> representation of commands than Strings, as not all the backends have
>> >> >> a DDL but expect API invocations for that purpose. For that it'd be
>> >> >> required to change Target#accept(String) into accept(Object) so we
>> can
>> >> >> pass some kind of command object. File exports would only work in a
>> >> >> limited fashion, but we could live with that. Schema
>> creation/dropping
>> >> >> bound to the SF lifecycle is what I am after here.
>> >> >>
>> >> >> I'd be willing to work on this once we agree on the general approach.
>> >> >>
>> >> >> Any thoughts?
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> --Gunnar
>> >> >>
>> >> >>
>> >> >>
>> >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <guillaume.smet at gmail.com
>> >:
>> >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <
>> steve at hibernate.org>
>> >> >> wrote:
>> >> >> >
>> >> >> >> If you clean up the conflicts I can look for 5.1
>> >> >> >>
>> >> >> >
>> >> >> > Done!
>> >> >> >
>> >> >> > --
>> >> >> > Guillaume
>> >> >> > _______________________________________________
>> >> >> > hibernate-dev mailing list
>> >> >> > hibernate-dev at lists.jboss.org
>> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >>
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Fri Jan 29 11:18:34 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 Jan 2016 16:18:34 +0000
Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re:
 5.1 tentative release date)
In-Reply-To: <CADGJaX88QHvuO8AJo47F=5nqq-HOsuRH_9dX4XyCkZVPFAr4ww@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
	<CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
	<CAFdSV9t=XTi=uxU625oEKKRbK5=o7ikYXzP6bmN39MCrKR+ffQ@mail.gmail.com>
	<CADGJaX88QHvuO8AJo47F=5nqq-HOsuRH_9dX4XyCkZVPFAr4ww@mail.gmail.com>
Message-ID: <CAFdSV9tCqO2cCO1qQYNbmPbSJhcrOrzh_8dkJMGCxJ+kwKnsSQ@mail.gmail.com>

I also plan on adding an @Incubating annotation for just such things :)

Anyway, I will start on this today.  It will take a few days though I
think.  I'll let you know when I have something ready to look at.

P.S.  Do you agree with what I said on your PR wrt TargetBase?


On Fri, Jan 29, 2016 at 10:15 AM Gunnar Morling <gunnar at hibernate.org>
wrote:

> Hi Steve,
>
> What you suggest sounds good. I've added a comment to
> https://hibernate.atlassian.net/browse/HHH-10458 itself.
>
> The reason why I didn't go for this from the beginning just was that I
> didn't want to break the contract of SchemaCreator and the other
> delegates.
>
> --Gunnar
>
>
>
>
> 2016-01-28 19:27 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > For this to work will require some significant changes.  The main one
> being
> > to combine JPA's support for schema generation along
> > with SchemaManagementTool.  The reason being simply that I will need to
> > encapsulate the interpretation of all these settings behind
> > the SchemaManagementTool facade in order for things to properly
> > replace SchemaManagementTool as Gunnar suggests.
> >
> > I am starting this work now on top of the work Gunnar has already done on
> > the PR he sent[1].  But that work is just the tip of the iceberg.  So if
> > you have input to this, speak soon.
> >
> >
> > [1] https://github.com/hibernate/hibernate-orm/pull/1231
> >
> > On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >
> >> I went for the proposed intermediary step to avoid breaking the API of
> >> SchemaManagementTool and its delegates. If you have a way for not
> >> breaking the API or think breaking it is alright, then +1 for doing
> >> the ProperSolution? in 5.1.
> >>
> >> What would it comprise, changing the delegate methods such as
> >> doCreate() to expect a single parameter object providing all the
> >> required info? Target could be a part of this, just an enum probably,
> >> based on wich delegates would do their thing. If it's that, I can try
> >> and help out with it.
> >>
> >> Regarding the release schedule, I'd personally be fine with pushing it
> >> a bit back, but then I don't know whether there are any other hard
> >> timelines to be met.
> >>
> >>
> >> 2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> > I'd like to get this work into 5.1.  But, as much as possible, I'd
> like
> >> to
> >> > get the ProperSolution in place rather than just a
> >> StepInTheRightDirection.
> >> > If we need to push this date 2-4 weeks I am ok with that.  That would
> >> help
> >> > us coordinate with Infinispan 8.2 schedule (iiuc) for
> >> hibernate-infinispan,
> >> > not to mention I still have to review the work Vlad has done on the
> docs
> >> > again as well as polish the load-by-multi-id API[1].
> >> >
> >> > [1] Sanne still waiting on your feedback to the open question of
> internal
> >> > routing of those calls.
> >> >
> >> > On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar at hibernate.org>
> >> wrote:
> >> >>
> >> >> Hi Steve,
> >> >>
> >> >> As discussed on IRC, I tried plugging in my own SchemaManagementTool
> >> >> and delegates and letting them do the initialization work required
> for
> >> >> OGM.
> >> >>
> >> >> I am hitting a wall though when it comes to the usage in the
> >> >> SchemaExport controller: As it's invoking doCreate() and doDrop()
> >> >> right in the constructor with a "fake" target for delegating the SQL
> >> >> statements, I am bitten by the fact that SchemaExport is instantiated
> >> >> twice in SessionFactoryImpl (once for create, once for drop at
> >> >> shutdown), so I see to invocations to doCreate() and doDrop(). Also I
> >> >> am lacking the knowledge of what's passed as Target for the
> controller
> >> >> invocation.
> >> >>
> >> >> So I went ahead and changed SchemaExport to invoke SchemaCreator and
> >> >> -Dropper only in execute(), passing them actual Target
> implementations
> >> >> as it's done in SchemaUpdate, too. It's not yet what you described as
> >> >> the ultimate goal (not looping back to Target), but IMO it's a step
> >> >> into the right direction, not the least making things consistent
> >> >> between SchemaExport and SchemaUpdate and also leaving APIs largely
> >> >> unchanged for the time being. With that I should be able to do it on
> >> >> the OGM side as you suggested, essentially ignoring the
> >> >> Target/Exporter stuff.
> >> >>
> >> >> I've filed ORM PR
> https://github.com/hibernate/hibernate-orm/pull/1231
> >> >> for the change. Let me know what you think.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> --Gunnar
> >> >>
> >> >>
> >> >> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> >> > I am not sure I am a big fan of The String->Object change
> >> specifically.
> >> >> > In
> >> >> > theory it sounds great.  But there is a major premise in schema
> >> tooling
> >> >> > around the idea of the actions being reduce-able to Strings.
> That's
> >> >> > important not just for SQL, but for the idea of writing to a file
> as
> >> >> > well.
> >> >> > It also affects the whole concept of Exporter/Exportable.
> >> >> >
> >> >> > The ultimate design goal here is to unify schema creation and
> dropping
> >> >> > across native and JPA requirements.  I just simply have not had the
> >> time
> >> >> > to
> >> >> > work on that.  This would all happen "behind" SchemaManagementTool
> and
> >> >> > friends.  SchemaExport, etc are actually just controllers
> responsible
> >> >> > for
> >> >> > coordinating the calls into the SchemaManagementTool delegates.
> The
> >> >> > main
> >> >> > problem at the moment IMO is that Target gets passed into these
> >> >> > SchemaManagementTool delegates.  Ideally, and certainly this would
> fit
> >> >> > with
> >> >> > your case, I think we want SchemaManagementTool or its delegates to
> >> >> > handle
> >> >> > interpreting the "arguments".  This was part of the intent of
> >> developing
> >> >> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc
> now;
> >> >> > the
> >> >> > idea was to encapsulate the settings each tool needs to operate and
> >> >> > isolate
> >> >> > the process of building/interpreting those args.
> >> >> >
> >> >> > The next step I wanted to look at there was to morph
> CommandLineArgs
> >> >> > into a
> >> >> > more generic "parameter object" for initializing the actual
> >> >> > SchemaManagementTool delegates.
> >> >> >
> >> >> > The idea is that the more we can push into SchemaManagementTool and
> >> its
> >> >> > delegates the more pluggable this entire process becomes.
> Ultimately,
> >> >> > as I
> >> >> > mentioned above, I just do not think it is feasible for ORM and
> OGM to
> >> >> > share all of these implementation contracts.  Forcing a switch from
> >> >> > String
> >> >> > (the DDL) arguments to some amorphic Object reinforces that in my
> >> mind.
> >> >> > But that would not stop OGM from completely swapping
> >> >> > SchemaManagementTool
> >> >> > and its delegates and simply not using Target, Exporters, etc.
> >> >> >
> >> >> >
> >> >> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling <
> gunnar at hibernate.org>
> >> >> > wrote:
> >> >> >
> >> >> >> Hi Steve,
> >> >> >>
> >> >> >> One thing useful to have for OGM would be a generalization of the
> >> >> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases.
> Not
> >> >> >> all of them are "schemaless", e.g. Cassandra works with a fixed
> >> >> >> schema, and while MongoDB largely is schemaless, we still want to
> >> >> >> create stuff like indexes in the database.
> >> >> >>
> >> >> >> I took a look and found that SchemaManagementTool as a pluggable
> >> >> >> service already goes halfway into that direction. The issue with
> it
> >> is
> >> >> >> that I cannot replace the list of exporters used by SchemaExport
> nor
> >> >> >> the list of tool targets used by SchemaUpdate. Having a pluggable
> >> >> >> service allowing me to customize that with an OGM-specific
> >> >> >> implementation should do the trick.
> >> >> >>
> >> >> >> As per some comments in the code, SchemaExport seems to be in some
> >> >> >> intermediary state, where the ops are not executed directly
> through
> >> >> >> the targets passed to SchemaCreator/Dropper but are read into
> String
> >> >> >> arrays which are then passed on to separate exporters. I suppose
> part
> >> >> >> of that work should be to consolidate this and basically follow
> the
> >> >> >> same approach as used in SchemaUpdate?
> >> >> >>
> >> >> >> Another facet is that for some OGM grid dialects we'd need another
> >> >> >> representation of commands than Strings, as not all the backends
> have
> >> >> >> a DDL but expect API invocations for that purpose. For that it'd
> be
> >> >> >> required to change Target#accept(String) into accept(Object) so we
> >> can
> >> >> >> pass some kind of command object. File exports would only work in
> a
> >> >> >> limited fashion, but we could live with that. Schema
> >> creation/dropping
> >> >> >> bound to the SF lifecycle is what I am after here.
> >> >> >>
> >> >> >> I'd be willing to work on this once we agree on the general
> approach.
> >> >> >>
> >> >> >> Any thoughts?
> >> >> >>
> >> >> >> Thanks,
> >> >> >>
> >> >> >> --Gunnar
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet <
> guillaume.smet at gmail.com
> >> >:
> >> >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <
> >> steve at hibernate.org>
> >> >> >> wrote:
> >> >> >> >
> >> >> >> >> If you clean up the conflicts I can look for 5.1
> >> >> >> >>
> >> >> >> >
> >> >> >> > Done!
> >> >> >> >
> >> >> >> > --
> >> >> >> > Guillaume
> >> >> >> > _______________________________________________
> >> >> >> > 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  Fri Jan 29 11:40:41 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 29 Jan 2016 17:40:41 +0100
Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re:
 5.1 tentative release date)
In-Reply-To: <CAFdSV9tCqO2cCO1qQYNbmPbSJhcrOrzh_8dkJMGCxJ+kwKnsSQ@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
	<CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
	<CAFdSV9t=XTi=uxU625oEKKRbK5=o7ikYXzP6bmN39MCrKR+ffQ@mail.gmail.com>
	<CADGJaX88QHvuO8AJo47F=5nqq-HOsuRH_9dX4XyCkZVPFAr4ww@mail.gmail.com>
	<CAFdSV9tCqO2cCO1qQYNbmPbSJhcrOrzh_8dkJMGCxJ+kwKnsSQ@mail.gmail.com>
Message-ID: <CADGJaX-YcXBoZ3mY9q93ByrJ9az8DYad+NHi85xh7yU_Tqmtuw@mail.gmail.com>

2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> I also plan on adding an @Incubating annotation for just such things :)

Yes, please. We have an annotation @Experimental in OGM which we use
for tagging APIs under development.

>
> Anyway, I will start on this today.  It will take a few days though I think.
> I'll let you know when I have something ready to look at.
>
> P.S.  Do you agree with what I said on your PR wrt TargetBase?

Yes, I do.

Not sure why I pulled the SQL logger into the base class tbh., as you
say it really makes only sense in the DB impl. I did not mean
TargetBase to be extended/customized by OGM, just to centralize some
stuff between the different impls in ORM. But that's mood with your
proposed redesign anyways I think.

>
>
> On Fri, Jan 29, 2016 at 10:15 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>>
>> Hi Steve,
>>
>> What you suggest sounds good. I've added a comment to
>> https://hibernate.atlassian.net/browse/HHH-10458 itself.
>>
>> The reason why I didn't go for this from the beginning just was that I
>> didn't want to break the contract of SchemaCreator and the other
>> delegates.
>>
>> --Gunnar
>>
>>
>>
>>
>> 2016-01-28 19:27 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > For this to work will require some significant changes.  The main one
>> > being
>> > to combine JPA's support for schema generation along
>> > with SchemaManagementTool.  The reason being simply that I will need to
>> > encapsulate the interpretation of all these settings behind
>> > the SchemaManagementTool facade in order for things to properly
>> > replace SchemaManagementTool as Gunnar suggests.
>> >
>> > I am starting this work now on top of the work Gunnar has already done
>> > on
>> > the PR he sent[1].  But that work is just the tip of the iceberg.  So if
>> > you have input to this, speak soon.
>> >
>> >
>> > [1] https://github.com/hibernate/hibernate-orm/pull/1231
>> >
>> > On Wed, Jan 20, 2016 at 6:13 AM Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >
>> >> I went for the proposed intermediary step to avoid breaking the API of
>> >> SchemaManagementTool and its delegates. If you have a way for not
>> >> breaking the API or think breaking it is alright, then +1 for doing
>> >> the ProperSolution? in 5.1.
>> >>
>> >> What would it comprise, changing the delegate methods such as
>> >> doCreate() to expect a single parameter object providing all the
>> >> required info? Target could be a part of this, just an enum probably,
>> >> based on wich delegates would do their thing. If it's that, I can try
>> >> and help out with it.
>> >>
>> >> Regarding the release schedule, I'd personally be fine with pushing it
>> >> a bit back, but then I don't know whether there are any other hard
>> >> timelines to be met.
>> >>
>> >>
>> >> 2016-01-19 16:25 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >> > I'd like to get this work into 5.1.  But, as much as possible, I'd
>> >> > like
>> >> to
>> >> > get the ProperSolution in place rather than just a
>> >> StepInTheRightDirection.
>> >> > If we need to push this date 2-4 weeks I am ok with that.  That would
>> >> help
>> >> > us coordinate with Infinispan 8.2 schedule (iiuc) for
>> >> hibernate-infinispan,
>> >> > not to mention I still have to review the work Vlad has done on the
>> >> > docs
>> >> > again as well as polish the load-by-multi-id API[1].
>> >> >
>> >> > [1] Sanne still waiting on your feedback to the open question of
>> >> > internal
>> >> > routing of those calls.
>> >> >
>> >> > On Tue, Jan 19, 2016 at 8:41 AM Gunnar Morling <gunnar at hibernate.org>
>> >> wrote:
>> >> >>
>> >> >> Hi Steve,
>> >> >>
>> >> >> As discussed on IRC, I tried plugging in my own SchemaManagementTool
>> >> >> and delegates and letting them do the initialization work required
>> >> >> for
>> >> >> OGM.
>> >> >>
>> >> >> I am hitting a wall though when it comes to the usage in the
>> >> >> SchemaExport controller: As it's invoking doCreate() and doDrop()
>> >> >> right in the constructor with a "fake" target for delegating the SQL
>> >> >> statements, I am bitten by the fact that SchemaExport is
>> >> >> instantiated
>> >> >> twice in SessionFactoryImpl (once for create, once for drop at
>> >> >> shutdown), so I see to invocations to doCreate() and doDrop(). Also
>> >> >> I
>> >> >> am lacking the knowledge of what's passed as Target for the
>> >> >> controller
>> >> >> invocation.
>> >> >>
>> >> >> So I went ahead and changed SchemaExport to invoke SchemaCreator and
>> >> >> -Dropper only in execute(), passing them actual Target
>> >> >> implementations
>> >> >> as it's done in SchemaUpdate, too. It's not yet what you described
>> >> >> as
>> >> >> the ultimate goal (not looping back to Target), but IMO it's a step
>> >> >> into the right direction, not the least making things consistent
>> >> >> between SchemaExport and SchemaUpdate and also leaving APIs largely
>> >> >> unchanged for the time being. With that I should be able to do it on
>> >> >> the OGM side as you suggested, essentially ignoring the
>> >> >> Target/Exporter stuff.
>> >> >>
>> >> >> I've filed ORM PR
>> >> >> https://github.com/hibernate/hibernate-orm/pull/1231
>> >> >> for the change. Let me know what you think.
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> --Gunnar
>> >> >>
>> >> >>
>> >> >> 2016-01-14 15:51 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >> >> > I am not sure I am a big fan of The String->Object change
>> >> specifically.
>> >> >> > In
>> >> >> > theory it sounds great.  But there is a major premise in schema
>> >> tooling
>> >> >> > around the idea of the actions being reduce-able to Strings.
>> >> >> > That's
>> >> >> > important not just for SQL, but for the idea of writing to a file
>> >> >> > as
>> >> >> > well.
>> >> >> > It also affects the whole concept of Exporter/Exportable.
>> >> >> >
>> >> >> > The ultimate design goal here is to unify schema creation and
>> >> >> > dropping
>> >> >> > across native and JPA requirements.  I just simply have not had
>> >> >> > the
>> >> time
>> >> >> > to
>> >> >> > work on that.  This would all happen "behind" SchemaManagementTool
>> >> >> > and
>> >> >> > friends.  SchemaExport, etc are actually just controllers
>> >> >> > responsible
>> >> >> > for
>> >> >> > coordinating the calls into the SchemaManagementTool delegates.
>> >> >> > The
>> >> >> > main
>> >> >> > problem at the moment IMO is that Target gets passed into these
>> >> >> > SchemaManagementTool delegates.  Ideally, and certainly this would
>> >> >> > fit
>> >> >> > with
>> >> >> > your case, I think we want SchemaManagementTool or its delegates
>> >> >> > to
>> >> >> > handle
>> >> >> > interpreting the "arguments".  This was part of the intent of
>> >> developing
>> >> >> > the "CommandLineArgs" stuff that is used inside SchemaExport, etc
>> >> >> > now;
>> >> >> > the
>> >> >> > idea was to encapsulate the settings each tool needs to operate
>> >> >> > and
>> >> >> > isolate
>> >> >> > the process of building/interpreting those args.
>> >> >> >
>> >> >> > The next step I wanted to look at there was to morph
>> >> >> > CommandLineArgs
>> >> >> > into a
>> >> >> > more generic "parameter object" for initializing the actual
>> >> >> > SchemaManagementTool delegates.
>> >> >> >
>> >> >> > The idea is that the more we can push into SchemaManagementTool
>> >> >> > and
>> >> its
>> >> >> > delegates the more pluggable this entire process becomes.
>> >> >> > Ultimately,
>> >> >> > as I
>> >> >> > mentioned above, I just do not think it is feasible for ORM and
>> >> >> > OGM to
>> >> >> > share all of these implementation contracts.  Forcing a switch
>> >> >> > from
>> >> >> > String
>> >> >> > (the DDL) arguments to some amorphic Object reinforces that in my
>> >> mind.
>> >> >> > But that would not stop OGM from completely swapping
>> >> >> > SchemaManagementTool
>> >> >> > and its delegates and simply not using Target, Exporters, etc.
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Jan 14, 2016 at 7:44 AM Gunnar Morling
>> >> >> > <gunnar at hibernate.org>
>> >> >> > wrote:
>> >> >> >
>> >> >> >> Hi Steve,
>> >> >> >>
>> >> >> >> One thing useful to have for OGM would be a generalization of the
>> >> >> >> hbm2ddl tooling so we can re-use it for managing NoSQL databases.
>> >> >> >> Not
>> >> >> >> all of them are "schemaless", e.g. Cassandra works with a fixed
>> >> >> >> schema, and while MongoDB largely is schemaless, we still want to
>> >> >> >> create stuff like indexes in the database.
>> >> >> >>
>> >> >> >> I took a look and found that SchemaManagementTool as a pluggable
>> >> >> >> service already goes halfway into that direction. The issue with
>> >> >> >> it
>> >> is
>> >> >> >> that I cannot replace the list of exporters used by SchemaExport
>> >> >> >> nor
>> >> >> >> the list of tool targets used by SchemaUpdate. Having a pluggable
>> >> >> >> service allowing me to customize that with an OGM-specific
>> >> >> >> implementation should do the trick.
>> >> >> >>
>> >> >> >> As per some comments in the code, SchemaExport seems to be in
>> >> >> >> some
>> >> >> >> intermediary state, where the ops are not executed directly
>> >> >> >> through
>> >> >> >> the targets passed to SchemaCreator/Dropper but are read into
>> >> >> >> String
>> >> >> >> arrays which are then passed on to separate exporters. I suppose
>> >> >> >> part
>> >> >> >> of that work should be to consolidate this and basically follow
>> >> >> >> the
>> >> >> >> same approach as used in SchemaUpdate?
>> >> >> >>
>> >> >> >> Another facet is that for some OGM grid dialects we'd need
>> >> >> >> another
>> >> >> >> representation of commands than Strings, as not all the backends
>> >> >> >> have
>> >> >> >> a DDL but expect API invocations for that purpose. For that it'd
>> >> >> >> be
>> >> >> >> required to change Target#accept(String) into accept(Object) so
>> >> >> >> we
>> >> can
>> >> >> >> pass some kind of command object. File exports would only work in
>> >> >> >> a
>> >> >> >> limited fashion, but we could live with that. Schema
>> >> creation/dropping
>> >> >> >> bound to the SF lifecycle is what I am after here.
>> >> >> >>
>> >> >> >> I'd be willing to work on this once we agree on the general
>> >> >> >> approach.
>> >> >> >>
>> >> >> >> Any thoughts?
>> >> >> >>
>> >> >> >> Thanks,
>> >> >> >>
>> >> >> >> --Gunnar
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> 2016-01-13 14:10 GMT+01:00 Guillaume Smet
>> >> >> >> <guillaume.smet at gmail.com
>> >> >:
>> >> >> >> > On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole <
>> >> steve at hibernate.org>
>> >> >> >> wrote:
>> >> >> >> >
>> >> >> >> >> If you clean up the conflicts I can look for 5.1
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Done!
>> >> >> >> >
>> >> >> >> > --
>> >> >> >> > Guillaume
>> >> >> >> > _______________________________________________
>> >> >> >> > hibernate-dev mailing list
>> >> >> >> > hibernate-dev at lists.jboss.org
>> >> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >> >>
>> >> >> > _______________________________________________
>> >> >> > hibernate-dev mailing list
>> >> >> > hibernate-dev at lists.jboss.org
>> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev


From steve at hibernate.org  Fri Jan 29 12:50:54 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 Jan 2016 17:50:54 +0000
Subject: [hibernate-dev] HHH-10487 - @Incubating annotation
Message-ID: <CAFdSV9u75m6=j0HAbBfFT-UoJrgdfY68WCnTXsJYEDKtn5XeWg@mail.gmail.com>

Per HHH-10487[1], I want to add an @Incubating annotation to mark APIs that
are still incubating.  Specifically, what do y'all think of
`java.lang.annotation.RetentionPolicy#CLASS` versus
`java.lang.annotation.RetentionPolicy#RUNTIME`?

[1] https://hibernate.atlassian.net/browse/HHH-10487

From steve at hibernate.org  Fri Jan 29 13:01:40 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 Jan 2016 18:01:40 +0000
Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re:
 5.1 tentative release date)
In-Reply-To: <CADGJaX-YcXBoZ3mY9q93ByrJ9az8DYad+NHi85xh7yU_Tqmtuw@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
	<CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
	<CAFdSV9t=XTi=uxU625oEKKRbK5=o7ikYXzP6bmN39MCrKR+ffQ@mail.gmail.com>
	<CADGJaX88QHvuO8AJo47F=5nqq-HOsuRH_9dX4XyCkZVPFAr4ww@mail.gmail.com>
	<CAFdSV9tCqO2cCO1qQYNbmPbSJhcrOrzh_8dkJMGCxJ+kwKnsSQ@mail.gmail.com>
	<CADGJaX-YcXBoZ3mY9q93ByrJ9az8DYad+NHi85xh7yU_Tqmtuw@mail.gmail.com>
Message-ID: <CAFdSV9sxs1Z_2r1p-nvBdEvMkF-Wu7K-Ok3a4gz2GD2V=pya0w@mail.gmail.com>

On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling <gunnar at hibernate.org>
wrote:

> 2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > I also plan on adding an @Incubating annotation for just such things :)
>
> Yes, please. We have an annotation @Experimental in OGM which we use
> for tagging APIs under development.
>

See https://hibernate.atlassian.net/browse/HHH-10487.  I also started a
separate discussion about this on the dev list.


BTW, as an extension to changing  SchemaManagementTool another thing I'd
like to add is some hook account for Envers use cases.  Specifically the
idea there is to be able to do a few things:
1) perform a selective create/drop.  selective in terms of just certain
objects.  This may be achievable through the new filter concept, although
we'd at least need a way to identify Envers tables from non-Envers tables.
Think of starting to use Hibernate+Envers on a schema that already exists.
2) perform "actions".  This is maybe beyond "schema tooling"; perhaps it is
more of a SessionFactory boot concept.  But one thing Envers misses today
that would be good to add is the ability to "prime" the audit tables.
Meaning, for audited entities that do not have entries in their audit
table, create one.  This for sure goes beyond simple SQL statements though.

From gunnar at hibernate.org  Fri Jan 29 13:02:08 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 29 Jan 2016 19:02:08 +0100
Subject: [hibernate-dev] HHH-10487 - @Incubating annotation
In-Reply-To: <CAFdSV9u75m6=j0HAbBfFT-UoJrgdfY68WCnTXsJYEDKtn5XeWg@mail.gmail.com>
References: <CAFdSV9u75m6=j0HAbBfFT-UoJrgdfY68WCnTXsJYEDKtn5XeWg@mail.gmail.com>
Message-ID: <CADGJaX-v2uxgKQZ_8Cs8NZ1Ov+U+qFsXcaYcvmKj8SQ8HPHTZA@mail.gmail.com>

Do you see any use case for accessing it reflectively at runtime?

FWIW, OGM's @Experimental has CLASS retention, which I think is
"enough retention" for its purpose.

2016-01-29 18:50 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> Per HHH-10487[1], I want to add an @Incubating annotation to mark APIs that
> are still incubating.  Specifically, what do y'all think of
> `java.lang.annotation.RetentionPolicy#CLASS` versus
> `java.lang.annotation.RetentionPolicy#RUNTIME`?
>
> [1] https://hibernate.atlassian.net/browse/HHH-10487
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri Jan 29 13:06:47 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 Jan 2016 18:06:47 +0000
Subject: [hibernate-dev] HHH-10487 - @Incubating annotation
In-Reply-To: <CADGJaX-v2uxgKQZ_8Cs8NZ1Ov+U+qFsXcaYcvmKj8SQ8HPHTZA@mail.gmail.com>
References: <CAFdSV9u75m6=j0HAbBfFT-UoJrgdfY68WCnTXsJYEDKtn5XeWg@mail.gmail.com>
	<CADGJaX-v2uxgKQZ_8Cs8NZ1Ov+U+qFsXcaYcvmKj8SQ8HPHTZA@mail.gmail.com>
Message-ID: <CAFdSV9u5B0jjCvJ6_wxk=o1D-0-Sk=AWTmvy+KNUXt2JoSPspw@mail.gmail.com>

I personally do not in terms of usage from ORM,  nor in usage by ORM users
either. I do wonder about tooling though. Like would it be useful for a
tool to see an implementation of an @Incubating contract being used and
warn the user?

On Fri, Jan 29, 2016, 12:02 PM Gunnar Morling <gunnar at hibernate.org> wrote:

> Do you see any use case for accessing it reflectively at runtime?
>
> FWIW, OGM's @Experimental has CLASS retention, which I think is
> "enough retention" for its purpose.
>
> 2016-01-29 18:50 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> > Per HHH-10487[1], I want to add an @Incubating annotation to mark APIs
> that
> > are still incubating.  Specifically, what do y'all think of
> > `java.lang.annotation.RetentionPolicy#CLASS` versus
> > `java.lang.annotation.RetentionPolicy#RUNTIME`?
> >
> > [1] https://hibernate.atlassian.net/browse/HHH-10487
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri Jan 29 13:11:22 2016
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 29 Jan 2016 18:11:22 +0000
Subject: [hibernate-dev] HHH-10487 - @Incubating annotation
In-Reply-To: <CAFdSV9u5B0jjCvJ6_wxk=o1D-0-Sk=AWTmvy+KNUXt2JoSPspw@mail.gmail.com>
References: <CAFdSV9u75m6=j0HAbBfFT-UoJrgdfY68WCnTXsJYEDKtn5XeWg@mail.gmail.com>
	<CADGJaX-v2uxgKQZ_8Cs8NZ1Ov+U+qFsXcaYcvmKj8SQ8HPHTZA@mail.gmail.com>
	<CAFdSV9u5B0jjCvJ6_wxk=o1D-0-Sk=AWTmvy+KNUXt2JoSPspw@mail.gmail.com>
Message-ID: <CAFm4XO2H1_dwXYAkM9UmMDpeXU9WPF54a5Ve2sOfo_jDK2sKcA@mail.gmail.com>

I would think that such a tool would work at compile time rather than
reflectively at runtime, but one can't be sure of course so it depends
on what you have in mind.

I'd also say make @Incubating with CLASS retention, it's more than
what people had before.. you can always evolve it later if someone
come with a brilliant use case which requires more.


On 29 January 2016 at 18:06, Steve Ebersole <steve at hibernate.org> wrote:
> I personally do not in terms of usage from ORM,  nor in usage by ORM users
> either. I do wonder about tooling though. Like would it be useful for a
> tool to see an implementation of an @Incubating contract being used and
> warn the user?
>
> On Fri, Jan 29, 2016, 12:02 PM Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Do you see any use case for accessing it reflectively at runtime?
>>
>> FWIW, OGM's @Experimental has CLASS retention, which I think is
>> "enough retention" for its purpose.
>>
>> 2016-01-29 18:50 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > Per HHH-10487[1], I want to add an @Incubating annotation to mark APIs
>> that
>> > are still incubating.  Specifically, what do y'all think of
>> > `java.lang.annotation.RetentionPolicy#CLASS` versus
>> > `java.lang.annotation.RetentionPolicy#RUNTIME`?
>> >
>> > [1] https://hibernate.atlassian.net/browse/HHH-10487
>> > _______________________________________________
>> > 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  Fri Jan 29 13:19:23 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 Jan 2016 18:19:23 +0000
Subject: [hibernate-dev] HHH-10487 - @Incubating annotation
In-Reply-To: <CAFm4XO2H1_dwXYAkM9UmMDpeXU9WPF54a5Ve2sOfo_jDK2sKcA@mail.gmail.com>
References: <CAFdSV9u75m6=j0HAbBfFT-UoJrgdfY68WCnTXsJYEDKtn5XeWg@mail.gmail.com>
	<CADGJaX-v2uxgKQZ_8Cs8NZ1Ov+U+qFsXcaYcvmKj8SQ8HPHTZA@mail.gmail.com>
	<CAFdSV9u5B0jjCvJ6_wxk=o1D-0-Sk=AWTmvy+KNUXt2JoSPspw@mail.gmail.com>
	<CAFm4XO2H1_dwXYAkM9UmMDpeXU9WPF54a5Ve2sOfo_jDK2sKcA@mail.gmail.com>
Message-ID: <CAFdSV9uO=SVf04QXNQsjP3MSQWUJZs2r56BFMy=z+w3exBrBXg@mail.gmail.com>

I don't have anything specific in mind.  Just more of a general thought
process, since its the first annotation of this type I am adding.


On Fri, Jan 29, 2016 at 12:11 PM Sanne Grinovero <sanne at hibernate.org>
wrote:

> I would think that such a tool would work at compile time rather than
> reflectively at runtime, but one can't be sure of course so it depends
> on what you have in mind.
>
> I'd also say make @Incubating with CLASS retention, it's more than
> what people had before.. you can always evolve it later if someone
> come with a brilliant use case which requires more.
>
>
> On 29 January 2016 at 18:06, Steve Ebersole <steve at hibernate.org> wrote:
> > I personally do not in terms of usage from ORM,  nor in usage by ORM
> users
> > either. I do wonder about tooling though. Like would it be useful for a
> > tool to see an implementation of an @Incubating contract being used and
> > warn the user?
> >
> > On Fri, Jan 29, 2016, 12:02 PM Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >
> >> Do you see any use case for accessing it reflectively at runtime?
> >>
> >> FWIW, OGM's @Experimental has CLASS retention, which I think is
> >> "enough retention" for its purpose.
> >>
> >> 2016-01-29 18:50 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> >> > Per HHH-10487[1], I want to add an @Incubating annotation to mark APIs
> >> that
> >> > are still incubating.  Specifically, what do y'all think of
> >> > `java.lang.annotation.RetentionPolicy#CLASS` versus
> >> > `java.lang.annotation.RetentionPolicy#RUNTIME`?
> >> >
> >> > [1] https://hibernate.atlassian.net/browse/HHH-10487
> >> > _______________________________________________
> >> > 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  Fri Jan 29 13:43:52 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 29 Jan 2016 19:43:52 +0100
Subject: [hibernate-dev] HHH-10487 - @Incubating annotation
In-Reply-To: <CAFdSV9uO=SVf04QXNQsjP3MSQWUJZs2r56BFMy=z+w3exBrBXg@mail.gmail.com>
References: <CAFdSV9u75m6=j0HAbBfFT-UoJrgdfY68WCnTXsJYEDKtn5XeWg@mail.gmail.com>
	<CADGJaX-v2uxgKQZ_8Cs8NZ1Ov+U+qFsXcaYcvmKj8SQ8HPHTZA@mail.gmail.com>
	<CAFdSV9u5B0jjCvJ6_wxk=o1D-0-Sk=AWTmvy+KNUXt2JoSPspw@mail.gmail.com>
	<CAFm4XO2H1_dwXYAkM9UmMDpeXU9WPF54a5Ve2sOfo_jDK2sKcA@mail.gmail.com>
	<CAFdSV9uO=SVf04QXNQsjP3MSQWUJZs2r56BFMy=z+w3exBrBXg@mail.gmail.com>
Message-ID: <CADGJaX_CTwtfREGdTYpKYP+RVPkvbB2qQH8+nJ1p_kXcX386MQ@mail.gmail.com>

One reason potentially speaking against RUNTIME is that any attributes
of the annotation would be retained as well, e.g. Strings with a
description. So it'd consume a tiny bit of memory which is not needed
by the user application.

Btw. there is a related JEP (http://openjdk.java.net/jeps/277) which
aims at generalising the existing @Deprecated annotation for purposes
like this. It suggests to add attributes to @Deprecated for expressing
the deprecation reason and an enum with possible causes. One being
EXPERIMENTAL:

    @Deprecated(EXPERIMENTAL)
    void myNewApi() { ... }

No idea though whether/when it will be part of Java, it's not listed
in the Java 9 JEPs at http://openjdk.java.net/projects/jdk9/.

Interestingly, @Deprecated has RUNTIME retention which may be the
reason that they don't propose to add a String attribute such as
description() as part of that JEP.

2016-01-29 19:19 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
> I don't have anything specific in mind.  Just more of a general thought
> process, since its the first annotation of this type I am adding.
>
>
> On Fri, Jan 29, 2016 at 12:11 PM Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> I would think that such a tool would work at compile time rather than
>> reflectively at runtime, but one can't be sure of course so it depends
>> on what you have in mind.
>>
>> I'd also say make @Incubating with CLASS retention, it's more than
>> what people had before.. you can always evolve it later if someone
>> come with a brilliant use case which requires more.
>>
>>
>> On 29 January 2016 at 18:06, Steve Ebersole <steve at hibernate.org> wrote:
>> > I personally do not in terms of usage from ORM,  nor in usage by ORM
>> > users
>> > either. I do wonder about tooling though. Like would it be useful for a
>> > tool to see an implementation of an @Incubating contract being used and
>> > warn the user?
>> >
>> > On Fri, Jan 29, 2016, 12:02 PM Gunnar Morling <gunnar at hibernate.org>
>> > wrote:
>> >
>> >> Do you see any use case for accessing it reflectively at runtime?
>> >>
>> >> FWIW, OGM's @Experimental has CLASS retention, which I think is
>> >> "enough retention" for its purpose.
>> >>
>> >> 2016-01-29 18:50 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> >> > Per HHH-10487[1], I want to add an @Incubating annotation to mark
>> >> > APIs
>> >> that
>> >> > are still incubating.  Specifically, what do y'all think of
>> >> > `java.lang.annotation.RetentionPolicy#CLASS` versus
>> >> > `java.lang.annotation.RetentionPolicy#RUNTIME`?
>> >> >
>> >> > [1] https://hibernate.atlassian.net/browse/HHH-10487
>> >> > _______________________________________________
>> >> > 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  Fri Jan 29 14:15:01 2016
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 Jan 2016 19:15:01 +0000
Subject: [hibernate-dev] SchemaManagementTool changes for 5.1 (was Re:
 5.1 tentative release date)
In-Reply-To: <CAFdSV9sxs1Z_2r1p-nvBdEvMkF-Wu7K-Ok3a4gz2GD2V=pya0w@mail.gmail.com>
References: <CAFdSV9u5Mc0TLms+fnAV1Z5GnYWz-h6vXfL=bKrddoQ2GL9VSQ@mail.gmail.com>
	<56900F9A.2010305@redhat.com>
	<CAFdSV9vmar2TODPKTLY28y62n6OoP_At0yNc2b2guYvRKA03HA@mail.gmail.com>
	<569077E3.9070201@redhat.com>
	<CAFdSV9uapWpGqKQKDKGu1hntnXtkm4c-Wehy6QrT0m5w=cMscg@mail.gmail.com>
	<56952518.4090700@redhat.com>
	<CALt0+o9_v=opUzEQvJX4N4oN=fyWpoWZ9cDSkyN0w3VDgex_TA@mail.gmail.com>
	<CAFdSV9uPfWZ0NBV8nzPXz-t=gJZc4sHK6x-oQOH7PGZyTSXDpg@mail.gmail.com>
	<CALt0+o-MARckuxUj4YAbT+wRDPJz2hGhsyL+ZoZXf05oZ4MXnA@mail.gmail.com>
	<CADGJaX_kmJ8QQGoZ+njNS5qT62aTNY-T+_1o65ztvp=NBTcEMQ@mail.gmail.com>
	<CAFdSV9vCNaV9fTzBwX2hSnZbZcH2HRHNdKJgb0FbxYDJ=bVdTQ@mail.gmail.com>
	<CADGJaX825V9f1t6od1thDOWpfz31pXayZDs-O8YgoKGe5QZyxg@mail.gmail.com>
	<CAFdSV9uL35=8N3Jhc+pdRZfvmjgb8tf2Z7r+Jx=ugcxXvGcwHA@mail.gmail.com>
	<CADGJaX-WnSAAKAD-mooYPzxAr-djGB34cFCdpAaHxacRTdO9mA@mail.gmail.com>
	<CAFdSV9t=XTi=uxU625oEKKRbK5=o7ikYXzP6bmN39MCrKR+ffQ@mail.gmail.com>
	<CADGJaX88QHvuO8AJo47F=5nqq-HOsuRH_9dX4XyCkZVPFAr4ww@mail.gmail.com>
	<CAFdSV9tCqO2cCO1qQYNbmPbSJhcrOrzh_8dkJMGCxJ+kwKnsSQ@mail.gmail.com>
	<CADGJaX-YcXBoZ3mY9q93ByrJ9az8DYad+NHi85xh7yU_Tqmtuw@mail.gmail.com>
	<CAFdSV9sxs1Z_2r1p-nvBdEvMkF-Wu7K-Ok3a4gz2GD2V=pya0w@mail.gmail.com>
Message-ID: <CAFdSV9v3Kh6wWD-o1Kkt_QcmEoXDVJ_FKZO5MDtfFb1tFXiBsw@mail.gmail.com>

I am debating with myself about
reusing `javax.persistence.schema-generation.database.action` and
`javax.persistence.schema-generation.scripts.action`
in terms of this new unified support.  The debate point being the fact that
we'd have to have those accept an extended range of values which
potentially hurts users in terms of JPA provider portability.  For example,
if they have:

javax.persistence.schema-generation.database.action=validate

Hibernate would understand that, but other providers likely would not.
This is beyond the concept of "strict compliance" I started in SQM in my
opinion.  Here we are moving toward a unification, meaning we expect people
to use this.

So do we reuse the JPA names?

On a related note.. in regards to the fact that JPA splits action between
script and database target whereas hbm2ddl defines just a singular action
value... does anyone know of a real case where someone defines different
actions between script and database?  I mean aside from one being NONE.  I
mean cases where they say we should do "create" for scripts but send
"drop-and-create" to the database?  That just seems odd to me.  I think we
have to account for the split since we have to account for JPA, and that
model fits both.  I was just curious




On Fri, Jan 29, 2016 at 12:01 PM Steve Ebersole <steve at hibernate.org> wrote:

> On Fri, Jan 29, 2016 at 10:40 AM Gunnar Morling <gunnar at hibernate.org>
> wrote:
>
>> 2016-01-29 17:18 GMT+01:00 Steve Ebersole <steve at hibernate.org>:
>> > I also plan on adding an @Incubating annotation for just such things :)
>>
>> Yes, please. We have an annotation @Experimental in OGM which we use
>> for tagging APIs under development.
>>
>
> See https://hibernate.atlassian.net/browse/HHH-10487.  I also started a
> separate discussion about this on the dev list.
>
>
> BTW, as an extension to changing  SchemaManagementTool another thing I'd
> like to add is some hook account for Envers use cases.  Specifically the
> idea there is to be able to do a few things:
> 1) perform a selective create/drop.  selective in terms of just certain
> objects.  This may be achievable through the new filter concept, although
> we'd at least need a way to identify Envers tables from non-Envers tables.
> Think of starting to use Hibernate+Envers on a schema that already exists.
> 2) perform "actions".  This is maybe beyond "schema tooling"; perhaps it
> is more of a SessionFactory boot concept.  But one thing Envers misses
> today that would be good to add is the ability to "prime" the audit
> tables.  Meaning, for audited entities that do not have entries in their
> audit table, create one.  This for sure goes beyond simple SQL statements
> though.
>