From steve at hibernate.org  Fri May  1 09:51:33 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 1 May 2015 08:51:33 -0500
Subject: [hibernate-dev] Auto quoting of keywords used as identifiers
Message-ID: <CAFdSV9sPUZe9SP8itma4sduosVOc80=DRFoUeNGQeg4RPUN_Vg@mail.gmail.com>

Gail, I saw your ping on IRC and thought it made sense to address here,
since you were not around on IRC anymore.

Overall, starting with 5.0, the idea is for Hibernate to automatically
quote any identifiers is recognizes as a keyword.  This is all encapsulated
within the org.hibernate.engine.jdbc.env.spi.IdentifierHelper obtained
via org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#getIdentifierHelper.

There are 2 parts to this...

First, we need to be able to recognize that an identifier is in fact a
keyword.  This piece is handled through
org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#isReservedWord, which is
based on a Set of keywords computed from 2 distinct "keyword sources":
1) Dialect#getKeywords
2) DatabaseMetaData#getSQLKeywords

At the moment, I think this misses a third source... ANSI SQL 2003 standard
keywords.  DatabaseMetaData#getSQLKeywords specifically is supposed to
return only keywords beyond the standard (2003) defined ones.  There are
really 2 options to address this:
1) add these standard keywords to Dialect
2) use a seperate (static) source for them.

Personally I prefer the second.  Even if we added all the standard keywords
to the base Dialect Set, it is just too easy for the Dialect subclass to
override getKeywords().  Also, I like the idea of continuing the convention
of these other 2 sources simply returning "extras".

Second, and this is BY FAR the harder part, we need to make sure that
everywhere that is building identifiers is using this code.  I tried hard
to make sure that was the case, but we all know that annotation binding is
a mess and its just too easy to miss stuff in there.  I'm all happy for a
second (or third, or fourth, ...) pair of eyes looking over this part, but
I personally think it is not the best allocation of our time considering
the difficulty in actually finding them all just by code review and the
time it would take and the amount of other stuff we have to do.  Eventually
we will get bug reports of cases where this does not happen.  My $.02

From steve at hibernate.org  Fri May  1 10:19:34 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 1 May 2015 09:19:34 -0500
Subject: [hibernate-dev] Auto quoting of keywords used as identifiers
In-Reply-To: <CAFdSV9sPUZe9SP8itma4sduosVOc80=DRFoUeNGQeg4RPUN_Vg@mail.gmail.com>
References: <CAFdSV9sPUZe9SP8itma4sduosVOc80=DRFoUeNGQeg4RPUN_Vg@mail.gmail.com>
Message-ID: <CAFdSV9tmG-i9Nmbga0Y9d3UKchr142OmkhAVRBXzQoH9TA8kPg@mail.gmail.com>

Interestingly, your IRC ping asked about KEY which in fact is *not* a
SQL:2003 keyword.  It had been a keyword in 92 and 99 SQL standards, but
was removed in 2003.

Which actually opens up an another interesting discussion as far as how
aggressive to be in terms of affirming an identifier as being a keyword and
thus quoting it.  Do we use SQL:2003 as the baseline?  Do we use SQL3
(99)?  SQL2 (92)?  Do we more aggressively build a superset from all 3?

My gut says we should:
1) Use SQL:2003 as the baseline
2) Augment with DatabaseMetaData#getSQLKeywords
3) Augment with Dialect#getKeywords
4) (?) Augment with application-provided keywords

FWIW (4) can actually be handles via custom PhysicalNamingStrategy in terms
of a custom PhysicalNamingStrategy deciding to quote a given identifier.


On Fri, May 1, 2015 at 8:51 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Gail, I saw your ping on IRC and thought it made sense to address here,
> since you were not around on IRC anymore.
>
> Overall, starting with 5.0, the idea is for Hibernate to automatically
> quote any identifiers is recognizes as a keyword.  This is all encapsulated
> within the org.hibernate.engine.jdbc.env.spi.IdentifierHelper obtained
> via org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#getIdentifierHelper.
>
> There are 2 parts to this...
>
> First, we need to be able to recognize that an identifier is in fact a
> keyword.  This piece is handled through
> org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#isReservedWord, which is
> based on a Set of keywords computed from 2 distinct "keyword sources":
> 1) Dialect#getKeywords
> 2) DatabaseMetaData#getSQLKeywords
>
> At the moment, I think this misses a third source... ANSI SQL 2003
> standard keywords.  DatabaseMetaData#getSQLKeywords specifically is
> supposed to return only keywords beyond the standard (2003) defined ones.
> There are really 2 options to address this:
> 1) add these standard keywords to Dialect
> 2) use a seperate (static) source for them.
>
> Personally I prefer the second.  Even if we added all the standard
> keywords to the base Dialect Set, it is just too easy for the Dialect
> subclass to override getKeywords().  Also, I like the idea of continuing
> the convention of these other 2 sources simply returning "extras".
>
> Second, and this is BY FAR the harder part, we need to make sure that
> everywhere that is building identifiers is using this code.  I tried hard
> to make sure that was the case, but we all know that annotation binding is
> a mess and its just too easy to miss stuff in there.  I'm all happy for a
> second (or third, or fourth, ...) pair of eyes looking over this part, but
> I personally think it is not the best allocation of our time considering
> the difficulty in actually finding them all just by code review and the
> time it would take and the amount of other stuff we have to do.  Eventually
> we will get bug reports of cases where this does not happen.  My $.02
>

From sanne at hibernate.org  Fri May  1 10:26:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 1 May 2015 15:26:47 +0100
Subject: [hibernate-dev] Auto quoting of keywords used as identifiers
In-Reply-To: <CAFdSV9tmG-i9Nmbga0Y9d3UKchr142OmkhAVRBXzQoH9TA8kPg@mail.gmail.com>
References: <CAFdSV9sPUZe9SP8itma4sduosVOc80=DRFoUeNGQeg4RPUN_Vg@mail.gmail.com>
	<CAFdSV9tmG-i9Nmbga0Y9d3UKchr142OmkhAVRBXzQoH9TA8kPg@mail.gmail.com>
Message-ID: <CAFm4XO3HO3gTn_WF3v_Q68+TRmgNQt9KDvQv_ivX_39PmwBvjQ@mail.gmail.com>

Rather than basing our decisions on standards, wouldn't it be more
useful to base it on *exactly* what the used database requires?

In other words, why wouldn't it suffice to have a single source of
keywords: the Dialect.

--Sanne



On 1 May 2015 at 15:19, Steve Ebersole <steve at hibernate.org> wrote:
> Interestingly, your IRC ping asked about KEY which in fact is *not* a
> SQL:2003 keyword.  It had been a keyword in 92 and 99 SQL standards, but
> was removed in 2003.
>
> Which actually opens up an another interesting discussion as far as how
> aggressive to be in terms of affirming an identifier as being a keyword and
> thus quoting it.  Do we use SQL:2003 as the baseline?  Do we use SQL3
> (99)?  SQL2 (92)?  Do we more aggressively build a superset from all 3?
>
> My gut says we should:
> 1) Use SQL:2003 as the baseline
> 2) Augment with DatabaseMetaData#getSQLKeywords
> 3) Augment with Dialect#getKeywords
> 4) (?) Augment with application-provided keywords
>
> FWIW (4) can actually be handles via custom PhysicalNamingStrategy in terms
> of a custom PhysicalNamingStrategy deciding to quote a given identifier.
>
>
> On Fri, May 1, 2015 at 8:51 AM, Steve Ebersole <steve at hibernate.org> wrote:
>
>> Gail, I saw your ping on IRC and thought it made sense to address here,
>> since you were not around on IRC anymore.
>>
>> Overall, starting with 5.0, the idea is for Hibernate to automatically
>> quote any identifiers is recognizes as a keyword.  This is all encapsulated
>> within the org.hibernate.engine.jdbc.env.spi.IdentifierHelper obtained
>> via org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#getIdentifierHelper.
>>
>> There are 2 parts to this...
>>
>> First, we need to be able to recognize that an identifier is in fact a
>> keyword.  This piece is handled through
>> org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#isReservedWord, which is
>> based on a Set of keywords computed from 2 distinct "keyword sources":
>> 1) Dialect#getKeywords
>> 2) DatabaseMetaData#getSQLKeywords
>>
>> At the moment, I think this misses a third source... ANSI SQL 2003
>> standard keywords.  DatabaseMetaData#getSQLKeywords specifically is
>> supposed to return only keywords beyond the standard (2003) defined ones.
>> There are really 2 options to address this:
>> 1) add these standard keywords to Dialect
>> 2) use a seperate (static) source for them.
>>
>> Personally I prefer the second.  Even if we added all the standard
>> keywords to the base Dialect Set, it is just too easy for the Dialect
>> subclass to override getKeywords().  Also, I like the idea of continuing
>> the convention of these other 2 sources simply returning "extras".
>>
>> Second, and this is BY FAR the harder part, we need to make sure that
>> everywhere that is building identifiers is using this code.  I tried hard
>> to make sure that was the case, but we all know that annotation binding is
>> a mess and its just too easy to miss stuff in there.  I'm all happy for a
>> second (or third, or fourth, ...) pair of eyes looking over this part, but
>> I personally think it is not the best allocation of our time considering
>> the difficulty in actually finding them all just by code review and the
>> time it would take and the amount of other stuff we have to do.  Eventually
>> we will get bug reports of cases where this does not happen.  My $.02
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri May  1 10:39:57 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 1 May 2015 15:39:57 +0100
Subject: [hibernate-dev] Google Summer of Code 2015
In-Reply-To: <406272E1-D0AE-4A37-B67E-5F1B9B85B3D9@hibernate.org>
References: <14d0a6f97e8-7ee5-5c6b@webprd-m96.mail.aol.com>
	<406272E1-D0AE-4A37-B67E-5F1B9B85B3D9@hibernate.org>
Message-ID: <CAFm4XO23YOQfRakd5oKEvg4kRjNgtOFTth+AWXyC3S6zX49NsQ@mail.gmail.com>

Hi Martin,
I would never have seen your email if Emmanuel hadn't replied to it.

Apparently google (I'm using gmail) is flagging your email account as
spam; the error message I see is too short and ambiguous to understand
what's wrong, but it seems like aol.com could not meet their
requirements.
This might be an issue with your provider, or it might depend on how
you have setup your email client. I've enabled a specific filter for
you but that applies only to me, I'd suggest you look at it ;)

-- Sanne

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

From sanne at hibernate.org  Fri May  1 11:56:18 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 1 May 2015 16:56:18 +0100
Subject: [hibernate-dev] [!] Changing the Faceting API in Hibernate Search
Message-ID: <CAFm4XO1mmNk_W16ETbzdUZWvDQ6sKQTCQ+PGfGfW0759-Ue9vg@mail.gmail.com>

Hi all,

Hardy completed the Faceting re-work in Hibernate Search to use the
much improved implementation from recent versions of Lucene, and we'd
like to merge his work now making these improvements available to
users of Hibernate Search 5.2.0+

There is a catch: while the API to create a Faceting Query is
unchanged and nicely backwards compatible, you'll now be required to
explicitly sign up the fields which you want to be "facetable" using a
new annotation: @Facet

The default for an indexed property is that faceting is disabled, so
people already using faceting will have to adjust their mapping, and
rebuild the indexes accordingly.
Unfortunately you won't notice the problem at compile time - and we
can't validate for it at boot time - but you'll get a reasonable
explanation in the exception when attempting to create a faceting
query.

There are many benefits to the new approach, so please bear with me
for applying such a non-backwards compatible patch in a minor release:
we won't break this rule often, nor are we lacking great reasons to
proceed.

For details see:
 - https://github.com/hibernate/hibernate-search/pull/821

Thanks,
Sanne

From steve at hibernate.org  Fri May  1 12:45:57 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 1 May 2015 11:45:57 -0500
Subject: [hibernate-dev] Auto quoting of keywords used as identifiers
In-Reply-To: <CAFm4XO3HO3gTn_WF3v_Q68+TRmgNQt9KDvQv_ivX_39PmwBvjQ@mail.gmail.com>
References: <CAFdSV9sPUZe9SP8itma4sduosVOc80=DRFoUeNGQeg4RPUN_Vg@mail.gmail.com>
	<CAFdSV9tmG-i9Nmbga0Y9d3UKchr142OmkhAVRBXzQoH9TA8kPg@mail.gmail.com>
	<CAFm4XO3HO3gTn_WF3v_Q68+TRmgNQt9KDvQv_ivX_39PmwBvjQ@mail.gmail.com>
Message-ID: <CAFdSV9tC4XUZoxNBhnVf1LK3DfrZ3W6ZVHmzUga+_pTbpvaKWw@mail.gmail.com>

I understand what you are saying, in principle.  Then there is the
practical side.  Personally I am not so interested in doing all the
investigation over each Dialect to determine their exact set of keywords (A
LOT of work), not to mention typing all that up (A LOT of duplication).  Of
course, if someone wants to volunteer to take on the task of identifying
the exact set of keywords for each Dialect I am not going to stop them.  You
volunteering? :)

As a compromise, we could have the complete set of keywords defined to
combination of:
1) DatabaseMetaData#getSQLKeywords
2) Dialect#getKeywords

and have *our* Dialect impls incorporate the SQL:2003 keywords into what
they return.

If the driver is returning us "extra keywords", I think it is simply a
BadIdea(tm) to ignore that.



On Fri, May 1, 2015 at 9:26 AM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Rather than basing our decisions on standards, wouldn't it be more
> useful to base it on *exactly* what the used database requires?
>
> In other words, why wouldn't it suffice to have a single source of
> keywords: the Dialect.
>
> --Sanne
>
>
>
> On 1 May 2015 at 15:19, Steve Ebersole <steve at hibernate.org> wrote:
> > Interestingly, your IRC ping asked about KEY which in fact is *not* a
> > SQL:2003 keyword.  It had been a keyword in 92 and 99 SQL standards, but
> > was removed in 2003.
> >
> > Which actually opens up an another interesting discussion as far as how
> > aggressive to be in terms of affirming an identifier as being a keyword
> and
> > thus quoting it.  Do we use SQL:2003 as the baseline?  Do we use SQL3
> > (99)?  SQL2 (92)?  Do we more aggressively build a superset from all 3?
> >
> > My gut says we should:
> > 1) Use SQL:2003 as the baseline
> > 2) Augment with DatabaseMetaData#getSQLKeywords
> > 3) Augment with Dialect#getKeywords
> > 4) (?) Augment with application-provided keywords
> >
> > FWIW (4) can actually be handles via custom PhysicalNamingStrategy in
> terms
> > of a custom PhysicalNamingStrategy deciding to quote a given identifier.
> >
> >
> > On Fri, May 1, 2015 at 8:51 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> >> Gail, I saw your ping on IRC and thought it made sense to address here,
> >> since you were not around on IRC anymore.
> >>
> >> Overall, starting with 5.0, the idea is for Hibernate to automatically
> >> quote any identifiers is recognizes as a keyword.  This is all
> encapsulated
> >> within the org.hibernate.engine.jdbc.env.spi.IdentifierHelper obtained
> >> via
> org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#getIdentifierHelper.
> >>
> >> There are 2 parts to this...
> >>
> >> First, we need to be able to recognize that an identifier is in fact a
> >> keyword.  This piece is handled through
> >> org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#isReservedWord, which
> is
> >> based on a Set of keywords computed from 2 distinct "keyword sources":
> >> 1) Dialect#getKeywords
> >> 2) DatabaseMetaData#getSQLKeywords
> >>
> >> At the moment, I think this misses a third source... ANSI SQL 2003
> >> standard keywords.  DatabaseMetaData#getSQLKeywords specifically is
> >> supposed to return only keywords beyond the standard (2003) defined
> ones.
> >> There are really 2 options to address this:
> >> 1) add these standard keywords to Dialect
> >> 2) use a seperate (static) source for them.
> >>
> >> Personally I prefer the second.  Even if we added all the standard
> >> keywords to the base Dialect Set, it is just too easy for the Dialect
> >> subclass to override getKeywords().  Also, I like the idea of continuing
> >> the convention of these other 2 sources simply returning "extras".
> >>
> >> Second, and this is BY FAR the harder part, we need to make sure that
> >> everywhere that is building identifiers is using this code.  I tried
> hard
> >> to make sure that was the case, but we all know that annotation binding
> is
> >> a mess and its just too easy to miss stuff in there.  I'm all happy for
> a
> >> second (or third, or fourth, ...) pair of eyes looking over this part,
> but
> >> I personally think it is not the best allocation of our time considering
> >> the difficulty in actually finding them all just by code review and the
> >> time it would take and the amount of other stuff we have to do.
> Eventually
> >> we will get bug reports of cases where this does not happen.  My $.02
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri May  1 13:17:46 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 1 May 2015 18:17:46 +0100
Subject: [hibernate-dev] Auto quoting of keywords used as identifiers
In-Reply-To: <CAFdSV9tC4XUZoxNBhnVf1LK3DfrZ3W6ZVHmzUga+_pTbpvaKWw@mail.gmail.com>
References: <CAFdSV9sPUZe9SP8itma4sduosVOc80=DRFoUeNGQeg4RPUN_Vg@mail.gmail.com>
	<CAFdSV9tmG-i9Nmbga0Y9d3UKchr142OmkhAVRBXzQoH9TA8kPg@mail.gmail.com>
	<CAFm4XO3HO3gTn_WF3v_Q68+TRmgNQt9KDvQv_ivX_39PmwBvjQ@mail.gmail.com>
	<CAFdSV9tC4XUZoxNBhnVf1LK3DfrZ3W6ZVHmzUga+_pTbpvaKWw@mail.gmail.com>
Message-ID: <CAFm4XO1CQ1ot1p+02PY9K5PMjFJ_co2qJ45CYSnBm7NZwFmODA@mail.gmail.com>

Right you could have the Dialects return the standard set by default,
then someone with specialistic knowledge of the specific database
could either override that with a custom Dialect or provide an
improvement patch.

I guess it's wise to not ignore the "extra keywords" defined by the
driver, but shouldn't a custom dialect developer not be able to
override it? To me it sounds like you're shaping the correct decision
for the default dialect implementation, but ultimately I think people
should be able to know better, be it because their JDBC driver is
outdated or just because their RDBMs ignores the standards. Neither
seems too unlikely to happen in practice :)

On 1 May 2015 at 17:45, Steve Ebersole <steve at hibernate.org> wrote:
> I understand what you are saying, in principle.  Then there is the practical
> side.  Personally I am not so interested in doing all the investigation over
> each Dialect to determine their exact set of keywords (A LOT of work), not
> to mention typing all that up (A LOT of duplication).  Of course, if someone
> wants to volunteer to take on the task of identifying the exact set of
> keywords for each Dialect I am not going to stop them.  You volunteering? :)
>
> As a compromise, we could have the complete set of keywords defined to
> combination of:
> 1) DatabaseMetaData#getSQLKeywords
> 2) Dialect#getKeywords
>
> and have *our* Dialect impls incorporate the SQL:2003 keywords into what
> they return.
>
> If the driver is returning us "extra keywords", I think it is simply a
> BadIdea(tm) to ignore that.
>
>
>
> On Fri, May 1, 2015 at 9:26 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Rather than basing our decisions on standards, wouldn't it be more
>> useful to base it on *exactly* what the used database requires?
>>
>> In other words, why wouldn't it suffice to have a single source of
>> keywords: the Dialect.
>>
>> --Sanne
>>
>>
>>
>> On 1 May 2015 at 15:19, Steve Ebersole <steve at hibernate.org> wrote:
>> > Interestingly, your IRC ping asked about KEY which in fact is *not* a
>> > SQL:2003 keyword.  It had been a keyword in 92 and 99 SQL standards, but
>> > was removed in 2003.
>> >
>> > Which actually opens up an another interesting discussion as far as how
>> > aggressive to be in terms of affirming an identifier as being a keyword
>> > and
>> > thus quoting it.  Do we use SQL:2003 as the baseline?  Do we use SQL3
>> > (99)?  SQL2 (92)?  Do we more aggressively build a superset from all 3?
>> >
>> > My gut says we should:
>> > 1) Use SQL:2003 as the baseline
>> > 2) Augment with DatabaseMetaData#getSQLKeywords
>> > 3) Augment with Dialect#getKeywords
>> > 4) (?) Augment with application-provided keywords
>> >
>> > FWIW (4) can actually be handles via custom PhysicalNamingStrategy in
>> > terms
>> > of a custom PhysicalNamingStrategy deciding to quote a given identifier.
>> >
>> >
>> > On Fri, May 1, 2015 at 8:51 AM, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >
>> >> Gail, I saw your ping on IRC and thought it made sense to address here,
>> >> since you were not around on IRC anymore.
>> >>
>> >> Overall, starting with 5.0, the idea is for Hibernate to automatically
>> >> quote any identifiers is recognizes as a keyword.  This is all
>> >> encapsulated
>> >> within the org.hibernate.engine.jdbc.env.spi.IdentifierHelper obtained
>> >> via
>> >> org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#getIdentifierHelper.
>> >>
>> >> There are 2 parts to this...
>> >>
>> >> First, we need to be able to recognize that an identifier is in fact a
>> >> keyword.  This piece is handled through
>> >> org.hibernate.engine.jdbc.env.spi.JdbcEnvironment#isReservedWord, which
>> >> is
>> >> based on a Set of keywords computed from 2 distinct "keyword sources":
>> >> 1) Dialect#getKeywords
>> >> 2) DatabaseMetaData#getSQLKeywords
>> >>
>> >> At the moment, I think this misses a third source... ANSI SQL 2003
>> >> standard keywords.  DatabaseMetaData#getSQLKeywords specifically is
>> >> supposed to return only keywords beyond the standard (2003) defined
>> >> ones.
>> >> There are really 2 options to address this:
>> >> 1) add these standard keywords to Dialect
>> >> 2) use a seperate (static) source for them.
>> >>
>> >> Personally I prefer the second.  Even if we added all the standard
>> >> keywords to the base Dialect Set, it is just too easy for the Dialect
>> >> subclass to override getKeywords().  Also, I like the idea of
>> >> continuing
>> >> the convention of these other 2 sources simply returning "extras".
>> >>
>> >> Second, and this is BY FAR the harder part, we need to make sure that
>> >> everywhere that is building identifiers is using this code.  I tried
>> >> hard
>> >> to make sure that was the case, but we all know that annotation binding
>> >> is
>> >> a mess and its just too easy to miss stuff in there.  I'm all happy for
>> >> a
>> >> second (or third, or fourth, ...) pair of eyes looking over this part,
>> >> but
>> >> I personally think it is not the best allocation of our time
>> >> considering
>> >> the difficulty in actually finding them all just by code review and the
>> >> time it would take and the amount of other stuff we have to do.
>> >> Eventually
>> >> we will get bug reports of cases where this does not happen.  My $.02
>> >>
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From martinbraun123 at aol.com  Fri May  1 13:34:34 2015
From: martinbraun123 at aol.com (Martin Braun)
Date: Fri, 1 May 2015 13:34:34 -0400
Subject: [hibernate-dev] Google Summer of Code 2015
In-Reply-To: <CAFm4XO23YOQfRakd5oKEvg4kRjNgtOFTth+AWXyC3S6zX49NsQ@mail.gmail.com>
Message-ID: <14d108b4d29-24cf-f49b@webprd-m18.mail.aol.com>

Hi Sanne,


could you provide me with the exact message it told you?
I am using the Web interface for aol.com so it can't be related
to my email client...


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




-----Original Message-----
From: Sanne Grinovero <sanne at hibernate.org>
To: Martin Braun <martinbraun123 at aol.com>
Cc: Hibernate Dev <hibernate-dev at lists.jboss.org>
Sent: Fri, May 1, 2015 4:40 pm
Subject: Re: [hibernate-dev] Google Summer of Code 2015


Hi Martin,
I would never have seen your email if Emmanuel hadn't replied to
it.

Apparently google (I'm using gmail) is flagging your email account
as
spam; the error message I see is too short and ambiguous to
understand
what's wrong, but it seems like aol.com could not meet
their
requirements.
This might be an issue with your provider, or it might
depend on how
you have setup your email client. I've enabled a specific filter
for
you but that applies only to me, I'd suggest you look at it ;)

--
Sanne

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

 

From steve at hibernate.org  Fri May  1 14:57:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 1 May 2015 13:57:55 -0500
Subject: [hibernate-dev] [!] Changing the Faceting API in Hibernate
	Search
In-Reply-To: <CAFm4XO1mmNk_W16ETbzdUZWvDQ6sKQTCQ+PGfGfW0759-Ue9vg@mail.gmail.com>
References: <CAFm4XO1mmNk_W16ETbzdUZWvDQ6sKQTCQ+PGfGfW0759-Ue9vg@mail.gmail.com>
Message-ID: <CAFdSV9ssWg1UNAaGKQoueht8XuM8yFnc00b1-wp=Tgb2nf8wpQ@mail.gmail.com>

So here is what I did.  I think this is the best compromise, short of us
hand crafting the keywords for each and every one of our Dialects...


1) I added this method to Dialect:

/**
 * Hook into auto-quoting of identifiers that are deemed to be keywords.
By default we
 * return all of the following here:<ul>
 *     <li>all keywords as defined by ANSI SQL:2003 specification</li>
 *     <li>all "extra" keywords reported by the JDBC driver </li>
 *     <li>all extra Dialect keywords</li>
 * </ul>
 * NOTE: The code that ultimately consumes these and uses them stores them
in a case-insensitive
 * Set, so case here does not matter.
 *
 * @see org.hibernate.engine.jdbc.env.spi.AnsiSqlKeywords#sql2003()
 * @see java.sql.DatabaseMetaData#getSQLKeywords()
 * @see #getKeywords()
 */
public Set<String> determineKeywordsForAutoQuoting(Set<String>
databaseMetadataReportedKeywords) {
final Set<String> keywords = new HashSet<String>();
keywords.addAll( AnsiSqlKeywords.INSTANCE.sql2003() );
keywords.addAll( databaseMetadataReportedKeywords );
keywords.addAll( getKeywords() );
return keywords;
}

2) Changed up JdbcEnvironment to use this method rather than just calling
Dialect#getKeywords

3) Deprecated Dialect#getKeywords


On Fri, May 1, 2015 at 10:56 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hi all,
>
> Hardy completed the Faceting re-work in Hibernate Search to use the
> much improved implementation from recent versions of Lucene, and we'd
> like to merge his work now making these improvements available to
> users of Hibernate Search 5.2.0+
>
> There is a catch: while the API to create a Faceting Query is
> unchanged and nicely backwards compatible, you'll now be required to
> explicitly sign up the fields which you want to be "facetable" using a
> new annotation: @Facet
>
> The default for an indexed property is that faceting is disabled, so
> people already using faceting will have to adjust their mapping, and
> rebuild the indexes accordingly.
> Unfortunately you won't notice the problem at compile time - and we
> can't validate for it at boot time - but you'll get a reasonable
> explanation in the exception when attempting to create a faceting
> query.
>
> There are many benefits to the new approach, so please bear with me
> for applying such a non-backwards compatible patch in a minor release:
> we won't break this rule often, nor are we lacking great reasons to
> proceed.
>
> For details see:
>  - https://github.com/hibernate/hibernate-search/pull/821
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From paranoiabla at gmail.com  Sat May  2 18:13:08 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Sun, 3 May 2015 01:13:08 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
Message-ID: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>

Hi guys,

I just tried hibernate 5.0 beta2 and here's my observations. First of all
the foreign key problems I had before seems to be resolved, however I see
the following error when executing tests with HSQL:


Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'defaultEntityManagerFactory' defined in class path
resource [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
Invocation of init method failed; nested exception is
javax.persistence.PersistenceException: [PersistenceUnit: default] Unable
to build Hibernate SessionFactory
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
    at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
    at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
    at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
    at
org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
    at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
    at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
    at
org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
    at
org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
    at
org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
    at
org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
    at
org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
    ... 36 more
Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
default] Unable to build Hibernate SessionFactory
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
    at
org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
    at
org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
    at
org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
    at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
    ... 50 more
Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: Unable
to execute schema management to JDBC target [alter table payment_info add
constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk) references
principal]
    at
org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
    at
org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
    at
org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
    at
org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
    at
org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
    at
org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
    at
org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
    at
org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
    at
org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
    at
org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
    at
org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
    ... 55 more
Caused by: java.sql.SQLSyntaxErrorException: object name already exists:
FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table payment_info add
constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk) references
principal]
    at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
    at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
    at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
    at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
    at
com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
    at
com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
    at
org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
    ... 65 more
Caused by: org.hsqldb.HsqlException: object name already exists:
FKS9WUD9NVE6S9CBOT5P4548JYH
    at org.hsqldb.error.Error.error(Unknown Source)
    at org.hsqldb.error.Error.error(Unknown Source)
    at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
    at org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown Source)
    at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
    at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
    at org.hsqldb.StatementSchema.getResult(Unknown Source)
    at org.hsqldb.StatementSchema.execute(Unknown Source)
    at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
    at org.hsqldb.Session.executeDirectStatement(Unknown Source)
    at org.hsqldb.Session.execute(Unknown Source)
    ... 70 more


When running it with mysql it doesn't show this error (very strange) so I
tried to export the schema to sql file and I can see only one foregin key
declaration:

    alter table payment_info
        add constraint FKs9wud9nve6s9cbot5p4548jyh
        foreign key (user_pk)
        references principal (pk);

Notice that this time it is lowercase. I'm trying to debug the hsql but it
is very hard as it doesn't stop on any of the breakpoints I add. If any of
you have an idea what might be causing it, please share your thoughts, if
not I'll let you know how I progress.

I wonder if it could be related to the duplicate joins warnings I see:
WARN : HHH000072: Duplicate joins for class:
com.nemesis.platform.core.model.media.MediaModel
WARN : HHH000072: Duplicate joins for class:
com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
WARN : HHH000072: Duplicate joins for class:
com.nemesis.platform.core.model.cms.AbstractPageModel
WARN : HHH000072: Duplicate joins for class:
com.nemesis.platform.core.model.cms.EmailPageModel
WARN : HHH000072: Duplicate joins for class:
com.nemesis.platform.core.model.cms.CategoryPageModel
.....

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From paranoiabla at gmail.com  Sun May  3 17:03:57 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Mon, 4 May 2015 00:03:57 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
Message-ID: <CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>

Hi guys,

I finally managed to reproduce it - here's a small application that will
generate the provided exception:

https://github.com/paranoiabla/hibernate-hsql-issue

Please notice that it works fine with Hibernate 4.3.x  I think it has to do
something with the CommerceCustomerModel - If I remove it or remove the
collection of payment infos that is inside of it, it all starts to work
fine.

Please have a look and thanks a lot for your efforts :)




2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:

> Hi guys,
>
> I just tried hibernate 5.0 beta2 and here's my observations. First of all
> the foreign key problems I had before seems to be resolved, however I see
> the following error when executing tests with HSQL:
>
>
> Caused by: org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'defaultEntityManagerFactory' defined in class path
> resource [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
> Invocation of init method failed; nested exception is
> javax.persistence.PersistenceException: [PersistenceUnit: default] Unable
> to build Hibernate SessionFactory
>     at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
>     at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>     at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>     at
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
>     at
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>     at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
>     at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
>     at
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
>     at
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
>     at
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
>     at
> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
>     at
> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
>     at
> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
>     at
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
>     at
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
>     ... 36 more
> Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
> default] Unable to build Hibernate SessionFactory
>     at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
>     at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
>     at
> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>     at
> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>     at
> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>     at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>     at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>     ... 50 more
> Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: Unable
> to execute schema management to JDBC target [alter table payment_info add
> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk) references
> principal]
>     at
> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
>     at
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
>     at
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
>     at
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
>     at
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
>     at
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
>     at
> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
>     at
> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
>     at
> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
>     at
> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
>     at
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
>     ... 55 more
> Caused by: java.sql.SQLSyntaxErrorException: object name already exists:
> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table payment_info add
> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk) references
> principal]
>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
>     at
> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
>     at
> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
>     at
> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
>     ... 65 more
> Caused by: org.hsqldb.HsqlException: object name already exists:
> FKS9WUD9NVE6S9CBOT5P4548JYH
>     at org.hsqldb.error.Error.error(Unknown Source)
>     at org.hsqldb.error.Error.error(Unknown Source)
>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
>     at org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown Source)
>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
>     at org.hsqldb.StatementSchema.execute(Unknown Source)
>     at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>     at org.hsqldb.Session.execute(Unknown Source)
>     ... 70 more
>
>
> When running it with mysql it doesn't show this error (very strange) so I
> tried to export the schema to sql file and I can see only one foregin key
> declaration:
>
>     alter table payment_info
>         add constraint FKs9wud9nve6s9cbot5p4548jyh
>         foreign key (user_pk)
>         references principal (pk);
>
> Notice that this time it is lowercase. I'm trying to debug the hsql but it
> is very hard as it doesn't stop on any of the breakpoints I add. If any of
> you have an idea what might be causing it, please share your thoughts, if
> not I'll let you know how I progress.
>
> I wonder if it could be related to the duplicate joins warnings I see:
> WARN : HHH000072: Duplicate joins for class:
> com.nemesis.platform.core.model.media.MediaModel
> WARN : HHH000072: Duplicate joins for class:
> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
> WARN : HHH000072: Duplicate joins for class:
> com.nemesis.platform.core.model.cms.AbstractPageModel
> WARN : HHH000072: Duplicate joins for class:
> com.nemesis.platform.core.model.cms.EmailPageModel
> WARN : HHH000072: Duplicate joins for class:
> com.nemesis.platform.core.model.cms.CategoryPageModel
> .....
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From amits.84 at gmail.com  Mon May  4 01:19:37 2015
From: amits.84 at gmail.com (amit shah)
Date: Mon, 4 May 2015 10:49:37 +0530
Subject: [hibernate-dev] Multitenancy Per Schema Fails With NPE
In-Reply-To: <CAFdSV9ugVs3EEB4nXkn5TO3CwaNhDU297pwTbPiaVx9pi1P0eA@mail.gmail.com>
References: <CALpK9-RatQXWSP75Mb=P60ec+5uFVi6hwxmCBaDGgY7AA8-qKg@mail.gmail.com>
	<CAFdSV9v+=vcfWSx+wUDXgFxGODRetjCpPJdzrG9aK3HyS7HBzQ@mail.gmail.com>
	<CALpK9-SOatR2S1c=LgsELruGcxCbUXkD+v31zpbeJLz0CLY=fQ@mail.gmail.com>
	<CAFdSV9ugVs3EEB4nXkn5TO3CwaNhDU297pwTbPiaVx9pi1P0eA@mail.gmail.com>
Message-ID: <CALpK9-QDR4RAaJEwst4T0HorotDu8jVikNQOBqRL3vXEW7Gdbw@mail.gmail.com>

Great! that helped.
Removing the config property worked out.

On Mon, Apr 27, 2015 at 4:29 PM, Steve Ebersole <steve at hibernate.org> wrote:

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

From gunnar at hibernate.org  Mon May  4 03:11:06 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 4 May 2015 09:11:06 +0200
Subject: [hibernate-dev] [!] Changing the Faceting API in Hibernate
	Search
In-Reply-To: <CAFm4XO1mmNk_W16ETbzdUZWvDQ6sKQTCQ+PGfGfW0759-Ue9vg@mail.gmail.com>
References: <CAFm4XO1mmNk_W16ETbzdUZWvDQ6sKQTCQ+PGfGfW0759-Ue9vg@mail.gmail.com>
Message-ID: <CADGJaX8EjtgJ1jC9vBNmAa1HpAY4XVKsEQ_gXYofmz9DzyC=yQ@mail.gmail.com>

+1 for merging this work and making the changed behaviour very apparent in
the migration notes  / announcement.

Btw. in addition to @Facet, it should be possible to enable specific fields
for faceting via the mapping API (if that's not part of the PR yet). Then a
user could programmatically enable faceting for all fields if that's what
they need.

--Gunnar


2015-05-01 17:56 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi all,
>
> Hardy completed the Faceting re-work in Hibernate Search to use the
> much improved implementation from recent versions of Lucene, and we'd
> like to merge his work now making these improvements available to
> users of Hibernate Search 5.2.0+
>
> There is a catch: while the API to create a Faceting Query is
> unchanged and nicely backwards compatible, you'll now be required to
> explicitly sign up the fields which you want to be "facetable" using a
> new annotation: @Facet
>
> The default for an indexed property is that faceting is disabled, so
> people already using faceting will have to adjust their mapping, and
> rebuild the indexes accordingly.
> Unfortunately you won't notice the problem at compile time - and we
> can't validate for it at boot time - but you'll get a reasonable
> explanation in the exception when attempting to create a faceting
> query.
>
> There are many benefits to the new approach, so please bear with me
> for applying such a non-backwards compatible patch in a minor release:
> we won't break this rule often, nor are we lacking great reasons to
> proceed.
>
> For details see:
>  - https://github.com/hibernate/hibernate-search/pull/821
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Mon May  4 04:33:16 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 4 May 2015 10:33:16 +0200
Subject: [hibernate-dev] [!] Changing the Faceting API in Hibernate
	Search
In-Reply-To: <CADGJaX8EjtgJ1jC9vBNmAa1HpAY4XVKsEQ_gXYofmz9DzyC=yQ@mail.gmail.com>
References: <CAFm4XO1mmNk_W16ETbzdUZWvDQ6sKQTCQ+PGfGfW0759-Ue9vg@mail.gmail.com>
	<CADGJaX8EjtgJ1jC9vBNmAa1HpAY4XVKsEQ_gXYofmz9DzyC=yQ@mail.gmail.com>
Message-ID: <20150504083316.GA54454@Nineveh.lan>

Hi,

On Mon, May 04, 2015 at 09:11:06AM +0200, Gunnar Morling wrote:
> +1 for merging this work and making the changed behaviour very apparent in
> the migration notes  / announcement.

+1 as well.

As I mentioned on the pull request, this is such a long standing issue and
a topic which we keep getting many questions and requests from users.
If it does not get merged now, I would assume it would not get in until Search 6
which imo is ways to late.

> Btw. in addition to @Facet, it should be possible to enable specific fields
> for faceting via the mapping API (if that's not part of the PR yet). Then a
> user could programmatically enable faceting for all fields if that's what
> they need.

Good idea. ATM it is not possible yet and I created https://hibernate.atlassian.net/browse/HSEARCH-1862
to track this. Probably a nice task for the next Search sprint.

--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/20150504/01f254c7/attachment.bin 

From emmanuel at hibernate.org  Mon May  4 12:42:29 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 4 May 2015 18:42:29 +0200
Subject: [hibernate-dev] Fwd: [wildfly-dev] WildFly 9.0.0.CR1 is released!
References: <55474a2f.654bb40a.1e24.563a@mx.google.com>
Message-ID: <44142A2D-F4F4-4FA6-999C-05A520C01B2A@hibernate.org>

Some info on Jandex 2.0 move on the WildFly front.

> Begin forwarded message:
> 
> From: Toma? Cerar <tomaz.cerar at gmail.com>
> Subject: Re: [wildfly-dev] WildFly 9.0.0.CR1 is released!
> Date: 4 May 2015 12:30:06 CEST
> To: Jozef Hartinger <jharting at redhat.com>, Jason Greene <jason.greene at redhat.com>, WildFly Dev <wildfly-dev at lists.jboss.org>
> 
> Yes!
> 
> With 10 we are moving to java 8 which will also bring in/allow us to move to jandex 2
> 
> Tomaz
> 
> Sent from my Phone
> From: Jozef Hartinger <mailto:jharting at redhat.com>
> Sent: ?4.?5.?2015 12:26
> To: Jason Greene <mailto:jason.greene at redhat.com>; WildFly Dev <mailto:wildfly-dev at lists.jboss.org>
> Subject: Re: [wildfly-dev] WildFly 9.0.0.CR1 is released!
> 
> Congrats on the release!
> 
> It seems that Jandex upgrade to 2.0 has not been done yet. Is my 
> understanding correct that it has been postponed till WF10?
> 
> On 05/01/2015 10:38 PM, Jason Greene wrote:
> > Hello Everyone,
> >
> > I am happy to announce the first candidate release of WildFly 9! WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new capabilities, including intelligent load balancing, HTTP/2 support, a new offline CLI mode, graceful single node shutdown, and a new Servlet-only distribution.
> >
> > For more details, check out the release notes:
> > https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes
> >
> > As always, you can download it here:
> > http://wildfly.org/downloads/
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


From steve at hibernate.org  Mon May  4 17:34:40 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 4 May 2015 16:34:40 -0500
Subject: [hibernate-dev] JPA callbacks enabled on SessionFactory
Message-ID: <CAFdSV9tz=dpwjPD_aYNW+JAFjV-1H2MkzPEQhefomkDSoXK7Dg@mail.gmail.com>

I recently have seen a bunch of attempts (and questions about) using JPA
callbacks with SessionFactory.  At the moment, a user would need to
manually enable the proper event listeners to get this to work.  I am
thinking about enabling this "out of the box".  Wanted to get everyone's
opinion.  I am thinking of this for post-5.0 (5.1 maybe).

From gunnar at hibernate.org  Tue May  5 03:04:42 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 5 May 2015 09:04:42 +0200
Subject: [hibernate-dev] Removing deprecated methods from Session and
	SessionFactory
Message-ID: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>

Hi,

There are several deprecated methods on Session:

* public Object load(Class theClass, Serializable id, LockMode lockMode)
* public Object load(String entityName, Serializable id, LockMode lockMode);
* public void lock(Object object, LockMode lockMode);
* public void lock(String entityName, Object object, LockMode lockMode);
* public void refresh(Object object, LockMode lockMode);
* public Object get(Class clazz, Serializable id, LockMode lockMode);
* public Object get(String entityName, Serializable id, LockMode lockMode);

and SessionFactory:

* public void evict(Class persistentClass) throws HibernateException;
* public void evict(Class persistentClass, Serializable id) throws
HibernateException;
* public void evictEntity(String entityName) throws HibernateException;
* public void evictEntity(String entityName, Serializable id) throws
HibernateException;
* public void evictCollection(String roleName) throws HibernateException;
* public void evictCollection(String roleName, Serializable id) throws
HibernateException;
* public void evictQueries(String cacheRegion) throws HibernateException;
* public void evictQueries() throws HibernateException;

The docs point to methods to be used alternatively, so the upcoming ORM 5
major release seems like a good occasion to remove these methods and
simplifying these contracts a bit. Any thoughts?

On a related note, I am wondering whether

    Session#public Object get(Class clazz, Serializable id, LockOptions
lockOptions);

etc. pull their weight. The same could be achieved via

    byId( entityClass ).with( lockOptions ).load( id )

Is it actually worth to have these "shortcut" methods?

--Gunnar

From mih_vlad at yahoo.com  Tue May  5 03:54:03 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Tue, 5 May 2015 07:54:03 +0000 (UTC)
Subject: [hibernate-dev] Immutable entities read-only caching improvement
	proposal
Message-ID: <1539900964.131704.1430812443770.JavaMail.yahoo@mail.yahoo.com>


Hi guys,
Taking this comment as a starting point
http://vladmihalcea.com/2015/04/27/how-does-hibernate-read_only-cacheconcurrencystrategy-work/comment-page-1/#comment-3404
To reduce cache entities hydration, we could simply use the: "hibernate.cache.use_reference_entries" setting, but that's too restrictive
as the AbstractEntityPersister prevents it when there are one-to-many associations on an immutable entity:
??? public boolean canUseReferenceCacheEntries() {
??? ??? // todo : should really validate that the cache access type is read-only

??? ??? if ( ! factory.getSettings().isDirectReferenceCacheEntriesEnabled() ) {
??? ??? ??? return false;
??? ??? }

??? ??? // for now, limit this to just entities that:
??? ??? // ??? ??? 1) are immutable
??? ??? if ( entityMetamodel.isMutable() ) {
??? ??? ??? return false;
??? ??? }

??? ??? //??? ??? 2)? have no associations.? Eventually we want to be a little more lenient with associations.
??? ??? for ( Type type : getSubclassPropertyTypeClosure() ) {
??? ??? ??? if ( type.isAssociationType() ) {
??? ??? ??? ??? return false;
??? ??? ??? }
??? ??? }

??? ??? return true;
??? }
If the entity is immutable and all to-many associations are all marked with "@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_ONLY)" 
we could allow the entity graph to be saved as an object reference.
This way we can save a lot of unnecessary CPU processing, spent with hydrating each second-level cache entry.

Vlad

From paranoiabla at gmail.com  Tue May  5 04:19:14 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Tue, 5 May 2015 11:19:14 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
	<CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
Message-ID: <CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>

Any of you have seen this issue? Shall I open a ticket?

2015-05-04 0:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:

> Hi guys,
>
> I finally managed to reproduce it - here's a small application that will
> generate the provided exception:
>
> https://github.com/paranoiabla/hibernate-hsql-issue
>
> Please notice that it works fine with Hibernate 4.3.x  I think it has to
> do something with the CommerceCustomerModel - If I remove it or remove the
> collection of payment infos that is inside of it, it all starts to work
> fine.
>
> Please have a look and thanks a lot for your efforts :)
>
>
>
>
> 2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>
>> Hi guys,
>>
>> I just tried hibernate 5.0 beta2 and here's my observations. First of all
>> the foreign key problems I had before seems to be resolved, however I see
>> the following error when executing tests with HSQL:
>>
>>
>> Caused by: org.springframework.beans.factory.BeanCreationException: Error
>> creating bean with name 'defaultEntityManagerFactory' defined in class path
>> resource [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
>> Invocation of init method failed; nested exception is
>> javax.persistence.PersistenceException: [PersistenceUnit: default] Unable
>> to build Hibernate SessionFactory
>>     at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
>>     at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>>     at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>>     at
>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
>>     at
>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>>     at
>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
>>     at
>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
>>     at
>> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
>>     at
>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
>>     at
>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
>>     at
>> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
>>     at
>> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
>>     at
>> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
>>     at
>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
>>     at
>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
>>     ... 36 more
>> Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
>> default] Unable to build Hibernate SessionFactory
>>     at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
>>     at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
>>     at
>> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>>     at
>> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>>     at
>> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>>     at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>>     at
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>>     ... 50 more
>> Caused by: org.hibernate.tool.schema.spi.SchemaManagementException:
>> Unable to execute schema management to JDBC target [alter table
>> payment_info add constraint FKs9wud9nve6s9cbot5p4548jyh foreign key
>> (user_pk) references principal]
>>     at
>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
>>     at
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
>>     at
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
>>     at
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
>>     at
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
>>     at
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
>>     at
>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
>>     at
>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
>>     at
>> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
>>     at
>> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
>>     at
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
>>     ... 55 more
>> Caused by: java.sql.SQLSyntaxErrorException: object name already exists:
>> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table payment_info add
>> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk) references
>> principal]
>>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
>>     at
>> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
>>     at
>> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
>>     at
>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
>>     ... 65 more
>> Caused by: org.hsqldb.HsqlException: object name already exists:
>> FKS9WUD9NVE6S9CBOT5P4548JYH
>>     at org.hsqldb.error.Error.error(Unknown Source)
>>     at org.hsqldb.error.Error.error(Unknown Source)
>>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
>>     at org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown Source)
>>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
>>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
>>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
>>     at org.hsqldb.StatementSchema.execute(Unknown Source)
>>     at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>>     at org.hsqldb.Session.execute(Unknown Source)
>>     ... 70 more
>>
>>
>> When running it with mysql it doesn't show this error (very strange) so I
>> tried to export the schema to sql file and I can see only one foregin key
>> declaration:
>>
>>     alter table payment_info
>>         add constraint FKs9wud9nve6s9cbot5p4548jyh
>>         foreign key (user_pk)
>>         references principal (pk);
>>
>> Notice that this time it is lowercase. I'm trying to debug the hsql but
>> it is very hard as it doesn't stop on any of the breakpoints I add. If any
>> of you have an idea what might be causing it, please share your thoughts,
>> if not I'll let you know how I progress.
>>
>> I wonder if it could be related to the duplicate joins warnings I see:
>> WARN : HHH000072: Duplicate joins for class:
>> com.nemesis.platform.core.model.media.MediaModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.nemesis.platform.core.model.cms.AbstractPageModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.nemesis.platform.core.model.cms.EmailPageModel
>> WARN : HHH000072: Duplicate joins for class:
>> com.nemesis.platform.core.model.cms.CategoryPageModel
>> .....
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>



-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From emmanuel at hibernate.org  Tue May  5 04:58:57 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 5 May 2015 10:58:57 +0200
Subject: [hibernate-dev] JPA callbacks enabled on SessionFactory
In-Reply-To: <CAFdSV9tz=dpwjPD_aYNW+JAFjV-1H2MkzPEQhefomkDSoXK7Dg@mail.gmail.com>
References: <CAFdSV9tz=dpwjPD_aYNW+JAFjV-1H2MkzPEQhefomkDSoXK7Dg@mail.gmail.com>
Message-ID: <6B9FE5E0-190B-4D36-841A-5C8D2A9EA961@hibernate.org>

I cannot see any harm.

> On 04 May 2015, at 23:34, Steve Ebersole <steve at hibernate.org> wrote:
> 
> I recently have seen a bunch of attempts (and questions about) using JPA
> callbacks with SessionFactory.  At the moment, a user would need to
> manually enable the proper event listeners to get this to work.  I am
> thinking about enabling this "out of the box".  Wanted to get everyone's
> opinion.  I am thinking of this for post-5.0 (5.1 maybe).
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From mih_vlad at yahoo.com  Tue May  5 06:52:45 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Tue, 5 May 2015 10:52:45 +0000 (UTC)
Subject: [hibernate-dev] NonStrictReadWriteEhcacheEntityRegionAccessStrategy
 removes the region Cache key twice
Message-ID: <280423352.179453.1430823165965.JavaMail.yahoo@mail.yahoo.com>

Hi,
When an entity is updated for the "CacheConcurrencyStrategy.NONSTRICT_READ_WRITE", the cache entry is removed twice:
1. Once from update:public boolean update(Object key, Object value, Object currentVersion, Object previousVersion)
      throws CacheException {
   remove( key );
   return false;
}


Vlad Mihalcea


From mih_vlad at yahoo.com  Tue May  5 06:55:52 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Tue, 5 May 2015 10:55:52 +0000 (UTC)
Subject: [hibernate-dev]
 NonStrictReadWriteEhcacheEntityRegionAccessStrategy removes the region
 Cache key twice
In-Reply-To: <280423352.179453.1430823165965.JavaMail.yahoo@mail.yahoo.com>
References: <280423352.179453.1430823165965.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <374549129.182321.1430823352485.JavaMail.yahoo@mail.yahoo.com>

Hi,

When an entity is updated for the "CacheConcurrencyStrategy.NONSTRICT_READ_WRITE", the cache entry is removed twice:

1. Once from update:

public boolean update(Object key, Object value, Object currentVersion, Object previousVersion)
????? throws CacheException {
?? remove( key );
?? return false;
}

2. From unlockItem:

@Override
public void unlockItem(Object key, SoftLock lock) throws CacheException {
?? ?region().remove( key );
}

Shouldn't this be called only once, either from update or from unlockItem, which is called in doAfterTransactionCompletion? 

Vlad Mihalcea?
 


     On Tuesday, May 5, 2015 1:52 PM, Mihalcea Vlad <mih_vlad at yahoo.com> wrote:
   

 Hi,
When an entity is updated for the "CacheConcurrencyStrategy.NONSTRICT_READ_WRITE", the cache entry is removed twice:
1. Once from update:public boolean update(Object key, Object value, Object currentVersion, Object previousVersion)
      throws CacheException {
   remove( key );
   return false;
}


Vlad Mihalcea



  

From sanne at hibernate.org  Tue May  5 07:04:55 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 5 May 2015 12:04:55 +0100
Subject: [hibernate-dev] Which versions of the application server should the
 Hibernate OGM modules support
Message-ID: <CAFm4XO3_GOJH_m+if+KmFKZgDvkdOMeszaTc-i6NnkH0qKR2kg@mail.gmail.com>

Hello all,
I actually have multiple questions on the subject.

# Module name

The Maven artifact id of the modules we're producing for WildFly 8 is
aptly named "org.hibernate.ogm:hibernate-ogm-modules-wildfly8".

I still think that's a good choice, as deploying modules is an
operation which is strictly coupled to the application server version.
I'm merly reminding this point as it suggests we *could* if - we want
to - easily produce modules for multiple application server versions.

# EAP versions

We're also producing modules for JBoss EAP6, but AFAIR these need some
love and I'm not sure if it's worth the effort - it might not need to
much work and I'm happy to look at it if you want to, but in case we
fix it these should have proper integration tests [next]:

# Integration tests of these modules

The current solution is that the integration tests are run with a
profile selection: so we choose upfront in the build if we want to
test the wildfly8 modules or the eap6 modules.

Are we still happy with this setup? I don't see a CI job which
verifies the EAP6 modules and I doubt you're all running the tests
twice.
Should we:
 A) add the CI job to verify the other profiles (EAP6 and others as needed)
 B) change approach and have the tests re-run for any build
 C) remove the EAP6 modules

My vote goes for B, even though it will make test runs take a bit
longer. To improve speed we can do other things - to be discussed
separately so I'd hope we don't give the execution speed too much
weight for the above choice.

# WildFly 8 vs WildFly 9

At the last meeting we agreed to support WildFly 9. We didn't decide
at what cost towards WF8 users: should we drop the WF8 modules?
I think I'm ok with dropping the older modules, however since we have
chosen for a module name which includes the version, it's pretty easy
for us to keep the WF8 modules around for now, and it's equally easy
to remove them from the project in future when we don't want to do
that anymore.

Documentation (user complexity) wise the instructions would be
identical so it's not a big burden to explain - one would just need to
pick the right set of modules.

I would prefer to keep the WF8 modules around for a little bit, but
only if we agree on an integration testing strategy which is able to
cover all the modules we build.

# JBoss Logger version

As a reminder, there's an update for JBoss Logger which - if applied -
will make it harder for OGM to work on WF8. Gunnar is making some
interesting suggestions to work around this on OGM-803 but let's see
first if
 - we really want to keep WF8
 - cant we not simply wait to update, I don't see why we should seel
trouble by upgrading this component now.

Sanne

From daltodavide at gmail.com  Tue May  5 07:33:50 2015
From: daltodavide at gmail.com (Davide D'Alto)
Date: Tue, 5 May 2015 12:33:50 +0100
Subject: [hibernate-dev] Which versions of the application server should
 the Hibernate OGM modules support
In-Reply-To: <CAFm4XO3_GOJH_m+if+KmFKZgDvkdOMeszaTc-i6NnkH0qKR2kg@mail.gmail.com>
References: <CAFm4XO3_GOJH_m+if+KmFKZgDvkdOMeszaTc-i6NnkH0qKR2kg@mail.gmail.com>
Message-ID: <CANoTJYPB3cyfxugdiJ-MiPxXA5TJM1_z=gOKoVzuXL9SqA+YWQ@mail.gmail.com>

> # EAP versions
>
> We're also producing modules for JBoss EAP6, but AFAIR these need some
> ove and I'm not sure if it's worth the effort - it might not need to
> much work and I'm happy to look at it if you want to, but in case we
>fix it these should have proper integration tests [next]:

I think we already have integration tests in place, we are not running them
at the moment
because the module for eap needs some love.

There is a profile in the pom of  hibernate-ogm-integrationtest.
If you enable the profile the test are executed (mvn -Peap).

It would probabaly be easier to maintain update if we move the tests in
different modules,
the speed of the build can still be managed via profile.

I think the reason it wasn't executed by default was mainly because there
was some complexity when downloading EAP from the repository for new
contributors.
I'm not sure if this is still the case

> # Integration tests of these modules
> ...
> B) change approach and have the tests re-run for any build

This is the solution I prefer although it might slow down the build.
Is it possible for a new contributor to dowload EAP from a maven repository
or does it requires
a special repository and related permissions?

Davide




On Tue, May 5, 2015 at 12:04 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Hello all,
> I actually have multiple questions on the subject.
>
> # Module name
>
> The Maven artifact id of the modules we're producing for WildFly 8 is
> aptly named "org.hibernate.ogm:hibernate-ogm-modules-wildfly8".
>
> I still think that's a good choice, as deploying modules is an
> operation which is strictly coupled to the application server version.
> I'm merly reminding this point as it suggests we *could* if - we want
> to - easily produce modules for multiple application server versions.
>
> # EAP versions
>
> We're also producing modules for JBoss EAP6, but AFAIR these need some
> love and I'm not sure if it's worth the effort - it might not need to
> much work and I'm happy to look at it if you want to, but in case we
> fix it these should have proper integration tests [next]:
>
> # Integration tests of these modules
>
> The current solution is that the integration tests are run with a
> profile selection: so we choose upfront in the build if we want to
> test the wildfly8 modules or the eap6 modules.
>
> Are we still happy with this setup? I don't see a CI job which
> verifies the EAP6 modules and I doubt you're all running the tests
> twice.
> Should we:
>  A) add the CI job to verify the other profiles (EAP6 and others as needed)
>  B) change approach and have the tests re-run for any build
>  C) remove the EAP6 modules
>
> My vote goes for B, even though it will make test runs take a bit
> longer. To improve speed we can do other things - to be discussed
> separately so I'd hope we don't give the execution speed too much
> weight for the above choice.
>
> # WildFly 8 vs WildFly 9
>
> At the last meeting we agreed to support WildFly 9. We didn't decide
> at what cost towards WF8 users: should we drop the WF8 modules?
> I think I'm ok with dropping the older modules, however since we have
> chosen for a module name which includes the version, it's pretty easy
> for us to keep the WF8 modules around for now, and it's equally easy
> to remove them from the project in future when we don't want to do
> that anymore.
>
> Documentation (user complexity) wise the instructions would be
> identical so it's not a big burden to explain - one would just need to
> pick the right set of modules.
>
> I would prefer to keep the WF8 modules around for a little bit, but
> only if we agree on an integration testing strategy which is able to
> cover all the modules we build.
>
> # JBoss Logger version
>
> As a reminder, there's an update for JBoss Logger which - if applied -
> will make it harder for OGM to work on WF8. Gunnar is making some
> interesting suggestions to work around this on OGM-803 but let's see
> first if
>  - we really want to keep WF8
>  - cant we not simply wait to update, I don't see why we should seel
> trouble by upgrading this component now.
>
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue May  5 07:39:49 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 5 May 2015 13:39:49 +0200
Subject: [hibernate-dev] Which versions of the application server should
 the Hibernate OGM modules support
In-Reply-To: <CAFm4XO3_GOJH_m+if+KmFKZgDvkdOMeszaTc-i6NnkH0qKR2kg@mail.gmail.com>
References: <CAFm4XO3_GOJH_m+if+KmFKZgDvkdOMeszaTc-i6NnkH0qKR2kg@mail.gmail.com>
Message-ID: <CADGJaX_WdVo5HUD=Nq49aXwy_2q3ee8w0J-7NuxoDhOH-41mjQ@mail.gmail.com>

Hi,

Answers inline.

--Gunnar

2015-05-05 13:04 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hello all,
> I actually have multiple questions on the subject.
>
> # Module name
>
> The Maven artifact id of the modules we're producing for WildFly 8 is
> aptly named "org.hibernate.ogm:hibernate-ogm-modules-wildfly8".
>
> I still think that's a good choice, as deploying modules is an
> operation which is strictly coupled to the application server version.
> I'm merly reminding this point as it suggests we *could* if - we want
> to - easily produce modules for multiple application server versions.
>

Yes, this was exactly the idea behind this naming: being able to provide
modules for different baseline versions, WF 8, 9 etc. Whether we actually
do create more than one at a given time is another question IMO. Also if
there is only a single ZIP targeting WF, having the major revision in their
still communicates very clearly the targeted baseline.

>
> # EAP versions
>
> We're also producing modules for JBoss EAP6, but AFAIR these need some
> love and I'm not sure if it's worth the effort - it might not need to
> much work and I'm happy to look at it if you want to, but in case we
> fix it these should have proper integration tests [next]:
>

At this point the EAP6 module ZIP is quite outdated, I don't think it will
work as is. Maybe it's not a bad idea to update it now that 6.4 is out? I
am not sure about the effort it'd need, but I expect quite a few modules
would have to be updated (including ORM).

>
> # Integration tests of these modules
>
> The current solution is that the integration tests are run with a
> profile selection: so we choose upfront in the build if we want to
> test the wildfly8 modules or the eap6 modules.
>
> Are we still happy with this setup? I don't see a CI job which
> verifies the EAP6 modules and I doubt you're all running the tests
> twice.
> Should we:
>  A) add the CI job to verify the other profiles (EAP6 and others as needed)
>  B) change approach and have the tests re-run for any build
>  C) remove the EAP6 modules
>
> My vote goes for B, even though it will make test runs take a bit
> longer. To improve speed we can do other things - to be discussed
> separately so I'd hope we don't give the execution speed too much
> weight for the above choice.
>

There is no CI job (anymore) as the EAP module ZIP is outdated :) Once that
has been addressed, such job could (and should) easily be re-instantiated,
so my vote would go for A).

Wrt. B), is this to say that you'd run the tests for WF *and* EAP as part
of local builds, too? If so, I am no fan of it. Build time is an issue, so
my preference is to test one set up during the default build (i.e. also
locally when running "mvn clean install") and run all others on CI. We do
the same e.g. for JDK versions (8, 9) and MongoDB providers (actual
MongoDB, Fongo). Running all these (and possibly combinations thereof) as
part of each build just takes too long.

# WildFly 8 vs WildFly 9
>
> At the last meeting we agreed to support WildFly 9. We didn't decide
> at what cost towards WF8 users: should we drop the WF8 modules?
>

It was my understanding that we would not put effort into updating the
modules for WF8 but rather focus on WF9. If there was a community-provided
PR for updating the WF8 ZIP, that'd be great of course and I would be all
for integrating it.


> I think I'm ok with dropping the older modules, however since we have
> chosen for a module name which includes the version, it's pretty easy
> for us to keep the WF8 modules around for now, and it's equally easy
> to remove them from the project in future when we don't want to do
> that anymore.
>

The name is one thing, but it also needs to be maintained. As said on JIRA,
the WF8 ZIP would at least have to be updated to pull in ORM 4.3.9. OGM
depends on a bugfix provided in that version. We used to have a local
work-around for this (so we could work with 4.3.7 coming with WF 8), but we
have just removed this. Now we could un-do that, but I'd prefer to move on
actually (if not only to benefit from other bug fixes in 4.3.9).

>
> Documentation (user complexity) wise the instructions would be
> identical so it's not a big burden to explain - one would just need to
> pick the right set of modules.
>
> I would prefer to keep the WF8 modules around for a little bit, but
> only if we agree on an integration testing strategy which is able to
> cover all the modules we build.
>

See above, the WF8 ZIP would need at least one update. Should we decide to
keep it, the integration test module would need to get another profile, so
we can run tests against WF 8 and 9 (on CI).


> # JBoss Logger version
>
> As a reminder, there's an update for JBoss Logger which - if applied -
> will make it harder for OGM to work on WF8. Gunnar is making some
> interesting suggestions to work around this on OGM-803 but let's see
> first if
>  - we really want to keep WF8
>  - cant we not simply wait to update, I don't see why we should seel
> trouble by upgrading this component now.
>

My reasoning for upgrading was that I prefer to work with a consistent set
of matching dependencies. But I just noticed that there is an inconsistency
already: ORM 4.3.9 still is on 3.1.3, whereas WF 9 has 3.2.1. So this could
wait a bit indeed IMO.



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

From sanne at hibernate.org  Tue May  5 07:48:44 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 5 May 2015 12:48:44 +0100
Subject: [hibernate-dev] Which versions of the application server should
 the Hibernate OGM modules support
In-Reply-To: <CANoTJYPB3cyfxugdiJ-MiPxXA5TJM1_z=gOKoVzuXL9SqA+YWQ@mail.gmail.com>
References: <CAFm4XO3_GOJH_m+if+KmFKZgDvkdOMeszaTc-i6NnkH0qKR2kg@mail.gmail.com>
	<CANoTJYPB3cyfxugdiJ-MiPxXA5TJM1_z=gOKoVzuXL9SqA+YWQ@mail.gmail.com>
Message-ID: <CAFm4XO0qf0NGab6L6qHJ_PbPhEsr9We3O9rii0mFp=3C58auXg@mail.gmail.com>

On 5 May 2015 at 12:33, Davide D'Alto <daltodavide at gmail.com> wrote:
>> # EAP versions
>>
>> We're also producing modules for JBoss EAP6, but AFAIR these need some
>> ove and I'm not sure if it's worth the effort - it might not need to
>> much work and I'm happy to look at it if you want to, but in case we
>>fix it these should have proper integration tests [next]:
>
> I think we already have integration tests in place, we are not running them
> at the moment
> because the module for eap needs some love.

That's what I refer to in the next paragraph.

> There is a profile in the pom of  hibernate-ogm-integrationtest.
> If you enable the profile the test are executed (mvn -Peap).
>
> It would probabaly be easier to maintain update if we move the tests in
> different modules,
> the speed of the build can still be managed via profile.
>
> I think the reason it wasn't executed by default was mainly because there
> was some complexity when downloading EAP from the repository for new
> contributors.
> I'm not sure if this is still the case
>
>> # Integration tests of these modules
>> ...
>> B) change approach and have the tests re-run for any build
>
> This is the solution I prefer although it might slow down the build.
> Is it possible for a new contributor to dowload EAP from a maven repository
> or does it requires
> a special repository and related permissions?

Good point, that reminds me why we had it as a profile. Still WF8 &&
WF9 could both be built w/o adding an additional repository.

I'll see if that can all be automated.

Thanks,
Sanne

>
> Davide
>
>
>
>
> On Tue, May 5, 2015 at 12:04 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Hello all,
>> I actually have multiple questions on the subject.
>>
>> # Module name
>>
>> The Maven artifact id of the modules we're producing for WildFly 8 is
>> aptly named "org.hibernate.ogm:hibernate-ogm-modules-wildfly8".
>>
>> I still think that's a good choice, as deploying modules is an
>> operation which is strictly coupled to the application server version.
>> I'm merly reminding this point as it suggests we *could* if - we want
>> to - easily produce modules for multiple application server versions.
>>
>> # EAP versions
>>
>> We're also producing modules for JBoss EAP6, but AFAIR these need some
>> love and I'm not sure if it's worth the effort - it might not need to
>> much work and I'm happy to look at it if you want to, but in case we
>> fix it these should have proper integration tests [next]:
>>
>> # Integration tests of these modules
>>
>> The current solution is that the integration tests are run with a
>> profile selection: so we choose upfront in the build if we want to
>> test the wildfly8 modules or the eap6 modules.
>>
>> Are we still happy with this setup? I don't see a CI job which
>> verifies the EAP6 modules and I doubt you're all running the tests
>> twice.
>> Should we:
>>  A) add the CI job to verify the other profiles (EAP6 and others as
>> needed)
>>  B) change approach and have the tests re-run for any build
>>  C) remove the EAP6 modules
>>
>> My vote goes for B, even though it will make test runs take a bit
>> longer. To improve speed we can do other things - to be discussed
>> separately so I'd hope we don't give the execution speed too much
>> weight for the above choice.
>>
>> # WildFly 8 vs WildFly 9
>>
>> At the last meeting we agreed to support WildFly 9. We didn't decide
>> at what cost towards WF8 users: should we drop the WF8 modules?
>> I think I'm ok with dropping the older modules, however since we have
>> chosen for a module name which includes the version, it's pretty easy
>> for us to keep the WF8 modules around for now, and it's equally easy
>> to remove them from the project in future when we don't want to do
>> that anymore.
>>
>> Documentation (user complexity) wise the instructions would be
>> identical so it's not a big burden to explain - one would just need to
>> pick the right set of modules.
>>
>> I would prefer to keep the WF8 modules around for a little bit, but
>> only if we agree on an integration testing strategy which is able to
>> cover all the modules we build.
>>
>> # JBoss Logger version
>>
>> As a reminder, there's an update for JBoss Logger which - if applied -
>> will make it harder for OGM to work on WF8. Gunnar is making some
>> interesting suggestions to work around this on OGM-803 but let's see
>> first if
>>  - we really want to keep WF8
>>  - cant we not simply wait to update, I don't see why we should seel
>> trouble by upgrading this component now.
>>
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From sanne at hibernate.org  Tue May  5 08:09:16 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 5 May 2015 13:09:16 +0100
Subject: [hibernate-dev] Which versions of the application server should
 the Hibernate OGM modules support
In-Reply-To: <CADGJaX_WdVo5HUD=Nq49aXwy_2q3ee8w0J-7NuxoDhOH-41mjQ@mail.gmail.com>
References: <CAFm4XO3_GOJH_m+if+KmFKZgDvkdOMeszaTc-i6NnkH0qKR2kg@mail.gmail.com>
	<CADGJaX_WdVo5HUD=Nq49aXwy_2q3ee8w0J-7NuxoDhOH-41mjQ@mail.gmail.com>
Message-ID: <CAFm4XO1wtgJVVAhfcEhAotPHZ1ODjroVM1aoLkLmpvNgjrpC5Q@mail.gmail.com>

On 5 May 2015 at 12:39, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> Answers inline.
>
> --Gunnar
>
> 2015-05-05 13:04 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Hello all,
>> I actually have multiple questions on the subject.
>>
>> # Module name
>>
>> The Maven artifact id of the modules we're producing for WildFly 8 is
>> aptly named "org.hibernate.ogm:hibernate-ogm-modules-wildfly8".
>>
>> I still think that's a good choice, as deploying modules is an
>> operation which is strictly coupled to the application server version.
>> I'm merly reminding this point as it suggests we *could* if - we want
>> to - easily produce modules for multiple application server versions.
>
>
> Yes, this was exactly the idea behind this naming: being able to provide
> modules for different baseline versions, WF 8, 9 etc. Whether we actually do
> create more than one at a given time is another question IMO. Also if there
> is only a single ZIP targeting WF, having the major revision in their still
> communicates very clearly the targeted baseline.
>>
>>
>> # EAP versions
>>
>> We're also producing modules for JBoss EAP6, but AFAIR these need some
>> love and I'm not sure if it's worth the effort - it might not need to
>> much work and I'm happy to look at it if you want to, but in case we
>> fix it these should have proper integration tests [next]:
>
>
> At this point the EAP6 module ZIP is quite outdated, I don't think it will
> work as is. Maybe it's not a bad idea to update it now that 6.4 is out? I am
> not sure about the effort it'd need, but I expect quite a few modules would
> have to be updated (including ORM).

Likely, as I said. I proposed to volunteer for this but only if we
agree we want that.
I guess you're both voting for it?


>> # Integration tests of these modules
>>
>> The current solution is that the integration tests are run with a
>> profile selection: so we choose upfront in the build if we want to
>> test the wildfly8 modules or the eap6 modules.
>>
>> Are we still happy with this setup? I don't see a CI job which
>> verifies the EAP6 modules and I doubt you're all running the tests
>> twice.
>> Should we:
>>  A) add the CI job to verify the other profiles (EAP6 and others as
>> needed)
>>  B) change approach and have the tests re-run for any build
>>  C) remove the EAP6 modules
>>
>> My vote goes for B, even though it will make test runs take a bit
>> longer. To improve speed we can do other things - to be discussed
>> separately so I'd hope we don't give the execution speed too much
>> weight for the above choice.
>
>
> There is no CI job (anymore) as the EAP module ZIP is outdated :) Once that
> has been addressed, such job could (and should) easily be re-instantiated,
> so my vote would go for A).
>
> Wrt. B), is this to say that you'd run the tests for WF *and* EAP as part of
> local builds, too? If so, I am no fan of it. Build time is an issue, so my
> preference is to test one set up during the default build (i.e. also locally
> when running "mvn clean install") and run all others on CI. We do the same
> e.g. for JDK versions (8, 9) and MongoDB providers (actual MongoDB, Fongo).
> Running all these (and possibly combinations thereof) as part of each build
> just takes too long.
>
>> # WildFly 8 vs WildFly 9
>>
>> At the last meeting we agreed to support WildFly 9. We didn't decide
>> at what cost towards WF8 users: should we drop the WF8 modules?
>
>
> It was my understanding that we would not put effort into updating the
> modules for WF8 but rather focus on WF9. If there was a community-provided
> PR for updating the WF8 ZIP, that'd be great of course and I would be all
> for integrating it.

The WF8 updates are working fine today, there is no need for a PR.

My question is rather if we should aim at keeping them working, or
throw out and replace with WF9.
It's also related to how you do integration tests.

I'll code the module to produce both, we can later decide if you want
these to trigger by a non-default profile or have options to disable
them locally.


>> I think I'm ok with dropping the older modules, however since we have
>> chosen for a module name which includes the version, it's pretty easy
>> for us to keep the WF8 modules around for now, and it's equally easy
>> to remove them from the project in future when we don't want to do
>> that anymore.
>
>
> The name is one thing, but it also needs to be maintained. As said on JIRA,
> the WF8 ZIP would at least have to be updated to pull in ORM 4.3.9. OGM
> depends on a bugfix provided in that version. We used to have a local
> work-around for this (so we could work with 4.3.7 coming with WF 8), but we
> have just removed this. Now we could un-do that, but I'd prefer to move on
> actually (if not only to benefit from other bug fixes in 4.3.9).

Tests seem to work fine, while it's linked to the default module or
ORM (v. 4.3.7).
What am I missing?
In this scope we're not after the ORM bugfixes.

>>
>>
>> Documentation (user complexity) wise the instructions would be
>> identical so it's not a big burden to explain - one would just need to
>> pick the right set of modules.
>>
>> I would prefer to keep the WF8 modules around for a little bit, but
>> only if we agree on an integration testing strategy which is able to
>> cover all the modules we build.
>
>
> See above, the WF8 ZIP would need at least one update. Should we decide to
> keep it, the integration test module would need to get another profile, so
> we can run tests against WF 8 and 9 (on CI).

Ok, but could you please open JIRAs to point out what's wrong with the
WF8 modules?

>
>>
>> # JBoss Logger version
>>
>> As a reminder, there's an update for JBoss Logger which - if applied -
>> will make it harder for OGM to work on WF8. Gunnar is making some
>> interesting suggestions to work around this on OGM-803 but let's see
>> first if
>>  - we really want to keep WF8
>>  - cant we not simply wait to update, I don't see why we should seel
>> trouble by upgrading this component now.
>
>
> My reasoning for upgrading was that I prefer to work with a consistent set
> of matching dependencies. But I just noticed that there is an inconsistency
> already: ORM 4.3.9 still is on 3.1.3, whereas WF 9 has 3.2.1. So this could
> wait a bit indeed IMO.

+1 Let's align with ORM, not the containers. Especially as the old
version works in the newer containers.

Thanks,
Sanne

From gunnar at hibernate.org  Tue May  5 08:30:57 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 5 May 2015 14:30:57 +0200
Subject: [hibernate-dev] Which versions of the application server should
 the Hibernate OGM modules support
In-Reply-To: <CAFm4XO1wtgJVVAhfcEhAotPHZ1ODjroVM1aoLkLmpvNgjrpC5Q@mail.gmail.com>
References: <CAFm4XO3_GOJH_m+if+KmFKZgDvkdOMeszaTc-i6NnkH0qKR2kg@mail.gmail.com>
	<CADGJaX_WdVo5HUD=Nq49aXwy_2q3ee8w0J-7NuxoDhOH-41mjQ@mail.gmail.com>
	<CAFm4XO1wtgJVVAhfcEhAotPHZ1ODjroVM1aoLkLmpvNgjrpC5Q@mail.gmail.com>
Message-ID: <CADGJaX9ftjGkB4kmy=93M_XC21PJP6poY-PTYTOXNpD+ANHEVA@mail.gmail.com>

Had a quick chat with Sanne on IRC :)

The reason it seemingly works with WF 8 + ORM 4.3.7 is that the bug I have
been talking about (HHH-9451) is not triggered by any of the integration
tests running on WF but only by a unit test in the MongoDB module.

Thus we agreed to not go through the hazzle of updating the WF 8 module ZIP
and create one for WF 9 instead. We will stick to the JBL version used by
ORM, so users could still create their own WF 8 module ZIP if needed.

Wrt. to the ZIP, could this be provided alternatively in form of a "feature
pack" instead? I have been hearing about it  several times, but I don't
know really whether that's possible already and what it would take to do it.

--Gunnar



2015-05-05 14:09 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> On 5 May 2015 at 12:39, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > Answers inline.
> >
> > --Gunnar
> >
> > 2015-05-05 13:04 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> Hello all,
> >> I actually have multiple questions on the subject.
> >>
> >> # Module name
> >>
> >> The Maven artifact id of the modules we're producing for WildFly 8 is
> >> aptly named "org.hibernate.ogm:hibernate-ogm-modules-wildfly8".
> >>
> >> I still think that's a good choice, as deploying modules is an
> >> operation which is strictly coupled to the application server version.
> >> I'm merly reminding this point as it suggests we *could* if - we want
> >> to - easily produce modules for multiple application server versions.
> >
> >
> > Yes, this was exactly the idea behind this naming: being able to provide
> > modules for different baseline versions, WF 8, 9 etc. Whether we
> actually do
> > create more than one at a given time is another question IMO. Also if
> there
> > is only a single ZIP targeting WF, having the major revision in their
> still
> > communicates very clearly the targeted baseline.
> >>
> >>
> >> # EAP versions
> >>
> >> We're also producing modules for JBoss EAP6, but AFAIR these need some
> >> love and I'm not sure if it's worth the effort - it might not need to
> >> much work and I'm happy to look at it if you want to, but in case we
> >> fix it these should have proper integration tests [next]:
> >
> >
> > At this point the EAP6 module ZIP is quite outdated, I don't think it
> will
> > work as is. Maybe it's not a bad idea to update it now that 6.4 is out?
> I am
> > not sure about the effort it'd need, but I expect quite a few modules
> would
> > have to be updated (including ORM).
>
> Likely, as I said. I proposed to volunteer for this but only if we
> agree we want that.
> I guess you're both voting for it?
>
>
> >> # Integration tests of these modules
> >>
> >> The current solution is that the integration tests are run with a
> >> profile selection: so we choose upfront in the build if we want to
> >> test the wildfly8 modules or the eap6 modules.
> >>
> >> Are we still happy with this setup? I don't see a CI job which
> >> verifies the EAP6 modules and I doubt you're all running the tests
> >> twice.
> >> Should we:
> >>  A) add the CI job to verify the other profiles (EAP6 and others as
> >> needed)
> >>  B) change approach and have the tests re-run for any build
> >>  C) remove the EAP6 modules
> >>
> >> My vote goes for B, even though it will make test runs take a bit
> >> longer. To improve speed we can do other things - to be discussed
> >> separately so I'd hope we don't give the execution speed too much
> >> weight for the above choice.
> >
> >
> > There is no CI job (anymore) as the EAP module ZIP is outdated :) Once
> that
> > has been addressed, such job could (and should) easily be
> re-instantiated,
> > so my vote would go for A).
> >
> > Wrt. B), is this to say that you'd run the tests for WF *and* EAP as
> part of
> > local builds, too? If so, I am no fan of it. Build time is an issue, so
> my
> > preference is to test one set up during the default build (i.e. also
> locally
> > when running "mvn clean install") and run all others on CI. We do the
> same
> > e.g. for JDK versions (8, 9) and MongoDB providers (actual MongoDB,
> Fongo).
> > Running all these (and possibly combinations thereof) as part of each
> build
> > just takes too long.
> >
> >> # WildFly 8 vs WildFly 9
> >>
> >> At the last meeting we agreed to support WildFly 9. We didn't decide
> >> at what cost towards WF8 users: should we drop the WF8 modules?
> >
> >
> > It was my understanding that we would not put effort into updating the
> > modules for WF8 but rather focus on WF9. If there was a
> community-provided
> > PR for updating the WF8 ZIP, that'd be great of course and I would be all
> > for integrating it.
>
> The WF8 updates are working fine today, there is no need for a PR.
>
> My question is rather if we should aim at keeping them working, or
> throw out and replace with WF9.
> It's also related to how you do integration tests.
>
> I'll code the module to produce both, we can later decide if you want
> these to trigger by a non-default profile or have options to disable
> them locally.
>
>
> >> I think I'm ok with dropping the older modules, however since we have
> >> chosen for a module name which includes the version, it's pretty easy
> >> for us to keep the WF8 modules around for now, and it's equally easy
> >> to remove them from the project in future when we don't want to do
> >> that anymore.
> >
> >
> > The name is one thing, but it also needs to be maintained. As said on
> JIRA,
> > the WF8 ZIP would at least have to be updated to pull in ORM 4.3.9. OGM
> > depends on a bugfix provided in that version. We used to have a local
> > work-around for this (so we could work with 4.3.7 coming with WF 8), but
> we
> > have just removed this. Now we could un-do that, but I'd prefer to move
> on
> > actually (if not only to benefit from other bug fixes in 4.3.9).
>
> Tests seem to work fine, while it's linked to the default module or
> ORM (v. 4.3.7).
> What am I missing?
> In this scope we're not after the ORM bugfixes.
>
> >>
> >>
> >> Documentation (user complexity) wise the instructions would be
> >> identical so it's not a big burden to explain - one would just need to
> >> pick the right set of modules.
> >>
> >> I would prefer to keep the WF8 modules around for a little bit, but
> >> only if we agree on an integration testing strategy which is able to
> >> cover all the modules we build.
> >
> >
> > See above, the WF8 ZIP would need at least one update. Should we decide
> to
> > keep it, the integration test module would need to get another profile,
> so
> > we can run tests against WF 8 and 9 (on CI).
>
> Ok, but could you please open JIRAs to point out what's wrong with the
> WF8 modules?
>
> >
> >>
> >> # JBoss Logger version
> >>
> >> As a reminder, there's an update for JBoss Logger which - if applied -
> >> will make it harder for OGM to work on WF8. Gunnar is making some
> >> interesting suggestions to work around this on OGM-803 but let's see
> >> first if
> >>  - we really want to keep WF8
> >>  - cant we not simply wait to update, I don't see why we should seel
> >> trouble by upgrading this component now.
> >
> >
> > My reasoning for upgrading was that I prefer to work with a consistent
> set
> > of matching dependencies. But I just noticed that there is an
> inconsistency
> > already: ORM 4.3.9 still is on 3.1.3, whereas WF 9 has 3.2.1. So this
> could
> > wait a bit indeed IMO.
>
> +1 Let's align with ORM, not the containers. Especially as the old
> version works in the newer containers.
>
> Thanks,
> Sanne
>

From steve at hibernate.org  Tue May  5 09:12:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 5 May 2015 08:12:09 -0500
Subject: [hibernate-dev] Removing deprecated methods from Session and
	SessionFactory
In-Reply-To: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
References: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
Message-ID: <CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>

In regards to the first 2 sets, yes I agree.

In regards to your second point, see the discussion on
https://hibernate.atlassian.net/browse/HHH-9761 first.  One idea was to
keep those methods as an "untyped API".  Another option would be to add
another byId (etc) method for untyped operations, something like:

User user = (User) session.byIdUntyped( UserImpl.class )...load( id );

versus

User user = session.byId( User.class )...load( id );


On Tue, May 5, 2015 at 2:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
>
> There are several deprecated methods on Session:
>
> * public Object load(Class theClass, Serializable id, LockMode lockMode)
> * public Object load(String entityName, Serializable id, LockMode
> lockMode);
> * public void lock(Object object, LockMode lockMode);
> * public void lock(String entityName, Object object, LockMode lockMode);
> * public void refresh(Object object, LockMode lockMode);
> * public Object get(Class clazz, Serializable id, LockMode lockMode);
> * public Object get(String entityName, Serializable id, LockMode lockMode);
>
> and SessionFactory:
>
> * public void evict(Class persistentClass) throws HibernateException;
> * public void evict(Class persistentClass, Serializable id) throws
> HibernateException;
> * public void evictEntity(String entityName) throws HibernateException;
> * public void evictEntity(String entityName, Serializable id) throws
> HibernateException;
> * public void evictCollection(String roleName) throws HibernateException;
> * public void evictCollection(String roleName, Serializable id) throws
> HibernateException;
> * public void evictQueries(String cacheRegion) throws HibernateException;
> * public void evictQueries() throws HibernateException;
>
> The docs point to methods to be used alternatively, so the upcoming ORM 5
> major release seems like a good occasion to remove these methods and
> simplifying these contracts a bit. Any thoughts?
>
> On a related note, I am wondering whether
>
>     Session#public Object get(Class clazz, Serializable id, LockOptions
> lockOptions);
>
> etc. pull their weight. The same could be achieved via
>
>     byId( entityClass ).with( lockOptions ).load( id )
>
> Is it actually worth to have these "shortcut" methods?
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue May  5 09:12:07 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 5 May 2015 14:12:07 +0100
Subject: [hibernate-dev] Which versions of the application server should
 the Hibernate OGM modules support
In-Reply-To: <CADGJaX9ftjGkB4kmy=93M_XC21PJP6poY-PTYTOXNpD+ANHEVA@mail.gmail.com>
References: <CAFm4XO3_GOJH_m+if+KmFKZgDvkdOMeszaTc-i6NnkH0qKR2kg@mail.gmail.com>
	<CADGJaX_WdVo5HUD=Nq49aXwy_2q3ee8w0J-7NuxoDhOH-41mjQ@mail.gmail.com>
	<CAFm4XO1wtgJVVAhfcEhAotPHZ1ODjroVM1aoLkLmpvNgjrpC5Q@mail.gmail.com>
	<CADGJaX9ftjGkB4kmy=93M_XC21PJP6poY-PTYTOXNpD+ANHEVA@mail.gmail.com>
Message-ID: <CAFm4XO0BNMM0tD4NR4MUC1k6kz9TL_NY3THNYJOLqnqF70J+HA@mail.gmail.com>

On 5 May 2015 at 13:30, Gunnar Morling <gunnar at hibernate.org> wrote:
> Had a quick chat with Sanne on IRC :)
>
> The reason it seemingly works with WF 8 + ORM 4.3.7 is that the bug I have
> been talking about (HHH-9451) is not triggered by any of the integration
> tests running on WF but only by a unit test in the MongoDB module.
>
> Thus we agreed to not go through the hazzle of updating the WF 8 module ZIP
> and create one for WF 9 instead. We will stick to the JBL version used by
> ORM, so users could still create their own WF 8 module ZIP if needed.
>
> Wrt. to the ZIP, could this be provided alternatively in form of a "feature
> pack" instead? I have been hearing about it  several times, but I don't know
> really whether that's possible already and what it would take to do it.

The "feature pack" is something for the WildFly build to consume; one
can experiment with it already using the WF9 codebase but there won't
be any benefit to end users until WF10.
I suspect it's going to be more relevant for us when we'll baseline on ORM5.

Logged it as OGM-809 as a future improvement.

Sanne

From steve at hibernate.org  Tue May  5 09:17:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 5 May 2015 08:17:55 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
	<CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
	<CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>
Message-ID: <CAFdSV9twBZPcnrJZM9cP29fe039Xapj00W4c-RnugRo+-sDcTw@mail.gmail.com>

Petar, I have just been focusing on other things the past 3 days or so.
Chill :)

I will look at this this week.  If you happen to have a chance to debug it
any further by then, that would rock.  FWIW, I do not think it is in any
way related to the duplicate secondary table warnings.  Those are
completely harmless I believe.  The FK naming logic has changed quite a bit
from pre-5.0 versions, my guess is that the issue lies there.  That or in
the logic to read existing FKs.

On Tue, May 5, 2015 at 3:19 AM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Any of you have seen this issue? Shall I open a ticket?
>
> 2015-05-04 0:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>
> > Hi guys,
> >
> > I finally managed to reproduce it - here's a small application that will
> > generate the provided exception:
> >
> > https://github.com/paranoiabla/hibernate-hsql-issue
> >
> > Please notice that it works fine with Hibernate 4.3.x  I think it has to
> > do something with the CommerceCustomerModel - If I remove it or remove
> the
> > collection of payment infos that is inside of it, it all starts to work
> > fine.
> >
> > Please have a look and thanks a lot for your efforts :)
> >
> >
> >
> >
> > 2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
> >
> >> Hi guys,
> >>
> >> I just tried hibernate 5.0 beta2 and here's my observations. First of
> all
> >> the foreign key problems I had before seems to be resolved, however I
> see
> >> the following error when executing tests with HSQL:
> >>
> >>
> >> Caused by: org.springframework.beans.factory.BeanCreationException:
> Error
> >> creating bean with name 'defaultEntityManagerFactory' defined in class
> path
> >> resource
> [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
> >> Invocation of init method failed; nested exception is
> >> javax.persistence.PersistenceException: [PersistenceUnit: default]
> Unable
> >> to build Hibernate SessionFactory
> >>     at
> >>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
> >>     at
> >>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
> >>     at
> >>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
> >>     at
> >>
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
> >>     at
> >>
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> >>     at
> >>
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
> >>     at
> >>
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
> >>     at
> >>
> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
> >>     at
> >>
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
> >>     at
> >>
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
> >>     at
> >>
> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
> >>     at
> >>
> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
> >>     at
> >>
> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
> >>     at
> >>
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
> >>     at
> >>
> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
> >>     ... 36 more
> >> Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
> >> default] Unable to build Hibernate SessionFactory
> >>     at
> >>
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
> >>     at
> >>
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
> >>     at
> >>
> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
> >>     at
> >>
> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
> >>     at
> >>
> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
> >>     at
> >>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
> >>     at
> >>
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
> >>     ... 50 more
> >> Caused by: org.hibernate.tool.schema.spi.SchemaManagementException:
> >> Unable to execute schema management to JDBC target [alter table
> >> payment_info add constraint FKs9wud9nve6s9cbot5p4548jyh foreign key
> >> (user_pk) references principal]
> >>     at
> >>
> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
> >>     at
> >>
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
> >>     at
> >>
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
> >>     at
> >>
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
> >>     at
> >>
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
> >>     at
> >>
> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
> >>     at
> >> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
> >>     at
> >> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
> >>     at
> >>
> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
> >>     at
> >>
> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
> >>     at
> >>
> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
> >>     ... 55 more
> >> Caused by: java.sql.SQLSyntaxErrorException: object name already exists:
> >> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table payment_info add
> >> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk) references
> >> principal]
> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
> >>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
> >>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
> >>     at
> >>
> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
> >>     at
> >>
> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
> >>     at
> >>
> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
> >>     ... 65 more
> >> Caused by: org.hsqldb.HsqlException: object name already exists:
> >> FKS9WUD9NVE6S9CBOT5P4548JYH
> >>     at org.hsqldb.error.Error.error(Unknown Source)
> >>     at org.hsqldb.error.Error.error(Unknown Source)
> >>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
> >>     at org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown
> Source)
> >>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
> >>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
> >>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
> >>     at org.hsqldb.StatementSchema.execute(Unknown Source)
> >>     at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
> >>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
> >>     at org.hsqldb.Session.execute(Unknown Source)
> >>     ... 70 more
> >>
> >>
> >> When running it with mysql it doesn't show this error (very strange) so
> I
> >> tried to export the schema to sql file and I can see only one foregin
> key
> >> declaration:
> >>
> >>     alter table payment_info
> >>         add constraint FKs9wud9nve6s9cbot5p4548jyh
> >>         foreign key (user_pk)
> >>         references principal (pk);
> >>
> >> Notice that this time it is lowercase. I'm trying to debug the hsql but
> >> it is very hard as it doesn't stop on any of the breakpoints I add. If
> any
> >> of you have an idea what might be causing it, please share your
> thoughts,
> >> if not I'll let you know how I progress.
> >>
> >> I wonder if it could be related to the duplicate joins warnings I see:
> >> WARN : HHH000072: Duplicate joins for class:
> >> com.nemesis.platform.core.model.media.MediaModel
> >> WARN : HHH000072: Duplicate joins for class:
> >>
> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
> >> WARN : HHH000072: Duplicate joins for class:
> >> com.nemesis.platform.core.model.cms.AbstractPageModel
> >> WARN : HHH000072: Duplicate joins for class:
> >> com.nemesis.platform.core.model.cms.EmailPageModel
> >> WARN : HHH000072: Duplicate joins for class:
> >> com.nemesis.platform.core.model.cms.CategoryPageModel
> >> .....
> >>
> >> --
> >> Regards, Petar!
> >> Karlovo, Bulgaria.
> >> ---
> >> Public PGP Key at:
> >>
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >>
> >
> >
> >
> > --
> > Regards, Petar!
> > Karlovo, Bulgaria.
> > ---
> > Public PGP Key at:
> >
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> >
>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue May  5 09:18:22 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 5 May 2015 14:18:22 +0100
Subject: [hibernate-dev] Removing deprecated methods from Session and
	SessionFactory
In-Reply-To: <CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>
References: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
	<CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>
Message-ID: <CAFm4XO0iJdKdLBK9gTOA8FRTracFpRU5O-0Saipn7dcrm7z-xQ@mail.gmail.com>

Please don't remove deprecated methods if there is no real need!



On 5 May 2015 at 14:12, Steve Ebersole <steve at hibernate.org> wrote:
> In regards to the first 2 sets, yes I agree.
>
> In regards to your second point, see the discussion on
> https://hibernate.atlassian.net/browse/HHH-9761 first.  One idea was to
> keep those methods as an "untyped API".  Another option would be to add
> another byId (etc) method for untyped operations, something like:
>
> User user = (User) session.byIdUntyped( UserImpl.class )...load( id );
>
> versus
>
> User user = session.byId( User.class )...load( id );
>
>
> On Tue, May 5, 2015 at 2:04 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>> Hi,
>>
>> There are several deprecated methods on Session:
>>
>> * public Object load(Class theClass, Serializable id, LockMode lockMode)
>> * public Object load(String entityName, Serializable id, LockMode
>> lockMode);
>> * public void lock(Object object, LockMode lockMode);
>> * public void lock(String entityName, Object object, LockMode lockMode);
>> * public void refresh(Object object, LockMode lockMode);
>> * public Object get(Class clazz, Serializable id, LockMode lockMode);
>> * public Object get(String entityName, Serializable id, LockMode lockMode);
>>
>> and SessionFactory:
>>
>> * public void evict(Class persistentClass) throws HibernateException;
>> * public void evict(Class persistentClass, Serializable id) throws
>> HibernateException;
>> * public void evictEntity(String entityName) throws HibernateException;
>> * public void evictEntity(String entityName, Serializable id) throws
>> HibernateException;
>> * public void evictCollection(String roleName) throws HibernateException;
>> * public void evictCollection(String roleName, Serializable id) throws
>> HibernateException;
>> * public void evictQueries(String cacheRegion) throws HibernateException;
>> * public void evictQueries() throws HibernateException;
>>
>> The docs point to methods to be used alternatively, so the upcoming ORM 5
>> major release seems like a good occasion to remove these methods and
>> simplifying these contracts a bit. Any thoughts?
>>
>> On a related note, I am wondering whether
>>
>>     Session#public Object get(Class clazz, Serializable id, LockOptions
>> lockOptions);
>>
>> etc. pull their weight. The same could be achieved via
>>
>>     byId( entityClass ).with( lockOptions ).load( id )
>>
>> Is it actually worth to have these "shortcut" methods?
>>
>> --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  Tue May  5 09:36:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 5 May 2015 08:36:27 -0500
Subject: [hibernate-dev] Removing deprecated methods from Session and
	SessionFactory
In-Reply-To: <CAFm4XO0iJdKdLBK9gTOA8FRTracFpRU5O-0Saipn7dcrm7z-xQ@mail.gmail.com>
References: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
	<CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>
	<CAFm4XO0iJdKdLBK9gTOA8FRTracFpRU5O-0Saipn7dcrm7z-xQ@mail.gmail.com>
Message-ID: <CAFdSV9vssBvAWccP=s1_ULGLZg1wVxEhewsKyQhFgRJBee2Nsg@mail.gmail.com>

Why?  Why even deprecate methods then?

On Tue, May 5, 2015 at 8:18 AM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Please don't remove deprecated methods if there is no real need!
>
>
>
> On 5 May 2015 at 14:12, Steve Ebersole <steve at hibernate.org> wrote:
> > In regards to the first 2 sets, yes I agree.
> >
> > In regards to your second point, see the discussion on
> > https://hibernate.atlassian.net/browse/HHH-9761 first.  One idea was to
> > keep those methods as an "untyped API".  Another option would be to add
> > another byId (etc) method for untyped operations, something like:
> >
> > User user = (User) session.byIdUntyped( UserImpl.class )...load( id );
> >
> > versus
> >
> > User user = session.byId( User.class )...load( id );
> >
> >
> > On Tue, May 5, 2015 at 2:04 AM, Gunnar Morling <gunnar at hibernate.org>
> wrote:
> >
> >> Hi,
> >>
> >> There are several deprecated methods on Session:
> >>
> >> * public Object load(Class theClass, Serializable id, LockMode lockMode)
> >> * public Object load(String entityName, Serializable id, LockMode
> >> lockMode);
> >> * public void lock(Object object, LockMode lockMode);
> >> * public void lock(String entityName, Object object, LockMode lockMode);
> >> * public void refresh(Object object, LockMode lockMode);
> >> * public Object get(Class clazz, Serializable id, LockMode lockMode);
> >> * public Object get(String entityName, Serializable id, LockMode
> lockMode);
> >>
> >> and SessionFactory:
> >>
> >> * public void evict(Class persistentClass) throws HibernateException;
> >> * public void evict(Class persistentClass, Serializable id) throws
> >> HibernateException;
> >> * public void evictEntity(String entityName) throws HibernateException;
> >> * public void evictEntity(String entityName, Serializable id) throws
> >> HibernateException;
> >> * public void evictCollection(String roleName) throws
> HibernateException;
> >> * public void evictCollection(String roleName, Serializable id) throws
> >> HibernateException;
> >> * public void evictQueries(String cacheRegion) throws
> HibernateException;
> >> * public void evictQueries() throws HibernateException;
> >>
> >> The docs point to methods to be used alternatively, so the upcoming ORM
> 5
> >> major release seems like a good occasion to remove these methods and
> >> simplifying these contracts a bit. Any thoughts?
> >>
> >> On a related note, I am wondering whether
> >>
> >>     Session#public Object get(Class clazz, Serializable id, LockOptions
> >> lockOptions);
> >>
> >> etc. pull their weight. The same could be achieved via
> >>
> >>     byId( entityClass ).with( lockOptions ).load( id )
> >>
> >> Is it actually worth to have these "shortcut" methods?
> >>
> >> --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  Tue May  5 12:47:58 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 5 May 2015 11:47:58 -0500
Subject: [hibernate-dev] [wildfly-dev] WildFly 9.0.0.CR1 is released!
In-Reply-To: <5548E7BE.1070301@redhat.com>
References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com>
	<5547492F.30504@redhat.com>
	<15EBE06E-005A-4D27-84FE-050A2BAC4E5C@redhat.com>
	<CAFm4XO2p91qHjnT6784+C9C6v7UZa8AGk8ZBTxqW97gw0V+S_A@mail.gmail.com>
	<5548E7BE.1070301@redhat.com>
Message-ID: <CAFdSV9uY+uNoCUDkNkBh8rZDrwzAzdOFizQcvAsqHiZWs0qhfg@mail.gmail.com>

FWIW, those hooks in Hibernate 5 already exist, based on Jandex 1, of
course :)

We are not currently using Jandex.  That was work happening under the
metamodel redesign, which we had to push to 6.0.

When we do start using Jandex, the plan is to use the provided Jandex as a
base.  But the problem always has been that Hibernate needs to augment that
information from orm.xml.  Also we do have to manage cases outside of
WildFly, so we'd have to build the Index manually.  Also, I want to look at
the building of an index as a build-time step, storing some representation
of that index into the artifact.  We can then locate that representation at
runtime and load it via resource lookup, depending on what that saves/gains
us perf wise (tbd).  Again this along with the passed Jandex index serve as
the base index.  We at least still need to do that augmentation as Jandex
does not handle that at all.

What is "end of deployment"?  Is that the end of phase-2 in our 2-phase JPA
bootstrap design?  If so, that should be fine.

On Tue, May 5, 2015 at 10:54 AM, Scott Marlow <smarlow at redhat.com> wrote:

> Best to talk with Jason but I heard that the Jandex indexes will soon be
> larger (as part of the Java 8 changes).  As a result of the size
> changes, Jandex indexes should only be accessed during the WildFly
> deployment phases.
>
> I'm not sure how Hibernate would use Jandex2 without creating its own
> instances of the indexes, which would be expensive memory wise.
>
> There is also the Hibernate 5.0 release, that we want to integrate with
> WildFly.  I think that is where we might tightly couple Hibernate ORM
> with Jandex, by passing a composite index into Hibernate.  The Jandex
> reference will need to be cleared by the end of deployment.  Would that
> help?
>
> On 05/04/2015 01:53 PM, Sanne Grinovero wrote:
> > Is it possible for our other projects (like Hibernate) to start using
> > Jandex2 sooner rather than later, w/o banning our users from WildFly
> > 9?
> >
> > We're in an innovation paradox ;-)
> >
> > Thanks,
> > Sanne
> >
> >
> > On 4 May 2015 at 15:07, Jason T. Greene <jason.greene at redhat.com> wrote:
> >> Yes that's correct. We need to make some deployer changes to prevent
> holding on to indexes.
> >>
> >> Sent from my iPhone
> >>
> >>> On May 4, 2015, at 6:25 AM, Jozef Hartinger <jharting at redhat.com>
> wrote:
> >>>
> >>> Congrats on the release!
> >>>
> >>> It seems that Jandex upgrade to 2.0 has not been done yet. Is my
> understanding correct that it has been postponed till WF10?
> >>>
> >>>> On 05/01/2015 10:38 PM, Jason Greene wrote:
> >>>> Hello Everyone,
> >>>>
> >>>> I am happy to announce the first candidate release of WildFly 9!
> WildFly 9 builds off of WildFly 8?s Java EE7 support, and adds many new
> capabilities, including intelligent load balancing, HTTP/2 support, a new
> offline CLI mode, graceful single node shutdown, and a new Servlet-only
> distribution.
> >>>>
> >>>> For more details, check out the release notes:
> >>>> https://developer.jboss.org/wiki/WildFly900CR1ReleaseNotes
> >>>>
> >>>> As always, you can download it here:
> >>>> http://wildfly.org/downloads/
> >>>>
> >>>> --
> >>>> Jason T. Greene
> >>>> WildFly Lead / JBoss EAP Platform Architect
> >>>> JBoss, a division of Red Hat
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

From smarlow at redhat.com  Tue May  5 13:55:20 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 05 May 2015 13:55:20 -0400
Subject: [hibernate-dev] [wildfly-dev] WildFly 9.0.0.CR1 is released!
In-Reply-To: <CAFdSV9uY+uNoCUDkNkBh8rZDrwzAzdOFizQcvAsqHiZWs0qhfg@mail.gmail.com>
References: <54E27886-3228-4B37-A3FA-EF8A82B146A8@redhat.com>	<5547492F.30504@redhat.com>	<15EBE06E-005A-4D27-84FE-050A2BAC4E5C@redhat.com>	<CAFm4XO2p91qHjnT6784+C9C6v7UZa8AGk8ZBTxqW97gw0V+S_A@mail.gmail.com>	<5548E7BE.1070301@redhat.com>
	<CAFdSV9uY+uNoCUDkNkBh8rZDrwzAzdOFizQcvAsqHiZWs0qhfg@mail.gmail.com>
Message-ID: <55490408.2090009@redhat.com>


> What is "end of deployment"?  Is that the end of phase-2 in our 2-phase
> JPA bootstrap design?  If so, that should be fine.

Yes, the end of phase-2 in our 2-phase JPA bootstrap design should occur 
before (WildFly) deployment is complete.


From hardy at hibernate.org  Tue May  5 14:38:46 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 5 May 2015 20:38:46 +0200
Subject: [hibernate-dev] Removing deprecated methods from Session and
 SessionFactory
In-Reply-To: <CAFdSV9vssBvAWccP=s1_ULGLZg1wVxEhewsKyQhFgRJBee2Nsg@mail.gmail.com>
References: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
	<CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>
	<CAFm4XO0iJdKdLBK9gTOA8FRTracFpRU5O-0Saipn7dcrm7z-xQ@mail.gmail.com>
	<CAFdSV9vssBvAWccP=s1_ULGLZg1wVxEhewsKyQhFgRJBee2Nsg@mail.gmail.com>
Message-ID: <20150505183846.GB5753@Nineveh.lan>

On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
> Why?  Why even deprecate methods then?

+1

--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/20150505/e9c1ca64/attachment.bin 

From gunnar at hibernate.org  Wed May  6 05:01:29 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 6 May 2015 11:01:29 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
Message-ID: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>

Hi,

When talking to people about OGM, there is always that awkward moment when
you need to explain that TX demarcation is required also for
non-transactional data stores.

While it makes sense for our purposes (we use the "TX cycle" to optimise
the work sent to the backend etc.), I can understand people who find that
odd API-wise. So I was thinking about how this could be improved.

When it comes to CDI, a more "neutral" annotation (and a portable extension
examining it) than @Transactional could be helpful:

    @UnitOfWork
    public void saveOrderAndCustomer(Order order, Customer customer) {
        session.persist( order );
        session.persist( customer );
    }

By means of the @UnitOfWork annotation it would be expressed that the
entire method should run as one "transaction". This also could be used to
specify an error handler for our new API to be applied for this unit of
work:

    @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
    public void saveOrderAndCustomer(Order order, Customer customer) { ... }

In non-managed environments, Java-8-style Lambda expressions could be
leveraged nicely to achieve the same:

    session.runUnitOfWork( () -> {
        session.persist( order );
        session.persist( customer );
    };

This should feel much nicer to e.g. users of the MongoDB backend than
invoking session.getTransaction().begin()/commit(). It also plays greatly
together with the error handling stuff:

    session.buildUnitOfWork( () -> {
        session.persist( order );
        session.persist( customer );
    } )
    .onFailedGridDialectOperation( context -> {
        // e.g. log failed op
        return ErrorHandlingStrategy.ABORT;
    } )
    .onRollback( context -> {
        // e.g. log applied ops
    } )
    .run();

Of course something equivalent could be done for Java 7, but it'd probably
look not as concise.

Any thoughts?

Cheers,

--Gunnar

From sanne at hibernate.org  Wed May  6 05:13:38 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 6 May 2015 10:13:38 +0100
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
Message-ID: <CAFm4XO0Jgpxci51L2vRKRpX2T6xmGS9Aescr3p5Wma6MfNkX9g@mail.gmail.com>

Did you consider that the existing definition of "Transaction
boundaries" can have different levels of isolation and guarantees,
depending on how the underlying components are configured?

I do agree with you that it's kind of weird that people write code
without making transactional requirements explicit in the code, but it
seems that the trend is to abstract from that and use the
"Transaction" term as a "Unit of work".

For example I find it strange that - in Java - one has to configure
the isolation levels of transactions to the safest (least efficient)
option possible among the types his *various* use cases require. It's
pretty obvious that it would be more efficient to choose those levels
as "profiles" based on use case, possibly bean or even method level.
I guess that's were complex applications split up in multiple deployments..

What is concerning is that the average developer will write Java code
making assumptions on the underlying transaction guarantees, and will
rarely communicate those as requirements to whoever configures it.
Is that what you aim to solve?




On 6 May 2015 at 10:01, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> When talking to people about OGM, there is always that awkward moment when
> you need to explain that TX demarcation is required also for
> non-transactional data stores.
>
> While it makes sense for our purposes (we use the "TX cycle" to optimise
> the work sent to the backend etc.), I can understand people who find that
> odd API-wise. So I was thinking about how this could be improved.
>
> When it comes to CDI, a more "neutral" annotation (and a portable extension
> examining it) than @Transactional could be helpful:
>
>     @UnitOfWork
>     public void saveOrderAndCustomer(Order order, Customer customer) {
>         session.persist( order );
>         session.persist( customer );
>     }
>
> By means of the @UnitOfWork annotation it would be expressed that the
> entire method should run as one "transaction". This also could be used to
> specify an error handler for our new API to be applied for this unit of
> work:
>
>     @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
>     public void saveOrderAndCustomer(Order order, Customer customer) { ... }
>
> In non-managed environments, Java-8-style Lambda expressions could be
> leveraged nicely to achieve the same:
>
>     session.runUnitOfWork( () -> {
>         session.persist( order );
>         session.persist( customer );
>     };
>
> This should feel much nicer to e.g. users of the MongoDB backend than
> invoking session.getTransaction().begin()/commit(). It also plays greatly
> together with the error handling stuff:
>
>     session.buildUnitOfWork( () -> {
>         session.persist( order );
>         session.persist( customer );
>     } )
>     .onFailedGridDialectOperation( context -> {
>         // e.g. log failed op
>         return ErrorHandlingStrategy.ABORT;
>     } )
>     .onRollback( context -> {
>         // e.g. log applied ops
>     } )
>     .run();
>
> Of course something equivalent could be done for Java 7, but it'd probably
> look not as concise.
>
> Any thoughts?
>
> Cheers,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Wed May  6 05:31:06 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 6 May 2015 11:31:06 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CAFm4XO0Jgpxci51L2vRKRpX2T6xmGS9Aescr3p5Wma6MfNkX9g@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<CAFm4XO0Jgpxci51L2vRKRpX2T6xmGS9Aescr3p5Wma6MfNkX9g@mail.gmail.com>
Message-ID: <CADGJaX_OjiDvjoZG5v3iQg0ukk5_AM5w_UNviA1SfHm8u_cpAg@mail.gmail.com>

2015-05-06 11:13 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Did you consider that the existing definition of "Transaction
> boundaries" can have different levels of isolation and guarantees,
> depending on how the underlying components are configured?
>

I didn't, but that's exactly the point. Talking (API-wise) about
"transactions", "isolation levels" does not really make sense if the
underlying backend is non-transactional by its nature.

We just piggy-back on the transaction cycle from ORM to control flushes,
but this doesn't give you any sort of transactional guarantees if not
natively supported. If you e.g. do an explicit flush() in the middle of a
"transaction", these changes will be visible to other clients, no matter
what kind of isolation level has been configured somewhere.

I do agree with you that it's kind of weird that people write code
> without making transactional requirements explicit in the code, but it
> seems that the trend is to abstract from that and use the
> "Transaction" term as a "Unit of work".
>

Where do you see this trend? Surely not e.g. in MongoDB or CouchDB? It's
exactly the usage of the term "transaction" which I find irritating for
these stores and which I thus seek to avoid.

For example I find it strange that - in Java - one has to configure
> the isolation levels of transactions to the safest (least efficient)
> option possible among the types his *various* use cases require. It's
> pretty obvious that it would be more efficient to choose those levels
> as "profiles" based on use case, possibly bean or even method level.
> I guess that's were complex applications split up in multiple deployments..
>
> What is concerning is that the average developer will write Java code
> making assumptions on the underlying transaction guarantees, and will
> rarely communicate those as requirements to whoever configures it.
> Is that what you aim to solve?
>
> Not really. What I aim to solve is to avoid making the user work with APIs
which suggest certain kinds of guarantees which in reality are not there
for certain backends.

>
>
>
> On 6 May 2015 at 10:01, Gunnar Morling <gunnar at hibernate.org> wrote:
> > Hi,
> >
> > When talking to people about OGM, there is always that awkward moment
> when
> > you need to explain that TX demarcation is required also for
> > non-transactional data stores.
> >
> > While it makes sense for our purposes (we use the "TX cycle" to optimise
> > the work sent to the backend etc.), I can understand people who find that
> > odd API-wise. So I was thinking about how this could be improved.
> >
> > When it comes to CDI, a more "neutral" annotation (and a portable
> extension
> > examining it) than @Transactional could be helpful:
> >
> >     @UnitOfWork
> >     public void saveOrderAndCustomer(Order order, Customer customer) {
> >         session.persist( order );
> >         session.persist( customer );
> >     }
> >
> > By means of the @UnitOfWork annotation it would be expressed that the
> > entire method should run as one "transaction". This also could be used to
> > specify an error handler for our new API to be applied for this unit of
> > work:
> >
> >     @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
> >     public void saveOrderAndCustomer(Order order, Customer customer) {
> ... }
> >
> > In non-managed environments, Java-8-style Lambda expressions could be
> > leveraged nicely to achieve the same:
> >
> >     session.runUnitOfWork( () -> {
> >         session.persist( order );
> >         session.persist( customer );
> >     };
> >
> > This should feel much nicer to e.g. users of the MongoDB backend than
> > invoking session.getTransaction().begin()/commit(). It also plays greatly
> > together with the error handling stuff:
> >
> >     session.buildUnitOfWork( () -> {
> >         session.persist( order );
> >         session.persist( customer );
> >     } )
> >     .onFailedGridDialectOperation( context -> {
> >         // e.g. log failed op
> >         return ErrorHandlingStrategy.ABORT;
> >     } )
> >     .onRollback( context -> {
> >         // e.g. log applied ops
> >     } )
> >     .run();
> >
> > Of course something equivalent could be done for Java 7, but it'd
> probably
> > look not as concise.
> >
> > Any thoughts?
> >
> > Cheers,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Wed May  6 05:43:19 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 6 May 2015 10:43:19 +0100
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CADGJaX_OjiDvjoZG5v3iQg0ukk5_AM5w_UNviA1SfHm8u_cpAg@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<CAFm4XO0Jgpxci51L2vRKRpX2T6xmGS9Aescr3p5Wma6MfNkX9g@mail.gmail.com>
	<CADGJaX_OjiDvjoZG5v3iQg0ukk5_AM5w_UNviA1SfHm8u_cpAg@mail.gmail.com>
Message-ID: <CAFm4XO2xt46-34zzKEPnsCChrNGcTCa+XdTB5ij-S_NpYjMXPQ@mail.gmail.com>

Making the user work with a Transaction API even though the storage
doesn't implement it "at all" isn't a novelty of OGM. Remember MySQL's
MyISAM ?
It's supported by Hibernate, and while InnoDB might be on the rise
compared to MyISAM, it's not dead.

The range of transactional capabilities of different engines varies a
lot in many subtle details which are hard to classify under a single
standard API; In my view not supporting any transactional capability
is just a very low form of transaction capabilities :)

I would totally agree with you that this is a concrete and interesting
problem to solve, but I don't think it's something for OGM to do.

Sanne


On 6 May 2015 at 10:31, Gunnar Morling <gunnar at hibernate.org> wrote:
> 2015-05-06 11:13 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Did you consider that the existing definition of "Transaction
>> boundaries" can have different levels of isolation and guarantees,
>> depending on how the underlying components are configured?
>
>
> I didn't, but that's exactly the point. Talking (API-wise) about
> "transactions", "isolation levels" does not really make sense if the
> underlying backend is non-transactional by its nature.
>
> We just piggy-back on the transaction cycle from ORM to control flushes, but
> this doesn't give you any sort of transactional guarantees if not natively
> supported. If you e.g. do an explicit flush() in the middle of a
> "transaction", these changes will be visible to other clients, no matter
> what kind of isolation level has been configured somewhere.
>
>> I do agree with you that it's kind of weird that people write code
>> without making transactional requirements explicit in the code, but it
>> seems that the trend is to abstract from that and use the
>> "Transaction" term as a "Unit of work".
>
>
> Where do you see this trend? Surely not e.g. in MongoDB or CouchDB? It's
> exactly the usage of the term "transaction" which I find irritating for
> these stores and which I thus seek to avoid.
>
>> For example I find it strange that - in Java - one has to configure
>> the isolation levels of transactions to the safest (least efficient)
>> option possible among the types his *various* use cases require. It's
>> pretty obvious that it would be more efficient to choose those levels
>> as "profiles" based on use case, possibly bean or even method level.
>> I guess that's were complex applications split up in multiple
>> deployments..
>>
>> What is concerning is that the average developer will write Java code
>> making assumptions on the underlying transaction guarantees, and will
>> rarely communicate those as requirements to whoever configures it.
>> Is that what you aim to solve?
>>
> Not really. What I aim to solve is to avoid making the user work with APIs
> which suggest certain kinds of guarantees which in reality are not there for
> certain backends.
>>
>>
>>
>>
>> On 6 May 2015 at 10:01, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > Hi,
>> >
>> > When talking to people about OGM, there is always that awkward moment
>> > when
>> > you need to explain that TX demarcation is required also for
>> > non-transactional data stores.
>> >
>> > While it makes sense for our purposes (we use the "TX cycle" to optimise
>> > the work sent to the backend etc.), I can understand people who find
>> > that
>> > odd API-wise. So I was thinking about how this could be improved.
>> >
>> > When it comes to CDI, a more "neutral" annotation (and a portable
>> > extension
>> > examining it) than @Transactional could be helpful:
>> >
>> >     @UnitOfWork
>> >     public void saveOrderAndCustomer(Order order, Customer customer) {
>> >         session.persist( order );
>> >         session.persist( customer );
>> >     }
>> >
>> > By means of the @UnitOfWork annotation it would be expressed that the
>> > entire method should run as one "transaction". This also could be used
>> > to
>> > specify an error handler for our new API to be applied for this unit of
>> > work:
>> >
>> >     @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
>> >     public void saveOrderAndCustomer(Order order, Customer customer) {
>> > ... }
>> >
>> > In non-managed environments, Java-8-style Lambda expressions could be
>> > leveraged nicely to achieve the same:
>> >
>> >     session.runUnitOfWork( () -> {
>> >         session.persist( order );
>> >         session.persist( customer );
>> >     };
>> >
>> > This should feel much nicer to e.g. users of the MongoDB backend than
>> > invoking session.getTransaction().begin()/commit(). It also plays
>> > greatly
>> > together with the error handling stuff:
>> >
>> >     session.buildUnitOfWork( () -> {
>> >         session.persist( order );
>> >         session.persist( customer );
>> >     } )
>> >     .onFailedGridDialectOperation( context -> {
>> >         // e.g. log failed op
>> >         return ErrorHandlingStrategy.ABORT;
>> >     } )
>> >     .onRollback( context -> {
>> >         // e.g. log applied ops
>> >     } )
>> >     .run();
>> >
>> > Of course something equivalent could be done for Java 7, but it'd
>> > probably
>> > look not as concise.
>> >
>> > Any thoughts?
>> >
>> > Cheers,
>> >
>> > --Gunnar
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From gunnar at hibernate.org  Wed May  6 05:51:08 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 6 May 2015 11:51:08 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CAFm4XO2xt46-34zzKEPnsCChrNGcTCa+XdTB5ij-S_NpYjMXPQ@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<CAFm4XO0Jgpxci51L2vRKRpX2T6xmGS9Aescr3p5Wma6MfNkX9g@mail.gmail.com>
	<CADGJaX_OjiDvjoZG5v3iQg0ukk5_AM5w_UNviA1SfHm8u_cpAg@mail.gmail.com>
	<CAFm4XO2xt46-34zzKEPnsCChrNGcTCa+XdTB5ij-S_NpYjMXPQ@mail.gmail.com>
Message-ID: <CADGJaX_WxNjPaPhz6=jAq5w=UNWyU7voJxKC7UR8menMK5DByw@mail.gmail.com>

2015-05-06 11:43 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Making the user work with a Transaction API even though the storage
> doesn't implement it "at all" isn't a novelty of OGM. Remember MySQL's
> MyISAM ?
> It's supported by Hibernate, and while InnoDB might be on the rise
> compared to MyISAM, it's not dead.
>

Novelty or not, it just seems not the best approach to me. It's one of the
things leading to those "if all you've got is a hammer, all problems look
like a nail" comments.


> The range of transactional capabilities of different engines varies a
> lot in many subtle details which are hard to classify under a single
> standard API; In my view not supporting any transactional capability
> is just a very low form of transaction capabilities :)
>
> I would totally agree with you that this is a concrete and interesting
> problem to solve, but I don't think it's something for OGM to do.
>

Who else should it do?

It's our task to provide sensible APIs for persisting data in different
backends. Requiring users to span "transactions" where there are none isn't
necessarily sensible in my book :)


Sanne
>
>
> On 6 May 2015 at 10:31, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2015-05-06 11:13 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >> Did you consider that the existing definition of "Transaction
> >> boundaries" can have different levels of isolation and guarantees,
> >> depending on how the underlying components are configured?
> >
> >
> > I didn't, but that's exactly the point. Talking (API-wise) about
> > "transactions", "isolation levels" does not really make sense if the
> > underlying backend is non-transactional by its nature.
> >
> > We just piggy-back on the transaction cycle from ORM to control flushes,
> but
> > this doesn't give you any sort of transactional guarantees if not
> natively
> > supported. If you e.g. do an explicit flush() in the middle of a
> > "transaction", these changes will be visible to other clients, no matter
> > what kind of isolation level has been configured somewhere.
> >
> >> I do agree with you that it's kind of weird that people write code
> >> without making transactional requirements explicit in the code, but it
> >> seems that the trend is to abstract from that and use the
> >> "Transaction" term as a "Unit of work".
> >
> >
> > Where do you see this trend? Surely not e.g. in MongoDB or CouchDB? It's
> > exactly the usage of the term "transaction" which I find irritating for
> > these stores and which I thus seek to avoid.
> >
> >> For example I find it strange that - in Java - one has to configure
> >> the isolation levels of transactions to the safest (least efficient)
> >> option possible among the types his *various* use cases require. It's
> >> pretty obvious that it would be more efficient to choose those levels
> >> as "profiles" based on use case, possibly bean or even method level.
> >> I guess that's were complex applications split up in multiple
> >> deployments..
> >>
> >> What is concerning is that the average developer will write Java code
> >> making assumptions on the underlying transaction guarantees, and will
> >> rarely communicate those as requirements to whoever configures it.
> >> Is that what you aim to solve?
> >>
> > Not really. What I aim to solve is to avoid making the user work with
> APIs
> > which suggest certain kinds of guarantees which in reality are not there
> for
> > certain backends.
> >>
> >>
> >>
> >>
> >> On 6 May 2015 at 10:01, Gunnar Morling <gunnar at hibernate.org> wrote:
> >> > Hi,
> >> >
> >> > When talking to people about OGM, there is always that awkward moment
> >> > when
> >> > you need to explain that TX demarcation is required also for
> >> > non-transactional data stores.
> >> >
> >> > While it makes sense for our purposes (we use the "TX cycle" to
> optimise
> >> > the work sent to the backend etc.), I can understand people who find
> >> > that
> >> > odd API-wise. So I was thinking about how this could be improved.
> >> >
> >> > When it comes to CDI, a more "neutral" annotation (and a portable
> >> > extension
> >> > examining it) than @Transactional could be helpful:
> >> >
> >> >     @UnitOfWork
> >> >     public void saveOrderAndCustomer(Order order, Customer customer) {
> >> >         session.persist( order );
> >> >         session.persist( customer );
> >> >     }
> >> >
> >> > By means of the @UnitOfWork annotation it would be expressed that the
> >> > entire method should run as one "transaction". This also could be used
> >> > to
> >> > specify an error handler for our new API to be applied for this unit
> of
> >> > work:
> >> >
> >> >     @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
> >> >     public void saveOrderAndCustomer(Order order, Customer customer) {
> >> > ... }
> >> >
> >> > In non-managed environments, Java-8-style Lambda expressions could be
> >> > leveraged nicely to achieve the same:
> >> >
> >> >     session.runUnitOfWork( () -> {
> >> >         session.persist( order );
> >> >         session.persist( customer );
> >> >     };
> >> >
> >> > This should feel much nicer to e.g. users of the MongoDB backend than
> >> > invoking session.getTransaction().begin()/commit(). It also plays
> >> > greatly
> >> > together with the error handling stuff:
> >> >
> >> >     session.buildUnitOfWork( () -> {
> >> >         session.persist( order );
> >> >         session.persist( customer );
> >> >     } )
> >> >     .onFailedGridDialectOperation( context -> {
> >> >         // e.g. log failed op
> >> >         return ErrorHandlingStrategy.ABORT;
> >> >     } )
> >> >     .onRollback( context -> {
> >> >         // e.g. log applied ops
> >> >     } )
> >> >     .run();
> >> >
> >> > Of course something equivalent could be done for Java 7, but it'd
> >> > probably
> >> > look not as concise.
> >> >
> >> > Any thoughts?
> >> >
> >> > Cheers,
> >> >
> >> > --Gunnar
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From emmanuel at hibernate.org  Wed May  6 08:19:30 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 6 May 2015 14:19:30 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
Message-ID: <27D88AF6-1F91-4483-9FE1-9B58820DFDB2@hibernate.org>

It?s an interesting idea.
Let me give you the reasons why I think the transaction API has merits.

There is already a notion of UnitOfWork that was named Conversation in Seam / CDI. But its span is potentially longer than the span of the updates window. The closer notion of a UnitOfWork is an EntityManager or a Session.

By introducing @UnitOfWork, you forgo all the integration between application frameworks and transactions. Here you offer a solution for CDI but we would need one for Java EE non CDI and one for Spring and one for Grails and one for? I understand you reluctance to call a Tiger a Cat but they are commonly referred as Cats.
Back to our problem, you either
- teach people that transaction is not what they might understand of transactions - if they even know what that means these days ;)
- teach them a new concept that suspiciously looks like a transaction anyways and force them to do the integration of that ?thing? with their universe.

I like the exploration of lamda usage for the Hibernate APIs but we probably should think about it in the larger scheme of ORM and in this async API trend. What could we do.
Note also that your example reflects a simple example where you *whole* unit of work is very simple and does not span services / DAOs. If it spans services / DAOs, then the lambda approach sort of fails a little by as you need to reach the session from within these nested service calls.

I am relatively open on these proposals but we need to flesh them out much better before we can consider them seriously (say for the next sprint).


> On 06 May 2015, at 11:01, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> Hi,
> 
> When talking to people about OGM, there is always that awkward moment when
> you need to explain that TX demarcation is required also for
> non-transactional data stores.
> 
> While it makes sense for our purposes (we use the "TX cycle" to optimise
> the work sent to the backend etc.), I can understand people who find that
> odd API-wise. So I was thinking about how this could be improved.
> 
> When it comes to CDI, a more "neutral" annotation (and a portable extension
> examining it) than @Transactional could be helpful:
> 
>    @UnitOfWork
>    public void saveOrderAndCustomer(Order order, Customer customer) {
>        session.persist( order );
>        session.persist( customer );
>    }
> 
> By means of the @UnitOfWork annotation it would be expressed that the
> entire method should run as one "transaction". This also could be used to
> specify an error handler for our new API to be applied for this unit of
> work:
> 
>    @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
>    public void saveOrderAndCustomer(Order order, Customer customer) { ... }
> 
> In non-managed environments, Java-8-style Lambda expressions could be
> leveraged nicely to achieve the same:
> 
>    session.runUnitOfWork( () -> {
>        session.persist( order );
>        session.persist( customer );
>    };
> 
> This should feel much nicer to e.g. users of the MongoDB backend than
> invoking session.getTransaction().begin()/commit(). It also plays greatly
> together with the error handling stuff:
> 
>    session.buildUnitOfWork( () -> {
>        session.persist( order );
>        session.persist( customer );
>    } )
>    .onFailedGridDialectOperation( context -> {
>        // e.g. log failed op
>        return ErrorHandlingStrategy.ABORT;
>    } )
>    .onRollback( context -> {
>        // e.g. log applied ops
>    } )
>    .run();
> 
> Of course something equivalent could be done for Java 7, but it'd probably
> look not as concise.
> 
> Any thoughts?
> 
> Cheers,
> 
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From gunnar at hibernate.org  Wed May  6 09:16:16 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 6 May 2015 15:16:16 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <27D88AF6-1F91-4483-9FE1-9B58820DFDB2@hibernate.org>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<27D88AF6-1F91-4483-9FE1-9B58820DFDB2@hibernate.org>
Message-ID: <CADGJaX--x3Mh4Lkntw=mu0=RV0kvxHzgJD+vF0efAe1TZF4=ug@mail.gmail.com>

2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> It?s an interesting idea.
> Let me give you the reasons why I think the transaction API has merits.
>
> There is already a notion of UnitOfWork that was named Conversation in
> Seam / CDI. But its span is potentially longer than the span of the updates
> window. The closer notion of a UnitOfWork is an EntityManager or a Session.

By introducing @UnitOfWork, you forgo all the integration between
> application frameworks and transactions. Here you offer a solution for CDI
> but we would need one for Java EE non CDI and one for Spring and one for
> Grails and one for?


The current integrations would continue to work. So e.g. EJB non-CDI would
still use JTA as is today. I don't find it to be a big problem there, as
it's much more under the covers (which is why it's nice to show EJBs in
demos ;). Same for the others basically.

I understand you reluctance to call a Tiger a Cat but they are commonly
> referred as Cats.
> Back to our problem, you either
> - teach people that transaction is not what they might understand of
> transactions - if they even know what that means these days ;)
> - teach them a new concept that suspiciously looks like a transaction
> anyways and force them to do the integration of that ?thing? with their
> universe.
>

I'd prefer the latter. The good thing is that it is up to us to
describe/document what the "thing" is, so we can manage expectations
towards it, far better then when using the term "transaction" which
automatically raises certain expectations (smart people will wonder how we
make it work, others may even fall into the trap and believe it is actually
TX).

>
> I like the exploration of lamda usage for the Hibernate APIs but we
> probably should think about it in the larger scheme of ORM and in this
> async API trend. What could we do.
> Note also that your example reflects a simple example where you *whole*
> unit of work is very simple and does not span services / DAOs. If it spans
> services / DAOs, then the lambda approach sort of fails a little by as you
> need to reach the session from within these nested service calls.
>

Yes, that is a good point. Probably we'd also need something like
beginUnitOfWork(). Maybe something like this is the better approach:

    session.buildUnitOfWork()
        .onFailedGridDialectOperation( context -> {
            // e.g. log failed op
            return ErrorHandlingStrategy.ABORT;
        } )
        .onRollback( context -> {
            // e.g. log applied ops
        } )
        .begin();

    session.persist( order );
    session.persist( customer );

    session.finishUnitOfWork();



> I am relatively open on these proposals but we need to flesh them out much
> better before we can consider them seriously (say for the next sprint).
>

Sure, it's not fully worked out, I just wanted to quickly gauge general
interest in this. I will file an issue.

>
>
> > On 06 May 2015, at 11:01, Gunnar Morling <gunnar at hibernate.org> wrote:
> >
> > Hi,
> >
> > When talking to people about OGM, there is always that awkward moment
> when
> > you need to explain that TX demarcation is required also for
> > non-transactional data stores.
> >
> > While it makes sense for our purposes (we use the "TX cycle" to optimise
> > the work sent to the backend etc.), I can understand people who find that
> > odd API-wise. So I was thinking about how this could be improved.
> >
> > When it comes to CDI, a more "neutral" annotation (and a portable
> extension
> > examining it) than @Transactional could be helpful:
> >
> >    @UnitOfWork
> >    public void saveOrderAndCustomer(Order order, Customer customer) {
> >        session.persist( order );
> >        session.persist( customer );
> >    }
> >
> > By means of the @UnitOfWork annotation it would be expressed that the
> > entire method should run as one "transaction". This also could be used to
> > specify an error handler for our new API to be applied for this unit of
> > work:
> >
> >    @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
> >    public void saveOrderAndCustomer(Order order, Customer customer) {
> ... }
> >
> > In non-managed environments, Java-8-style Lambda expressions could be
> > leveraged nicely to achieve the same:
> >
> >    session.runUnitOfWork( () -> {
> >        session.persist( order );
> >        session.persist( customer );
> >    };
> >
> > This should feel much nicer to e.g. users of the MongoDB backend than
> > invoking session.getTransaction().begin()/commit(). It also plays greatly
> > together with the error handling stuff:
> >
> >    session.buildUnitOfWork( () -> {
> >        session.persist( order );
> >        session.persist( customer );
> >    } )
> >    .onFailedGridDialectOperation( context -> {
> >        // e.g. log failed op
> >        return ErrorHandlingStrategy.ABORT;
> >    } )
> >    .onRollback( context -> {
> >        // e.g. log applied ops
> >    } )
> >    .run();
> >
> > Of course something equivalent could be done for Java 7, but it'd
> probably
> > look not as concise.
> >
> > Any thoughts?
> >
> > Cheers,
> >
> > --Gunnar
> > _______________________________________________
> > 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 May  6 10:00:52 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 6 May 2015 16:00:52 +0200
Subject: [hibernate-dev] HHH-7610 - Embedded and nulls
Message-ID: <CALt0+o-HcLZgkVHE-oD1MEde+97J84m3xr6Go3is-JCOyKTMGQ@mail.gmail.com>

Hi all,

(sorry for the long silence, have been dealing with personal issues)

I have cycles next week and I would like to tackle this issue:
https://hibernate.atlassian.net/browse/HHH-7610

My colleague, Laurent Almeras, already worked on a patch here:
https://github.com/openwide-java/hibernate-orm/commits/embedded-empty-configuration
.

Steve gave us a few advices and we took them into account in the following
commits.

Should I rebase the patch and propose a PR? If so, for which branches?

As a lot of people asked for it, I would prefer it being integrated instead
of keeping a set of patches here at Open Wide.

Thanks for your feedback!

-- 
Guillaume

From steve at hibernate.org  Wed May  6 12:10:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 6 May 2015 11:10:53 -0500
Subject: [hibernate-dev] HHH-7610 - Embedded and nulls
In-Reply-To: <CALt0+o-HcLZgkVHE-oD1MEde+97J84m3xr6Go3is-JCOyKTMGQ@mail.gmail.com>
References: <CALt0+o-HcLZgkVHE-oD1MEde+97J84m3xr6Go3is-JCOyKTMGQ@mail.gmail.com>
Message-ID: <CAFdSV9tQQKemH3kqaZrNhSzOESJ4ou8mywFaQDAOnmC5E4rQkA@mail.gmail.com>

Sure, I can take a look at a Pull Request.  Just ping us on the list when
it is ready (sometimes the PR notifications "get lost" in the shuffle).

On Wed, May 6, 2015 at 9:00 AM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi all,
>
> (sorry for the long silence, have been dealing with personal issues)
>
> I have cycles next week and I would like to tackle this issue:
> https://hibernate.atlassian.net/browse/HHH-7610
>
> My colleague, Laurent Almeras, already worked on a patch here:
>
> https://github.com/openwide-java/hibernate-orm/commits/embedded-empty-configuration
> .
>
> Steve gave us a few advices and we took them into account in the following
> commits.
>
> Should I rebase the patch and propose a PR? If so, for which branches?
>
> As a lot of people asked for it, I would prefer it being integrated instead
> of keeping a set of patches here at Open Wide.
>
> Thanks for your feedback!
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Wed May  6 15:58:03 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 6 May 2015 21:58:03 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
Message-ID: <20150506195803.GA11293@Nineveh.lan>

Hi,

On Wed, May 06, 2015 at 11:01:29AM +0200, Gunnar Morling wrote:
> When talking to people about OGM, there is always that awkward moment when
> you need to explain that TX demarcation is required also for
> non-transactional data stores.
> 
> While it makes sense for our purposes (we use the "TX cycle" to optimise
> the work sent to the backend etc.), I can understand people who find that
> odd API-wise. So I was thinking about how this could be improved.

Personally I count myself to the category of people who raise an eyebrow about
using transactions for non transactional data stores. 

> When it comes to CDI, a more "neutral" annotation (and a portable extension
> examining it) than @Transactional could be helpful:
> 
>     @UnitOfWork
>     public void saveOrderAndCustomer(Order order, Customer customer) {
>         session.persist( order );
>         session.persist( customer );
>     }
> 
> By means of the @UnitOfWork annotation it would be expressed that the
> entire method should run as one "transaction". This also could be used to
> specify an error handler for our new API to be applied for this unit of
> work:
> 
>     @UnitOfWork(errorHandler=FailedOpsLoggingHandler.class)
>     public void saveOrderAndCustomer(Order order, Customer customer) { ... }

Interesting.

> In non-managed environments, Java-8-style Lambda expressions could be
> leveraged nicely to achieve the same:
> 
>     session.runUnitOfWork( () -> {
>         session.persist( order );
>         session.persist( customer );
>     };
> 
> This should feel much nicer to e.g. users of the MongoDB backend than
> invoking session.getTransaction().begin()/commit(). It also plays greatly
> together with the error handling stuff:
> 
>     session.buildUnitOfWork( () -> {
>         session.persist( order );
>         session.persist( customer );
>     } )
>     .onFailedGridDialectOperation( context -> {
>         // e.g. log failed op
>         return ErrorHandlingStrategy.ABORT;
>     } )
>     .onRollback( context -> {
>         // e.g. log applied ops
>     } )
>     .run();
> 
> Of course something equivalent could be done for Java 7, but it'd probably
> look not as concise.

I like how the lambdas play out there. Personally I think it would be more important
to start with a Java 7 based approach. Only offering this type of functionality for Java 8
might limit the potential user base and it also adds some complexity to OGM as well,
since you probably still want to offer Java 7 compatible artifacts. That said, I think the
lambda approach has definitely a future.

--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/20150506/86cf0890/attachment.bin 

From hardy at hibernate.org  Wed May  6 16:00:15 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 6 May 2015 22:00:15 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CAFm4XO0Jgpxci51L2vRKRpX2T6xmGS9Aescr3p5Wma6MfNkX9g@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<CAFm4XO0Jgpxci51L2vRKRpX2T6xmGS9Aescr3p5Wma6MfNkX9g@mail.gmail.com>
Message-ID: <20150506200015.GB11293@Nineveh.lan>

Hi,

On Wed, May 06, 2015 at 10:13:38AM +0100, Sanne Grinovero wrote:
> I do agree with you that it's kind of weird that people write code
> without making transactional requirements explicit in the code, but it
> seems that the trend is to abstract from that and use the
> "Transaction" term as a "Unit of work".

What are you referring to? Where do you see this trend.

> For example I find it strange that - in Java - one has to configure
> the isolation levels of transactions to the safest (least efficient)
> option possible among the types his *various* use cases require. It's
> pretty obvious that it would be more efficient to choose those levels
> as "profiles" based on use case, possibly bean or even method level.
> I guess that's were complex applications split up in multiple deployments..

I am not sure I am quite following you on 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/20150506/6a5e0358/attachment.bin 

From hardy at hibernate.org  Wed May  6 16:10:57 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Wed, 6 May 2015 22:10:57 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CADGJaX--x3Mh4Lkntw=mu0=RV0kvxHzgJD+vF0efAe1TZF4=ug@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<27D88AF6-1F91-4483-9FE1-9B58820DFDB2@hibernate.org>
	<CADGJaX--x3Mh4Lkntw=mu0=RV0kvxHzgJD+vF0efAe1TZF4=ug@mail.gmail.com>
Message-ID: <20150506201057.GC11293@Nineveh.lan>

Hi,

On Wed, May 06, 2015 at 03:16:16PM +0200, Gunnar Morling wrote:
> By introducing @UnitOfWork, you forgo all the integration between
> > application frameworks and transactions. Here you offer a solution for CDI
> > but we would need one for Java EE non CDI and one for Spring and one for
> > Grails and one for?
> 
> 
> The current integrations would continue to work. So e.g. EJB non-CDI would
> still use JTA as is today. I don't find it to be a big problem there, as
> it's much more under the covers (which is why it's nice to show EJBs in
> demos ;). Same for the others basically.

+1

> I understand you reluctance to call a Tiger a Cat but they are commonly
> > referred as Cats.
> > Back to our problem, you either
> > - teach people that transaction is not what they might understand of
> > transactions - if they even know what that means these days ;)
> > - teach them a new concept that suspiciously looks like a transaction
> > anyways and force them to do the integration of that ?thing? with their
> > universe.
> >
> 
> I'd prefer the latter. The good thing is that it is up to us to
> describe/document what the "thing" is, so we can manage expectations
> towards it, far better then when using the term "transaction" which
> automatically raises certain expectations (smart people will wonder how we
> make it work, others may even fall into the trap and believe it is actually
> TX).

A clear +1 for the latter options from me as well. It's all about managing expectations 
and right now we conjure the wrong ones for non transactional databases.

This transaction issue is imo one of the big sore points of OGM. The other one
is, that there is no clear separation on what one can and cannot do using JPA.
Some things will never be supported others could work, but are not implemented yet.
One never really knows. It has a bit of a sour after taste.

--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/20150506/20fd82db/attachment.bin 

From guillaume.smet at gmail.com  Wed May  6 16:21:54 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 6 May 2015 22:21:54 +0200
Subject: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed
	interceptor
Message-ID: <CALt0+o_1dMXYeOfC6uHQu-UsakjqjC5Jo8=uu1DDwA8YCTgu2Q@mail.gmail.com>

Hi,

As I have cycles this week and next week, I thought I might as well do some
QA on Hibernate 5.

I'm still in the process of porting our code to 5 atm and I have a pattern
we used before I can't find an elegant way to port on Hibernate 5: this
pattern is used to inject a Spring managed interceptor.

We override the persistence provider to inject the interceptor in the
Hibernate configuration:
https://gist.github.com/gsmet/e8d3003344938b1d327b

I studied the new code for quite some time and I couldn't find a way to
inject my interceptor in 5.

Note that it's a pretty common usage in the Spring managed world.

Thanks for any guidance.

-- 
Guillaume

From steve at hibernate.org  Wed May  6 22:59:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 6 May 2015 21:59:31 -0500
Subject: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed
	interceptor
In-Reply-To: <CALt0+o_1dMXYeOfC6uHQu-UsakjqjC5Jo8=uu1DDwA8YCTgu2Q@mail.gmail.com>
References: <CALt0+o_1dMXYeOfC6uHQu-UsakjqjC5Jo8=uu1DDwA8YCTgu2Q@mail.gmail.com>
Message-ID: <CAFdSV9sjK_HEi5B7ag0y9AtuNcdDr5_6XhgQF+Fnnf8MaY_Otw@mail.gmail.com>

As outlined in
http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html#_migration,
Configuration#setInterceptor
calls now map to the SessionFactoryBuilder#applyInterceptor method.  So
really we need to look at choices for how to influence the Interceptor on
SessionFactoryBuilder.  I say choices because there are a few ways.  The
most appropriate way I think in your case (given that you already
questionable subclass an internal class ;) would be to just override
EntityManagerFactoryBuilderImpl#populate(SessionFactoryBuilder,
StandardServiceRegistry) to apply your Interceptor.

On Wed, May 6, 2015 at 3:21 PM, Guillaume Smet <guillaume.smet at gmail.com>
wrote:

> Hi,
>
> As I have cycles this week and next week, I thought I might as well do some
> QA on Hibernate 5.
>
> I'm still in the process of porting our code to 5 atm and I have a pattern
> we used before I can't find an elegant way to port on Hibernate 5: this
> pattern is used to inject a Spring managed interceptor.
>
> We override the persistence provider to inject the interceptor in the
> Hibernate configuration:
> https://gist.github.com/gsmet/e8d3003344938b1d327b
>
> I studied the new code for quite some time and I couldn't find a way to
> inject my interceptor in 5.
>
> Note that it's a pretty common usage in the Spring managed world.
>
> Thanks for any guidance.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From emmanuel at hibernate.org  Thu May  7 02:12:54 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 7 May 2015 08:12:54 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CADGJaX--x3Mh4Lkntw=mu0=RV0kvxHzgJD+vF0efAe1TZF4=ug@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<27D88AF6-1F91-4483-9FE1-9B58820DFDB2@hibernate.org>
	<CADGJaX--x3Mh4Lkntw=mu0=RV0kvxHzgJD+vF0efAe1TZF4=ug@mail.gmail.com>
Message-ID: <CD63AAB6-2BF1-43D2-BB2C-209CC3197417@hibernate.org>


> On 06 May 2015, at 15:16, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> 
> 
> 2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>>:
> It?s an interesting idea.
> Let me give you the reasons why I think the transaction API has merits.
> 
> There is already a notion of UnitOfWork that was named Conversation in Seam / CDI. But its span is potentially longer than the span of the updates window. The closer notion of a UnitOfWork is an EntityManager or a Session.
> By introducing @UnitOfWork, you forgo all the integration between application frameworks and transactions. Here you offer a solution for CDI but we would need one for Java EE non CDI and one for Spring and one for Grails and one for?
> 
> The current integrations would continue to work. So e.g. EJB non-CDI would still use JTA as is today. I don't find it to be a big problem there, as it's much more under the covers (which is why it's nice to show EJBs in demos ;). Same for the others basically.

OK so you would still support essentially Hibernate Transactions with how we wired them with (compensation). But also add this new concept that would do exactly the same thing for people offended by the term transaction? Or am I misunderstanding something.


From gunnar at hibernate.org  Thu May  7 02:38:28 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 7 May 2015 08:38:28 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CD63AAB6-2BF1-43D2-BB2C-209CC3197417@hibernate.org>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<27D88AF6-1F91-4483-9FE1-9B58820DFDB2@hibernate.org>
	<CADGJaX--x3Mh4Lkntw=mu0=RV0kvxHzgJD+vF0efAe1TZF4=ug@mail.gmail.com>
	<CD63AAB6-2BF1-43D2-BB2C-209CC3197417@hibernate.org>
Message-ID: <CADGJaX_nj=SfRg0OuMp1O3_7vPunevJj9M60byOfLP6KF7bSrQ@mail.gmail.com>

2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

>
> On 06 May 2015, at 15:16, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
>
> 2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
>> It?s an interesting idea.
>> Let me give you the reasons why I think the transaction API has merits.
>>
>> There is already a notion of UnitOfWork that was named Conversation in
>> Seam / CDI. But its span is potentially longer than the span of the updates
>> window. The closer notion of a UnitOfWork is an EntityManager or a Session.
>
> By introducing @UnitOfWork, you forgo all the integration between
>> application frameworks and transactions. Here you offer a solution for CDI
>> but we would need one for Java EE non CDI and one for Spring and one for
>> Grails and one for?
>
>
> The current integrations would continue to work. So e.g. EJB non-CDI would
> still use JTA as is today. I don't find it to be a big problem there, as
> it's much more under the covers (which is why it's nice to show EJBs in
> demos ;). Same for the others basically.
>
>
> OK so you would still support essentially Hibernate Transactions with how
> we wired them with (compensation).
>

Yes, right. Under the hood essentially nothing would change.


> But also add this new concept that would do exactly the same thing for
> people offended by the term transaction? Or am I misunderstanding something.
>

It would be similar, but not the same. Specifically, such API would not
promise rollback capabilities or isolation from other, concurrent units of
work when e.g. doing explicit flushes.

From emmanuel at hibernate.org  Thu May  7 04:29:33 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 7 May 2015 10:29:33 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CADGJaX_nj=SfRg0OuMp1O3_7vPunevJj9M60byOfLP6KF7bSrQ@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<27D88AF6-1F91-4483-9FE1-9B58820DFDB2@hibernate.org>
	<CADGJaX--x3Mh4Lkntw=mu0=RV0kvxHzgJD+vF0efAe1TZF4=ug@mail.gmail.com>
	<CD63AAB6-2BF1-43D2-BB2C-209CC3197417@hibernate.org>
	<CADGJaX_nj=SfRg0OuMp1O3_7vPunevJj9M60byOfLP6KF7bSrQ@mail.gmail.com>
Message-ID: <0718B486-85DB-4A65-B3AF-0B388945EB4C@hibernate.org>


> On 07 May 2015, at 08:38, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> 
> 
> 2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>>:
> 
>> On 06 May 2015, at 15:16, Gunnar Morling <gunnar at hibernate.org <mailto:gunnar at hibernate.org>> wrote:
>> 
>> 
>> 
>> 2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org <mailto:emmanuel at hibernate.org>>:
>> It?s an interesting idea.
>> Let me give you the reasons why I think the transaction API has merits.
>> 
>> There is already a notion of UnitOfWork that was named Conversation in Seam / CDI. But its span is potentially longer than the span of the updates window. The closer notion of a UnitOfWork is an EntityManager or a Session.
>> By introducing @UnitOfWork, you forgo all the integration between application frameworks and transactions. Here you offer a solution for CDI but we would need one for Java EE non CDI and one for Spring and one for Grails and one for?
>> 
>> The current integrations would continue to work. So e.g. EJB non-CDI would still use JTA as is today. I don't find it to be a big problem there, as it's much more under the covers (which is why it's nice to show EJBs in demos ;). Same for the others basically.
> 
> OK so you would still support essentially Hibernate Transactions with how we wired them with (compensation). 
> 
> Yes, right. Under the hood essentially nothing would change.
>  
> But also add this new concept that would do exactly the same thing for people offended by the term transaction? Or am I misunderstanding something.
> 
> It would be similar, but not the same. Specifically, such API would not promise rollback capabilities or isolation from other, concurrent units of work when e.g. doing explicit flushes.

But I could still use session.getTransaction() and get the ?wrong? behavior?

From guillaume.smet at gmail.com  Thu May  7 11:37:46 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Thu, 7 May 2015 17:37:46 +0200
Subject: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed
	interceptor
In-Reply-To: <CAFdSV9sjK_HEi5B7ag0y9AtuNcdDr5_6XhgQF+Fnnf8MaY_Otw@mail.gmail.com>
References: <CALt0+o_1dMXYeOfC6uHQu-UsakjqjC5Jo8=uu1DDwA8YCTgu2Q@mail.gmail.com>
	<CAFdSV9sjK_HEi5B7ag0y9AtuNcdDr5_6XhgQF+Fnnf8MaY_Otw@mail.gmail.com>
Message-ID: <CALt0+o-rqdU5QL6q6t5HgDkNQN+7PRNvBw8G3BND72Ka1fJCJw@mail.gmail.com>

Yup, populate(SessionFactoryBuilder, StandardServiceRegistry) was my
favorite spot too but it's currently private. Would you mind making it
protected?

Note that if we can do so without subclassing the said internal class, I'm
all ears :). This method was inspired by a blog post for 4.2 that I ported
to 4.3. It has the advantage of not being too intrusive.

-- 
Guillaume

On Thu, May 7, 2015 at 4:59 AM, Steve Ebersole <steve at hibernate.org> wrote:

> As outlined in
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html#_migration, Configuration#setInterceptor
> calls now map to the SessionFactoryBuilder#applyInterceptor method.  So
> really we need to look at choices for how to influence the Interceptor on
> SessionFactoryBuilder.  I say choices because there are a few ways.  The
> most appropriate way I think in your case (given that you already
> questionable subclass an internal class ;) would be to just override
> EntityManagerFactoryBuilderImpl#populate(SessionFactoryBuilder,
> StandardServiceRegistry) to apply your Interceptor.
>
> On Wed, May 6, 2015 at 3:21 PM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Hi,
>>
>> As I have cycles this week and next week, I thought I might as well do
>> some
>> QA on Hibernate 5.
>>
>> I'm still in the process of porting our code to 5 atm and I have a pattern
>> we used before I can't find an elegant way to port on Hibernate 5: this
>> pattern is used to inject a Spring managed interceptor.
>>
>> We override the persistence provider to inject the interceptor in the
>> Hibernate configuration:
>> https://gist.github.com/gsmet/e8d3003344938b1d327b
>>
>> I studied the new code for quite some time and I couldn't find a way to
>> inject my interceptor in 5.
>>
>> Note that it's a pretty common usage in the Spring managed world.
>>
>> Thanks for any guidance.
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Thu May  7 11:51:32 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 7 May 2015 17:51:32 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <0718B486-85DB-4A65-B3AF-0B388945EB4C@hibernate.org>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<27D88AF6-1F91-4483-9FE1-9B58820DFDB2@hibernate.org>
	<CADGJaX--x3Mh4Lkntw=mu0=RV0kvxHzgJD+vF0efAe1TZF4=ug@mail.gmail.com>
	<CD63AAB6-2BF1-43D2-BB2C-209CC3197417@hibernate.org>
	<CADGJaX_nj=SfRg0OuMp1O3_7vPunevJj9M60byOfLP6KF7bSrQ@mail.gmail.com>
	<0718B486-85DB-4A65-B3AF-0B388945EB4C@hibernate.org>
Message-ID: <CADGJaX-WubzvcbN0veYUF2ZCh9Aev8yPeFO9ZaasSjL2tBeY0g@mail.gmail.com>

2015-05-07 10:29 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

>
> On 07 May 2015, at 08:38, Gunnar Morling <gunnar at hibernate.org> wrote:
>
>
>
> 2015-05-07 8:12 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
>>
>> On 06 May 2015, at 15:16, Gunnar Morling <gunnar at hibernate.org> wrote:
>>
>>
>>
>> 2015-05-06 14:19 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>>
>>> It?s an interesting idea.
>>> Let me give you the reasons why I think the transaction API has merits.
>>>
>>> There is already a notion of UnitOfWork that was named Conversation in
>>> Seam / CDI. But its span is potentially longer than the span of the updates
>>> window. The closer notion of a UnitOfWork is an EntityManager or a Session.
>>
>> By introducing @UnitOfWork, you forgo all the integration between
>>> application frameworks and transactions. Here you offer a solution for CDI
>>> but we would need one for Java EE non CDI and one for Spring and one for
>>> Grails and one for?
>>
>>
>> The current integrations would continue to work. So e.g. EJB non-CDI
>> would still use JTA as is today. I don't find it to be a big problem there,
>> as it's much more under the covers (which is why it's nice to show EJBs in
>> demos ;). Same for the others basically.
>>
>>
>> OK so you would still support essentially Hibernate Transactions with how
>> we wired them with (compensation).
>>
>
> Yes, right. Under the hood essentially nothing would change.
>
>
>> But also add this new concept that would do exactly the same thing for
>> people offended by the term transaction? Or am I misunderstanding something.
>>
>
> It would be similar, but not the same. Specifically, such API would not
> promise rollback capabilities or isolation from other, concurrent units of
> work when e.g. doing explicit flushes.
>
>
> But I could still use session.getTransaction() and get the ?wrong?
> behavior?
>

I think it's the general question should we have an API which offers
"everything", i.e. the sum of all functionality of all backends, meaning
that some parts of the announced API functionality will fail at runtime
(either silently or with an exception) on some backends. Or should we have
a more limited API which is supported everywhere, and then allow to
"unwrap" for certain backends (or families) and access advanced
functionality just applying to those (as we e.g. do with the configuration
API).

Currently OgmSession is the former, i.e. you could invoke getTransaction()
and basically achieve the same as with the proposed alternative. But you
could also try to rollback() and then it would fail, depending on the store.

I feel like the latter a bit better. For that we'd need a more limited
OgmSession contract, not extending ORM's Session. This could e.g. host the
runWorkUnit() functionality which is portable across backends.

Then there could be something like
OgmSession.as(TransactionalSession.class).beginTransaction(). Here you
would explicitly opt into transactional functionality. Of course you still
could wrongly invoke this e.g. for MongoDB, but IMO it can be documented in
a better way and help to manage people's expectations towards supported
functionality. Or, e.g. with CDI it could even fail right at deploy of no
TransactionalSession bean can be produced as per the current backend.

From brmeyer at redhat.com  Thu May  7 14:22:42 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 7 May 2015 14:22:42 -0400 (EDT)
Subject: [hibernate-dev] disabling envers during runtime
In-Reply-To: <257311077.15182529.1431022816419.JavaMail.zimbra@redhat.com>
Message-ID: <369307140.15183845.1431022962062.JavaMail.zimbra@redhat.com>

In older ORM versions, Envers could be dynamically disabled during runtime by creating an AuditEventListener delegate and surrounding the super calls with custom logic.  Info: https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Development_Guide/Enable_or_Disable_Auditing_at_Runtime1.html

Now that the architecture is different (EnversListener), any thoughts on alternatives?  Having trouble finding ideas...

In addition, is there a way to disable envers during SF bootstrapping?  Ie, set some sort of "hibernate.envers.disable" property?

From brmeyer at redhat.com  Thu May  7 14:28:12 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 7 May 2015 14:28:12 -0400 (EDT)
Subject: [hibernate-dev] disabling envers during runtime
In-Reply-To: <369307140.15183845.1431022962062.JavaMail.zimbra@redhat.com>
References: <369307140.15183845.1431022962062.JavaMail.zimbra@redhat.com>
Message-ID: <1048505615.15189499.1431023292597.JavaMail.zimbra@redhat.com>

...heh, it's already in the docs ;)

http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch15.html#d5e4486

----- Original Message -----
> From: "Brett Meyer" <brmeyer at redhat.com>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Thursday, May 7, 2015 2:22:42 PM
> Subject: [hibernate-dev] disabling envers during runtime
> 
> In older ORM versions, Envers could be dynamically disabled during runtime by
> creating an AuditEventListener delegate and surrounding the super calls with
> custom logic.  Info:
> https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Development_Guide/Enable_or_Disable_Auditing_at_Runtime1.html
> 
> Now that the architecture is different (EnversListener), any thoughts on
> alternatives?  Having trouble finding ideas...
> 
> In addition, is there a way to disable envers during SF bootstrapping?  Ie,
> set some sort of "hibernate.envers.disable" property?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From steve at hibernate.org  Thu May  7 15:26:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 7 May 2015 14:26:30 -0500
Subject: [hibernate-dev] disabling envers during runtime
In-Reply-To: <1048505615.15189499.1431023292597.JavaMail.zimbra@redhat.com>
References: <369307140.15183845.1431022962062.JavaMail.zimbra@redhat.com>
	<1048505615.15189499.1431023292597.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9vEV17z4hO7mQh+3FrWLcAkouAHcXR1ttQCzWrx5FdabQ@mail.gmail.com>

hibernate.listeners.envers.autoRegister is the old property.  See:

public static final String INTEGRATION_ENABLED =
"hibernate.integration.envers.enabled";

The old one is still recognized...

On Thu, May 7, 2015 at 1:28 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> ...heh, it's already in the docs ;)
>
>
> http://docs.jboss.org/hibernate/orm/4.3/devguide/en-US/html/ch15.html#d5e4486
>
> ----- Original Message -----
> > From: "Brett Meyer" <brmeyer at redhat.com>
> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > Sent: Thursday, May 7, 2015 2:22:42 PM
> > Subject: [hibernate-dev] disabling envers during runtime
> >
> > In older ORM versions, Envers could be dynamically disabled during
> runtime by
> > creating an AuditEventListener delegate and surrounding the super calls
> with
> > custom logic.  Info:
> >
> https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6/html/Development_Guide/Enable_or_Disable_Auditing_at_Runtime1.html
> >
> > Now that the architecture is different (EnversListener), any thoughts on
> > alternatives?  Having trouble finding ideas...
> >
> > In addition, is there a way to disable envers during SF bootstrapping?
> Ie,
> > set some sort of "hibernate.envers.disable" property?
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.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 May  8 03:00:37 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 8 May 2015 09:00:37 +0200
Subject: [hibernate-dev] [OGM] JIRA components for backends
Message-ID: <CADGJaX-fqRx2N_MuWtkaJX5cc47q+m=mayVntTiu8WM_YgHQRw@mail.gmail.com>

Hi,

As we had discussed a while ago, I have created a dedicated JIRA component
for each of our backends in OGM.

This means we don't have to encode the backend in issue titles anymore.
Thanks to Hardy's release script, the component name will be added to issue
titles in the change logs. Just make sure issues you are working on are
assigned to the right component.

The previous "datastore" component should not be used any longer for issues
we work on from now on. Unfortunately there is no component archiving
feature in JIRA, so we cannot actually disable the legacy component. I have
renamed it so it shows up last in the drop-down. It's not perfect, but the
alternative would be to physically delete it, which I dislike as it'd
affect all the closed issues linked to it.

Cheers,

--Gunnar

From guillaume.smet at gmail.com  Fri May  8 09:09:03 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 8 May 2015 15:09:03 +0200
Subject: [hibernate-dev] HHH-7610 - Embedded and nulls
In-Reply-To: <CAFdSV9tQQKemH3kqaZrNhSzOESJ4ou8mywFaQDAOnmC5E4rQkA@mail.gmail.com>
References: <CALt0+o-HcLZgkVHE-oD1MEde+97J84m3xr6Go3is-JCOyKTMGQ@mail.gmail.com>
	<CAFdSV9tQQKemH3kqaZrNhSzOESJ4ou8mywFaQDAOnmC5E4rQkA@mail.gmail.com>
Message-ID: <CALt0+o-x7b6vReEsZ=sknDd9zmDMR3qO1tYH7ZWhHCO4dr_VMg@mail.gmail.com>

OK, done: https://github.com/hibernate/hibernate-orm/pull/944 (I just
squashed the commits of Laurent into one)

This PR is for 4.3 as we originally wrote it for 4.3. I already ported it
to 5 but I prefer waiting we have settled everything before submitting the
other PR for 5 (the merge requires a bit of work).

FWIW, we are running this in production for quite some time now.

On Wed, May 6, 2015 at 6:10 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Sure, I can take a look at a Pull Request.  Just ping us on the list when
> it is ready (sometimes the PR notifications "get lost" in the shuffle).
>
> On Wed, May 6, 2015 at 9:00 AM, Guillaume Smet <guillaume.smet at gmail.com>
> wrote:
>
>> Hi all,
>>
>> (sorry for the long silence, have been dealing with personal issues)
>>
>> I have cycles next week and I would like to tackle this issue:
>> https://hibernate.atlassian.net/browse/HHH-7610
>>
>> My colleague, Laurent Almeras, already worked on a patch here:
>>
>> https://github.com/openwide-java/hibernate-orm/commits/embedded-empty-configuration
>> .
>>
>> Steve gave us a few advices and we took them into account in the following
>> commits.
>>
>> Should I rebase the patch and propose a PR? If so, for which branches?
>>
>> As a lot of people asked for it, I would prefer it being integrated
>> instead
>> of keeping a set of patches here at Open Wide.
>>
>> Thanks for your feedback!
>>
>> --
>> Guillaume
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From sanne at hibernate.org  Fri May  8 09:10:20 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 8 May 2015 14:10:20 +0100
Subject: [hibernate-dev] Hibernate Search 5 compatible with Hibernate
	ORM 4?
In-Reply-To: <9848649F-CA94-4BB3-88E2-DDD6E0D3A987@hibernate.org>
References: <CAFm4XO0dLJsF57+xjaB3Qr4a8DqOYWif0FZQCK5-6cUpmdTR+Q@mail.gmail.com>
	<3B4B5EEA-00C1-4DF0-A71A-76E8309D0E29@hibernate.org>
	<CAFm4XO2_+cj5hjWQqU1gDFCW-Lq9Rhb3S9MhiYtCd8QwN032mQ@mail.gmail.com>
	<9848649F-CA94-4BB3-88E2-DDD6E0D3A987@hibernate.org>
Message-ID: <CAFm4XO3GOg5AG6_58CHPqOrVGMTSsQf0b8WVtjvWsH1oUQ6j4Q@mail.gmail.com>

An ANT user on the forums got in trouble several times, first with
Lucene versions vs Hibernate Search, then fixed that he upgraded ORM
to 5 as well to align with Search 5 only to see Validator blow up at
bootstrap.

https://forum.hibernate.org/viewtopic.php?f=9&t=1039286

I'm thinking if we should invest a little time in developing a way to
detect a non-compatible version on classpath. We obviously can't make
that perfect as projects can't know the future, but we could get a
decent error message for the most common mistakes, for example major
versions.

What about the Hibernate ORM 'Integrator' mechanism to have a way to
define for example:
 - expected ranges of ORM which *should* work (based on our
major.minor conventions)
 - expected versions which definitely work (being tested and released with)
 - some kind of blacklist capability to list specific versions (or
ranges) which are known to definitely not work

This could be for example an annotation we use on our Integrator
implementations?

Not aiming at a perfect solution of course - but it's better than
nothing. The open question is if this is worth our time, but maybe
it's an easy improvement?

-- Sanne


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

From sanne at hibernate.org  Fri May  8 12:47:03 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 8 May 2015 17:47:03 +0100
Subject: [hibernate-dev] Removing deprecated methods from Session and
	SessionFactory
In-Reply-To: <20150505183846.GB5753@Nineveh.lan>
References: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
	<CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>
	<CAFm4XO0iJdKdLBK9gTOA8FRTracFpRU5O-0Saipn7dcrm7z-xQ@mail.gmail.com>
	<CAFdSV9vssBvAWccP=s1_ULGLZg1wVxEhewsKyQhFgRJBee2Nsg@mail.gmail.com>
	<20150505183846.GB5753@Nineveh.lan>
Message-ID: <CAFm4XO1pkG8vJjNXu3wueCxhVYT-VXwkudHvuUqXersJPZQh7A@mail.gmail.com>

Of course we can delete them, I just meant to stress there should be a
different "appropriate moment" for:
 A] removal of deprecated methods for the sake of it (cleanup of old garbage)
 B] removal of a method during a major release (API changes allowed)
because we can't otherwise get some improvement

When a new major release comes - say Hibernate ORM 5.0 - we'll have
quite a bit of "B" changes, as they are unavoidable and desired.

If we also make all changes in category A, the steer amount of changes
might become a critical mass which scare off people from upgrading.

Speaking as a user who regularly codes as a client for such changes
(for example Lucene 4 was a rather dramatic "fix" with over 2,000
compilation problems in Hibernate Search), I can swear that it's very
nice if I can upgrade my application by fixing *some limited*
compilation failures, and then run my testsuite. Then rinse and
repeat... if I have to code 2 weeks straight w/o being able to run my
tests I'll despair.

So for ORM I'd not immediately delete all deprecated methods: let it
be easy for people to upgrade to 5 as that's an intimidating process;
let them realise that with a couple of changes they can do it. Once
they're over the scary part, you can remove the long deprecated
methods in some minor.
But if any of these methods is a hindrance to get improvements done, no mercy :)

Sanne

On 5 May 2015 at 19:38, Hardy Ferentschik <hardy at hibernate.org> wrote:
> On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
>> Why?  Why even deprecate methods then?
>
> +1
>
> --Hardy

From steve at hibernate.org  Fri May  8 13:33:24 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 8 May 2015 12:33:24 -0500
Subject: [hibernate-dev] Removing deprecated methods from Session and
	SessionFactory
In-Reply-To: <CAFm4XO1pkG8vJjNXu3wueCxhVYT-VXwkudHvuUqXersJPZQh7A@mail.gmail.com>
References: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
	<CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>
	<CAFm4XO0iJdKdLBK9gTOA8FRTracFpRU5O-0Saipn7dcrm7z-xQ@mail.gmail.com>
	<CAFdSV9vssBvAWccP=s1_ULGLZg1wVxEhewsKyQhFgRJBee2Nsg@mail.gmail.com>
	<20150505183846.GB5753@Nineveh.lan>
	<CAFm4XO1pkG8vJjNXu3wueCxhVYT-VXwkudHvuUqXersJPZQh7A@mail.gmail.com>
Message-ID: <CAFdSV9twKzJwL8=U4fWjj2QixXnZy8qcZ8FbOYJeekTCcmcBnQ@mail.gmail.com>

I don't know if I agree with this.  I'll play the other side... What if you
had done the Lucene 4 upgrade and spent a bunch of time managing API
changes and finally got it right and then Lucene 4.1 cam along and removed
a bunch of deprecated methods?  I think I'd actually be a tad more pissed
off at this scenario.  Maybe that's just me?  And realize that alot of the
methods that are deprecated and being discussed have actually be deprecated
in before 4.0 even.  That's a long time...

On Fri, May 8, 2015 at 11:47 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> Of course we can delete them, I just meant to stress there should be a
> different "appropriate moment" for:
>  A] removal of deprecated methods for the sake of it (cleanup of old
> garbage)
>  B] removal of a method during a major release (API changes allowed)
> because we can't otherwise get some improvement
>
> When a new major release comes - say Hibernate ORM 5.0 - we'll have
> quite a bit of "B" changes, as they are unavoidable and desired.
>
> If we also make all changes in category A, the steer amount of changes
> might become a critical mass which scare off people from upgrading.
>
> Speaking as a user who regularly codes as a client for such changes
> (for example Lucene 4 was a rather dramatic "fix" with over 2,000
> compilation problems in Hibernate Search), I can swear that it's very
> nice if I can upgrade my application by fixing *some limited*
> compilation failures, and then run my testsuite. Then rinse and
> repeat... if I have to code 2 weeks straight w/o being able to run my
> tests I'll despair.
>
> So for ORM I'd not immediately delete all deprecated methods: let it
> be easy for people to upgrade to 5 as that's an intimidating process;
> let them realise that with a couple of changes they can do it. Once
> they're over the scary part, you can remove the long deprecated
> methods in some minor.
> But if any of these methods is a hindrance to get improvements done, no
> mercy :)
>
> Sanne
>
> On 5 May 2015 at 19:38, Hardy Ferentschik <hardy at hibernate.org> wrote:
> > On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
> >> Why?  Why even deprecate methods then?
> >
> > +1
> >
> > --Hardy
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri May  8 13:59:42 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 8 May 2015 18:59:42 +0100
Subject: [hibernate-dev] Removing deprecated methods from Session and
	SessionFactory
In-Reply-To: <CAFdSV9twKzJwL8=U4fWjj2QixXnZy8qcZ8FbOYJeekTCcmcBnQ@mail.gmail.com>
References: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
	<CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>
	<CAFm4XO0iJdKdLBK9gTOA8FRTracFpRU5O-0Saipn7dcrm7z-xQ@mail.gmail.com>
	<CAFdSV9vssBvAWccP=s1_ULGLZg1wVxEhewsKyQhFgRJBee2Nsg@mail.gmail.com>
	<20150505183846.GB5753@Nineveh.lan>
	<CAFm4XO1pkG8vJjNXu3wueCxhVYT-VXwkudHvuUqXersJPZQh7A@mail.gmail.com>
	<CAFdSV9twKzJwL8=U4fWjj2QixXnZy8qcZ8FbOYJeekTCcmcBnQ@mail.gmail.com>
Message-ID: <CAFm4XO3SdkTZjcWE7m1H0L=QEo6Gsm3q0dFZO=efWtDYBpz-Lg@mail.gmail.com>

On 8 May 2015 at 18:33, Steve Ebersole <steve at hibernate.org> wrote:
> I don't know if I agree with this.  I'll play the other side... What if you
> had done the Lucene 4 upgrade and spent a bunch of time managing API changes
> and finally got it right and then Lucene 4.1 cam along and removed a bunch
> of deprecated methods?  I think I'd actually be a tad more pissed off at
> this scenario.  Maybe that's just me?  And realize that alot of the methods
> that are deprecated and being discussed have actually be deprecated in
> before 4.0 even.  That's a long time...

If that would have happened, I'd open the source code before
upgrading, get my IDE to highlight deprecated methods and resolve
them.
I would have been able to remove a dozen trivial ones, then run the
testsuite to confirm.. then remove a tricky one, run the testsuite to
confirm.. etc..

When I'm done, I upgrade to Lucene 4.1 and test again.

I would have loved that!

Think about the opposite: you code flat out for two weeks, and then
you have some test failing in a very mysterious way; then it's like
"ok, one of these 40,000 lines of changes is wrong".
It took us 2 months of work, or almost a year if you include finding
an appropriate moment in which you can actually afford to block any
other activity for no other reason than an upgrade.

Sanne


>
> On Fri, May 8, 2015 at 11:47 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> Of course we can delete them, I just meant to stress there should be a
>> different "appropriate moment" for:
>>  A] removal of deprecated methods for the sake of it (cleanup of old
>> garbage)
>>  B] removal of a method during a major release (API changes allowed)
>> because we can't otherwise get some improvement
>>
>> When a new major release comes - say Hibernate ORM 5.0 - we'll have
>> quite a bit of "B" changes, as they are unavoidable and desired.
>>
>> If we also make all changes in category A, the steer amount of changes
>> might become a critical mass which scare off people from upgrading.
>>
>> Speaking as a user who regularly codes as a client for such changes
>> (for example Lucene 4 was a rather dramatic "fix" with over 2,000
>> compilation problems in Hibernate Search), I can swear that it's very
>> nice if I can upgrade my application by fixing *some limited*
>> compilation failures, and then run my testsuite. Then rinse and
>> repeat... if I have to code 2 weeks straight w/o being able to run my
>> tests I'll despair.
>>
>> So for ORM I'd not immediately delete all deprecated methods: let it
>> be easy for people to upgrade to 5 as that's an intimidating process;
>> let them realise that with a couple of changes they can do it. Once
>> they're over the scary part, you can remove the long deprecated
>> methods in some minor.
>> But if any of these methods is a hindrance to get improvements done, no
>> mercy :)
>>
>> Sanne
>>
>> On 5 May 2015 at 19:38, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> > On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
>> >> Why?  Why even deprecate methods then?
>> >
>> > +1
>> >
>> > --Hardy
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Fri May  8 14:30:47 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 8 May 2015 13:30:47 -0500
Subject: [hibernate-dev] Removing deprecated methods from Session and
	SessionFactory
In-Reply-To: <CAFm4XO3SdkTZjcWE7m1H0L=QEo6Gsm3q0dFZO=efWtDYBpz-Lg@mail.gmail.com>
References: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
	<CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>
	<CAFm4XO0iJdKdLBK9gTOA8FRTracFpRU5O-0Saipn7dcrm7z-xQ@mail.gmail.com>
	<CAFdSV9vssBvAWccP=s1_ULGLZg1wVxEhewsKyQhFgRJBee2Nsg@mail.gmail.com>
	<20150505183846.GB5753@Nineveh.lan>
	<CAFm4XO1pkG8vJjNXu3wueCxhVYT-VXwkudHvuUqXersJPZQh7A@mail.gmail.com>
	<CAFdSV9twKzJwL8=U4fWjj2QixXnZy8qcZ8FbOYJeekTCcmcBnQ@mail.gmail.com>
	<CAFm4XO3SdkTZjcWE7m1H0L=QEo6Gsm3q0dFZO=efWtDYBpz-Lg@mail.gmail.com>
Message-ID: <CAFdSV9s_JkAZni4GxT3eJh7DfXDYmuugEv1bN9AgZT38pMpdQQ@mail.gmail.com>

Sanne, the methods are already deprecated.  You can already do that step.
For the deprecated methods that actually have a replacement anyway.

But think about the ones that don't.  They are the ones that are likely to
"still be there" on the API and likely do absolutely nothing.  Because if
there was a corollary, we would have named it in the deprecation message
when we deprecated it.

I mean following your logic (assuming that we are good citizens) you would
always do a first step of upgrading to the latest bugfixz release of the
previous release family.  That version will have the deprecations in
place.  For example, if I want to upgrade to 5.0 I would first upgrade to
the latest 4.3 and fix any deprecations.  *Then* I can update to 5.0.  Its
exactly what you described just in reverse.  Except that it allows us to
actually clean up trash :)



On Fri, May 8, 2015 at 12:59 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 8 May 2015 at 18:33, Steve Ebersole <steve at hibernate.org> wrote:
> > I don't know if I agree with this.  I'll play the other side... What if
> you
> > had done the Lucene 4 upgrade and spent a bunch of time managing API
> changes
> > and finally got it right and then Lucene 4.1 cam along and removed a
> bunch
> > of deprecated methods?  I think I'd actually be a tad more pissed off at
> > this scenario.  Maybe that's just me?  And realize that alot of the
> methods
> > that are deprecated and being discussed have actually be deprecated in
> > before 4.0 even.  That's a long time...
>
> If that would have happened, I'd open the source code before
> upgrading, get my IDE to highlight deprecated methods and resolve
> them.
> I would have been able to remove a dozen trivial ones, then run the
> testsuite to confirm.. then remove a tricky one, run the testsuite to
> confirm.. etc..
>
> When I'm done, I upgrade to Lucene 4.1 and test again.
>
> I would have loved that!
>
> Think about the opposite: you code flat out for two weeks, and then
> you have some test failing in a very mysterious way; then it's like
> "ok, one of these 40,000 lines of changes is wrong".
> It took us 2 months of work, or almost a year if you include finding
> an appropriate moment in which you can actually afford to block any
> other activity for no other reason than an upgrade.
>
> Sanne
>
>
> >
> > On Fri, May 8, 2015 at 11:47 AM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> Of course we can delete them, I just meant to stress there should be a
> >> different "appropriate moment" for:
> >>  A] removal of deprecated methods for the sake of it (cleanup of old
> >> garbage)
> >>  B] removal of a method during a major release (API changes allowed)
> >> because we can't otherwise get some improvement
> >>
> >> When a new major release comes - say Hibernate ORM 5.0 - we'll have
> >> quite a bit of "B" changes, as they are unavoidable and desired.
> >>
> >> If we also make all changes in category A, the steer amount of changes
> >> might become a critical mass which scare off people from upgrading.
> >>
> >> Speaking as a user who regularly codes as a client for such changes
> >> (for example Lucene 4 was a rather dramatic "fix" with over 2,000
> >> compilation problems in Hibernate Search), I can swear that it's very
> >> nice if I can upgrade my application by fixing *some limited*
> >> compilation failures, and then run my testsuite. Then rinse and
> >> repeat... if I have to code 2 weeks straight w/o being able to run my
> >> tests I'll despair.
> >>
> >> So for ORM I'd not immediately delete all deprecated methods: let it
> >> be easy for people to upgrade to 5 as that's an intimidating process;
> >> let them realise that with a couple of changes they can do it. Once
> >> they're over the scary part, you can remove the long deprecated
> >> methods in some minor.
> >> But if any of these methods is a hindrance to get improvements done, no
> >> mercy :)
> >>
> >> Sanne
> >>
> >> On 5 May 2015 at 19:38, Hardy Ferentschik <hardy at hibernate.org> wrote:
> >> > On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
> >> >> Why?  Why even deprecate methods then?
> >> >
> >> > +1
> >> >
> >> > --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  Fri May  8 16:02:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 8 May 2015 21:02:47 +0100
Subject: [hibernate-dev] Removing deprecated methods from Session and
	SessionFactory
In-Reply-To: <CAFdSV9s_JkAZni4GxT3eJh7DfXDYmuugEv1bN9AgZT38pMpdQQ@mail.gmail.com>
References: <CADGJaX9BS0wjBbo9kfprnTdN566gwO0nJwdwSM=d0YRwj_DZAw@mail.gmail.com>
	<CAFdSV9t0s6fag-k3Rj70Z+DcMmJqw6VNfHoUUdn27pTGXYyRuA@mail.gmail.com>
	<CAFm4XO0iJdKdLBK9gTOA8FRTracFpRU5O-0Saipn7dcrm7z-xQ@mail.gmail.com>
	<CAFdSV9vssBvAWccP=s1_ULGLZg1wVxEhewsKyQhFgRJBee2Nsg@mail.gmail.com>
	<20150505183846.GB5753@Nineveh.lan>
	<CAFm4XO1pkG8vJjNXu3wueCxhVYT-VXwkudHvuUqXersJPZQh7A@mail.gmail.com>
	<CAFdSV9twKzJwL8=U4fWjj2QixXnZy8qcZ8FbOYJeekTCcmcBnQ@mail.gmail.com>
	<CAFm4XO3SdkTZjcWE7m1H0L=QEo6Gsm3q0dFZO=efWtDYBpz-Lg@mail.gmail.com>
	<CAFdSV9s_JkAZni4GxT3eJh7DfXDYmuugEv1bN9AgZT38pMpdQQ@mail.gmail.com>
Message-ID: <CAFm4XO02BCT-XpRYe6-GH6d=VOzBHSb7gxZ1wGOFP_0S7NT87Q@mail.gmail.com>

Right, seems we agree then; mine is purely a quantitative approach:
don't break too much in a single version, but if these have been
deprecated already my comment doesn't apply.

Sanne

On 8 May 2015 at 19:30, Steve Ebersole <steve at hibernate.org> wrote:
> Sanne, the methods are already deprecated.  You can already do that step.
> For the deprecated methods that actually have a replacement anyway.
>
> But think about the ones that don't.  They are the ones that are likely to
> "still be there" on the API and likely do absolutely nothing.  Because if
> there was a corollary, we would have named it in the deprecation message
> when we deprecated it.
>
> I mean following your logic (assuming that we are good citizens) you would
> always do a first step of upgrading to the latest bugfixz release of the
> previous release family.  That version will have the deprecations in place.
> For example, if I want to upgrade to 5.0 I would first upgrade to the latest
> 4.3 and fix any deprecations.  *Then* I can update to 5.0.  Its exactly what
> you described just in reverse.  Except that it allows us to actually clean
> up trash :)
>
>
>
> On Fri, May 8, 2015 at 12:59 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> On 8 May 2015 at 18:33, Steve Ebersole <steve at hibernate.org> wrote:
>> > I don't know if I agree with this.  I'll play the other side... What if
>> > you
>> > had done the Lucene 4 upgrade and spent a bunch of time managing API
>> > changes
>> > and finally got it right and then Lucene 4.1 cam along and removed a
>> > bunch
>> > of deprecated methods?  I think I'd actually be a tad more pissed off at
>> > this scenario.  Maybe that's just me?  And realize that alot of the
>> > methods
>> > that are deprecated and being discussed have actually be deprecated in
>> > before 4.0 even.  That's a long time...
>>
>> If that would have happened, I'd open the source code before
>> upgrading, get my IDE to highlight deprecated methods and resolve
>> them.
>> I would have been able to remove a dozen trivial ones, then run the
>> testsuite to confirm.. then remove a tricky one, run the testsuite to
>> confirm.. etc..
>>
>> When I'm done, I upgrade to Lucene 4.1 and test again.
>>
>> I would have loved that!
>>
>> Think about the opposite: you code flat out for two weeks, and then
>> you have some test failing in a very mysterious way; then it's like
>> "ok, one of these 40,000 lines of changes is wrong".
>> It took us 2 months of work, or almost a year if you include finding
>> an appropriate moment in which you can actually afford to block any
>> other activity for no other reason than an upgrade.
>>
>> Sanne
>>
>>
>> >
>> > On Fri, May 8, 2015 at 11:47 AM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> Of course we can delete them, I just meant to stress there should be a
>> >> different "appropriate moment" for:
>> >>  A] removal of deprecated methods for the sake of it (cleanup of old
>> >> garbage)
>> >>  B] removal of a method during a major release (API changes allowed)
>> >> because we can't otherwise get some improvement
>> >>
>> >> When a new major release comes - say Hibernate ORM 5.0 - we'll have
>> >> quite a bit of "B" changes, as they are unavoidable and desired.
>> >>
>> >> If we also make all changes in category A, the steer amount of changes
>> >> might become a critical mass which scare off people from upgrading.
>> >>
>> >> Speaking as a user who regularly codes as a client for such changes
>> >> (for example Lucene 4 was a rather dramatic "fix" with over 2,000
>> >> compilation problems in Hibernate Search), I can swear that it's very
>> >> nice if I can upgrade my application by fixing *some limited*
>> >> compilation failures, and then run my testsuite. Then rinse and
>> >> repeat... if I have to code 2 weeks straight w/o being able to run my
>> >> tests I'll despair.
>> >>
>> >> So for ORM I'd not immediately delete all deprecated methods: let it
>> >> be easy for people to upgrade to 5 as that's an intimidating process;
>> >> let them realise that with a couple of changes they can do it. Once
>> >> they're over the scary part, you can remove the long deprecated
>> >> methods in some minor.
>> >> But if any of these methods is a hindrance to get improvements done, no
>> >> mercy :)
>> >>
>> >> Sanne
>> >>
>> >> On 5 May 2015 at 19:38, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> >> > On Tue, May 05, 2015 at 08:36:27AM -0500, Steve Ebersole wrote:
>> >> >> Why?  Why even deprecate methods then?
>> >> >
>> >> > +1
>> >> >
>> >> > --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  Sat May  9 06:17:35 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 9 May 2015 11:17:35 +0100
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
Message-ID: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>

Hi,
I'm having some trouble to build a fresh checkout from master.
The first attempt produced:

 FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'hibernate-core-parent'.
> Could not resolve all dependencies for configuration ':classpath'.
   > Could not find com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.

So I checked out this plugin:
https://github.com/lburgazzoli/lb-gradle-plugins , installed it
locally.

Now I get :

FAILURE: Build failed with an exception.

* Where:
Build file '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
line: 109

* What went wrong:
A problem occurred evaluating project ':hibernate-osgi'.
> Could not find method features() for arguments [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6] on project ':hibernate-osgi'.

Do I need to apply some patches to that plugin?

thanks,
Sanne

From steve at hibernate.org  Sat May  9 09:09:06 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 9 May 2015 08:09:06 -0500
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
Message-ID: <CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>

Sorry I forgot I had not yet integrated my newest work on that plugin
upstream.  Check out my fork of it and publish that locally
: git at github.com:sebersole/lb-gradle-plugins.git

On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi,
> I'm having some trouble to build a fresh checkout from master.
> The first attempt produced:
>
>  FAILURE: Build failed with an exception.
>
> * What went wrong:
> A problem occurred configuring root project 'hibernate-core-parent'.
> > Could not resolve all dependencies for configuration ':classpath'.
>    > Could not find
> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
>
> So I checked out this plugin:
> https://github.com/lburgazzoli/lb-gradle-plugins , installed it
> locally.
>
> Now I get :
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Build file
> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
> line: 109
>
> * What went wrong:
> A problem occurred evaluating project ':hibernate-osgi'.
> > Could not find method features() for arguments
> [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6]
> on project ':hibernate-osgi'.
>
> Do I need to apply some patches to that plugin?
>
> thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Sat May  9 09:11:02 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 9 May 2015 08:11:02 -0500
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
Message-ID: <CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>

Interesting... The ORM master CI builds stopped pulling changes and auto
building.  Any idea why?

On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Sorry I forgot I had not yet integrated my newest work on that plugin
> upstream.  Check out my fork of it and publish that locally
> : git at github.com:sebersole/lb-gradle-plugins.git
>
> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> Hi,
>> I'm having some trouble to build a fresh checkout from master.
>> The first attempt produced:
>>
>>  FAILURE: Build failed with an exception.
>>
>> * What went wrong:
>> A problem occurred configuring root project 'hibernate-core-parent'.
>> > Could not resolve all dependencies for configuration ':classpath'.
>>    > Could not find
>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
>>
>> So I checked out this plugin:
>> https://github.com/lburgazzoli/lb-gradle-plugins , installed it
>> locally.
>>
>> Now I get :
>>
>> FAILURE: Build failed with an exception.
>>
>> * Where:
>> Build file
>> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
>> line: 109
>>
>> * What went wrong:
>> A problem occurred evaluating project ':hibernate-osgi'.
>> > Could not find method features() for arguments
>> [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6]
>> on project ':hibernate-osgi'.
>>
>> Do I need to apply some patches to that plugin?
>>
>> thanks,
>> Sanne
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Sat May  9 09:24:24 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 9 May 2015 08:24:24 -0500
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
Message-ID: <CAFdSV9tpar5-=EETtRvZpQi4TjHxwprNgq3xpv9WJisV4G6Zmg@mail.gmail.com>

Sanne, I actually went ahead and published my local work SNAPSHOT to the
JBoss snapshot repo.  You build should just find it now...

On Sat, May 9, 2015 at 8:11 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Interesting... The ORM master CI builds stopped pulling changes and auto
> building.  Any idea why?
>
> On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Sorry I forgot I had not yet integrated my newest work on that plugin
>> upstream.  Check out my fork of it and publish that locally
>> : git at github.com:sebersole/lb-gradle-plugins.git
>>
>> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> Hi,
>>> I'm having some trouble to build a fresh checkout from master.
>>> The first attempt produced:
>>>
>>>  FAILURE: Build failed with an exception.
>>>
>>> * What went wrong:
>>> A problem occurred configuring root project 'hibernate-core-parent'.
>>> > Could not resolve all dependencies for configuration ':classpath'.
>>>    > Could not find
>>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
>>>
>>> So I checked out this plugin:
>>> https://github.com/lburgazzoli/lb-gradle-plugins , installed it
>>> locally.
>>>
>>> Now I get :
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * Where:
>>> Build file
>>> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
>>> line: 109
>>>
>>> * What went wrong:
>>> A problem occurred evaluating project ':hibernate-osgi'.
>>> > Could not find method features() for arguments
>>> [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6]
>>> on project ':hibernate-osgi'.
>>>
>>> Do I need to apply some patches to that plugin?
>>>
>>> thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>

From sanne at hibernate.org  Sat May  9 09:24:21 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 9 May 2015 14:24:21 +0100
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
Message-ID: <CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>

I updated my checkout to your fork, but there are no new commits
compared to Luca's fork. Maybe you need to push it? Or which branch is
it?

Anyway it's not a blocker as I've changed my master branch to precede
your last OSGi changes.. I just won't be able to test it with latest
but that shouldn't be a problem.

I'll have a look at CI; I don't know.. we had two slaves running out
of disk space, that's likely going to happen on all remaining slaves
soon if I don't rebuild them..

On 9 May 2015 at 14:11, Steve Ebersole <steve at hibernate.org> wrote:
> Interesting... The ORM master CI builds stopped pulling changes and auto
> building.  Any idea why?
>
> On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> Sorry I forgot I had not yet integrated my newest work on that plugin
>> upstream.  Check out my fork of it and publish that locally :
>> git at github.com:sebersole/lb-gradle-plugins.git
>>
>> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> Hi,
>>> I'm having some trouble to build a fresh checkout from master.
>>> The first attempt produced:
>>>
>>>  FAILURE: Build failed with an exception.
>>>
>>> * What went wrong:
>>> A problem occurred configuring root project 'hibernate-core-parent'.
>>> > Could not resolve all dependencies for configuration ':classpath'.
>>>    > Could not find
>>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
>>>
>>> So I checked out this plugin:
>>> https://github.com/lburgazzoli/lb-gradle-plugins , installed it
>>> locally.
>>>
>>> Now I get :
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * Where:
>>> Build file
>>> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
>>> line: 109
>>>
>>> * What went wrong:
>>> A problem occurred evaluating project ':hibernate-osgi'.
>>> > Could not find method features() for arguments
>>> > [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6]
>>> > on project ':hibernate-osgi'.
>>>
>>> Do I need to apply some patches to that plugin?
>>>
>>> thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>

From steve at hibernate.org  Sat May  9 09:27:25 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 9 May 2015 08:27:25 -0500
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
	<CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>
Message-ID: <CAFdSV9tQgP4nPFXEo7TDWzoGhPo5NLJK3rM_WcHMoevtHNyG7A@mail.gmail.com>

It is the dsl-extension branch.  But like I said, you should just be able
to find it from JBoss snapshot repo now.

On Sat, May 9, 2015 at 8:24 AM, Sanne Grinovero <sanne at hibernate.org> wrote:

> I updated my checkout to your fork, but there are no new commits
> compared to Luca's fork. Maybe you need to push it? Or which branch is
> it?
>
> Anyway it's not a blocker as I've changed my master branch to precede
> your last OSGi changes.. I just won't be able to test it with latest
> but that shouldn't be a problem.
>
> I'll have a look at CI; I don't know.. we had two slaves running out
> of disk space, that's likely going to happen on all remaining slaves
> soon if I don't rebuild them..
>
> On 9 May 2015 at 14:11, Steve Ebersole <steve at hibernate.org> wrote:
> > Interesting... The ORM master CI builds stopped pulling changes and auto
> > building.  Any idea why?
> >
> > On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >> Sorry I forgot I had not yet integrated my newest work on that plugin
> >> upstream.  Check out my fork of it and publish that locally :
> >> git at github.com:sebersole/lb-gradle-plugins.git
> >>
> >> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>>
> >>> Hi,
> >>> I'm having some trouble to build a fresh checkout from master.
> >>> The first attempt produced:
> >>>
> >>>  FAILURE: Build failed with an exception.
> >>>
> >>> * What went wrong:
> >>> A problem occurred configuring root project 'hibernate-core-parent'.
> >>> > Could not resolve all dependencies for configuration ':classpath'.
> >>>    > Could not find
> >>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
> >>>
> >>> So I checked out this plugin:
> >>> https://github.com/lburgazzoli/lb-gradle-plugins , installed it
> >>> locally.
> >>>
> >>> Now I get :
> >>>
> >>> FAILURE: Build failed with an exception.
> >>>
> >>> * Where:
> >>> Build file
> >>>
> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
> >>> line: 109
> >>>
> >>> * What went wrong:
> >>> A problem occurred evaluating project ':hibernate-osgi'.
> >>> > Could not find method features() for arguments
> >>> >
> [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6
> ]
> >>> > on project ':hibernate-osgi'.
> >>>
> >>> Do I need to apply some patches to that plugin?
> >>>
> >>> thanks,
> >>> Sanne
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Sat May  9 11:05:29 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 9 May 2015 16:05:29 +0100
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAFdSV9tQgP4nPFXEo7TDWzoGhPo5NLJK3rM_WcHMoevtHNyG7A@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
	<CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>
	<CAFdSV9tQgP4nPFXEo7TDWzoGhPo5NLJK3rM_WcHMoevtHNyG7A@mail.gmail.com>
Message-ID: <CAFm4XO1UpivDd4zii9euB_jgdXEw_nzz9bqfLNYotGnEHrVjKA@mail.gmail.com>

Thanks! that worked, making progress now.

There was a compilation failure: HHH-9783

and Eclipse project import is broken again, I'll use IntelliJ this
weekend. Infinispan tests fail.. I'll ignore that.

Cheers,
Sanne

On 9 May 2015 at 14:27, Steve Ebersole <steve at hibernate.org> wrote:
> It is the dsl-extension branch.  But like I said, you should just be able to
> find it from JBoss snapshot repo now.
>
> On Sat, May 9, 2015 at 8:24 AM, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> I updated my checkout to your fork, but there are no new commits
>> compared to Luca's fork. Maybe you need to push it? Or which branch is
>> it?
>>
>> Anyway it's not a blocker as I've changed my master branch to precede
>> your last OSGi changes.. I just won't be able to test it with latest
>> but that shouldn't be a problem.
>>
>> I'll have a look at CI; I don't know.. we had two slaves running out
>> of disk space, that's likely going to happen on all remaining slaves
>> soon if I don't rebuild them..
>>
>> On 9 May 2015 at 14:11, Steve Ebersole <steve at hibernate.org> wrote:
>> > Interesting... The ORM master CI builds stopped pulling changes and auto
>> > building.  Any idea why?
>> >
>> > On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >>
>> >> Sorry I forgot I had not yet integrated my newest work on that plugin
>> >> upstream.  Check out my fork of it and publish that locally :
>> >> git at github.com:sebersole/lb-gradle-plugins.git
>> >>
>> >> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero <sanne at hibernate.org>
>> >> wrote:
>> >>>
>> >>> Hi,
>> >>> I'm having some trouble to build a fresh checkout from master.
>> >>> The first attempt produced:
>> >>>
>> >>>  FAILURE: Build failed with an exception.
>> >>>
>> >>> * What went wrong:
>> >>> A problem occurred configuring root project 'hibernate-core-parent'.
>> >>> > Could not resolve all dependencies for configuration ':classpath'.
>> >>>    > Could not find
>> >>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
>> >>>
>> >>> So I checked out this plugin:
>> >>> https://github.com/lburgazzoli/lb-gradle-plugins , installed it
>> >>> locally.
>> >>>
>> >>> Now I get :
>> >>>
>> >>> FAILURE: Build failed with an exception.
>> >>>
>> >>> * Where:
>> >>> Build file
>> >>>
>> >>> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
>> >>> line: 109
>> >>>
>> >>> * What went wrong:
>> >>> A problem occurred evaluating project ':hibernate-osgi'.
>> >>> > Could not find method features() for arguments
>> >>> >
>> >>> > [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6]
>> >>> > on project ':hibernate-osgi'.
>> >>>
>> >>> Do I need to apply some patches to that plugin?
>> >>>
>> >>> thanks,
>> >>> Sanne
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Sat May  9 14:23:17 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 9 May 2015 13:23:17 -0500
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAFm4XO1UpivDd4zii9euB_jgdXEw_nzz9bqfLNYotGnEHrVjKA@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
	<CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>
	<CAFdSV9tQgP4nPFXEo7TDWzoGhPo5NLJK3rM_WcHMoevtHNyG7A@mail.gmail.com>
	<CAFm4XO1UpivDd4zii9euB_jgdXEw_nzz9bqfLNYotGnEHrVjKA@mail.gmail.com>
Message-ID: <CAFdSV9uWdMs=BUaqHxYNW-wtT-Qq7pbH8BKc=WhsfKvRLb2=Dw@mail.gmail.com>

I pretty routinely run into problems running the testsuite in infinispan.
Generally the failures are transient.  Just try running it again.  If it
fails the same again then we have a problem.

No idea about eclipse.  I don't use it, so it is impossible for me to
validate.  If you see issues let me know the specifics and we can fix them.
On May 9, 2015 10:06 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:

> Thanks! that worked, making progress now.
>
> There was a compilation failure: HHH-9783
>
> and Eclipse project import is broken again, I'll use IntelliJ this
> weekend. Infinispan tests fail.. I'll ignore that.
>
> Cheers,
> Sanne
>
> On 9 May 2015 at 14:27, Steve Ebersole <steve at hibernate.org> wrote:
> > It is the dsl-extension branch.  But like I said, you should just be
> able to
> > find it from JBoss snapshot repo now.
> >
> > On Sat, May 9, 2015 at 8:24 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> >>
> >> I updated my checkout to your fork, but there are no new commits
> >> compared to Luca's fork. Maybe you need to push it? Or which branch is
> >> it?
> >>
> >> Anyway it's not a blocker as I've changed my master branch to precede
> >> your last OSGi changes.. I just won't be able to test it with latest
> >> but that shouldn't be a problem.
> >>
> >> I'll have a look at CI; I don't know.. we had two slaves running out
> >> of disk space, that's likely going to happen on all remaining slaves
> >> soon if I don't rebuild them..
> >>
> >> On 9 May 2015 at 14:11, Steve Ebersole <steve at hibernate.org> wrote:
> >> > Interesting... The ORM master CI builds stopped pulling changes and
> auto
> >> > building.  Any idea why?
> >> >
> >> > On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole <steve at hibernate.org>
> >> > wrote:
> >> >>
> >> >> Sorry I forgot I had not yet integrated my newest work on that plugin
> >> >> upstream.  Check out my fork of it and publish that locally :
> >> >> git at github.com:sebersole/lb-gradle-plugins.git
> >> >>
> >> >> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero <sanne at hibernate.org
> >
> >> >> wrote:
> >> >>>
> >> >>> Hi,
> >> >>> I'm having some trouble to build a fresh checkout from master.
> >> >>> The first attempt produced:
> >> >>>
> >> >>>  FAILURE: Build failed with an exception.
> >> >>>
> >> >>> * What went wrong:
> >> >>> A problem occurred configuring root project 'hibernate-core-parent'.
> >> >>> > Could not resolve all dependencies for configuration ':classpath'.
> >> >>>    > Could not find
> >> >>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
> >> >>>
> >> >>> So I checked out this plugin:
> >> >>> https://github.com/lburgazzoli/lb-gradle-plugins , installed it
> >> >>> locally.
> >> >>>
> >> >>> Now I get :
> >> >>>
> >> >>> FAILURE: Build failed with an exception.
> >> >>>
> >> >>> * Where:
> >> >>> Build file
> >> >>>
> >> >>>
> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
> >> >>> line: 109
> >> >>>
> >> >>> * What went wrong:
> >> >>> A problem occurred evaluating project ':hibernate-osgi'.
> >> >>> > Could not find method features() for arguments
> >> >>> >
> >> >>> >
> [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6
> ]
> >> >>> > on project ':hibernate-osgi'.
> >> >>>
> >> >>> Do I need to apply some patches to that plugin?
> >> >>>
> >> >>> thanks,
> >> >>> Sanne
> >> >>> _______________________________________________
> >> >>> hibernate-dev mailing list
> >> >>> hibernate-dev at lists.jboss.org
> >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >>
> >> >>
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gbadner at redhat.com  Mon May 11 01:49:06 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 11 May 2015 01:49:06 -0400 (EDT)
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use Infinispan
	7.2.1.Final
In-Reply-To: <1292038035.15226462.1431321060545.JavaMail.zimbra@redhat.com>
Message-ID: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>

I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.

I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 7.1.0.Final:

1) https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
2) https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
(The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).

1) updated infinispan-configs.xml to use
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns="urn:infinispan:config:7.0"
        xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">

After 1) was cherry-picked, I was able to build and run tests successfully using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) using Infinispan 6.0.0.Final, there were lots of test failures due to problems configuring the cache:
        Caused by: org.hibernate.cache.CacheException
            Caused by: org.infinispan.commons.CacheConfigurationException
                Caused by: javax.xml.stream.XMLStreamException

I've attached the output from test org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.

Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 branch? Could an application have its own dependence on Infinispan 6.0.0.Final?

Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 7.2.1.Final: https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87. After rebuilding,  
org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase fails. I've attached the output for that test as well. 

Galder, HHH-9781 is still open. Is there more work to do on this? Am I missing some other commit that would fix the TimestampsRegionImplTestCase failure?

This commit (for HHH-9781) includes a change to use org.infinispan.commons.util.CloseableIterator, which does not appear to be in Infinispan 6.0.0.Final, so this would not be backward-compatible either.

Next I cherry-picked the commit for HHH-9776: https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5. TimestampsRegionImplTestCase still fails; there are no other failures.

Galder, HHH-9776 is still open. Is there more work to be done on that issue?

I've pushed this work to my fork for others to see: https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.

I've postponed creating a pull request and running the TCK until we resolve backward-compatibility requirements and the unit test failure. It's OK with me if someone wants to go ahead and run the TCK with what I have so far.

Regards,
Gail

From galder at redhat.com  Mon May 11 03:48:37 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 11 May 2015 09:48:37 +0200
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
Message-ID: <E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>

Hi Gail,

Thanks for looking into this.

For the scope of WF, the XML part is irrelevant since WF does its own configuration parsing, and hence there's no need to make any such changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x standalone, then yes, they need to adjust XML configuration.

The evict/clear issues that 7.2 brought up, and the incorrect element count can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We just need to apply the changes in a way that work regardless of whether 6.0 or 7.2 is used.

I'll work on that today.

Cheers,

> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
> 
> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
> 
> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 7.1.0.Final:
> 
> 1) https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
> 2) https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
> 
> 1) updated infinispan-configs.xml to use
> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>        xmlns="urn:infinispan:config:7.0"
>        xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
> 
> After 1) was cherry-picked, I was able to build and run tests successfully using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) using Infinispan 6.0.0.Final, there were lots of test failures due to problems configuring the cache:
>        Caused by: org.hibernate.cache.CacheException
>            Caused by: org.infinispan.commons.CacheConfigurationException
>                Caused by: javax.xml.stream.XMLStreamException
> 
> I've attached the output from test org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
> 
> Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 branch? Could an application have its own dependence on Infinispan 6.0.0.Final?
> 
> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 7.2.1.Final: https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87. After rebuilding,  
> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase fails. I've attached the output for that test as well. 
> 
> Galder, HHH-9781 is still open. Is there more work to do on this? Am I missing some other commit that would fix the TimestampsRegionImplTestCase failure?
> 
> This commit (for HHH-9781) includes a change to use org.infinispan.commons.util.CloseableIterator, which does not appear to be in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
> 
> Next I cherry-picked the commit for HHH-9776: https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5. TimestampsRegionImplTestCase still fails; there are no other failures.
> 
> Galder, HHH-9776 is still open. Is there more work to be done on that issue?
> 
> I've pushed this work to my fork for others to see: https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
> 
> I've postponed creating a pull request and running the TCK until we resolve backward-compatibility requirements and the unit test failure. It's OK with me if someone wants to go ahead and run the TCK with what I have so far.
> 
> Regards,
> Gail
> <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>


--
Galder Zamarre?o
galder at redhat.com






From gunnar at hibernate.org  Mon May 11 03:58:18 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 11 May 2015 09:58:18 +0200
Subject: [hibernate-dev] Forum down
Message-ID: <CADGJaX-vN7wV=LLeC3AcaFJAhiLB7PUFZzYkv2TsQ9dS5S6OgA@mail.gmail.com>

Hi,

Accessing https://forum.hibernate.org/ gives me an error:

    SQL ERROR [ mysql4 ]
    Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2) [2002]

Could someone with the right credentials take a look into this?

Thanks,

--Gunnar

From galder at redhat.com  Mon May 11 04:31:07 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 11 May 2015 10:31:07 +0200
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>
Message-ID: <CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>

Hi Gail,

I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it works fine with both Infinispan 7.x and 6.x:
https://github.com/hibernate/hibernate-orm/pull/948

Cheers,

> On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com> wrote:
> 
> Hi Gail,
> 
> Thanks for looking into this.
> 
> For the scope of WF, the XML part is irrelevant since WF does its own configuration parsing, and hence there's no need to make any such changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x standalone, then yes, they need to adjust XML configuration.
> 
> The evict/clear issues that 7.2 brought up, and the incorrect element count can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We just need to apply the changes in a way that work regardless of whether 6.0 or 7.2 is used.
> 
> I'll work on that today.
> 
> Cheers,
> 
>> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
>> 
>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
>> 
>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 7.1.0.Final:
>> 
>> 1) https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
>> 2) https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
>> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
>> 
>> 1) updated infinispan-configs.xml to use
>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>       xmlns="urn:infinispan:config:7.0"
>>       xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
>> 
>> After 1) was cherry-picked, I was able to build and run tests successfully using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) using Infinispan 6.0.0.Final, there were lots of test failures due to problems configuring the cache:
>>       Caused by: org.hibernate.cache.CacheException
>>           Caused by: org.infinispan.commons.CacheConfigurationException
>>               Caused by: javax.xml.stream.XMLStreamException
>> 
>> I've attached the output from test org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
>> 
>> Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 branch? Could an application have its own dependence on Infinispan 6.0.0.Final?
>> 
>> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 7.2.1.Final: https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87. After rebuilding,  
>> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase fails. I've attached the output for that test as well. 
>> 
>> Galder, HHH-9781 is still open. Is there more work to do on this? Am I missing some other commit that would fix the TimestampsRegionImplTestCase failure?
>> 
>> This commit (for HHH-9781) includes a change to use org.infinispan.commons.util.CloseableIterator, which does not appear to be in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
>> 
>> Next I cherry-picked the commit for HHH-9776: https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5. TimestampsRegionImplTestCase still fails; there are no other failures.
>> 
>> Galder, HHH-9776 is still open. Is there more work to be done on that issue?
>> 
>> I've pushed this work to my fork for others to see: https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
>> 
>> I've postponed creating a pull request and running the TCK until we resolve backward-compatibility requirements and the unit test failure. It's OK with me if someone wants to go ahead and run the TCK with what I have so far.
>> 
>> Regards,
>> Gail
>> <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
> 
> 
> --
> Galder Zamarre?o
> galder at redhat.com
> 
> 
> 
> 


--
Galder Zamarre?o
galder at redhat.com






From gbadner at redhat.com  Mon May 11 05:00:08 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 11 May 2015 05:00:08 -0400 (EDT)
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>
	<CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
Message-ID: <85114432.15345448.1431334808562.JavaMail.zimbra@redhat.com>

Hi Galder,

I'm not thinking too well atm (it's 2am) and really need to get to sleep. 

If someone else wants to look it over, push, and get the standalone TCK started, please feel free. Otherwise, I will pick this up first thing tomorrow.

Thanks for the pull request!

Gail
----- Original Message -----
> From: "Galder Zamarre?o" <galder at redhat.com>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Galder Zamarreno" <gzamarre at redhat.com>, "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow"
> <smarlow at redhat.com>, "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, May 11, 2015 1:31:07 AM
> Subject: Re: Problems upgrading ORM 4.3 branch to use Infinispan 7.2.1.Final
> 
> Hi Gail,
> 
> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it works
> fine with both Infinispan 7.x and 6.x:
> https://github.com/hibernate/hibernate-orm/pull/948
> 
> Cheers,
> 
> > On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com> wrote:
> > 
> > Hi Gail,
> > 
> > Thanks for looking into this.
> > 
> > For the scope of WF, the XML part is irrelevant since WF does its own
> > configuration parsing, and hence there's no need to make any such changes
> > in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x
> > standalone, then yes, they need to adjust XML configuration.
> > 
> > The evict/clear issues that 7.2 brought up, and the incorrect element count
> > can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We
> > just need to apply the changes in a way that work regardless of whether
> > 6.0 or 7.2 is used.
> > 
> > I'll work on that today.
> > 
> > Cheers,
> > 
> >> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
> >> 
> >> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
> >> 
> >> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use
> >> Infinispan 7.1.0.Final:
> >> 
> >> 1)
> >> https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
> >> 2)
> >> https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
> >> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26)
> >> appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
> >> 
> >> 1) updated infinispan-configs.xml to use
> >> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>       xmlns="urn:infinispan:config:7.0"
> >>       xsi:schemaLocation="urn:infinispan:config:7.0
> >>       http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
> >> 
> >> After 1) was cherry-picked, I was able to build and run tests successfully
> >> using Infinispan 7.1.0.Final. When I tried running tests (without
> >> cleaning) using Infinispan 6.0.0.Final, there were lots of test failures
> >> due to problems configuring the cache:
> >>       Caused by: org.hibernate.cache.CacheException
> >>           Caused by: org.infinispan.commons.CacheConfigurationException
> >>               Caused by: javax.xml.stream.XMLStreamException
> >> 
> >> I've attached the output from test
> >> org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
> >> 
> >> Do we need to continue to support running Infinispan 6.0.0.Final in ORM
> >> 4.3 branch? Could an application have its own dependence on Infinispan
> >> 6.0.0.Final?
> >> 
> >> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to
> >> 7.2.1.Final:
> >> https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87.
> >> After rebuilding,
> >> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase
> >> fails. I've attached the output for that test as well.
> >> 
> >> Galder, HHH-9781 is still open. Is there more work to do on this? Am I
> >> missing some other commit that would fix the TimestampsRegionImplTestCase
> >> failure?
> >> 
> >> This commit (for HHH-9781) includes a change to use
> >> org.infinispan.commons.util.CloseableIterator, which does not appear to
> >> be in Infinispan 6.0.0.Final, so this would not be backward-compatible
> >> either.
> >> 
> >> Next I cherry-picked the commit for HHH-9776:
> >> https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5.
> >> TimestampsRegionImplTestCase still fails; there are no other failures.
> >> 
> >> Galder, HHH-9776 is still open. Is there more work to be done on that
> >> issue?
> >> 
> >> I've pushed this work to my fork for others to see:
> >> https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
> >> 
> >> I've postponed creating a pull request and running the TCK until we
> >> resolve backward-compatibility requirements and the unit test failure.
> >> It's OK with me if someone wants to go ahead and run the TCK with what I
> >> have so far.
> >> 
> >> Regards,
> >> Gail
> >> <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
> > 
> > 
> > --
> > Galder Zamarre?o
> > galder at redhat.com
> > 
> > 
> > 
> > 
> 
> 
> --
> Galder Zamarre?o
> galder at redhat.com
> 
> 
> 
> 
> 


From sanne at hibernate.org  Mon May 11 06:55:25 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 11 May 2015 11:55:25 +0100
Subject: [hibernate-dev] Hibernate OGM: Multi-Tenancy?
Message-ID: <CAFm4XO2wtNPCUmGKs3eJ_jDO=v6mAJqZgb8NfN26QZiDWypQ7Q@mail.gmail.com>

As I'm upgrading the Hibernate OGM -> Hibernate Search integration,
the new Search SPI explicitly demands a tenant-id on work
construction.

I suspect more work will be needed for multi-tenancy (at least some
tests) so I've opened OGM-821.

Might not be too complex? I suspect query results already respect the
restrictions.

I don't think multi-tenancy should be a very high priority for OGM,
but if this could pave the road to multiple-storage (different kinds)
.. now that would be really interesting.

Sanne

From dreborier at gmail.com  Mon May 11 09:37:31 2015
From: dreborier at gmail.com (andrea boriero)
Date: Mon, 11 May 2015 14:37:31 +0100
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAFdSV9uWdMs=BUaqHxYNW-wtT-Qq7pbH8BKc=WhsfKvRLb2=Dw@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
	<CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>
	<CAFdSV9tQgP4nPFXEo7TDWzoGhPo5NLJK3rM_WcHMoevtHNyG7A@mail.gmail.com>
	<CAFm4XO1UpivDd4zii9euB_jgdXEw_nzz9bqfLNYotGnEHrVjKA@mail.gmail.com>
	<CAFdSV9uWdMs=BUaqHxYNW-wtT-Qq7pbH8BKc=WhsfKvRLb2=Dw@mail.gmail.com>
Message-ID: <CAL00eSQ65d88xALmo4QvEagQaVZu7jVizXgQ4iQMy35=SbWK5w@mail.gmail.com>

I have spotted the problem and I'm fixing the infinispan tests.

On 9 May 2015 at 19:23, Steve Ebersole <steve at hibernate.org> wrote:

> I pretty routinely run into problems running the testsuite in infinispan.
> Generally the failures are transient.  Just try running it again.  If it
> fails the same again then we have a problem.
>
> No idea about eclipse.  I don't use it, so it is impossible for me to
> validate.  If you see issues let me know the specifics and we can fix them.
> On May 9, 2015 10:06 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:
>
> > Thanks! that worked, making progress now.
> >
> > There was a compilation failure: HHH-9783
> >
> > and Eclipse project import is broken again, I'll use IntelliJ this
> > weekend. Infinispan tests fail.. I'll ignore that.
> >
> > Cheers,
> > Sanne
> >
> > On 9 May 2015 at 14:27, Steve Ebersole <steve at hibernate.org> wrote:
> > > It is the dsl-extension branch.  But like I said, you should just be
> > able to
> > > find it from JBoss snapshot repo now.
> > >
> > > On Sat, May 9, 2015 at 8:24 AM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> > >>
> > >> I updated my checkout to your fork, but there are no new commits
> > >> compared to Luca's fork. Maybe you need to push it? Or which branch is
> > >> it?
> > >>
> > >> Anyway it's not a blocker as I've changed my master branch to precede
> > >> your last OSGi changes.. I just won't be able to test it with latest
> > >> but that shouldn't be a problem.
> > >>
> > >> I'll have a look at CI; I don't know.. we had two slaves running out
> > >> of disk space, that's likely going to happen on all remaining slaves
> > >> soon if I don't rebuild them..
> > >>
> > >> On 9 May 2015 at 14:11, Steve Ebersole <steve at hibernate.org> wrote:
> > >> > Interesting... The ORM master CI builds stopped pulling changes and
> > auto
> > >> > building.  Any idea why?
> > >> >
> > >> > On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole <steve at hibernate.org
> >
> > >> > wrote:
> > >> >>
> > >> >> Sorry I forgot I had not yet integrated my newest work on that
> plugin
> > >> >> upstream.  Check out my fork of it and publish that locally :
> > >> >> git at github.com:sebersole/lb-gradle-plugins.git
> > >> >>
> > >> >> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero <
> sanne at hibernate.org
> > >
> > >> >> wrote:
> > >> >>>
> > >> >>> Hi,
> > >> >>> I'm having some trouble to build a fresh checkout from master.
> > >> >>> The first attempt produced:
> > >> >>>
> > >> >>>  FAILURE: Build failed with an exception.
> > >> >>>
> > >> >>> * What went wrong:
> > >> >>> A problem occurred configuring root project
> 'hibernate-core-parent'.
> > >> >>> > Could not resolve all dependencies for configuration
> ':classpath'.
> > >> >>>    > Could not find
> > >> >>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
> > >> >>>
> > >> >>> So I checked out this plugin:
> > >> >>> https://github.com/lburgazzoli/lb-gradle-plugins , installed it
> > >> >>> locally.
> > >> >>>
> > >> >>> Now I get :
> > >> >>>
> > >> >>> FAILURE: Build failed with an exception.
> > >> >>>
> > >> >>> * Where:
> > >> >>> Build file
> > >> >>>
> > >> >>>
> >
> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
> > >> >>> line: 109
> > >> >>>
> > >> >>> * What went wrong:
> > >> >>> A problem occurred evaluating project ':hibernate-osgi'.
> > >> >>> > Could not find method features() for arguments
> > >> >>> >
> > >> >>> >
> >
> [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6
> > ]
> > >> >>> > on project ':hibernate-osgi'.
> > >> >>>
> > >> >>> Do I need to apply some patches to that plugin?
> > >> >>>
> > >> >>> thanks,
> > >> >>> Sanne
> > >> >>> _______________________________________________
> > >> >>> hibernate-dev mailing list
> > >> >>> hibernate-dev at lists.jboss.org
> > >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >>
> > >> >>
> > >> >
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon May 11 09:45:17 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 11 May 2015 14:45:17 +0100
Subject: [hibernate-dev] Two Hibernate Search releases: 5.3.0.Beta1 and
	5.2.0.Final
Message-ID: <CAFm4XO1VRW0jLqaC9ArxfJ2drjO+3u1T4XjtXZ3OnsT6K9EWsg@mail.gmail.com>

Today we announce two Hibernate Search releases, apologies for the
delay since these were available last week already but we had some
issues with the release platform.

Version 5.3.0.Beta1 includes some great improvements with Faceting:
 - http://in.relation.to/Bloggers/HibernateSearch530Beta1WithNativeLuceneFaceting

We also released our current "stable" branch 5.2.0.Final
to make our improved multi-tenancy integration generally available:
 - http://in.relation.to/Bloggers/HibernateSearch520FinalBringsFullMultitenancySupport

Sanne

From sanne at hibernate.org  Mon May 11 09:54:13 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 11 May 2015 14:54:13 +0100
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAL00eSQ65d88xALmo4QvEagQaVZu7jVizXgQ4iQMy35=SbWK5w@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
	<CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>
	<CAFdSV9tQgP4nPFXEo7TDWzoGhPo5NLJK3rM_WcHMoevtHNyG7A@mail.gmail.com>
	<CAFm4XO1UpivDd4zii9euB_jgdXEw_nzz9bqfLNYotGnEHrVjKA@mail.gmail.com>
	<CAFdSV9uWdMs=BUaqHxYNW-wtT-Qq7pbH8BKc=WhsfKvRLb2=Dw@mail.gmail.com>
	<CAL00eSQ65d88xALmo4QvEagQaVZu7jVizXgQ4iQMy35=SbWK5w@mail.gmail.com>
Message-ID: <CAFm4XO3LonJL4Z3m7A-QgLQsHH123Pnpd7McMA7SrbXmeRN_xA@mail.gmail.com>

Hi Andrea,
that's great but make sure you work with Galder, he's currently
looking at related things I think. Or at least he should review your
changes.

Sanne

On 11 May 2015 at 14:37, andrea boriero <dreborier at gmail.com> wrote:
> I have spotted the problem and I'm fixing the infinispan tests.
>
> On 9 May 2015 at 19:23, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> I pretty routinely run into problems running the testsuite in infinispan.
>> Generally the failures are transient.  Just try running it again.  If it
>> fails the same again then we have a problem.
>>
>> No idea about eclipse.  I don't use it, so it is impossible for me to
>> validate.  If you see issues let me know the specifics and we can fix
>> them.
>> On May 9, 2015 10:06 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:
>>
>> > Thanks! that worked, making progress now.
>> >
>> > There was a compilation failure: HHH-9783
>> >
>> > and Eclipse project import is broken again, I'll use IntelliJ this
>> > weekend. Infinispan tests fail.. I'll ignore that.
>> >
>> > Cheers,
>> > Sanne
>> >
>> > On 9 May 2015 at 14:27, Steve Ebersole <steve at hibernate.org> wrote:
>> > > It is the dsl-extension branch.  But like I said, you should just be
>> > able to
>> > > find it from JBoss snapshot repo now.
>> > >
>> > > On Sat, May 9, 2015 at 8:24 AM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> > >>
>> > >> I updated my checkout to your fork, but there are no new commits
>> > >> compared to Luca's fork. Maybe you need to push it? Or which branch
>> > >> is
>> > >> it?
>> > >>
>> > >> Anyway it's not a blocker as I've changed my master branch to precede
>> > >> your last OSGi changes.. I just won't be able to test it with latest
>> > >> but that shouldn't be a problem.
>> > >>
>> > >> I'll have a look at CI; I don't know.. we had two slaves running out
>> > >> of disk space, that's likely going to happen on all remaining slaves
>> > >> soon if I don't rebuild them..
>> > >>
>> > >> On 9 May 2015 at 14:11, Steve Ebersole <steve at hibernate.org> wrote:
>> > >> > Interesting... The ORM master CI builds stopped pulling changes and
>> > auto
>> > >> > building.  Any idea why?
>> > >> >
>> > >> > On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole
>> > >> > <steve at hibernate.org>
>> > >> > wrote:
>> > >> >>
>> > >> >> Sorry I forgot I had not yet integrated my newest work on that
>> > >> >> plugin
>> > >> >> upstream.  Check out my fork of it and publish that locally :
>> > >> >> git at github.com:sebersole/lb-gradle-plugins.git
>> > >> >>
>> > >> >> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero
>> > >> >> <sanne at hibernate.org
>> > >
>> > >> >> wrote:
>> > >> >>>
>> > >> >>> Hi,
>> > >> >>> I'm having some trouble to build a fresh checkout from master.
>> > >> >>> The first attempt produced:
>> > >> >>>
>> > >> >>>  FAILURE: Build failed with an exception.
>> > >> >>>
>> > >> >>> * What went wrong:
>> > >> >>> A problem occurred configuring root project
>> > >> >>> 'hibernate-core-parent'.
>> > >> >>> > Could not resolve all dependencies for configuration
>> > >> >>> > ':classpath'.
>> > >> >>>    > Could not find
>> > >> >>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
>> > >> >>>
>> > >> >>> So I checked out this plugin:
>> > >> >>> https://github.com/lburgazzoli/lb-gradle-plugins , installed it
>> > >> >>> locally.
>> > >> >>>
>> > >> >>> Now I get :
>> > >> >>>
>> > >> >>> FAILURE: Build failed with an exception.
>> > >> >>>
>> > >> >>> * Where:
>> > >> >>> Build file
>> > >> >>>
>> > >> >>>
>> >
>> > '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
>> > >> >>> line: 109
>> > >> >>>
>> > >> >>> * What went wrong:
>> > >> >>> A problem occurred evaluating project ':hibernate-osgi'.
>> > >> >>> > Could not find method features() for arguments
>> > >> >>> >
>> > >> >>> >
>> >
>> > [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6
>> > ]
>> > >> >>> > on project ':hibernate-osgi'.
>> > >> >>>
>> > >> >>> Do I need to apply some patches to that plugin?
>> > >> >>>
>> > >> >>> thanks,
>> > >> >>> Sanne
>> > >> >>> _______________________________________________
>> > >> >>> hibernate-dev mailing list
>> > >> >>> hibernate-dev at lists.jboss.org
>> > >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >> >>
>> > >> >>
>> > >> >
>> > >> _______________________________________________
>> > >> hibernate-dev mailing list
>> > >> hibernate-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >
>> > >
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From andrea at hibernate.org  Mon May 11 10:00:32 2015
From: andrea at hibernate.org (andrea boriero)
Date: Mon, 11 May 2015 15:00:32 +0100
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAFm4XO3LonJL4Z3m7A-QgLQsHH123Pnpd7McMA7SrbXmeRN_xA@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
	<CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>
	<CAFdSV9tQgP4nPFXEo7TDWzoGhPo5NLJK3rM_WcHMoevtHNyG7A@mail.gmail.com>
	<CAFm4XO1UpivDd4zii9euB_jgdXEw_nzz9bqfLNYotGnEHrVjKA@mail.gmail.com>
	<CAFdSV9uWdMs=BUaqHxYNW-wtT-Qq7pbH8BKc=WhsfKvRLb2=Dw@mail.gmail.com>
	<CAL00eSQ65d88xALmo4QvEagQaVZu7jVizXgQ4iQMy35=SbWK5w@mail.gmail.com>
	<CAFm4XO3LonJL4Z3m7A-QgLQsHH123Pnpd7McMA7SrbXmeRN_xA@mail.gmail.com>
Message-ID: <CAL00eSTJ3KhEMh_a-nAq8ZW-3LE+FMebz_WHZmEi-StKNHGaZQ@mail.gmail.com>

Hi Sanne,

the problem seems related to a change made to
JtaTransactionCorrdinatorImp#afterCompletion() so I don't think has any
relation with Galder work,
anyway in case I'll submit a pull request :)

On 11 May 2015 at 14:54, Sanne Grinovero <sanne at hibernate.org> wrote:

> Hi Andrea,
> that's great but make sure you work with Galder, he's currently
> looking at related things I think. Or at least he should review your
> changes.
>
> Sanne
>
> On 11 May 2015 at 14:37, andrea boriero <dreborier at gmail.com> wrote:
> > I have spotted the problem and I'm fixing the infinispan tests.
> >
> > On 9 May 2015 at 19:23, Steve Ebersole <steve at hibernate.org> wrote:
> >>
> >> I pretty routinely run into problems running the testsuite in
> infinispan.
> >> Generally the failures are transient.  Just try running it again.  If it
> >> fails the same again then we have a problem.
> >>
> >> No idea about eclipse.  I don't use it, so it is impossible for me to
> >> validate.  If you see issues let me know the specifics and we can fix
> >> them.
> >> On May 9, 2015 10:06 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:
> >>
> >> > Thanks! that worked, making progress now.
> >> >
> >> > There was a compilation failure: HHH-9783
> >> >
> >> > and Eclipse project import is broken again, I'll use IntelliJ this
> >> > weekend. Infinispan tests fail.. I'll ignore that.
> >> >
> >> > Cheers,
> >> > Sanne
> >> >
> >> > On 9 May 2015 at 14:27, Steve Ebersole <steve at hibernate.org> wrote:
> >> > > It is the dsl-extension branch.  But like I said, you should just be
> >> > able to
> >> > > find it from JBoss snapshot repo now.
> >> > >
> >> > > On Sat, May 9, 2015 at 8:24 AM, Sanne Grinovero <
> sanne at hibernate.org>
> >> > wrote:
> >> > >>
> >> > >> I updated my checkout to your fork, but there are no new commits
> >> > >> compared to Luca's fork. Maybe you need to push it? Or which branch
> >> > >> is
> >> > >> it?
> >> > >>
> >> > >> Anyway it's not a blocker as I've changed my master branch to
> precede
> >> > >> your last OSGi changes.. I just won't be able to test it with
> latest
> >> > >> but that shouldn't be a problem.
> >> > >>
> >> > >> I'll have a look at CI; I don't know.. we had two slaves running
> out
> >> > >> of disk space, that's likely going to happen on all remaining
> slaves
> >> > >> soon if I don't rebuild them..
> >> > >>
> >> > >> On 9 May 2015 at 14:11, Steve Ebersole <steve at hibernate.org>
> wrote:
> >> > >> > Interesting... The ORM master CI builds stopped pulling changes
> and
> >> > auto
> >> > >> > building.  Any idea why?
> >> > >> >
> >> > >> > On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole
> >> > >> > <steve at hibernate.org>
> >> > >> > wrote:
> >> > >> >>
> >> > >> >> Sorry I forgot I had not yet integrated my newest work on that
> >> > >> >> plugin
> >> > >> >> upstream.  Check out my fork of it and publish that locally :
> >> > >> >> git at github.com:sebersole/lb-gradle-plugins.git
> >> > >> >>
> >> > >> >> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero
> >> > >> >> <sanne at hibernate.org
> >> > >
> >> > >> >> wrote:
> >> > >> >>>
> >> > >> >>> Hi,
> >> > >> >>> I'm having some trouble to build a fresh checkout from master.
> >> > >> >>> The first attempt produced:
> >> > >> >>>
> >> > >> >>>  FAILURE: Build failed with an exception.
> >> > >> >>>
> >> > >> >>> * What went wrong:
> >> > >> >>> A problem occurred configuring root project
> >> > >> >>> 'hibernate-core-parent'.
> >> > >> >>> > Could not resolve all dependencies for configuration
> >> > >> >>> > ':classpath'.
> >> > >> >>>    > Could not find
> >> > >> >>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
> >> > >> >>>
> >> > >> >>> So I checked out this plugin:
> >> > >> >>> https://github.com/lburgazzoli/lb-gradle-plugins , installed
> it
> >> > >> >>> locally.
> >> > >> >>>
> >> > >> >>> Now I get :
> >> > >> >>>
> >> > >> >>> FAILURE: Build failed with an exception.
> >> > >> >>>
> >> > >> >>> * Where:
> >> > >> >>> Build file
> >> > >> >>>
> >> > >> >>>
> >> >
> >> >
> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
> >> > >> >>> line: 109
> >> > >> >>>
> >> > >> >>> * What went wrong:
> >> > >> >>> A problem occurred evaluating project ':hibernate-osgi'.
> >> > >> >>> > Could not find method features() for arguments
> >> > >> >>> >
> >> > >> >>> >
> >> >
> >> >
> [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6
> >> > ]
> >> > >> >>> > on project ':hibernate-osgi'.
> >> > >> >>>
> >> > >> >>> Do I need to apply some patches to that plugin?
> >> > >> >>>
> >> > >> >>> thanks,
> >> > >> >>> Sanne
> >> > >> >>> _______________________________________________
> >> > >> >>> hibernate-dev mailing list
> >> > >> >>> hibernate-dev at lists.jboss.org
> >> > >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >> >>
> >> > >> >>
> >> > >> >
> >> > >> _______________________________________________
> >> > >> hibernate-dev mailing list
> >> > >> hibernate-dev at lists.jboss.org
> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > >
> >> > >
> >> > _______________________________________________
> >> > hibernate-dev mailing list
> >> > hibernate-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> >
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From steve at hibernate.org  Mon May 11 10:18:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 11 May 2015 09:18:27 -0500
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAL00eSTJ3KhEMh_a-nAq8ZW-3LE+FMebz_WHZmEi-StKNHGaZQ@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
	<CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>
	<CAFdSV9tQgP4nPFXEo7TDWzoGhPo5NLJK3rM_WcHMoevtHNyG7A@mail.gmail.com>
	<CAFm4XO1UpivDd4zii9euB_jgdXEw_nzz9bqfLNYotGnEHrVjKA@mail.gmail.com>
	<CAFdSV9uWdMs=BUaqHxYNW-wtT-Qq7pbH8BKc=WhsfKvRLb2=Dw@mail.gmail.com>
	<CAL00eSQ65d88xALmo4QvEagQaVZu7jVizXgQ4iQMy35=SbWK5w@mail.gmail.com>
	<CAFm4XO3LonJL4Z3m7A-QgLQsHH123Pnpd7McMA7SrbXmeRN_xA@mail.gmail.com>
	<CAL00eSTJ3KhEMh_a-nAq8ZW-3LE+FMebz_WHZmEi-StKNHGaZQ@mail.gmail.com>
Message-ID: <CAFdSV9tGHho4FRwRGaJeAMeTd-YKoDkrsmpVp2CjCyc6Pmkq9Q@mail.gmail.com>

Yes please.  I would like to look over the change as well
On May 11, 2015 9:01 AM, "andrea boriero" <andrea at hibernate.org> wrote:

> Hi Sanne,
>
> the problem seems related to a change made to
> JtaTransactionCorrdinatorImp#afterCompletion() so I don't think has any
> relation with Galder work,
> anyway in case I'll submit a pull request :)
>
> On 11 May 2015 at 14:54, Sanne Grinovero <sanne at hibernate.org> wrote:
>
> > Hi Andrea,
> > that's great but make sure you work with Galder, he's currently
> > looking at related things I think. Or at least he should review your
> > changes.
> >
> > Sanne
> >
> > On 11 May 2015 at 14:37, andrea boriero <dreborier at gmail.com> wrote:
> > > I have spotted the problem and I'm fixing the infinispan tests.
> > >
> > > On 9 May 2015 at 19:23, Steve Ebersole <steve at hibernate.org> wrote:
> > >>
> > >> I pretty routinely run into problems running the testsuite in
> > infinispan.
> > >> Generally the failures are transient.  Just try running it again.  If
> it
> > >> fails the same again then we have a problem.
> > >>
> > >> No idea about eclipse.  I don't use it, so it is impossible for me to
> > >> validate.  If you see issues let me know the specifics and we can fix
> > >> them.
> > >> On May 9, 2015 10:06 AM, "Sanne Grinovero" <sanne at hibernate.org>
> wrote:
> > >>
> > >> > Thanks! that worked, making progress now.
> > >> >
> > >> > There was a compilation failure: HHH-9783
> > >> >
> > >> > and Eclipse project import is broken again, I'll use IntelliJ this
> > >> > weekend. Infinispan tests fail.. I'll ignore that.
> > >> >
> > >> > Cheers,
> > >> > Sanne
> > >> >
> > >> > On 9 May 2015 at 14:27, Steve Ebersole <steve at hibernate.org> wrote:
> > >> > > It is the dsl-extension branch.  But like I said, you should just
> be
> > >> > able to
> > >> > > find it from JBoss snapshot repo now.
> > >> > >
> > >> > > On Sat, May 9, 2015 at 8:24 AM, Sanne Grinovero <
> > sanne at hibernate.org>
> > >> > wrote:
> > >> > >>
> > >> > >> I updated my checkout to your fork, but there are no new commits
> > >> > >> compared to Luca's fork. Maybe you need to push it? Or which
> branch
> > >> > >> is
> > >> > >> it?
> > >> > >>
> > >> > >> Anyway it's not a blocker as I've changed my master branch to
> > precede
> > >> > >> your last OSGi changes.. I just won't be able to test it with
> > latest
> > >> > >> but that shouldn't be a problem.
> > >> > >>
> > >> > >> I'll have a look at CI; I don't know.. we had two slaves running
> > out
> > >> > >> of disk space, that's likely going to happen on all remaining
> > slaves
> > >> > >> soon if I don't rebuild them..
> > >> > >>
> > >> > >> On 9 May 2015 at 14:11, Steve Ebersole <steve at hibernate.org>
> > wrote:
> > >> > >> > Interesting... The ORM master CI builds stopped pulling changes
> > and
> > >> > auto
> > >> > >> > building.  Any idea why?
> > >> > >> >
> > >> > >> > On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole
> > >> > >> > <steve at hibernate.org>
> > >> > >> > wrote:
> > >> > >> >>
> > >> > >> >> Sorry I forgot I had not yet integrated my newest work on that
> > >> > >> >> plugin
> > >> > >> >> upstream.  Check out my fork of it and publish that locally :
> > >> > >> >> git at github.com:sebersole/lb-gradle-plugins.git
> > >> > >> >>
> > >> > >> >> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero
> > >> > >> >> <sanne at hibernate.org
> > >> > >
> > >> > >> >> wrote:
> > >> > >> >>>
> > >> > >> >>> Hi,
> > >> > >> >>> I'm having some trouble to build a fresh checkout from
> master.
> > >> > >> >>> The first attempt produced:
> > >> > >> >>>
> > >> > >> >>>  FAILURE: Build failed with an exception.
> > >> > >> >>>
> > >> > >> >>> * What went wrong:
> > >> > >> >>> A problem occurred configuring root project
> > >> > >> >>> 'hibernate-core-parent'.
> > >> > >> >>> > Could not resolve all dependencies for configuration
> > >> > >> >>> > ':classpath'.
> > >> > >> >>>    > Could not find
> > >> > >> >>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
> > >> > >> >>>
> > >> > >> >>> So I checked out this plugin:
> > >> > >> >>> https://github.com/lburgazzoli/lb-gradle-plugins , installed
> > it
> > >> > >> >>> locally.
> > >> > >> >>>
> > >> > >> >>> Now I get :
> > >> > >> >>>
> > >> > >> >>> FAILURE: Build failed with an exception.
> > >> > >> >>>
> > >> > >> >>> * Where:
> > >> > >> >>> Build file
> > >> > >> >>>
> > >> > >> >>>
> > >> >
> > >> >
> >
> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
> > >> > >> >>> line: 109
> > >> > >> >>>
> > >> > >> >>> * What went wrong:
> > >> > >> >>> A problem occurred evaluating project ':hibernate-osgi'.
> > >> > >> >>> > Could not find method features() for arguments
> > >> > >> >>> >
> > >> > >> >>> >
> > >> >
> > >> >
> >
> [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6
> > >> > ]
> > >> > >> >>> > on project ':hibernate-osgi'.
> > >> > >> >>>
> > >> > >> >>> Do I need to apply some patches to that plugin?
> > >> > >> >>>
> > >> > >> >>> thanks,
> > >> > >> >>> Sanne
> > >> > >> >>> _______________________________________________
> > >> > >> >>> hibernate-dev mailing list
> > >> > >> >>> hibernate-dev at lists.jboss.org
> > >> > >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> > >> >>
> > >> > >> >>
> > >> > >> >
> > >> > >> _______________________________________________
> > >> > >> hibernate-dev mailing list
> > >> > >> hibernate-dev at lists.jboss.org
> > >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> > >
> > >> > >
> > >> > _______________________________________________
> > >> > hibernate-dev mailing list
> > >> > hibernate-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >> >
> > >> _______________________________________________
> > >> hibernate-dev mailing list
> > >> hibernate-dev at lists.jboss.org
> > >> https://lists.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 May 11 10:34:42 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 11 May 2015 15:34:42 +0100
Subject: [hibernate-dev] How to build Hibernate ORM / master ?
In-Reply-To: <CAL00eSTJ3KhEMh_a-nAq8ZW-3LE+FMebz_WHZmEi-StKNHGaZQ@mail.gmail.com>
References: <CAFm4XO2jsdY70KSn_=W_hbaWowOdq1vSJ223XQkR-SinvBUwJw@mail.gmail.com>
	<CAFdSV9vrCbq2VikzAO0Fjv=k03P-3xJgs4WTdmrpMPJ8GkBkiA@mail.gmail.com>
	<CAFdSV9vosS49Wqp+ooynOgBt7wwRX8YqDGrKWsCnmRV9qzdJ1Q@mail.gmail.com>
	<CAFm4XO16Vv_AGo8FgTmtF=26c8YZZy4vGyb46b2V+ynohtbXKQ@mail.gmail.com>
	<CAFdSV9tQgP4nPFXEo7TDWzoGhPo5NLJK3rM_WcHMoevtHNyG7A@mail.gmail.com>
	<CAFm4XO1UpivDd4zii9euB_jgdXEw_nzz9bqfLNYotGnEHrVjKA@mail.gmail.com>
	<CAFdSV9uWdMs=BUaqHxYNW-wtT-Qq7pbH8BKc=WhsfKvRLb2=Dw@mail.gmail.com>
	<CAL00eSQ65d88xALmo4QvEagQaVZu7jVizXgQ4iQMy35=SbWK5w@mail.gmail.com>
	<CAFm4XO3LonJL4Z3m7A-QgLQsHH123Pnpd7McMA7SrbXmeRN_xA@mail.gmail.com>
	<CAL00eSTJ3KhEMh_a-nAq8ZW-3LE+FMebz_WHZmEi-StKNHGaZQ@mail.gmail.com>
Message-ID: <CAFm4XO2sg5fQ+YDOQeMD-GUZYwth-DZ4RaRd5eOs0FFzB7u6cA@mail.gmail.com>

Ok, still good to let him know so we don't waste his time ;)

On 11 May 2015 at 15:00, andrea boriero <andrea at hibernate.org> wrote:
> Hi Sanne,
>
> the problem seems related to a change made to
> JtaTransactionCorrdinatorImp#afterCompletion() so I don't think has any
> relation with Galder work,
> anyway in case I'll submit a pull request :)
>
> On 11 May 2015 at 14:54, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Hi Andrea,
>> that's great but make sure you work with Galder, he's currently
>> looking at related things I think. Or at least he should review your
>> changes.
>>
>> Sanne
>>
>> On 11 May 2015 at 14:37, andrea boriero <dreborier at gmail.com> wrote:
>> > I have spotted the problem and I'm fixing the infinispan tests.
>> >
>> > On 9 May 2015 at 19:23, Steve Ebersole <steve at hibernate.org> wrote:
>> >>
>> >> I pretty routinely run into problems running the testsuite in
>> >> infinispan.
>> >> Generally the failures are transient.  Just try running it again.  If
>> >> it
>> >> fails the same again then we have a problem.
>> >>
>> >> No idea about eclipse.  I don't use it, so it is impossible for me to
>> >> validate.  If you see issues let me know the specifics and we can fix
>> >> them.
>> >> On May 9, 2015 10:06 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:
>> >>
>> >> > Thanks! that worked, making progress now.
>> >> >
>> >> > There was a compilation failure: HHH-9783
>> >> >
>> >> > and Eclipse project import is broken again, I'll use IntelliJ this
>> >> > weekend. Infinispan tests fail.. I'll ignore that.
>> >> >
>> >> > Cheers,
>> >> > Sanne
>> >> >
>> >> > On 9 May 2015 at 14:27, Steve Ebersole <steve at hibernate.org> wrote:
>> >> > > It is the dsl-extension branch.  But like I said, you should just
>> >> > > be
>> >> > able to
>> >> > > find it from JBoss snapshot repo now.
>> >> > >
>> >> > > On Sat, May 9, 2015 at 8:24 AM, Sanne Grinovero
>> >> > > <sanne at hibernate.org>
>> >> > wrote:
>> >> > >>
>> >> > >> I updated my checkout to your fork, but there are no new commits
>> >> > >> compared to Luca's fork. Maybe you need to push it? Or which
>> >> > >> branch
>> >> > >> is
>> >> > >> it?
>> >> > >>
>> >> > >> Anyway it's not a blocker as I've changed my master branch to
>> >> > >> precede
>> >> > >> your last OSGi changes.. I just won't be able to test it with
>> >> > >> latest
>> >> > >> but that shouldn't be a problem.
>> >> > >>
>> >> > >> I'll have a look at CI; I don't know.. we had two slaves running
>> >> > >> out
>> >> > >> of disk space, that's likely going to happen on all remaining
>> >> > >> slaves
>> >> > >> soon if I don't rebuild them..
>> >> > >>
>> >> > >> On 9 May 2015 at 14:11, Steve Ebersole <steve at hibernate.org>
>> >> > >> wrote:
>> >> > >> > Interesting... The ORM master CI builds stopped pulling changes
>> >> > >> > and
>> >> > auto
>> >> > >> > building.  Any idea why?
>> >> > >> >
>> >> > >> > On Sat, May 9, 2015 at 8:09 AM, Steve Ebersole
>> >> > >> > <steve at hibernate.org>
>> >> > >> > wrote:
>> >> > >> >>
>> >> > >> >> Sorry I forgot I had not yet integrated my newest work on that
>> >> > >> >> plugin
>> >> > >> >> upstream.  Check out my fork of it and publish that locally :
>> >> > >> >> git at github.com:sebersole/lb-gradle-plugins.git
>> >> > >> >>
>> >> > >> >> On Sat, May 9, 2015 at 5:17 AM, Sanne Grinovero
>> >> > >> >> <sanne at hibernate.org
>> >> > >
>> >> > >> >> wrote:
>> >> > >> >>>
>> >> > >> >>> Hi,
>> >> > >> >>> I'm having some trouble to build a fresh checkout from master.
>> >> > >> >>> The first attempt produced:
>> >> > >> >>>
>> >> > >> >>>  FAILURE: Build failed with an exception.
>> >> > >> >>>
>> >> > >> >>> * What went wrong:
>> >> > >> >>> A problem occurred configuring root project
>> >> > >> >>> 'hibernate-core-parent'.
>> >> > >> >>> > Could not resolve all dependencies for configuration
>> >> > >> >>> > ':classpath'.
>> >> > >> >>>    > Could not find
>> >> > >> >>> com.github.lburgazzoli:lb-karaf-features-gen:1.0.0.SNAPSHOT.
>> >> > >> >>>
>> >> > >> >>> So I checked out this plugin:
>> >> > >> >>> https://github.com/lburgazzoli/lb-gradle-plugins , installed
>> >> > >> >>> it
>> >> > >> >>> locally.
>> >> > >> >>>
>> >> > >> >>> Now I get :
>> >> > >> >>>
>> >> > >> >>> FAILURE: Build failed with an exception.
>> >> > >> >>>
>> >> > >> >>> * Where:
>> >> > >> >>> Build file
>> >> > >> >>>
>> >> > >> >>>
>> >> >
>> >> >
>> >> > '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/hibernate-osgi.gradle'
>> >> > >> >>> line: 109
>> >> > >> >>>
>> >> > >> >>> * What went wrong:
>> >> > >> >>> A problem occurred evaluating project ':hibernate-osgi'.
>> >> > >> >>> > Could not find method features() for arguments
>> >> > >> >>> >
>> >> > >> >>> >
>> >> >
>> >> >
>> >> > [hibernate_osgi_8b1jmrdt2yykus6805h9qfv3i$_run_closure8_closure18 at 705dc1a6
>> >> > ]
>> >> > >> >>> > on project ':hibernate-osgi'.
>> >> > >> >>>
>> >> > >> >>> Do I need to apply some patches to that plugin?
>> >> > >> >>>
>> >> > >> >>> thanks,
>> >> > >> >>> Sanne
>> >> > >> >>> _______________________________________________
>> >> > >> >>> hibernate-dev mailing list
>> >> > >> >>> hibernate-dev at lists.jboss.org
>> >> > >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > >> >>
>> >> > >> >>
>> >> > >> >
>> >> > >> _______________________________________________
>> >> > >> hibernate-dev mailing list
>> >> > >> hibernate-dev at lists.jboss.org
>> >> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> > >
>> >> > >
>> >> > _______________________________________________
>> >> > hibernate-dev mailing list
>> >> > hibernate-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >> >
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>
>

From smarlow at redhat.com  Mon May 11 10:45:33 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Mon, 11 May 2015 10:45:33 -0400
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>
	<CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
Message-ID: <5550C08D.4070204@redhat.com>

Do we need to have a Hibernate ORM continuous integration test setup to 
run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or 
is ORM/Infinispan already tested as part of the Infinispan CI testing?

On 05/11/2015 04:31 AM, Galder Zamarre?o wrote:
> Hi Gail,
>
> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it works fine with both Infinispan 7.x and 6.x:
> https://github.com/hibernate/hibernate-orm/pull/948
>
> Cheers,
>
>> On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com> wrote:
>>
>> Hi Gail,
>>
>> Thanks for looking into this.
>>
>> For the scope of WF, the XML part is irrelevant since WF does its own configuration parsing, and hence there's no need to make any such changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x standalone, then yes, they need to adjust XML configuration.
>>
>> The evict/clear issues that 7.2 brought up, and the incorrect element count can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We just need to apply the changes in a way that work regardless of whether 6.0 or 7.2 is used.
>>
>> I'll work on that today.
>>
>> Cheers,
>>
>>> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
>>>
>>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
>>>
>>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 7.1.0.Final:
>>>
>>> 1) https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
>>> 2) https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
>>> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
>>>
>>> 1) updated infinispan-configs.xml to use
>>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>        xmlns="urn:infinispan:config:7.0"
>>>        xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
>>>
>>> After 1) was cherry-picked, I was able to build and run tests successfully using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) using Infinispan 6.0.0.Final, there were lots of test failures due to problems configuring the cache:
>>>        Caused by: org.hibernate.cache.CacheException
>>>            Caused by: org.infinispan.commons.CacheConfigurationException
>>>                Caused by: javax.xml.stream.XMLStreamException
>>>
>>> I've attached the output from test org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
>>>
>>> Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 branch? Could an application have its own dependence on Infinispan 6.0.0.Final?
>>>
>>> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 7.2.1.Final: https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87. After rebuilding,
>>> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase fails. I've attached the output for that test as well.
>>>
>>> Galder, HHH-9781 is still open. Is there more work to do on this? Am I missing some other commit that would fix the TimestampsRegionImplTestCase failure?
>>>
>>> This commit (for HHH-9781) includes a change to use org.infinispan.commons.util.CloseableIterator, which does not appear to be in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
>>>
>>> Next I cherry-picked the commit for HHH-9776: https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5. TimestampsRegionImplTestCase still fails; there are no other failures.
>>>
>>> Galder, HHH-9776 is still open. Is there more work to be done on that issue?
>>>
>>> I've pushed this work to my fork for others to see: https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
>>>
>>> I've postponed creating a pull request and running the TCK until we resolve backward-compatibility requirements and the unit test failure. It's OK with me if someone wants to go ahead and run the TCK with what I have so far.
>>>
>>> Regards,
>>> Gail
>>> <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
>>
>>
>> --
>> Galder Zamarre?o
>> galder at redhat.com
>>
>>
>>
>>
>
>
> --
> Galder Zamarre?o
> galder at redhat.com
>
>
>
>

From galder at redhat.com  Mon May 11 11:23:34 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 11 May 2015 17:23:34 +0200
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <5550C08D.4070204@redhat.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>
	<CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
	<5550C08D.4070204@redhat.com>
Message-ID: <14A500D5-9652-43C5-8240-6E13A346DB6E@redhat.com>


> On 11 May 2015, at 16:45, Scott Marlow <smarlow at redhat.com> wrote:
> 
> Do we need to have a Hibernate ORM continuous integration test setup to run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or is ORM/Infinispan already tested as part of the Infinispan CI testing?

In this particular case, as mentioned below, running ORM 4.3 testsuite with Infinispan 7.2.1 would mostly fail because of XML changes. Again, this does not affect WF, so it would not really help you much.

We do have some tests in Infinispan CI to test integration with HB but need some updates [1].

Cheers,

[1] http://ci.infinispan.org/project.html?projectId=HibernateIntegration

> 
> On 05/11/2015 04:31 AM, Galder Zamarre?o wrote:
>> Hi Gail,
>> 
>> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it works fine with both Infinispan 7.x and 6.x:
>> https://github.com/hibernate/hibernate-orm/pull/948
>> 
>> Cheers,
>> 
>>> On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com> wrote:
>>> 
>>> Hi Gail,
>>> 
>>> Thanks for looking into this.
>>> 
>>> For the scope of WF, the XML part is irrelevant since WF does its own configuration parsing, and hence there's no need to make any such changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x standalone, then yes, they need to adjust XML configuration.
>>> 
>>> The evict/clear issues that 7.2 brought up, and the incorrect element count can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We just need to apply the changes in a way that work regardless of whether 6.0 or 7.2 is used.
>>> 
>>> I'll work on that today.
>>> 
>>> Cheers,
>>> 
>>>> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
>>>> 
>>>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
>>>> 
>>>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 7.1.0.Final:
>>>> 
>>>> 1) https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
>>>> 2) https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
>>>> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
>>>> 
>>>> 1) updated infinispan-configs.xml to use
>>>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>       xmlns="urn:infinispan:config:7.0"
>>>>       xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
>>>> 
>>>> After 1) was cherry-picked, I was able to build and run tests successfully using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) using Infinispan 6.0.0.Final, there were lots of test failures due to problems configuring the cache:
>>>>       Caused by: org.hibernate.cache.CacheException
>>>>           Caused by: org.infinispan.commons.CacheConfigurationException
>>>>               Caused by: javax.xml.stream.XMLStreamException
>>>> 
>>>> I've attached the output from test org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
>>>> 
>>>> Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 branch? Could an application have its own dependence on Infinispan 6.0.0.Final?
>>>> 
>>>> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 7.2.1.Final: https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87. After rebuilding,
>>>> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase fails. I've attached the output for that test as well.
>>>> 
>>>> Galder, HHH-9781 is still open. Is there more work to do on this? Am I missing some other commit that would fix the TimestampsRegionImplTestCase failure?
>>>> 
>>>> This commit (for HHH-9781) includes a change to use org.infinispan.commons.util.CloseableIterator, which does not appear to be in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
>>>> 
>>>> Next I cherry-picked the commit for HHH-9776: https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5. TimestampsRegionImplTestCase still fails; there are no other failures.
>>>> 
>>>> Galder, HHH-9776 is still open. Is there more work to be done on that issue?
>>>> 
>>>> I've pushed this work to my fork for others to see: https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
>>>> 
>>>> I've postponed creating a pull request and running the TCK until we resolve backward-compatibility requirements and the unit test failure. It's OK with me if someone wants to go ahead and run the TCK with what I have so far.
>>>> 
>>>> Regards,
>>>> Gail
>>>> <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
>>> 
>>> 
>>> --
>>> Galder Zamarre?o
>>> galder at redhat.com
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Galder Zamarre?o
>> galder at redhat.com
>> 
>> 
>> 
>> 


--
Galder Zamarre?o
galder at redhat.com






From sanne at hibernate.org  Mon May 11 11:26:52 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 11 May 2015 16:26:52 +0100
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <14A500D5-9652-43C5-8240-6E13A346DB6E@redhat.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>
	<CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
	<5550C08D.4070204@redhat.com>
	<14A500D5-9652-43C5-8240-6E13A346DB6E@redhat.com>
Message-ID: <CAFm4XO0n3vLq8Zi5eq9HsKz4nuHdW5ysWRPbwP68n8hhfXhGwg@mail.gmail.com>

Any reason to not upgrade Hibernate ORM 4.3 to use Infinispan 7.2.1.Final ?
Was Infinispan 6 friendly to JDK 6 users?

On 11 May 2015 at 16:23, Galder Zamarre?o <galder at redhat.com> wrote:
>
>> On 11 May 2015, at 16:45, Scott Marlow <smarlow at redhat.com> wrote:
>>
>> Do we need to have a Hibernate ORM continuous integration test setup to run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or is ORM/Infinispan already tested as part of the Infinispan CI testing?
>
> In this particular case, as mentioned below, running ORM 4.3 testsuite with Infinispan 7.2.1 would mostly fail because of XML changes. Again, this does not affect WF, so it would not really help you much.
>
> We do have some tests in Infinispan CI to test integration with HB but need some updates [1].
>
> Cheers,
>
> [1] http://ci.infinispan.org/project.html?projectId=HibernateIntegration
>
>>
>> On 05/11/2015 04:31 AM, Galder Zamarre?o wrote:
>>> Hi Gail,
>>>
>>> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it works fine with both Infinispan 7.x and 6.x:
>>> https://github.com/hibernate/hibernate-orm/pull/948
>>>
>>> Cheers,
>>>
>>>> On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com> wrote:
>>>>
>>>> Hi Gail,
>>>>
>>>> Thanks for looking into this.
>>>>
>>>> For the scope of WF, the XML part is irrelevant since WF does its own configuration parsing, and hence there's no need to make any such changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x standalone, then yes, they need to adjust XML configuration.
>>>>
>>>> The evict/clear issues that 7.2 brought up, and the incorrect element count can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We just need to apply the changes in a way that work regardless of whether 6.0 or 7.2 is used.
>>>>
>>>> I'll work on that today.
>>>>
>>>> Cheers,
>>>>
>>>>> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
>>>>>
>>>>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
>>>>>
>>>>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 7.1.0.Final:
>>>>>
>>>>> 1) https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
>>>>> 2) https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
>>>>> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
>>>>>
>>>>> 1) updated infinispan-configs.xml to use
>>>>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>       xmlns="urn:infinispan:config:7.0"
>>>>>       xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
>>>>>
>>>>> After 1) was cherry-picked, I was able to build and run tests successfully using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) using Infinispan 6.0.0.Final, there were lots of test failures due to problems configuring the cache:
>>>>>       Caused by: org.hibernate.cache.CacheException
>>>>>           Caused by: org.infinispan.commons.CacheConfigurationException
>>>>>               Caused by: javax.xml.stream.XMLStreamException
>>>>>
>>>>> I've attached the output from test org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
>>>>>
>>>>> Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 branch? Could an application have its own dependence on Infinispan 6.0.0.Final?
>>>>>
>>>>> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 7.2.1.Final: https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87. After rebuilding,
>>>>> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase fails. I've attached the output for that test as well.
>>>>>
>>>>> Galder, HHH-9781 is still open. Is there more work to do on this? Am I missing some other commit that would fix the TimestampsRegionImplTestCase failure?
>>>>>
>>>>> This commit (for HHH-9781) includes a change to use org.infinispan.commons.util.CloseableIterator, which does not appear to be in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
>>>>>
>>>>> Next I cherry-picked the commit for HHH-9776: https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5. TimestampsRegionImplTestCase still fails; there are no other failures.
>>>>>
>>>>> Galder, HHH-9776 is still open. Is there more work to be done on that issue?
>>>>>
>>>>> I've pushed this work to my fork for others to see: https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
>>>>>
>>>>> I've postponed creating a pull request and running the TCK until we resolve backward-compatibility requirements and the unit test failure. It's OK with me if someone wants to go ahead and run the TCK with what I have so far.
>>>>>
>>>>> Regards,
>>>>> Gail
>>>>> <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
>>>>
>>>>
>>>> --
>>>> Galder Zamarre?o
>>>> galder at redhat.com
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Galder Zamarre?o
>>> galder at redhat.com
>>>
>>>
>>>
>>>
>
>
> --
> Galder Zamarre?o
> galder at redhat.com
>
>
>
>


From galder at redhat.com  Mon May 11 11:35:08 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 11 May 2015 17:35:08 +0200
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <CAFm4XO0n3vLq8Zi5eq9HsKz4nuHdW5ysWRPbwP68n8hhfXhGwg@mail.gmail.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>
	<CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
	<5550C08D.4070204@redhat.com>
	<14A500D5-9652-43C5-8240-6E13A346DB6E@redhat.com>
	<CAFm4XO0n3vLq8Zi5eq9HsKz4nuHdW5ysWRPbwP68n8hhfXhGwg@mail.gmail.com>
Message-ID: <01306178-CC63-4DD9-8DAA-6B574886D9CB@redhat.com>


> On 11 May 2015, at 17:26, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> Any reason to not upgrade Hibernate ORM 4.3 to use Infinispan 7.2.1.Final ?
> Was Infinispan 6 friendly to JDK 6 users?

Yup, Infinispan 6 requires JDK 6, and Infinispan 7 requires JDK7.

Also, on top of JDK changes, not sure it'd be a good idea to make a dependency update of that magnitude in a bug fix release, since it'd change the Infinispan version used, and you'd break all the standalone 4.3 users that have tweaked Infinispan configuration, they'd have to move to the more WF/AS-like XML configuration. Those using default would be fine since we could tweak the default configuration.

Cheers,

> 
> On 11 May 2015 at 16:23, Galder Zamarre?o <galder at redhat.com> wrote:
>> 
>>> On 11 May 2015, at 16:45, Scott Marlow <smarlow at redhat.com> wrote:
>>> 
>>> Do we need to have a Hibernate ORM continuous integration test setup to run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or is ORM/Infinispan already tested as part of the Infinispan CI testing?
>> 
>> In this particular case, as mentioned below, running ORM 4.3 testsuite with Infinispan 7.2.1 would mostly fail because of XML changes. Again, this does not affect WF, so it would not really help you much.
>> 
>> We do have some tests in Infinispan CI to test integration with HB but need some updates [1].
>> 
>> Cheers,
>> 
>> [1] http://ci.infinispan.org/project.html?projectId=HibernateIntegration
>> 
>>> 
>>> On 05/11/2015 04:31 AM, Galder Zamarre?o wrote:
>>>> Hi Gail,
>>>> 
>>>> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it works fine with both Infinispan 7.x and 6.x:
>>>> https://github.com/hibernate/hibernate-orm/pull/948
>>>> 
>>>> Cheers,
>>>> 
>>>>> On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com> wrote:
>>>>> 
>>>>> Hi Gail,
>>>>> 
>>>>> Thanks for looking into this.
>>>>> 
>>>>> For the scope of WF, the XML part is irrelevant since WF does its own configuration parsing, and hence there's no need to make any such changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x standalone, then yes, they need to adjust XML configuration.
>>>>> 
>>>>> The evict/clear issues that 7.2 brought up, and the incorrect element count can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We just need to apply the changes in a way that work regardless of whether 6.0 or 7.2 is used.
>>>>> 
>>>>> I'll work on that today.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>>> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
>>>>>> 
>>>>>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
>>>>>> 
>>>>>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 7.1.0.Final:
>>>>>> 
>>>>>> 1) https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
>>>>>> 2) https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
>>>>>> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
>>>>>> 
>>>>>> 1) updated infinispan-configs.xml to use
>>>>>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>      xmlns="urn:infinispan:config:7.0"
>>>>>>      xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
>>>>>> 
>>>>>> After 1) was cherry-picked, I was able to build and run tests successfully using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) using Infinispan 6.0.0.Final, there were lots of test failures due to problems configuring the cache:
>>>>>>      Caused by: org.hibernate.cache.CacheException
>>>>>>          Caused by: org.infinispan.commons.CacheConfigurationException
>>>>>>              Caused by: javax.xml.stream.XMLStreamException
>>>>>> 
>>>>>> I've attached the output from test org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
>>>>>> 
>>>>>> Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 branch? Could an application have its own dependence on Infinispan 6.0.0.Final?
>>>>>> 
>>>>>> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 7.2.1.Final: https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87. After rebuilding,
>>>>>> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase fails. I've attached the output for that test as well.
>>>>>> 
>>>>>> Galder, HHH-9781 is still open. Is there more work to do on this? Am I missing some other commit that would fix the TimestampsRegionImplTestCase failure?
>>>>>> 
>>>>>> This commit (for HHH-9781) includes a change to use org.infinispan.commons.util.CloseableIterator, which does not appear to be in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
>>>>>> 
>>>>>> Next I cherry-picked the commit for HHH-9776: https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5. TimestampsRegionImplTestCase still fails; there are no other failures.
>>>>>> 
>>>>>> Galder, HHH-9776 is still open. Is there more work to be done on that issue?
>>>>>> 
>>>>>> I've pushed this work to my fork for others to see: https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
>>>>>> 
>>>>>> I've postponed creating a pull request and running the TCK until we resolve backward-compatibility requirements and the unit test failure. It's OK with me if someone wants to go ahead and run the TCK with what I have so far.
>>>>>> 
>>>>>> Regards,
>>>>>> Gail
>>>>>> <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
>>>>> 
>>>>> 
>>>>> --
>>>>> Galder Zamarre?o
>>>>> galder at redhat.com
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Galder Zamarre?o
>>>> galder at redhat.com
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>> --
>> Galder Zamarre?o
>> galder at redhat.com
>> 
>> 
>> 
>> 


--
Galder Zamarre?o
galder at redhat.com






From sanne at hibernate.org  Mon May 11 11:52:50 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 11 May 2015 16:52:50 +0100
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <01306178-CC63-4DD9-8DAA-6B574886D9CB@redhat.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>
	<CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
	<5550C08D.4070204@redhat.com>
	<14A500D5-9652-43C5-8240-6E13A346DB6E@redhat.com>
	<CAFm4XO0n3vLq8Zi5eq9HsKz4nuHdW5ysWRPbwP68n8hhfXhGwg@mail.gmail.com>
	<01306178-CC63-4DD9-8DAA-6B574886D9CB@redhat.com>
Message-ID: <CAFm4XO3e4+T9f3w183kTkBBsOhJDT8ARwLpGqLEifmWTkk_K0w@mail.gmail.com>

On 11 May 2015 at 16:35, Galder Zamarre?o <galder at redhat.com> wrote:
>
>> On 11 May 2015, at 17:26, Sanne Grinovero <sanne at hibernate.org> wrote:
>>
>> Any reason to not upgrade Hibernate ORM 4.3 to use Infinispan 7.2.1.Final ?
>> Was Infinispan 6 friendly to JDK 6 users?
>
> Yup, Infinispan 6 requires JDK 6, and Infinispan 7 requires JDK7.
>
> Also, on top of JDK changes, not sure it'd be a good idea to make a dependency update of that magnitude in a bug fix release, since it'd change the Infinispan version used, and you'd break all the standalone 4.3 users that have tweaked Infinispan configuration, they'd have to move to the more WF/AS-like XML configuration. Those using default would be fine since we could tweak the default configuration.

Ok, many good reasons :)

But it's a worrying divergence between the catefory of users running
in WildFly and who doesn't. Also we'd want CI tests for both
Infinispan integrations, which is not trivial because of all the
changes in the Infinispan configuration format.

Should this be a 4.4.0 release?

Regarding the JDK, one could say that Java 7 is required when using
the Infinispan cache. This is something we'd need to document for
Hibernate ORM 5 anyway, might as well have it apply to a 4.4.

Thanks,
Sanne

>
> Cheers,
>
>>
>> On 11 May 2015 at 16:23, Galder Zamarre?o <galder at redhat.com> wrote:
>>>
>>>> On 11 May 2015, at 16:45, Scott Marlow <smarlow at redhat.com> wrote:
>>>>
>>>> Do we need to have a Hibernate ORM continuous integration test setup to run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or is ORM/Infinispan already tested as part of the Infinispan CI testing?
>>>
>>> In this particular case, as mentioned below, running ORM 4.3 testsuite with Infinispan 7.2.1 would mostly fail because of XML changes. Again, this does not affect WF, so it would not really help you much.
>>>
>>> We do have some tests in Infinispan CI to test integration with HB but need some updates [1].
>>>
>>> Cheers,
>>>
>>> [1] http://ci.infinispan.org/project.html?projectId=HibernateIntegration
>>>
>>>>
>>>> On 05/11/2015 04:31 AM, Galder Zamarre?o wrote:
>>>>> Hi Gail,
>>>>>
>>>>> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it works fine with both Infinispan 7.x and 6.x:
>>>>> https://github.com/hibernate/hibernate-orm/pull/948
>>>>>
>>>>> Cheers,
>>>>>
>>>>>> On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com> wrote:
>>>>>>
>>>>>> Hi Gail,
>>>>>>
>>>>>> Thanks for looking into this.
>>>>>>
>>>>>> For the scope of WF, the XML part is irrelevant since WF does its own configuration parsing, and hence there's no need to make any such changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x standalone, then yes, they need to adjust XML configuration.
>>>>>>
>>>>>> The evict/clear issues that 7.2 brought up, and the incorrect element count can be fixed in ORM 4.3 without the need to up the dependency to 7.2. We just need to apply the changes in a way that work regardless of whether 6.0 or 7.2 is used.
>>>>>>
>>>>>> I'll work on that today.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>>> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
>>>>>>>
>>>>>>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3 branch.
>>>>>>>
>>>>>>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use Infinispan 7.1.0.Final:
>>>>>>>
>>>>>>> 1) https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
>>>>>>> 2) https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
>>>>>>> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26) appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
>>>>>>>
>>>>>>> 1) updated infinispan-configs.xml to use
>>>>>>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>>>>>>      xmlns="urn:infinispan:config:7.0"
>>>>>>>      xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
>>>>>>>
>>>>>>> After 1) was cherry-picked, I was able to build and run tests successfully using Infinispan 7.1.0.Final. When I tried running tests (without cleaning) using Infinispan 6.0.0.Final, there were lots of test failures due to problems configuring the cache:
>>>>>>>      Caused by: org.hibernate.cache.CacheException
>>>>>>>          Caused by: org.infinispan.commons.CacheConfigurationException
>>>>>>>              Caused by: javax.xml.stream.XMLStreamException
>>>>>>>
>>>>>>> I've attached the output from test org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
>>>>>>>
>>>>>>> Do we need to continue to support running Infinispan 6.0.0.Final in ORM 4.3 branch? Could an application have its own dependence on Infinispan 6.0.0.Final?
>>>>>>>
>>>>>>> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan to 7.2.1.Final: https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87. After rebuilding,
>>>>>>> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase fails. I've attached the output for that test as well.
>>>>>>>
>>>>>>> Galder, HHH-9781 is still open. Is there more work to do on this? Am I missing some other commit that would fix the TimestampsRegionImplTestCase failure?
>>>>>>>
>>>>>>> This commit (for HHH-9781) includes a change to use org.infinispan.commons.util.CloseableIterator, which does not appear to be in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
>>>>>>>
>>>>>>> Next I cherry-picked the commit for HHH-9776: https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5. TimestampsRegionImplTestCase still fails; there are no other failures.
>>>>>>>
>>>>>>> Galder, HHH-9776 is still open. Is there more work to be done on that issue?
>>>>>>>
>>>>>>> I've pushed this work to my fork for others to see: https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
>>>>>>>
>>>>>>> I've postponed creating a pull request and running the TCK until we resolve backward-compatibility requirements and the unit test failure. It's OK with me if someone wants to go ahead and run the TCK with what I have so far.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Gail
>>>>>>> <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Galder Zamarre?o
>>>>>> galder at redhat.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Galder Zamarre?o
>>>>> galder at redhat.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Galder Zamarre?o
>>> galder at redhat.com
>>>
>>>
>>>
>>>
>
>
> --
> Galder Zamarre?o
> galder at redhat.com
>
>
>
>


From steve at hibernate.org  Mon May 11 12:14:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 11 May 2015 11:14:37 -0500
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <CAFm4XO3e4+T9f3w183kTkBBsOhJDT8ARwLpGqLEifmWTkk_K0w@mail.gmail.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<E3044AD8-FDD1-49BB-882D-20758A8BCFBA@redhat.com>
	<CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
	<5550C08D.4070204@redhat.com>
	<14A500D5-9652-43C5-8240-6E13A346DB6E@redhat.com>
	<CAFm4XO0n3vLq8Zi5eq9HsKz4nuHdW5ysWRPbwP68n8hhfXhGwg@mail.gmail.com>
	<01306178-CC63-4DD9-8DAA-6B574886D9CB@redhat.com>
	<CAFm4XO3e4+T9f3w183kTkBBsOhJDT8ARwLpGqLEifmWTkk_K0w@mail.gmail.com>
Message-ID: <CAFdSV9vMByMjsFH7au3vwdi_nmAwCZwis=TMeaz6SWV7mSoF5w@mail.gmail.com>

WRT 4.4, nooooooooooooooooo! :)

On Mon, May 11, 2015 at 10:52 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 11 May 2015 at 16:35, Galder Zamarre?o <galder at redhat.com> wrote:
> >
> >> On 11 May 2015, at 17:26, Sanne Grinovero <sanne at hibernate.org> wrote:
> >>
> >> Any reason to not upgrade Hibernate ORM 4.3 to use Infinispan
> 7.2.1.Final ?
> >> Was Infinispan 6 friendly to JDK 6 users?
> >
> > Yup, Infinispan 6 requires JDK 6, and Infinispan 7 requires JDK7.
> >
> > Also, on top of JDK changes, not sure it'd be a good idea to make a
> dependency update of that magnitude in a bug fix release, since it'd change
> the Infinispan version used, and you'd break all the standalone 4.3 users
> that have tweaked Infinispan configuration, they'd have to move to the more
> WF/AS-like XML configuration. Those using default would be fine since we
> could tweak the default configuration.
>
> Ok, many good reasons :)
>
> But it's a worrying divergence between the catefory of users running
> in WildFly and who doesn't. Also we'd want CI tests for both
> Infinispan integrations, which is not trivial because of all the
> changes in the Infinispan configuration format.
>
> Should this be a 4.4.0 release?
>
> Regarding the JDK, one could say that Java 7 is required when using
> the Infinispan cache. This is something we'd need to document for
> Hibernate ORM 5 anyway, might as well have it apply to a 4.4.
>
> Thanks,
> Sanne
>
> >
> > Cheers,
> >
> >>
> >> On 11 May 2015 at 16:23, Galder Zamarre?o <galder at redhat.com> wrote:
> >>>
> >>>> On 11 May 2015, at 16:45, Scott Marlow <smarlow at redhat.com> wrote:
> >>>>
> >>>> Do we need to have a Hibernate ORM continuous integration test setup
> to run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or
> is ORM/Infinispan already tested as part of the Infinispan CI testing?
> >>>
> >>> In this particular case, as mentioned below, running ORM 4.3 testsuite
> with Infinispan 7.2.1 would mostly fail because of XML changes. Again, this
> does not affect WF, so it would not really help you much.
> >>>
> >>> We do have some tests in Infinispan CI to test integration with HB but
> need some updates [1].
> >>>
> >>> Cheers,
> >>>
> >>> [1]
> http://ci.infinispan.org/project.html?projectId=HibernateIntegration
> >>>
> >>>>
> >>>> On 05/11/2015 04:31 AM, Galder Zamarre?o wrote:
> >>>>> Hi Gail,
> >>>>>
> >>>>> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it
> works fine with both Infinispan 7.x and 6.x:
> >>>>> https://github.com/hibernate/hibernate-orm/pull/948
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>>> On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com>
> wrote:
> >>>>>>
> >>>>>> Hi Gail,
> >>>>>>
> >>>>>> Thanks for looking into this.
> >>>>>>
> >>>>>> For the scope of WF, the XML part is irrelevant since WF does its
> own configuration parsing, and hence there's no need to make any such
> changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x
> standalone, then yes, they need to adjust XML configuration.
> >>>>>>
> >>>>>> The evict/clear issues that 7.2 brought up, and the incorrect
> element count can be fixed in ORM 4.3 without the need to up the dependency
> to 7.2. We just need to apply the changes in a way that work regardless of
> whether 6.0 or 7.2 is used.
> >>>>>>
> >>>>>> I'll work on that today.
> >>>>>>
> >>>>>> Cheers,
> >>>>>>
> >>>>>>> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
> >>>>>>>
> >>>>>>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3
> branch.
> >>>>>>>
> >>>>>>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use
> Infinispan 7.1.0.Final:
> >>>>>>>
> >>>>>>> 1)
> https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
> >>>>>>> 2)
> https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
> >>>>>>> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26)
> appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
> >>>>>>>
> >>>>>>> 1) updated infinispan-configs.xml to use
> >>>>>>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >>>>>>>      xmlns="urn:infinispan:config:7.0"
> >>>>>>>      xsi:schemaLocation="urn:infinispan:config:7.0
> http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
> >>>>>>>
> >>>>>>> After 1) was cherry-picked, I was able to build and run tests
> successfully using Infinispan 7.1.0.Final. When I tried running tests
> (without cleaning) using Infinispan 6.0.0.Final, there were lots of test
> failures due to problems configuring the cache:
> >>>>>>>      Caused by: org.hibernate.cache.CacheException
> >>>>>>>          Caused by:
> org.infinispan.commons.CacheConfigurationException
> >>>>>>>              Caused by: javax.xml.stream.XMLStreamException
> >>>>>>>
> >>>>>>> I've attached the output from test
> org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
> >>>>>>>
> >>>>>>> Do we need to continue to support running Infinispan 6.0.0.Final
> in ORM 4.3 branch? Could an application have its own dependence on
> Infinispan 6.0.0.Final?
> >>>>>>>
> >>>>>>> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan
> to 7.2.1.Final:
> https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87.
> After rebuilding,
> >>>>>>>
> org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase
> fails. I've attached the output for that test as well.
> >>>>>>>
> >>>>>>> Galder, HHH-9781 is still open. Is there more work to do on this?
> Am I missing some other commit that would fix the
> TimestampsRegionImplTestCase failure?
> >>>>>>>
> >>>>>>> This commit (for HHH-9781) includes a change to use
> org.infinispan.commons.util.CloseableIterator, which does not appear to be
> in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
> >>>>>>>
> >>>>>>> Next I cherry-picked the commit for HHH-9776:
> https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5.
> TimestampsRegionImplTestCase still fails; there are no other failures.
> >>>>>>>
> >>>>>>> Galder, HHH-9776 is still open. Is there more work to be done on
> that issue?
> >>>>>>>
> >>>>>>> I've pushed this work to my fork for others to see:
> https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
> >>>>>>>
> >>>>>>> I've postponed creating a pull request and running the TCK until
> we resolve backward-compatibility requirements and the unit test failure.
> It's OK with me if someone wants to go ahead and run the TCK with what I
> have so far.
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Gail
> >>>>>>>
> <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> Galder Zamarre?o
> >>>>>> galder at redhat.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Galder Zamarre?o
> >>>>> galder at redhat.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>> --
> >>> Galder Zamarre?o
> >>> galder at redhat.com
> >>>
> >>>
> >>>
> >>>
> >
> >
> > --
> > Galder Zamarre?o
> > galder at redhat.com
> >
> >
> >
> >
>

From gbadner at redhat.com  Mon May 11 16:23:04 2015
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 11 May 2015 16:23:04 -0400 (EDT)
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to use
	Infinispan 7.2.1.Final
In-Reply-To: <CAFdSV9vMByMjsFH7au3vwdi_nmAwCZwis=TMeaz6SWV7mSoF5w@mail.gmail.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<CF00E7D9-B842-4A3F-BF17-2523E7EAF148@redhat.com>
	<5550C08D.4070204@redhat.com>
	<14A500D5-9652-43C5-8240-6E13A346DB6E@redhat.com>
	<CAFm4XO0n3vLq8Zi5eq9HsKz4nuHdW5ysWRPbwP68n8hhfXhGwg@mail.gmail.com>
	<01306178-CC63-4DD9-8DAA-6B574886D9CB@redhat.com>
	<CAFm4XO3e4+T9f3w183kTkBBsOhJDT8ARwLpGqLEifmWTkk_K0w@mail.gmail.com>
	<CAFdSV9vMByMjsFH7au3vwdi_nmAwCZwis=TMeaz6SWV7mSoF5w@mail.gmail.com>
Message-ID: <683564741.15770823.1431375784174.JavaMail.zimbra@redhat.com>

Just to let you know, I'm working on the pull request. 

My plan is to:
- merge pull request (still need to review)
- re-build/test hibernate-infinispan using Infinispan 6.0.0.Final
- manually test hibernate-infinispan using Infinispan 7.2.1.Final [1]
- push commit and snapshot
- run standalone TCK using Hibernate 4.3 snapshot with Infinispan 6.0.0.Final
- run standalone TCK using Hibernate 4.3 snapshot with Infinispan 7.2.1.Final

If all goes well, release 4.3.10.Final. If not, I'll keep you posted.

[1] I'd like to change the gradle build so that hibernate-infinispan unit tests are executed twice; first time using Infinispan 6.0.0.Final; second time using 7.2.1.Final. I haven't done much with gradle, so if someone can tell me quickly how to do this, I'll get the gradle build change into 4.3.10.Final; otherwise, I'll get that build change into 4.3.11.Final.

Thanks,
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Sanne Grinovero" <sanne at hibernate.org>
> Cc: "Galder Zamarre?o" <galder at redhat.com>, "Scott Marlow" <smarlow at redhat.com>, "Gail Badner" <gbadner at redhat.com>,
> "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Monday, May 11, 2015 9:14:37 AM
> Subject: Re: Problems upgrading ORM 4.3 branch to use Infinispan 7.2.1.Final
> 
> WRT 4.4, nooooooooooooooooo! :)
> 
> On Mon, May 11, 2015 at 10:52 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> 
> > On 11 May 2015 at 16:35, Galder Zamarre?o <galder at redhat.com> wrote:
> > >
> > >> On 11 May 2015, at 17:26, Sanne Grinovero <sanne at hibernate.org> wrote:
> > >>
> > >> Any reason to not upgrade Hibernate ORM 4.3 to use Infinispan
> > 7.2.1.Final ?
> > >> Was Infinispan 6 friendly to JDK 6 users?
> > >
> > > Yup, Infinispan 6 requires JDK 6, and Infinispan 7 requires JDK7.
> > >
> > > Also, on top of JDK changes, not sure it'd be a good idea to make a
> > dependency update of that magnitude in a bug fix release, since it'd change
> > the Infinispan version used, and you'd break all the standalone 4.3 users
> > that have tweaked Infinispan configuration, they'd have to move to the more
> > WF/AS-like XML configuration. Those using default would be fine since we
> > could tweak the default configuration.
> >
> > Ok, many good reasons :)
> >
> > But it's a worrying divergence between the catefory of users running
> > in WildFly and who doesn't. Also we'd want CI tests for both
> > Infinispan integrations, which is not trivial because of all the
> > changes in the Infinispan configuration format.
> >
> > Should this be a 4.4.0 release?
> >
> > Regarding the JDK, one could say that Java 7 is required when using
> > the Infinispan cache. This is something we'd need to document for
> > Hibernate ORM 5 anyway, might as well have it apply to a 4.4.
> >
> > Thanks,
> > Sanne
> >
> > >
> > > Cheers,
> > >
> > >>
> > >> On 11 May 2015 at 16:23, Galder Zamarre?o <galder at redhat.com> wrote:
> > >>>
> > >>>> On 11 May 2015, at 16:45, Scott Marlow <smarlow at redhat.com> wrote:
> > >>>>
> > >>>> Do we need to have a Hibernate ORM continuous integration test setup
> > to run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or
> > is ORM/Infinispan already tested as part of the Infinispan CI testing?
> > >>>
> > >>> In this particular case, as mentioned below, running ORM 4.3 testsuite
> > with Infinispan 7.2.1 would mostly fail because of XML changes. Again, this
> > does not affect WF, so it would not really help you much.
> > >>>
> > >>> We do have some tests in Infinispan CI to test integration with HB but
> > need some updates [1].
> > >>>
> > >>> Cheers,
> > >>>
> > >>> [1]
> > http://ci.infinispan.org/project.html?projectId=HibernateIntegration
> > >>>
> > >>>>
> > >>>> On 05/11/2015 04:31 AM, Galder Zamarre?o wrote:
> > >>>>> Hi Gail,
> > >>>>>
> > >>>>> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that it
> > works fine with both Infinispan 7.x and 6.x:
> > >>>>> https://github.com/hibernate/hibernate-orm/pull/948
> > >>>>>
> > >>>>> Cheers,
> > >>>>>
> > >>>>>> On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com>
> > wrote:
> > >>>>>>
> > >>>>>> Hi Gail,
> > >>>>>>
> > >>>>>> Thanks for looking into this.
> > >>>>>>
> > >>>>>> For the scope of WF, the XML part is irrelevant since WF does its
> > own configuration parsing, and hence there's no need to make any such
> > changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x
> > standalone, then yes, they need to adjust XML configuration.
> > >>>>>>
> > >>>>>> The evict/clear issues that 7.2 brought up, and the incorrect
> > element count can be fixed in ORM 4.3 without the need to up the dependency
> > to 7.2. We just need to apply the changes in a way that work regardless of
> > whether 6.0 or 7.2 is used.
> > >>>>>>
> > >>>>>> I'll work on that today.
> > >>>>>>
> > >>>>>> Cheers,
> > >>>>>>
> > >>>>>>> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
> > >>>>>>>
> > >>>>>>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3
> > branch.
> > >>>>>>>
> > >>>>>>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use
> > Infinispan 7.1.0.Final:
> > >>>>>>>
> > >>>>>>> 1)
> > https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
> > >>>>>>> 2)
> > https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
> > >>>>>>> (The 3rd (merge) commit (2cff88cac76147ebb0da5bff8d3605c8a109fd26)
> > appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
> > >>>>>>>
> > >>>>>>> 1) updated infinispan-configs.xml to use
> > >>>>>>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > >>>>>>>      xmlns="urn:infinispan:config:7.0"
> > >>>>>>>      xsi:schemaLocation="urn:infinispan:config:7.0
> > http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
> > >>>>>>>
> > >>>>>>> After 1) was cherry-picked, I was able to build and run tests
> > successfully using Infinispan 7.1.0.Final. When I tried running tests
> > (without cleaning) using Infinispan 6.0.0.Final, there were lots of test
> > failures due to problems configuring the cache:
> > >>>>>>>      Caused by: org.hibernate.cache.CacheException
> > >>>>>>>          Caused by:
> > org.infinispan.commons.CacheConfigurationException
> > >>>>>>>              Caused by: javax.xml.stream.XMLStreamException
> > >>>>>>>
> > >>>>>>> I've attached the output from test
> > org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
> > >>>>>>>
> > >>>>>>> Do we need to continue to support running Infinispan 6.0.0.Final
> > in ORM 4.3 branch? Could an application have its own dependence on
> > Infinispan 6.0.0.Final?
> > >>>>>>>
> > >>>>>>> Next I cherry-picked the commit for HHH-9781 to upgrade Infinispan
> > to 7.2.1.Final:
> > https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87.
> > After rebuilding,
> > >>>>>>>
> > org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase
> > fails. I've attached the output for that test as well.
> > >>>>>>>
> > >>>>>>> Galder, HHH-9781 is still open. Is there more work to do on this?
> > Am I missing some other commit that would fix the
> > TimestampsRegionImplTestCase failure?
> > >>>>>>>
> > >>>>>>> This commit (for HHH-9781) includes a change to use
> > org.infinispan.commons.util.CloseableIterator, which does not appear to be
> > in Infinispan 6.0.0.Final, so this would not be backward-compatible either.
> > >>>>>>>
> > >>>>>>> Next I cherry-picked the commit for HHH-9776:
> > https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5.
> > TimestampsRegionImplTestCase still fails; there are no other failures.
> > >>>>>>>
> > >>>>>>> Galder, HHH-9776 is still open. Is there more work to be done on
> > that issue?
> > >>>>>>>
> > >>>>>>> I've pushed this work to my fork for others to see:
> > https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
> > >>>>>>>
> > >>>>>>> I've postponed creating a pull request and running the TCK until
> > we resolve backward-compatibility requirements and the unit test failure.
> > It's OK with me if someone wants to go ahead and run the TCK with what I
> > have so far.
> > >>>>>>>
> > >>>>>>> Regards,
> > >>>>>>> Gail
> > >>>>>>>
> > <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Galder Zamarre?o
> > >>>>>> galder at redhat.com
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>> Galder Zamarre?o
> > >>>>> galder at redhat.com
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >>> --
> > >>> Galder Zamarre?o
> > >>> galder at redhat.com
> > >>>
> > >>>
> > >>>
> > >>>
> > >
> > >
> > > --
> > > Galder Zamarre?o
> > > galder at redhat.com
> > >
> > >
> > >
> > >
> >
> 


From gbadner at redhat.com  Tue May 12 02:54:26 2015
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 12 May 2015 02:54:26 -0400 (EDT)
Subject: [hibernate-dev] Problems upgrading ORM 4.3 branch to
	use	Infinispan 7.2.1.Final
In-Reply-To: <683564741.15770823.1431375784174.JavaMail.zimbra@redhat.com>
References: <1647867628.15244269.1431323346753.JavaMail.zimbra@redhat.com>
	<5550C08D.4070204@redhat.com>
	<14A500D5-9652-43C5-8240-6E13A346DB6E@redhat.com>
	<CAFm4XO0n3vLq8Zi5eq9HsKz4nuHdW5ysWRPbwP68n8hhfXhGwg@mail.gmail.com>
	<01306178-CC63-4DD9-8DAA-6B574886D9CB@redhat.com>
	<CAFm4XO3e4+T9f3w183kTkBBsOhJDT8ARwLpGqLEifmWTkk_K0w@mail.gmail.com>
	<CAFdSV9vMByMjsFH7au3vwdi_nmAwCZwis=TMeaz6SWV7mSoF5w@mail.gmail.com>
	<683564741.15770823.1431375784174.JavaMail.zimbra@redhat.com>
Message-ID: <822056978.15949010.1431413666178.JavaMail.zimbra@redhat.com>

See below for status...

I could not figure out a way to re-run Hibernate tests using Infinispan 7.2.1.Final without rebuilding source code. I tried `gradle --no-rebuild` but it didn't seem to work. When the source code is rebuilt, there are lots of failures.

Anyone have ideas how to do this?

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>, "Galder Zamarre?o" <galder at redhat.com>
> Sent: Monday, May 11, 2015 1:23:04 PM
> Subject: Re: [hibernate-dev] Problems upgrading ORM 4.3 branch to use	Infinispan 7.2.1.Final
> 
> Just to let you know, I'm working on the pull request.
> 
> My plan is to:
> - merge pull request (done; also added updates to BulkOperationsTestCase for testing HHH-9781)
> - re-build/test hibernate-infinispan using Infinispan 6.0.0.Final (done)
> - manually test hibernate-infinispan using Infinispan 7.2.1.Final [1] (could not figure out how to do this)
> - push commit and snapshot (done)
> - run standalone TCK using Hibernate 4.3 snapshot with Infinispan 6.0.0.Final (in progress)
> - run standalone TCK using Hibernate 4.3 snapshot with Infinispan 7.2.1.Final (will work with Scott Marlow to do this Tuesday)
> 
> If all goes well, release 4.3.10.Final. If not, I'll keep you posted.
> 
> [1] I'd like to change the gradle build so that hibernate-infinispan unit
> tests are executed twice; first time using Infinispan 6.0.0.Final; second
> time using 7.2.1.Final. I haven't done much with gradle, so if someone can
> tell me quickly how to do this, I'll get the gradle build change into
> 4.3.10.Final; otherwise, I'll get that build change into 4.3.11.Final.
> 
> Thanks,
> Gail
> 
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "Sanne Grinovero" <sanne at hibernate.org>
> > Cc: "Galder Zamarre?o" <galder at redhat.com>, "Scott Marlow"
> > <smarlow at redhat.com>, "Gail Badner" <gbadner at redhat.com>,
> > "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > Sent: Monday, May 11, 2015 9:14:37 AM
> > Subject: Re: Problems upgrading ORM 4.3 branch to use Infinispan
> > 7.2.1.Final
> > 
> > WRT 4.4, nooooooooooooooooo! :)
> > 
> > On Mon, May 11, 2015 at 10:52 AM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> > 
> > > On 11 May 2015 at 16:35, Galder Zamarre?o <galder at redhat.com> wrote:
> > > >
> > > >> On 11 May 2015, at 17:26, Sanne Grinovero <sanne at hibernate.org> wrote:
> > > >>
> > > >> Any reason to not upgrade Hibernate ORM 4.3 to use Infinispan
> > > 7.2.1.Final ?
> > > >> Was Infinispan 6 friendly to JDK 6 users?
> > > >
> > > > Yup, Infinispan 6 requires JDK 6, and Infinispan 7 requires JDK7.
> > > >
> > > > Also, on top of JDK changes, not sure it'd be a good idea to make a
> > > dependency update of that magnitude in a bug fix release, since it'd
> > > change
> > > the Infinispan version used, and you'd break all the standalone 4.3 users
> > > that have tweaked Infinispan configuration, they'd have to move to the
> > > more
> > > WF/AS-like XML configuration. Those using default would be fine since we
> > > could tweak the default configuration.
> > >
> > > Ok, many good reasons :)
> > >
> > > But it's a worrying divergence between the catefory of users running
> > > in WildFly and who doesn't. Also we'd want CI tests for both
> > > Infinispan integrations, which is not trivial because of all the
> > > changes in the Infinispan configuration format.
> > >
> > > Should this be a 4.4.0 release?
> > >
> > > Regarding the JDK, one could say that Java 7 is required when using
> > > the Infinispan cache. This is something we'd need to document for
> > > Hibernate ORM 5 anyway, might as well have it apply to a 4.4.
> > >
> > > Thanks,
> > > Sanne
> > >
> > > >
> > > > Cheers,
> > > >
> > > >>
> > > >> On 11 May 2015 at 16:23, Galder Zamarre?o <galder at redhat.com> wrote:
> > > >>>
> > > >>>> On 11 May 2015, at 16:45, Scott Marlow <smarlow at redhat.com> wrote:
> > > >>>>
> > > >>>> Do we need to have a Hibernate ORM continuous integration test setup
> > > to run against Infinispan 7.2.1?  How about Infinispan 8.x (master?).  Or
> > > is ORM/Infinispan already tested as part of the Infinispan CI testing?
> > > >>>
> > > >>> In this particular case, as mentioned below, running ORM 4.3
> > > >>> testsuite
> > > with Infinispan 7.2.1 would mostly fail because of XML changes. Again,
> > > this
> > > does not affect WF, so it would not really help you much.
> > > >>>
> > > >>> We do have some tests in Infinispan CI to test integration with HB
> > > >>> but
> > > need some updates [1].
> > > >>>
> > > >>> Cheers,
> > > >>>
> > > >>> [1]
> > > http://ci.infinispan.org/project.html?projectId=HibernateIntegration
> > > >>>
> > > >>>>
> > > >>>> On 05/11/2015 04:31 AM, Galder Zamarre?o wrote:
> > > >>>>> Hi Gail,
> > > >>>>>
> > > >>>>> I've sent a PR for 4.3 to fix HHH-9781 and HHH-9776 in a way that
> > > >>>>> it
> > > works fine with both Infinispan 7.x and 6.x:
> > > >>>>> https://github.com/hibernate/hibernate-orm/pull/948
> > > >>>>>
> > > >>>>> Cheers,
> > > >>>>>
> > > >>>>>> On 11 May 2015, at 09:48, Galder Zamarre?o <galder at redhat.com>
> > > wrote:
> > > >>>>>>
> > > >>>>>> Hi Gail,
> > > >>>>>>
> > > >>>>>> Thanks for looking into this.
> > > >>>>>>
> > > >>>>>> For the scope of WF, the XML part is irrelevant since WF does its
> > > own configuration parsing, and hence there's no need to make any such
> > > changes in ORM 4.3. If someone wants to use ORM 4.3 with Infinispan 7.2.x
> > > standalone, then yes, they need to adjust XML configuration.
> > > >>>>>>
> > > >>>>>> The evict/clear issues that 7.2 brought up, and the incorrect
> > > element count can be fixed in ORM 4.3 without the need to up the
> > > dependency
> > > to 7.2. We just need to apply the changes in a way that work regardless
> > > of
> > > whether 6.0 or 7.2 is used.
> > > >>>>>>
> > > >>>>>> I'll work on that today.
> > > >>>>>>
> > > >>>>>> Cheers,
> > > >>>>>>
> > > >>>>>>> On 11 May 2015, at 07:49, Gail Badner <gbadner at redhat.com> wrote:
> > > >>>>>>>
> > > >>>>>>> I ran into some issues upgrading to Infinispan 7.2.1.Final in 4.3
> > > branch.
> > > >>>>>>>
> > > >>>>>>> I cherry-picked the 2 commits for HHH-9632 to upgrade 4.3 to use
> > > Infinispan 7.1.0.Final:
> > > >>>>>>>
> > > >>>>>>> 1)
> > > https://github.com/hibernate/hibernate-orm/commit/260ff03ae5e8cce0d1d56484e32825222e3046d5
> > > >>>>>>> 2)
> > > https://github.com/hibernate/hibernate-orm/commit/1b7e112994413559484e6873f019c5e2c557506b
> > > >>>>>>> (The 3rd (merge) commit
> > > >>>>>>> (2cff88cac76147ebb0da5bff8d3605c8a109fd26)
> > > appeared duplicate 1b7e112994413559484e6873f019c5e2c557506b).
> > > >>>>>>>
> > > >>>>>>> 1) updated infinispan-configs.xml to use
> > > >>>>>>> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> > > >>>>>>>      xmlns="urn:infinispan:config:7.0"
> > > >>>>>>>      xsi:schemaLocation="urn:infinispan:config:7.0
> > > http://www.infinispan.org/schemas/infinispan-config-7.0.xsd">
> > > >>>>>>>
> > > >>>>>>> After 1) was cherry-picked, I was able to build and run tests
> > > successfully using Infinispan 7.1.0.Final. When I tried running tests
> > > (without cleaning) using Infinispan 6.0.0.Final, there were lots of test
> > > failures due to problems configuring the cache:
> > > >>>>>>>      Caused by: org.hibernate.cache.CacheException
> > > >>>>>>>          Caused by:
> > > org.infinispan.commons.CacheConfigurationException
> > > >>>>>>>              Caused by: javax.xml.stream.XMLStreamException
> > > >>>>>>>
> > > >>>>>>> I've attached the output from test
> > > org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.
> > > >>>>>>>
> > > >>>>>>> Do we need to continue to support running Infinispan 6.0.0.Final
> > > in ORM 4.3 branch? Could an application have its own dependence on
> > > Infinispan 6.0.0.Final?
> > > >>>>>>>
> > > >>>>>>> Next I cherry-picked the commit for HHH-9781 to upgrade
> > > >>>>>>> Infinispan
> > > to 7.2.1.Final:
> > > https://github.com/hibernate/hibernate-orm/commit/37494f4a9f31c7eaa3486542cb2014b1d3756a87.
> > > After rebuilding,
> > > >>>>>>>
> > > org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase
> > > fails. I've attached the output for that test as well.
> > > >>>>>>>
> > > >>>>>>> Galder, HHH-9781 is still open. Is there more work to do on this?
> > > Am I missing some other commit that would fix the
> > > TimestampsRegionImplTestCase failure?
> > > >>>>>>>
> > > >>>>>>> This commit (for HHH-9781) includes a change to use
> > > org.infinispan.commons.util.CloseableIterator, which does not appear to
> > > be
> > > in Infinispan 6.0.0.Final, so this would not be backward-compatible
> > > either.
> > > >>>>>>>
> > > >>>>>>> Next I cherry-picked the commit for HHH-9776:
> > > https://github.com/hibernate/hibernate-orm/commit/f8186e10c24a4951785ab43dbaadbec3195df2e5.
> > > TimestampsRegionImplTestCase still fails; there are no other failures.
> > > >>>>>>>
> > > >>>>>>> Galder, HHH-9776 is still open. Is there more work to be done on
> > > that issue?
> > > >>>>>>>
> > > >>>>>>> I've pushed this work to my fork for others to see:
> > > https://github.com/gbadner/hibernate-core/tree/HHH-9632_HHH-9781_HHH-9776.
> > > >>>>>>>
> > > >>>>>>> I've postponed creating a pull request and running the TCK until
> > > we resolve backward-compatibility requirements and the unit test failure.
> > > It's OK with me if someone wants to go ahead and run the TCK with what I
> > > have so far.
> > > >>>>>>>
> > > >>>>>>> Regards,
> > > >>>>>>> Gail
> > > >>>>>>>
> > > <TEST-org.hibernate.test.cache.infinispan.timestamp.TimestampsRegionImplTestCase.xml><TEST-org.hibernate.test.cache.infinispan.InfinispanRegionFactoryTestCase.xml>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> --
> > > >>>>>> Galder Zamarre?o
> > > >>>>>> galder at redhat.com
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>> Galder Zamarre?o
> > > >>>>> galder at redhat.com
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> Galder Zamarre?o
> > > >>> galder at redhat.com
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >
> > > >
> > > > --
> > > > Galder Zamarre?o
> > > > galder at redhat.com
> > > >
> > > >
> > > >
> > > >
> > >
> > 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From sanne at hibernate.org  Tue May 12 05:43:08 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 12 May 2015 10:43:08 +0100
Subject: [hibernate-dev] JMS configuration for the Hibernate Search backend
Message-ID: <CAFm4XO2uEyUx33H9A7OdLvR0vM6vLA1CtW1amioVjZr3_emufw@mail.gmail.com>

Hi all,
I'm having an interesting conversation on the forums:
 - https://forum.hibernate.org/viewtopic.php?f=9&t=1039407

Pawel is mentioning the need to configure a PROVIDER_URL property to
get his slaves to know were to connect to.
I'm pretty sure others have successfully configured this in the past,
so I guess there might be multiple ways to set such a thing up but my
hands on experience with JMS is very limited.

Would someone know how if we need to support configuring this
PROVIDER_URL, or explain what the alternatives are?

Thanks,
Sanne

From hardy at hibernate.org  Tue May 12 07:12:38 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 12 May 2015 13:12:38 +0200
Subject: [hibernate-dev] JMS configuration for the Hibernate Search
 backend
In-Reply-To: <CAFm4XO2uEyUx33H9A7OdLvR0vM6vLA1CtW1amioVjZr3_emufw@mail.gmail.com>
References: <CAFm4XO2uEyUx33H9A7OdLvR0vM6vLA1CtW1amioVjZr3_emufw@mail.gmail.com>
Message-ID: <20150512111238.GC64040@Nineveh.lan>

Hi,

In case we are talking about Context.PROVIDER_URL, then this is a 
JNDI configuration property. He should be able to set it via hibernate.jndi.url.

--Hardy


On Tue, May 12, 2015 at 10:43:08AM +0100, Sanne Grinovero wrote:
> Hi all,
> I'm having an interesting conversation on the forums:
>  - https://forum.hibernate.org/viewtopic.php?f=9&t=1039407
> 
> Pawel is mentioning the need to configure a PROVIDER_URL property to
> get his slaves to know were to connect to.
> I'm pretty sure others have successfully configured this in the past,
> so I guess there might be multiple ways to set such a thing up but my
> hands on experience with JMS is very limited.
> 
> Would someone know how if we need to support configuring this
> PROVIDER_URL, or explain what the alternatives are?
> 
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
-------------- 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/20150512/334d9d3f/attachment.bin 

From hardy at hibernate.org  Tue May 12 07:30:55 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 12 May 2015 13:30:55 +0200
Subject: [hibernate-dev] JMS configuration for the Hibernate Search
 backend
In-Reply-To: <20150512111238.GC64040@Nineveh.lan>
References: <CAFm4XO2uEyUx33H9A7OdLvR0vM6vLA1CtW1amioVjZr3_emufw@mail.gmail.com>
	<20150512111238.GC64040@Nineveh.lan>
Message-ID: <20150512113055.GD64040@Nineveh.lan>

This might help as well - https://docs.jboss.org/author/display/WFLY8/JNDI+Reference

On Tue, May 12, 2015 at 01:12:38PM +0200, Hardy Ferentschik wrote:
> Hi,
> 
> In case we are talking about Context.PROVIDER_URL, then this is a 
> JNDI configuration property. He should be able to set it via hibernate.jndi.url.
> 
> --Hardy
> 
> 
> On Tue, May 12, 2015 at 10:43:08AM +0100, Sanne Grinovero wrote:
> > Hi all,
> > I'm having an interesting conversation on the forums:
> >  - https://forum.hibernate.org/viewtopic.php?f=9&t=1039407
> > 
> > Pawel is mentioning the need to configure a PROVIDER_URL property to
> > get his slaves to know were to connect to.
> > I'm pretty sure others have successfully configured this in the past,
> > so I guess there might be multiple ways to set such a thing up but my
> > hands on experience with JMS is very limited.
> > 
> > Would someone know how if we need to support configuring this
> > PROVIDER_URL, or explain what the alternatives are?
> > 
> > Thanks,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev



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

-------------- 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/20150512/9fd659dd/attachment.bin 

From sanne at hibernate.org  Tue May 12 18:55:16 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 12 May 2015 23:55:16 +0100
Subject: [hibernate-dev] SchemaExport usage ?
Message-ID: <CAFm4XO0T6qyaw6WGgoNjA+r-FqzyaAyc27h-2ro+SqFEu=u5og@mail.gmail.com>

We have some Hibernate Search tests which use multi-tenancy, and
require the schema to be exported explicitly. I'm trying to get these
to run now with Hibernate ORM 5.

I can't use the command line tool, as the test configuration options
should be passed by instance (there are several unit tests to be run,
each with its own configuration).

I already have a SessionFactory started, so I'd prefer to use its
metadata if possible, but while SchemaExport has plenty of
constructors, it doesn't seem to have one I could use.

This one looks like a good candidate:

 SchemaExport(ConnectionHelper connectionHelper, MetadataImplementor metadata)

as I do have a ConnectionHelper instance. But while I have a reference
to my SessionFactory, and a reference to the Configuration which
started it, I couldn't find a way to get a MetadataImplementor from
these?

Wouldn't it be very useful to have something like

SchemaExport(ConnectionHelper connectionHelper, SessionFactorty sf) ?

I think all multi-tenancy users would need something similar.


Partially unrelated, the methods:
 - org.hibernate.cfg.Configuration.generateDropSchemaScript(Dialect)
 - org.hibernate.cfg.Configuration.generateSchemaCreationScript(Dialect)

are returning an hard coded String[0]. Should these be implemented
before 5.0.0.Final, or are these meant to be deprecated?

Thanks,
Sanne

From steve at hibernate.org  Wed May 13 00:05:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 12 May 2015 23:05:13 -0500
Subject: [hibernate-dev] SchemaExport usage ?
In-Reply-To: <CAFm4XO0T6qyaw6WGgoNjA+r-FqzyaAyc27h-2ro+SqFEu=u5og@mail.gmail.com>
References: <CAFm4XO0T6qyaw6WGgoNjA+r-FqzyaAyc27h-2ro+SqFEu=u5og@mail.gmail.com>
Message-ID: <CAFdSV9sHAQ1t=gt3G9O1ONwGeQHxSXk_J3+0oyoYs0cB8qpHAQ@mail.gmail.com>

None of the bootstrapping contracts are kept around after the SF is
bootstrapped.  Nothing different there from Configuration.  There is
nothing meaningful on SessionFactory for performing any schema tools.  For
what its worth I hope to change that with the metamodel work (6.0), but for
now this is the case.

The Configuration methods should be removed.  I just missed them.

Take a look
at org.hibernate.test.multitenancy.schema.SchemaBasedMultiTenancyTest in
regards to how I do this for my tests

On Tue, May 12, 2015 at 5:55 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> We have some Hibernate Search tests which use multi-tenancy, and
> require the schema to be exported explicitly. I'm trying to get these
> to run now with Hibernate ORM 5.
>
> I can't use the command line tool, as the test configuration options
> should be passed by instance (there are several unit tests to be run,
> each with its own configuration).
>
> I already have a SessionFactory started, so I'd prefer to use its
> metadata if possible, but while SchemaExport has plenty of
> constructors, it doesn't seem to have one I could use.
>
> This one looks like a good candidate:
>
>  SchemaExport(ConnectionHelper connectionHelper, MetadataImplementor
> metadata)
>
> as I do have a ConnectionHelper instance. But while I have a reference
> to my SessionFactory, and a reference to the Configuration which
> started it, I couldn't find a way to get a MetadataImplementor from
> these?
>
> Wouldn't it be very useful to have something like
>
> SchemaExport(ConnectionHelper connectionHelper, SessionFactorty sf) ?
>
> I think all multi-tenancy users would need something similar.
>
>
> Partially unrelated, the methods:
>  - org.hibernate.cfg.Configuration.generateDropSchemaScript(Dialect)
>  - org.hibernate.cfg.Configuration.generateSchemaCreationScript(Dialect)
>
> are returning an hard coded String[0]. Should these be implemented
> before 5.0.0.Final, or are these meant to be deprecated?
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Wed May 13 00:09:49 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 12 May 2015 23:09:49 -0500
Subject: [hibernate-dev] SchemaExport usage ?
In-Reply-To: <CAFdSV9sHAQ1t=gt3G9O1ONwGeQHxSXk_J3+0oyoYs0cB8qpHAQ@mail.gmail.com>
References: <CAFm4XO0T6qyaw6WGgoNjA+r-FqzyaAyc27h-2ro+SqFEu=u5og@mail.gmail.com>
	<CAFdSV9sHAQ1t=gt3G9O1ONwGeQHxSXk_J3+0oyoYs0cB8qpHAQ@mail.gmail.com>
Message-ID: <CAFdSV9t_BycD+XnkQdw=fHO6=B=GA9MEqTnS37phbk-5W=QvbA@mail.gmail.com>

HHH-9792 - Clean up missed Configuration methods

On Tue, May 12, 2015 at 11:05 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> None of the bootstrapping contracts are kept around after the SF is
> bootstrapped.  Nothing different there from Configuration.  There is
> nothing meaningful on SessionFactory for performing any schema tools.  For
> what its worth I hope to change that with the metamodel work (6.0), but for
> now this is the case.
>
> The Configuration methods should be removed.  I just missed them.
>
> Take a look
> at org.hibernate.test.multitenancy.schema.SchemaBasedMultiTenancyTest in
> regards to how I do this for my tests
>
> On Tue, May 12, 2015 at 5:55 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> We have some Hibernate Search tests which use multi-tenancy, and
>> require the schema to be exported explicitly. I'm trying to get these
>> to run now with Hibernate ORM 5.
>>
>> I can't use the command line tool, as the test configuration options
>> should be passed by instance (there are several unit tests to be run,
>> each with its own configuration).
>>
>> I already have a SessionFactory started, so I'd prefer to use its
>> metadata if possible, but while SchemaExport has plenty of
>> constructors, it doesn't seem to have one I could use.
>>
>> This one looks like a good candidate:
>>
>>  SchemaExport(ConnectionHelper connectionHelper, MetadataImplementor
>> metadata)
>>
>> as I do have a ConnectionHelper instance. But while I have a reference
>> to my SessionFactory, and a reference to the Configuration which
>> started it, I couldn't find a way to get a MetadataImplementor from
>> these?
>>
>> Wouldn't it be very useful to have something like
>>
>> SchemaExport(ConnectionHelper connectionHelper, SessionFactorty sf) ?
>>
>> I think all multi-tenancy users would need something similar.
>>
>>
>> Partially unrelated, the methods:
>>  - org.hibernate.cfg.Configuration.generateDropSchemaScript(Dialect)
>>  - org.hibernate.cfg.Configuration.generateSchemaCreationScript(Dialect)
>>
>> are returning an hard coded String[0]. Should these be implemented
>> before 5.0.0.Final, or are these meant to be deprecated?
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> 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 May 13 07:56:55 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 13 May 2015 13:56:55 +0200
Subject: [hibernate-dev] Search - Plain text and SimpleQueryParser
Message-ID: <CALt0+o8Q7JVAzXa65qz=fVRv6mPhPjZEcEv5XVxcZ2CBipq5uw@mail.gmail.com>

Hi,

Having some spare time, I revisited my patch that used the Lucene
SimpleQueryParser to provide more advanced search features to the end user.

At my company, our search requirements are usually the following:
- a full text search on the name and description;
- a set of dropdown choices.

Our full text search uses the AND operator as our customers usually
requires this. It's not something we can do with the current keyword()
search (I described the issue at length in
https://hibernate.atlassian.net/browse/HSEARCH-917).

We often give the ability to use boolean operators and phrase queries to
the end user.

How did we expose this feature? We build a Lucene query using the
MultiFieldsQueryParser and we set the default operator to AND. We can't use
the DSL.

Starting with Lucene 4, we have a nice parser which is called
SimpleQueryParser and which is... simple and resilient. And I think it
would be a good idea to expose it via the DSL.

It currently looks like this:
https://github.com/openwide-java/hibernate-search/commit/ee776744760d8115965a05c939227d24133b58ec
(there's not much code, Lucene is doing the magic).

There are a couple of XXX I would like to discuss and I'm not that thrilled
with the names I gave to the options.

I have some spare time this week and next week so I'll be able to polish
the patch based on your feedback!

Have a nice day.

-- 
Guillaume

From gunnar at hibernate.org  Wed May 13 08:28:08 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 13 May 2015 14:28:08 +0200
Subject: [hibernate-dev] [OGM] Need to list entities when using Hibernate
	OGM on WildFly
Message-ID: <CADGJaX94y0sKeQwKVXcTzFL69bEXb+efcYdA-NVBZpHbN6FYsA@mail.gmail.com>

Hi,

When using Hibernate OGM on WildFly, one needs to list the entity classes
in persistence.xml, otherwise and "Unknown entity" exception will be raised.

Does anyone have a rough idea what may be causing this or where to get
started to analyse this issue?

Thanks,

--Gunnar

From smarlow at redhat.com  Wed May 13 09:08:13 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 13 May 2015 09:08:13 -0400
Subject: [hibernate-dev] [OGM] Need to list entities when using
 Hibernate OGM on WildFly
In-Reply-To: <CADGJaX94y0sKeQwKVXcTzFL69bEXb+efcYdA-NVBZpHbN6FYsA@mail.gmail.com>
References: <CADGJaX94y0sKeQwKVXcTzFL69bEXb+efcYdA-NVBZpHbN6FYsA@mail.gmail.com>
Message-ID: <55534CBD.8060404@redhat.com>

I remember seeing this before but don't remember why.  Years ago, I 
blogged [1] about using OGM on JBoss AS (before the rename to WildFly). 
  I didn't name the entity classes in the blog (or git [2]), so not sure 
if that was because OGM worked better back then or I just got lucky with 
my simple test case.

By the way, we are talking about moving Jipijapa back into the WildFly 
code base, to get more eyeballs on it.  Currently its just me reviewing 
my own code changes, but on WildFly we usually get a peer code review as 
part of pull request processing.  I wanted to mention this, as we talked 
in the past about possibly adding JPA integration code for OGM (if there 
is ever a need).  Obviously, if the Jipijapa code is moving to WildFly, 
we would want to do any integration there.  This is still being discussed.

Scott

[1] 
http://in.relation.to/Bloggers/UsingADifferentPersistenceProviderWithAS701#H-ExperimentalUseOfOGMOnAS701

[2] 
https://github.com/scottmarlow/wildfly/commit/9282f0f6bd20007b834f3390c08a0978bf578d2c

On 05/13/2015 08:28 AM, Gunnar Morling wrote:
> Hi,
>
> When using Hibernate OGM on WildFly, one needs to list the entity classes
> in persistence.xml, otherwise and "Unknown entity" exception will be raised.
>
> Does anyone have a rough idea what may be causing this or where to get
> started to analyse this issue?
>
> 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  Wed May 13 12:29:11 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 13 May 2015 12:29:11 -0400 (EDT)
Subject: [hibernate-dev] Another pull request for supporting Infinispan
	7.2.1 in 4.3
In-Reply-To: <CAFdSV9uk8tNwNjb6hLJB1MHAPFu6qAPBQuG5=2n_Uu5PKPommA@mail.gmail.com>
References: <182273131.16549787.1431498665346.JavaMail.zimbra@redhat.com>
	<1640734682.16558940.1431500648918.JavaMail.zimbra@redhat.com>
	<CAFdSV9uGcd9-76pg5pVKE2Erk9htFOMJKAvwg+4aYRLXy0KR2Q@mail.gmail.com>
	<CAFdSV9uk8tNwNjb6hLJB1MHAPFu6qAPBQuG5=2n_Uu5PKPommA@mail.gmail.com>
Message-ID: <1353579200.16905459.1431534551051.JavaMail.zimbra@redhat.com>

Adding hibernate-dev.

No, I did not have a chance to read up on what you suggested. I sounded like it had some limitations that would not work, but maybe I misunderstood. I'll look into it today.

The last couple of days have been very long. Sorry for the oversights.

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow" <smarlow at redhat.com>, "Galder Zamarre?o"
> <galder at redhat.com>
> Sent: Wednesday, May 13, 2015 5:33:24 AM
> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> 
> On May 13, 2015 7:32 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
> >
> > 1) This really should be a hibernate-core discussion
> 
> I meant to say hibernate-dev...
> 
> > 2) I already suggested using forced version in Gradle and gave you a link
> on how that works.  Did you read it?  Did you try it?
> >
> > On May 13, 2015 2:04 AM, "Gail Badner" <gbadner at redhat.com> wrote:
> >>
> >> Sanne, Scott, and I discussed how Hibernate should deal with supporting
> Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it would
> be sufficient to:
> >> - specify the Infinispan 7.2 configuration by using
> hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to switch if
> parsing failed);
> >> - run tests manually with Infinispan 7.2 for WildFly integration testing.
> >>
> >> I created another pull request:
> https://github.com/hibernate/hibernate-orm/pull/953
> >>
> >> My pull request incorporated some of Galder's changes from
> https://github.com/hibernate/hibernate-orm/pull/951.
> >>
> >> The main differences:
> >> - Hibernate will consider the 7.2 configuration as test code
> >> - the 7.2 configuration can be specified using
> -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> >>
> >> Currently, the only way to run hibernate-infinispan tests is to change
> infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice to be
> able to specify infinispanVersion as a environment variable, defaulting to
> 6.0.0.Final to avoid having to manually update libraries.gradle.
> >>
> >> Another consideration is that manually updating libraries.gradle forces
> a re-build using Infinispan 7.2.1 as a dependency.
> >>
> >> Since WildFly will use a hiberanate-infinispan jar build against
> Infinispan 6.0.0.Final (won't it???), I think it would be best if we could
> run unit tests without rebuilding with Infinispan 7.2.1, but using it as a
> run time dependency. I haven't been able to figure out how to do that
> though.
> >>
> >> Anyone have an idea how to do that, even manually?
> >>
> >> Thoughts on all this?
> >>
> >> Thanks,
> >> Gail
> 


From sanne at hibernate.org  Wed May 13 12:48:57 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Wed, 13 May 2015 17:48:57 +0100
Subject: [hibernate-dev] SchemaExport usage ?
In-Reply-To: <CAFdSV9t_BycD+XnkQdw=fHO6=B=GA9MEqTnS37phbk-5W=QvbA@mail.gmail.com>
References: <CAFm4XO0T6qyaw6WGgoNjA+r-FqzyaAyc27h-2ro+SqFEu=u5og@mail.gmail.com>
	<CAFdSV9sHAQ1t=gt3G9O1ONwGeQHxSXk_J3+0oyoYs0cB8qpHAQ@mail.gmail.com>
	<CAFdSV9t_BycD+XnkQdw=fHO6=B=GA9MEqTnS37phbk-5W=QvbA@mail.gmail.com>
Message-ID: <CAFm4XO0shyKk_RE1yDkYQh8uwPhLKrYb3Ai-0mUMF-gBvPRACw@mail.gmail.com>

Thanks Steve, that was very helpful.

On 13 May 2015 at 05:09, Steve Ebersole <steve at hibernate.org> wrote:
> HHH-9792 - Clean up missed Configuration methods
>
> On Tue, May 12, 2015 at 11:05 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>>
>> None of the bootstrapping contracts are kept around after the SF is
>> bootstrapped.  Nothing different there from Configuration.  There is nothing
>> meaningful on SessionFactory for performing any schema tools.  For what its
>> worth I hope to change that with the metamodel work (6.0), but for now this
>> is the case.
>>
>> The Configuration methods should be removed.  I just missed them.
>>
>> Take a look at
>> org.hibernate.test.multitenancy.schema.SchemaBasedMultiTenancyTest in
>> regards to how I do this for my tests
>>
>> On Tue, May 12, 2015 at 5:55 PM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>>
>>> We have some Hibernate Search tests which use multi-tenancy, and
>>> require the schema to be exported explicitly. I'm trying to get these
>>> to run now with Hibernate ORM 5.
>>>
>>> I can't use the command line tool, as the test configuration options
>>> should be passed by instance (there are several unit tests to be run,
>>> each with its own configuration).
>>>
>>> I already have a SessionFactory started, so I'd prefer to use its
>>> metadata if possible, but while SchemaExport has plenty of
>>> constructors, it doesn't seem to have one I could use.
>>>
>>> This one looks like a good candidate:
>>>
>>>  SchemaExport(ConnectionHelper connectionHelper, MetadataImplementor
>>> metadata)
>>>
>>> as I do have a ConnectionHelper instance. But while I have a reference
>>> to my SessionFactory, and a reference to the Configuration which
>>> started it, I couldn't find a way to get a MetadataImplementor from
>>> these?
>>>
>>> Wouldn't it be very useful to have something like
>>>
>>> SchemaExport(ConnectionHelper connectionHelper, SessionFactorty sf) ?
>>>
>>> I think all multi-tenancy users would need something similar.
>>>
>>>
>>> Partially unrelated, the methods:
>>>  - org.hibernate.cfg.Configuration.generateDropSchemaScript(Dialect)
>>>  - org.hibernate.cfg.Configuration.generateSchemaCreationScript(Dialect)
>>>
>>> are returning an hard coded String[0]. Should these be implemented
>>> before 5.0.0.Final, or are these meant to be deprecated?
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>

From steve at hibernate.org  Wed May 13 12:57:24 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 May 2015 11:57:24 -0500
Subject: [hibernate-dev] Another pull request for supporting Infinispan
	7.2.1 in 4.3
In-Reply-To: <1353579200.16905459.1431534551051.JavaMail.zimbra@redhat.com>
References: <182273131.16549787.1431498665346.JavaMail.zimbra@redhat.com>
	<1640734682.16558940.1431500648918.JavaMail.zimbra@redhat.com>
	<CAFdSV9uGcd9-76pg5pVKE2Erk9htFOMJKAvwg+4aYRLXy0KR2Q@mail.gmail.com>
	<CAFdSV9uk8tNwNjb6hLJB1MHAPFu6qAPBQuG5=2n_Uu5PKPommA@mail.gmail.com>
	<1353579200.16905459.1431534551051.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9vnAJ1S8=Cs6Sf2xNZkOqEmxZUu+WjW+4QngAaz_vQQzA@mail.gmail.com>

Not sure what limitations you mean.  All I said was that if you wanted to
allow testing with both you would need to make this conditional and expose
a property to control which to use.

On Wed, May 13, 2015 at 11:29 AM, Gail Badner <gbadner at redhat.com> wrote:

> Adding hibernate-dev.
>
> No, I did not have a chance to read up on what you suggested. I sounded
> like it had some limitations that would not work, but maybe I
> misunderstood. I'll look into it today.
>
> The last couple of days have been very long. Sorry for the oversights.
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "Gail Badner" <gbadner at redhat.com>
> > Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow" <
> smarlow at redhat.com>, "Galder Zamarre?o"
> > <galder at redhat.com>
> > Sent: Wednesday, May 13, 2015 5:33:24 AM
> > Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> >
> > On May 13, 2015 7:32 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
> > >
> > > 1) This really should be a hibernate-core discussion
> >
> > I meant to say hibernate-dev...
> >
> > > 2) I already suggested using forced version in Gradle and gave you a
> link
> > on how that works.  Did you read it?  Did you try it?
> > >
> > > On May 13, 2015 2:04 AM, "Gail Badner" <gbadner at redhat.com> wrote:
> > >>
> > >> Sanne, Scott, and I discussed how Hibernate should deal with
> supporting
> > Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it would
> > be sufficient to:
> > >> - specify the Infinispan 7.2 configuration by using
> > hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to switch if
> > parsing failed);
> > >> - run tests manually with Infinispan 7.2 for WildFly integration
> testing.
> > >>
> > >> I created another pull request:
> > https://github.com/hibernate/hibernate-orm/pull/953
> > >>
> > >> My pull request incorporated some of Galder's changes from
> > https://github.com/hibernate/hibernate-orm/pull/951.
> > >>
> > >> The main differences:
> > >> - Hibernate will consider the 7.2 configuration as test code
> > >> - the 7.2 configuration can be specified using
> >
> -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> > >>
> > >> Currently, the only way to run hibernate-infinispan tests is to change
> > infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice to be
> > able to specify infinispanVersion as a environment variable, defaulting
> to
> > 6.0.0.Final to avoid having to manually update libraries.gradle.
> > >>
> > >> Another consideration is that manually updating libraries.gradle
> forces
> > a re-build using Infinispan 7.2.1 as a dependency.
> > >>
> > >> Since WildFly will use a hiberanate-infinispan jar build against
> > Infinispan 6.0.0.Final (won't it???), I think it would be best if we
> could
> > run unit tests without rebuilding with Infinispan 7.2.1, but using it as
> a
> > run time dependency. I haven't been able to figure out how to do that
> > though.
> > >>
> > >> Anyone have an idea how to do that, even manually?
> > >>
> > >> Thoughts on all this?
> > >>
> > >> Thanks,
> > >> Gail
> >
>

From steve at hibernate.org  Wed May 13 13:55:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 May 2015 12:55:54 -0500
Subject: [hibernate-dev] Fwd: Build failed in Jenkins:
	hibernate-orm-master-h2 #900
In-Reply-To: <788185724.103.1431539048797.JavaMail.javamailuser@localhost>
References: <788185724.103.1431539048797.JavaMail.javamailuser@localhost>
Message-ID: <CAFdSV9uB799t=SspSgWZ1QT88Ej3EK-EN-t911YC12rp1hd52A@mail.gmail.com>

Is there a reason that this particular hibernate-infinispan test continues
to be the one that fails when the CI jobs fail?  It's a transient failure;
the jobs succeed a few times, then fail.
---------- Forwarded message ----------
From: "Hibernate CI" <ci at hibernate.org>
Date: May 13, 2015 12:44 PM
Subject: Build failed in Jenkins: hibernate-orm-master-h2 #900
To: <steve at hibernate.org>
Cc:

See <http://ci.hibernate.org/job/hibernate-orm-master-h2/900/changes>
>
> Changes:
>
> [Steve Ebersole] HHH-9790 - Remove deprecated methods from Session and
> SessionFactory
>
> ------------------------------------------
> [...truncated 767 lines...]
> JAVA6_HOME setting not specified, some build features will be disabled
> JAVA6_HOME setting not specified, some build features will be disabled
> JAVA6_HOME setting not specified, some build features will be disabled
> :documentation:clean
> :hibernate-c3p0:clean UP-TO-DATE
> :hibernate-core:clean UP-TO-DATE
> :hibernate-ehcache:clean UP-TO-DATE
> :hibernate-enhance-maven-plugin:clean UP-TO-DATE
> :hibernate-entitymanager:clean UP-TO-DATE
> :hibernate-envers:clean UP-TO-DATE
> :hibernate-gradle-plugin:clean UP-TO-DATE
> :hibernate-hikaricp:clean UP-TO-DATE
> :hibernate-infinispan:clean UP-TO-DATE
> :hibernate-java8:clean UP-TO-DATE
> :hibernate-jpamodelgen:clean UP-TO-DATE
> :hibernate-osgi:clean UP-TO-DATE
> :hibernate-proxool:clean UP-TO-DATE
> :hibernate-spatial:clean UP-TO-DATE
> :hibernate-testing:clean UP-TO-DATE
> :release:clean
> :documentation:compileJava UP-TO-DATE
> :documentation:processResources UP-TO-DATE
> :documentation:classes UP-TO-DATE
> :documentation:compileTestJava UP-TO-DATE
> :documentation:processTestResources UP-TO-DATE
> :documentation:testClasses UP-TO-DATE
> :documentation:test UP-TO-DATE
> :hibernate-core:generateGrammarSource
> [ant:null] ANTLR Parser Generator   Version 2.7.7 (20060906)   1989-2005
> [ant:null] ANTLR Parser Generator   Version 2.7.7 (20060906)   1989-2005
> [ant:null] ANTLR Parser Generator   Version 2.7.7 (20060906)   1989-2005
> [ant:null] ANTLR Parser Generator   Version 2.7.7 (20060906)   1989-2005
> [ant:null] ANTLR Parser Generator   Version 2.7.7 (20060906)   1989-2005
> [ant:null] ANTLR Parser Generator   Version 2.7.7 (20060906)   1989-2005
> :hibernate-core:xjc
> :hibernate-core:compileJavaNote: 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.
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-core:processResources
> :hibernate-core:classes
> :hibernate-core:jar
> :hibernate-c3p0:compileJavaNote: <
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/target/generated-src/apt/main/org/hibernate/c3p0/internal/C3P0MessageLogger_$logger.java>
> uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-c3p0:processResources
> :hibernate-c3p0:classes
> :hibernate-testing:compileJavaNote: 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.
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-testing:processResources
> :hibernate-testing:classes
> :hibernate-testing:jar
> :hibernate-c3p0:compileTestJava
> :hibernate-c3p0:processTestResources
> :hibernate-c3p0:testClasses
> :hibernate-c3p0:test
> :hibernate-c3p0:checkstyleMain
> :hibernate-c3p0:findbugsMain
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/target/reports/findbugs/main.xml
> >
> :hibernate-c3p0:findbugsTest
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-c3p0/target/reports/findbugs/test.xml
> >
> :hibernate-c3p0:buildDashboard
> :hibernate-core:generateTestGrammarSource UP-TO-DATE
> :hibernate-core: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-core:processTestResources
> :hibernate-core:testClasses
> :hibernate-core:test
> :hibernate-core:checkstyleMain
> Checkstyle rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/target/reports/checkstyle/main.xml
> >
> :hibernate-core:findbugsMain
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/target/reports/findbugs/main.xml
> >
> :hibernate-core:findbugsTest
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-core/target/reports/findbugs/test.xml
> >
> :hibernate-core:buildDashboard
> :hibernate-ehcache:compileJavaNote: <
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/target/generated-src/apt/main/org/hibernate/cache/ehcache/EhCacheMessageLogger_$logger.java>
> uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-ehcache:processResources
> :hibernate-ehcache:classes
> :hibernate-ehcache:compileTestJavaNote: Some input files use unchecked or
> unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :hibernate-ehcache:processTestResources
> :hibernate-ehcache:testClasses
> :hibernate-ehcache:test
> :hibernate-ehcache:checkstyleMain
> :hibernate-ehcache:findbugsMain
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/target/reports/findbugs/main.xml
> >
> :hibernate-ehcache:findbugsTest
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-ehcache/target/reports/findbugs/test.xml
> >
> :hibernate-ehcache:buildDashboard
> :hibernate-enhance-maven-plugin:compileJavaNote: <
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/hibernate-enhance-maven-plugin/src/main/java/org/hibernate/bytecode/enhance/plugins/MavenEnhancePlugin.java>
> uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-enhance-maven-plugin:processPluginXml
> :hibernate-enhance-maven-plugin:processResources
> :hibernate-enhance-maven-plugin:classes
> :hibernate-enhance-maven-plugin:compileTestJava UP-TO-DATE
> :hibernate-enhance-maven-plugin:processTestResources UP-TO-DATE
> :hibernate-enhance-maven-plugin:testClasses UP-TO-DATE
> :hibernate-enhance-maven-plugin:test UP-TO-DATE
> :hibernate-enhance-maven-plugin:checkstyleMain
> Checkstyle rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/hibernate-enhance-maven-plugin/target/reports/checkstyle/main.xml
> >
> :hibernate-enhance-maven-plugin:findbugsMain
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/tooling/hibernate-enhance-maven-plugin/target/reports/findbugs/main.xml
> >
> :hibernate-enhance-maven-plugin:findbugsTest UP-TO-DATE
> :hibernate-enhance-maven-plugin:buildDashboard
> :hibernate-entitymanager:compileJavaNote: 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.
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-entitymanager:processResources
> :hibernate-entitymanager:classes
> :hibernate-jpamodelgen:jaxb
> :hibernate-jpamodelgen:xjc SKIPPED
> :hibernate-jpamodelgen:compileJava
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-jpamodelgen:processResources
> :hibernate-jpamodelgen:classes
> :hibernate-jpamodelgen:jar
> :hibernate-entitymanager: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-entitymanager:copyBundleResources
> :hibernate-entitymanager:processTestResources
> :hibernate-entitymanager:testClasses
> :hibernate-entitymanager:test
> :hibernate-entitymanager:checkstyleMain
> Checkstyle rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entitymanager/target/reports/checkstyle/main.xml
> >
> :hibernate-entitymanager:findbugsMain
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entitymanager/target/reports/findbugs/main.xml
> >
> :hibernate-entitymanager:findbugsTest
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-entitymanager/target/reports/findbugs/test.xml
> >
> :hibernate-entitymanager:buildDashboard
> :hibernate-entitymanager:jar
> :hibernate-entitymanager:testJar
> :hibernate-envers:compileJavaNote: 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.
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-envers:processResources
> :hibernate-envers:classes
> :hibernate-envers: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-envers:processTestResources
> :hibernate-envers:testClasses
> :hibernate-envers:test
> :hibernate-envers:checkstyleMain
> Checkstyle rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-envers/target/reports/checkstyle/main.xml
> >
> :hibernate-envers:findbugsMain
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-envers/target/reports/findbugs/main.xml
> >
> :hibernate-envers:findbugsTest
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-envers/target/reports/findbugs/test.xml
> >
> :hibernate-envers:buildDashboard
> :hibernate-gradle-plugin:compileJava UP-TO-DATE
> :hibernate-gradle-plugin:compileGroovywarning: Implicitly compiled files
> were not subject to annotation processing.
>   Use -proc:none to disable annotation processing or -implicit to specify
> a policy for implicit compilation.
> 1 warning
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-gradle-plugin:processResources
> :hibernate-gradle-plugin:classes
> :hibernate-gradle-plugin:compileTestJava UP-TO-DATE
> :hibernate-gradle-plugin:compileTestGroovy UP-TO-DATE
> :hibernate-gradle-plugin:processTestResources UP-TO-DATE
> :hibernate-gradle-plugin:testClasses UP-TO-DATE
> :hibernate-gradle-plugin:test UP-TO-DATE
> :hibernate-gradle-plugin:checkstyleMain UP-TO-DATE
> :hibernate-gradle-plugin:findbugsMain UP-TO-DATE
> :hibernate-gradle-plugin:findbugsTest UP-TO-DATE
> :hibernate-gradle-plugin:buildDashboard
> :hibernate-hikaricp:compileJava
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-hikaricp:processResources
> :hibernate-hikaricp:classes
> :hibernate-hikaricp:compileTestJava
> :hibernate-hikaricp:processTestResources
> :hibernate-hikaricp:testClasses
> :hibernate-hikaricp:test
> :hibernate-hikaricp:checkstyleMain
> Checkstyle rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-hikaricp/target/reports/checkstyle/main.xml
> >
> :hibernate-hikaricp:findbugsMain
> FindBugs rule violations were found. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-hikaricp/target/reports/findbugs/main.xml
> >
> :hibernate-hikaricp:findbugsTest
> :hibernate-hikaricp:buildDashboard
> :hibernate-infinispan:compileJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: <
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-infinispan/src/main/java/org/hibernate/cache/infinispan/InfinispanRegionFactory.java>
> uses unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> Starting AnimalSniffer checks using [java16-1.0.signature] against
> [sourceSets.main]
> :hibernate-infinispan:processResources
> :hibernate-infinispan:classes
> :hibernate-infinispan: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-infinispan:processTestResources
> :hibernate-infinispan:testClasses
> :hibernate-infinispan:test
>
> org.hibernate.test.cache.infinispan.query.QueryRegionImplTestCase >
> testEvict FAILED
>     java.lang.AssertionError
>
> 136 tests completed, 1 failed, 5 skipped
> :hibernate-infinispan:test FAILED
> :hibernate-infinispan:buildDashboard
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':hibernate-infinispan:test'.
> > There were failing tests. See the report at: file://<
> http://ci.hibernate.org/job/hibernate-orm-master-h2/ws/hibernate-infinispan/target/reports/tests/index.html
> >
>
> * 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: 38 mins 33.676 secs
> Build step 'Execute shell' marked build as failure
> [CHECKSTYLE] Skipping publisher since build result is FAILURE
> [FINDBUGS] Skipping publisher since build result is FAILURE
> [TASKS] Skipping publisher since build result is FAILURE
> Recording test results
> Publishing Javadoc
>

From paranoiabla at gmail.com  Wed May 13 13:59:04 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Wed, 13 May 2015 20:59:04 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAFdSV9twBZPcnrJZM9cP29fe039Xapj00W4c-RnugRo+-sDcTw@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
	<CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
	<CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>
	<CAFdSV9twBZPcnrJZM9cP29fe039Xapj00W4c-RnugRo+-sDcTw@mail.gmail.com>
Message-ID: <CAKnbemW4=M-fPspoYERbeZBq6tXc6+JJ8sLrcmLvG7HxJwom+g@mail.gmail.com>

Any luck on reproducing this?

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

> Petar, I have just been focusing on other things the past 3 days or so.
> Chill :)
>
> I will look at this this week.  If you happen to have a chance to debug it
> any further by then, that would rock.  FWIW, I do not think it is in any
> way related to the duplicate secondary table warnings.  Those are
> completely harmless I believe.  The FK naming logic has changed quite a bit
> from pre-5.0 versions, my guess is that the issue lies there.  That or in
> the logic to read existing FKs.
>
> On Tue, May 5, 2015 at 3:19 AM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Any of you have seen this issue? Shall I open a ticket?
>>
>> 2015-05-04 0:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>
>> > Hi guys,
>> >
>> > I finally managed to reproduce it - here's a small application that will
>> > generate the provided exception:
>> >
>> > https://github.com/paranoiabla/hibernate-hsql-issue
>> >
>> > Please notice that it works fine with Hibernate 4.3.x  I think it has to
>> > do something with the CommerceCustomerModel - If I remove it or remove
>> the
>> > collection of payment infos that is inside of it, it all starts to work
>> > fine.
>> >
>> > Please have a look and thanks a lot for your efforts :)
>> >
>> >
>> >
>> >
>> > 2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>> >
>> >> Hi guys,
>> >>
>> >> I just tried hibernate 5.0 beta2 and here's my observations. First of
>> all
>> >> the foreign key problems I had before seems to be resolved, however I
>> see
>> >> the following error when executing tests with HSQL:
>> >>
>> >>
>> >> Caused by: org.springframework.beans.factory.BeanCreationException:
>> Error
>> >> creating bean with name 'defaultEntityManagerFactory' defined in class
>> path
>> >> resource
>> [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
>> >> Invocation of init method failed; nested exception is
>> >> javax.persistence.PersistenceException: [PersistenceUnit: default]
>> Unable
>> >> to build Hibernate SessionFactory
>> >>     at
>> >>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
>> >>     at
>> >>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>> >>     at
>> >>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>> >>     at
>> >>
>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
>> >>     at
>> >>
>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>> >>     at
>> >>
>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
>> >>     at
>> >>
>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
>> >>     at
>> >>
>> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
>> >>     at
>> >>
>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
>> >>     at
>> >>
>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
>> >>     at
>> >>
>> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
>> >>     at
>> >>
>> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
>> >>     at
>> >>
>> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
>> >>     at
>> >>
>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
>> >>     at
>> >>
>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
>> >>     ... 36 more
>> >> Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
>> >> default] Unable to build Hibernate SessionFactory
>> >>     at
>> >>
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
>> >>     at
>> >>
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
>> >>     at
>> >>
>> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>> >>     at
>> >>
>> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>> >>     at
>> >>
>> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>> >>     at
>> >>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>> >>     at
>> >>
>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>> >>     ... 50 more
>> >> Caused by: org.hibernate.tool.schema.spi.SchemaManagementException:
>> >> Unable to execute schema management to JDBC target [alter table
>> >> payment_info add constraint FKs9wud9nve6s9cbot5p4548jyh foreign key
>> >> (user_pk) references principal]
>> >>     at
>> >>
>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
>> >>     at
>> >>
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
>> >>     at
>> >>
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
>> >>     at
>> >>
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
>> >>     at
>> >>
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
>> >>     at
>> >>
>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
>> >>     at
>> >> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
>> >>     at
>> >> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
>> >>     at
>> >>
>> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
>> >>     at
>> >>
>> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
>> >>     at
>> >>
>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
>> >>     ... 55 more
>> >> Caused by: java.sql.SQLSyntaxErrorException: object name already
>> exists:
>> >> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table payment_info add
>> >> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk) references
>> >> principal]
>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>> >>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>> >>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
>> >>     at
>> >>
>> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
>> >>     at
>> >>
>> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
>> >>     at
>> >>
>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
>> >>     ... 65 more
>> >> Caused by: org.hsqldb.HsqlException: object name already exists:
>> >> FKS9WUD9NVE6S9CBOT5P4548JYH
>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>> >>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
>> >>     at org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown
>> Source)
>> >>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
>> >>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
>> >>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
>> >>     at org.hsqldb.StatementSchema.execute(Unknown Source)
>> >>     at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>> >>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>> >>     at org.hsqldb.Session.execute(Unknown Source)
>> >>     ... 70 more
>> >>
>> >>
>> >> When running it with mysql it doesn't show this error (very strange)
>> so I
>> >> tried to export the schema to sql file and I can see only one foregin
>> key
>> >> declaration:
>> >>
>> >>     alter table payment_info
>> >>         add constraint FKs9wud9nve6s9cbot5p4548jyh
>> >>         foreign key (user_pk)
>> >>         references principal (pk);
>> >>
>> >> Notice that this time it is lowercase. I'm trying to debug the hsql but
>> >> it is very hard as it doesn't stop on any of the breakpoints I add. If
>> any
>> >> of you have an idea what might be causing it, please share your
>> thoughts,
>> >> if not I'll let you know how I progress.
>> >>
>> >> I wonder if it could be related to the duplicate joins warnings I see:
>> >> WARN : HHH000072: Duplicate joins for class:
>> >> com.nemesis.platform.core.model.media.MediaModel
>> >> WARN : HHH000072: Duplicate joins for class:
>> >>
>> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
>> >> WARN : HHH000072: Duplicate joins for class:
>> >> com.nemesis.platform.core.model.cms.AbstractPageModel
>> >> WARN : HHH000072: Duplicate joins for class:
>> >> com.nemesis.platform.core.model.cms.EmailPageModel
>> >> WARN : HHH000072: Duplicate joins for class:
>> >> com.nemesis.platform.core.model.cms.CategoryPageModel
>> >> .....
>> >>
>> >> --
>> >> Regards, Petar!
>> >> Karlovo, Bulgaria.
>> >> ---
>> >> Public PGP Key at:
>> >>
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> >>
>> >
>> >
>> >
>> > --
>> > Regards, Petar!
>> > Karlovo, Bulgaria.
>> > ---
>> > Public PGP Key at:
>> >
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> >
>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From gbadner at redhat.com  Wed May 13 14:48:32 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 13 May 2015 14:48:32 -0400 (EDT)
Subject: [hibernate-dev] Another pull request for supporting Infinispan
	7.2.1 in 4.3
In-Reply-To: <CAFdSV9vnAJ1S8=Cs6Sf2xNZkOqEmxZUu+WjW+4QngAaz_vQQzA@mail.gmail.com>
References: <182273131.16549787.1431498665346.JavaMail.zimbra@redhat.com>
	<1640734682.16558940.1431500648918.JavaMail.zimbra@redhat.com>
	<CAFdSV9uGcd9-76pg5pVKE2Erk9htFOMJKAvwg+4aYRLXy0KR2Q@mail.gmail.com>
	<CAFdSV9uk8tNwNjb6hLJB1MHAPFu6qAPBQuG5=2n_Uu5PKPommA@mail.gmail.com>
	<1353579200.16905459.1431534551051.JavaMail.zimbra@redhat.com>
	<CAFdSV9vnAJ1S8=Cs6Sf2xNZkOqEmxZUu+WjW+4QngAaz_vQQzA@mail.gmail.com>
Message-ID: <1178559274.16978227.1431542912778.JavaMail.zimbra@redhat.com>

As suggested by Sanne and Galder, I'll open a new Jira for the commit in my pull request and amend the comment to reflect the new Jira.

I'll see if I can get "forced version" in Gradle working in the next couple of hours. If not, I don't want to hold up releasing 4.3.10.Final for this. I can try to get those details worked out later.

I think that about wraps up what is needed for Hibernate 4.3 to support and test with Infinispan 7.2.1.Final.  Unless I hear otherwise, I plan to release 4.3.10.Final later today, tomorrow at the latest.

Regards,
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow" <smarlow at redhat.com>, "Galder Zamarre?o"
> <galder at redhat.com>, "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, May 13, 2015 9:57:24 AM
> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> 
> Not sure what limitations you mean.  All I said was that if you wanted to
> allow testing with both you would need to make this conditional and expose
> a property to control which to use.
> 
> On Wed, May 13, 2015 at 11:29 AM, Gail Badner <gbadner at redhat.com> wrote:
> 
> > Adding hibernate-dev.
> >
> > No, I did not have a chance to read up on what you suggested. I sounded
> > like it had some limitations that would not work, but maybe I
> > misunderstood. I'll look into it today.
> >
> > The last couple of days have been very long. Sorry for the oversights.
> >
> > ----- Original Message -----
> > > From: "Steve Ebersole" <steve at hibernate.org>
> > > To: "Gail Badner" <gbadner at redhat.com>
> > > Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow" <
> > smarlow at redhat.com>, "Galder Zamarre?o"
> > > <galder at redhat.com>
> > > Sent: Wednesday, May 13, 2015 5:33:24 AM
> > > Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> > >
> > > On May 13, 2015 7:32 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
> > > >
> > > > 1) This really should be a hibernate-core discussion
> > >
> > > I meant to say hibernate-dev...
> > >
> > > > 2) I already suggested using forced version in Gradle and gave you a
> > link
> > > on how that works.  Did you read it?  Did you try it?
> > > >
> > > > On May 13, 2015 2:04 AM, "Gail Badner" <gbadner at redhat.com> wrote:
> > > >>
> > > >> Sanne, Scott, and I discussed how Hibernate should deal with
> > supporting
> > > Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it would
> > > be sufficient to:
> > > >> - specify the Infinispan 7.2 configuration by using
> > > hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to switch if
> > > parsing failed);
> > > >> - run tests manually with Infinispan 7.2 for WildFly integration
> > testing.
> > > >>
> > > >> I created another pull request:
> > > https://github.com/hibernate/hibernate-orm/pull/953
> > > >>
> > > >> My pull request incorporated some of Galder's changes from
> > > https://github.com/hibernate/hibernate-orm/pull/951.
> > > >>
> > > >> The main differences:
> > > >> - Hibernate will consider the 7.2 configuration as test code
> > > >> - the 7.2 configuration can be specified using
> > >
> > -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> > > >>
> > > >> Currently, the only way to run hibernate-infinispan tests is to change
> > > infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice to be
> > > able to specify infinispanVersion as a environment variable, defaulting
> > to
> > > 6.0.0.Final to avoid having to manually update libraries.gradle.
> > > >>
> > > >> Another consideration is that manually updating libraries.gradle
> > forces
> > > a re-build using Infinispan 7.2.1 as a dependency.
> > > >>
> > > >> Since WildFly will use a hiberanate-infinispan jar build against
> > > Infinispan 6.0.0.Final (won't it???), I think it would be best if we
> > could
> > > run unit tests without rebuilding with Infinispan 7.2.1, but using it as
> > a
> > > run time dependency. I haven't been able to figure out how to do that
> > > though.
> > > >>
> > > >> Anyone have an idea how to do that, even manually?
> > > >>
> > > >> Thoughts on all this?
> > > >>
> > > >> Thanks,
> > > >> Gail
> > >
> >
> 


From smarlow at redhat.com  Wed May 13 14:56:04 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 13 May 2015 14:56:04 -0400
Subject: [hibernate-dev] Another pull request for supporting Infinispan
	7.2.1 in 4.3
In-Reply-To: <1178559274.16978227.1431542912778.JavaMail.zimbra@redhat.com>
References: <182273131.16549787.1431498665346.JavaMail.zimbra@redhat.com>
	<1640734682.16558940.1431500648918.JavaMail.zimbra@redhat.com>
	<CAFdSV9uGcd9-76pg5pVKE2Erk9htFOMJKAvwg+4aYRLXy0KR2Q@mail.gmail.com>
	<CAFdSV9uk8tNwNjb6hLJB1MHAPFu6qAPBQuG5=2n_Uu5PKPommA@mail.gmail.com>
	<1353579200.16905459.1431534551051.JavaMail.zimbra@redhat.com>
	<CAFdSV9vnAJ1S8=Cs6Sf2xNZkOqEmxZUu+WjW+4QngAaz_vQQzA@mail.gmail.com>
	<1178559274.16978227.1431542912778.JavaMail.zimbra@redhat.com>
Message-ID: <55539E44.1080605@redhat.com>


On 05/13/2015 02:48 PM, Gail Badner wrote:
> As suggested by Sanne and Galder, I'll open a new Jira for the commit in my pull request and amend the comment to reflect the new Jira.
>
> I'll see if I can get "forced version" in Gradle working in the next couple of hours. If not, I don't want to hold up releasing 4.3.10.Final for this. I can try to get those details worked out later.
>
> I think that about wraps up what is needed for Hibernate 4.3 to support and test with Infinispan 7.2.1.Final.  Unless I hear otherwise, I plan to release 4.3.10.Final later today, tomorrow at the latest.

Awesome, thanks for all of the help Gail in syncing Hibernate up to 
Infinispan 7.2.1!  Thanks to Sanne, Galder & Steve as well.  Very much 
appreciated!

I'm not sure of what will be in Infinispan 8.0 but that could need more 
hibernate-infinispan changes as well.  I think that Infinispan 8.0 might 
find its way into WildFly 10.

>
> Regards,
> Gail
>
> ----- Original Message -----
>> From: "Steve Ebersole" <steve at hibernate.org>
>> To: "Gail Badner" <gbadner at redhat.com>
>> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow" <smarlow at redhat.com>, "Galder Zamarre?o"
>> <galder at redhat.com>, "Hibernate Dev" <hibernate-dev at lists.jboss.org>
>> Sent: Wednesday, May 13, 2015 9:57:24 AM
>> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
>>
>> Not sure what limitations you mean.  All I said was that if you wanted to
>> allow testing with both you would need to make this conditional and expose
>> a property to control which to use.
>>
>> On Wed, May 13, 2015 at 11:29 AM, Gail Badner <gbadner at redhat.com> wrote:
>>
>>> Adding hibernate-dev.
>>>
>>> No, I did not have a chance to read up on what you suggested. I sounded
>>> like it had some limitations that would not work, but maybe I
>>> misunderstood. I'll look into it today.
>>>
>>> The last couple of days have been very long. Sorry for the oversights.
>>>
>>> ----- Original Message -----
>>>> From: "Steve Ebersole" <steve at hibernate.org>
>>>> To: "Gail Badner" <gbadner at redhat.com>
>>>> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow" <
>>> smarlow at redhat.com>, "Galder Zamarre?o"
>>>> <galder at redhat.com>
>>>> Sent: Wednesday, May 13, 2015 5:33:24 AM
>>>> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
>>>>
>>>> On May 13, 2015 7:32 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
>>>>>
>>>>> 1) This really should be a hibernate-core discussion
>>>>
>>>> I meant to say hibernate-dev...
>>>>
>>>>> 2) I already suggested using forced version in Gradle and gave you a
>>> link
>>>> on how that works.  Did you read it?  Did you try it?
>>>>>
>>>>> On May 13, 2015 2:04 AM, "Gail Badner" <gbadner at redhat.com> wrote:
>>>>>>
>>>>>> Sanne, Scott, and I discussed how Hibernate should deal with
>>> supporting
>>>> Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it would
>>>> be sufficient to:
>>>>>> - specify the Infinispan 7.2 configuration by using
>>>> hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to switch if
>>>> parsing failed);
>>>>>> - run tests manually with Infinispan 7.2 for WildFly integration
>>> testing.
>>>>>>
>>>>>> I created another pull request:
>>>> https://github.com/hibernate/hibernate-orm/pull/953
>>>>>>
>>>>>> My pull request incorporated some of Galder's changes from
>>>> https://github.com/hibernate/hibernate-orm/pull/951.
>>>>>>
>>>>>> The main differences:
>>>>>> - Hibernate will consider the 7.2 configuration as test code
>>>>>> - the 7.2 configuration can be specified using
>>>>
>>> -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
>>>>>>
>>>>>> Currently, the only way to run hibernate-infinispan tests is to change
>>>> infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice to be
>>>> able to specify infinispanVersion as a environment variable, defaulting
>>> to
>>>> 6.0.0.Final to avoid having to manually update libraries.gradle.
>>>>>>
>>>>>> Another consideration is that manually updating libraries.gradle
>>> forces
>>>> a re-build using Infinispan 7.2.1 as a dependency.
>>>>>>
>>>>>> Since WildFly will use a hiberanate-infinispan jar build against
>>>> Infinispan 6.0.0.Final (won't it???), I think it would be best if we
>>> could
>>>> run unit tests without rebuilding with Infinispan 7.2.1, but using it as
>>> a
>>>> run time dependency. I haven't been able to figure out how to do that
>>>> though.
>>>>>>
>>>>>> Anyone have an idea how to do that, even manually?
>>>>>>
>>>>>> Thoughts on all this?
>>>>>>
>>>>>> Thanks,
>>>>>> Gail
>>>>
>>>
>>

From steve at hibernate.org  Wed May 13 16:52:47 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 May 2015 15:52:47 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAKnbemW4=M-fPspoYERbeZBq6tXc6+JJ8sLrcmLvG7HxJwom+g@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
	<CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
	<CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>
	<CAFdSV9twBZPcnrJZM9cP29fe039Xapj00W4c-RnugRo+-sDcTw@mail.gmail.com>
	<CAKnbemW4=M-fPspoYERbeZBq6tXc6+JJ8sLrcmLvG7HxJwom+g@mail.gmail.com>
Message-ID: <CAFdSV9viw_bsC_bMst87N9gZbMSyUjgmDrKCvoqpH4tjPueRgA@mail.gmail.com>

Nope.  Well, specifically yes your test fails as is.  But since you did not
simplify your environment, I took that opportunity and simplified it.  So I
sent you a PR that adds a new test using your model and successfully
running an schema update.  The only difference is that my test does not
have all this unnecessary Spring BS in the mix.

So no, I do not thinking this warrants a Hibernate Jira.  Until you can
simplify this to happen with just Hibernate in the picture.

On Wed, May 13, 2015 at 12:59 PM, Petar Tahchiev <paranoiabla at gmail.com>
wrote:

> Any luck on reproducing this?
>
> 2015-05-05 16:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> Petar, I have just been focusing on other things the past 3 days or so.
>> Chill :)
>>
>> I will look at this this week.  If you happen to have a chance to debug
>> it any further by then, that would rock.  FWIW, I do not think it is in any
>> way related to the duplicate secondary table warnings.  Those are
>> completely harmless I believe.  The FK naming logic has changed quite a bit
>> from pre-5.0 versions, my guess is that the issue lies there.  That or in
>> the logic to read existing FKs.
>>
>> On Tue, May 5, 2015 at 3:19 AM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Any of you have seen this issue? Shall I open a ticket?
>>>
>>> 2015-05-04 0:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>
>>> > Hi guys,
>>> >
>>> > I finally managed to reproduce it - here's a small application that
>>> will
>>> > generate the provided exception:
>>> >
>>> > https://github.com/paranoiabla/hibernate-hsql-issue
>>> >
>>> > Please notice that it works fine with Hibernate 4.3.x  I think it has
>>> to
>>> > do something with the CommerceCustomerModel - If I remove it or remove
>>> the
>>> > collection of payment infos that is inside of it, it all starts to work
>>> > fine.
>>> >
>>> > Please have a look and thanks a lot for your efforts :)
>>> >
>>> >
>>> >
>>> >
>>> > 2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>> >
>>> >> Hi guys,
>>> >>
>>> >> I just tried hibernate 5.0 beta2 and here's my observations. First of
>>> all
>>> >> the foreign key problems I had before seems to be resolved, however I
>>> see
>>> >> the following error when executing tests with HSQL:
>>> >>
>>> >>
>>> >> Caused by: org.springframework.beans.factory.BeanCreationException:
>>> Error
>>> >> creating bean with name 'defaultEntityManagerFactory' defined in
>>> class path
>>> >> resource
>>> [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
>>> >> Invocation of init method failed; nested exception is
>>> >> javax.persistence.PersistenceException: [PersistenceUnit: default]
>>> Unable
>>> >> to build Hibernate SessionFactory
>>> >>     at
>>> >>
>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
>>> >>     at
>>> >>
>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>>> >>     at
>>> >>
>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>>> >>     at
>>> >>
>>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
>>> >>     at
>>> >>
>>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>>> >>     at
>>> >>
>>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
>>> >>     at
>>> >>
>>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
>>> >>     at
>>> >>
>>> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
>>> >>     at
>>> >>
>>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
>>> >>     at
>>> >>
>>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
>>> >>     at
>>> >>
>>> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
>>> >>     at
>>> >>
>>> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
>>> >>     at
>>> >>
>>> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
>>> >>     at
>>> >>
>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
>>> >>     at
>>> >>
>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
>>> >>     ... 36 more
>>> >> Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
>>> >> default] Unable to build Hibernate SessionFactory
>>> >>     at
>>> >>
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
>>> >>     at
>>> >>
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
>>> >>     at
>>> >>
>>> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>>> >>     at
>>> >>
>>> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>>> >>     at
>>> >>
>>> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>>> >>     at
>>> >>
>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>>> >>     at
>>> >>
>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>>> >>     ... 50 more
>>> >> Caused by: org.hibernate.tool.schema.spi.SchemaManagementException:
>>> >> Unable to execute schema management to JDBC target [alter table
>>> >> payment_info add constraint FKs9wud9nve6s9cbot5p4548jyh foreign key
>>> >> (user_pk) references principal]
>>> >>     at
>>> >>
>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
>>> >>     at
>>> >>
>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
>>> >>     at
>>> >>
>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
>>> >>     at
>>> >>
>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
>>> >>     at
>>> >>
>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
>>> >>     at
>>> >>
>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
>>> >>     at
>>> >> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
>>> >>     at
>>> >> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
>>> >>     at
>>> >>
>>> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
>>> >>     at
>>> >>
>>> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
>>> >>     at
>>> >>
>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
>>> >>     ... 55 more
>>> >> Caused by: java.sql.SQLSyntaxErrorException: object name already
>>> exists:
>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table payment_info add
>>> >> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk)
>>> references
>>> >> principal]
>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>> >>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>>> >>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
>>> >>     at
>>> >>
>>> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
>>> >>     at
>>> >>
>>> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
>>> >>     at
>>> >>
>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
>>> >>     ... 65 more
>>> >> Caused by: org.hsqldb.HsqlException: object name already exists:
>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH
>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>> >>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
>>> >>     at org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown
>>> Source)
>>> >>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
>>> >>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
>>> >>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
>>> >>     at org.hsqldb.StatementSchema.execute(Unknown Source)
>>> >>     at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>> >>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>>> >>     at org.hsqldb.Session.execute(Unknown Source)
>>> >>     ... 70 more
>>> >>
>>> >>
>>> >> When running it with mysql it doesn't show this error (very strange)
>>> so I
>>> >> tried to export the schema to sql file and I can see only one foregin
>>> key
>>> >> declaration:
>>> >>
>>> >>     alter table payment_info
>>> >>         add constraint FKs9wud9nve6s9cbot5p4548jyh
>>> >>         foreign key (user_pk)
>>> >>         references principal (pk);
>>> >>
>>> >> Notice that this time it is lowercase. I'm trying to debug the hsql
>>> but
>>> >> it is very hard as it doesn't stop on any of the breakpoints I add.
>>> If any
>>> >> of you have an idea what might be causing it, please share your
>>> thoughts,
>>> >> if not I'll let you know how I progress.
>>> >>
>>> >> I wonder if it could be related to the duplicate joins warnings I see:
>>> >> WARN : HHH000072: Duplicate joins for class:
>>> >> com.nemesis.platform.core.model.media.MediaModel
>>> >> WARN : HHH000072: Duplicate joins for class:
>>> >>
>>> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
>>> >> WARN : HHH000072: Duplicate joins for class:
>>> >> com.nemesis.platform.core.model.cms.AbstractPageModel
>>> >> WARN : HHH000072: Duplicate joins for class:
>>> >> com.nemesis.platform.core.model.cms.EmailPageModel
>>> >> WARN : HHH000072: Duplicate joins for class:
>>> >> com.nemesis.platform.core.model.cms.CategoryPageModel
>>> >> .....
>>> >>
>>> >> --
>>> >> Regards, Petar!
>>> >> Karlovo, Bulgaria.
>>> >> ---
>>> >> Public PGP Key at:
>>> >>
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Regards, Petar!
>>> > Karlovo, Bulgaria.
>>> > ---
>>> > Public PGP Key at:
>>> >
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> >
>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From gbadner at redhat.com  Wed May 13 20:43:51 2015
From: gbadner at redhat.com (Gail Badner)
Date: Wed, 13 May 2015 20:43:51 -0400 (EDT)
Subject: [hibernate-dev] Another pull request for supporting Infinispan
	7.2.1 in 4.3
In-Reply-To: <55539E44.1080605@redhat.com>
References: <182273131.16549787.1431498665346.JavaMail.zimbra@redhat.com>
	<1640734682.16558940.1431500648918.JavaMail.zimbra@redhat.com>
	<CAFdSV9uGcd9-76pg5pVKE2Erk9htFOMJKAvwg+4aYRLXy0KR2Q@mail.gmail.com>
	<CAFdSV9uk8tNwNjb6hLJB1MHAPFu6qAPBQuG5=2n_Uu5PKPommA@mail.gmail.com>
	<1353579200.16905459.1431534551051.JavaMail.zimbra@redhat.com>
	<CAFdSV9vnAJ1S8=Cs6Sf2xNZkOqEmxZUu+WjW+4QngAaz_vQQzA@mail.gmail.com>
	<1178559274.16978227.1431542912778.JavaMail.zimbra@redhat.com>
	<55539E44.1080605@redhat.com>
Message-ID: <1239081321.17084617.1431564231880.JavaMail.zimbra@redhat.com>

I don't think I fully understand Gradle ResolutionStrategy. [1] 

I'm looking for something that could be used to change test runtime dependencies, without rebuilding the hibernate-infinspan jar. I'm not proficient enough with Gradle to know if ResolutionStrategy can be used for that, I'll have to look into it after 4.3.10.Final is released.

I did some experimenting though and found that by making the following change in libraries.gradle, I can test with a different version of Infinispan:

-    infinispanVersion = '6.0.0.Final'
+    infinispanVersion =  project.hasProperty( 'infinispanVersion' ) ? infinispanVersion : '6.0.0.Final'

I can force Hibernate to test using Infinispan 7.2.1.Final with the 7.2 test configuration using the command:
../gradlew test -PinfinispanVersion=7.2.1.Final -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml

Unfortunately, it forces source/test code to be rebuilt using Infinispan 7.2.1.Final. I would really like to be able to test using the hibernate-infinispan jar built using Infinispan 6.0.0.Final as a build dependency, because WildFly will be using the Hibernate 4.3.10.Final jar built with Infinispan 6.0.0.Final.

I'm going to move forward with releasing 4.3.10.Final and revisit this later.

Thanks everyone for your help on getting 4.3 to work with Infinispan 7.2.1.Final. It is very much appreciated.

Gail

[1] http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html 

----- Original Message -----
> From: "Scott Marlow" <smarlow at redhat.com>
> To: "Gail Badner" <gbadner at redhat.com>, "Steve Ebersole" <steve at hibernate.org>
> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Galder Zamarre?o" <galder at redhat.com>, "Hibernate Dev"
> <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, May 13, 2015 11:56:04 AM
> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> 
> 
> On 05/13/2015 02:48 PM, Gail Badner wrote:
> > As suggested by Sanne and Galder, I'll open a new Jira for the commit in my
> > pull request and amend the comment to reflect the new Jira.
> >
> > I'll see if I can get "forced version" in Gradle working in the next couple
> > of hours. If not, I don't want to hold up releasing 4.3.10.Final for this.
> > I can try to get those details worked out later.
> >
> > I think that about wraps up what is needed for Hibernate 4.3 to support and
> > test with Infinispan 7.2.1.Final.  Unless I hear otherwise, I plan to
> > release 4.3.10.Final later today, tomorrow at the latest.
> 
> Awesome, thanks for all of the help Gail in syncing Hibernate up to
> Infinispan 7.2.1!  Thanks to Sanne, Galder & Steve as well.  Very much
> appreciated!
> 
> I'm not sure of what will be in Infinispan 8.0 but that could need more
> hibernate-infinispan changes as well.  I think that Infinispan 8.0 might
> find its way into WildFly 10.
> 
> >
> > Regards,
> > Gail
> >
> > ----- Original Message -----
> >> From: "Steve Ebersole" <steve at hibernate.org>
> >> To: "Gail Badner" <gbadner at redhat.com>
> >> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow"
> >> <smarlow at redhat.com>, "Galder Zamarre?o"
> >> <galder at redhat.com>, "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> >> Sent: Wednesday, May 13, 2015 9:57:24 AM
> >> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> >>
> >> Not sure what limitations you mean.  All I said was that if you wanted to
> >> allow testing with both you would need to make this conditional and expose
> >> a property to control which to use.
> >>
> >> On Wed, May 13, 2015 at 11:29 AM, Gail Badner <gbadner at redhat.com> wrote:
> >>
> >>> Adding hibernate-dev.
> >>>
> >>> No, I did not have a chance to read up on what you suggested. I sounded
> >>> like it had some limitations that would not work, but maybe I
> >>> misunderstood. I'll look into it today.
> >>>
> >>> The last couple of days have been very long. Sorry for the oversights.
> >>>
> >>> ----- Original Message -----
> >>>> From: "Steve Ebersole" <steve at hibernate.org>
> >>>> To: "Gail Badner" <gbadner at redhat.com>
> >>>> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow" <
> >>> smarlow at redhat.com>, "Galder Zamarre?o"
> >>>> <galder at redhat.com>
> >>>> Sent: Wednesday, May 13, 2015 5:33:24 AM
> >>>> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> >>>>
> >>>> On May 13, 2015 7:32 AM, "Steve Ebersole" <steve at hibernate.org> wrote:
> >>>>>
> >>>>> 1) This really should be a hibernate-core discussion
> >>>>
> >>>> I meant to say hibernate-dev...
> >>>>
> >>>>> 2) I already suggested using forced version in Gradle and gave you a
> >>> link
> >>>> on how that works.  Did you read it?  Did you try it?
> >>>>>
> >>>>> On May 13, 2015 2:04 AM, "Gail Badner" <gbadner at redhat.com> wrote:
> >>>>>>
> >>>>>> Sanne, Scott, and I discussed how Hibernate should deal with
> >>> supporting
> >>>> Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it
> >>>> would
> >>>> be sufficient to:
> >>>>>> - specify the Infinispan 7.2 configuration by using
> >>>> hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to switch if
> >>>> parsing failed);
> >>>>>> - run tests manually with Infinispan 7.2 for WildFly integration
> >>> testing.
> >>>>>>
> >>>>>> I created another pull request:
> >>>> https://github.com/hibernate/hibernate-orm/pull/953
> >>>>>>
> >>>>>> My pull request incorporated some of Galder's changes from
> >>>> https://github.com/hibernate/hibernate-orm/pull/951.
> >>>>>>
> >>>>>> The main differences:
> >>>>>> - Hibernate will consider the 7.2 configuration as test code
> >>>>>> - the 7.2 configuration can be specified using
> >>>>
> >>> -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> >>>>>>
> >>>>>> Currently, the only way to run hibernate-infinispan tests is to change
> >>>> infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice to
> >>>> be
> >>>> able to specify infinispanVersion as a environment variable, defaulting
> >>> to
> >>>> 6.0.0.Final to avoid having to manually update libraries.gradle.
> >>>>>>
> >>>>>> Another consideration is that manually updating libraries.gradle
> >>> forces
> >>>> a re-build using Infinispan 7.2.1 as a dependency.
> >>>>>>
> >>>>>> Since WildFly will use a hiberanate-infinispan jar build against
> >>>> Infinispan 6.0.0.Final (won't it???), I think it would be best if we
> >>> could
> >>>> run unit tests without rebuilding with Infinispan 7.2.1, but using it as
> >>> a
> >>>> run time dependency. I haven't been able to figure out how to do that
> >>>> though.
> >>>>>>
> >>>>>> Anyone have an idea how to do that, even manually?
> >>>>>>
> >>>>>> Thoughts on all this?
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Gail
> >>>>
> >>>
> >>
> 


From steve at hibernate.org  Wed May 13 22:03:19 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 13 May 2015 21:03:19 -0500
Subject: [hibernate-dev] Another pull request for supporting Infinispan
	7.2.1 in 4.3
In-Reply-To: <1239081321.17084617.1431564231880.JavaMail.zimbra@redhat.com>
References: <182273131.16549787.1431498665346.JavaMail.zimbra@redhat.com>
	<1640734682.16558940.1431500648918.JavaMail.zimbra@redhat.com>
	<CAFdSV9uGcd9-76pg5pVKE2Erk9htFOMJKAvwg+4aYRLXy0KR2Q@mail.gmail.com>
	<CAFdSV9uk8tNwNjb6hLJB1MHAPFu6qAPBQuG5=2n_Uu5PKPommA@mail.gmail.com>
	<1353579200.16905459.1431534551051.JavaMail.zimbra@redhat.com>
	<CAFdSV9vnAJ1S8=Cs6Sf2xNZkOqEmxZUu+WjW+4QngAaz_vQQzA@mail.gmail.com>
	<1178559274.16978227.1431542912778.JavaMail.zimbra@redhat.com>
	<55539E44.1080605@redhat.com>
	<1239081321.17084617.1431564231880.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9ve-oPaEdBfYeRiGJM_5etxPyfLad0dNFPY3Q4HwswMgA@mail.gmail.com>

Well you have to realize that there are 3 classpaths involved here:
1) compiling the main sources (compile)
2) compiling the test sources (testCompile)
3) running the tests (testRuntime)

You can set each of those differently.  But instead what you do is to
change all 3 to the same value.  Obviously if you ask Gradle to compile
with a different Infinispan version by specifying it in compile
Configuration it is going to recognize that and recompile the main
sources.  That's a GoodThing(tm).  But really you are doing the wrong
thing.  Really you just want to keep the same Infinispan version
(6.whatever) for compile and testCompile.  You really just want variance in
testRuntime.

The one concern with this is that Gradle willl then see a "version
conflict".  It will see Infinispan 6 in the compile and testCompile (via
compile) configurations, and Infinispan 7 in the testRuntime
configuration.  I am not exactly sure what Gradle will do there.  But I do
know that you can tell Gradle what to do there... by forcing the version.
In fact ResolutionStrategy is all about these "version conflicts" and what
to do.

So something like this in hibernate-infinispan.gradle:

if ( useInfinispan7ForTesting() ) {
    configurations {
        testRuntime {
            resolutionStrategy {
                force 'org.infinispan:infinispan-core:7.2.1.Final`
            }
        }
    }
}

dependencies {
    compile( libraries.infinispan ) // 6, as before
    ...
}

I actually think you can use force to force the version to use even if it
is not a case of a version conflict.  That's what the above tries.  In
testRuntime there really is not version conflict
for 'org.infinispan:infinispan-core', but we ask Gradle to force
the 'org.infinispan:infinispan-core' version to 7.2.1.Final.  That is my
reading of how forced versions work based on the DSL guide.  I have not
tried it myself, so I do not know how it works in practice.


On Wed, May 13, 2015 at 7:43 PM, Gail Badner <gbadner at redhat.com> wrote:

> I don't think I fully understand Gradle ResolutionStrategy. [1]
>
> I'm looking for something that could be used to change test runtime
> dependencies, without rebuilding the hibernate-infinspan jar. I'm not
> proficient enough with Gradle to know if ResolutionStrategy can be used for
> that, I'll have to look into it after 4.3.10.Final is released.
>
> I did some experimenting though and found that by making the following
> change in libraries.gradle, I can test with a different version of
> Infinispan:
>
> -    infinispanVersion = '6.0.0.Final'
> +    infinispanVersion =  project.hasProperty( 'infinispanVersion' ) ?
> infinispanVersion : '6.0.0.Final'
>
> I can force Hibernate to test using Infinispan 7.2.1.Final with the 7.2
> test configuration using the command:
> ../gradlew test -PinfinispanVersion=7.2.1.Final
> -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
>
> Unfortunately, it forces source/test code to be rebuilt using Infinispan
> 7.2.1.Final. I would really like to be able to test using the
> hibernate-infinispan jar built using Infinispan 6.0.0.Final as a build
> dependency, because WildFly will be using the Hibernate 4.3.10.Final jar
> built with Infinispan 6.0.0.Final.
>
> I'm going to move forward with releasing 4.3.10.Final and revisit this
> later.
>
> Thanks everyone for your help on getting 4.3 to work with Infinispan
> 7.2.1.Final. It is very much appreciated.
>
> Gail
>
> [1]
> http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html
>
> ----- Original Message -----
> > From: "Scott Marlow" <smarlow at redhat.com>
> > To: "Gail Badner" <gbadner at redhat.com>, "Steve Ebersole" <
> steve at hibernate.org>
> > Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Galder Zamarre?o" <
> galder at redhat.com>, "Hibernate Dev"
> > <hibernate-dev at lists.jboss.org>
> > Sent: Wednesday, May 13, 2015 11:56:04 AM
> > Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> >
> >
> > On 05/13/2015 02:48 PM, Gail Badner wrote:
> > > As suggested by Sanne and Galder, I'll open a new Jira for the commit
> in my
> > > pull request and amend the comment to reflect the new Jira.
> > >
> > > I'll see if I can get "forced version" in Gradle working in the next
> couple
> > > of hours. If not, I don't want to hold up releasing 4.3.10.Final for
> this.
> > > I can try to get those details worked out later.
> > >
> > > I think that about wraps up what is needed for Hibernate 4.3 to
> support and
> > > test with Infinispan 7.2.1.Final.  Unless I hear otherwise, I plan to
> > > release 4.3.10.Final later today, tomorrow at the latest.
> >
> > Awesome, thanks for all of the help Gail in syncing Hibernate up to
> > Infinispan 7.2.1!  Thanks to Sanne, Galder & Steve as well.  Very much
> > appreciated!
> >
> > I'm not sure of what will be in Infinispan 8.0 but that could need more
> > hibernate-infinispan changes as well.  I think that Infinispan 8.0 might
> > find its way into WildFly 10.
> >
> > >
> > > Regards,
> > > Gail
> > >
> > > ----- Original Message -----
> > >> From: "Steve Ebersole" <steve at hibernate.org>
> > >> To: "Gail Badner" <gbadner at redhat.com>
> > >> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow"
> > >> <smarlow at redhat.com>, "Galder Zamarre?o"
> > >> <galder at redhat.com>, "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > >> Sent: Wednesday, May 13, 2015 9:57:24 AM
> > >> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in
> 4.3
> > >>
> > >> Not sure what limitations you mean.  All I said was that if you
> wanted to
> > >> allow testing with both you would need to make this conditional and
> expose
> > >> a property to control which to use.
> > >>
> > >> On Wed, May 13, 2015 at 11:29 AM, Gail Badner <gbadner at redhat.com>
> wrote:
> > >>
> > >>> Adding hibernate-dev.
> > >>>
> > >>> No, I did not have a chance to read up on what you suggested. I
> sounded
> > >>> like it had some limitations that would not work, but maybe I
> > >>> misunderstood. I'll look into it today.
> > >>>
> > >>> The last couple of days have been very long. Sorry for the
> oversights.
> > >>>
> > >>> ----- Original Message -----
> > >>>> From: "Steve Ebersole" <steve at hibernate.org>
> > >>>> To: "Gail Badner" <gbadner at redhat.com>
> > >>>> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow" <
> > >>> smarlow at redhat.com>, "Galder Zamarre?o"
> > >>>> <galder at redhat.com>
> > >>>> Sent: Wednesday, May 13, 2015 5:33:24 AM
> > >>>> Subject: Re: Another pull request for supporting Infinispan 7.2.1
> in 4.3
> > >>>>
> > >>>> On May 13, 2015 7:32 AM, "Steve Ebersole" <steve at hibernate.org>
> wrote:
> > >>>>>
> > >>>>> 1) This really should be a hibernate-core discussion
> > >>>>
> > >>>> I meant to say hibernate-dev...
> > >>>>
> > >>>>> 2) I already suggested using forced version in Gradle and gave you
> a
> > >>> link
> > >>>> on how that works.  Did you read it?  Did you try it?
> > >>>>>
> > >>>>> On May 13, 2015 2:04 AM, "Gail Badner" <gbadner at redhat.com> wrote:
> > >>>>>>
> > >>>>>> Sanne, Scott, and I discussed how Hibernate should deal with
> > >>> supporting
> > >>>> Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it
> > >>>> would
> > >>>> be sufficient to:
> > >>>>>> - specify the Infinispan 7.2 configuration by using
> > >>>> hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to
> switch if
> > >>>> parsing failed);
> > >>>>>> - run tests manually with Infinispan 7.2 for WildFly integration
> > >>> testing.
> > >>>>>>
> > >>>>>> I created another pull request:
> > >>>> https://github.com/hibernate/hibernate-orm/pull/953
> > >>>>>>
> > >>>>>> My pull request incorporated some of Galder's changes from
> > >>>> https://github.com/hibernate/hibernate-orm/pull/951.
> > >>>>>>
> > >>>>>> The main differences:
> > >>>>>> - Hibernate will consider the 7.2 configuration as test code
> > >>>>>> - the 7.2 configuration can be specified using
> > >>>>
> > >>>
> -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> > >>>>>>
> > >>>>>> Currently, the only way to run hibernate-infinispan tests is to
> change
> > >>>> infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice
> to
> > >>>> be
> > >>>> able to specify infinispanVersion as a environment variable,
> defaulting
> > >>> to
> > >>>> 6.0.0.Final to avoid having to manually update libraries.gradle.
> > >>>>>>
> > >>>>>> Another consideration is that manually updating libraries.gradle
> > >>> forces
> > >>>> a re-build using Infinispan 7.2.1 as a dependency.
> > >>>>>>
> > >>>>>> Since WildFly will use a hiberanate-infinispan jar build against
> > >>>> Infinispan 6.0.0.Final (won't it???), I think it would be best if we
> > >>> could
> > >>>> run unit tests without rebuilding with Infinispan 7.2.1, but using
> it as
> > >>> a
> > >>>> run time dependency. I haven't been able to figure out how to do
> that
> > >>>> though.
> > >>>>>>
> > >>>>>> Anyone have an idea how to do that, even manually?
> > >>>>>>
> > >>>>>> Thoughts on all this?
> > >>>>>>
> > >>>>>> Thanks,
> > >>>>>> Gail
> > >>>>
> > >>>
> > >>
> >
>

From gbadner at redhat.com  Thu May 14 01:23:28 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 14 May 2015 01:23:28 -0400 (EDT)
Subject: [hibernate-dev] Another pull request for supporting Infinispan
	7.2.1 in 4.3
In-Reply-To: <CAFdSV9ve-oPaEdBfYeRiGJM_5etxPyfLad0dNFPY3Q4HwswMgA@mail.gmail.com>
References: <182273131.16549787.1431498665346.JavaMail.zimbra@redhat.com>
	<CAFdSV9uk8tNwNjb6hLJB1MHAPFu6qAPBQuG5=2n_Uu5PKPommA@mail.gmail.com>
	<1353579200.16905459.1431534551051.JavaMail.zimbra@redhat.com>
	<CAFdSV9vnAJ1S8=Cs6Sf2xNZkOqEmxZUu+WjW+4QngAaz_vQQzA@mail.gmail.com>
	<1178559274.16978227.1431542912778.JavaMail.zimbra@redhat.com>
	<55539E44.1080605@redhat.com>
	<1239081321.17084617.1431564231880.JavaMail.zimbra@redhat.com>
	<CAFdSV9ve-oPaEdBfYeRiGJM_5etxPyfLad0dNFPY3Q4HwswMgA@mail.gmail.com>
Message-ID: <1494880914.17134375.1431581008556.JavaMail.zimbra@redhat.com>

Hi Steve,

Thanks for the explanation. That helps a lot. I'll see if I can get it working tomorrow morning.

I'll release 4.3.10.Final Thursday. After working 3 late nights in a row, I need to rest tonight.

Regards,
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Scott Marlow" <smarlow at redhat.com>, "Sanne Grinovero" <sanne at hibernate.org>, "Galder Zamarre?o"
> <galder at redhat.com>, "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Wednesday, May 13, 2015 7:03:19 PM
> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> 
> Well you have to realize that there are 3 classpaths involved here:
> 1) compiling the main sources (compile)
> 2) compiling the test sources (testCompile)
> 3) running the tests (testRuntime)
> 
> You can set each of those differently.  But instead what you do is to
> change all 3 to the same value.  Obviously if you ask Gradle to compile
> with a different Infinispan version by specifying it in compile
> Configuration it is going to recognize that and recompile the main
> sources.  That's a GoodThing(tm).  But really you are doing the wrong
> thing.  Really you just want to keep the same Infinispan version
> (6.whatever) for compile and testCompile.  You really just want variance in
> testRuntime.
> 
> The one concern with this is that Gradle willl then see a "version
> conflict".  It will see Infinispan 6 in the compile and testCompile (via
> compile) configurations, and Infinispan 7 in the testRuntime
> configuration.  I am not exactly sure what Gradle will do there.  But I do
> know that you can tell Gradle what to do there... by forcing the version.
> In fact ResolutionStrategy is all about these "version conflicts" and what
> to do.
> 
> So something like this in hibernate-infinispan.gradle:
> 
> if ( useInfinispan7ForTesting() ) {
>     configurations {
>         testRuntime {
>             resolutionStrategy {
>                 force 'org.infinispan:infinispan-core:7.2.1.Final`
>             }
>         }
>     }
> }
> 
> dependencies {
>     compile( libraries.infinispan ) // 6, as before
>     ...
> }
> 
> I actually think you can use force to force the version to use even if it
> is not a case of a version conflict.  That's what the above tries.  In
> testRuntime there really is not version conflict
> for 'org.infinispan:infinispan-core', but we ask Gradle to force
> the 'org.infinispan:infinispan-core' version to 7.2.1.Final.  That is my
> reading of how forced versions work based on the DSL guide.  I have not
> tried it myself, so I do not know how it works in practice.
> 
> 
> On Wed, May 13, 2015 at 7:43 PM, Gail Badner <gbadner at redhat.com> wrote:
> 
> > I don't think I fully understand Gradle ResolutionStrategy. [1]
> >
> > I'm looking for something that could be used to change test runtime
> > dependencies, without rebuilding the hibernate-infinspan jar. I'm not
> > proficient enough with Gradle to know if ResolutionStrategy can be used for
> > that, I'll have to look into it after 4.3.10.Final is released.
> >
> > I did some experimenting though and found that by making the following
> > change in libraries.gradle, I can test with a different version of
> > Infinispan:
> >
> > -    infinispanVersion = '6.0.0.Final'
> > +    infinispanVersion =  project.hasProperty( 'infinispanVersion' ) ?
> > infinispanVersion : '6.0.0.Final'
> >
> > I can force Hibernate to test using Infinispan 7.2.1.Final with the 7.2
> > test configuration using the command:
> > ../gradlew test -PinfinispanVersion=7.2.1.Final
> > -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> >
> > Unfortunately, it forces source/test code to be rebuilt using Infinispan
> > 7.2.1.Final. I would really like to be able to test using the
> > hibernate-infinispan jar built using Infinispan 6.0.0.Final as a build
> > dependency, because WildFly will be using the Hibernate 4.3.10.Final jar
> > built with Infinispan 6.0.0.Final.
> >
> > I'm going to move forward with releasing 4.3.10.Final and revisit this
> > later.
> >
> > Thanks everyone for your help on getting 4.3 to work with Infinispan
> > 7.2.1.Final. It is very much appreciated.
> >
> > Gail
> >
> > [1]
> > http://gradle.org/docs/current/dsl/org.gradle.api.artifacts.ResolutionStrategy.html
> >
> > ----- Original Message -----
> > > From: "Scott Marlow" <smarlow at redhat.com>
> > > To: "Gail Badner" <gbadner at redhat.com>, "Steve Ebersole" <
> > steve at hibernate.org>
> > > Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Galder Zamarre?o" <
> > galder at redhat.com>, "Hibernate Dev"
> > > <hibernate-dev at lists.jboss.org>
> > > Sent: Wednesday, May 13, 2015 11:56:04 AM
> > > Subject: Re: Another pull request for supporting Infinispan 7.2.1 in 4.3
> > >
> > >
> > > On 05/13/2015 02:48 PM, Gail Badner wrote:
> > > > As suggested by Sanne and Galder, I'll open a new Jira for the commit
> > in my
> > > > pull request and amend the comment to reflect the new Jira.
> > > >
> > > > I'll see if I can get "forced version" in Gradle working in the next
> > couple
> > > > of hours. If not, I don't want to hold up releasing 4.3.10.Final for
> > this.
> > > > I can try to get those details worked out later.
> > > >
> > > > I think that about wraps up what is needed for Hibernate 4.3 to
> > support and
> > > > test with Infinispan 7.2.1.Final.  Unless I hear otherwise, I plan to
> > > > release 4.3.10.Final later today, tomorrow at the latest.
> > >
> > > Awesome, thanks for all of the help Gail in syncing Hibernate up to
> > > Infinispan 7.2.1!  Thanks to Sanne, Galder & Steve as well.  Very much
> > > appreciated!
> > >
> > > I'm not sure of what will be in Infinispan 8.0 but that could need more
> > > hibernate-infinispan changes as well.  I think that Infinispan 8.0 might
> > > find its way into WildFly 10.
> > >
> > > >
> > > > Regards,
> > > > Gail
> > > >
> > > > ----- Original Message -----
> > > >> From: "Steve Ebersole" <steve at hibernate.org>
> > > >> To: "Gail Badner" <gbadner at redhat.com>
> > > >> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow"
> > > >> <smarlow at redhat.com>, "Galder Zamarre?o"
> > > >> <galder at redhat.com>, "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > > >> Sent: Wednesday, May 13, 2015 9:57:24 AM
> > > >> Subject: Re: Another pull request for supporting Infinispan 7.2.1 in
> > 4.3
> > > >>
> > > >> Not sure what limitations you mean.  All I said was that if you
> > wanted to
> > > >> allow testing with both you would need to make this conditional and
> > expose
> > > >> a property to control which to use.
> > > >>
> > > >> On Wed, May 13, 2015 at 11:29 AM, Gail Badner <gbadner at redhat.com>
> > wrote:
> > > >>
> > > >>> Adding hibernate-dev.
> > > >>>
> > > >>> No, I did not have a chance to read up on what you suggested. I
> > sounded
> > > >>> like it had some limitations that would not work, but maybe I
> > > >>> misunderstood. I'll look into it today.
> > > >>>
> > > >>> The last couple of days have been very long. Sorry for the
> > oversights.
> > > >>>
> > > >>> ----- Original Message -----
> > > >>>> From: "Steve Ebersole" <steve at hibernate.org>
> > > >>>> To: "Gail Badner" <gbadner at redhat.com>
> > > >>>> Cc: "Sanne Grinovero" <sanne at hibernate.org>, "Scott Marlow" <
> > > >>> smarlow at redhat.com>, "Galder Zamarre?o"
> > > >>>> <galder at redhat.com>
> > > >>>> Sent: Wednesday, May 13, 2015 5:33:24 AM
> > > >>>> Subject: Re: Another pull request for supporting Infinispan 7.2.1
> > in 4.3
> > > >>>>
> > > >>>> On May 13, 2015 7:32 AM, "Steve Ebersole" <steve at hibernate.org>
> > wrote:
> > > >>>>>
> > > >>>>> 1) This really should be a hibernate-core discussion
> > > >>>>
> > > >>>> I meant to say hibernate-dev...
> > > >>>>
> > > >>>>> 2) I already suggested using forced version in Gradle and gave you
> > a
> > > >>> link
> > > >>>> on how that works.  Did you read it?  Did you try it?
> > > >>>>>
> > > >>>>> On May 13, 2015 2:04 AM, "Gail Badner" <gbadner at redhat.com> wrote:
> > > >>>>>>
> > > >>>>>> Sanne, Scott, and I discussed how Hibernate should deal with
> > > >>> supporting
> > > >>>> Infinispan 7.2.1 in 4.3 earlier today. I think the consensus was it
> > > >>>> would
> > > >>>> be sufficient to:
> > > >>>>>> - specify the Infinispan 7.2 configuration by using
> > > >>>> hibernate.cache.infinispan.cfg (so Hibernate wouldn't have to
> > switch if
> > > >>>> parsing failed);
> > > >>>>>> - run tests manually with Infinispan 7.2 for WildFly integration
> > > >>> testing.
> > > >>>>>>
> > > >>>>>> I created another pull request:
> > > >>>> https://github.com/hibernate/hibernate-orm/pull/953
> > > >>>>>>
> > > >>>>>> My pull request incorporated some of Galder's changes from
> > > >>>> https://github.com/hibernate/hibernate-orm/pull/951.
> > > >>>>>>
> > > >>>>>> The main differences:
> > > >>>>>> - Hibernate will consider the 7.2 configuration as test code
> > > >>>>>> - the 7.2 configuration can be specified using
> > > >>>>
> > > >>>
> > -Dhibernate.cache.infinispan.cfg=src/test/resources/infinispan-7-configs.xml
> > > >>>>>>
> > > >>>>>> Currently, the only way to run hibernate-infinispan tests is to
> > change
> > > >>>> infinispanVersion from 6.0.0.Final to 7.2.1.Final. It would be nice
> > to
> > > >>>> be
> > > >>>> able to specify infinispanVersion as a environment variable,
> > defaulting
> > > >>> to
> > > >>>> 6.0.0.Final to avoid having to manually update libraries.gradle.
> > > >>>>>>
> > > >>>>>> Another consideration is that manually updating libraries.gradle
> > > >>> forces
> > > >>>> a re-build using Infinispan 7.2.1 as a dependency.
> > > >>>>>>
> > > >>>>>> Since WildFly will use a hiberanate-infinispan jar build against
> > > >>>> Infinispan 6.0.0.Final (won't it???), I think it would be best if we
> > > >>> could
> > > >>>> run unit tests without rebuilding with Infinispan 7.2.1, but using
> > it as
> > > >>> a
> > > >>>> run time dependency. I haven't been able to figure out how to do
> > that
> > > >>>> though.
> > > >>>>>>
> > > >>>>>> Anyone have an idea how to do that, even manually?
> > > >>>>>>
> > > >>>>>> Thoughts on all this?
> > > >>>>>>
> > > >>>>>> Thanks,
> > > >>>>>> Gail
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> 


From steve at hibernate.org  Thu May 14 12:27:29 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 May 2015 11:27:29 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAFdSV9viw_bsC_bMst87N9gZbMSyUjgmDrKCvoqpH4tjPueRgA@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
	<CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
	<CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>
	<CAFdSV9twBZPcnrJZM9cP29fe039Xapj00W4c-RnugRo+-sDcTw@mail.gmail.com>
	<CAKnbemW4=M-fPspoYERbeZBq6tXc6+JJ8sLrcmLvG7HxJwom+g@mail.gmail.com>
	<CAFdSV9viw_bsC_bMst87N9gZbMSyUjgmDrKCvoqpH4tjPueRgA@mail.gmail.com>
Message-ID: <CAFdSV9uLCBSjf+GRtzbsOK5YjbTWL07dRA7ADRB15taGafXpSA@mail.gmail.com>

No word on the new test case I take it?

WRT the HHH000072 logged warnings, like i said the warning is inocuous.
But I did correct it: https://hibernate.atlassian.net/browse/HHH-9797

On Wed, May 13, 2015 at 3:52 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Nope.  Well, specifically yes your test fails as is.  But since you did
> not simplify your environment, I took that opportunity and simplified it.
> So I sent you a PR that adds a new test using your model and successfully
> running an schema update.  The only difference is that my test does not
> have all this unnecessary Spring BS in the mix.
>
> So no, I do not thinking this warrants a Hibernate Jira.  Until you can
> simplify this to happen with just Hibernate in the picture.
>
> On Wed, May 13, 2015 at 12:59 PM, Petar Tahchiev <paranoiabla at gmail.com>
> wrote:
>
>> Any luck on reproducing this?
>>
>> 2015-05-05 16:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> Petar, I have just been focusing on other things the past 3 days or so.
>>> Chill :)
>>>
>>> I will look at this this week.  If you happen to have a chance to debug
>>> it any further by then, that would rock.  FWIW, I do not think it is in any
>>> way related to the duplicate secondary table warnings.  Those are
>>> completely harmless I believe.  The FK naming logic has changed quite a bit
>>> from pre-5.0 versions, my guess is that the issue lies there.  That or in
>>> the logic to read existing FKs.
>>>
>>> On Tue, May 5, 2015 at 3:19 AM, Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>> Any of you have seen this issue? Shall I open a ticket?
>>>>
>>>> 2015-05-04 0:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>
>>>> > Hi guys,
>>>> >
>>>> > I finally managed to reproduce it - here's a small application that
>>>> will
>>>> > generate the provided exception:
>>>> >
>>>> > https://github.com/paranoiabla/hibernate-hsql-issue
>>>> >
>>>> > Please notice that it works fine with Hibernate 4.3.x  I think it has
>>>> to
>>>> > do something with the CommerceCustomerModel - If I remove it or
>>>> remove the
>>>> > collection of payment infos that is inside of it, it all starts to
>>>> work
>>>> > fine.
>>>> >
>>>> > Please have a look and thanks a lot for your efforts :)
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > 2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>> >
>>>> >> Hi guys,
>>>> >>
>>>> >> I just tried hibernate 5.0 beta2 and here's my observations. First
>>>> of all
>>>> >> the foreign key problems I had before seems to be resolved, however
>>>> I see
>>>> >> the following error when executing tests with HSQL:
>>>> >>
>>>> >>
>>>> >> Caused by: org.springframework.beans.factory.BeanCreationException:
>>>> Error
>>>> >> creating bean with name 'defaultEntityManagerFactory' defined in
>>>> class path
>>>> >> resource
>>>> [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
>>>> >> Invocation of init method failed; nested exception is
>>>> >> javax.persistence.PersistenceException: [PersistenceUnit: default]
>>>> Unable
>>>> >> to build Hibernate SessionFactory
>>>> >>     at
>>>> >>
>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
>>>> >>     at
>>>> >>
>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>>>> >>     at
>>>> >>
>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>>>> >>     at
>>>> >>
>>>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
>>>> >>     at
>>>> >>
>>>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>>>> >>     at
>>>> >>
>>>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
>>>> >>     at
>>>> >>
>>>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
>>>> >>     at
>>>> >>
>>>> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
>>>> >>     at
>>>> >>
>>>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
>>>> >>     at
>>>> >>
>>>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
>>>> >>     at
>>>> >>
>>>> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
>>>> >>     at
>>>> >>
>>>> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
>>>> >>     at
>>>> >>
>>>> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
>>>> >>     at
>>>> >>
>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
>>>> >>     at
>>>> >>
>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
>>>> >>     ... 36 more
>>>> >> Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
>>>> >> default] Unable to build Hibernate SessionFactory
>>>> >>     at
>>>> >>
>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
>>>> >>     at
>>>> >>
>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
>>>> >>     at
>>>> >>
>>>> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>>>> >>     at
>>>> >>
>>>> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>>>> >>     at
>>>> >>
>>>> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>>>> >>     at
>>>> >>
>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>>>> >>     at
>>>> >>
>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>>>> >>     ... 50 more
>>>> >> Caused by: org.hibernate.tool.schema.spi.SchemaManagementException:
>>>> >> Unable to execute schema management to JDBC target [alter table
>>>> >> payment_info add constraint FKs9wud9nve6s9cbot5p4548jyh foreign key
>>>> >> (user_pk) references principal]
>>>> >>     at
>>>> >>
>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
>>>> >>     at
>>>> >>
>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
>>>> >>     at
>>>> >>
>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
>>>> >>     at
>>>> >>
>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
>>>> >>     at
>>>> >>
>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
>>>> >>     at
>>>> >>
>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
>>>> >>     at
>>>> >>
>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
>>>> >>     at
>>>> >>
>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
>>>> >>     at
>>>> >>
>>>> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
>>>> >>     at
>>>> >>
>>>> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
>>>> >>     at
>>>> >>
>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
>>>> >>     ... 55 more
>>>> >> Caused by: java.sql.SQLSyntaxErrorException: object name already
>>>> exists:
>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table payment_info
>>>> add
>>>> >> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk)
>>>> references
>>>> >> principal]
>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>> >>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>>>> >>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
>>>> >>     at
>>>> >>
>>>> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
>>>> >>     at
>>>> >>
>>>> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
>>>> >>     at
>>>> >>
>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
>>>> >>     ... 65 more
>>>> >> Caused by: org.hsqldb.HsqlException: object name already exists:
>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH
>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>> >>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
>>>> >>     at org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown
>>>> Source)
>>>> >>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
>>>> >>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
>>>> >>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
>>>> >>     at org.hsqldb.StatementSchema.execute(Unknown Source)
>>>> >>     at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>>> >>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>>>> >>     at org.hsqldb.Session.execute(Unknown Source)
>>>> >>     ... 70 more
>>>> >>
>>>> >>
>>>> >> When running it with mysql it doesn't show this error (very strange)
>>>> so I
>>>> >> tried to export the schema to sql file and I can see only one
>>>> foregin key
>>>> >> declaration:
>>>> >>
>>>> >>     alter table payment_info
>>>> >>         add constraint FKs9wud9nve6s9cbot5p4548jyh
>>>> >>         foreign key (user_pk)
>>>> >>         references principal (pk);
>>>> >>
>>>> >> Notice that this time it is lowercase. I'm trying to debug the hsql
>>>> but
>>>> >> it is very hard as it doesn't stop on any of the breakpoints I add.
>>>> If any
>>>> >> of you have an idea what might be causing it, please share your
>>>> thoughts,
>>>> >> if not I'll let you know how I progress.
>>>> >>
>>>> >> I wonder if it could be related to the duplicate joins warnings I
>>>> see:
>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>> >> com.nemesis.platform.core.model.media.MediaModel
>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>> >>
>>>> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>> >> com.nemesis.platform.core.model.cms.AbstractPageModel
>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>> >> com.nemesis.platform.core.model.cms.EmailPageModel
>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>> >> com.nemesis.platform.core.model.cms.CategoryPageModel
>>>> >> .....
>>>> >>
>>>> >> --
>>>> >> Regards, Petar!
>>>> >> Karlovo, Bulgaria.
>>>> >> ---
>>>> >> Public PGP Key at:
>>>> >>
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Regards, Petar!
>>>> > Karlovo, Bulgaria.
>>>> > ---
>>>> > Public PGP Key at:
>>>> >
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> ---
>>>> Public PGP Key at:
>>>>
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>
>>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>
>

From paranoiabla at gmail.com  Thu May 14 12:30:06 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Thu, 14 May 2015 19:30:06 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAFdSV9uLCBSjf+GRtzbsOK5YjbTWL07dRA7ADRB15taGafXpSA@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
	<CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
	<CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>
	<CAFdSV9twBZPcnrJZM9cP29fe039Xapj00W4c-RnugRo+-sDcTw@mail.gmail.com>
	<CAKnbemW4=M-fPspoYERbeZBq6tXc6+JJ8sLrcmLvG7HxJwom+g@mail.gmail.com>
	<CAFdSV9viw_bsC_bMst87N9gZbMSyUjgmDrKCvoqpH4tjPueRgA@mail.gmail.com>
	<CAFdSV9uLCBSjf+GRtzbsOK5YjbTWL07dRA7ADRB15taGafXpSA@mail.gmail.com>
Message-ID: <CAKnbemUC2cHYvyBQpxxeNNovJn+gS+7XAJg00S=UQbzuYaDvVQ@mail.gmail.com>

Hi Steve,

your test indeed works fine - I logged here
https://jira.spring.io/browse/SPR-11694 so that the spring guys will have a
look, but I don't think spring is doing any magic on the foreign keys.
Juergen Hoeller from spring proposed it might be a bug in Hibernate's
EntityManager implementation.

I wish we could find out where the problem, but I'm not really that good to
investigate further.

2015-05-14 19:27 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> No word on the new test case I take it?
>
> WRT the HHH000072 logged warnings, like i said the warning is inocuous.
> But I did correct it: https://hibernate.atlassian.net/browse/HHH-9797
>
> On Wed, May 13, 2015 at 3:52 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Nope.  Well, specifically yes your test fails as is.  But since you did
>> not simplify your environment, I took that opportunity and simplified it.
>> So I sent you a PR that adds a new test using your model and successfully
>> running an schema update.  The only difference is that my test does not
>> have all this unnecessary Spring BS in the mix.
>>
>> So no, I do not thinking this warrants a Hibernate Jira.  Until you can
>> simplify this to happen with just Hibernate in the picture.
>>
>> On Wed, May 13, 2015 at 12:59 PM, Petar Tahchiev <paranoiabla at gmail.com>
>> wrote:
>>
>>> Any luck on reproducing this?
>>>
>>> 2015-05-05 16:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> Petar, I have just been focusing on other things the past 3 days or
>>>> so.  Chill :)
>>>>
>>>> I will look at this this week.  If you happen to have a chance to debug
>>>> it any further by then, that would rock.  FWIW, I do not think it is in any
>>>> way related to the duplicate secondary table warnings.  Those are
>>>> completely harmless I believe.  The FK naming logic has changed quite a bit
>>>> from pre-5.0 versions, my guess is that the issue lies there.  That or in
>>>> the logic to read existing FKs.
>>>>
>>>> On Tue, May 5, 2015 at 3:19 AM, Petar Tahchiev <paranoiabla at gmail.com>
>>>> wrote:
>>>>
>>>>> Any of you have seen this issue? Shall I open a ticket?
>>>>>
>>>>> 2015-05-04 0:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>
>>>>> > Hi guys,
>>>>> >
>>>>> > I finally managed to reproduce it - here's a small application that
>>>>> will
>>>>> > generate the provided exception:
>>>>> >
>>>>> > https://github.com/paranoiabla/hibernate-hsql-issue
>>>>> >
>>>>> > Please notice that it works fine with Hibernate 4.3.x  I think it
>>>>> has to
>>>>> > do something with the CommerceCustomerModel - If I remove it or
>>>>> remove the
>>>>> > collection of payment infos that is inside of it, it all starts to
>>>>> work
>>>>> > fine.
>>>>> >
>>>>> > Please have a look and thanks a lot for your efforts :)
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > 2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>> >
>>>>> >> Hi guys,
>>>>> >>
>>>>> >> I just tried hibernate 5.0 beta2 and here's my observations. First
>>>>> of all
>>>>> >> the foreign key problems I had before seems to be resolved, however
>>>>> I see
>>>>> >> the following error when executing tests with HSQL:
>>>>> >>
>>>>> >>
>>>>> >> Caused by: org.springframework.beans.factory.BeanCreationException:
>>>>> Error
>>>>> >> creating bean with name 'defaultEntityManagerFactory' defined in
>>>>> class path
>>>>> >> resource
>>>>> [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
>>>>> >> Invocation of init method failed; nested exception is
>>>>> >> javax.persistence.PersistenceException: [PersistenceUnit: default]
>>>>> Unable
>>>>> >> to build Hibernate SessionFactory
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
>>>>> >>     ... 36 more
>>>>> >> Caused by: javax.persistence.PersistenceException: [PersistenceUnit:
>>>>> >> default] Unable to build Hibernate SessionFactory
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>>>>> >>     at
>>>>> >>
>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>>>>> >>     ... 50 more
>>>>> >> Caused by: org.hibernate.tool.schema.spi.SchemaManagementException:
>>>>> >> Unable to execute schema management to JDBC target [alter table
>>>>> >> payment_info add constraint FKs9wud9nve6s9cbot5p4548jyh foreign key
>>>>> >> (user_pk) references principal]
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
>>>>> >>     ... 55 more
>>>>> >> Caused by: java.sql.SQLSyntaxErrorException: object name already
>>>>> exists:
>>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table payment_info
>>>>> add
>>>>> >> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk)
>>>>> references
>>>>> >> principal]
>>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>>> >>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>>>>> >>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
>>>>> >>     at
>>>>> >>
>>>>> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
>>>>> >>     at
>>>>> >>
>>>>> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
>>>>> >>     at
>>>>> >>
>>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
>>>>> >>     ... 65 more
>>>>> >> Caused by: org.hsqldb.HsqlException: object name already exists:
>>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH
>>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>>> >>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
>>>>> >>     at org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown
>>>>> Source)
>>>>> >>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
>>>>> >>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
>>>>> >>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
>>>>> >>     at org.hsqldb.StatementSchema.execute(Unknown Source)
>>>>> >>     at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>>>> >>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>>>>> >>     at org.hsqldb.Session.execute(Unknown Source)
>>>>> >>     ... 70 more
>>>>> >>
>>>>> >>
>>>>> >> When running it with mysql it doesn't show this error (very
>>>>> strange) so I
>>>>> >> tried to export the schema to sql file and I can see only one
>>>>> foregin key
>>>>> >> declaration:
>>>>> >>
>>>>> >>     alter table payment_info
>>>>> >>         add constraint FKs9wud9nve6s9cbot5p4548jyh
>>>>> >>         foreign key (user_pk)
>>>>> >>         references principal (pk);
>>>>> >>
>>>>> >> Notice that this time it is lowercase. I'm trying to debug the hsql
>>>>> but
>>>>> >> it is very hard as it doesn't stop on any of the breakpoints I add.
>>>>> If any
>>>>> >> of you have an idea what might be causing it, please share your
>>>>> thoughts,
>>>>> >> if not I'll let you know how I progress.
>>>>> >>
>>>>> >> I wonder if it could be related to the duplicate joins warnings I
>>>>> see:
>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>> >> com.nemesis.platform.core.model.media.MediaModel
>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>> >>
>>>>> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>> >> com.nemesis.platform.core.model.cms.AbstractPageModel
>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>> >> com.nemesis.platform.core.model.cms.EmailPageModel
>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>> >> com.nemesis.platform.core.model.cms.CategoryPageModel
>>>>> >> .....
>>>>> >>
>>>>> >> --
>>>>> >> Regards, Petar!
>>>>> >> Karlovo, Bulgaria.
>>>>> >> ---
>>>>> >> Public PGP Key at:
>>>>> >>
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Regards, Petar!
>>>>> > Karlovo, Bulgaria.
>>>>> > ---
>>>>> > Public PGP Key at:
>>>>> >
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards, Petar!
>>>>> Karlovo, Bulgaria.
>>>>> ---
>>>>> Public PGP Key at:
>>>>>
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>
>>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From sanne at hibernate.org  Thu May 14 17:05:20 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 14 May 2015 22:05:20 +0100
Subject: [hibernate-dev] Search - Plain text and SimpleQueryParser
In-Reply-To: <CALt0+o8Q7JVAzXa65qz=fVRv6mPhPjZEcEv5XVxcZ2CBipq5uw@mail.gmail.com>
References: <CALt0+o8Q7JVAzXa65qz=fVRv6mPhPjZEcEv5XVxcZ2CBipq5uw@mail.gmail.com>
Message-ID: <CAFm4XO2MRYzaQL2pcvbkU6VPOfJKYBg1awef45oJh+zf-RWkmw@mail.gmail.com>

Hi Guillaume, welcome back!

I love the usability of this, I agree we should expose this
functionality. The "text()" method seems a good choice too.

On some other details:

 - ignoreAnalyzer() I agree with your comment, it doesn't seem to make
much sense. But what about not having the method rather than making it
throw an exception?
I'm assuming that should be possible by making some changes in the
interfaces, but I didn't try so I might be missing some complexity.

 - ignoreFieldBridge() This one is more controversial. I think
generally we should accept the types in their original form, so for
example accept a parameter which is not a String but a custom user
type, for which a field bridge or some two-way StringBridge could be
registered, and we apply the conversion automatically.
We do this on other APIs and we should be consistent across methods,
although there are some obscure ambiguities with that choice, for
example we do apply the FieldBridge from the field *name* and not from
the runtime type of the parameter, which introduces some complexities
when the query is targeting multiple fields with different indexing
options, especially if the input is expected to be in different types.

I don't think these implications were too clear when we first created
the DSL, so not ruling out a change of direction to be considered for
the next major version; you feedback as power user would be essential.
I still think that it's convenient for example to automatically encode
a Date type, but the type should then be matched differently to each
field.. how could we do that using this Lucene parser?

Another pain point which your tests are highlighting, is the lack of
an easy to use, short hand for the sorting API. Created HSEARCH-1872
as a discussion point.

Thanks,
Sanne



On 13 May 2015 at 12:56, Guillaume Smet <guillaume.smet at gmail.com> wrote:
> Hi,
>
> Having some spare time, I revisited my patch that used the Lucene
> SimpleQueryParser to provide more advanced search features to the end user.
>
> At my company, our search requirements are usually the following:
> - a full text search on the name and description;
> - a set of dropdown choices.
>
> Our full text search uses the AND operator as our customers usually
> requires this. It's not something we can do with the current keyword()
> search (I described the issue at length in
> https://hibernate.atlassian.net/browse/HSEARCH-917).
>
> We often give the ability to use boolean operators and phrase queries to
> the end user.
>
> How did we expose this feature? We build a Lucene query using the
> MultiFieldsQueryParser and we set the default operator to AND. We can't use
> the DSL.
>
> Starting with Lucene 4, we have a nice parser which is called
> SimpleQueryParser and which is... simple and resilient. And I think it
> would be a good idea to expose it via the DSL.
>
> It currently looks like this:
> https://github.com/openwide-java/hibernate-search/commit/ee776744760d8115965a05c939227d24133b58ec
> (there's not much code, Lucene is doing the magic).
>
> There are a couple of XXX I would like to discuss and I'm not that thrilled
> with the names I gave to the options.
>
> I have some spare time this week and next week so I'll be able to polish
> the patch based on your feedback!
>
> Have a nice day.
>
> --
> Guillaume
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Thu May 14 17:24:14 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 14 May 2015 17:24:14 -0400 (EDT)
Subject: [hibernate-dev] Preparing to release 4.3.10.Final
Message-ID: <1549800064.17692792.1431638654887.JavaMail.zimbra@redhat.com>

Please do not push any commits until after 4.3.10.Final is released.
Thanks,
Gail

From steve at hibernate.org  Thu May 14 17:27:26 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 May 2015 16:27:26 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAKnbemUC2cHYvyBQpxxeNNovJn+gS+7XAJg00S=UQbzuYaDvVQ@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
	<CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
	<CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>
	<CAFdSV9twBZPcnrJZM9cP29fe039Xapj00W4c-RnugRo+-sDcTw@mail.gmail.com>
	<CAKnbemW4=M-fPspoYERbeZBq6tXc6+JJ8sLrcmLvG7HxJwom+g@mail.gmail.com>
	<CAFdSV9viw_bsC_bMst87N9gZbMSyUjgmDrKCvoqpH4tjPueRgA@mail.gmail.com>
	<CAFdSV9uLCBSjf+GRtzbsOK5YjbTWL07dRA7ADRB15taGafXpSA@mail.gmail.com>
	<CAKnbemUC2cHYvyBQpxxeNNovJn+gS+7XAJg00S=UQbzuYaDvVQ@mail.gmail.com>
Message-ID: <CAFdSV9soz-x1Ym+HqM-JdR27_74xUnt6M-=3FokJ1HmXpqOyZg@mail.gmail.com>

So you're original test was using JPA?  See this illustrates why it's best
to isolate tests down to SSCCE.

I will try again with JPA specifically.
On May 14, 2015 11:30 AM, "Petar Tahchiev" <paranoiabla at gmail.com> wrote:

> Hi Steve,
>
> your test indeed works fine - I logged here
> https://jira.spring.io/browse/SPR-11694 so that the spring guys will have
> a look, but I don't think spring is doing any magic on the foreign keys.
> Juergen Hoeller from spring proposed it might be a bug in Hibernate's
> EntityManager implementation.
>
> I wish we could find out where the problem, but I'm not really that good
> to investigate further.
>
> 2015-05-14 19:27 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>
>> No word on the new test case I take it?
>>
>> WRT the HHH000072 logged warnings, like i said the warning is inocuous.
>> But I did correct it: https://hibernate.atlassian.net/browse/HHH-9797
>>
>> On Wed, May 13, 2015 at 3:52 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>
>>> Nope.  Well, specifically yes your test fails as is.  But since you did
>>> not simplify your environment, I took that opportunity and simplified it.
>>> So I sent you a PR that adds a new test using your model and successfully
>>> running an schema update.  The only difference is that my test does not
>>> have all this unnecessary Spring BS in the mix.
>>>
>>> So no, I do not thinking this warrants a Hibernate Jira.  Until you can
>>> simplify this to happen with just Hibernate in the picture.
>>>
>>> On Wed, May 13, 2015 at 12:59 PM, Petar Tahchiev <paranoiabla at gmail.com>
>>> wrote:
>>>
>>>> Any luck on reproducing this?
>>>>
>>>> 2015-05-05 16:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>
>>>>> Petar, I have just been focusing on other things the past 3 days or
>>>>> so.  Chill :)
>>>>>
>>>>> I will look at this this week.  If you happen to have a chance to
>>>>> debug it any further by then, that would rock.  FWIW, I do not think it is
>>>>> in any way related to the duplicate secondary table warnings.  Those are
>>>>> completely harmless I believe.  The FK naming logic has changed quite a bit
>>>>> from pre-5.0 versions, my guess is that the issue lies there.  That or in
>>>>> the logic to read existing FKs.
>>>>>
>>>>> On Tue, May 5, 2015 at 3:19 AM, Petar Tahchiev <paranoiabla at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Any of you have seen this issue? Shall I open a ticket?
>>>>>>
>>>>>> 2015-05-04 0:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>>
>>>>>> > Hi guys,
>>>>>> >
>>>>>> > I finally managed to reproduce it - here's a small application that
>>>>>> will
>>>>>> > generate the provided exception:
>>>>>> >
>>>>>> > https://github.com/paranoiabla/hibernate-hsql-issue
>>>>>> >
>>>>>> > Please notice that it works fine with Hibernate 4.3.x  I think it
>>>>>> has to
>>>>>> > do something with the CommerceCustomerModel - If I remove it or
>>>>>> remove the
>>>>>> > collection of payment infos that is inside of it, it all starts to
>>>>>> work
>>>>>> > fine.
>>>>>> >
>>>>>> > Please have a look and thanks a lot for your efforts :)
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > 2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>> >
>>>>>> >> Hi guys,
>>>>>> >>
>>>>>> >> I just tried hibernate 5.0 beta2 and here's my observations. First
>>>>>> of all
>>>>>> >> the foreign key problems I had before seems to be resolved,
>>>>>> however I see
>>>>>> >> the following error when executing tests with HSQL:
>>>>>> >>
>>>>>> >>
>>>>>> >> Caused by:
>>>>>> org.springframework.beans.factory.BeanCreationException: Error
>>>>>> >> creating bean with name 'defaultEntityManagerFactory' defined in
>>>>>> class path
>>>>>> >> resource
>>>>>> [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
>>>>>> >> Invocation of init method failed; nested exception is
>>>>>> >> javax.persistence.PersistenceException: [PersistenceUnit: default]
>>>>>> Unable
>>>>>> >> to build Hibernate SessionFactory
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
>>>>>> >>     ... 36 more
>>>>>> >> Caused by: javax.persistence.PersistenceException:
>>>>>> [PersistenceUnit:
>>>>>> >> default] Unable to build Hibernate SessionFactory
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>>>>>> >>     ... 50 more
>>>>>> >> Caused by: org.hibernate.tool.schema.spi.SchemaManagementException:
>>>>>> >> Unable to execute schema management to JDBC target [alter table
>>>>>> >> payment_info add constraint FKs9wud9nve6s9cbot5p4548jyh foreign key
>>>>>> >> (user_pk) references principal]
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
>>>>>> >>     ... 55 more
>>>>>> >> Caused by: java.sql.SQLSyntaxErrorException: object name already
>>>>>> exists:
>>>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table payment_info
>>>>>> add
>>>>>> >> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk)
>>>>>> references
>>>>>> >> principal]
>>>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>>>> >>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>>>>>> >>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
>>>>>> >>     at
>>>>>> >>
>>>>>> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
>>>>>> >>     at
>>>>>> >>
>>>>>> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
>>>>>> >>     at
>>>>>> >>
>>>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
>>>>>> >>     ... 65 more
>>>>>> >> Caused by: org.hsqldb.HsqlException: object name already exists:
>>>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH
>>>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>>>> >>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
>>>>>> >>     at org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown
>>>>>> Source)
>>>>>> >>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
>>>>>> >>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
>>>>>> >>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
>>>>>> >>     at org.hsqldb.StatementSchema.execute(Unknown Source)
>>>>>> >>     at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>>>>> >>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>>>>>> >>     at org.hsqldb.Session.execute(Unknown Source)
>>>>>> >>     ... 70 more
>>>>>> >>
>>>>>> >>
>>>>>> >> When running it with mysql it doesn't show this error (very
>>>>>> strange) so I
>>>>>> >> tried to export the schema to sql file and I can see only one
>>>>>> foregin key
>>>>>> >> declaration:
>>>>>> >>
>>>>>> >>     alter table payment_info
>>>>>> >>         add constraint FKs9wud9nve6s9cbot5p4548jyh
>>>>>> >>         foreign key (user_pk)
>>>>>> >>         references principal (pk);
>>>>>> >>
>>>>>> >> Notice that this time it is lowercase. I'm trying to debug the
>>>>>> hsql but
>>>>>> >> it is very hard as it doesn't stop on any of the breakpoints I
>>>>>> add. If any
>>>>>> >> of you have an idea what might be causing it, please share your
>>>>>> thoughts,
>>>>>> >> if not I'll let you know how I progress.
>>>>>> >>
>>>>>> >> I wonder if it could be related to the duplicate joins warnings I
>>>>>> see:
>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>> >> com.nemesis.platform.core.model.media.MediaModel
>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>> >>
>>>>>> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>> >> com.nemesis.platform.core.model.cms.AbstractPageModel
>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>> >> com.nemesis.platform.core.model.cms.EmailPageModel
>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>> >> com.nemesis.platform.core.model.cms.CategoryPageModel
>>>>>> >> .....
>>>>>> >>
>>>>>> >> --
>>>>>> >> Regards, Petar!
>>>>>> >> Karlovo, Bulgaria.
>>>>>> >> ---
>>>>>> >> Public PGP Key at:
>>>>>> >>
>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Regards, Petar!
>>>>>> > Karlovo, Bulgaria.
>>>>>> > ---
>>>>>> > Public PGP Key at:
>>>>>> >
>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards, Petar!
>>>>>> Karlovo, Bulgaria.
>>>>>> ---
>>>>>> Public PGP Key at:
>>>>>>
>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>> _______________________________________________
>>>>>> hibernate-dev mailing list
>>>>>> hibernate-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards, Petar!
>>>> Karlovo, Bulgaria.
>>>> ---
>>>> Public PGP Key at:
>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>
>>>
>>>
>>
>
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>

From sanne at hibernate.org  Thu May 14 19:54:01 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 15 May 2015 00:54:01 +0100
Subject: [hibernate-dev] SchemaExport usage ?
In-Reply-To: <CAFm4XO0shyKk_RE1yDkYQh8uwPhLKrYb3Ai-0mUMF-gBvPRACw@mail.gmail.com>
References: <CAFm4XO0T6qyaw6WGgoNjA+r-FqzyaAyc27h-2ro+SqFEu=u5og@mail.gmail.com>
	<CAFdSV9sHAQ1t=gt3G9O1ONwGeQHxSXk_J3+0oyoYs0cB8qpHAQ@mail.gmail.com>
	<CAFdSV9t_BycD+XnkQdw=fHO6=B=GA9MEqTnS37phbk-5W=QvbA@mail.gmail.com>
	<CAFm4XO0shyKk_RE1yDkYQh8uwPhLKrYb3Ai-0mUMF-gBvPRACw@mail.gmail.com>
Message-ID: <CAFm4XO2N2JAWg8m1jafKsr5c0U_n3srBnqH+KcS3BBuHhPsvVw@mail.gmail.com>

It's all working now but I copied a couple of utility classes from
ORM, as they were part of the tests.
essentially I needed JdbcConnectionAccessImpl :
 - https://github.com/hibernate/hibernate-search/commit/12df1b654cefad17b5186e3d3f4c5419d41295d1#diff-f3753a568f2086a66b118016751498edR21

Filed HHH-9801, very low priority though.

On 13 May 2015 at 17:48, Sanne Grinovero <sanne at hibernate.org> wrote:
> Thanks Steve, that was very helpful.
>
> On 13 May 2015 at 05:09, Steve Ebersole <steve at hibernate.org> wrote:
>> HHH-9792 - Clean up missed Configuration methods
>>
>> On Tue, May 12, 2015 at 11:05 PM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>>
>>> None of the bootstrapping contracts are kept around after the SF is
>>> bootstrapped.  Nothing different there from Configuration.  There is nothing
>>> meaningful on SessionFactory for performing any schema tools.  For what its
>>> worth I hope to change that with the metamodel work (6.0), but for now this
>>> is the case.
>>>
>>> The Configuration methods should be removed.  I just missed them.
>>>
>>> Take a look at
>>> org.hibernate.test.multitenancy.schema.SchemaBasedMultiTenancyTest in
>>> regards to how I do this for my tests
>>>
>>> On Tue, May 12, 2015 at 5:55 PM, Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>>
>>>> We have some Hibernate Search tests which use multi-tenancy, and
>>>> require the schema to be exported explicitly. I'm trying to get these
>>>> to run now with Hibernate ORM 5.
>>>>
>>>> I can't use the command line tool, as the test configuration options
>>>> should be passed by instance (there are several unit tests to be run,
>>>> each with its own configuration).
>>>>
>>>> I already have a SessionFactory started, so I'd prefer to use its
>>>> metadata if possible, but while SchemaExport has plenty of
>>>> constructors, it doesn't seem to have one I could use.
>>>>
>>>> This one looks like a good candidate:
>>>>
>>>>  SchemaExport(ConnectionHelper connectionHelper, MetadataImplementor
>>>> metadata)
>>>>
>>>> as I do have a ConnectionHelper instance. But while I have a reference
>>>> to my SessionFactory, and a reference to the Configuration which
>>>> started it, I couldn't find a way to get a MetadataImplementor from
>>>> these?
>>>>
>>>> Wouldn't it be very useful to have something like
>>>>
>>>> SchemaExport(ConnectionHelper connectionHelper, SessionFactorty sf) ?
>>>>
>>>> I think all multi-tenancy users would need something similar.
>>>>
>>>>
>>>> Partially unrelated, the methods:
>>>>  - org.hibernate.cfg.Configuration.generateDropSchemaScript(Dialect)
>>>>  - org.hibernate.cfg.Configuration.generateSchemaCreationScript(Dialect)
>>>>
>>>> are returning an hard coded String[0]. Should these be implemented
>>>> before 5.0.0.Final, or are these meant to be deprecated?
>>>>
>>>> Thanks,
>>>> Sanne
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>

From steve at hibernate.org  Thu May 14 21:03:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 May 2015 20:03:11 -0500
Subject: [hibernate-dev] SchemaExport usage ?
In-Reply-To: <CAFm4XO2N2JAWg8m1jafKsr5c0U_n3srBnqH+KcS3BBuHhPsvVw@mail.gmail.com>
References: <CAFm4XO0T6qyaw6WGgoNjA+r-FqzyaAyc27h-2ro+SqFEu=u5og@mail.gmail.com>
	<CAFdSV9sHAQ1t=gt3G9O1ONwGeQHxSXk_J3+0oyoYs0cB8qpHAQ@mail.gmail.com>
	<CAFdSV9t_BycD+XnkQdw=fHO6=B=GA9MEqTnS37phbk-5W=QvbA@mail.gmail.com>
	<CAFm4XO0shyKk_RE1yDkYQh8uwPhLKrYb3Ai-0mUMF-gBvPRACw@mail.gmail.com>
	<CAFm4XO2N2JAWg8m1jafKsr5c0U_n3srBnqH+KcS3BBuHhPsvVw@mail.gmail.com>
Message-ID: <CAFdSV9ug5Wy=kDKwgw_eJNmmGba45NtyTzmuuZBn7aAVE6pOZg@mail.gmail.com>

You mean the testing impl/variants of these?
On May 14, 2015 6:55 PM, "Sanne Grinovero" <sanne at hibernate.org> wrote:

> It's all working now but I copied a couple of utility classes from
> ORM, as they were part of the tests.
> essentially I needed JdbcConnectionAccessImpl :
>  -
> https://github.com/hibernate/hibernate-search/commit/12df1b654cefad17b5186e3d3f4c5419d41295d1#diff-f3753a568f2086a66b118016751498edR21
>
> Filed HHH-9801, very low priority though.
>
> On 13 May 2015 at 17:48, Sanne Grinovero <sanne at hibernate.org> wrote:
> > Thanks Steve, that was very helpful.
> >
> > On 13 May 2015 at 05:09, Steve Ebersole <steve at hibernate.org> wrote:
> >> HHH-9792 - Clean up missed Configuration methods
> >>
> >> On Tue, May 12, 2015 at 11:05 PM, Steve Ebersole <steve at hibernate.org>
> >> wrote:
> >>>
> >>> None of the bootstrapping contracts are kept around after the SF is
> >>> bootstrapped.  Nothing different there from Configuration.  There is
> nothing
> >>> meaningful on SessionFactory for performing any schema tools.  For
> what its
> >>> worth I hope to change that with the metamodel work (6.0), but for now
> this
> >>> is the case.
> >>>
> >>> The Configuration methods should be removed.  I just missed them.
> >>>
> >>> Take a look at
> >>> org.hibernate.test.multitenancy.schema.SchemaBasedMultiTenancyTest in
> >>> regards to how I do this for my tests
> >>>
> >>> On Tue, May 12, 2015 at 5:55 PM, Sanne Grinovero <sanne at hibernate.org>
> >>> wrote:
> >>>>
> >>>> We have some Hibernate Search tests which use multi-tenancy, and
> >>>> require the schema to be exported explicitly. I'm trying to get these
> >>>> to run now with Hibernate ORM 5.
> >>>>
> >>>> I can't use the command line tool, as the test configuration options
> >>>> should be passed by instance (there are several unit tests to be run,
> >>>> each with its own configuration).
> >>>>
> >>>> I already have a SessionFactory started, so I'd prefer to use its
> >>>> metadata if possible, but while SchemaExport has plenty of
> >>>> constructors, it doesn't seem to have one I could use.
> >>>>
> >>>> This one looks like a good candidate:
> >>>>
> >>>>  SchemaExport(ConnectionHelper connectionHelper, MetadataImplementor
> >>>> metadata)
> >>>>
> >>>> as I do have a ConnectionHelper instance. But while I have a reference
> >>>> to my SessionFactory, and a reference to the Configuration which
> >>>> started it, I couldn't find a way to get a MetadataImplementor from
> >>>> these?
> >>>>
> >>>> Wouldn't it be very useful to have something like
> >>>>
> >>>> SchemaExport(ConnectionHelper connectionHelper, SessionFactorty sf) ?
> >>>>
> >>>> I think all multi-tenancy users would need something similar.
> >>>>
> >>>>
> >>>> Partially unrelated, the methods:
> >>>>  - org.hibernate.cfg.Configuration.generateDropSchemaScript(Dialect)
> >>>>  -
> org.hibernate.cfg.Configuration.generateSchemaCreationScript(Dialect)
> >>>>
> >>>> are returning an hard coded String[0]. Should these be implemented
> >>>> before 5.0.0.Final, or are these meant to be deprecated?
> >>>>
> >>>> Thanks,
> >>>> Sanne
> >>>> _______________________________________________
> >>>> hibernate-dev mailing list
> >>>> hibernate-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>>
> >>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu May 14 22:20:49 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 14 May 2015 21:20:49 -0500
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAFdSV9soz-x1Ym+HqM-JdR27_74xUnt6M-=3FokJ1HmXpqOyZg@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
	<CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
	<CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>
	<CAFdSV9twBZPcnrJZM9cP29fe039Xapj00W4c-RnugRo+-sDcTw@mail.gmail.com>
	<CAKnbemW4=M-fPspoYERbeZBq6tXc6+JJ8sLrcmLvG7HxJwom+g@mail.gmail.com>
	<CAFdSV9viw_bsC_bMst87N9gZbMSyUjgmDrKCvoqpH4tjPueRgA@mail.gmail.com>
	<CAFdSV9uLCBSjf+GRtzbsOK5YjbTWL07dRA7ADRB15taGafXpSA@mail.gmail.com>
	<CAKnbemUC2cHYvyBQpxxeNNovJn+gS+7XAJg00S=UQbzuYaDvVQ@mail.gmail.com>
	<CAFdSV9soz-x1Ym+HqM-JdR27_74xUnt6M-=3FokJ1HmXpqOyZg@mail.gmail.com>
Message-ID: <CAFdSV9tBsbM76NZcD_kUx9stRFQQusH-rPTM4YQG3bKN66KYBw@mail.gmail.com>

Actually that cannot be it.  JPA does not define schema update capability.
On May 14, 2015 4:27 PM, "Steve Ebersole" <steve at hibernate.org> wrote:

> So you're original test was using JPA?  See this illustrates why it's best
> to isolate tests down to SSCCE.
>
> I will try again with JPA specifically.
> On May 14, 2015 11:30 AM, "Petar Tahchiev" <paranoiabla at gmail.com> wrote:
>
>> Hi Steve,
>>
>> your test indeed works fine - I logged here
>> https://jira.spring.io/browse/SPR-11694 so that the spring guys will
>> have a look, but I don't think spring is doing any magic on the foreign
>> keys. Juergen Hoeller from spring proposed it might be a bug in
>> Hibernate's EntityManager implementation.
>>
>> I wish we could find out where the problem, but I'm not really that good
>> to investigate further.
>>
>> 2015-05-14 19:27 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> No word on the new test case I take it?
>>>
>>> WRT the HHH000072 logged warnings, like i said the warning is
>>> inocuous.  But I did correct it:
>>> https://hibernate.atlassian.net/browse/HHH-9797
>>>
>>> On Wed, May 13, 2015 at 3:52 PM, Steve Ebersole <steve at hibernate.org>
>>> wrote:
>>>
>>>> Nope.  Well, specifically yes your test fails as is.  But since you did
>>>> not simplify your environment, I took that opportunity and simplified it.
>>>> So I sent you a PR that adds a new test using your model and successfully
>>>> running an schema update.  The only difference is that my test does not
>>>> have all this unnecessary Spring BS in the mix.
>>>>
>>>> So no, I do not thinking this warrants a Hibernate Jira.  Until you can
>>>> simplify this to happen with just Hibernate in the picture.
>>>>
>>>> On Wed, May 13, 2015 at 12:59 PM, Petar Tahchiev <paranoiabla at gmail.com
>>>> > wrote:
>>>>
>>>>> Any luck on reproducing this?
>>>>>
>>>>> 2015-05-05 16:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>
>>>>>> Petar, I have just been focusing on other things the past 3 days or
>>>>>> so.  Chill :)
>>>>>>
>>>>>> I will look at this this week.  If you happen to have a chance to
>>>>>> debug it any further by then, that would rock.  FWIW, I do not think it is
>>>>>> in any way related to the duplicate secondary table warnings.  Those are
>>>>>> completely harmless I believe.  The FK naming logic has changed quite a bit
>>>>>> from pre-5.0 versions, my guess is that the issue lies there.  That or in
>>>>>> the logic to read existing FKs.
>>>>>>
>>>>>> On Tue, May 5, 2015 at 3:19 AM, Petar Tahchiev <paranoiabla at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Any of you have seen this issue? Shall I open a ticket?
>>>>>>>
>>>>>>> 2015-05-04 0:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>>>
>>>>>>> > Hi guys,
>>>>>>> >
>>>>>>> > I finally managed to reproduce it - here's a small application
>>>>>>> that will
>>>>>>> > generate the provided exception:
>>>>>>> >
>>>>>>> > https://github.com/paranoiabla/hibernate-hsql-issue
>>>>>>> >
>>>>>>> > Please notice that it works fine with Hibernate 4.3.x  I think it
>>>>>>> has to
>>>>>>> > do something with the CommerceCustomerModel - If I remove it or
>>>>>>> remove the
>>>>>>> > collection of payment infos that is inside of it, it all starts to
>>>>>>> work
>>>>>>> > fine.
>>>>>>> >
>>>>>>> > Please have a look and thanks a lot for your efforts :)
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > 2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>>> >
>>>>>>> >> Hi guys,
>>>>>>> >>
>>>>>>> >> I just tried hibernate 5.0 beta2 and here's my observations.
>>>>>>> First of all
>>>>>>> >> the foreign key problems I had before seems to be resolved,
>>>>>>> however I see
>>>>>>> >> the following error when executing tests with HSQL:
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> Caused by:
>>>>>>> org.springframework.beans.factory.BeanCreationException: Error
>>>>>>> >> creating bean with name 'defaultEntityManagerFactory' defined in
>>>>>>> class path
>>>>>>> >> resource
>>>>>>> [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
>>>>>>> >> Invocation of init method failed; nested exception is
>>>>>>> >> javax.persistence.PersistenceException: [PersistenceUnit:
>>>>>>> default] Unable
>>>>>>> >> to build Hibernate SessionFactory
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
>>>>>>> >>     ... 36 more
>>>>>>> >> Caused by: javax.persistence.PersistenceException:
>>>>>>> [PersistenceUnit:
>>>>>>> >> default] Unable to build Hibernate SessionFactory
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>>>>>>> >>     ... 50 more
>>>>>>> >> Caused by:
>>>>>>> org.hibernate.tool.schema.spi.SchemaManagementException:
>>>>>>> >> Unable to execute schema management to JDBC target [alter table
>>>>>>> >> payment_info add constraint FKs9wud9nve6s9cbot5p4548jyh foreign
>>>>>>> key
>>>>>>> >> (user_pk) references principal]
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
>>>>>>> >>     ... 55 more
>>>>>>> >> Caused by: java.sql.SQLSyntaxErrorException: object name already
>>>>>>> exists:
>>>>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table
>>>>>>> payment_info add
>>>>>>> >> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk)
>>>>>>> references
>>>>>>> >> principal]
>>>>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>>>>> >>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>>>>>>> >>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown Source)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
>>>>>>> >>     at
>>>>>>> >>
>>>>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
>>>>>>> >>     ... 65 more
>>>>>>> >> Caused by: org.hsqldb.HsqlException: object name already exists:
>>>>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH
>>>>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>>>>> >>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
>>>>>>> >>     at
>>>>>>> org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown Source)
>>>>>>> >>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown Source)
>>>>>>> >>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
>>>>>>> >>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
>>>>>>> >>     at org.hsqldb.StatementSchema.execute(Unknown Source)
>>>>>>> >>     at org.hsqldb.Session.executeCompiledStatement(Unknown Source)
>>>>>>> >>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>>>>>>> >>     at org.hsqldb.Session.execute(Unknown Source)
>>>>>>> >>     ... 70 more
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> When running it with mysql it doesn't show this error (very
>>>>>>> strange) so I
>>>>>>> >> tried to export the schema to sql file and I can see only one
>>>>>>> foregin key
>>>>>>> >> declaration:
>>>>>>> >>
>>>>>>> >>     alter table payment_info
>>>>>>> >>         add constraint FKs9wud9nve6s9cbot5p4548jyh
>>>>>>> >>         foreign key (user_pk)
>>>>>>> >>         references principal (pk);
>>>>>>> >>
>>>>>>> >> Notice that this time it is lowercase. I'm trying to debug the
>>>>>>> hsql but
>>>>>>> >> it is very hard as it doesn't stop on any of the breakpoints I
>>>>>>> add. If any
>>>>>>> >> of you have an idea what might be causing it, please share your
>>>>>>> thoughts,
>>>>>>> >> if not I'll let you know how I progress.
>>>>>>> >>
>>>>>>> >> I wonder if it could be related to the duplicate joins warnings I
>>>>>>> see:
>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>> >> com.nemesis.platform.core.model.media.MediaModel
>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>> >>
>>>>>>> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>> >> com.nemesis.platform.core.model.cms.AbstractPageModel
>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>> >> com.nemesis.platform.core.model.cms.EmailPageModel
>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>> >> com.nemesis.platform.core.model.cms.CategoryPageModel
>>>>>>> >> .....
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> Regards, Petar!
>>>>>>> >> Karlovo, Bulgaria.
>>>>>>> >> ---
>>>>>>> >> Public PGP Key at:
>>>>>>> >>
>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>>>>>>> 0611
>>>>>>> >>
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > --
>>>>>>> > Regards, Petar!
>>>>>>> > Karlovo, Bulgaria.
>>>>>>> > ---
>>>>>>> > Public PGP Key at:
>>>>>>> >
>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards, Petar!
>>>>>>> Karlovo, Bulgaria.
>>>>>>> ---
>>>>>>> Public PGP Key at:
>>>>>>>
>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards, Petar!
>>>>> Karlovo, Bulgaria.
>>>>> ---
>>>>> Public PGP Key at:
>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>
>

From gbadner at redhat.com  Thu May 14 23:29:04 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 14 May 2015 23:29:04 -0400 (EDT)
Subject: [hibernate-dev] Hibernate ORM 4.3.10.Final Released
In-Reply-To: <784642919.17783351.1431660413659.JavaMail.zimbra@redhat.com>
Message-ID: <292228585.17783468.1431660544164.JavaMail.zimbra@redhat.com>

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

From gbadner at redhat.com  Fri May 15 01:41:45 2015
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 15 May 2015 01:41:45 -0400 (EDT)
Subject: [hibernate-dev] NoSuchMethodError running hibernate-infinispan
 tests with Infinispan 7.2.1
In-Reply-To: <113632043.17805907.1431667381034.JavaMail.zimbra@redhat.com>
Message-ID: <1046314230.17809186.1431668505635.JavaMail.zimbra@redhat.com>

Following Steve's suggestion using resolutionStrategy, I was able to build the hibernate-infinispan jar with Infinispan 6.0.0.Final and run the unit tests with 7.2.1.Final.

I'm sure there's a more elegant way to do this, so I've created a new jira (HHH-9802) and a pull request with the change I made: https://github.com/hibernate/hibernate-orm/pull/955 .

There were actually some unit test failures in InfinispanRegionFactoryTestCase using 7.2.1.Final due to java.lang.NoSuchMethodError. 

It happens in assertions like:

         assertEquals(5000, cacheCfg.eviction().maxEntries());

The problem is that org.infinispan.configuration.cache.EvictionConfiguration.maxEntries() returns int in 6.0.0.Final, but returns long in 7.2.1.Final. The only usage I see is in the unit tests. I can probably workaround this in the unit test, but I was wondering if this could cause a problem if an application used this method directly. 

Galder, do you know if this is a concern?

I have instructions in the pull request for reproducing these failures.

I commented out the failing assertions locally to verify that nothing else causes the test to fail.

I also see org.hibernate.cache.infinispan.TypeOverrides.evictionMaxEntries is defined as an int. That gets initialized based on a value set for on hibernate.cache.infinispan.<classnam>.eviction.max_entries. The only place I see TypeOverrides.getEvictionMaxEntries() used is in InfinispanRegionFactoryTestCase. Does this actually get used anywhere? Does the value find its way into a EvictionConfiguration.maxEntries field? If so, should be a long (instead of an int) in master?

I had a quick chat with Scott Marlow when I realized this was a potential problem and we agreed that it shouldn't block releasing Hibernate ORM 4.3.10.Final. I have gone ahead and released 4.3.10.Final. 

I will check in on things Friday morning, but I have to leave by 10:30am and will be off the rest of the day. I can pick this up on Monday if need be.

Regards,
Gail

From emmanuel at hibernate.org  Fri May 15 03:11:00 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 15 May 2015 09:11:00 +0200
Subject: [hibernate-dev] [OGM] Demarcating units of work
In-Reply-To: <CADGJaX-WubzvcbN0veYUF2ZCh9Aev8yPeFO9ZaasSjL2tBeY0g@mail.gmail.com>
References: <CADGJaX8D-bKUt+A9bCJkZXg1CD9DmOhtxe6-SM3d21e+3ZYarg@mail.gmail.com>
	<27D88AF6-1F91-4483-9FE1-9B58820DFDB2@hibernate.org>
	<CADGJaX--x3Mh4Lkntw=mu0=RV0kvxHzgJD+vF0efAe1TZF4=ug@mail.gmail.com>
	<CD63AAB6-2BF1-43D2-BB2C-209CC3197417@hibernate.org>
	<CADGJaX_nj=SfRg0OuMp1O3_7vPunevJj9M60byOfLP6KF7bSrQ@mail.gmail.com>
	<0718B486-85DB-4A65-B3AF-0B388945EB4C@hibernate.org>
	<CADGJaX-WubzvcbN0veYUF2ZCh9Aev8yPeFO9ZaasSjL2tBeY0g@mail.gmail.com>
Message-ID: <20150515071100.GA36999@hibernate.org>

On Thu 2015-05-07 17:51, Gunnar Morling wrote:
> > But I could still use session.getTransaction() and get the ?wrong?
> > behavior?
> >
> 
> I think it's the general question should we have an API which offers
> "everything", i.e. the sum of all functionality of all backends, meaning
> that some parts of the announced API functionality will fail at runtime
> (either silently or with an exception) on some backends. Or should we have
> a more limited API which is supported everywhere, and then allow to
> "unwrap" for certain backends (or families) and access advanced
> functionality just applying to those (as we e.g. do with the configuration
> API).
> 
> Currently OgmSession is the former, i.e. you could invoke getTransaction()
> and basically achieve the same as with the proposed alternative. But you
> could also try to rollback() and then it would fail, depending on the store.
> 
> I feel like the latter a bit better. For that we'd need a more limited
> OgmSession contract, not extending ORM's Session. This could e.g. host the
> runWorkUnit() functionality which is portable across backends.
> 
> Then there could be something like
> OgmSession.as(TransactionalSession.class).beginTransaction(). Here you
> would explicitly opt into transactional functionality. Of course you still
> could wrongly invoke this e.g. for MongoDB, but IMO it can be documented in
> a better way and help to manage people's expectations towards supported
> functionality. Or, e.g. with CDI it could even fail right at deploy of no
> TransactionalSession bean can be produced as per the current backend.

I am not sure how you reconcile that with the idea that OGM is a JPA
persistence provider implementation that integrates with things like app
servers and that these guys do use the `EntityManager` API. Will you forbid
app servers to expose rollback on the JTA APIs? And to inject a
`EntityManager` and force an `OgmEntityManager`?

From paranoiabla at gmail.com  Fri May 15 05:51:40 2015
From: paranoiabla at gmail.com (Petar Tahchiev)
Date: Fri, 15 May 2015 12:51:40 +0300
Subject: [hibernate-dev] Trying Hibernate 5.0.0.Beta2
In-Reply-To: <CAFdSV9tBsbM76NZcD_kUx9stRFQQusH-rPTM4YQG3bKN66KYBw@mail.gmail.com>
References: <CAKnbemXzV5d-eKuFGP1ucf4xKsSB1WBNUKyQo8G1NY7qwiYsSg@mail.gmail.com>
	<CAKnbemX-djbHVkyxu6eg4E+K_Y+=D+YN++UOm=tEMBqrPBDu2A@mail.gmail.com>
	<CAKnbemV46fQYPZwJv-hPpXvieDOFU+25oarH+4zYPG2ZSnT3xA@mail.gmail.com>
	<CAFdSV9twBZPcnrJZM9cP29fe039Xapj00W4c-RnugRo+-sDcTw@mail.gmail.com>
	<CAKnbemW4=M-fPspoYERbeZBq6tXc6+JJ8sLrcmLvG7HxJwom+g@mail.gmail.com>
	<CAFdSV9viw_bsC_bMst87N9gZbMSyUjgmDrKCvoqpH4tjPueRgA@mail.gmail.com>
	<CAFdSV9uLCBSjf+GRtzbsOK5YjbTWL07dRA7ADRB15taGafXpSA@mail.gmail.com>
	<CAKnbemUC2cHYvyBQpxxeNNovJn+gS+7XAJg00S=UQbzuYaDvVQ@mail.gmail.com>
	<CAFdSV9soz-x1Ym+HqM-JdR27_74xUnt6M-=3FokJ1HmXpqOyZg@mail.gmail.com>
	<CAFdSV9tBsbM76NZcD_kUx9stRFQQusH-rPTM4YQG3bKN66KYBw@mail.gmail.com>
Message-ID: <CAKnbemWWckcehvhknuvX9hJbJxCoWbf+xxf0yagYham9vHrCkA@mail.gmail.com>

I think it is closely related (if not the same) to this one:

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

2015-05-15 5:20 GMT+03:00 Steve Ebersole <steve at hibernate.org>:

> Actually that cannot be it.  JPA does not define schema update capability.
> On May 14, 2015 4:27 PM, "Steve Ebersole" <steve at hibernate.org> wrote:
>
>> So you're original test was using JPA?  See this illustrates why it's
>> best to isolate tests down to SSCCE.
>>
>> I will try again with JPA specifically.
>> On May 14, 2015 11:30 AM, "Petar Tahchiev" <paranoiabla at gmail.com> wrote:
>>
>>> Hi Steve,
>>>
>>> your test indeed works fine - I logged here
>>> https://jira.spring.io/browse/SPR-11694 so that the spring guys will
>>> have a look, but I don't think spring is doing any magic on the foreign
>>> keys. Juergen Hoeller from spring proposed it might be a bug in
>>> Hibernate's EntityManager implementation.
>>>
>>> I wish we could find out where the problem, but I'm not really that good
>>> to investigate further.
>>>
>>> 2015-05-14 19:27 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>
>>>> No word on the new test case I take it?
>>>>
>>>> WRT the HHH000072 logged warnings, like i said the warning is
>>>> inocuous.  But I did correct it:
>>>> https://hibernate.atlassian.net/browse/HHH-9797
>>>>
>>>> On Wed, May 13, 2015 at 3:52 PM, Steve Ebersole <steve at hibernate.org>
>>>> wrote:
>>>>
>>>>> Nope.  Well, specifically yes your test fails as is.  But since you
>>>>> did not simplify your environment, I took that opportunity and simplified
>>>>> it.  So I sent you a PR that adds a new test using your model and
>>>>> successfully running an schema update.  The only difference is that my test
>>>>> does not have all this unnecessary Spring BS in the mix.
>>>>>
>>>>> So no, I do not thinking this warrants a Hibernate Jira.  Until you
>>>>> can simplify this to happen with just Hibernate in the picture.
>>>>>
>>>>> On Wed, May 13, 2015 at 12:59 PM, Petar Tahchiev <
>>>>> paranoiabla at gmail.com> wrote:
>>>>>
>>>>>> Any luck on reproducing this?
>>>>>>
>>>>>> 2015-05-05 16:17 GMT+03:00 Steve Ebersole <steve at hibernate.org>:
>>>>>>
>>>>>>> Petar, I have just been focusing on other things the past 3 days or
>>>>>>> so.  Chill :)
>>>>>>>
>>>>>>> I will look at this this week.  If you happen to have a chance to
>>>>>>> debug it any further by then, that would rock.  FWIW, I do not think it is
>>>>>>> in any way related to the duplicate secondary table warnings.  Those are
>>>>>>> completely harmless I believe.  The FK naming logic has changed quite a bit
>>>>>>> from pre-5.0 versions, my guess is that the issue lies there.  That or in
>>>>>>> the logic to read existing FKs.
>>>>>>>
>>>>>>> On Tue, May 5, 2015 at 3:19 AM, Petar Tahchiev <
>>>>>>> paranoiabla at gmail.com> wrote:
>>>>>>>
>>>>>>>> Any of you have seen this issue? Shall I open a ticket?
>>>>>>>>
>>>>>>>> 2015-05-04 0:03 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>>>>
>>>>>>>> > Hi guys,
>>>>>>>> >
>>>>>>>> > I finally managed to reproduce it - here's a small application
>>>>>>>> that will
>>>>>>>> > generate the provided exception:
>>>>>>>> >
>>>>>>>> > https://github.com/paranoiabla/hibernate-hsql-issue
>>>>>>>> >
>>>>>>>> > Please notice that it works fine with Hibernate 4.3.x  I think it
>>>>>>>> has to
>>>>>>>> > do something with the CommerceCustomerModel - If I remove it or
>>>>>>>> remove the
>>>>>>>> > collection of payment infos that is inside of it, it all starts
>>>>>>>> to work
>>>>>>>> > fine.
>>>>>>>> >
>>>>>>>> > Please have a look and thanks a lot for your efforts :)
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > 2015-05-03 1:13 GMT+03:00 Petar Tahchiev <paranoiabla at gmail.com>:
>>>>>>>> >
>>>>>>>> >> Hi guys,
>>>>>>>> >>
>>>>>>>> >> I just tried hibernate 5.0 beta2 and here's my observations.
>>>>>>>> First of all
>>>>>>>> >> the foreign key problems I had before seems to be resolved,
>>>>>>>> however I see
>>>>>>>> >> the following error when executing tests with HSQL:
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> Caused by:
>>>>>>>> org.springframework.beans.factory.BeanCreationException: Error
>>>>>>>> >> creating bean with name 'defaultEntityManagerFactory' defined in
>>>>>>>> class path
>>>>>>>> >> resource
>>>>>>>> [com/nemesis/platform/core/config/PlatformCoreTestConfig.class]:
>>>>>>>> >> Invocation of init method failed; nested exception is
>>>>>>>> >> javax.persistence.PersistenceException: [PersistenceUnit:
>>>>>>>> default] Unable
>>>>>>>> >> to build Hibernate SessionFactory
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1578)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:545)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:482)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:304)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:300)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:195)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1011)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:802)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:521)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.boot.SpringApplication.refresh(SpringApplication.java:687)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.boot.test.SpringApplicationContextLoader.loadContext(SpringApplicationContextLoader.java:100)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContextInternal(DefaultCacheAwareContextLoaderDelegate.java:98)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:116)
>>>>>>>> >>     ... 36 more
>>>>>>>> >> Caused by: javax.persistence.PersistenceException:
>>>>>>>> [PersistenceUnit:
>>>>>>>> >> default] Unable to build Hibernate SessionFactory
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.persistenceException(EntityManagerFactoryBuilderImpl.java:874)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:802)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.orm.jpa.vendor.SpringHibernateJpaPersistenceProvider.createContainerEntityManagerFactory(SpringHibernateJpaPersistenceProvider.java:60)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean.createNativeEntityManagerFactory(LocalContainerEntityManagerFactoryBean.java:343)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.afterPropertiesSet(AbstractEntityManagerFactoryBean.java:318)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
>>>>>>>> >>     ... 50 more
>>>>>>>> >> Caused by:
>>>>>>>> org.hibernate.tool.schema.spi.SchemaManagementException:
>>>>>>>> >> Unable to execute schema management to JDBC target [alter table
>>>>>>>> >> payment_info add constraint FKs9wud9nve6s9cbot5p4548jyh foreign
>>>>>>>> key
>>>>>>>> >> (user_pk) references principal]
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:75)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlString(SchemaMigratorImpl.java:349)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applySqlStrings(SchemaMigratorImpl.java:338)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.applyForeignKeys(SchemaMigratorImpl.java:303)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigrationToTargets(SchemaMigratorImpl.java:135)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.tool.schema.internal.SchemaMigratorImpl.doMigration(SchemaMigratorImpl.java:76)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:146)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.tool.hbm2ddl.SchemaUpdate.execute(SchemaUpdate.java:114)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:461)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:799)
>>>>>>>> >>     ... 55 more
>>>>>>>> >> Caused by: java.sql.SQLSyntaxErrorException: object name already
>>>>>>>> exists:
>>>>>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH in statement [alter table
>>>>>>>> payment_info add
>>>>>>>> >> constraint FKs9wud9nve6s9cbot5p4548jyh foreign key (user_pk)
>>>>>>>> references
>>>>>>>> >> principal]
>>>>>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>>>>>> >>     at org.hsqldb.jdbc.JDBCUtil.sqlException(Unknown Source)
>>>>>>>> >>     at org.hsqldb.jdbc.JDBCStatement.fetchResult(Unknown Source)
>>>>>>>> >>     at org.hsqldb.jdbc.JDBCStatement.executeUpdate(Unknown
>>>>>>>> Source)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> com.zaxxer.hikari.proxy.StatementProxy.executeUpdate(StatementProxy.java:108)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> com.zaxxer.hikari.proxy.StatementJavassistProxy.executeUpdate(StatementJavassistProxy.java)
>>>>>>>> >>     at
>>>>>>>> >>
>>>>>>>> org.hibernate.tool.schema.internal.TargetDatabaseImpl.accept(TargetDatabaseImpl.java:72)
>>>>>>>> >>     ... 65 more
>>>>>>>> >> Caused by: org.hsqldb.HsqlException: object name already exists:
>>>>>>>> >> FKS9WUD9NVE6S9CBOT5P4548JYH
>>>>>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>>>>>> >>     at org.hsqldb.error.Error.error(Unknown Source)
>>>>>>>> >>     at org.hsqldb.SchemaObjectSet.checkAdd(Unknown Source)
>>>>>>>> >>     at
>>>>>>>> org.hsqldb.SchemaManager.checkSchemaObjectNotExists(Unknown Source)
>>>>>>>> >>     at org.hsqldb.TableWorks.checkCreateForeignKey(Unknown
>>>>>>>> Source)
>>>>>>>> >>     at org.hsqldb.TableWorks.addForeignKey(Unknown Source)
>>>>>>>> >>     at org.hsqldb.StatementSchema.getResult(Unknown Source)
>>>>>>>> >>     at org.hsqldb.StatementSchema.execute(Unknown Source)
>>>>>>>> >>     at org.hsqldb.Session.executeCompiledStatement(Unknown
>>>>>>>> Source)
>>>>>>>> >>     at org.hsqldb.Session.executeDirectStatement(Unknown Source)
>>>>>>>> >>     at org.hsqldb.Session.execute(Unknown Source)
>>>>>>>> >>     ... 70 more
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> When running it with mysql it doesn't show this error (very
>>>>>>>> strange) so I
>>>>>>>> >> tried to export the schema to sql file and I can see only one
>>>>>>>> foregin key
>>>>>>>> >> declaration:
>>>>>>>> >>
>>>>>>>> >>     alter table payment_info
>>>>>>>> >>         add constraint FKs9wud9nve6s9cbot5p4548jyh
>>>>>>>> >>         foreign key (user_pk)
>>>>>>>> >>         references principal (pk);
>>>>>>>> >>
>>>>>>>> >> Notice that this time it is lowercase. I'm trying to debug the
>>>>>>>> hsql but
>>>>>>>> >> it is very hard as it doesn't stop on any of the breakpoints I
>>>>>>>> add. If any
>>>>>>>> >> of you have an idea what might be causing it, please share your
>>>>>>>> thoughts,
>>>>>>>> >> if not I'll let you know how I progress.
>>>>>>>> >>
>>>>>>>> >> I wonder if it could be related to the duplicate joins warnings
>>>>>>>> I see:
>>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> >> com.nemesis.platform.core.model.media.MediaModel
>>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> >>
>>>>>>>> com.nemesis.platform.module.commerce.core.model.order.TerritoryDeliveryModeValueModel
>>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> >> com.nemesis.platform.core.model.cms.AbstractPageModel
>>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> >> com.nemesis.platform.core.model.cms.EmailPageModel
>>>>>>>> >> WARN : HHH000072: Duplicate joins for class:
>>>>>>>> >> com.nemesis.platform.core.model.cms.CategoryPageModel
>>>>>>>> >> .....
>>>>>>>> >>
>>>>>>>> >> --
>>>>>>>> >> Regards, Petar!
>>>>>>>> >> Karlovo, Bulgaria.
>>>>>>>> >> ---
>>>>>>>> >> Public PGP Key at:
>>>>>>>> >>
>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>> >> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>>>>>>>> 0611
>>>>>>>> >>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > --
>>>>>>>> > Regards, Petar!
>>>>>>>> > Karlovo, Bulgaria.
>>>>>>>> > ---
>>>>>>>> > Public PGP Key at:
>>>>>>>> >
>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>> > Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311
>>>>>>>> 0611
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Regards, Petar!
>>>>>>>> Karlovo, Bulgaria.
>>>>>>>> ---
>>>>>>>> Public PGP Key at:
>>>>>>>>
>>>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>>> _______________________________________________
>>>>>>>> hibernate-dev mailing list
>>>>>>>> hibernate-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards, Petar!
>>>>>> Karlovo, Bulgaria.
>>>>>> ---
>>>>>> Public PGP Key at:
>>>>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Regards, Petar!
>>> Karlovo, Bulgaria.
>>> ---
>>> Public PGP Key at:
>>> https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>>>
>>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
https://keyserver1.pgp.com/vkd/DownloadKey.event?keyid=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611

From gunnar at hibernate.org  Fri May 15 07:14:20 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 15 May 2015 13:14:20 +0200
Subject: [hibernate-dev] [OGM] Need to list entities when using
 Hibernate OGM on WildFly
In-Reply-To: <55534CBD.8060404@redhat.com>
References: <CADGJaX94y0sKeQwKVXcTzFL69bEXb+efcYdA-NVBZpHbN6FYsA@mail.gmail.com>
	<55534CBD.8060404@redhat.com>
Message-ID: <CADGJaX__YPD7hGOcR4s2ZBDDUcCgtvAJNLZo4qTxc6rdrNx7EA@mail.gmail.com>

2015-05-13 15:08 GMT+02:00 Scott Marlow <smarlow at redhat.com>:

> I remember seeing this before but don't remember why.  Years ago, I
> blogged [1] about using OGM on JBoss AS (before the rename to WildFly).  I
> didn't name the entity classes in the blog (or git [2]), so not sure if
> that was because OGM worked better back then or I just got lucky with my
> simple test case.
>

Ok, I've filed https://hibernate.atlassian.net/browse/OGM-828 for this.

>
> By the way, we are talking about moving Jipijapa back into the WildFly
> code base, to get more eyeballs on it.  Currently its just me reviewing my
> own code changes, but on WildFly we usually get a peer code review as part
> of pull request processing.  I wanted to mention this, as we talked in the
> past about possibly adding JPA integration code for OGM (if there is ever a
> need).  Obviously, if the Jipijapa code is moving to WildFly, we would want
> to do any integration there.  This is still being discussed.
>

Interesting, thanks for the heads-up.

Wrt. to integration code, it'd be nice if the OGM module(s) could be added
automatically to applications using the OGM persistence provider and one
(or more) of the OGM backends. Currently it'd requires fiddling with
manifest headers and the like

Scott
>
> [1]
> http://in.relation.to/Bloggers/UsingADifferentPersistenceProviderWithAS701#H-ExperimentalUseOfOGMOnAS701
>
> [2]
> https://github.com/scottmarlow/wildfly/commit/9282f0f6bd20007b834f3390c08a0978bf578d2c
>
>
> On 05/13/2015 08:28 AM, Gunnar Morling wrote:
>
>> Hi,
>>
>> When using Hibernate OGM on WildFly, one needs to list the entity classes
>> in persistence.xml, otherwise and "Unknown entity" exception will be
>> raised.
>>
>> Does anyone have a rough idea what may be causing this or where to get
>> started to analyse this issue?
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>

From sanne at hibernate.org  Fri May 15 07:45:54 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 15 May 2015 12:45:54 +0100
Subject: [hibernate-dev] SchemaExport usage ?
In-Reply-To: <CAFdSV9ug5Wy=kDKwgw_eJNmmGba45NtyTzmuuZBn7aAVE6pOZg@mail.gmail.com>
References: <CAFm4XO0T6qyaw6WGgoNjA+r-FqzyaAyc27h-2ro+SqFEu=u5og@mail.gmail.com>
	<CAFdSV9sHAQ1t=gt3G9O1ONwGeQHxSXk_J3+0oyoYs0cB8qpHAQ@mail.gmail.com>
	<CAFdSV9t_BycD+XnkQdw=fHO6=B=GA9MEqTnS37phbk-5W=QvbA@mail.gmail.com>
	<CAFm4XO0shyKk_RE1yDkYQh8uwPhLKrYb3Ai-0mUMF-gBvPRACw@mail.gmail.com>
	<CAFm4XO2N2JAWg8m1jafKsr5c0U_n3srBnqH+KcS3BBuHhPsvVw@mail.gmail.com>
	<CAFdSV9ug5Wy=kDKwgw_eJNmmGba45NtyTzmuuZBn7aAVE6pOZg@mail.gmail.com>
Message-ID: <CAFm4XO1uYUUbk96=dETrP0NCNwhgK2B_2DE8TDdhRsU=xrP5Pg@mail.gmail.com>

I'm not sure how to call it, I'm referring to this source file:

hibernate-core/src/test/java/org/hibernate/test/common/JdbcConnectionAccessImpl.java

That, along with other files in the same package, seems useful to
create tests. I've temporarily copied into the Hibernate Search
sources.



On 15 May 2015 at 02:03, Steve Ebersole <steve at hibernate.org> wrote:
> You mean the testing impl/variants of these?
>
> On May 14, 2015 6:55 PM, "Sanne Grinovero" <sanne at hibernate.org> wrote:
>>
>> It's all working now but I copied a couple of utility classes from
>> ORM, as they were part of the tests.
>> essentially I needed JdbcConnectionAccessImpl :
>>  -
>> https://github.com/hibernate/hibernate-search/commit/12df1b654cefad17b5186e3d3f4c5419d41295d1#diff-f3753a568f2086a66b118016751498edR21
>>
>> Filed HHH-9801, very low priority though.
>>
>> On 13 May 2015 at 17:48, Sanne Grinovero <sanne at hibernate.org> wrote:
>> > Thanks Steve, that was very helpful.
>> >
>> > On 13 May 2015 at 05:09, Steve Ebersole <steve at hibernate.org> wrote:
>> >> HHH-9792 - Clean up missed Configuration methods
>> >>
>> >> On Tue, May 12, 2015 at 11:05 PM, Steve Ebersole <steve at hibernate.org>
>> >> wrote:
>> >>>
>> >>> None of the bootstrapping contracts are kept around after the SF is
>> >>> bootstrapped.  Nothing different there from Configuration.  There is
>> >>> nothing
>> >>> meaningful on SessionFactory for performing any schema tools.  For
>> >>> what its
>> >>> worth I hope to change that with the metamodel work (6.0), but for now
>> >>> this
>> >>> is the case.
>> >>>
>> >>> The Configuration methods should be removed.  I just missed them.
>> >>>
>> >>> Take a look at
>> >>> org.hibernate.test.multitenancy.schema.SchemaBasedMultiTenancyTest in
>> >>> regards to how I do this for my tests
>> >>>
>> >>> On Tue, May 12, 2015 at 5:55 PM, Sanne Grinovero <sanne at hibernate.org>
>> >>> wrote:
>> >>>>
>> >>>> We have some Hibernate Search tests which use multi-tenancy, and
>> >>>> require the schema to be exported explicitly. I'm trying to get these
>> >>>> to run now with Hibernate ORM 5.
>> >>>>
>> >>>> I can't use the command line tool, as the test configuration options
>> >>>> should be passed by instance (there are several unit tests to be run,
>> >>>> each with its own configuration).
>> >>>>
>> >>>> I already have a SessionFactory started, so I'd prefer to use its
>> >>>> metadata if possible, but while SchemaExport has plenty of
>> >>>> constructors, it doesn't seem to have one I could use.
>> >>>>
>> >>>> This one looks like a good candidate:
>> >>>>
>> >>>>  SchemaExport(ConnectionHelper connectionHelper, MetadataImplementor
>> >>>> metadata)
>> >>>>
>> >>>> as I do have a ConnectionHelper instance. But while I have a
>> >>>> reference
>> >>>> to my SessionFactory, and a reference to the Configuration which
>> >>>> started it, I couldn't find a way to get a MetadataImplementor from
>> >>>> these?
>> >>>>
>> >>>> Wouldn't it be very useful to have something like
>> >>>>
>> >>>> SchemaExport(ConnectionHelper connectionHelper, SessionFactorty sf) ?
>> >>>>
>> >>>> I think all multi-tenancy users would need something similar.
>> >>>>
>> >>>>
>> >>>> Partially unrelated, the methods:
>> >>>>  - org.hibernate.cfg.Configuration.generateDropSchemaScript(Dialect)
>> >>>>  -
>> >>>> org.hibernate.cfg.Configuration.generateSchemaCreationScript(Dialect)
>> >>>>
>> >>>> are returning an hard coded String[0]. Should these be implemented
>> >>>> before 5.0.0.Final, or are these meant to be deprecated?
>> >>>>
>> >>>> Thanks,
>> >>>> Sanne
>> >>>> _______________________________________________
>> >>>> hibernate-dev mailing list
>> >>>> hibernate-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>
>> >>>
>> >>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri May 15 07:51:51 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 15 May 2015 12:51:51 +0100
Subject: [hibernate-dev] Unable to build local snapshots of ORM 5
Message-ID: <CAFm4XO1DKiD7WfBjMBouk=oaU8Hmxfs6G2vM54BwTA1jWR87fg@mail.gmail.com>

I need to build local snapshots of ORM to test things with Hibernate
Search, but invoking "publishToMavenLocal" produces an error on the
OSGi module:

FAILURE: Build failed with an exception.
 * What went wrong:
Execution failed for task
':hibernate-osgi:publishMavenJavaPublicationToMavenLocal'.
Failed to publish publication 'mavenJava' to repository 'MavenLocal'
    > Invalid publication 'mavenJava': artifact file does not exist:
'/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.0-SNAPSHOT-karaf.xml'

All I know is that indeed that file isn't there.

I tried to workaround the problem by deploying a snapshot to Nexus,
but that failed with a similar error.

From steve at hibernate.org  Fri May 15 08:12:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 15 May 2015 07:12:31 -0500
Subject: [hibernate-dev] Unable to build local snapshots of ORM 5
In-Reply-To: <CAFm4XO1DKiD7WfBjMBouk=oaU8Hmxfs6G2vM54BwTA1jWR87fg@mail.gmail.com>
References: <CAFm4XO1DKiD7WfBjMBouk=oaU8Hmxfs6G2vM54BwTA1jWR87fg@mail.gmail.com>
Message-ID: <CAFdSV9uiTX4FESK8=5hwzMZjkgMShCV1VJeUeYAVpTON3GWjRg@mail.gmail.com>

Hmm I might not have set up the task deps properly for the task that
generates that file.  It should depend on the hibernate-osgi jar task.  You
can try setting the deps or you can try running the task directly.  It's
called something like generateKarafFeatures
On May 15, 2015 6:52 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:

> I need to build local snapshots of ORM to test things with Hibernate
> Search, but invoking "publishToMavenLocal" produces an error on the
> OSGi module:
>
> FAILURE: Build failed with an exception.
>  * What went wrong:
> Execution failed for task
> ':hibernate-osgi:publishMavenJavaPublicationToMavenLocal'.
> Failed to publish publication 'mavenJava' to repository 'MavenLocal'
>     > Invalid publication 'mavenJava': artifact file does not exist:
>
> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.0-SNAPSHOT-karaf.xml'
>
> All I know is that indeed that file isn't there.
>
> I tried to workaround the problem by deploying a snapshot to Nexus,
> but that failed with a similar error.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri May 15 08:18:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 15 May 2015 07:18:09 -0500
Subject: [hibernate-dev] Unable to build local snapshots of ORM 5
In-Reply-To: <CAFdSV9uiTX4FESK8=5hwzMZjkgMShCV1VJeUeYAVpTON3GWjRg@mail.gmail.com>
References: <CAFm4XO1DKiD7WfBjMBouk=oaU8Hmxfs6G2vM54BwTA1jWR87fg@mail.gmail.com>
	<CAFdSV9uiTX4FESK8=5hwzMZjkgMShCV1VJeUeYAVpTON3GWjRg@mail.gmail.com>
Message-ID: <CAFdSV9uL6tOvTPKFn6vQ8k3PRy+opg8eV8cb2Z1UxyWcy8C9cw@mail.gmail.com>

Oh that's right.  This is something I wanted to look at changing in that
karaf plugin I contribute to.  Normally you define artifacts for publishing
via the task that produces them; Gradle will then automatically add that
task as a dep to the publishing related tasks.  But Gradle expects the task
to implement certain extra interfaces.  So in the short term I just named
the file.  Anyway, for now setting up the task deps manually or running the
task directly as I mentioned before should work.

On Fri, May 15, 2015 at 7:12 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Hmm I might not have set up the task deps properly for the task that
> generates that file.  It should depend on the hibernate-osgi jar task.  You
> can try setting the deps or you can try running the task directly.  It's
> called something like generateKarafFeatures
> On May 15, 2015 6:52 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:
>
>> I need to build local snapshots of ORM to test things with Hibernate
>> Search, but invoking "publishToMavenLocal" produces an error on the
>> OSGi module:
>>
>> FAILURE: Build failed with an exception.
>>  * What went wrong:
>> Execution failed for task
>> ':hibernate-osgi:publishMavenJavaPublicationToMavenLocal'.
>> Failed to publish publication 'mavenJava' to repository 'MavenLocal'
>>     > Invalid publication 'mavenJava': artifact file does not exist:
>>
>> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.0-SNAPSHOT-karaf.xml'
>>
>> All I know is that indeed that file isn't there.
>>
>> I tried to workaround the problem by deploying a snapshot to Nexus,
>> but that failed with a similar error.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>

From sanne at hibernate.org  Fri May 15 08:19:38 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 15 May 2015 13:19:38 +0100
Subject: [hibernate-dev] Unable to build local snapshots of ORM 5
In-Reply-To: <CAFdSV9uL6tOvTPKFn6vQ8k3PRy+opg8eV8cb2Z1UxyWcy8C9cw@mail.gmail.com>
References: <CAFm4XO1DKiD7WfBjMBouk=oaU8Hmxfs6G2vM54BwTA1jWR87fg@mail.gmail.com>
	<CAFdSV9uiTX4FESK8=5hwzMZjkgMShCV1VJeUeYAVpTON3GWjRg@mail.gmail.com>
	<CAFdSV9uL6tOvTPKFn6vQ8k3PRy+opg8eV8cb2Z1UxyWcy8C9cw@mail.gmail.com>
Message-ID: <CAFm4XO1n-JbLWOGKxa+KRSagg0PehxR6+C-oaTqXV3_75cv2jA@mail.gmail.com>

thanks Steve,
this works fine, as you suggested:

./gradlew clean generateKarafFeatures publishToMavenLocal
-DJAVA6_HOME=/opt/jdk-6/

On 15 May 2015 at 13:18, Steve Ebersole <steve at hibernate.org> wrote:
> Oh that's right.  This is something I wanted to look at changing in that
> karaf plugin I contribute to.  Normally you define artifacts for publishing
> via the task that produces them; Gradle will then automatically add that
> task as a dep to the publishing related tasks.  But Gradle expects the task
> to implement certain extra interfaces.  So in the short term I just named
> the file.  Anyway, for now setting up the task deps manually or running the
> task directly as I mentioned before should work.
>
> On Fri, May 15, 2015 at 7:12 AM, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> Hmm I might not have set up the task deps properly for the task that
>> generates that file.  It should depend on the hibernate-osgi jar task.  You
>> can try setting the deps or you can try running the task directly.  It's
>> called something like generateKarafFeatures
>>
>> On May 15, 2015 6:52 AM, "Sanne Grinovero" <sanne at hibernate.org> wrote:
>>>
>>> I need to build local snapshots of ORM to test things with Hibernate
>>> Search, but invoking "publishToMavenLocal" produces an error on the
>>> OSGi module:
>>>
>>> FAILURE: Build failed with an exception.
>>>  * What went wrong:
>>> Execution failed for task
>>> ':hibernate-osgi:publishMavenJavaPublicationToMavenLocal'.
>>> Failed to publish publication 'mavenJava' to repository 'MavenLocal'
>>>     > Invalid publication 'mavenJava': artifact file does not exist:
>>>
>>> '/home/sanne/workspaces/hibernate/hibernate-core-parent/hibernate-osgi/target/karafFeatures/hibernate-osgi-5.0.0-SNAPSHOT-karaf.xml'
>>>
>>> All I know is that indeed that file isn't there.
>>>
>>> I tried to workaround the problem by deploying a snapshot to Nexus,
>>> but that failed with a similar error.
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From guillaume.smet at gmail.com  Fri May 15 08:58:05 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Fri, 15 May 2015 14:58:05 +0200
Subject: [hibernate-dev] Search - Plain text and SimpleQueryParser
In-Reply-To: <CAFm4XO2MRYzaQL2pcvbkU6VPOfJKYBg1awef45oJh+zf-RWkmw@mail.gmail.com>
References: <CALt0+o8Q7JVAzXa65qz=fVRv6mPhPjZEcEv5XVxcZ2CBipq5uw@mail.gmail.com>
	<CAFm4XO2MRYzaQL2pcvbkU6VPOfJKYBg1awef45oJh+zf-RWkmw@mail.gmail.com>
Message-ID: <CALt0+o84uPL8GjHLBB2Wu6spSXH-sCgABwAOe-cKcxwrq0czNw@mail.gmail.com>

Hi Sanne,

Thanks for your feedback. My answers below:

On Thu, May 14, 2015 at 11:05 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

>  - ignoreAnalyzer() I agree with your comment, it doesn't seem to make
> much sense. But what about not having the method rather than making it
> throw an exception?
> I'm assuming that should be possible by making some changes in the
> interfaces, but I didn't try so I might be missing some complexity.
>
>
Yes, it's not hard at all. I removed the FieldCustomization interface from
PlainTextMatchingContext.


>  - ignoreFieldBridge() This one is more controversial. I think
> generally we should accept the types in their original form, so for
> example accept a parameter which is not a String but a custom user
> type, for which a field bridge or some two-way StringBridge could be
> registered, and we apply the conversion automatically.
> We do this on other APIs and we should be consistent across methods,
> although there are some obscure ambiguities with that choice, for
> example we do apply the FieldBridge from the field *name* and not from
> the runtime type of the parameter, which introduces some complexities
> when the query is targeting multiple fields with different indexing
> options, especially if the input is expected to be in different types.
>

Plain text search only supports String search. It tokenizes and parses the
string to build the query term by term (and terms might be operators,
negative queries, fuzzy queries...). You cannot apply a StringBridge to the
whole string and you cannot apply a StringBridge to each term after the
tokenization.

That's why I'm thinking it's a limitation we should accept.


> I don't think these implications were too clear when we first created
> the DSL, so not ruling out a change of direction to be considered for
> the next major version; you feedback as power user would be essential.
> I still think that it's convenient for example to automatically encode
> a Date type, but the type should then be matched differently to each
> field.. how could we do that using this Lucene parser?
>

Well, it's not how this parser works, that's why I called it text search.

I tighten the DSL a bit in a further commit.

As for the current code, I don't really like the .defaultOperatorIsAnd()
method name. Any better ideas?

Another pain point which your tests are highlighting, is the lack of
> an easy to use, short hand for the sorting API. Created HSEARCH-1872
> as a discussion point.
>

If we're talking about the limitations of the DSL, let's tackle this
subject :).

Here are the main reasons why we are forced to not use the DSL (or at least
add a layer on top of it):
- ability to search on multiple fields with an AND operator: we used the
Lucene MultiFieldsQueryParser, we now have switched to the
SimpleQueryParser (what I propose here would solve this issue)
- ability to ignore a condition if the term (term in a general way) is
null: most of the time, users only define 1 or 2 fields of the search
engine and we want to ignore this part of the query if the term is null.
Currently, we end up with a lot of boilerplate code.
- ability to ignore a query if the query is null (typically a boolean
junction and a for loop with no items)

-- 
Guillaume

From smarlow at redhat.com  Fri May 15 10:32:33 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 15 May 2015 10:32:33 -0400
Subject: [hibernate-dev] NoSuchMethodError running hibernate-infinispan
 tests with Infinispan 7.2.1
In-Reply-To: <1046314230.17809186.1431668505635.JavaMail.zimbra@redhat.com>
References: <1046314230.17809186.1431668505635.JavaMail.zimbra@redhat.com>
Message-ID: <55560381.10607@redhat.com>

On 05/15/2015 01:41 AM, Gail Badner wrote:
> Following Steve's suggestion using resolutionStrategy, I was able to build the hibernate-infinispan jar with Infinispan 6.0.0.Final and run the unit tests with 7.2.1.Final.
>
> I'm sure there's a more elegant way to do this, so I've created a new jira (HHH-9802) and a pull request with the change I made: https://github.com/hibernate/hibernate-orm/pull/955 .
>
> There were actually some unit test failures in InfinispanRegionFactoryTestCase using 7.2.1.Final due to java.lang.NoSuchMethodError.
>
> It happens in assertions like:
>
>           assertEquals(5000, cacheCfg.eviction().maxEntries());
>
> The problem is that org.infinispan.configuration.cache.EvictionConfiguration.maxEntries() returns int in 6.0.0.Final, but returns long in 7.2.1.Final. The only usage I see is in the unit tests. I can probably workaround this in the unit test, but I was wondering if this could cause a problem if an application used this method directly.
>
> Galder, do you know if this is a concern?
>
> I have instructions in the pull request for reproducing these failures.
>
> I commented out the failing assertions locally to verify that nothing else causes the test to fail.
>
> I also see org.hibernate.cache.infinispan.TypeOverrides.evictionMaxEntries is defined as an int. That gets initialized based on a value set for on hibernate.cache.infinispan.<classnam>.eviction.max_entries. The only place I see TypeOverrides.getEvictionMaxEntries() used is in InfinispanRegionFactoryTestCase. Does this actually get used anywhere? Does the value find its way into a EvictionConfiguration.maxEntries field? If so, should be a long (instead of an int) in master?
>
> I had a quick chat with Scott Marlow when I realized this was a potential problem and we agreed that it shouldn't block releasing Hibernate ORM 4.3.10.Final. I have gone ahead and released 4.3.10.Final.

As far as I can tell, applications that compile against Infinispan 6.x, 
will be expecting cacheCfg.eviction().maxEntries() to always be an int 
(as Gail states).  Those applications will be broken when they try to 
drop in Infinispan 7.x.  I don't think this is a Hibernate bug but think 
we need input from infinispan-dev.  I'll try cross posting on that 
mailing list.

>
> I will check in on things Friday morning, but I have to leave by 10:30am and will be off the rest of the day. I can pick this up on Monday if need be.
>
> Regards,
> Gail
>

From emmanuel at hibernate.org  Fri May 15 11:32:25 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 15 May 2015 17:32:25 +0200
Subject: [hibernate-dev] [OGM] DocumentStoreConfiguration
Message-ID: <20150515153225.GB36999@hibernate.org>

So far DocumentStoreConfiguration is very generic and only deals with
remote datastore with reasonable expectations (hosts, ports, usernames.

Cassandra makes use of that class.
Should we rename it and create a subclass for document stores that would
be empty today?

Emmanuel

From emmanuel at hibernate.org  Fri May 15 11:58:23 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 15 May 2015 17:58:23 +0200
Subject: [hibernate-dev] [OGM] Cassandra failure
Message-ID: <20150515155823.GC36999@hibernate.org>

Hey Jonathan,

I investigated a bit the Cassandra failure I am seeing.

The logs based on a code change I did are here 
https://gist.github.com/emmanuelbernard/13d22d15dc983a83a7e2

My understanding is that the failing type is the TrueFalseType used on
Bookmark.isPrivate. This type returns a F char for false.

The commit is recent a2b310 (yesterday).

Emmanuel

From sanne at hibernate.org  Fri May 15 12:44:00 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 15 May 2015 17:44:00 +0100
Subject: [hibernate-dev] [OGM] DocumentStoreConfiguration
In-Reply-To: <20150515153225.GB36999@hibernate.org>
References: <20150515153225.GB36999@hibernate.org>
Message-ID: <CAFm4XO2XmbGRnJ1DwyXKmUpg6mNwyCw9cxm1ZYsDQdVa-Lk2Tg@mail.gmail.com>

+1

On 15 May 2015 at 16:32, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> So far DocumentStoreConfiguration is very generic and only deals with
> remote datastore with reasonable expectations (hosts, ports, usernames.
>
> Cassandra makes use of that class.
> Should we rename it and create a subclass for document stores that would
> be empty today?
>
> Emmanuel
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Fri May 15 15:43:39 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 15 May 2015 21:43:39 +0200
Subject: [hibernate-dev] [OGM] DocumentStoreConfiguration
In-Reply-To: <CAFm4XO2XmbGRnJ1DwyXKmUpg6mNwyCw9cxm1ZYsDQdVa-Lk2Tg@mail.gmail.com>
References: <20150515153225.GB36999@hibernate.org>
	<CAFm4XO2XmbGRnJ1DwyXKmUpg6mNwyCw9cxm1ZYsDQdVa-Lk2Tg@mail.gmail.com>
Message-ID: <CADGJaX_cNv4SeXvqHRwAyf6xpwSpFAO9cFZ0N7RuP42tzxYS2w@mail.gmail.com>

Yes, we should.

There is already an issue for this:
https://hibernate.atlassian.net/browse/OGM-798 ("Extract base class from
DocumentStoreConfiguration").

2015-05-15 18:44 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> +1
>
> On 15 May 2015 at 16:32, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > So far DocumentStoreConfiguration is very generic and only deals with
> > remote datastore with reasonable expectations (hosts, ports, usernames.
> >
> > Cassandra makes use of that class.
> > Should we rename it and create a subclass for document stores that would
> > be empty today?
> >
> > Emmanuel
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri May 15 16:14:48 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 15 May 2015 21:14:48 +0100
Subject: [hibernate-dev] AvailableSettings#USE_NEW_ID_GENERATOR_MAPPINGS
Message-ID: <CAFm4XO3JiWZNo=-hH7cMKo=C9vRFc=hfftop_f6XAqjVwk3Uog@mail.gmail.com>

I just noticed that the ORM testsuite seems to consistently set this
option to "true".

The default being false, the "new" kind is available since ORM 3.2
according to javadoc.

Would this be a good time to switch the default?

From steve at hibernate.org  Fri May 15 18:55:43 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 15 May 2015 17:55:43 -0500
Subject: [hibernate-dev] AvailableSettings#USE_NEW_ID_GENERATOR_MAPPINGS
In-Reply-To: <CAFm4XO3JiWZNo=-hH7cMKo=C9vRFc=hfftop_f6XAqjVwk3Uog@mail.gmail.com>
References: <CAFm4XO3JiWZNo=-hH7cMKo=C9vRFc=hfftop_f6XAqjVwk3Uog@mail.gmail.com>
Message-ID: <CAFdSV9t6XUJ6tE1qX1tg-tGq1zmbh2U7FwZbFS7Gk_iA_6yBXQ@mail.gmail.com>

The problem is legacy databases and how to help users migrate the id
generation strategies.  Or are you thinking that existing users would have
to disable this on upgrade?

On Fri, May 15, 2015 at 3:14 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I just noticed that the ORM testsuite seems to consistently set this
> option to "true".
>
> The default being false, the "new" kind is available since ORM 3.2
> according to javadoc.
>
> Would this be a good time to switch the default?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri May 15 19:19:42 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 15 May 2015 18:19:42 -0500
Subject: [hibernate-dev] Checkstyle and ORM
Message-ID: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>

FYI : https://hibernate.atlassian.net/browse/HHH-9803

Its not super high on my priority list, but I want to get to a point where
we can start to fail the build on "serious checkstyle regressions".  Part
of that is being more realistic with what is considered serious, and part
of that is fixing up code.

For example, we have quite a few warnings about spaces rather than tabs for
indentation.  That's a serious one to me.  There are quite a few "unused
import" warnings, again to me that's serious (it just looks sloppy).

A few I have already disabled.  Checking that there is a package-info.java
file for example.  I'd love to make a requirement that all API and SPI
packages have one.  But as far as I know that detailing is not available in
checkstyle, and I really dont overly care about package-info.java files for
internal packages.

These are just a few examples.  #909[1] (still running atm) is the first
build with my preliminary work here.  Let me know if there are any checks
anyone feels strongly about in one bucket or another.


[1] http://ci.hibernate.org/job/hibernate-orm-master-h2/909/

From sanne at hibernate.org  Sat May 16 10:11:02 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 16 May 2015 15:11:02 +0100
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
Message-ID: <CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>

One nice thing of checkstyle is that it's easily extended, for example
in Search we added a couple of checks, like to ban double whitespaces:
 - https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/DoubleSpacesCheck.java

Or to ban specific import statements:
 - https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/IllegalImport.java

For example this is useful to iteratively move away from
commons-annotations, like we ban its AssertionFailure to favor usage
of a different AssertionFailure within Search:
 - https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/resources/checkstyle.xml#L172

But checkstyle isn't enough, I for one would love to ban auto-boxing
from our main code (it's ok in tests) as I'd rather the syntax call
explicit attention to it.
Sometimes it's dangerous for performance reasons, or because of other
subtle API compability reasons like the JBoss Logger upgrade.. but
checktyle can't do such things, you need to add additional tools to
the mix, like FindBugs.

Have a look at the above linked checkstyle.xml for more ideas, but
sometimes I feel we've been too strict as it does fire back on quick
prototyping: it's very annoying to have your build fail for a couple
of style errors when you're deep in debugging some functionality..
I'd rather stick to it though, as it can be disabled locally with
appropriate flags and there finally are no more delays in pull request
reviews because of whitespacing.

To make it slightly less annoying I've made a CheckStyle filter which
allows us to enforce some selected rules only on non-test code:
 - https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/filters/ExcludeTestPackages.java

We could similarly extend it to enforce a package-info.java for all
non-test, non .impl packages?

One which I would strongly enforce is about having the right copyright
headers. For example I've seen various hibernate-infinispan classes
using a non-Hibernate template. The traditional header includes the
year, which was sometimes problematic (like you'd copy an header in a
new class and mark it with a 6 years old copyright); so now we're
using a simplified copyright template which is shorter and has no
mention years:
 - https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/analyzer/Discriminator.java#L1-L6
(according to legal that's good enough)

-- Sanne


On 16 May 2015 at 00:19, Steve Ebersole <steve at hibernate.org> wrote:
> FYI : https://hibernate.atlassian.net/browse/HHH-9803
>
> Its not super high on my priority list, but I want to get to a point where
> we can start to fail the build on "serious checkstyle regressions".  Part
> of that is being more realistic with what is considered serious, and part
> of that is fixing up code.
>
> For example, we have quite a few warnings about spaces rather than tabs for
> indentation.  That's a serious one to me.  There are quite a few "unused
> import" warnings, again to me that's serious (it just looks sloppy).
>
> A few I have already disabled.  Checking that there is a package-info.java
> file for example.  I'd love to make a requirement that all API and SPI
> packages have one.  But as far as I know that detailing is not available in
> checkstyle, and I really dont overly care about package-info.java files for
> internal packages.
>
> These are just a few examples.  #909[1] (still running atm) is the first
> build with my preliminary work here.  Let me know if there are any checks
> anyone feels strongly about in one bucket or another.
>
>
> [1] http://ci.hibernate.org/job/hibernate-orm-master-h2/909/
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Sat May 16 10:16:49 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sat, 16 May 2015 15:16:49 +0100
Subject: [hibernate-dev] AvailableSettings#USE_NEW_ID_GENERATOR_MAPPINGS
In-Reply-To: <CAFdSV9t6XUJ6tE1qX1tg-tGq1zmbh2U7FwZbFS7Gk_iA_6yBXQ@mail.gmail.com>
References: <CAFm4XO3JiWZNo=-hH7cMKo=C9vRFc=hfftop_f6XAqjVwk3Uog@mail.gmail.com>
	<CAFdSV9t6XUJ6tE1qX1tg-tGq1zmbh2U7FwZbFS7Gk_iA_6yBXQ@mail.gmail.com>
Message-ID: <CAFm4XO2hKpcAfHv1EsAiBLO3DPxLUNOZZQO+DuUABMt=bP88bQ@mail.gmail.com>

On 15 May 2015 at 23:55, Steve Ebersole <steve at hibernate.org> wrote:
> The problem is legacy databases and how to help users migrate the id
> generation strategies.  Or are you thinking that existing users would have
> to disable this on upgrade?

I would expect that yes. Or is there no reasonable benefit in using
the new ones?

It's a tradeoff which I can't judge, I just pointed it out as it
seemed a forgotten detail.

-- Sanne

>
> On Fri, May 15, 2015 at 3:14 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> I just noticed that the ORM testsuite seems to consistently set this
>> option to "true".
>>
>> The default being false, the "new" kind is available since ORM 3.2
>> according to javadoc.
>>
>> Would this be a good time to switch the default?
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Sat May 16 14:02:49 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 16 May 2015 13:02:49 -0500
Subject: [hibernate-dev] AvailableSettings#USE_NEW_ID_GENERATOR_MAPPINGS
In-Reply-To: <CAFm4XO2hKpcAfHv1EsAiBLO3DPxLUNOZZQO+DuUABMt=bP88bQ@mail.gmail.com>
References: <CAFm4XO3JiWZNo=-hH7cMKo=C9vRFc=hfftop_f6XAqjVwk3Uog@mail.gmail.com>
	<CAFdSV9t6XUJ6tE1qX1tg-tGq1zmbh2U7FwZbFS7Gk_iA_6yBXQ@mail.gmail.com>
	<CAFm4XO2hKpcAfHv1EsAiBLO3DPxLUNOZZQO+DuUABMt=bP88bQ@mail.gmail.com>
Message-ID: <CAFdSV9u=C9Na3wQOJoperpbg1yDOv9F5aP-JKLe5ZpZa5GLb-A@mail.gmail.com>

>From a performance and maintainability perspective I think there is a big
win in moving to the new generators.  But the problem is people migrating
and the change in expectations.  2 specific examples:

1) User migrating where the legacy code picked "identity" generation.  The
new code would pick "sequence style" generation.  How do these users
migrate or update their schemas?  I am pretty sure our schema update tool
does not support de-IDENTITY-fying columns.  In fact I don't even know how
to do that in any db, let along in any kind of standard way.

2) Users migrating where the legacy code picked any of the "hilo"
generations.  The new code would pick "sequence style" generation.  Here
the problem is the values stored in the sequence/id-table versus how those
are translated to id values stored in the entity tables.   How would users
migrate those values?


On Sat, May 16, 2015 at 9:16 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 15 May 2015 at 23:55, Steve Ebersole <steve at hibernate.org> wrote:
> > The problem is legacy databases and how to help users migrate the id
> > generation strategies.  Or are you thinking that existing users would
> have
> > to disable this on upgrade?
>
> I would expect that yes. Or is there no reasonable benefit in using
> the new ones?
>
> It's a tradeoff which I can't judge, I just pointed it out as it
> seemed a forgotten detail.
>
> -- Sanne
>
> >
> > On Fri, May 15, 2015 at 3:14 PM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> I just noticed that the ORM testsuite seems to consistently set this
> >> option to "true".
> >>
> >> The default being false, the "new" kind is available since ORM 3.2
> >> according to javadoc.
> >>
> >> Would this be a good time to switch the default?
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.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  Sat May 16 14:18:18 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 16 May 2015 13:18:18 -0500
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
Message-ID: <CAFdSV9t+6t7EhCPVGj4rbPQQ-ycU7XpqmqDCNCtqLeOWMC6DOQ@mail.gmail.com>

Yes, we use FindBugs too; I will start a discussion about it after this.  I
wanted to do CheckStyle first because its easier to work with IMO.  And yes
we use FindBugs because there are thins it can do that CheckStyle just
cannot (like checking for the use of non-localized
String#toUpperCase/toLowerCase that we consider a bug).  Certainly the 2
work in tandem.

Using filters is an interesting discussion as we do have this in ORM as
well.  The thing we keep running into is generated sources, but I can
certainly see what you do for tests as well.  BTW, your filter impl
mentions checking for "[not required for tests]", but I do not see that at
all in the CheckStyle config you linked[1]?

Yes, we should simplify the header and start enforcing it.  I think a first
pass for CheckStyle actually failing a build would be:
1) Use of spaces rather than tabs
2) No file header

Again, I said *fail* the build.  So these are the ones I would consider an
error initially.  We'd still have others come up as a warning.  Also in
Gradle these are not run depending on what task you run.  If you simply run
test, "code quality" (checkstyle, findbugs, etc) are not run.  CI runs the
check task as well.

Anyone want to "bang the table" to add more to the failure list?

[1]
https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/resources/checkstyle.xml#L172

On Sat, May 16, 2015 at 9:11 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> One nice thing of checkstyle is that it's easily extended, for example
> in Search we added a couple of checks, like to ban double whitespaces:
>  -
> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/DoubleSpacesCheck.java
>
> Or to ban specific import statements:
>  -
> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/IllegalImport.java
>
> For example this is useful to iteratively move away from
> commons-annotations, like we ban its AssertionFailure to favor usage
> of a different AssertionFailure within Search:
>  -
> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/resources/checkstyle.xml#L172
>
> But checkstyle isn't enough, I for one would love to ban auto-boxing
> from our main code (it's ok in tests) as I'd rather the syntax call
> explicit attention to it.
> Sometimes it's dangerous for performance reasons, or because of other
> subtle API compability reasons like the JBoss Logger upgrade.. but
> checktyle can't do such things, you need to add additional tools to
> the mix, like FindBugs.
>
> Have a look at the above linked checkstyle.xml for more ideas, but
> sometimes I feel we've been too strict as it does fire back on quick
> prototyping: it's very annoying to have your build fail for a couple
> of style errors when you're deep in debugging some functionality..
> I'd rather stick to it though, as it can be disabled locally with
> appropriate flags and there finally are no more delays in pull request
> reviews because of whitespacing.
>
> To make it slightly less annoying I've made a CheckStyle filter which
> allows us to enforce some selected rules only on non-test code:
>  -
> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/filters/ExcludeTestPackages.java
>
> We could similarly extend it to enforce a package-info.java for all
> non-test, non .impl packages?
>
> One which I would strongly enforce is about having the right copyright
> headers. For example I've seen various hibernate-infinispan classes
> using a non-Hibernate template. The traditional header includes the
> year, which was sometimes problematic (like you'd copy an header in a
> new class and mark it with a 6 years old copyright); so now we're
> using a simplified copyright template which is shorter and has no
> mention years:
>  -
> https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/analyzer/Discriminator.java#L1-L6
> (according to legal that's good enough)
>
> -- Sanne
>
>
> On 16 May 2015 at 00:19, Steve Ebersole <steve at hibernate.org> wrote:
> > FYI : https://hibernate.atlassian.net/browse/HHH-9803
> >
> > Its not super high on my priority list, but I want to get to a point
> where
> > we can start to fail the build on "serious checkstyle regressions".  Part
> > of that is being more realistic with what is considered serious, and part
> > of that is fixing up code.
> >
> > For example, we have quite a few warnings about spaces rather than tabs
> for
> > indentation.  That's a serious one to me.  There are quite a few "unused
> > import" warnings, again to me that's serious (it just looks sloppy).
> >
> > A few I have already disabled.  Checking that there is a
> package-info.java
> > file for example.  I'd love to make a requirement that all API and SPI
> > packages have one.  But as far as I know that detailing is not available
> in
> > checkstyle, and I really dont overly care about package-info.java files
> for
> > internal packages.
> >
> > These are just a few examples.  #909[1] (still running atm) is the first
> > build with my preliminary work here.  Let me know if there are any checks
> > anyone feels strongly about in one bucket or another.
> >
> >
> > [1] http://ci.hibernate.org/job/hibernate-orm-master-h2/909/
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.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  Sat May 16 14:26:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 16 May 2015 13:26:11 -0500
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFdSV9t+6t7EhCPVGj4rbPQQ-ycU7XpqmqDCNCtqLeOWMC6DOQ@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<CAFdSV9t+6t7EhCPVGj4rbPQQ-ycU7XpqmqDCNCtqLeOWMC6DOQ@mail.gmail.com>
Message-ID: <CAFdSV9v8Jr8VsdrcfYCQWPg3h1OX3udBPTonvuOcO2kVkyy+sA@mail.gmail.com>

Actually a few others I will add:

3) missing @Override
4) missing @Deprecated/@deprecated
5) missing braces
6) star imports
7) redundant imports
8) lower case 'l' for long literals (upper case is much more readable)
9) missing newline at end of file


On Sat, May 16, 2015 at 1:18 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Yes, we use FindBugs too; I will start a discussion about it after this.
> I wanted to do CheckStyle first because its easier to work with IMO.  And
> yes we use FindBugs because there are thins it can do that CheckStyle just
> cannot (like checking for the use of non-localized
> String#toUpperCase/toLowerCase that we consider a bug).  Certainly the 2
> work in tandem.
>
> Using filters is an interesting discussion as we do have this in ORM as
> well.  The thing we keep running into is generated sources, but I can
> certainly see what you do for tests as well.  BTW, your filter impl
> mentions checking for "[not required for tests]", but I do not see that at
> all in the CheckStyle config you linked[1]?
>
> Yes, we should simplify the header and start enforcing it.  I think a
> first pass for CheckStyle actually failing a build would be:
> 1) Use of spaces rather than tabs
> 2) No file header
>
> Again, I said *fail* the build.  So these are the ones I would consider an
> error initially.  We'd still have others come up as a warning.  Also in
> Gradle these are not run depending on what task you run.  If you simply run
> test, "code quality" (checkstyle, findbugs, etc) are not run.  CI runs the
> check task as well.
>
> Anyone want to "bang the table" to add more to the failure list?
>
> [1]
> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/resources/checkstyle.xml#L172
>
> On Sat, May 16, 2015 at 9:11 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> One nice thing of checkstyle is that it's easily extended, for example
>> in Search we added a couple of checks, like to ban double whitespaces:
>>  -
>> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/DoubleSpacesCheck.java
>>
>> Or to ban specific import statements:
>>  -
>> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/IllegalImport.java
>>
>> For example this is useful to iteratively move away from
>> commons-annotations, like we ban its AssertionFailure to favor usage
>> of a different AssertionFailure within Search:
>>  -
>> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/resources/checkstyle.xml#L172
>>
>> But checkstyle isn't enough, I for one would love to ban auto-boxing
>> from our main code (it's ok in tests) as I'd rather the syntax call
>> explicit attention to it.
>> Sometimes it's dangerous for performance reasons, or because of other
>> subtle API compability reasons like the JBoss Logger upgrade.. but
>> checktyle can't do such things, you need to add additional tools to
>> the mix, like FindBugs.
>>
>> Have a look at the above linked checkstyle.xml for more ideas, but
>> sometimes I feel we've been too strict as it does fire back on quick
>> prototyping: it's very annoying to have your build fail for a couple
>> of style errors when you're deep in debugging some functionality..
>> I'd rather stick to it though, as it can be disabled locally with
>> appropriate flags and there finally are no more delays in pull request
>> reviews because of whitespacing.
>>
>> To make it slightly less annoying I've made a CheckStyle filter which
>> allows us to enforce some selected rules only on non-test code:
>>  -
>> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/filters/ExcludeTestPackages.java
>>
>> We could similarly extend it to enforce a package-info.java for all
>> non-test, non .impl packages?
>>
>> One which I would strongly enforce is about having the right copyright
>> headers. For example I've seen various hibernate-infinispan classes
>> using a non-Hibernate template. The traditional header includes the
>> year, which was sometimes problematic (like you'd copy an header in a
>> new class and mark it with a 6 years old copyright); so now we're
>> using a simplified copyright template which is shorter and has no
>> mention years:
>>  -
>> https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/analyzer/Discriminator.java#L1-L6
>> (according to legal that's good enough)
>>
>> -- Sanne
>>
>>
>> On 16 May 2015 at 00:19, Steve Ebersole <steve at hibernate.org> wrote:
>> > FYI : https://hibernate.atlassian.net/browse/HHH-9803
>> >
>> > Its not super high on my priority list, but I want to get to a point
>> where
>> > we can start to fail the build on "serious checkstyle regressions".
>> Part
>> > of that is being more realistic with what is considered serious, and
>> part
>> > of that is fixing up code.
>> >
>> > For example, we have quite a few warnings about spaces rather than tabs
>> for
>> > indentation.  That's a serious one to me.  There are quite a few "unused
>> > import" warnings, again to me that's serious (it just looks sloppy).
>> >
>> > A few I have already disabled.  Checking that there is a
>> package-info.java
>> > file for example.  I'd love to make a requirement that all API and SPI
>> > packages have one.  But as far as I know that detailing is not
>> available in
>> > checkstyle, and I really dont overly care about package-info.java files
>> for
>> > internal packages.
>> >
>> > These are just a few examples.  #909[1] (still running atm) is the first
>> > build with my preliminary work here.  Let me know if there are any
>> checks
>> > anyone feels strongly about in one bucket or another.
>> >
>> >
>> > [1] http://ci.hibernate.org/job/hibernate-orm-master-h2/909/
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev at lists.jboss.org
>> > https://lists.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  Sat May 16 14:43:03 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 16 May 2015 13:43:03 -0500
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFdSV9v8Jr8VsdrcfYCQWPg3h1OX3udBPTonvuOcO2kVkyy+sA@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<CAFdSV9t+6t7EhCPVGj4rbPQQ-ycU7XpqmqDCNCtqLeOWMC6DOQ@mail.gmail.com>
	<CAFdSV9v8Jr8VsdrcfYCQWPg3h1OX3udBPTonvuOcO2kVkyy+sA@mail.gmail.com>
Message-ID: <CAFdSV9t+-xzz2Pzj7CbpmV0595XYNP0serYu_3z8g6tFvYHjXw@mail.gmail.com>

Sanne, can you give me the low-down on this line?

<property name="cacheFile" value="${checkstyle.cache.file}" />

On Sat, May 16, 2015 at 1:26 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Actually a few others I will add:
>
> 3) missing @Override
> 4) missing @Deprecated/@deprecated
> 5) missing braces
> 6) star imports
> 7) redundant imports
> 8) lower case 'l' for long literals (upper case is much more readable)
> 9) missing newline at end of file
>
>
> On Sat, May 16, 2015 at 1:18 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Yes, we use FindBugs too; I will start a discussion about it after this.
>> I wanted to do CheckStyle first because its easier to work with IMO.  And
>> yes we use FindBugs because there are thins it can do that CheckStyle just
>> cannot (like checking for the use of non-localized
>> String#toUpperCase/toLowerCase that we consider a bug).  Certainly the 2
>> work in tandem.
>>
>> Using filters is an interesting discussion as we do have this in ORM as
>> well.  The thing we keep running into is generated sources, but I can
>> certainly see what you do for tests as well.  BTW, your filter impl
>> mentions checking for "[not required for tests]", but I do not see that at
>> all in the CheckStyle config you linked[1]?
>>
>> Yes, we should simplify the header and start enforcing it.  I think a
>> first pass for CheckStyle actually failing a build would be:
>> 1) Use of spaces rather than tabs
>> 2) No file header
>>
>> Again, I said *fail* the build.  So these are the ones I would consider
>> an error initially.  We'd still have others come up as a warning.  Also in
>> Gradle these are not run depending on what task you run.  If you simply run
>> test, "code quality" (checkstyle, findbugs, etc) are not run.  CI runs the
>> check task as well.
>>
>> Anyone want to "bang the table" to add more to the failure list?
>>
>> [1]
>> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/resources/checkstyle.xml#L172
>>
>> On Sat, May 16, 2015 at 9:11 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>>
>>> One nice thing of checkstyle is that it's easily extended, for example
>>> in Search we added a couple of checks, like to ban double whitespaces:
>>>  -
>>> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/DoubleSpacesCheck.java
>>>
>>> Or to ban specific import statements:
>>>  -
>>> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/IllegalImport.java
>>>
>>> For example this is useful to iteratively move away from
>>> commons-annotations, like we ban its AssertionFailure to favor usage
>>> of a different AssertionFailure within Search:
>>>  -
>>> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/resources/checkstyle.xml#L172
>>>
>>> But checkstyle isn't enough, I for one would love to ban auto-boxing
>>> from our main code (it's ok in tests) as I'd rather the syntax call
>>> explicit attention to it.
>>> Sometimes it's dangerous for performance reasons, or because of other
>>> subtle API compability reasons like the JBoss Logger upgrade.. but
>>> checktyle can't do such things, you need to add additional tools to
>>> the mix, like FindBugs.
>>>
>>> Have a look at the above linked checkstyle.xml for more ideas, but
>>> sometimes I feel we've been too strict as it does fire back on quick
>>> prototyping: it's very annoying to have your build fail for a couple
>>> of style errors when you're deep in debugging some functionality..
>>> I'd rather stick to it though, as it can be disabled locally with
>>> appropriate flags and there finally are no more delays in pull request
>>> reviews because of whitespacing.
>>>
>>> To make it slightly less annoying I've made a CheckStyle filter which
>>> allows us to enforce some selected rules only on non-test code:
>>>  -
>>> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/filters/ExcludeTestPackages.java
>>>
>>> We could similarly extend it to enforce a package-info.java for all
>>> non-test, non .impl packages?
>>>
>>> One which I would strongly enforce is about having the right copyright
>>> headers. For example I've seen various hibernate-infinispan classes
>>> using a non-Hibernate template. The traditional header includes the
>>> year, which was sometimes problematic (like you'd copy an header in a
>>> new class and mark it with a 6 years old copyright); so now we're
>>> using a simplified copyright template which is shorter and has no
>>> mention years:
>>>  -
>>> https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/analyzer/Discriminator.java#L1-L6
>>> (according to legal that's good enough)
>>>
>>> -- Sanne
>>>
>>>
>>> On 16 May 2015 at 00:19, Steve Ebersole <steve at hibernate.org> wrote:
>>> > FYI : https://hibernate.atlassian.net/browse/HHH-9803
>>> >
>>> > Its not super high on my priority list, but I want to get to a point
>>> where
>>> > we can start to fail the build on "serious checkstyle regressions".
>>> Part
>>> > of that is being more realistic with what is considered serious, and
>>> part
>>> > of that is fixing up code.
>>> >
>>> > For example, we have quite a few warnings about spaces rather than
>>> tabs for
>>> > indentation.  That's a serious one to me.  There are quite a few
>>> "unused
>>> > import" warnings, again to me that's serious (it just looks sloppy).
>>> >
>>> > A few I have already disabled.  Checking that there is a
>>> package-info.java
>>> > file for example.  I'd love to make a requirement that all API and SPI
>>> > packages have one.  But as far as I know that detailing is not
>>> available in
>>> > checkstyle, and I really dont overly care about package-info.java
>>> files for
>>> > internal packages.
>>> >
>>> > These are just a few examples.  #909[1] (still running atm) is the
>>> first
>>> > build with my preliminary work here.  Let me know if there are any
>>> checks
>>> > anyone feels strongly about in one bucket or another.
>>> >
>>> >
>>> > [1] http://ci.hibernate.org/job/hibernate-orm-master-h2/909/
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.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 jmnarloch at gmail.com  Sun May 17 15:12:46 2015
From: jmnarloch at gmail.com (Jakub Narloch)
Date: Sun, 17 May 2015 21:12:46 +0200
Subject: [hibernate-dev] Hibernate O/RM Java 8 API.
Message-ID: <CAMs4Jtiso+kp6Z07gDdKmD270Q8fZ+vmb9_YXGJbFtS_Z1h62w@mail.gmail.com>

Hi,

I would like to get back to last year idea, namely the the idea to
introduce new Java 8 API. Since that would not be possible to do directly
in Hibernate Core since it's backward compatibility with Java 6, I had
created a side project that introduces decorator/wrapper on top of
Hibernate Query API that introduces support for Streams<?> and retrieving
Optional<?> results.

I had already implemented the two basic ideas and was hopping for some kind
of feedback whether you would be interested in continouing this idea, also
a code review would be a usefull thing.

References:
Github project: https://github.com/jmnarloch/hibernate-streams-wrapper
JIRA issue: https://hibernate.atlassian.net/browse/HHH-9338

Regards,
Jakub Narloch

From jonathan.halliday at redhat.com  Mon May 18 05:06:59 2015
From: jonathan.halliday at redhat.com (Jonathan Halliday)
Date: Mon, 18 May 2015 10:06:59 +0100
Subject: [hibernate-dev] [OGM] Cassandra failure
In-Reply-To: <20150515155823.GC36999@hibernate.org>
References: <20150515155823.GC36999@hibernate.org>
Message-ID: <5559ABB3.5040800@redhat.com>


yup, looks like the new columns added as part of OGM-717 don't work with 
cassandra.  Which kinda begs the question - how did the branch get into 
that state?  Is the CI skipping tests?

Jonathan.

On 15/05/15 16:58, Emmanuel Bernard wrote:
> Hey Jonathan,
>
> I investigated a bit the Cassandra failure I am seeing.
>
> The logs based on a code change I did are here
> https://gist.github.com/emmanuelbernard/13d22d15dc983a83a7e2
>
> My understanding is that the failing type is the TrueFalseType used on
> Bookmark.isPrivate. This type returns a F char for false.
>
> The commit is recent a2b310 (yesterday).
>
> Emmanuel
>
>

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

From sanne at hibernate.org  Mon May 18 05:11:28 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 18 May 2015 10:11:28 +0100
Subject: [hibernate-dev] [OGM] Cassandra failure
In-Reply-To: <5559ABB3.5040800@redhat.com>
References: <20150515155823.GC36999@hibernate.org>
	<5559ABB3.5040800@redhat.com>
Message-ID: <CAFm4XO2TD7sc6SpS_erix5LaXX0L=i3TCUQHVA9_2kCrwW0yag@mail.gmail.com>

On 18 May 2015 at 10:06, Jonathan Halliday <jonathan.halliday at redhat.com> wrote:
>
> yup, looks like the new columns added as part of OGM-717 don't work with
> cassandra.  Which kinda begs the question - how did the branch get into
> that state?  Is the CI skipping tests?

No, it was reported:
  - http://ci.hibernate.org/view/OGM/job/hibernate-ogm-master/24/

Probably some confusion during PR review.

Sanne

>
> Jonathan.
>
> On 15/05/15 16:58, Emmanuel Bernard wrote:
>> Hey Jonathan,
>>
>> I investigated a bit the Cassandra failure I am seeing.
>>
>> The logs based on a code change I did are here
>> https://gist.github.com/emmanuelbernard/13d22d15dc983a83a7e2
>>
>> My understanding is that the failing type is the TrueFalseType used on
>> Bookmark.isPrivate. This type returns a F char for false.
>>
>> The commit is recent a2b310 (yesterday).
>>
>> Emmanuel
>>
>>
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (USA), Matt Parson
> (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Mon May 18 05:12:56 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 18 May 2015 11:12:56 +0200
Subject: [hibernate-dev] [OGM] Cassandra failure
In-Reply-To: <5559ABB3.5040800@redhat.com>
References: <20150515155823.GC36999@hibernate.org>
	<5559ABB3.5040800@redhat.com>
Message-ID: <CADGJaX9gOOt7bJfo2s_txbfdw9CnPyLiS=hhXkOQHTe6_UoQzQ@mail.gmail.com>

Hey,

Yes, Davide has already sent a fix for this, by mapping these types to
String rather than Character. Indeed CI was skipping test execution for
Cassandra (as CASSANDRA_HOSTNAME wasn't set), I have changed this earlier
this morning. Just re-triggered the build for master, let's see how that
goes.

--Gunnar


2015-05-18 11:06 GMT+02:00 Jonathan Halliday <jonathan.halliday at redhat.com>:

>
> yup, looks like the new columns added as part of OGM-717 don't work with
> cassandra.  Which kinda begs the question - how did the branch get into
> that state?  Is the CI skipping tests?
>
> Jonathan.
>
> On 15/05/15 16:58, Emmanuel Bernard wrote:
> > Hey Jonathan,
> >
> > I investigated a bit the Cassandra failure I am seeing.
> >
> > The logs based on a code change I did are here
> > https://gist.github.com/emmanuelbernard/13d22d15dc983a83a7e2
> >
> > My understanding is that the failing type is the TrueFalseType used on
> > Bookmark.isPrivate. This type returns a F char for false.
> >
> > The commit is recent a2b310 (yesterday).
> >
> > Emmanuel
> >
> >
>
> --
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham (USA), Matt Parson
> (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Mon May 18 05:22:05 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 18 May 2015 10:22:05 +0100
Subject: [hibernate-dev] [OGM] Cassandra failure
In-Reply-To: <CADGJaX9gOOt7bJfo2s_txbfdw9CnPyLiS=hhXkOQHTe6_UoQzQ@mail.gmail.com>
References: <20150515155823.GC36999@hibernate.org>
	<5559ABB3.5040800@redhat.com>
	<CADGJaX9gOOt7bJfo2s_txbfdw9CnPyLiS=hhXkOQHTe6_UoQzQ@mail.gmail.com>
Message-ID: <CAFm4XO05YZa-ob3jzEE8KZec_=QLEUnt28qjzf8=onOqRiinjg@mail.gmail.com>

Ok, sorry I must have checked the build right after you fixed it ..

Thanks,
Sanne

On 18 May 2015 at 10:12, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hey,
>
> Yes, Davide has already sent a fix for this, by mapping these types to
> String rather than Character. Indeed CI was skipping test execution for
> Cassandra (as CASSANDRA_HOSTNAME wasn't set), I have changed this earlier
> this morning. Just re-triggered the build for master, let's see how that
> goes.
>
> --Gunnar
>
>
> 2015-05-18 11:06 GMT+02:00 Jonathan Halliday <jonathan.halliday at redhat.com>:
>
>>
>> yup, looks like the new columns added as part of OGM-717 don't work with
>> cassandra.  Which kinda begs the question - how did the branch get into
>> that state?  Is the CI skipping tests?
>>
>> Jonathan.
>>
>> On 15/05/15 16:58, Emmanuel Bernard wrote:
>> > Hey Jonathan,
>> >
>> > I investigated a bit the Cassandra failure I am seeing.
>> >
>> > The logs based on a code change I did are here
>> > https://gist.github.com/emmanuelbernard/13d22d15dc983a83a7e2
>> >
>> > My understanding is that the failing type is the TrueFalseType used on
>> > Bookmark.isPrivate. This type returns a F char for false.
>> >
>> > The commit is recent a2b310 (yesterday).
>> >
>> > Emmanuel
>> >
>> >
>>
>> --
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham (USA), Matt Parson
>> (USA), Charlie Peters (USA), Michael O'Neill(Ireland)
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From ewastawicka91 at gmail.com  Mon May 18 07:08:11 2015
From: ewastawicka91 at gmail.com (Ewa Stawicka)
Date: Mon, 18 May 2015 13:08:11 +0200
Subject: [hibernate-dev] [OGM] AbstractKey
Message-ID: <CABoYUHwLabfq3c2MD1mAr2WJrrT2D4s3v21MpeW=oD0dK9mHeA@mail.gmail.com>

There are three classes AssociationKey, EnityKey, IdSourceKey, which all
contains methods:
public String[] getColumnNames()
public Object[] getColumnValues()
public String getTable()

and we have three methods in couchdb module:
Identifier.createAssociationId, Identifier.createEntityId,
CouchDBDatastore.createId, each one does basicly the same, but takes
different parameter.
Can we extract abstract class AbstractKey, with columnValues field, some
getters, createId method? I will need createId method in couchbase module.

Ewa

From emmanuel at hibernate.org  Mon May 18 10:14:08 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 18 May 2015 16:14:08 +0200
Subject: [hibernate-dev] [OGM] AbstractKey
In-Reply-To: <CABoYUHwLabfq3c2MD1mAr2WJrrT2D4s3v21MpeW=oD0dK9mHeA@mail.gmail.com>
References: <CABoYUHwLabfq3c2MD1mAr2WJrrT2D4s3v21MpeW=oD0dK9mHeA@mail.gmail.com>
Message-ID: <DA10EDBC-A5CF-462E-AFB8-75058F9448B1@hibernate.org>

No. We had that abstract class before and that turned out to be a bad idea when you factor forever backward compatibility into the mix. 

> On 18 mai 2015, at 13:08, Ewa Stawicka <ewastawicka91 at gmail.com> wrote:
> 
> There are three classes AssociationKey, EnityKey, IdSourceKey, which all
> contains methods:
> public String[] getColumnNames()
> public Object[] getColumnValues()
> public String getTable()
> 
> and we have three methods in couchdb module:
> Identifier.createAssociationId, Identifier.createEntityId,
> CouchDBDatastore.createId, each one does basicly the same, but takes
> different parameter.
> Can we extract abstract class AbstractKey, with columnValues field, some
> getters, createId method? I will need createId method in couchbase module.
> 
> Ewa
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


From emmanuel at hibernate.org  Mon May 18 10:23:23 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 18 May 2015 16:23:23 +0200
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
Message-ID: <83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>

Note that custom checkstyle rule implementations does not fare well with IDE checkstyle rules enforcement. 
I can't make it reliably work on search and OGM. 

> On 16 mai 2015, at 16:11, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> One nice thing of checkstyle is that it's easily extended, for example
> in Search we added a couple of checks, like to ban double whitespaces:
> - https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/DoubleSpacesCheck.java
> 
> Or to ban specific import statements:
> - https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/IllegalImport.java
> 
> For example this is useful to iteratively move away from
> commons-annotations, like we ban its AssertionFailure to favor usage
> of a different AssertionFailure within Search:
> - https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/resources/checkstyle.xml#L172
> 
> But checkstyle isn't enough, I for one would love to ban auto-boxing
> from our main code (it's ok in tests) as I'd rather the syntax call
> explicit attention to it.
> Sometimes it's dangerous for performance reasons, or because of other
> subtle API compability reasons like the JBoss Logger upgrade.. but
> checktyle can't do such things, you need to add additional tools to
> the mix, like FindBugs.
> 
> Have a look at the above linked checkstyle.xml for more ideas, but
> sometimes I feel we've been too strict as it does fire back on quick
> prototyping: it's very annoying to have your build fail for a couple
> of style errors when you're deep in debugging some functionality..
> I'd rather stick to it though, as it can be disabled locally with
> appropriate flags and there finally are no more delays in pull request
> reviews because of whitespacing.
> 
> To make it slightly less annoying I've made a CheckStyle filter which
> allows us to enforce some selected rules only on non-test code:
> - https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/filters/ExcludeTestPackages.java
> 
> We could similarly extend it to enforce a package-info.java for all
> non-test, non .impl packages?
> 
> One which I would strongly enforce is about having the right copyright
> headers. For example I've seen various hibernate-infinispan classes
> using a non-Hibernate template. The traditional header includes the
> year, which was sometimes problematic (like you'd copy an header in a
> new class and mark it with a 6 years old copyright); so now we're
> using a simplified copyright template which is shorter and has no
> mention years:
> - https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/analyzer/Discriminator.java#L1-L6
> (according to legal that's good enough)
> 
> -- Sanne
> 
> 
>> On 16 May 2015 at 00:19, Steve Ebersole <steve at hibernate.org> wrote:
>> FYI : https://hibernate.atlassian.net/browse/HHH-9803
>> 
>> Its not super high on my priority list, but I want to get to a point where
>> we can start to fail the build on "serious checkstyle regressions".  Part
>> of that is being more realistic with what is considered serious, and part
>> of that is fixing up code.
>> 
>> For example, we have quite a few warnings about spaces rather than tabs for
>> indentation.  That's a serious one to me.  There are quite a few "unused
>> import" warnings, again to me that's serious (it just looks sloppy).
>> 
>> A few I have already disabled.  Checking that there is a package-info.java
>> file for example.  I'd love to make a requirement that all API and SPI
>> packages have one.  But as far as I know that detailing is not available in
>> checkstyle, and I really dont overly care about package-info.java files for
>> internal packages.
>> 
>> These are just a few examples.  #909[1] (still running atm) is the first
>> build with my preliminary work here.  Let me know if there are any checks
>> anyone feels strongly about in one bucket or another.
>> 
>> 
>> [1] http://ci.hibernate.org/job/hibernate-orm-master-h2/909/
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.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 May 18 10:52:52 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 18 May 2015 15:52:52 +0100
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFdSV9t+-xzz2Pzj7CbpmV0595XYNP0serYu_3z8g6tFvYHjXw@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<CAFdSV9t+6t7EhCPVGj4rbPQQ-ycU7XpqmqDCNCtqLeOWMC6DOQ@mail.gmail.com>
	<CAFdSV9v8Jr8VsdrcfYCQWPg3h1OX3udBPTonvuOcO2kVkyy+sA@mail.gmail.com>
	<CAFdSV9t+-xzz2Pzj7CbpmV0595XYNP0serYu_3z8g6tFvYHjXw@mail.gmail.com>
Message-ID: <CAFm4XO13AH6VCkQqT9RUPJMc4oAWwbDAv-adyMwKE7_3+CSfig@mail.gmail.com>

On 16 May 2015 at 19:43, Steve Ebersole <steve at hibernate.org> wrote:
>
> Sanne, can you give me the low-down on this line?
>
> <property name="cacheFile" value="${checkstyle.cache.file}" />

I'm not sure of that one; it's "documented" here under TreeWalker section:
 - http://checkstyle.sourceforge.net/config.html

That specific value we use is what is suggested to use in combination
with the Maven plugin which integrates with Checkstyle.
It's supposed to avoid some duplicate checks, however I've not seen
any change in performance, so I guess you could ignore it.

From sanne at hibernate.org  Mon May 18 10:58:46 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 18 May 2015 15:58:46 +0100
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
Message-ID: <CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>

On 18 May 2015 at 15:23, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Note that custom checkstyle rule implementations does not fare well with IDE checkstyle rules enforcement.
> I can't make it reliably work on search and OGM.

As far as I remember the problem was related with having the
customisations as part of the project which is being built.
I'd hope one day we could publish a common set of rules by releasing
the custom as an independent project, consumed by all. We could try
that already for some projects, and see if the others catch up
eventually? They don't even have to use the same XML so there is some
room for customizing which rules exactly each project wants to
enforce.

I'm not sure if that will resolve your problem but it's worth trying;
it could also slightly speed up the builds by a couple of seconds, as
you wouldn't have to rebuild the checkstyle module each time.

From steve at hibernate.org  Mon May 18 11:03:23 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 May 2015 10:03:23 -0500
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
Message-ID: <CAFdSV9tfrqaP+tWKrwjoKfeZV60F9KUACvrqYSCU9wPUkBovVA@mail.gmail.com>

Sure.  Personally I think the "trick" is to keep the number of failures
small.  In fact I initially listed just 9, but am already thinking of
moving at least one from high to medium (and therefore not considered a
failure).




On Mon, May 18, 2015 at 9:23 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Note that custom checkstyle rule implementations does not fare well with
> IDE checkstyle rules enforcement.
> I can't make it reliably work on search and OGM.
>
> > On 16 mai 2015, at 16:11, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> > One nice thing of checkstyle is that it's easily extended, for example
> > in Search we added a couple of checks, like to ban double whitespaces:
> > -
> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/DoubleSpacesCheck.java
> >
> > Or to ban specific import statements:
> > -
> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/checks/regexp/IllegalImport.java
> >
> > For example this is useful to iteratively move away from
> > commons-annotations, like we ban its AssertionFailure to favor usage
> > of a different AssertionFailure within Search:
> > -
> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/resources/checkstyle.xml#L172
> >
> > But checkstyle isn't enough, I for one would love to ban auto-boxing
> > from our main code (it's ok in tests) as I'd rather the syntax call
> > explicit attention to it.
> > Sometimes it's dangerous for performance reasons, or because of other
> > subtle API compability reasons like the JBoss Logger upgrade.. but
> > checktyle can't do such things, you need to add additional tools to
> > the mix, like FindBugs.
> >
> > Have a look at the above linked checkstyle.xml for more ideas, but
> > sometimes I feel we've been too strict as it does fire back on quick
> > prototyping: it's very annoying to have your build fail for a couple
> > of style errors when you're deep in debugging some functionality..
> > I'd rather stick to it though, as it can be disabled locally with
> > appropriate flags and there finally are no more delays in pull request
> > reviews because of whitespacing.
> >
> > To make it slightly less annoying I've made a CheckStyle filter which
> > allows us to enforce some selected rules only on non-test code:
> > -
> https://github.com/hibernate/hibernate-search/blob/master/build-config/src/main/java/org/hibernate/checkstyle/filters/ExcludeTestPackages.java
> >
> > We could similarly extend it to enforce a package-info.java for all
> > non-test, non .impl packages?
> >
> > One which I would strongly enforce is about having the right copyright
> > headers. For example I've seen various hibernate-infinispan classes
> > using a non-Hibernate template. The traditional header includes the
> > year, which was sometimes problematic (like you'd copy an header in a
> > new class and mark it with a 6 years old copyright); so now we're
> > using a simplified copyright template which is shorter and has no
> > mention years:
> > -
> https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/analyzer/Discriminator.java#L1-L6
> > (according to legal that's good enough)
> >
> > -- Sanne
> >
> >
> >> On 16 May 2015 at 00:19, Steve Ebersole <steve at hibernate.org> wrote:
> >> FYI : https://hibernate.atlassian.net/browse/HHH-9803
> >>
> >> Its not super high on my priority list, but I want to get to a point
> where
> >> we can start to fail the build on "serious checkstyle regressions".
> Part
> >> of that is being more realistic with what is considered serious, and
> part
> >> of that is fixing up code.
> >>
> >> For example, we have quite a few warnings about spaces rather than tabs
> for
> >> indentation.  That's a serious one to me.  There are quite a few "unused
> >> import" warnings, again to me that's serious (it just looks sloppy).
> >>
> >> A few I have already disabled.  Checking that there is a
> package-info.java
> >> file for example.  I'd love to make a requirement that all API and SPI
> >> packages have one.  But as far as I know that detailing is not
> available in
> >> checkstyle, and I really dont overly care about package-info.java files
> for
> >> internal packages.
> >>
> >> These are just a few examples.  #909[1] (still running atm) is the first
> >> build with my preliminary work here.  Let me know if there are any
> checks
> >> anyone feels strongly about in one bucket or another.
> >>
> >>
> >> [1] http://ci.hibernate.org/job/hibernate-orm-master-h2/909/
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.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  Mon May 18 11:14:26 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 May 2015 10:14:26 -0500
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
	<CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>
Message-ID: <CAFdSV9vWCO4p-YRwXdzUL_PcvVLWHT8PGLi8xURmvgiVTMFCVQ@mail.gmail.com>

As far as the file header, I have often thought of condensing our ORM one
so that is awesome information.  For my own curiosity did Richard give you
a reason that the copyright statement is not necessary?

On Mon, May 18, 2015 at 9:58 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 18 May 2015 at 15:23, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> > Note that custom checkstyle rule implementations does not fare well with
> IDE checkstyle rules enforcement.
> > I can't make it reliably work on search and OGM.
>
> As far as I remember the problem was related with having the
> customisations as part of the project which is being built.
> I'd hope one day we could publish a common set of rules by releasing
> the custom as an independent project, consumed by all. We could try
> that already for some projects, and see if the others catch up
> eventually? They don't even have to use the same XML so there is some
> room for customizing which rules exactly each project wants to
> enforce.
>
> I'm not sure if that will resolve your problem but it's worth trying;
> it could also slightly speed up the builds by a couple of seconds, as
> you wouldn't have to rebuild the checkstyle module each time.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Mon May 18 11:20:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 May 2015 10:20:59 -0500
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFdSV9vWCO4p-YRwXdzUL_PcvVLWHT8PGLi8xURmvgiVTMFCVQ@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
	<CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>
	<CAFdSV9vWCO4p-YRwXdzUL_PcvVLWHT8PGLi8xURmvgiVTMFCVQ@mail.gmail.com>
Message-ID: <CAFdSV9uq-KUdXbuhFuvZXRoYexMBXfPa5OCv9Mwi5HGiBsdBHQ@mail.gmail.com>

Sorry hit send too soon :(

Anyway.. I assume it is because we know this information from commit
history?

As far as the ORM one, I propose a similar change.  Any objections?

On Mon, May 18, 2015 at 10:14 AM, Steve Ebersole <steve at hibernate.org>
wrote:

> As far as the file header, I have often thought of condensing our ORM one
> so that is awesome information.  For my own curiosity did Richard give you
> a reason that the copyright statement is not necessary?
>
> On Mon, May 18, 2015 at 9:58 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 18 May 2015 at 15:23, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> > Note that custom checkstyle rule implementations does not fare well
>> with IDE checkstyle rules enforcement.
>> > I can't make it reliably work on search and OGM.
>>
>> As far as I remember the problem was related with having the
>> customisations as part of the project which is being built.
>> I'd hope one day we could publish a common set of rules by releasing
>> the custom as an independent project, consumed by all. We could try
>> that already for some projects, and see if the others catch up
>> eventually? They don't even have to use the same XML so there is some
>> room for customizing which rules exactly each project wants to
>> enforce.
>>
>> I'm not sure if that will resolve your problem but it's worth trying;
>> it could also slightly speed up the builds by a couple of seconds, as
>> you wouldn't have to rebuild the checkstyle module each time.
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From emmanuel at hibernate.org  Mon May 18 11:33:19 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 18 May 2015 17:33:19 +0200
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFdSV9uq-KUdXbuhFuvZXRoYexMBXfPa5OCv9Mwi5HGiBsdBHQ@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
	<CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>
	<CAFdSV9vWCO4p-YRwXdzUL_PcvVLWHT8PGLi8xURmvgiVTMFCVQ@mail.gmail.com>
	<CAFdSV9uq-KUdXbuhFuvZXRoYexMBXfPa5OCv9Mwi5HGiBsdBHQ@mail.gmail.com>
Message-ID: <8F9EDE29-707C-4E28-93CF-5159C7A05909@hibernate.org>

+1 I thought it was in already :)

> On 18 mai 2015, at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Sorry hit send too soon :(
> 
> Anyway.. I assume it is because we know this information from commit
> history?
> 
> As far as the ORM one, I propose a similar change.  Any objections?
> 
> On Mon, May 18, 2015 at 10:14 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
> 
>> As far as the file header, I have often thought of condensing our ORM one
>> so that is awesome information.  For my own curiosity did Richard give you
>> a reason that the copyright statement is not necessary?
>> 
>> On Mon, May 18, 2015 at 9:58 AM, Sanne Grinovero <sanne at hibernate.org>
>> wrote:
>> 
>>>> On 18 May 2015 at 15:23, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>>> Note that custom checkstyle rule implementations does not fare well
>>> with IDE checkstyle rules enforcement.
>>>> I can't make it reliably work on search and OGM.
>>> 
>>> As far as I remember the problem was related with having the
>>> customisations as part of the project which is being built.
>>> I'd hope one day we could publish a common set of rules by releasing
>>> the custom as an independent project, consumed by all. We could try
>>> that already for some projects, and see if the others catch up
>>> eventually? They don't even have to use the same XML so there is some
>>> room for customizing which rules exactly each project wants to
>>> enforce.
>>> 
>>> I'm not sure if that will resolve your problem but it's worth trying;
>>> it could also slightly speed up the builds by a couple of seconds, as
>>> you wouldn't have to rebuild the checkstyle module each time.
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.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 May 18 14:44:02 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 May 2015 13:44:02 -0500
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <8F9EDE29-707C-4E28-93CF-5159C7A05909@hibernate.org>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
	<CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>
	<CAFdSV9vWCO4p-YRwXdzUL_PcvVLWHT8PGLi8xURmvgiVTMFCVQ@mail.gmail.com>
	<CAFdSV9uq-KUdXbuhFuvZXRoYexMBXfPa5OCv9Mwi5HGiBsdBHQ@mail.gmail.com>
	<8F9EDE29-707C-4E28-93CF-5159C7A05909@hibernate.org>
Message-ID: <CAFdSV9s9iGSh5uBObMjOeonkOg28b40KkEf-j19rBk=Z3oR01w@mail.gmail.com>

And see, this[1] is exactly the kind of thing I always try to avoid...  Why
did y'all decide on that approach?


[1] https://github.com/hibernate/hibernate-search/blob/master/copyright.txt

On Mon, May 18, 2015 at 10:33 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> +1 I thought it was in already :)
>
> > On 18 mai 2015, at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
> >
> > Sorry hit send too soon :(
> >
> > Anyway.. I assume it is because we know this information from commit
> > history?
> >
> > As far as the ORM one, I propose a similar change.  Any objections?
> >
> > On Mon, May 18, 2015 at 10:14 AM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> As far as the file header, I have often thought of condensing our ORM
> one
> >> so that is awesome information.  For my own curiosity did Richard give
> you
> >> a reason that the copyright statement is not necessary?
> >>
> >> On Mon, May 18, 2015 at 9:58 AM, Sanne Grinovero <sanne at hibernate.org>
> >> wrote:
> >>
> >>>> On 18 May 2015 at 15:23, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >>>> Note that custom checkstyle rule implementations does not fare well
> >>> with IDE checkstyle rules enforcement.
> >>>> I can't make it reliably work on search and OGM.
> >>>
> >>> As far as I remember the problem was related with having the
> >>> customisations as part of the project which is being built.
> >>> I'd hope one day we could publish a common set of rules by releasing
> >>> the custom as an independent project, consumed by all. We could try
> >>> that already for some projects, and see if the others catch up
> >>> eventually? They don't even have to use the same XML so there is some
> >>> room for customizing which rules exactly each project wants to
> >>> enforce.
> >>>
> >>> I'm not sure if that will resolve your problem but it's worth trying;
> >>> it could also slightly speed up the builds by a couple of seconds, as
> >>> you wouldn't have to rebuild the checkstyle module each time.
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.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 May 18 15:48:33 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 18 May 2015 20:48:33 +0100
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFdSV9s9iGSh5uBObMjOeonkOg28b40KkEf-j19rBk=Z3oR01w@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
	<CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>
	<CAFdSV9vWCO4p-YRwXdzUL_PcvVLWHT8PGLi8xURmvgiVTMFCVQ@mail.gmail.com>
	<CAFdSV9uq-KUdXbuhFuvZXRoYexMBXfPa5OCv9Mwi5HGiBsdBHQ@mail.gmail.com>
	<8F9EDE29-707C-4E28-93CF-5159C7A05909@hibernate.org>
	<CAFdSV9s9iGSh5uBObMjOeonkOg28b40KkEf-j19rBk=Z3oR01w@mail.gmail.com>
Message-ID: <CAFm4XO29BHevNy587_Og1CmMvOz_QyMQ+=OHrW941yYWTMXOJw@mail.gmail.com>

On 18 May 2015 at 19:44, Steve Ebersole <steve at hibernate.org> wrote:
> And see, this[1] is exactly the kind of thing I always try to avoid...  Why
> did y'all decide on that approach?

Personally I think the main reason is pride. Some contributors
explicitly asked me if it was ok to add their names, after they had
contributed several nice patches.

FYI I don't update it at each and every release, but when I do I do it
in batches by using the git log: append to existing file, pipe to sort
and pipe to uniq, remove some aliases for same person so it's a low
burden.

I have no idea if there are legal strings attached.

Sanne



>
>
> [1] https://github.com/hibernate/hibernate-search/blob/master/copyright.txt
>
> On Mon, May 18, 2015 at 10:33 AM, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
>>
>> +1 I thought it was in already :)
>>
>> > On 18 mai 2015, at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
>> >
>> > Sorry hit send too soon :(
>> >
>> > Anyway.. I assume it is because we know this information from commit
>> > history?
>> >
>> > As far as the ORM one, I propose a similar change.  Any objections?
>> >
>> > On Mon, May 18, 2015 at 10:14 AM, Steve Ebersole <steve at hibernate.org>
>> > wrote:
>> >
>> >> As far as the file header, I have often thought of condensing our ORM
>> >> one
>> >> so that is awesome information.  For my own curiosity did Richard give
>> >> you
>> >> a reason that the copyright statement is not necessary?
>> >>
>> >> On Mon, May 18, 2015 at 9:58 AM, Sanne Grinovero <sanne at hibernate.org>
>> >> wrote:
>> >>
>> >>>> On 18 May 2015 at 15:23, Emmanuel Bernard <emmanuel at hibernate.org>
>> >>>> wrote:
>> >>>> Note that custom checkstyle rule implementations does not fare well
>> >>> with IDE checkstyle rules enforcement.
>> >>>> I can't make it reliably work on search and OGM.
>> >>>
>> >>> As far as I remember the problem was related with having the
>> >>> customisations as part of the project which is being built.
>> >>> I'd hope one day we could publish a common set of rules by releasing
>> >>> the custom as an independent project, consumed by all. We could try
>> >>> that already for some projects, and see if the others catch up
>> >>> eventually? They don't even have to use the same XML so there is some
>> >>> room for customizing which rules exactly each project wants to
>> >>> enforce.
>> >>>
>> >>> I'm not sure if that will resolve your problem but it's worth trying;
>> >>> it could also slightly speed up the builds by a couple of seconds, as
>> >>> you wouldn't have to rebuild the checkstyle module each time.
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev at lists.jboss.org
>> >>> https://lists.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 May 18 16:07:08 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 May 2015 15:07:08 -0500
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFm4XO29BHevNy587_Og1CmMvOz_QyMQ+=OHrW941yYWTMXOJw@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
	<CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>
	<CAFdSV9vWCO4p-YRwXdzUL_PcvVLWHT8PGLi8xURmvgiVTMFCVQ@mail.gmail.com>
	<CAFdSV9uq-KUdXbuhFuvZXRoYexMBXfPa5OCv9Mwi5HGiBsdBHQ@mail.gmail.com>
	<8F9EDE29-707C-4E28-93CF-5159C7A05909@hibernate.org>
	<CAFdSV9s9iGSh5uBObMjOeonkOg28b40KkEf-j19rBk=Z3oR01w@mail.gmail.com>
	<CAFm4XO29BHevNy587_Og1CmMvOz_QyMQ+=OHrW941yYWTMXOJw@mail.gmail.com>
Message-ID: <CAFdSV9sbOWbwiDpwWGF2tUeBDdR0UeivRk8okjwzmhCKQDfVEQ@mail.gmail.com>

Hardy, do you happen to still have your sed script for updating these file
headers?

On Mon, May 18, 2015 at 2:48 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 18 May 2015 at 19:44, Steve Ebersole <steve at hibernate.org> wrote:
> > And see, this[1] is exactly the kind of thing I always try to avoid...
> Why
> > did y'all decide on that approach?
>
> Personally I think the main reason is pride. Some contributors
> explicitly asked me if it was ok to add their names, after they had
> contributed several nice patches.
>
> FYI I don't update it at each and every release, but when I do I do it
> in batches by using the git log: append to existing file, pipe to sort
> and pipe to uniq, remove some aliases for same person so it's a low
> burden.
>
> I have no idea if there are legal strings attached.
>
> Sanne
>
>
>
> >
> >
> > [1]
> https://github.com/hibernate/hibernate-search/blob/master/copyright.txt
> >
> > On Mon, May 18, 2015 at 10:33 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>
> > wrote:
> >>
> >> +1 I thought it was in already :)
> >>
> >> > On 18 mai 2015, at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
> >> >
> >> > Sorry hit send too soon :(
> >> >
> >> > Anyway.. I assume it is because we know this information from commit
> >> > history?
> >> >
> >> > As far as the ORM one, I propose a similar change.  Any objections?
> >> >
> >> > On Mon, May 18, 2015 at 10:14 AM, Steve Ebersole <steve at hibernate.org
> >
> >> > wrote:
> >> >
> >> >> As far as the file header, I have often thought of condensing our ORM
> >> >> one
> >> >> so that is awesome information.  For my own curiosity did Richard
> give
> >> >> you
> >> >> a reason that the copyright statement is not necessary?
> >> >>
> >> >> On Mon, May 18, 2015 at 9:58 AM, Sanne Grinovero <
> sanne at hibernate.org>
> >> >> wrote:
> >> >>
> >> >>>> On 18 May 2015 at 15:23, Emmanuel Bernard <emmanuel at hibernate.org>
> >> >>>> wrote:
> >> >>>> Note that custom checkstyle rule implementations does not fare well
> >> >>> with IDE checkstyle rules enforcement.
> >> >>>> I can't make it reliably work on search and OGM.
> >> >>>
> >> >>> As far as I remember the problem was related with having the
> >> >>> customisations as part of the project which is being built.
> >> >>> I'd hope one day we could publish a common set of rules by releasing
> >> >>> the custom as an independent project, consumed by all. We could try
> >> >>> that already for some projects, and see if the others catch up
> >> >>> eventually? They don't even have to use the same XML so there is
> some
> >> >>> room for customizing which rules exactly each project wants to
> >> >>> enforce.
> >> >>>
> >> >>> I'm not sure if that will resolve your problem but it's worth
> trying;
> >> >>> it could also slightly speed up the builds by a couple of seconds,
> as
> >> >>> you wouldn't have to rebuild the checkstyle module each time.
> >> >>> _______________________________________________
> >> >>> hibernate-dev mailing list
> >> >>> hibernate-dev at lists.jboss.org
> >> >>> https://lists.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  Mon May 18 23:01:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 May 2015 22:01:28 -0500
Subject: [hibernate-dev] Sharing IDE code styles
Message-ID: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>

The recent discussion on Checkstyle got me thinking about best ways to
share/distribute code styles for IDE setup.  Storing them in the project
itself is not very workable for IntelliJ at least.  I started thinking
about a separate repository under the hibernate GitHub organization.  Does
everyone use the code style I attached to
https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ, or
do y'all use custom versions of that?

Do y'all think it makes any sense to do this?

From steve at hibernate.org  Mon May 18 23:16:56 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 18 May 2015 22:16:56 -0500
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFdSV9sbOWbwiDpwWGF2tUeBDdR0UeivRk8okjwzmhCKQDfVEQ@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
	<CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>
	<CAFdSV9vWCO4p-YRwXdzUL_PcvVLWHT8PGLi8xURmvgiVTMFCVQ@mail.gmail.com>
	<CAFdSV9uq-KUdXbuhFuvZXRoYexMBXfPa5OCv9Mwi5HGiBsdBHQ@mail.gmail.com>
	<8F9EDE29-707C-4E28-93CF-5159C7A05909@hibernate.org>
	<CAFdSV9s9iGSh5uBObMjOeonkOg28b40KkEf-j19rBk=Z3oR01w@mail.gmail.com>
	<CAFm4XO29BHevNy587_Og1CmMvOz_QyMQ+=OHrW941yYWTMXOJw@mail.gmail.com>
	<CAFdSV9sbOWbwiDpwWGF2tUeBDdR0UeivRk8okjwzmhCKQDfVEQ@mail.gmail.com>
Message-ID: <CAFdSV9td5wuJJi-JnzVQgoiEvTCThFEdnH3nLaCgKPYHuWGd=w@mail.gmail.com>

ORM master is now enforcing checkstyle.  The CI builds will fail if you
commit anything that was deemed a severity of error/high.  The only part
missing there is headers, which I will follow up with once I hear back from
Hardy.

On Mon, May 18, 2015 at 3:07 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Hardy, do you happen to still have your sed script for updating these file
> headers?
>
> On Mon, May 18, 2015 at 2:48 PM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> On 18 May 2015 at 19:44, Steve Ebersole <steve at hibernate.org> wrote:
>> > And see, this[1] is exactly the kind of thing I always try to avoid...
>> Why
>> > did y'all decide on that approach?
>>
>> Personally I think the main reason is pride. Some contributors
>> explicitly asked me if it was ok to add their names, after they had
>> contributed several nice patches.
>>
>> FYI I don't update it at each and every release, but when I do I do it
>> in batches by using the git log: append to existing file, pipe to sort
>> and pipe to uniq, remove some aliases for same person so it's a low
>> burden.
>>
>> I have no idea if there are legal strings attached.
>>
>> Sanne
>>
>>
>>
>> >
>> >
>> > [1]
>> https://github.com/hibernate/hibernate-search/blob/master/copyright.txt
>> >
>> > On Mon, May 18, 2015 at 10:33 AM, Emmanuel Bernard <
>> emmanuel at hibernate.org>
>> > wrote:
>> >>
>> >> +1 I thought it was in already :)
>> >>
>> >> > On 18 mai 2015, at 17:20, Steve Ebersole <steve at hibernate.org>
>> wrote:
>> >> >
>> >> > Sorry hit send too soon :(
>> >> >
>> >> > Anyway.. I assume it is because we know this information from commit
>> >> > history?
>> >> >
>> >> > As far as the ORM one, I propose a similar change.  Any objections?
>> >> >
>> >> > On Mon, May 18, 2015 at 10:14 AM, Steve Ebersole <
>> steve at hibernate.org>
>> >> > wrote:
>> >> >
>> >> >> As far as the file header, I have often thought of condensing our
>> ORM
>> >> >> one
>> >> >> so that is awesome information.  For my own curiosity did Richard
>> give
>> >> >> you
>> >> >> a reason that the copyright statement is not necessary?
>> >> >>
>> >> >> On Mon, May 18, 2015 at 9:58 AM, Sanne Grinovero <
>> sanne at hibernate.org>
>> >> >> wrote:
>> >> >>
>> >> >>>> On 18 May 2015 at 15:23, Emmanuel Bernard <emmanuel at hibernate.org
>> >
>> >> >>>> wrote:
>> >> >>>> Note that custom checkstyle rule implementations does not fare
>> well
>> >> >>> with IDE checkstyle rules enforcement.
>> >> >>>> I can't make it reliably work on search and OGM.
>> >> >>>
>> >> >>> As far as I remember the problem was related with having the
>> >> >>> customisations as part of the project which is being built.
>> >> >>> I'd hope one day we could publish a common set of rules by
>> releasing
>> >> >>> the custom as an independent project, consumed by all. We could try
>> >> >>> that already for some projects, and see if the others catch up
>> >> >>> eventually? They don't even have to use the same XML so there is
>> some
>> >> >>> room for customizing which rules exactly each project wants to
>> >> >>> enforce.
>> >> >>>
>> >> >>> I'm not sure if that will resolve your problem but it's worth
>> trying;
>> >> >>> it could also slightly speed up the builds by a couple of seconds,
>> as
>> >> >>> you wouldn't have to rebuild the checkstyle module each time.
>> >> >>> _______________________________________________
>> >> >>> hibernate-dev mailing list
>> >> >>> hibernate-dev at lists.jboss.org
>> >> >>> https://lists.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 galder at redhat.com  Tue May 19 03:22:37 2015
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Tue, 19 May 2015 09:22:37 +0200
Subject: [hibernate-dev] NoSuchMethodError running hibernate-infinispan
	tests with Infinispan 7.2.1
In-Reply-To: <55560381.10607@redhat.com>
References: <1046314230.17809186.1431668505635.JavaMail.zimbra@redhat.com>
	<55560381.10607@redhat.com>
Message-ID: <9A839FB2-2F2D-40AE-B26F-849BCD2CDAE3@redhat.com>

This is not problematic for 2LC users because except in testing, we never check this value in the production code. IOW, in production we set max entries but we don't query it, so it's not problematic. In testing, we verify that the cache's eviction max entries is the one we've configured via the Hibernate/JPA configuration, but that's it.

Thanks Gail for all the hard work!! :)

> On 15 May 2015, at 16:32, Scott Marlow <smarlow at redhat.com> wrote:
> 
> On 05/15/2015 01:41 AM, Gail Badner wrote:
>> Following Steve's suggestion using resolutionStrategy, I was able to build the hibernate-infinispan jar with Infinispan 6.0.0.Final and run the unit tests with 7.2.1.Final.
>> 
>> I'm sure there's a more elegant way to do this, so I've created a new jira (HHH-9802) and a pull request with the change I made: https://github.com/hibernate/hibernate-orm/pull/955 .
>> 
>> There were actually some unit test failures in InfinispanRegionFactoryTestCase using 7.2.1.Final due to java.lang.NoSuchMethodError.
>> 
>> It happens in assertions like:
>> 
>>          assertEquals(5000, cacheCfg.eviction().maxEntries());
>> 
>> The problem is that org.infinispan.configuration.cache.EvictionConfiguration.maxEntries() returns int in 6.0.0.Final, but returns long in 7.2.1.Final. The only usage I see is in the unit tests. I can probably workaround this in the unit test, but I was wondering if this could cause a problem if an application used this method directly.
>> 
>> Galder, do you know if this is a concern?
>> 
>> I have instructions in the pull request for reproducing these failures.
>> 
>> I commented out the failing assertions locally to verify that nothing else causes the test to fail.
>> 
>> I also see org.hibernate.cache.infinispan.TypeOverrides.evictionMaxEntries is defined as an int. That gets initialized based on a value set for on hibernate.cache.infinispan.<classnam>.eviction.max_entries. The only place I see TypeOverrides.getEvictionMaxEntries() used is in InfinispanRegionFactoryTestCase. Does this actually get used anywhere? Does the value find its way into a EvictionConfiguration.maxEntries field? If so, should be a long (instead of an int) in master?
>> 
>> I had a quick chat with Scott Marlow when I realized this was a potential problem and we agreed that it shouldn't block releasing Hibernate ORM 4.3.10.Final. I have gone ahead and released 4.3.10.Final.
> 
> As far as I can tell, applications that compile against Infinispan 6.x, will be expecting cacheCfg.eviction().maxEntries() to always be an int (as Gail states).  Those applications will be broken when they try to drop in Infinispan 7.x.  I don't think this is a Hibernate bug but think we need input from infinispan-dev.  I'll try cross posting on that mailing list.
> 
>> 
>> I will check in on things Friday morning, but I have to leave by 10:30am and will be off the rest of the day. I can pick this up on Monday if need be.
>> 
>> Regards,
>> Gail
>> 


--
Galder Zamarre?o
galder at redhat.com






From dreborier at gmail.com  Tue May 19 04:59:27 2015
From: dreborier at gmail.com (andrea boriero)
Date: Tue, 19 May 2015 09:59:27 +0100
Subject: [hibernate-dev] Sharing IDE code styles
In-Reply-To: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>
References: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>
Message-ID: <CAL00eSRy9iuK8vmxLGXMNHZLUD2WQA-CrMZVQ5Ffqc8LUML41g@mail.gmail.com>

I'm using your version

On 19 May 2015 at 04:01, Steve Ebersole <steve at hibernate.org> wrote:

> The recent discussion on Checkstyle got me thinking about best ways to
> share/distribute code styles for IDE setup.  Storing them in the project
> itself is not very workable for IntelliJ at least.  I started thinking
> about a separate repository under the hibernate GitHub organization.  Does
> everyone use the code style I attached to
> https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ, or
> do y'all use custom versions of that?
>
> Do y'all think it makes any sense to do this?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Tue May 19 06:44:23 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 19 May 2015 11:44:23 +0100
Subject: [hibernate-dev] [ORM|OGM|Search] Adding an unwrap() new method to
	org.hibernate.Session
Message-ID: <CAFm4XO0mM8DaNcdYHFezruoqe_mpG7v2ivC5WQzHaZH7=f7H_Q@mail.gmail.com>

I was looking at how Search and OGM benefit from the
SessionDelegatorBaseImpl; extending this base class was a good
progress but there is something missing.

OGM has to still reimplement all methods defined by the EventSource
contract, making the implementation confusing as while it extends the
base delegate it still has to directly delegate for many other
methods.
So my initial impulse was to go and refactor the
SessionDelegatorBaseImpl to actually be an "EventSourceBaseDelegator",
adding the additional interface and delegates for the missing methods.

But questioning why the OGM Session needs to implement EventSource, it
turns out the reason is that when it uses Search this needs to access
the EventSource and will cast the given Session to one; so OGM's
Session has to implement that interface too, only for this reason.

Such a cast has never been dangerous for Search in the past as there
was only one Session but the existence of the SessionDelegatorBaseImpl
in ORM is making it easy to see more Session implementations which
actually don't implement EventSource (and often don't need to).
Rather than forcing / recommending all implementors to consistently
extend EventSource as well, it would be nice to introduce a way to get
a typesafe reference to the only EventSource we need.

My proposal is to add an unwrap() method to the public
org.hibernate.Session, like the one in JPA, and enhance the
implementation of both SessionImpl#unwrap and the
EntityManagerImpl#unwrap() to also satisfy requests for the
EventSource.class, and then possibly other such components as needed.

I would then be able to remove some casts in various places, and OGM's
Session wouldn't need to implement the EventSource interface.

ok?

Thanks,
Sanne

From hardy at hibernate.org  Tue May 19 10:33:43 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 19 May 2015 16:33:43 +0200
Subject: [hibernate-dev] Checkstyle and ORM
In-Reply-To: <CAFdSV9sbOWbwiDpwWGF2tUeBDdR0UeivRk8okjwzmhCKQDfVEQ@mail.gmail.com>
References: <CAFdSV9ss2rD6QS=_oQYB0-zLfWK8wM8YcBpT+SiJd_Z7VX4Xgw@mail.gmail.com>
	<CAFm4XO2DfG12ccvJnq_A693KM=h5Je5Y1GKwL5JTR+XpXRwLfQ@mail.gmail.com>
	<83ACABFB-A501-450E-8314-5DA62C3DD808@hibernate.org>
	<CAFm4XO1hR_HkcdSp0ZnutuAXLS+3b67i8P6XSytoY_njmm-pqg@mail.gmail.com>
	<CAFdSV9vWCO4p-YRwXdzUL_PcvVLWHT8PGLi8xURmvgiVTMFCVQ@mail.gmail.com>
	<CAFdSV9uq-KUdXbuhFuvZXRoYexMBXfPa5OCv9Mwi5HGiBsdBHQ@mail.gmail.com>
	<8F9EDE29-707C-4E28-93CF-5159C7A05909@hibernate.org>
	<CAFdSV9s9iGSh5uBObMjOeonkOg28b40KkEf-j19rBk=Z3oR01w@mail.gmail.com>
	<CAFm4XO29BHevNy587_Og1CmMvOz_QyMQ+=OHrW941yYWTMXOJw@mail.gmail.com>
	<CAFdSV9sbOWbwiDpwWGF2tUeBDdR0UeivRk8okjwzmhCKQDfVEQ@mail.gmail.com>
Message-ID: <20150519143343.GA1059@Nineveh.fritz.box>

On Mon, May 18, 2015 at 03:07:08PM -0500, Steve Ebersole wrote:
> Hardy, do you happen to still have your sed script for updating these file
> headers?

I do, they are attached to the JIRA issue - https://hibernate.atlassian.net/browse/HV-926.
You will need to adjust them to your needs. I used find and xargs to pass the files
to sed, then I use two regular expressions to define the start and range of the replace "c"
command. The first regular expression matches the first line of the license header and the 
second the last. Since Validator already had a consistent license header, I only needed one
single sed command. If the license headers currently used in ORM differ a lot you might have 
to run multiple.

As Gunnar pointed out to me, there is maven-license-plugin which also has a Gradle
"port" - https://github.com/hierynomus/license-gradle-plugin. I have no experience with
either plugin though. 

--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/20150519/363fe85c/attachment-0001.bin 

From hardy at hibernate.org  Tue May 19 10:40:23 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 19 May 2015 16:40:23 +0200
Subject: [hibernate-dev] Sharing IDE code styles
In-Reply-To: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>
References: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>
Message-ID: <20150519144023.GB1059@Nineveh.fritz.box>

Hi,

Hibernate Validator used initially the same style as ORM. I am saying used
to since the file attached to this url - http://hibernate.org/validator/contribute/ -
seems to differ a fair bit from the file you are referring to. 
A lot of the difference might just be indentation and re-ordering issues. After all
your version is hibernate-style-steve-2.xml. My guess is that the Validator style is
derived from hibernate-style-steve-1.xml :-)

Either way, differences should not be so huge.

--Hardy 

On Mon, May 18, 2015 at 10:01:28PM -0500, Steve Ebersole wrote:
> The recent discussion on Checkstyle got me thinking about best ways to
> share/distribute code styles for IDE setup.  Storing them in the project
> itself is not very workable for IntelliJ at least.  I started thinking
> about a separate repository under the hibernate GitHub organization.  Does
> everyone use the code style I attached to
> https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ, or
> do y'all use custom versions of that?
> 
> Do y'all think it makes any sense to do this?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
-------------- 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/20150519/6b3bece6/attachment.bin 

From steve at hibernate.org  Tue May 19 11:07:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 May 2015 10:07:09 -0500
Subject: [hibernate-dev] Sharing IDE code styles
In-Reply-To: <20150519144023.GB1059@Nineveh.fritz.box>
References: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>
	<20150519144023.GB1059@Nineveh.fritz.box>
Message-ID: <CAFdSV9tq1DcjD4D5CzSd=W29Fn6B+XBUNU9U5e9fvMPjy1eCpA@mail.gmail.com>

My thinking was more about how to find which one supersedes which others.
If I (as a contributor) have a few of these code style files available to
me from the Hibernate team, how do I know which is the latest?

As I pointed out, I actually had to update my code style slightly after
migrating to 14 because it was inadvertently introducing leading spaces
rather than tabs in certain cases.  Which illustrates that there are really
2 axis in play here, the targetted version of IDE and the version of the
code style.

Anyway, this is what got me thinking that using git might be nice for this,
and GitHub could make it centrally available.


On Tue, May 19, 2015 at 9:40 AM, Hardy Ferentschik <hardy at hibernate.org>
wrote:

> Hi,
>
> Hibernate Validator used initially the same style as ORM. I am saying used
> to since the file attached to this url -
> http://hibernate.org/validator/contribute/ -
> seems to differ a fair bit from the file you are referring to.
> A lot of the difference might just be indentation and re-ordering issues.
> After all
> your version is hibernate-style-steve-2.xml. My guess is that the
> Validator style is
> derived from hibernate-style-steve-1.xml :-)
>
> Either way, differences should not be so huge.
>
> --Hardy
>
> On Mon, May 18, 2015 at 10:01:28PM -0500, Steve Ebersole wrote:
> > The recent discussion on Checkstyle got me thinking about best ways to
> > share/distribute code styles for IDE setup.  Storing them in the project
> > itself is not very workable for IntelliJ at least.  I started thinking
> > about a separate repository under the hibernate GitHub organization.
> Does
> > everyone use the code style I attached to
> > https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ,
> or
> > do y'all use custom versions of that?
> >
> > Do y'all think it makes any sense to do 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 May 19 11:14:14 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 May 2015 10:14:14 -0500
Subject: [hibernate-dev] Hibernate O/RM Java 8 API.
In-Reply-To: <CAMs4Jtiso+kp6Z07gDdKmD270Q8fZ+vmb9_YXGJbFtS_Z1h62w@mail.gmail.com>
References: <CAMs4Jtiso+kp6Z07gDdKmD270Q8fZ+vmb9_YXGJbFtS_Z1h62w@mail.gmail.com>
Message-ID: <CAFdSV9tWUv=3RL+hCi2Er1pM1UojQc2d756Ybc0wXcFmWqbtbQ@mail.gmail.com>

Jakub,

Thanks for starting on this :)

I think the thing that is missing here is the one that most users will want
which is support for Optional attributes in their domain model.  Of course
that is the harder one because it would require changes inside Hibernate.

I'll take a look at the code and give you any kind of feedback I can.  What
do you mean by asking if we are "interested in [continuing] this idea"?

On Sun, May 17, 2015 at 2:12 PM, Jakub Narloch <jmnarloch at gmail.com> wrote:

> Hi,
>
> I would like to get back to last year idea, namely the the idea to
> introduce new Java 8 API. Since that would not be possible to do directly
> in Hibernate Core since it's backward compatibility with Java 6, I had
> created a side project that introduces decorator/wrapper on top of
> Hibernate Query API that introduces support for Streams<?> and retrieving
> Optional<?> results.
>
> I had already implemented the two basic ideas and was hopping for some kind
> of feedback whether you would be interested in continouing this idea, also
> a code review would be a usefull thing.
>
> References:
> Github project: https://github.com/jmnarloch/hibernate-streams-wrapper
> JIRA issue: https://hibernate.atlassian.net/browse/HHH-9338
>
> Regards,
> Jakub Narloch
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue May 19 11:21:11 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 19 May 2015 17:21:11 +0200
Subject: [hibernate-dev] Sharing IDE code styles
In-Reply-To: <CAFdSV9tq1DcjD4D5CzSd=W29Fn6B+XBUNU9U5e9fvMPjy1eCpA@mail.gmail.com>
References: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>
	<20150519144023.GB1059@Nineveh.fritz.box>
	<CAFdSV9tq1DcjD4D5CzSd=W29Fn6B+XBUNU9U5e9fvMPjy1eCpA@mail.gmail.com>
Message-ID: <CADGJaX8=_HKVdDMuvhnsAoEL_q5JmtvLZPmO2tXfKp9=fBT-ow@mail.gmail.com>

+1 for having the style(s) in Git.

There is another axis, though, which is the used IDE. So far we couldn't
find a way to make Eclipse and IntelliJ do exactly the same thing wrt.
formatting. There is just not the exact same set of options available in
both IDEs, so outputs will always differ a bit.

But I don't think it's a big problem as long no one re-formats entire files
just for the sake of it. And if explicit formatting changes are needed for
whatever reason, they should go in dedicated commits independently from
actual code changes. Reviewing is otherwise a pain.



2015-05-19 17:07 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> My thinking was more about how to find which one supersedes which others.
> If I (as a contributor) have a few of these code style files available to
> me from the Hibernate team, how do I know which is the latest?
>
> As I pointed out, I actually had to update my code style slightly after
> migrating to 14 because it was inadvertently introducing leading spaces
> rather than tabs in certain cases.  Which illustrates that there are really
> 2 axis in play here, the targetted version of IDE and the version of the
> code style.
>
> Anyway, this is what got me thinking that using git might be nice for this,
> and GitHub could make it centrally available.
>
>
> On Tue, May 19, 2015 at 9:40 AM, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
>
> > Hi,
> >
> > Hibernate Validator used initially the same style as ORM. I am saying
> used
> > to since the file attached to this url -
> > http://hibernate.org/validator/contribute/ -
> > seems to differ a fair bit from the file you are referring to.
> > A lot of the difference might just be indentation and re-ordering issues.
> > After all
> > your version is hibernate-style-steve-2.xml. My guess is that the
> > Validator style is
> > derived from hibernate-style-steve-1.xml :-)
> >
> > Either way, differences should not be so huge.
> >
> > --Hardy
> >
> > On Mon, May 18, 2015 at 10:01:28PM -0500, Steve Ebersole wrote:
> > > The recent discussion on Checkstyle got me thinking about best ways to
> > > share/distribute code styles for IDE setup.  Storing them in the
> project
> > > itself is not very workable for IntelliJ at least.  I started thinking
> > > about a separate repository under the hibernate GitHub organization.
> > Does
> > > everyone use the code style I attached to
> > > https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ,
> > or
> > > do y'all use custom versions of that?
> > >
> > > Do y'all think it makes any sense to do this?
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.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 May 19 12:15:26 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 May 2015 11:15:26 -0500
Subject: [hibernate-dev] Sharing IDE code styles
In-Reply-To: <CADGJaX8=_HKVdDMuvhnsAoEL_q5JmtvLZPmO2tXfKp9=fBT-ow@mail.gmail.com>
References: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>
	<20150519144023.GB1059@Nineveh.fritz.box>
	<CAFdSV9tq1DcjD4D5CzSd=W29Fn6B+XBUNU9U5e9fvMPjy1eCpA@mail.gmail.com>
	<CADGJaX8=_HKVdDMuvhnsAoEL_q5JmtvLZPmO2tXfKp9=fBT-ow@mail.gmail.com>
Message-ID: <CAFdSV9vPcZ-c059sQxdNgUJ0hwnv7GJSLtXbbfvvgtcJO3hY2w@mail.gmail.com>

I just did some bulk reformatting to get things conforming with styles.
But moving forward I agree that we should not be reformatting entire
files.  Eclipse used to do that by default (cough cough).

And yes I understand that there is another axis for IDEs.  I just figured
that one was self-evident :P  There actually is (or used to be) a tool that
allowed the same codestyle to be used across the different IDEs.  I forget
the name of it, but it is not OSS nor free.
On May 19, 2015 10:21 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:

> +1 for having the style(s) in Git.
>
> There is another axis, though, which is the used IDE. So far we couldn't
> find a way to make Eclipse and IntelliJ do exactly the same thing wrt.
> formatting. There is just not the exact same set of options available in
> both IDEs, so outputs will always differ a bit.
>
> But I don't think it's a big problem as long no one re-formats entire
> files just for the sake of it. And if explicit formatting changes are
> needed for whatever reason, they should go in dedicated commits
> independently from actual code changes. Reviewing is otherwise a pain.
>
>
>
> 2015-05-19 17:07 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>
>> My thinking was more about how to find which one supersedes which others.
>> If I (as a contributor) have a few of these code style files available to
>> me from the Hibernate team, how do I know which is the latest?
>>
>> As I pointed out, I actually had to update my code style slightly after
>> migrating to 14 because it was inadvertently introducing leading spaces
>> rather than tabs in certain cases.  Which illustrates that there are
>> really
>> 2 axis in play here, the targetted version of IDE and the version of the
>> code style.
>>
>> Anyway, this is what got me thinking that using git might be nice for
>> this,
>> and GitHub could make it centrally available.
>>
>>
>> On Tue, May 19, 2015 at 9:40 AM, Hardy Ferentschik <hardy at hibernate.org>
>> wrote:
>>
>> > Hi,
>> >
>> > Hibernate Validator used initially the same style as ORM. I am saying
>> used
>> > to since the file attached to this url -
>> > http://hibernate.org/validator/contribute/ -
>> > seems to differ a fair bit from the file you are referring to.
>> > A lot of the difference might just be indentation and re-ordering
>> issues.
>> > After all
>> > your version is hibernate-style-steve-2.xml. My guess is that the
>> > Validator style is
>> > derived from hibernate-style-steve-1.xml :-)
>> >
>> > Either way, differences should not be so huge.
>> >
>> > --Hardy
>> >
>> > On Mon, May 18, 2015 at 10:01:28PM -0500, Steve Ebersole wrote:
>> > > The recent discussion on Checkstyle got me thinking about best ways to
>> > > share/distribute code styles for IDE setup.  Storing them in the
>> project
>> > > itself is not very workable for IntelliJ at least.  I started thinking
>> > > about a separate repository under the hibernate GitHub organization.
>> > Does
>> > > everyone use the code style I attached to
>> > > https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>> ,
>> > or
>> > > do y'all use custom versions of that?
>> > >
>> > > Do y'all think it makes any sense to do this?
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev at lists.jboss.org
>> > > https://lists.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 May 19 12:16:50 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 May 2015 11:16:50 -0500
Subject: [hibernate-dev] Hibernate O/RM Java 8 API.
In-Reply-To: <CAMs4JtgJT-sXGi9Fizc4BH499Q44-Ahh63rLiEtTd-DhJN4_Kw@mail.gmail.com>
References: <CAMs4Jtiso+kp6Z07gDdKmD270Q8fZ+vmb9_YXGJbFtS_Z1h62w@mail.gmail.com>
	<CAFdSV9tWUv=3RL+hCi2Er1pM1UojQc2d756Ybc0wXcFmWqbtbQ@mail.gmail.com>
	<CAMs4JtgJT-sXGi9Fizc4BH499Q44-Ahh63rLiEtTd-DhJN4_Kw@mail.gmail.com>
Message-ID: <CAFdSV9vz2OjJzf0SMPzsHeiX14hCmH8dCLRWTj2PbFfs_5hWpA@mail.gmail.com>

Let's keep this on list ok?  Thanks.

First, have you seen the new hibernate-java8 module that is part of 5.0?

Some replies in-line...

> But I am curious what would be your opinion on this extended API idea and
approach that I took and whether you would for instance consider taking it
under the hibernate umbrella as a kind of official extension in future.

Hard to say.  More than likely the next major release will drop support for
Java 6.  I personally see no benefit in supporting "just" 7, so I'd likely
go right to 8.


>
> At the moment I would like to focus on three things:
> - Introduce typed (generic) queries, because at this moment streams of
Object's are not quite useful.

Yes, we should certainly do this.  I just made some Session methods
generic, so this certainly fits.   But this is not Java 8 specific in any
way...

>
>
>
> - Enable registration of LocaleDate, LocalTime as query params.

You can do that now:
* org.hibernate.Query#setParameter(java.lang.String, java.lang.Object)
* org.hibernate.Query#setParameter(java.lang.String, java.lang.Object,
org.hibernate.type.Type)

I assume you mean adding method signatures accepting those specific types?


>
> - Custom type handlers for LocalDate, LocalTime
>
> - Custom type handlers for Optional<?>

No idea what you mean here.  What do you mean by "type handler"?

And as far as using LocalDate, etc as query parameters... you can do that
now.  Do you mean specific methods accepting them?


>
> If you could help me with one thing on the regarding the Optional
attributes mapping. As my understanding is correct the relation/entity
mapping are being handled by OneToOneType, ManyToOneType classes. To your
knowledge would it be possible to provide an overrided version of them, or
it would rather require to alter them directly in Hibernate core?

As I understand it (I have not looked overly deeply yet), we would
essentially need a Type representing Optional that wraps an "underlying
Type".  It is very similar to the idea of AttributeConverters.  We could
handle it at a lower lecvel here too like we do for AttributeConverter.

From jmnarloch at gmail.com  Tue May 19 13:51:42 2015
From: jmnarloch at gmail.com (Jakub Narloch)
Date: Tue, 19 May 2015 19:51:42 +0200
Subject: [hibernate-dev] Hibernate O/RM Java 8 API.
In-Reply-To: <CAFdSV9vz2OjJzf0SMPzsHeiX14hCmH8dCLRWTj2PbFfs_5hWpA@mail.gmail.com>
References: <CAMs4Jtiso+kp6Z07gDdKmD270Q8fZ+vmb9_YXGJbFtS_Z1h62w@mail.gmail.com>
	<CAFdSV9tWUv=3RL+hCi2Er1pM1UojQc2d756Ybc0wXcFmWqbtbQ@mail.gmail.com>
	<CAMs4JtgJT-sXGi9Fizc4BH499Q44-Ahh63rLiEtTd-DhJN4_Kw@mail.gmail.com>
	<CAFdSV9vz2OjJzf0SMPzsHeiX14hCmH8dCLRWTj2PbFfs_5hWpA@mail.gmail.com>
Message-ID: <CAMs4Jth9CDFLNutXS86TatXCCSig_xFF9NsPvsLb=QPfd+iMyg@mail.gmail.com>

2015-05-19 18:16 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> Let's keep this on list ok?  Thanks.
>
> First, have you seen the new hibernate-java8 module that is part of 5.0?
>
Ahh, I somehow miss that, going to take a look right away.

>
> >
> > At the moment I would like to focus on three things:
> > - Introduce typed (generic) queries, because at this moment streams of
> Object's are not quite useful.
>
> Yes, we should certainly do this.  I just made some Session methods
> generic, so this certainly fits.   But this is not Java 8 specific in any
> way...
>
> > - Enable registration of LocaleDate, LocalTime as query params.
>
> You can do that now:
> * org.hibernate.Query#setParameter(java.lang.String, java.lang.Object)
> * org.hibernate.Query#setParameter(java.lang.String, java.lang.Object,
> org.hibernate.type.Type)
>
> I assume you mean adding method signatures accepting those specific types?
>
Yes, I meant a convinient methods similar to those setDate and setTime,
something like setLocalDate, setLocalTime

>
> >
> > - Custom type handlers for LocalDate, LocalTime
> >
> > - Custom type handlers for Optional<?>
>
Sorry for ambiguity. I was refering to "custom user types" from the
reference, this is at least my understanding how Hibernate maps the Object
to SQL in general.
To sum up what I would like to be able to do "mapping" of an entity as
fallows:

class Employee {

  Optional<Employee> manager;

  LocalDate createDate;
  LocalDate updateDate;
}

So some extra org.hibernate.type.Type definitions will be needed similar to
those that you had defined in hibernate-java8.

>
>
> >
> > If you could help me with one thing on the regarding the Optional
> attributes mapping. As my understanding is correct the relation/entity
> mapping are being handled by OneToOneType, ManyToOneType classes. To your
> knowledge would it be possible to provide an overrided version of them, or
> it would rather require to alter them directly in Hibernate core?
>
> As I understand it (I have not looked overly deeply yet), we would
> essentially need a Type representing Optional that wraps an "underlying
> Type".  It is very similar to the idea of AttributeConverters.  We could
> handle it at a lower lecvel here too like we do for AttributeConverter.
>
Cool, I will explore this a bit more and see what I could do with that.

Thanks,
Jakub

From sanne at hibernate.org  Tue May 19 16:41:16 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 19 May 2015 21:41:16 +0100
Subject: [hibernate-dev] Sharing IDE code styles
In-Reply-To: <CAFdSV9vPcZ-c059sQxdNgUJ0hwnv7GJSLtXbbfvvgtcJO3hY2w@mail.gmail.com>
References: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>
	<20150519144023.GB1059@Nineveh.fritz.box>
	<CAFdSV9tq1DcjD4D5CzSd=W29Fn6B+XBUNU9U5e9fvMPjy1eCpA@mail.gmail.com>
	<CADGJaX8=_HKVdDMuvhnsAoEL_q5JmtvLZPmO2tXfKp9=fBT-ow@mail.gmail.com>
	<CAFdSV9vPcZ-c059sQxdNgUJ0hwnv7GJSLtXbbfvvgtcJO3hY2w@mail.gmail.com>
Message-ID: <CAFm4XO3SmNGgq4Gpx9u3OqYnvS=CB8=kGDKSRq=-A7eZx+bs=Q@mail.gmail.com>

I'd be happy to share my Eclipse templates in the same repository.
AFAIR we had similar problems, I always thought my templates were "the
reference" but then at some point we had multiple versions, I suspect
because of freshly exporting the same from a newer version of the IDE
but we'll never know.

As far as I know my Eclipse rules produce a close enough end result to
your styles, with at most slight different conventions in ordering of
import statements.

On 19 May 2015 at 17:15, Steve Ebersole <steve at hibernate.org> wrote:
> I just did some bulk reformatting to get things conforming with styles.
> But moving forward I agree that we should not be reformatting entire
> files.  Eclipse used to do that by default (cough cough).
>
> And yes I understand that there is another axis for IDEs.  I just figured
> that one was self-evident :P  There actually is (or used to be) a tool that
> allowed the same codestyle to be used across the different IDEs.  I forget
> the name of it, but it is not OSS nor free.
> On May 19, 2015 10:21 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
>
>> +1 for having the style(s) in Git.
>>
>> There is another axis, though, which is the used IDE. So far we couldn't
>> find a way to make Eclipse and IntelliJ do exactly the same thing wrt.
>> formatting. There is just not the exact same set of options available in
>> both IDEs, so outputs will always differ a bit.
>>
>> But I don't think it's a big problem as long no one re-formats entire
>> files just for the sake of it. And if explicit formatting changes are
>> needed for whatever reason, they should go in dedicated commits
>> independently from actual code changes. Reviewing is otherwise a pain.
>>
>>
>>
>> 2015-05-19 17:07 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>
>>> My thinking was more about how to find which one supersedes which others.
>>> If I (as a contributor) have a few of these code style files available to
>>> me from the Hibernate team, how do I know which is the latest?
>>>
>>> As I pointed out, I actually had to update my code style slightly after
>>> migrating to 14 because it was inadvertently introducing leading spaces
>>> rather than tabs in certain cases.  Which illustrates that there are
>>> really
>>> 2 axis in play here, the targetted version of IDE and the version of the
>>> code style.
>>>
>>> Anyway, this is what got me thinking that using git might be nice for
>>> this,
>>> and GitHub could make it centrally available.
>>>
>>>
>>> On Tue, May 19, 2015 at 9:40 AM, Hardy Ferentschik <hardy at hibernate.org>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > Hibernate Validator used initially the same style as ORM. I am saying
>>> used
>>> > to since the file attached to this url -
>>> > http://hibernate.org/validator/contribute/ -
>>> > seems to differ a fair bit from the file you are referring to.
>>> > A lot of the difference might just be indentation and re-ordering
>>> issues.
>>> > After all
>>> > your version is hibernate-style-steve-2.xml. My guess is that the
>>> > Validator style is
>>> > derived from hibernate-style-steve-1.xml :-)
>>> >
>>> > Either way, differences should not be so huge.
>>> >
>>> > --Hardy
>>> >
>>> > On Mon, May 18, 2015 at 10:01:28PM -0500, Steve Ebersole wrote:
>>> > > The recent discussion on Checkstyle got me thinking about best ways to
>>> > > share/distribute code styles for IDE setup.  Storing them in the
>>> project
>>> > > itself is not very workable for IntelliJ at least.  I started thinking
>>> > > about a separate repository under the hibernate GitHub organization.
>>> > Does
>>> > > everyone use the code style I attached to
>>> > > https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
>>> ,
>>> > or
>>> > > do y'all use custom versions of that?
>>> > >
>>> > > Do y'all think it makes any sense to do this?
>>> > > _______________________________________________
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev at lists.jboss.org
>>> > > https://lists.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 May 19 16:52:17 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 May 2015 15:52:17 -0500
Subject: [hibernate-dev] Hibernate O/RM Java 8 API.
In-Reply-To: <CAMs4Jth9CDFLNutXS86TatXCCSig_xFF9NsPvsLb=QPfd+iMyg@mail.gmail.com>
References: <CAMs4Jtiso+kp6Z07gDdKmD270Q8fZ+vmb9_YXGJbFtS_Z1h62w@mail.gmail.com>
	<CAFdSV9tWUv=3RL+hCi2Er1pM1UojQc2d756Ybc0wXcFmWqbtbQ@mail.gmail.com>
	<CAMs4JtgJT-sXGi9Fizc4BH499Q44-Ahh63rLiEtTd-DhJN4_Kw@mail.gmail.com>
	<CAFdSV9vz2OjJzf0SMPzsHeiX14hCmH8dCLRWTj2PbFfs_5hWpA@mail.gmail.com>
	<CAMs4Jth9CDFLNutXS86TatXCCSig_xFF9NsPvsLb=QPfd+iMyg@mail.gmail.com>
Message-ID: <CAFdSV9uKFFAUmU=TRWHUTK1gZLVRRn7y5NU8R6QDVXLDS=aUfg@mail.gmail.com>

On Tue, May 19, 2015 at 12:51 PM, Jakub Narloch <jmnarloch at gmail.com> wrote:

>
>
> 2015-05-19 18:16 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
>>
>> > - Enable registration of LocaleDate, LocalTime as query params.
>>
>> You can do that now:
>> * org.hibernate.Query#setParameter(java.lang.String, java.lang.Object)
>> * org.hibernate.Query#setParameter(java.lang.String, java.lang.Object,
>> org.hibernate.type.Type)
>>
>> I assume you mean adding method signatures accepting those specific types?
>>
> Yes, I meant a convinient methods similar to those setDate and setTime,
> something like setLocalDate, setLocalTime
>

But that would in fact introduce a Java 8 dependency on hibernate-core if
we did this directly.  We could maybe use some form of "unwrap" notion
where hibernate-java8 could auto-register some delegate for "additional
param setting".  We could use the same concept in relation to
hibernate-spatial as well for setting geolatte specific parameters.


>
>> >
>> > - Custom type handlers for LocalDate, LocalTime
>> >
>> > - Custom type handlers for Optional<?>
>>
> Sorry for ambiguity. I was refering to "custom user types" from the
> reference, this is at least my understanding how Hibernate maps the Object
> to SQL in general.
> To sum up what I would like to be able to do "mapping" of an entity as
> fallows:
>
> class Employee {
>
>   Optional<Employee> manager;
>
>   LocalDate createDate;
>   LocalDate updateDate;
> }
>

As far as the Java 8 date/time stuff... see the hibernate-java8 module...
that is its whole goal...  Optional support has a little more to it, some
of which is alluded to in this discussion



>
> So some extra org.hibernate.type.Type definitions will be needed similar
> to those that you had defined in hibernate-java8.
>

Um, why would we need extra*s*?  We need one... for Optional.

From sanne at hibernate.org  Tue May 19 18:19:42 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 19 May 2015 23:19:42 +0100
Subject: [hibernate-dev] Upgrades for ci.hibernate.org
Message-ID: <CAFm4XO3dZO_BX4DtJg=RaKRiTWHb8CA7Va7b=raLOSpyeVPbeQ@mail.gmail.com>

Hi all,
the build slaves for ci.hibernate.org got refreshed.

Several jobs failed during the last week as the micro quotas we had
were getting full.
The 4 nodes have now 4 times the RAM, 4 times the CPU and 8 times the
disk space.
(that's 15GB of RAM, 8 CPUs, 80GB of dedicated space per node)

N.B. both relational and NoSQL databases are running on a much smaller
18GB partition, shared with the OS system files. Tests are expected to
cleanup after use!

I've tested some of the main builds and they seem to run fine, but
there are various exotic jobs which don't get run too often.. please
let us know if you see something unusual.

Some things of note:
 - I reconfigured the Gradle and Maven global environment (defaults)
to more generous heap sizes
    -- you might want to do the same, if you did override those in your jobs
 - the various JDKs got updated
 - the HQL Parser project apparently was just verifying it could
successfully checkout the project.. fixed that to actually run the
build, and the tests too!
 - it took Davide and me a couple of hours to figure how to script the
disk size changes, but the actual re-build from scratch of all slaves
only took minutes! eureka
 - the HQL Parser is now experimenting with the Gradle option to run
parallel builds (try to get some benefits form all these cores)
   -- I'm temporarily playing with the setting on Hibernate ORM too,
I'll probably return it to more conservative options soon ..

Remaining TODOs:
 - merge the open PRs of ci.hibernate.org
 - think of how to automate disk space reclaim? Or keep an eye on its growth
 - Several Jenkins plugins need to be upgraded. I'd prefer we wait a
bit on that and verify first that most jobs build fine, to ease
diagnostics of all the things which break when those get updated..

Thanks,
Sanne

From steve at hibernate.org  Tue May 19 21:47:40 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 May 2015 20:47:40 -0500
Subject: [hibernate-dev] Hibernate ORM - next steps
Message-ID: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>

Now that 5.0 is settling down I wanted to start planning where we go from
here in terms of feature development and schedule/releases.

Here is my high-level list of features/work:
* rework SQL generation & HQL parser
* change JDBC extraction to work by position, rather than alias (reworking
SQL generation is a prerequisite)
* rework annotation binding (Jandex, etc)
* extended orm.xml, deprecate hbm.xml
* discriminator-based multi-tenancy
* port Hibernate Criteria constructs to JPA criteria, begin deprecation of
Hibernate Criteria
* extend JPA criteria API with fluent support
* ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
* merging hibernate-entitymanager into hibernate-core
* continue to fill out bytecode enhancement capabilities

Some of these are more involved than others.  The task for re-writing SQL
generation is a HUGE undertaking, but also has many huge benefits.
Re-writing annotation binding is another huge undertaking, but again with
many benefits.

Any others we should add to the list here?

And then we can work on scheduling them.

From steve at hibernate.org  Tue May 19 22:15:51 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 19 May 2015 21:15:51 -0500
Subject: [hibernate-dev] Sharing IDE code styles
In-Reply-To: <CAFm4XO3SmNGgq4Gpx9u3OqYnvS=CB8=kGDKSRq=-A7eZx+bs=Q@mail.gmail.com>
References: <CAFdSV9u1q4UgqUD5ioXa32RuMP8=J1PvWgpxu+WyYdN5rCriYA@mail.gmail.com>
	<20150519144023.GB1059@Nineveh.fritz.box>
	<CAFdSV9tq1DcjD4D5CzSd=W29Fn6B+XBUNU9U5e9fvMPjy1eCpA@mail.gmail.com>
	<CADGJaX8=_HKVdDMuvhnsAoEL_q5JmtvLZPmO2tXfKp9=fBT-ow@mail.gmail.com>
	<CAFdSV9vPcZ-c059sQxdNgUJ0hwnv7GJSLtXbbfvvgtcJO3hY2w@mail.gmail.com>
	<CAFm4XO3SmNGgq4Gpx9u3OqYnvS=CB8=kGDKSRq=-A7eZx+bs=Q@mail.gmail.com>
Message-ID: <CAFdSV9ti=n+yu=odBfmzk0pFnR=s_gs7-otiT54v=Pru9FM51w@mail.gmail.com>

https://github.com/hibernate/hibernate-ide-codestyles

On Tue, May 19, 2015 at 3:41 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I'd be happy to share my Eclipse templates in the same repository.
> AFAIR we had similar problems, I always thought my templates were "the
> reference" but then at some point we had multiple versions, I suspect
> because of freshly exporting the same from a newer version of the IDE
> but we'll never know.
>
> As far as I know my Eclipse rules produce a close enough end result to
> your styles, with at most slight different conventions in ordering of
> import statements.
>
> On 19 May 2015 at 17:15, Steve Ebersole <steve at hibernate.org> wrote:
> > I just did some bulk reformatting to get things conforming with styles.
> > But moving forward I agree that we should not be reformatting entire
> > files.  Eclipse used to do that by default (cough cough).
> >
> > And yes I understand that there is another axis for IDEs.  I just figured
> > that one was self-evident :P  There actually is (or used to be) a tool
> that
> > allowed the same codestyle to be used across the different IDEs.  I
> forget
> > the name of it, but it is not OSS nor free.
> > On May 19, 2015 10:21 AM, "Gunnar Morling" <gunnar at hibernate.org> wrote:
> >
> >> +1 for having the style(s) in Git.
> >>
> >> There is another axis, though, which is the used IDE. So far we couldn't
> >> find a way to make Eclipse and IntelliJ do exactly the same thing wrt.
> >> formatting. There is just not the exact same set of options available in
> >> both IDEs, so outputs will always differ a bit.
> >>
> >> But I don't think it's a big problem as long no one re-formats entire
> >> files just for the sake of it. And if explicit formatting changes are
> >> needed for whatever reason, they should go in dedicated commits
> >> independently from actual code changes. Reviewing is otherwise a pain.
> >>
> >>
> >>
> >> 2015-05-19 17:07 GMT+02:00 Steve Ebersole <steve at hibernate.org>:
> >>
> >>> My thinking was more about how to find which one supersedes which
> others.
> >>> If I (as a contributor) have a few of these code style files available
> to
> >>> me from the Hibernate team, how do I know which is the latest?
> >>>
> >>> As I pointed out, I actually had to update my code style slightly after
> >>> migrating to 14 because it was inadvertently introducing leading spaces
> >>> rather than tabs in certain cases.  Which illustrates that there are
> >>> really
> >>> 2 axis in play here, the targetted version of IDE and the version of
> the
> >>> code style.
> >>>
> >>> Anyway, this is what got me thinking that using git might be nice for
> >>> this,
> >>> and GitHub could make it centrally available.
> >>>
> >>>
> >>> On Tue, May 19, 2015 at 9:40 AM, Hardy Ferentschik <
> hardy at hibernate.org>
> >>> wrote:
> >>>
> >>> > Hi,
> >>> >
> >>> > Hibernate Validator used initially the same style as ORM. I am saying
> >>> used
> >>> > to since the file attached to this url -
> >>> > http://hibernate.org/validator/contribute/ -
> >>> > seems to differ a fair bit from the file you are referring to.
> >>> > A lot of the difference might just be indentation and re-ordering
> >>> issues.
> >>> > After all
> >>> > your version is hibernate-style-steve-2.xml. My guess is that the
> >>> > Validator style is
> >>> > derived from hibernate-style-steve-1.xml :-)
> >>> >
> >>> > Either way, differences should not be so huge.
> >>> >
> >>> > --Hardy
> >>> >
> >>> > On Mon, May 18, 2015 at 10:01:28PM -0500, Steve Ebersole wrote:
> >>> > > The recent discussion on Checkstyle got me thinking about best
> ways to
> >>> > > share/distribute code styles for IDE setup.  Storing them in the
> >>> project
> >>> > > itself is not very workable for IntelliJ at least.  I started
> thinking
> >>> > > about a separate repository under the hibernate GitHub
> organization.
> >>> > Does
> >>> > > everyone use the code style I attached to
> >>> > >
> https://developer.jboss.org/wiki/ContributingToHibernateUsingIntelliJ
> >>> ,
> >>> > or
> >>> > > do y'all use custom versions of that?
> >>> > >
> >>> > > Do y'all think it makes any sense to do this?
> >>> > > _______________________________________________
> >>> > > hibernate-dev mailing list
> >>> > > hibernate-dev at lists.jboss.org
> >>> > > https://lists.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 May 20 02:00:48 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 20 May 2015 01:00:48 -0500
Subject: [hibernate-dev] ORM - FindBugs/PMD
In-Reply-To: <CAFdSV9tTXXAZnGSnsr1OTsoXd79M4v3=uZW_G2RnaQo94jrxqw@mail.gmail.com>
References: <CAFdSV9tTXXAZnGSnsr1OTsoXd79M4v3=uZW_G2RnaQo94jrxqw@mail.gmail.com>
Message-ID: <CAFdSV9vYVvHadhvVUd64uEKxySycVaWg94AaBx_vbgBokrL=Eg@mail.gmail.com>

Checkstyle in ORM is now good to go and enforced in the CI jobs.

So I started thinking about FindBugs.  We do have FindBugs set up.  However
it is utterly out of control at the moment.  Maybe it's just me, but I find
FindBugs impossible to configure "well".  Granted I have little experience
with it, but Web searches turn up almost nothing on how to configure
FindBugs.  A few things in particular bug me about FindBugs:
1) Because it works on classes, not sources, it's nearly impossible to
succinctly say "ignore generated sources".  Would love to be proved wrong
there :)
2) I am unsure how to tell FindBugs which rules to run and which to not.  I
*think* this can be done through its filter files, but I have yet to find a
decent doc on doing that.
3) I have no idea how to change the confidence and severity of the things
FindBugs reports.  I have mentioned the DM_CONVERT_CASE scenario to some of
you before.  For us that is always a bug but FindBugs treats it with low
confidence (maybe a bug, maybe not).

I know PMD covers a lot of the same cases.  Anyone familiar with it?  lf it
is more easily configurable, maybe it fits our needs better...

From davide at hibernate.org  Wed May 20 06:58:58 2015
From: davide at hibernate.org (Davide D'Alto)
Date: Wed, 20 May 2015 11:58:58 +0100
Subject: [hibernate-dev] [Search] Projections of collection of elements with
	embeddable
Message-ID: <CANoTJYOtMu13bX1HTm91oY=aoy3gE_+M-mHeB2YL2-dTpLbYVg@mail.gmail.com>

Hi,

while working on OGM-781 I noticed that there is a problem with Hibernate
Search when trying to get the projection of a property that represents a
collection of elements..

EntityInfo#getProjections()[0] will always return the first value of the
association.

For example, if I index the following entity:

    @Indexed
    public static class ExampleEntity {

        @Field(store = Store.YES)
        Integer someInteger;

        ...

        @Field(store = Store.YES)
        @IndexedEmbedded
        List<Integer> someCollection;
    }

and than add a projection on  "someCollection"

EntityInfo.getProjection()[0] will only return the first result of the
collection instead of returning a List<Integer>.

This seems a bug to me.
I've already created a local branch that should fix the behaviour in this
case.

It also makes me wonder, what should we do with a list of embeddables?

For example:

@Field(store = Store.YES)
@IndexedEmbedded
List<ExampleEntity> nestedExamples

In this case,  would it make sense to project "someCollection.someInteger"?
And what would be the expected result calling EntityInfo.getProjection()[0]?

Cheers,
Davide

From steve at hibernate.org  Wed May 20 08:28:31 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 20 May 2015 07:28:31 -0500
Subject: [hibernate-dev] Support for DELETE statements ActionQueue
	sorting
In-Reply-To: <1593310606.1663202.1427321124917.JavaMail.yahoo@mail.yahoo.com>
References: <1593310606.1663202.1427321124917.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAFdSV9vZa_OTxxpwW=a0a2_eivOEvP3d+tZ4QvscHZZQH1NLOA@mail.gmail.com>

The difference is that insert ordering is merely a question of performance
in order to better leverage JDBC batching.  Here you are suggesting that
there is a bug in the order of deletes.  Or are you just wanting to order
the deletes to better leverage JDBC batching as well?  It's not clear.

On Wed, Mar 25, 2015 at 5:05 PM, Mihalcea Vlad <mih_vlad at yahoo.com> wrote:

> Hi,
>
> While INSERT sorting is handled by ActionQueue.InsertActionSorter, DELETE
> statements are not sorted at all.
>
> A DeleteActionSorter woudl have to rearrange DELETES in the opposite order
> as the INSERT sorting, the Children having to be deleted first.
>
> The current work-around is to dissociate all Children and manually flush
> the Session, so that the orphan-removal kicks in before the Parent entities
> delete occurs.
>
> Any plans for supporting such a feature?
>
> Vlad Mihalcea
>

From gunnar at hibernate.org  Wed May 20 12:34:12 2015
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 20 May 2015 18:34:12 +0200
Subject: [hibernate-dev] Upgrades for ci.hibernate.org
In-Reply-To: <CAFm4XO3dZO_BX4DtJg=RaKRiTWHb8CA7Va7b=raLOSpyeVPbeQ@mail.gmail.com>
References: <CAFm4XO3dZO_BX4DtJg=RaKRiTWHb8CA7Va7b=raLOSpyeVPbeQ@mail.gmail.com>
Message-ID: <CADGJaX_CxbrFrHYkvbOgO2yZ9KW+u_vCQex_-BGuHRbERX6gMg@mail.gmail.com>

Hi Sanne,

Apparently you changed some of the OGM jobs to not use their own private
Maven repo any longer. What was the reason for that? I had chosen to work
with private repos intentionally, so to avoid interferences between
different jobs.

It may not be strictly needed as long as we don't run jobs in parallel on
one node, but I still prefer the original style because it removes one
level of complexity when it e.g. comes to the analysis of build failures.

--Gunnar




2015-05-20 0:19 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi all,
> the build slaves for ci.hibernate.org got refreshed.
>
> Several jobs failed during the last week as the micro quotas we had
> were getting full.
> The 4 nodes have now 4 times the RAM, 4 times the CPU and 8 times the
> disk space.
> (that's 15GB of RAM, 8 CPUs, 80GB of dedicated space per node)
>
> N.B. both relational and NoSQL databases are running on a much smaller
> 18GB partition, shared with the OS system files. Tests are expected to
> cleanup after use!
>
> I've tested some of the main builds and they seem to run fine, but
> there are various exotic jobs which don't get run too often.. please
> let us know if you see something unusual.
>
> Some things of note:
>  - I reconfigured the Gradle and Maven global environment (defaults)
> to more generous heap sizes
>     -- you might want to do the same, if you did override those in your
> jobs
>  - the various JDKs got updated
>  - the HQL Parser project apparently was just verifying it could
> successfully checkout the project.. fixed that to actually run the
> build, and the tests too!
>  - it took Davide and me a couple of hours to figure how to script the
> disk size changes, but the actual re-build from scratch of all slaves
> only took minutes! eureka
>  - the HQL Parser is now experimenting with the Gradle option to run
> parallel builds (try to get some benefits form all these cores)
>    -- I'm temporarily playing with the setting on Hibernate ORM too,
> I'll probably return it to more conservative options soon ..
>
> Remaining TODOs:
>  - merge the open PRs of ci.hibernate.org
>  - think of how to automate disk space reclaim? Or keep an eye on its
> growth
>  - Several Jenkins plugins need to be upgraded. I'd prefer we wait a
> bit on that and verify first that most jobs build fine, to ease
> diagnostics of all the things which break when those get updated..
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu May 21 13:27:43 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 21 May 2015 12:27:43 -0500
Subject: [hibernate-dev] 4.3
Message-ID: <CAFdSV9vv+8KneJdG3QDtqoXWx4zxKe3z8CcDg5xC7KwFK1NbQw@mail.gmail.com>

I am having trouble building 4.3 even from a clean checkout:

:hibernate-core:runSourceGenerators
:hibernate-core:runAnnotationProcessors FAILED

FAILURE: Build failed with an exception.

* Where:
Script
'/home/sebersole/projects/hibernate/hibernate-4.3/hibernate-orm/source-generation.gradle'
line: 305

From dreborier at gmail.com  Thu May 21 13:34:01 2015
From: dreborier at gmail.com (andrea boriero)
Date: Thu, 21 May 2015 18:34:01 +0100
Subject: [hibernate-dev] 4.3
In-Reply-To: <CAFdSV9vv+8KneJdG3QDtqoXWx4zxKe3z8CcDg5xC7KwFK1NbQw@mail.gmail.com>
References: <CAFdSV9vv+8KneJdG3QDtqoXWx4zxKe3z8CcDg5xC7KwFK1NbQw@mail.gmail.com>
Message-ID: <CAL00eSTyt2ynop3vWKsSSG_E66p2+UoGFkm1pYkOt19GUZ1Grg@mail.gmail.com>

are you using java 8?



On 21 May 2015 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:

> I am having trouble building 4.3 even from a clean checkout:
>
> :hibernate-core:runSourceGenerators
> :hibernate-core:runAnnotationProcessors FAILED
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Script
>
> '/home/sebersole/projects/hibernate/hibernate-4.3/hibernate-orm/source-generation.gradle'
> line: 305
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Thu May 21 13:41:17 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 21 May 2015 12:41:17 -0500
Subject: [hibernate-dev] 4.3
In-Reply-To: <CAL00eSTyt2ynop3vWKsSSG_E66p2+UoGFkm1pYkOt19GUZ1Grg@mail.gmail.com>
References: <CAFdSV9vv+8KneJdG3QDtqoXWx4zxKe3z8CcDg5xC7KwFK1NbQw@mail.gmail.com>
	<CAL00eSTyt2ynop3vWKsSSG_E66p2+UoGFkm1pYkOt19GUZ1Grg@mail.gmail.com>
Message-ID: <CAFdSV9vDbiv1i0n_RACdaj4f32R=AtFM40cxHEGsUB-XkW1EhA@mail.gmail.com>

Ah, yes that was it.  Thanks!

On Thu, May 21, 2015 at 12:34 PM, andrea boriero <dreborier at gmail.com>
wrote:

> are you using java 8?
>
>
>
> On 21 May 2015 at 18:27, Steve Ebersole <steve at hibernate.org> wrote:
>
>> I am having trouble building 4.3 even from a clean checkout:
>>
>> :hibernate-core:runSourceGenerators
>> :hibernate-core:runAnnotationProcessors FAILED
>>
>> FAILURE: Build failed with an exception.
>>
>> * Where:
>> Script
>>
>> '/home/sebersole/projects/hibernate/hibernate-4.3/hibernate-orm/source-generation.gradle'
>> line: 305
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Sat May 23 13:49:50 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 23 May 2015 12:49:50 -0500
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
Message-ID: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>

Brett,

As part of HHH-7527 (Enterprise OSGi support) you had changed
the org.hibernate.jpa.boot.spi.Bootstrap contract to basically overload
each method to additional accept a "providedClassLoader".

Every one of those methods however, also accepts
a org.hibernate.jpa.boot.spi.PersistenceUnitDescriptor which exposes 2
ClassLoader already.

Additionally, this ClassLoader is ultimately just used to build the
ClassLoaderService which hibernate-osgi overrides anyway.

Just curious if I missed something.  Unless I did, it seems to me that we
really do not need these overloads on Bootstrap to support Enterprise
OSGi.  This dove-tails with a discussion from the Karaf user list
ultimately discussing OsgiClassLoaderService and "holding bundles" that are
being re-installed or upgraded.  Ultimately I am thinking through ways to
support being able to release OSGI bundle references from the
OsgiClassLoaderService...

From brmeyer at redhat.com  Tue May 26 11:44:13 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Tue, 26 May 2015 11:44:13 -0400 (EDT)
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
Message-ID: <179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>

IIRC:

OsgiPersistenceProvider and OsgiSessionFactoryService both need *some* way to build the OsgiClassLoader and pass it into Hibernate bootstrapping.  For the SF, that's easy: just hand OSGiClassLoaderServiceImpl to BootstrapServiceRegistryBuilder.  For EMF, it looks like I mistakenly overrode those Bootstrap methods -- I missed that PersistenceUnitDescriptor included the CL.  So you're probably right -- presumably you could strip 'em out and somehow use the descriptor, but you might still need the overridden method in HibernatePersistenceProvider so that OsgiPersistenceProvider can give you the OsgiClassLoader to use.

> Additionally, this ClassLoader is ultimately just used to build the
> ClassLoaderService which hibernate-osgi overrides anyway.

Right, assuming you're talking about 'ClassLoaderHelper.overridenClassLoader'.  But the intention there was to remove that whole class ASAP -- that was just a temporary hack for ORM 4, since CL handling was still really static.  But admittedly, I'm a bit out of touch with ORM 5, so I'm not sure if that's feasible yet.

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Saturday, May 23, 2015 1:49:50 PM
> Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
> 
> Brett,
> 
> As part of HHH-7527 (Enterprise OSGi support) you had changed
> the org.hibernate.jpa.boot.spi.Bootstrap contract to basically overload
> each method to additional accept a "providedClassLoader".
> 
> Every one of those methods however, also accepts
> a org.hibernate.jpa.boot.spi.PersistenceUnitDescriptor which exposes 2
> ClassLoader already.
> 
> Additionally, this ClassLoader is ultimately just used to build the
> ClassLoaderService which hibernate-osgi overrides anyway.
> 
> Just curious if I missed something.  Unless I did, it seems to me that we
> really do not need these overloads on Bootstrap to support Enterprise
> OSGi.  This dove-tails with a discussion from the Karaf user list
> ultimately discussing OsgiClassLoaderService and "holding bundles" that are
> being re-installed or upgraded.  Ultimately I am thinking through ways to
> support being able to release OSGI bundle references from the
> OsgiClassLoaderService...
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From hardy at hibernate.org  Tue May 26 14:58:12 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 26 May 2015 20:58:12 +0200
Subject: [hibernate-dev] First 5.2 Candidate Release - Hibernate Validator
	5.2.0.CR1
Message-ID: <20150526185812.GA12926@Nineveh.lan>

Hi there,

Moving Hibernate Validator along towards a 5.2 Final I am happy to announce the
release of Hibernate Validator 5.2.0.CR1. You find more information about the 
release on in.relation.to - http://in.relation.to/42796.lace

Hopefully this will be the first and last Candidate Release and the next announcement
will be for the Final release.

Enjoy!

From steve at hibernate.org  Tue May 26 15:11:25 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 May 2015 14:11:25 -0500
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>

I would fully expect hibernate-osgi to not directly use Bootstrap to build
an EntityManagerFactoryBuilder.  Bootstrap is geared toward users wanting
to leverage 2-phase JPA bootstrapping, not our components.  I would have
expected Enterprise OSGi support to instead directly build (and possibly
override) EntityManagerFactoryBuilderImpl.  I'll add that as a task for
post-5.0.  Because I think that is a first step in being able to better
manage bundles coming and going.  Please correct me if I am wrong.  Also
I'd like to start making sure that we fully support (certain) OSGi services
being replaced.  Especially thinking of TransactionManagers and DataSources.


On Tue, May 26, 2015 at 10:44 AM, Brett Meyer <brmeyer at redhat.com> wrote:

> IIRC:
>
> OsgiPersistenceProvider and OsgiSessionFactoryService both need *some* way
> to build the OsgiClassLoader and pass it into Hibernate bootstrapping.  For
> the SF, that's easy: just hand OSGiClassLoaderServiceImpl to
> BootstrapServiceRegistryBuilder.  For EMF, it looks like I mistakenly
> overrode those Bootstrap methods -- I missed that PersistenceUnitDescriptor
> included the CL.  So you're probably right -- presumably you could strip
> 'em out and somehow use the descriptor, but you might still need the
> overridden method in HibernatePersistenceProvider so that
> OsgiPersistenceProvider can give you the OsgiClassLoader to use.
>
> > Additionally, this ClassLoader is ultimately just used to build the
> > ClassLoaderService which hibernate-osgi overrides anyway.
>
> Right, assuming you're talking about
> 'ClassLoaderHelper.overridenClassLoader'.  But the intention there was to
> remove that whole class ASAP -- that was just a temporary hack for ORM 4,
> since CL handling was still really static.  But admittedly, I'm a bit out
> of touch with ORM 5, so I'm not sure if that's feasible yet.
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > Sent: Saturday, May 23, 2015 1:49:50 PM
> > Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
> >
> > Brett,
> >
> > As part of HHH-7527 (Enterprise OSGi support) you had changed
> > the org.hibernate.jpa.boot.spi.Bootstrap contract to basically overload
> > each method to additional accept a "providedClassLoader".
> >
> > Every one of those methods however, also accepts
> > a org.hibernate.jpa.boot.spi.PersistenceUnitDescriptor which exposes 2
> > ClassLoader already.
> >
> > Additionally, this ClassLoader is ultimately just used to build the
> > ClassLoaderService which hibernate-osgi overrides anyway.
> >
> > Just curious if I missed something.  Unless I did, it seems to me that we
> > really do not need these overloads on Bootstrap to support Enterprise
> > OSGi.  This dove-tails with a discussion from the Karaf user list
> > ultimately discussing OsgiClassLoaderService and "holding bundles" that
> are
> > being re-installed or upgraded.  Ultimately I am thinking through ways to
> > support being able to release OSGI bundle references from the
> > OsgiClassLoaderService...
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From brmeyer at redhat.com  Tue May 26 16:26:17 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Tue, 26 May 2015 16:26:17 -0400 (EDT)
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
	<CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
Message-ID: <1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>

> I would fully expect hibernate-osgi to not directly use Bootstrap to build
> an EntityManagerFactoryBuilder.  Bootstrap is geared toward users wanting
> to leverage 2-phase JPA bootstrapping, not our components.  I would have
> expected Enterprise OSGi support to instead directly build (and possibly
> override) EntityManagerFactoryBuilderImpl.  I'll add that as a task for
> post-5.0.

+1, makes sense.  I should have done that to begin with...

> Because I think that is a first step in being able to better
> manage bundles coming and going.  Please correct me if I am wrong.

At first glance, supporting bundles being activated/deactivated at runtime may just be limited to OsgiClassLoader and an impl of OSGi's "BundleListener".  HibernateBundleActivator would simply register that listener during startup (BundleContext#addBundleListener), which would receive the events.  As bundles are added/removed from the runtime, they'd just be added/removed from OsgiClassLoader#bundles.

> Also I'd like to start making sure that we fully support (certain) OSGi services
> being replaced.  Especially thinking of TransactionManagers and DataSources.

+1

> 
> 
> On Tue, May 26, 2015 at 10:44 AM, Brett Meyer <brmeyer at redhat.com> wrote:
> 
> > IIRC:
> >
> > OsgiPersistenceProvider and OsgiSessionFactoryService both need *some* way
> > to build the OsgiClassLoader and pass it into Hibernate bootstrapping.  For
> > the SF, that's easy: just hand OSGiClassLoaderServiceImpl to
> > BootstrapServiceRegistryBuilder.  For EMF, it looks like I mistakenly
> > overrode those Bootstrap methods -- I missed that PersistenceUnitDescriptor
> > included the CL.  So you're probably right -- presumably you could strip
> > 'em out and somehow use the descriptor, but you might still need the
> > overridden method in HibernatePersistenceProvider so that
> > OsgiPersistenceProvider can give you the OsgiClassLoader to use.
> >
> > > Additionally, this ClassLoader is ultimately just used to build the
> > > ClassLoaderService which hibernate-osgi overrides anyway.
> >
> > Right, assuming you're talking about
> > 'ClassLoaderHelper.overridenClassLoader'.  But the intention there was to
> > remove that whole class ASAP -- that was just a temporary hack for ORM 4,
> > since CL handling was still really static.  But admittedly, I'm a bit out
> > of touch with ORM 5, so I'm not sure if that's feasible yet.
> >
> > ----- Original Message -----
> > > From: "Steve Ebersole" <steve at hibernate.org>
> > > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > > Sent: Saturday, May 23, 2015 1:49:50 PM
> > > Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
> > >
> > > Brett,
> > >
> > > As part of HHH-7527 (Enterprise OSGi support) you had changed
> > > the org.hibernate.jpa.boot.spi.Bootstrap contract to basically overload
> > > each method to additional accept a "providedClassLoader".
> > >
> > > Every one of those methods however, also accepts
> > > a org.hibernate.jpa.boot.spi.PersistenceUnitDescriptor which exposes 2
> > > ClassLoader already.
> > >
> > > Additionally, this ClassLoader is ultimately just used to build the
> > > ClassLoaderService which hibernate-osgi overrides anyway.
> > >
> > > Just curious if I missed something.  Unless I did, it seems to me that we
> > > really do not need these overloads on Bootstrap to support Enterprise
> > > OSGi.  This dove-tails with a discussion from the Karaf user list
> > > ultimately discussing OsgiClassLoaderService and "holding bundles" that
> > are
> > > being re-installed or upgraded.  Ultimately I am thinking through ways to
> > > support being able to release OSGI bundle references from the
> > > OsgiClassLoaderService...
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> >
> 

From steve at hibernate.org  Tue May 26 16:57:00 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 May 2015 15:57:00 -0500
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
	<CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
	<1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>

Awesome, thanks!  So I'll investigate BundleListener...

Is that the best way to know when TransactionManagers and DataSources come
and go too?  Or is there a more specific concept for listening to an "OSGi
service"?

Also, do the containers generally handle "in-flight" requests in
regards to TransactionManagers
and DataSources on activated/deactivated?  I guess this is more a
curiosity, since I do not see what we could do if the container does not
manage it.

On Tue, May 26, 2015 at 3:26 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> > I would fully expect hibernate-osgi to not directly use Bootstrap to
> build
> > an EntityManagerFactoryBuilder.  Bootstrap is geared toward users wanting
> > to leverage 2-phase JPA bootstrapping, not our components.  I would have
> > expected Enterprise OSGi support to instead directly build (and possibly
> > override) EntityManagerFactoryBuilderImpl.  I'll add that as a task for
> > post-5.0.
>
> +1, makes sense.  I should have done that to begin with...
>
> > Because I think that is a first step in being able to better
> > manage bundles coming and going.  Please correct me if I am wrong.
>
> At first glance, supporting bundles being activated/deactivated at runtime
> may just be limited to OsgiClassLoader and an impl of OSGi's
> "BundleListener".  HibernateBundleActivator would simply register that
> listener during startup (BundleContext#addBundleListener), which would
> receive the events.  As bundles are added/removed from the runtime, they'd
> just be added/removed from OsgiClassLoader#bundles.
>
> > Also I'd like to start making sure that we fully support (certain) OSGi
> services
> > being replaced.  Especially thinking of TransactionManagers and
> DataSources.
>
> +1
>
> >
> >
> > On Tue, May 26, 2015 at 10:44 AM, Brett Meyer <brmeyer at redhat.com>
> wrote:
> >
> > > IIRC:
> > >
> > > OsgiPersistenceProvider and OsgiSessionFactoryService both need *some*
> way
> > > to build the OsgiClassLoader and pass it into Hibernate
> bootstrapping.  For
> > > the SF, that's easy: just hand OSGiClassLoaderServiceImpl to
> > > BootstrapServiceRegistryBuilder.  For EMF, it looks like I mistakenly
> > > overrode those Bootstrap methods -- I missed that
> PersistenceUnitDescriptor
> > > included the CL.  So you're probably right -- presumably you could
> strip
> > > 'em out and somehow use the descriptor, but you might still need the
> > > overridden method in HibernatePersistenceProvider so that
> > > OsgiPersistenceProvider can give you the OsgiClassLoader to use.
> > >
> > > > Additionally, this ClassLoader is ultimately just used to build the
> > > > ClassLoaderService which hibernate-osgi overrides anyway.
> > >
> > > Right, assuming you're talking about
> > > 'ClassLoaderHelper.overridenClassLoader'.  But the intention there was
> to
> > > remove that whole class ASAP -- that was just a temporary hack for ORM
> 4,
> > > since CL handling was still really static.  But admittedly, I'm a bit
> out
> > > of touch with ORM 5, so I'm not sure if that's feasible yet.
> > >
> > > ----- Original Message -----
> > > > From: "Steve Ebersole" <steve at hibernate.org>
> > > > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> > > > Sent: Saturday, May 23, 2015 1:49:50 PM
> > > > Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
> > > >
> > > > Brett,
> > > >
> > > > As part of HHH-7527 (Enterprise OSGi support) you had changed
> > > > the org.hibernate.jpa.boot.spi.Bootstrap contract to basically
> overload
> > > > each method to additional accept a "providedClassLoader".
> > > >
> > > > Every one of those methods however, also accepts
> > > > a org.hibernate.jpa.boot.spi.PersistenceUnitDescriptor which exposes
> 2
> > > > ClassLoader already.
> > > >
> > > > Additionally, this ClassLoader is ultimately just used to build the
> > > > ClassLoaderService which hibernate-osgi overrides anyway.
> > > >
> > > > Just curious if I missed something.  Unless I did, it seems to me
> that we
> > > > really do not need these overloads on Bootstrap to support Enterprise
> > > > OSGi.  This dove-tails with a discussion from the Karaf user list
> > > > ultimately discussing OsgiClassLoaderService and "holding bundles"
> that
> > > are
> > > > being re-installed or upgraded.  Ultimately I am thinking through
> ways to
> > > > support being able to release OSGI bundle references from the
> > > > OsgiClassLoaderService...
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >
> > >
> >
>

From steve at hibernate.org  Tue May 26 17:49:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 May 2015 16:49:53 -0500
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
	<CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
	<1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>
	<CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>
Message-ID: <CAFdSV9vJL32POW-zHToOwK8vfOKRy6mNp_gto3-Kk_Vi9z2PdA@mail.gmail.com>

I created the following 2 issues to track these improvements:

https://hibernate.atlassian.net/browse/HHH-9818
https://hibernate.atlassian.net/browse/HHH-9819



On Tue, May 26, 2015 at 3:57 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Awesome, thanks!  So I'll investigate BundleListener...
>
> Is that the best way to know when TransactionManagers and DataSources come
> and go too?  Or is there a more specific concept for listening to an "OSGi
> service"?
>
> Also, do the containers generally handle "in-flight" requests in regards
> to TransactionManagers and DataSources on activated/deactivated?  I guess
> this is more a curiosity, since I do not see what we could do if the
> container does not manage it.
>
> On Tue, May 26, 2015 at 3:26 PM, Brett Meyer <brmeyer at redhat.com> wrote:
>
>> > I would fully expect hibernate-osgi to not directly use Bootstrap to
>> build
>> > an EntityManagerFactoryBuilder.  Bootstrap is geared toward users
>> wanting
>> > to leverage 2-phase JPA bootstrapping, not our components.  I would have
>> > expected Enterprise OSGi support to instead directly build (and possibly
>> > override) EntityManagerFactoryBuilderImpl.  I'll add that as a task for
>> > post-5.0.
>>
>> +1, makes sense.  I should have done that to begin with...
>>
>> > Because I think that is a first step in being able to better
>> > manage bundles coming and going.  Please correct me if I am wrong.
>>
>> At first glance, supporting bundles being activated/deactivated at
>> runtime may just be limited to OsgiClassLoader and an impl of OSGi's
>> "BundleListener".  HibernateBundleActivator would simply register that
>> listener during startup (BundleContext#addBundleListener), which would
>> receive the events.  As bundles are added/removed from the runtime, they'd
>> just be added/removed from OsgiClassLoader#bundles.
>>
>> > Also I'd like to start making sure that we fully support (certain) OSGi
>> services
>> > being replaced.  Especially thinking of TransactionManagers and
>> DataSources.
>>
>> +1
>>
>> >
>> >
>> > On Tue, May 26, 2015 at 10:44 AM, Brett Meyer <brmeyer at redhat.com>
>> wrote:
>> >
>> > > IIRC:
>> > >
>> > > OsgiPersistenceProvider and OsgiSessionFactoryService both need
>> *some* way
>> > > to build the OsgiClassLoader and pass it into Hibernate
>> bootstrapping.  For
>> > > the SF, that's easy: just hand OSGiClassLoaderServiceImpl to
>> > > BootstrapServiceRegistryBuilder.  For EMF, it looks like I mistakenly
>> > > overrode those Bootstrap methods -- I missed that
>> PersistenceUnitDescriptor
>> > > included the CL.  So you're probably right -- presumably you could
>> strip
>> > > 'em out and somehow use the descriptor, but you might still need the
>> > > overridden method in HibernatePersistenceProvider so that
>> > > OsgiPersistenceProvider can give you the OsgiClassLoader to use.
>> > >
>> > > > Additionally, this ClassLoader is ultimately just used to build the
>> > > > ClassLoaderService which hibernate-osgi overrides anyway.
>> > >
>> > > Right, assuming you're talking about
>> > > 'ClassLoaderHelper.overridenClassLoader'.  But the intention there
>> was to
>> > > remove that whole class ASAP -- that was just a temporary hack for
>> ORM 4,
>> > > since CL handling was still really static.  But admittedly, I'm a bit
>> out
>> > > of touch with ORM 5, so I'm not sure if that's feasible yet.
>> > >
>> > > ----- Original Message -----
>> > > > From: "Steve Ebersole" <steve at hibernate.org>
>> > > > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>> > > > Sent: Saturday, May 23, 2015 1:49:50 PM
>> > > > Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
>> > > >
>> > > > Brett,
>> > > >
>> > > > As part of HHH-7527 (Enterprise OSGi support) you had changed
>> > > > the org.hibernate.jpa.boot.spi.Bootstrap contract to basically
>> overload
>> > > > each method to additional accept a "providedClassLoader".
>> > > >
>> > > > Every one of those methods however, also accepts
>> > > > a org.hibernate.jpa.boot.spi.PersistenceUnitDescriptor which
>> exposes 2
>> > > > ClassLoader already.
>> > > >
>> > > > Additionally, this ClassLoader is ultimately just used to build the
>> > > > ClassLoaderService which hibernate-osgi overrides anyway.
>> > > >
>> > > > Just curious if I missed something.  Unless I did, it seems to me
>> that we
>> > > > really do not need these overloads on Bootstrap to support
>> Enterprise
>> > > > OSGi.  This dove-tails with a discussion from the Karaf user list
>> > > > ultimately discussing OsgiClassLoaderService and "holding bundles"
>> that
>> > > are
>> > > > being re-installed or upgraded.  Ultimately I am thinking through
>> ways to
>> > > > support being able to release OSGI bundle references from the
>> > > > OsgiClassLoaderService...
>> > > > _______________________________________________
>> > > > hibernate-dev mailing list
>> > > > hibernate-dev at lists.jboss.org
>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > > >
>> > >
>> >
>>
>
>

From steve at hibernate.org  Tue May 26 22:53:48 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 May 2015 21:53:48 -0500
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <CAFdSV9vJL32POW-zHToOwK8vfOKRy6mNp_gto3-Kk_Vi9z2PdA@mail.gmail.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
	<CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
	<1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>
	<CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>
	<CAFdSV9vJL32POW-zHToOwK8vfOKRy6mNp_gto3-Kk_Vi9z2PdA@mail.gmail.com>
Message-ID: <CAFdSV9tuj6ZPmY-3BQhH2t92Lsv70XZ5Jo7Am3cgzSddaYM7rg@mail.gmail.com>

In regards to OsgiClassLoader and dynamically managing the "classpath", any
thoughts on how to handle out single call to OsgiClassLoader#addClassLoader
(from OsgiPersistenceProvider passing
the javax.persistence.spi.PersistenceUnitInfo#getClassLoader we get from
the e-OSGi container)?

I am not sure what all makes up that ClassLoader.

On Tue, May 26, 2015 at 4:49 PM, Steve Ebersole <steve at hibernate.org> wrote:

> I created the following 2 issues to track these improvements:
>
> https://hibernate.atlassian.net/browse/HHH-9818
> https://hibernate.atlassian.net/browse/HHH-9819
>
>
>
> On Tue, May 26, 2015 at 3:57 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Awesome, thanks!  So I'll investigate BundleListener...
>>
>> Is that the best way to know when TransactionManagers and DataSources
>> come and go too?  Or is there a more specific concept for listening to an
>> "OSGi service"?
>>
>> Also, do the containers generally handle "in-flight" requests in regards
>> to TransactionManagers and DataSources on activated/deactivated?  I
>> guess this is more a curiosity, since I do not see what we could do if the
>> container does not manage it.
>>
>> On Tue, May 26, 2015 at 3:26 PM, Brett Meyer <brmeyer at redhat.com> wrote:
>>
>>> > I would fully expect hibernate-osgi to not directly use Bootstrap to
>>> build
>>> > an EntityManagerFactoryBuilder.  Bootstrap is geared toward users
>>> wanting
>>> > to leverage 2-phase JPA bootstrapping, not our components.  I would
>>> have
>>> > expected Enterprise OSGi support to instead directly build (and
>>> possibly
>>> > override) EntityManagerFactoryBuilderImpl.  I'll add that as a task for
>>> > post-5.0.
>>>
>>> +1, makes sense.  I should have done that to begin with...
>>>
>>> > Because I think that is a first step in being able to better
>>> > manage bundles coming and going.  Please correct me if I am wrong.
>>>
>>> At first glance, supporting bundles being activated/deactivated at
>>> runtime may just be limited to OsgiClassLoader and an impl of OSGi's
>>> "BundleListener".  HibernateBundleActivator would simply register that
>>> listener during startup (BundleContext#addBundleListener), which would
>>> receive the events.  As bundles are added/removed from the runtime, they'd
>>> just be added/removed from OsgiClassLoader#bundles.
>>>
>>> > Also I'd like to start making sure that we fully support (certain)
>>> OSGi services
>>> > being replaced.  Especially thinking of TransactionManagers and
>>> DataSources.
>>>
>>> +1
>>>
>>> >
>>> >
>>> > On Tue, May 26, 2015 at 10:44 AM, Brett Meyer <brmeyer at redhat.com>
>>> wrote:
>>> >
>>> > > IIRC:
>>> > >
>>> > > OsgiPersistenceProvider and OsgiSessionFactoryService both need
>>> *some* way
>>> > > to build the OsgiClassLoader and pass it into Hibernate
>>> bootstrapping.  For
>>> > > the SF, that's easy: just hand OSGiClassLoaderServiceImpl to
>>> > > BootstrapServiceRegistryBuilder.  For EMF, it looks like I mistakenly
>>> > > overrode those Bootstrap methods -- I missed that
>>> PersistenceUnitDescriptor
>>> > > included the CL.  So you're probably right -- presumably you could
>>> strip
>>> > > 'em out and somehow use the descriptor, but you might still need the
>>> > > overridden method in HibernatePersistenceProvider so that
>>> > > OsgiPersistenceProvider can give you the OsgiClassLoader to use.
>>> > >
>>> > > > Additionally, this ClassLoader is ultimately just used to build the
>>> > > > ClassLoaderService which hibernate-osgi overrides anyway.
>>> > >
>>> > > Right, assuming you're talking about
>>> > > 'ClassLoaderHelper.overridenClassLoader'.  But the intention there
>>> was to
>>> > > remove that whole class ASAP -- that was just a temporary hack for
>>> ORM 4,
>>> > > since CL handling was still really static.  But admittedly, I'm a
>>> bit out
>>> > > of touch with ORM 5, so I'm not sure if that's feasible yet.
>>> > >
>>> > > ----- Original Message -----
>>> > > > From: "Steve Ebersole" <steve at hibernate.org>
>>> > > > To: "hibernate-dev" <hibernate-dev at lists.jboss.org>
>>> > > > Sent: Saturday, May 23, 2015 1:49:50 PM
>>> > > > Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
>>> > > >
>>> > > > Brett,
>>> > > >
>>> > > > As part of HHH-7527 (Enterprise OSGi support) you had changed
>>> > > > the org.hibernate.jpa.boot.spi.Bootstrap contract to basically
>>> overload
>>> > > > each method to additional accept a "providedClassLoader".
>>> > > >
>>> > > > Every one of those methods however, also accepts
>>> > > > a org.hibernate.jpa.boot.spi.PersistenceUnitDescriptor which
>>> exposes 2
>>> > > > ClassLoader already.
>>> > > >
>>> > > > Additionally, this ClassLoader is ultimately just used to build the
>>> > > > ClassLoaderService which hibernate-osgi overrides anyway.
>>> > > >
>>> > > > Just curious if I missed something.  Unless I did, it seems to me
>>> that we
>>> > > > really do not need these overloads on Bootstrap to support
>>> Enterprise
>>> > > > OSGi.  This dove-tails with a discussion from the Karaf user list
>>> > > > ultimately discussing OsgiClassLoaderService and "holding bundles"
>>> that
>>> > > are
>>> > > > being re-installed or upgraded.  Ultimately I am thinking through
>>> ways to
>>> > > > support being able to release OSGI bundle references from the
>>> > > > OsgiClassLoaderService...
>>> > > > _______________________________________________
>>> > > > hibernate-dev mailing list
>>> > > > hibernate-dev at lists.jboss.org
>>> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > > >
>>> > >
>>> >
>>>
>>
>>
>

From steve at hibernate.org  Tue May 26 23:29:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 May 2015 22:29:11 -0500
Subject: [hibernate-dev] More Dialect and quoting fun
Message-ID: <CAFdSV9uJp+-CS8V9N9f-qoN0gSRhRWW3ZzGTiN3Sb2AKQxQgLg@mail.gmail.com>

What follows is solely an issue with schema update and schema validation, 2
tools that to date we have not "really" supported, but I am trying to
change that with 5.0.

We discussed before the idea of auto-quoting and who should be the
authority in regards to keywords.  We decided that it would be Dialect, for
Dialects that chose to do it, rather than the JDBC DatabaseMetaData.
However there is another piece to this that we currently miss.  It has to
do with the following methods:

* java.sql.DatabaseMetaData#storesMixedCaseQuotedIdentifiers
* java.sql.DatabaseMetaData#storesLowerCaseQuotedIdentifiers
* java.sql.DatabaseMetaData#storesUpperCaseQuotedIdentifiers
* java.sql.DatabaseMetaData#storesMixedCaseIdentifiers
* java.sql.DatabaseMetaData#storesUpperCaseIdentifiers
* java.sql.DatabaseMetaData#storesLowerCaseIdentifiers

We already have bug reports that come directly from drivers not
implementing these "properly".

They come into play in the implementation of the following methods (on
org.hibernate.engine.jdbc.env.spi.IdentifierHelper):

* toMetaDataCatalogName
* toMetaDataSchemaName
* toMetaDataObjectName
* fromMetaDataCatalogName
* fromMetaDataSchemaName
* fromMetaDataObjectName

The to* methods are used when binding the Identifiers to the metadata
queries (DatabaseMetaData#getTables method e.g.).  The from* methods are
used when extracting values from the results.  We currently rely on the
answers to the referenced DatabaseMetaData methods to determine the
quoting->case conversion and case->quoting conversions.

My proposal is that we go a step further than what we did for Dialect and
auto-quoting.  For that, we defined a
Dialect#determineKeywordsForAutoQuoting method and allowed Dialects to
override it if they wanted.  The only time that method is used actually is
in building the IdentifierHelper instance.  So my proposal is that we drop
Dialect#determineKeywordsForAutoQuoting and instead define a
Dialect#buildIdentifierHelper method.  This could work one of 2 ways.

First, the Dialect#buildIdentifierHelper method accepts a DatabaseMetaData
and the base implementation would do what we do today.  However,
DatabaseMetaData can very well be null.  When we initialize
IdentifierHelper atm we assume some (H2 based) defaults.  So going this
first route would mean each Dialect impl that wants to override this method
having to handle nulls there.  Not ideal.

A second approach would be to have Dialect#buildIdentifierHelper accept
either no parameters or just one parameter which would be the same as what
is passed to Dialect#determineKeywordsForAutoQuoting.  This would work such
that null returned from this method would mean to use a fallback approach
based on DatabaseMetaData.

What do y'all think?

From steve at hibernate.org  Tue May 26 23:49:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 26 May 2015 22:49:41 -0500
Subject: [hibernate-dev] More Dialect and quoting fun
In-Reply-To: <CAFdSV9uJp+-CS8V9N9f-qoN0gSRhRWW3ZzGTiN3Sb2AKQxQgLg@mail.gmail.com>
References: <CAFdSV9uJp+-CS8V9N9f-qoN0gSRhRWW3ZzGTiN3Sb2AKQxQgLg@mail.gmail.com>
Message-ID: <CAFdSV9tzqKOWLfoFi3ktvE+VOd+BBj3r+gJvikdak2=i5_=Btg@mail.gmail.com>

If anyone is interested, the issue is here:
https://hibernate.atlassian.net/browse/HHH-9820

I do wonder overall about the interplay that should happen between a
Dialect and the JdbcEnvironment.

On Tue, May 26, 2015 at 10:29 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> What follows is solely an issue with schema update and schema validation,
> 2 tools that to date we have not "really" supported, but I am trying to
> change that with 5.0.
>
> We discussed before the idea of auto-quoting and who should be the
> authority in regards to keywords.  We decided that it would be Dialect, for
> Dialects that chose to do it, rather than the JDBC DatabaseMetaData.
> However there is another piece to this that we currently miss.  It has to
> do with the following methods:
>
> * java.sql.DatabaseMetaData#storesMixedCaseQuotedIdentifiers
> * java.sql.DatabaseMetaData#storesLowerCaseQuotedIdentifiers
> * java.sql.DatabaseMetaData#storesUpperCaseQuotedIdentifiers
> * java.sql.DatabaseMetaData#storesMixedCaseIdentifiers
> * java.sql.DatabaseMetaData#storesUpperCaseIdentifiers
> * java.sql.DatabaseMetaData#storesLowerCaseIdentifiers
>
> We already have bug reports that come directly from drivers not
> implementing these "properly".
>
> They come into play in the implementation of the following methods (on
> org.hibernate.engine.jdbc.env.spi.IdentifierHelper):
>
> * toMetaDataCatalogName
> * toMetaDataSchemaName
> * toMetaDataObjectName
> * fromMetaDataCatalogName
> * fromMetaDataSchemaName
> * fromMetaDataObjectName
>
> The to* methods are used when binding the Identifiers to the metadata
> queries (DatabaseMetaData#getTables method e.g.).  The from* methods are
> used when extracting values from the results.  We currently rely on the
> answers to the referenced DatabaseMetaData methods to determine the
> quoting->case conversion and case->quoting conversions.
>
> My proposal is that we go a step further than what we did for Dialect and
> auto-quoting.  For that, we defined a
> Dialect#determineKeywordsForAutoQuoting method and allowed Dialects to
> override it if they wanted.  The only time that method is used actually is
> in building the IdentifierHelper instance.  So my proposal is that we drop
> Dialect#determineKeywordsForAutoQuoting and instead define a
> Dialect#buildIdentifierHelper method.  This could work one of 2 ways.
>
> First, the Dialect#buildIdentifierHelper method accepts a DatabaseMetaData
> and the base implementation would do what we do today.  However,
> DatabaseMetaData can very well be null.  When we initialize
> IdentifierHelper atm we assume some (H2 based) defaults.  So going this
> first route would mean each Dialect impl that wants to override this method
> having to handle nulls there.  Not ideal.
>
> A second approach would be to have Dialect#buildIdentifierHelper accept
> either no parameters or just one parameter which would be the same as what
> is passed to Dialect#determineKeywordsForAutoQuoting.  This would work such
> that null returned from this method would mean to use a fallback approach
> based on DatabaseMetaData.
>
> What do y'all think?
>

From manderse at redhat.com  Wed May 27 06:23:19 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 27 May 2015 12:23:19 +0200
Subject: [hibernate-dev] More Dialect and quoting fun
In-Reply-To: <CAFdSV9tzqKOWLfoFi3ktvE+VOd+BBj3r+gJvikdak2=i5_=Btg@mail.gmail.com>
References: <CAFdSV9uJp+-CS8V9N9f-qoN0gSRhRWW3ZzGTiN3Sb2AKQxQgLg@mail.gmail.com>
	<CAFdSV9tzqKOWLfoFi3ktvE+VOd+BBj3r+gJvikdak2=i5_=Btg@mail.gmail.com>
Message-ID: <39C38B72-F9CF-4942-8996-3585AC61238A@redhat.com>

On 27 May 2015, at 5:49, Steve Ebersole wrote:

> If anyone is interested, the issue is here:
> https://hibernate.atlassian.net/browse/HHH-9820
>
> I do wonder overall about the interplay that should happen between a
> Dialect and the JdbcEnvironment.

I reckon your issue is that you need access to Dialect before you might
have a DatabaseMetaData so you can't give that to the Dialect to hold on 
to ?

Thus having some parameter to Dialect that allows access to 
DatabaseMetaData
would be most sensible I would think.

One concern about DatabaseMetaData that hit the tools a few times is 
that
getting this can be extremely expensive for some drivers (I don't recall 
which
exactly, but Oracle comes to mind ;)

Thus if you do add it as a parameter to Dialect calls, it might be worth
proxying or wrap DatabaseMetaData. Also be aware that DatabaseMetaData 
might
actually *require* a connection to a database which is not optimal
for tools that might want to just get a script generated without 
requiring
full access to a database.

/max

>
> On Tue, May 26, 2015 at 10:29 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> What follows is solely an issue with schema update and schema 
>> validation,
>> 2 tools that to date we have not "really" supported, but I am trying 
>> to
>> change that with 5.0.
>>
>> We discussed before the idea of auto-quoting and who should be the
>> authority in regards to keywords.  We decided that it would be 
>> Dialect, for
>> Dialects that chose to do it, rather than the JDBC DatabaseMetaData.
>> However there is another piece to this that we currently miss.  It 
>> has to
>> do with the following methods:
>>
>> * java.sql.DatabaseMetaData#storesMixedCaseQuotedIdentifiers
>> * java.sql.DatabaseMetaData#storesLowerCaseQuotedIdentifiers
>> * java.sql.DatabaseMetaData#storesUpperCaseQuotedIdentifiers
>> * java.sql.DatabaseMetaData#storesMixedCaseIdentifiers
>> * java.sql.DatabaseMetaData#storesUpperCaseIdentifiers
>> * java.sql.DatabaseMetaData#storesLowerCaseIdentifiers
>>
>> We already have bug reports that come directly from drivers not
>> implementing these "properly".
>>
>> They come into play in the implementation of the following methods 
>> (on
>> org.hibernate.engine.jdbc.env.spi.IdentifierHelper):
>>
>> * toMetaDataCatalogName
>> * toMetaDataSchemaName
>> * toMetaDataObjectName
>> * fromMetaDataCatalogName
>> * fromMetaDataSchemaName
>> * fromMetaDataObjectName
>>
>> The to* methods are used when binding the Identifiers to the metadata
>> queries (DatabaseMetaData#getTables method e.g.).  The from* methods 
>> are
>> used when extracting values from the results.  We currently rely on 
>> the
>> answers to the referenced DatabaseMetaData methods to determine the
>> quoting->case conversion and case->quoting conversions.
>>
>> My proposal is that we go a step further than what we did for Dialect 
>> and
>> auto-quoting.  For that, we defined a
>> Dialect#determineKeywordsForAutoQuoting method and allowed Dialects 
>> to
>> override it if they wanted.  The only time that method is used 
>> actually is
>> in building the IdentifierHelper instance.  So my proposal is that we 
>> drop
>> Dialect#determineKeywordsForAutoQuoting and instead define a
>> Dialect#buildIdentifierHelper method.  This could work one of 2 ways.
>>
>> First, the Dialect#buildIdentifierHelper method accepts a 
>> DatabaseMetaData
>> and the base implementation would do what we do today.  However,
>> DatabaseMetaData can very well be null.  When we initialize
>> IdentifierHelper atm we assume some (H2 based) defaults.  So going 
>> this
>> first route would mean each Dialect impl that wants to override this 
>> method
>> having to handle nulls there.  Not ideal.
>>
>> A second approach would be to have Dialect#buildIdentifierHelper 
>> accept
>> either no parameters or just one parameter which would be the same as 
>> what
>> is passed to Dialect#determineKeywordsForAutoQuoting.  This would 
>> work such
>> that null returned from this method would mean to use a fallback 
>> approach
>> based on DatabaseMetaData.
>>
>> What do y'all think?
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


/max
http://about.me/maxandersen

From steve at hibernate.org  Wed May 27 07:41:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 06:41:41 -0500
Subject: [hibernate-dev] More Dialect and quoting fun
In-Reply-To: <39C38B72-F9CF-4942-8996-3585AC61238A@redhat.com>
References: <CAFdSV9uJp+-CS8V9N9f-qoN0gSRhRWW3ZzGTiN3Sb2AKQxQgLg@mail.gmail.com>
	<CAFdSV9tzqKOWLfoFi3ktvE+VOd+BBj3r+gJvikdak2=i5_=Btg@mail.gmail.com>
	<39C38B72-F9CF-4942-8996-3585AC61238A@redhat.com>
Message-ID: <CAFdSV9sMKZt=geq=Xa0mm8_0076u6Yccg5i4bTbL0ayD6dQa=Q@mail.gmail.com>

On Wed, May 27, 2015 at 5:23 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

> On 27 May 2015, at 5:49, Steve Ebersole wrote:
>
>  If anyone is interested, the issue is here:
>> https://hibernate.atlassian.net/browse/HHH-9820
>>
>> I do wonder overall about the interplay that should happen between a
>> Dialect and the JdbcEnvironment.
>>
>
> I reckon your issue is that you need access to Dialect before you might
> have a DatabaseMetaData so you can't give that to the Dialect to hold on
> to ?
>

No, that is not my concern at all.

I absolutely do not want the Dialect to "hold on to" the DatabaseMetaData
if by that you mean holding it as instance state.  I was really just
meaning for it to have access to the DatabaseMetaData for the duration of
this method call.  This is actually part of a larger idea I have slowly
been evolving where we use the driver and the Dialect to build an
"understanding" of the capabilities of the underlying database.  The old
way was calling one or more of the 50,000 (give or take ;) true/false
methods on Dialect at runtime.  The new evolving approach is to build
delegates/helpers at boot time that encapsulate all that.  Most of that
work so far is encapsulated by JdbcEnvironment.  One piece of this
JdbcEnvironment is this IdentifierHelper
(JdbcEnvironment#getIdentifierHelper).

Maybe it makes the most sense to psuedo-code some approaches:
https://gist.github.com/sebersole/46b5b7968e748648f562



> One concern about DatabaseMetaData that hit the tools a few times is that
> getting this can be extremely expensive for some drivers (I don't recall
> which
> exactly, but Oracle comes to mind ;)
>

We get this once per bootstrap.

From manderse at redhat.com  Wed May 27 08:33:03 2015
From: manderse at redhat.com (Max Rydahl Andersen)
Date: Wed, 27 May 2015 14:33:03 +0200
Subject: [hibernate-dev] More Dialect and quoting fun
In-Reply-To: <CAFdSV9sMKZt=geq=Xa0mm8_0076u6Yccg5i4bTbL0ayD6dQa=Q@mail.gmail.com>
References: <CAFdSV9uJp+-CS8V9N9f-qoN0gSRhRWW3ZzGTiN3Sb2AKQxQgLg@mail.gmail.com>
	<CAFdSV9tzqKOWLfoFi3ktvE+VOd+BBj3r+gJvikdak2=i5_=Btg@mail.gmail.com>
	<39C38B72-F9CF-4942-8996-3585AC61238A@redhat.com>
	<CAFdSV9sMKZt=geq=Xa0mm8_0076u6Yccg5i4bTbL0ayD6dQa=Q@mail.gmail.com>
Message-ID: <DA91CFD0-5091-40FF-9856-C03F832AB052@redhat.com>


> The old
> way was calling one or more of the 50,000 (give or take ;) true/false
> methods on Dialect at runtime.  The new evolving approach is to build
> delegates/helpers at boot time that encapsulate all that.  Most of that
> work so far is encapsulated by JdbcEnvironment.  One piece of this
> JdbcEnvironment is this IdentifierHelper
> (JdbcEnvironment#getIdentifierHelper).
>
> Maybe it makes the most sense to psuedo-code some approaches:
> https://gist.github.com/sebersole/46b5b7968e748648f562

Of these I think the outline in "first approach" is the best
since it does give the Dialect a chance to actually "talk" to the
server to figure out a possible better lookup than the jdbcDriver does.

But as you said the dialect must handle getting null passed in - just don't 
see a better way to handle that.

Could even keep the implicit contract of if you return null it will
do as described in "second approach" and have a decent fallback.

/max


>
>
>
>> One concern about DatabaseMetaData that hit the tools a few times is that
>> getting this can be extremely expensive for some drivers (I don't recall
>> which
>> exactly, but Oracle comes to mind ;)
>>
>
> We get this once per bootstrap.


/max
http://about.me/maxandersen

From steve at hibernate.org  Wed May 27 09:50:11 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 08:50:11 -0500
Subject: [hibernate-dev] More Dialect and quoting fun
In-Reply-To: <DA91CFD0-5091-40FF-9856-C03F832AB052@redhat.com>
References: <CAFdSV9uJp+-CS8V9N9f-qoN0gSRhRWW3ZzGTiN3Sb2AKQxQgLg@mail.gmail.com>
	<CAFdSV9tzqKOWLfoFi3ktvE+VOd+BBj3r+gJvikdak2=i5_=Btg@mail.gmail.com>
	<39C38B72-F9CF-4942-8996-3585AC61238A@redhat.com>
	<CAFdSV9sMKZt=geq=Xa0mm8_0076u6Yccg5i4bTbL0ayD6dQa=Q@mail.gmail.com>
	<DA91CFD0-5091-40FF-9856-C03F832AB052@redhat.com>
Message-ID: <CAFdSV9ubdjjti7Ko8-c-TLxcyrYmXLL_hvviz1020VOnU00PSg@mail.gmail.com>

I actually started with the third approach.  But you bring up a good point
about allowing the Dialect to access the DatabaseMetaData (and hence
Connection) if it wanted to.  So I would change that a bit.  See the
updated gist

On Wed, May 27, 2015 at 7:33 AM, Max Rydahl Andersen <manderse at redhat.com>
wrote:

>
> > The old
> > way was calling one or more of the 50,000 (give or take ;) true/false
> > methods on Dialect at runtime.  The new evolving approach is to build
> > delegates/helpers at boot time that encapsulate all that.  Most of that
> > work so far is encapsulated by JdbcEnvironment.  One piece of this
> > JdbcEnvironment is this IdentifierHelper
> > (JdbcEnvironment#getIdentifierHelper).
> >
> > Maybe it makes the most sense to psuedo-code some approaches:
> > https://gist.github.com/sebersole/46b5b7968e748648f562
>
> Of these I think the outline in "first approach" is the best
> since it does give the Dialect a chance to actually "talk" to the
> server to figure out a possible better lookup than the jdbcDriver does.
>
> But as you said the dialect must handle getting null passed in - just don't
> see a better way to handle that.
>
> Could even keep the implicit contract of if you return null it will
> do as described in "second approach" and have a decent fallback.
>
> /max
>
>
> >
> >
> >
> >> One concern about DatabaseMetaData that hit the tools a few times is
> that
> >> getting this can be extremely expensive for some drivers (I don't recall
> >> which
> >> exactly, but Oracle comes to mind ;)
> >>
> >
> > We get this once per bootstrap.
>
>
> /max
> http://about.me/maxandersen
>

From steve at hibernate.org  Wed May 27 12:30:28 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 11:30:28 -0500
Subject: [hibernate-dev] More Dialect and quoting fun
In-Reply-To: <CAFdSV9ubdjjti7Ko8-c-TLxcyrYmXLL_hvviz1020VOnU00PSg@mail.gmail.com>
References: <CAFdSV9uJp+-CS8V9N9f-qoN0gSRhRWW3ZzGTiN3Sb2AKQxQgLg@mail.gmail.com>
	<CAFdSV9tzqKOWLfoFi3ktvE+VOd+BBj3r+gJvikdak2=i5_=Btg@mail.gmail.com>
	<39C38B72-F9CF-4942-8996-3585AC61238A@redhat.com>
	<CAFdSV9sMKZt=geq=Xa0mm8_0076u6Yccg5i4bTbL0ayD6dQa=Q@mail.gmail.com>
	<DA91CFD0-5091-40FF-9856-C03F832AB052@redhat.com>
	<CAFdSV9ubdjjti7Ko8-c-TLxcyrYmXLL_hvviz1020VOnU00PSg@mail.gmail.com>
Message-ID: <CAFdSV9vgTUjdSdVJkn+rPAkyo3MGkoEpEQRs3fSMD6wip8_1Ow@mail.gmail.com>

I went ahead and got something in for CR1.  Take a look...

On Wed, May 27, 2015 at 8:50 AM, Steve Ebersole <steve at hibernate.org> wrote:

> I actually started with the third approach.  But you bring up a good point
> about allowing the Dialect to access the DatabaseMetaData (and hence
> Connection) if it wanted to.  So I would change that a bit.  See the
> updated gist
>
> On Wed, May 27, 2015 at 7:33 AM, Max Rydahl Andersen <manderse at redhat.com>
> wrote:
>
>>
>> > The old
>> > way was calling one or more of the 50,000 (give or take ;) true/false
>> > methods on Dialect at runtime.  The new evolving approach is to build
>> > delegates/helpers at boot time that encapsulate all that.  Most of that
>> > work so far is encapsulated by JdbcEnvironment.  One piece of this
>> > JdbcEnvironment is this IdentifierHelper
>> > (JdbcEnvironment#getIdentifierHelper).
>> >
>> > Maybe it makes the most sense to psuedo-code some approaches:
>> > https://gist.github.com/sebersole/46b5b7968e748648f562
>>
>> Of these I think the outline in "first approach" is the best
>> since it does give the Dialect a chance to actually "talk" to the
>> server to figure out a possible better lookup than the jdbcDriver does.
>>
>> But as you said the dialect must handle getting null passed in - just
>> don't
>> see a better way to handle that.
>>
>> Could even keep the implicit contract of if you return null it will
>> do as described in "second approach" and have a decent fallback.
>>
>> /max
>>
>>
>> >
>> >
>> >
>> >> One concern about DatabaseMetaData that hit the tools a few times is
>> that
>> >> getting this can be extremely expensive for some drivers (I don't
>> recall
>> >> which
>> >> exactly, but Oracle comes to mind ;)
>> >>
>> >
>> > We get this once per bootstrap.
>>
>>
>> /max
>> http://about.me/maxandersen
>>
>
>

From steve at hibernate.org  Wed May 27 21:56:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 20:56:41 -0500
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <5134CE9B.5020700@hibernate.org>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
Message-ID: <CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>

If I may dig up a zombie thread.. :)

What I plan to do unless I hear loud arguments to the contrary is to
truncate this to just the current major release indicated by branch.  E.g.
the 4.2 branch would maintain changes just for 4.2 release family, etc.
This kind of goes hand-on-hand with what I am planning for the in-line
migration guide too.

On Mon, Mar 4, 2013 at 10:40 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Depends what you mean "sync it in master".  Its not like you should be
> cherry-picking changelog changes from other branches to master.
>
> But, you should be collecting the changes from Jira putting them into the
> changelog on the indicated branch(es).  Currently, that means anything
> marked jpa21 should get copied into the master changelog.  Sames was true
> for 4.2 before 4.2 was branched off, and 4.1 before that and so on.
> Granted it is more difficult in an environment like we have where we
> maintain multiple branches simultaneously.  But this highlights the
> importance of marking versions correctly in Jira.
>
>
>
> On 03/04/2013 08:34 AM, Brett Meyer wrote:
>
>> I always maintain it in the 4.1/4.2 branches, but we admittedly forget to
>> sync it in master.  Up to you guys.
>>
>> Brett Meyer
>> Red Hat Software Engineer, Hibernate
>> +1 260.349.5732
>>
>> ----- Original Message -----
>> From: "Steve Ebersole" <steve at hibernate.org>
>> To: "Sanne Grinovero" <sanne at hibernate.org>
>> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
>> Sent: Sunday, March 3, 2013 10:42:12 AM
>> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
>>
>> If I had to guess, Brett probably just missed updating that during the
>> last few releases.  I am open to discuss either option here; either
>> remove the file or maintain it.
>>
>>
>> On Sat 02 Mar 2013 02:58:56 PM CST, Sanne Grinovero wrote:
>>
>>> On 2 March 2013 20:51, Hardy Ferentschik <hardy at hibernate.org> wrote:
>>>
>>>> On 2 Mar 2013, at 21:19, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>>
>>>>  The file changelog.txt in the root ot the Hibernate ORM project
>>>>> seems outdated.
>>>>>
>>>>
>>>> Personally I find this file useless. I think a link a link in the
>>>> readme to the Jira changeling would suffice. However, I know some
>>>> people think the changelog is valuable.
>>>>
>>>> But of course, it either needs to be maintained or deleted.
>>>>
>>>
>>> +1
>>> I'd prefer maintained, but otherwise deleted woudl be better than
>>> misleading indeed.
>>>
>>> The reason I like it is that it allows me a very quick search on the
>>> history of the current branch, while from JIRA it's not immediate.
>>> Of course from there I continue on JIRA or GIT logs for more insight..
>>>
>>> In this case I wanted to double-check if we had dropped OSCache
>>> support. I remember we had planned for it, but couldn't find tracking
>>> about its removal in JIRA.
>>>
>>> Sanne
>>>
>>>
>>>>
>>>>>
>>>> --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 steve at hibernate.org  Wed May 27 21:57:39 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 20:57:39 -0500
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
Message-ID: <CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>

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

On Wed, May 27, 2015 at 8:56 PM, Steve Ebersole <steve at hibernate.org> wrote:

> If I may dig up a zombie thread.. :)
>
> What I plan to do unless I hear loud arguments to the contrary is to
> truncate this to just the current major release indicated by branch.  E.g.
> the 4.2 branch would maintain changes just for 4.2 release family, etc.
> This kind of goes hand-on-hand with what I am planning for the in-line
> migration guide too.
>
> On Mon, Mar 4, 2013 at 10:40 AM, Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Depends what you mean "sync it in master".  Its not like you should be
>> cherry-picking changelog changes from other branches to master.
>>
>> But, you should be collecting the changes from Jira putting them into the
>> changelog on the indicated branch(es).  Currently, that means anything
>> marked jpa21 should get copied into the master changelog.  Sames was true
>> for 4.2 before 4.2 was branched off, and 4.1 before that and so on.
>> Granted it is more difficult in an environment like we have where we
>> maintain multiple branches simultaneously.  But this highlights the
>> importance of marking versions correctly in Jira.
>>
>>
>>
>> On 03/04/2013 08:34 AM, Brett Meyer wrote:
>>
>>> I always maintain it in the 4.1/4.2 branches, but we admittedly forget
>>> to sync it in master.  Up to you guys.
>>>
>>> Brett Meyer
>>> Red Hat Software Engineer, Hibernate
>>> +1 260.349.5732
>>>
>>> ----- Original Message -----
>>> From: "Steve Ebersole" <steve at hibernate.org>
>>> To: "Sanne Grinovero" <sanne at hibernate.org>
>>> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
>>> Sent: Sunday, March 3, 2013 10:42:12 AM
>>> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
>>>
>>> If I had to guess, Brett probably just missed updating that during the
>>> last few releases.  I am open to discuss either option here; either
>>> remove the file or maintain it.
>>>
>>>
>>> On Sat 02 Mar 2013 02:58:56 PM CST, Sanne Grinovero wrote:
>>>
>>>> On 2 March 2013 20:51, Hardy Ferentschik <hardy at hibernate.org> wrote:
>>>>
>>>>> On 2 Mar 2013, at 21:19, Sanne Grinovero <sanne at hibernate.org> wrote:
>>>>>
>>>>>  The file changelog.txt in the root ot the Hibernate ORM project
>>>>>> seems outdated.
>>>>>>
>>>>>
>>>>> Personally I find this file useless. I think a link a link in the
>>>>> readme to the Jira changeling would suffice. However, I know some
>>>>> people think the changelog is valuable.
>>>>>
>>>>> But of course, it either needs to be maintained or deleted.
>>>>>
>>>>
>>>> +1
>>>> I'd prefer maintained, but otherwise deleted woudl be better than
>>>> misleading indeed.
>>>>
>>>> The reason I like it is that it allows me a very quick search on the
>>>> history of the current branch, while from JIRA it's not immediate.
>>>> Of course from there I continue on JIRA or GIT logs for more insight..
>>>>
>>>> In this case I wanted to double-check if we had dropped OSCache
>>>> support. I remember we had planned for it, but couldn't find tracking
>>>> about its removal in JIRA.
>>>>
>>>> Sanne
>>>>
>>>>
>>>>>
>>>>>>
>>>>> --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 brmeyer at redhat.com  Wed May 27 22:01:51 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 27 May 2015 22:01:51 -0400 (EDT)
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
Message-ID: <787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>

+1 from me.  Although, on the other hand, do we really need to keep maintaining that to begin with?  I guess I never thought simply having users go to the JIRA release notes was a big deal.  Just my $.02.

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>, "Sanne Grinovero" <sanne at hibernate.org>
> Sent: Wednesday, May 27, 2015 9:57:39 PM
> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> 
> https://hibernate.atlassian.net/browse/HHH-9827
> 
> On Wed, May 27, 2015 at 8:56 PM, Steve Ebersole <steve at hibernate.org> wrote:
> 
> > If I may dig up a zombie thread.. :)
> >
> > What I plan to do unless I hear loud arguments to the contrary is to
> > truncate this to just the current major release indicated by branch.  E.g.
> > the 4.2 branch would maintain changes just for 4.2 release family, etc.
> > This kind of goes hand-on-hand with what I am planning for the in-line
> > migration guide too.
> >
> > On Mon, Mar 4, 2013 at 10:40 AM, Steve Ebersole <steve at hibernate.org>
> > wrote:
> >
> >> Depends what you mean "sync it in master".  Its not like you should be
> >> cherry-picking changelog changes from other branches to master.
> >>
> >> But, you should be collecting the changes from Jira putting them into the
> >> changelog on the indicated branch(es).  Currently, that means anything
> >> marked jpa21 should get copied into the master changelog.  Sames was true
> >> for 4.2 before 4.2 was branched off, and 4.1 before that and so on.
> >> Granted it is more difficult in an environment like we have where we
> >> maintain multiple branches simultaneously.  But this highlights the
> >> importance of marking versions correctly in Jira.
> >>
> >>
> >>
> >> On 03/04/2013 08:34 AM, Brett Meyer wrote:
> >>
> >>> I always maintain it in the 4.1/4.2 branches, but we admittedly forget
> >>> to sync it in master.  Up to you guys.
> >>>
> >>> Brett Meyer
> >>> Red Hat Software Engineer, Hibernate
> >>> +1 260.349.5732
> >>>
> >>> ----- Original Message -----
> >>> From: "Steve Ebersole" <steve at hibernate.org>
> >>> To: "Sanne Grinovero" <sanne at hibernate.org>
> >>> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> >>> Sent: Sunday, March 3, 2013 10:42:12 AM
> >>> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> >>>
> >>> If I had to guess, Brett probably just missed updating that during the
> >>> last few releases.  I am open to discuss either option here; either
> >>> remove the file or maintain it.
> >>>
> >>>
> >>> On Sat 02 Mar 2013 02:58:56 PM CST, Sanne Grinovero wrote:
> >>>
> >>>> On 2 March 2013 20:51, Hardy Ferentschik <hardy at hibernate.org> wrote:
> >>>>
> >>>>> On 2 Mar 2013, at 21:19, Sanne Grinovero <sanne at hibernate.org> wrote:
> >>>>>
> >>>>>  The file changelog.txt in the root ot the Hibernate ORM project
> >>>>>> seems outdated.
> >>>>>>
> >>>>>
> >>>>> Personally I find this file useless. I think a link a link in the
> >>>>> readme to the Jira changeling would suffice. However, I know some
> >>>>> people think the changelog is valuable.
> >>>>>
> >>>>> But of course, it either needs to be maintained or deleted.
> >>>>>
> >>>>
> >>>> +1
> >>>> I'd prefer maintained, but otherwise deleted woudl be better than
> >>>> misleading indeed.
> >>>>
> >>>> The reason I like it is that it allows me a very quick search on the
> >>>> history of the current branch, while from JIRA it's not immediate.
> >>>> Of course from there I continue on JIRA or GIT logs for more insight..
> >>>>
> >>>> In this case I wanted to double-check if we had dropped OSCache
> >>>> support. I remember we had planned for it, but couldn't find tracking
> >>>> about its removal in JIRA.
> >>>>
> >>>> Sanne
> >>>>
> >>>>
> >>>>>
> >>>>>>
> >>>>> --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 steve at hibernate.org  Wed May 27 22:07:53 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 21:07:53 -0500
Subject: [hibernate-dev] Hibernate ORM 5.0.0.CR1 Release
Message-ID: <CAFdSV9stxLvREzQW=R0aCBfciOYbTUFBtC01YHgL+8qU7FQH6g@mail.gmail.com>

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

From brmeyer at redhat.com  Wed May 27 22:09:35 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 27 May 2015 22:09:35 -0400 (EDT)
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
	<CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
	<1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>
	<CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>
Message-ID: <591309801.7224156.1432778975070.JavaMail.zimbra@redhat.com>

> Is that the best way to know when TransactionManagers and DataSources come
> and go too?  Or is there a more specific concept for listening to an "OSGi
> service"?

At least for TransactionManagers, yes, the BundleListener is probably the best approach.  I'm not aware of a more specific way beyond that, but I'm not 100%.  Honestly not sure about the DataSource -- can't remember if most containers automatically expose that or not.

> 
> Also, do the containers generally handle "in-flight" requests in
> regards to TransactionManagers
> and DataSources on activated/deactivated?  I guess this is more a
> curiosity, since I do not see what we could do if the container does not
> manage it.

Really good question, but not sure.  The hope is that a truly OSGi-friendly bundle is "dynamic" enough to gracefully terminate in-progress actions if deactivated.  They're given that opportunity through BundleActivator#stop.  Of course, that's entirely up to the specific impl.  I would expect Karaf container-provided defaults (Geronimo JTA, etc.) to handle that reasonably well for basic cases, but not sure about the real-world edge cases...

Note that I always hoped to make Hibernate fit that bill, but we're *far* from it.  Deactivation would, in all likelihood, be catastrophic.  And no idea about re-activation.

From brmeyer at redhat.com  Wed May 27 22:16:17 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Wed, 27 May 2015 22:16:17 -0400 (EDT)
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <CAFdSV9tuj6ZPmY-3BQhH2t92Lsv70XZ5Jo7Am3cgzSddaYM7rg@mail.gmail.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
	<CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
	<1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>
	<CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>
	<CAFdSV9vJL32POW-zHToOwK8vfOKRy6mNp_gto3-Kk_Vi9z2PdA@mail.gmail.com>
	<CAFdSV9tuj6ZPmY-3BQhH2t92Lsv70XZ5Jo7Am3cgzSddaYM7rg@mail.gmail.com>
Message-ID: <636039041.7224887.1432779377264.JavaMail.zimbra@redhat.com>

> In regards to OsgiClassLoader and dynamically managing the "classpath", any
> thoughts on how to handle out single call to OsgiClassLoader#addClassLoader
> (from OsgiPersistenceProvider passing
> the javax.persistence.spi.PersistenceUnitInfo#getClassLoader we get from
> the e-OSGi container)?
> 
> I am not sure what all makes up that ClassLoader.

Another really good question, but not sure.  I *hope* that Aries (and other Enterprise OSGi JPA providers) would smartly/narrowly scope that to the specific persistence unit and responsible bundle, but who knows what that actually means in practice.  Since our Enterprise OSGi setup currently works, I would assume that *some* sort of scoping is in place.  Otherwise, we'd hit CL conflicts.

From steve at hibernate.org  Wed May 27 22:47:29 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 21:47:29 -0500
Subject: [hibernate-dev] Release announcements
Message-ID: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>

At the moment we write release announcements using in.relation.to and then
announce in other mediums by posting that link.  We all agree (more or
less) that the wiki editor and rendering on there leaves much to be desired.

Brett had mentioned a long time ago about GitHub and its release
capabilities and tonight I went back and looked at them again.  I created a
more descriptive release announcement in GitHub then its default of just
using the tag message for this 5.0.0.CR1 release just to see how it worked
out.  Here are the 2 links for comparison:

* http://in.relation.to/Bloggers/HibernateORM500CR1Release
* https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR1

There are a few things to notice here.  First, I think we can all agree
that the second looks considerably better.  Also, there is a lot to be said
for these being closely available from the source repo.

Another thing to note is that the GitHub release has the ability to attach
random zips and tgz.  I have not taken advantage of that as I felt bad
uploading our 62 and 97 Mb release bundles here just for a PoC.  I do have
a task for myself post 5.0 to re-think how we build these release
bundles[1].  But ultimately whether it makes sens to attach them here comes
down to whether we think SF and its FRS has any advantage.  I think
download statistics will be the only discussion point there.

Anyway, moving forward I plan to move to this approach for release
announcements.

The only sticky point is the sourcing for the banners on hibernate.org.
What drives that?  RSS?

Thoughts?

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

From steve at hibernate.org  Wed May 27 22:53:38 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 21:53:38 -0500
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9vpJLJdfEeCS0ro3DaRDCaru9BobPKvp9N-k+zeHp-7Yg@mail.gmail.com>

Personally I also think that we should refer people to Jira for this
information.  We already have an authoritative version of this list (Jira)
and I generally dislike duplication.

But I am just trying to manage different perspectives.  A few people raised
points that relying on Jira might not be the best for a few reasons.  So
trying to reach a consensus that works for everyone.

I just know that an ~ 400Kb text file for this purpose is a bit of overkill
no matter what side of the fence people fall :)


On Wed, May 27, 2015 at 9:01 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> +1 from me.  Although, on the other hand, do we really need to keep
> maintaining that to begin with?  I guess I never thought simply having
> users go to the JIRA release notes was a big deal.  Just my $.02.
>
> ----- Original Message -----
> > From: "Steve Ebersole" <steve at hibernate.org>
> > To: "Brett Meyer" <brmeyer at redhat.com>
> > Cc: "Hibernate" <hibernate-dev at lists.jboss.org>, "Sanne Grinovero" <
> sanne at hibernate.org>
> > Sent: Wednesday, May 27, 2015 9:57:39 PM
> > Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> >
> > https://hibernate.atlassian.net/browse/HHH-9827
> >
> > On Wed, May 27, 2015 at 8:56 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >
> > > If I may dig up a zombie thread.. :)
> > >
> > > What I plan to do unless I hear loud arguments to the contrary is to
> > > truncate this to just the current major release indicated by branch.
> E.g.
> > > the 4.2 branch would maintain changes just for 4.2 release family, etc.
> > > This kind of goes hand-on-hand with what I am planning for the in-line
> > > migration guide too.
> > >
> > > On Mon, Mar 4, 2013 at 10:40 AM, Steve Ebersole <steve at hibernate.org>
> > > wrote:
> > >
> > >> Depends what you mean "sync it in master".  Its not like you should be
> > >> cherry-picking changelog changes from other branches to master.
> > >>
> > >> But, you should be collecting the changes from Jira putting them into
> the
> > >> changelog on the indicated branch(es).  Currently, that means anything
> > >> marked jpa21 should get copied into the master changelog.  Sames was
> true
> > >> for 4.2 before 4.2 was branched off, and 4.1 before that and so on.
> > >> Granted it is more difficult in an environment like we have where we
> > >> maintain multiple branches simultaneously.  But this highlights the
> > >> importance of marking versions correctly in Jira.
> > >>
> > >>
> > >>
> > >> On 03/04/2013 08:34 AM, Brett Meyer wrote:
> > >>
> > >>> I always maintain it in the 4.1/4.2 branches, but we admittedly
> forget
> > >>> to sync it in master.  Up to you guys.
> > >>>
> > >>> Brett Meyer
> > >>> Red Hat Software Engineer, Hibernate
> > >>> +1 260.349.5732
> > >>>
> > >>> ----- Original Message -----
> > >>> From: "Steve Ebersole" <steve at hibernate.org>
> > >>> To: "Sanne Grinovero" <sanne at hibernate.org>
> > >>> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> > >>> Sent: Sunday, March 3, 2013 10:42:12 AM
> > >>> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> > >>>
> > >>> If I had to guess, Brett probably just missed updating that during
> the
> > >>> last few releases.  I am open to discuss either option here; either
> > >>> remove the file or maintain it.
> > >>>
> > >>>
> > >>> On Sat 02 Mar 2013 02:58:56 PM CST, Sanne Grinovero wrote:
> > >>>
> > >>>> On 2 March 2013 20:51, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> > >>>>
> > >>>>> On 2 Mar 2013, at 21:19, Sanne Grinovero <sanne at hibernate.org>
> wrote:
> > >>>>>
> > >>>>>  The file changelog.txt in the root ot the Hibernate ORM project
> > >>>>>> seems outdated.
> > >>>>>>
> > >>>>>
> > >>>>> Personally I find this file useless. I think a link a link in the
> > >>>>> readme to the Jira changeling would suffice. However, I know some
> > >>>>> people think the changelog is valuable.
> > >>>>>
> > >>>>> But of course, it either needs to be maintained or deleted.
> > >>>>>
> > >>>>
> > >>>> +1
> > >>>> I'd prefer maintained, but otherwise deleted woudl be better than
> > >>>> misleading indeed.
> > >>>>
> > >>>> The reason I like it is that it allows me a very quick search on the
> > >>>> history of the current branch, while from JIRA it's not immediate.
> > >>>> Of course from there I continue on JIRA or GIT logs for more
> insight..
> > >>>>
> > >>>> In this case I wanted to double-check if we had dropped OSCache
> > >>>> support. I remember we had planned for it, but couldn't find
> tracking
> > >>>> about its removal in JIRA.
> > >>>>
> > >>>> Sanne
> > >>>>
> > >>>>
> > >>>>>
> > >>>>>>
> > >>>>> --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 steve at hibernate.org  Wed May 27 23:43:41 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 22:43:41 -0500
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <591309801.7224156.1432778975070.JavaMail.zimbra@redhat.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
	<CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
	<1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>
	<CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>
	<591309801.7224156.1432778975070.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9t7Z20UpFo3Drf0J0_hJjduxsnNv7_QU0nuxdD+Oq4wCg@mail.gmail.com>

On Wed, May 27, 2015 at 9:09 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> > Is that the best way to know when TransactionManagers and DataSources
> come
> > and go too?  Or is there a more specific concept for listening to an
> "OSGi
> > service"?
>
> At least for TransactionManagers, yes, the BundleListener is probably the
> best approach.  I'm not aware of a more specific way beyond that, but I'm
> not 100%.  Honestly not sure about the DataSource -- can't remember if most
> containers automatically expose that or not.
>

But I would have to know the bundle that TransactionManager comes from in
order to listener to it, no?

I think we ultimately want an "OSGi DataSource adpater" as well, sort of
like we do with OsgiJtaPlatform.  I say an adapter here so that it can fit
with both ConnectionProvider and with MultiTenantConnectionProvider.


> >
> > Also, do the containers generally handle "in-flight" requests in
> > regards to TransactionManagers
> > and DataSources on activated/deactivated?  I guess this is more a
> > curiosity, since I do not see what we could do if the container does not
> > manage it.
>
> Really good question, but not sure.  The hope is that a truly
> OSGi-friendly bundle is "dynamic" enough to gracefully terminate
> in-progress actions if deactivated.  They're given that opportunity through
> BundleActivator#stop.  Of course, that's entirely up to the specific impl.
> I would expect Karaf container-provided defaults (Geronimo JTA, etc.) to
> handle that reasonably well for basic cases, but not sure about the
> real-world edge cases...
>
> Note that I always hoped to make Hibernate fit that bill, but we're *far*
> from it.  Deactivation would, in all likelihood, be catastrophic.  And no
> idea about re-activation.
>

I *think* de-activation would be catastrophic during the period that the
depended-on bundle is not available.  I am ok with that.  That seems
natural to me.  If a bundle we are providing persistence for says it wants
to use a JTA TransactionManager e.g. and that TransactionManager is not
available... I think an exception is perfectly valid outcome.

But yes it is the re-activation case (the TransactionManager becomes
available again) that I want to work.  In theory this should be a simple
thing to do; I think we already have the proper encapsulation with
OsgiJtaPlatform.  I just have no idea how to know when these things become
available and when they become unavailable.

I'll poke around on the Kara user list and see what I can find.

From steve at hibernate.org  Wed May 27 23:48:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 22:48:09 -0500
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <636039041.7224887.1432779377264.JavaMail.zimbra@redhat.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
	<CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
	<1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>
	<CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>
	<CAFdSV9vJL32POW-zHToOwK8vfOKRy6mNp_gto3-Kk_Vi9z2PdA@mail.gmail.com>
	<CAFdSV9tuj6ZPmY-3BQhH2t92Lsv70XZ5Jo7Am3cgzSddaYM7rg@mail.gmail.com>
	<636039041.7224887.1432779377264.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9s1krfy5D89MHVmYdcG==tKBHEsLPKH=su9x+vhZgrGiA@mail.gmail.com>

More I mean what bundle(s) should I listen to in order to know that the
ClassLoader is no longer valid?  Or how would I otherwise know that or be
notified of that?

I can ping Christian regarding Aries specifically and get his thoughts.

On Wed, May 27, 2015 at 9:16 PM, Brett Meyer <brmeyer at redhat.com> wrote:

> > In regards to OsgiClassLoader and dynamically managing the "classpath",
> any
> > thoughts on how to handle out single call to
> OsgiClassLoader#addClassLoader
> > (from OsgiPersistenceProvider passing
> > the javax.persistence.spi.PersistenceUnitInfo#getClassLoader we get from
> > the e-OSGi container)?
> >
> > I am not sure what all makes up that ClassLoader.
>
> Another really good question, but not sure.  I *hope* that Aries (and
> other Enterprise OSGi JPA providers) would smartly/narrowly scope that to
> the specific persistence unit and responsible bundle, but who knows what
> that actually means in practice.  Since our Enterprise OSGi setup currently
> works, I would assume that *some* sort of scoping is in place.  Otherwise,
> we'd hit CL conflicts.
>

From steve at hibernate.org  Thu May 28 00:34:44 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 27 May 2015 23:34:44 -0500
Subject: [hibernate-dev] HCANN, AnnotationFactory and TCCL
Message-ID: <CAFdSV9u4hpdy+iRRcHwuGt7x0FwHRmtd=tFpXL8Rf+Ve08R0LA@mail.gmail.com>

WildFly consuming ORM 5.0 is still hitting one last TCCL issue with HCANN.
It happens in
the org.hibernate.annotations.common.annotationfactory.AnnotationFactory#create
method trying to build the "annotation proxy class".

There are a few possible approaches to resolve this...

The simplest potentially effects other HCANN consumers, so we'd obviously
all need to agree.  Anyway, the simplest approach is to use the ClassLoader
for annotation @interface Class rather than the TCCL.  I do not see a
problem with that, but it would change some semantic.

The only other workable approach (without redesign of HCANN) I could think
of is to basically make a copy of AnnotationFactory and copy it into ORM.

Sure I could overload AnnotationFactory#create to optionally accept a
ClassLoader, but that introduces a hard dependency on new specific version
of HCANN.

Open to other suggestions.  Thoughts?

From hardy at hibernate.org  Thu May 28 04:42:05 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 28 May 2015 10:42:05 +0200
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
Message-ID: <20150528084205.GB35093@Nineveh.lan>

On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> +1 from me.  Although, on the other hand, do we really need to keep maintaining that to begin with?  I guess I never thought simply having users go to the JIRA release notes was a big deal.  Just my $.02.

Same for me on both counts, the proposed handling of changelog.txt as well as Brett's comment regarding the usefulness of this file altogether.

--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/20150528/6e16e99f/attachment.bin 

From hardy at hibernate.org  Thu May 28 05:05:27 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 28 May 2015 11:05:27 +0200
Subject: [hibernate-dev] Release announcements
In-Reply-To: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>
References: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>
Message-ID: <20150528090527.GC35093@Nineveh.lan>

Hi,

On Wed, May 27, 2015 at 09:47:29PM -0500, Steve Ebersole wrote:
> At the moment we write release announcements using in.relation.to and then
> announce in other mediums by posting that link.  We all agree (more or
> less) that the wiki editor and rendering on there leaves much to be desired.

+100, the editor and rendering sucks.

> Brett had mentioned a long time ago about GitHub and its release
> capabilities and tonight I went back and looked at them again.  I created a
> more descriptive release announcement in GitHub then its default of just
> using the tag message for this 5.0.0.CR1 release just to see how it worked
> out.  Here are the 2 links for comparison:
> 
> * http://in.relation.to/Bloggers/HibernateORM500CR1Release
> * https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR1
> 
> There are a few things to notice here.  First, I think we can all agree
> that the second looks considerably better.  Also, there is a lot to be said
> for these being closely available from the source repo.

I like this approach in general and I agree there is a certain merit in having
the announcements in the source repo, BUT :-)

We are very close now with the migration of in.relation.to to awestruct. In fact I
was hoping we could do the migration within a couple of weeks. Using the awestruct
based blog, we get markdown/ascidoc for writing the blog entries and also a blog
which matches it its style the current hibernate.org website. It also means we can
continue our practice of announcing on the blog. The release announcements make up
a considerable part of the blog content, I fear moving them to GitHub will make our blog
to appear stagnant.

My vote is to push this blog migration through - now!

--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/20150528/312dba63/attachment.bin 

From hardy at hibernate.org  Thu May 28 05:31:22 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 28 May 2015 11:31:22 +0200
Subject: [hibernate-dev] HCANN, AnnotationFactory and TCCL
In-Reply-To: <CAFdSV9u4hpdy+iRRcHwuGt7x0FwHRmtd=tFpXL8Rf+Ve08R0LA@mail.gmail.com>
References: <CAFdSV9u4hpdy+iRRcHwuGt7x0FwHRmtd=tFpXL8Rf+Ve08R0LA@mail.gmail.com>
Message-ID: <20150528093122.GD35093@Nineveh.lan>

Hi,

On Wed, May 27, 2015 at 11:34:44PM -0500, Steve Ebersole wrote:
> The simplest potentially effects other HCANN consumers, so we'd obviously
> all need to agree.  Anyway, the simplest approach is to use the ClassLoader
> for annotation @interface Class rather than the TCCL.  I do not see a
> problem with that,

Right, seems reasonable to me.

> The only other workable approach (without redesign of HCANN) I could think
> of is to basically make a copy of AnnotationFactory and copy it into ORM.

For what it's worth, that's what Validator did. There we just needed the annotation
proxies and had no need for the whole ReflectionManager business. Also I wanted
to avoid another dependency. 

In ORM the situation is a bit different. Just copying the AnnotationFactory does not
remove the need for commons annotations (sigh), so I guess I stick with the first
approach.

--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/20150528/e3de32b2/attachment.bin 

From sanne at hibernate.org  Thu May 28 06:08:05 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 28 May 2015 11:08:05 +0100
Subject: [hibernate-dev] HCANN, AnnotationFactory and TCCL
In-Reply-To: <CAFdSV9u4hpdy+iRRcHwuGt7x0FwHRmtd=tFpXL8Rf+Ve08R0LA@mail.gmail.com>
References: <CAFdSV9u4hpdy+iRRcHwuGt7x0FwHRmtd=tFpXL8Rf+Ve08R0LA@mail.gmail.com>
Message-ID: <CAFm4XO3mwF2DN5p2VXhyUTf=cKNd8XzYue=pGLfws9EBvkB4DA@mail.gmail.com>

On 28 May 2015 at 05:34, Steve Ebersole <steve at hibernate.org> wrote:
> WildFly consuming ORM 5.0 is still hitting one last TCCL issue with HCANN.
> It happens in
> the org.hibernate.annotations.common.annotationfactory.AnnotationFactory#create
> method trying to build the "annotation proxy class".
>
> There are a few possible approaches to resolve this...
>
> The simplest potentially effects other HCANN consumers, so we'd obviously
> all need to agree.  Anyway, the simplest approach is to use the ClassLoader
> for annotation @interface Class rather than the TCCL.  I do not see a
> problem with that, but it would change some semantic.

+1 as well
With that TCCL trick in place it seems it was possible to have the
module actually use a set of annotations provided by the user, to
override those (with same name) already provided by ORM. If that was
meant as a "feature" I'd be glad to see it killed.

>
> The only other workable approach (without redesign of HCANN) I could think
> of is to basically make a copy of AnnotationFactory and copy it into ORM.
>
> Sure I could overload AnnotationFactory#create to optionally accept a
> ClassLoader, but that introduces a hard dependency on new specific version
> of HCANN.

The above approach seems nicer as you already have the Class,
otherwise I'd prefer to see such helpers to always allow an explicit
ClassLoader.
I don't think you have to worry about ORM requiring new versions of
HCANN occasionally, we all have to make changes to keep up anyway and
a version upgrade is easy enough.

We did have a problem with recent "planet alignment" efforts of
versions on other platforms though, which was caused by a significant
semantic change of a similar classloader improvement, and some people
had upgraded the micro version of HCANN without enough testing. As far
as I remember the dangerous upgrade was the upgrade from HCANN
4.0.1.Final to 4.0.5.Final, which breaks Hibernate ORM 4.2 within the
app server.

In retrospective we should have increased the minor version of HCANN,
so maybe you could do that now when fixing the TCCL issue?

>
> Open to other suggestions.  Thoughts?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Thu May 28 06:16:49 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 28 May 2015 11:16:49 +0100
Subject: [hibernate-dev] Release announcements
In-Reply-To: <20150528090527.GC35093@Nineveh.lan>
References: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>
	<20150528090527.GC35093@Nineveh.lan>
Message-ID: <CAFm4XO3evq2euAQ9_6U6-D0REVu=ABcppmO3QgE7EXwHAO_nmg@mail.gmail.com>

On 28 May 2015 at 10:05, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> On Wed, May 27, 2015 at 09:47:29PM -0500, Steve Ebersole wrote:
>> At the moment we write release announcements using in.relation.to and then
>> announce in other mediums by posting that link.  We all agree (more or
>> less) that the wiki editor and rendering on there leaves much to be desired.
>
> +100, the editor and rendering sucks.
>
>> Brett had mentioned a long time ago about GitHub and its release
>> capabilities and tonight I went back and looked at them again.  I created a
>> more descriptive release announcement in GitHub then its default of just
>> using the tag message for this 5.0.0.CR1 release just to see how it worked
>> out.  Here are the 2 links for comparison:
>>
>> * http://in.relation.to/Bloggers/HibernateORM500CR1Release
>> * https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR1
>>
>> There are a few things to notice here.  First, I think we can all agree
>> that the second looks considerably better.  Also, there is a lot to be said
>> for these being closely available from the source repo.
>
> I like this approach in general and I agree there is a certain merit in having
> the announcements in the source repo, BUT :-)
>
> We are very close now with the migration of in.relation.to to awestruct. In fact I
> was hoping we could do the migration within a couple of weeks. Using the awestruct
> based blog, we get markdown/ascidoc for writing the blog entries and also a blog
> which matches it its style the current hibernate.org website. It also means we can
> continue our practice of announcing on the blog. The release announcements make up
> a considerable part of the blog content, I fear moving them to GitHub will make our blog
> to appear stagnant.

+1
Not least, it's an extremely lengthy process to change the habits of
your user population to go look elsewhere,
I think that any move to a different URL - no matter how shiny the new
place - would be damaging.

Of course if we could post a link and some metadata on github releases
automatically as well, that would be nice.

Granted that with the style of the current blog platform it might not
have such a big population of readers, but we hope the new blog to be
better at that. At very least I think we need to keep the new feeds
alive, they are not only fetched directly by readers but also
aggregated by other platforms such as the very hibernate.org

>
> My vote is to push this blog migration through - now!

Looking forward to it! TBH I don't even remember how the drafts looked like..

-- Sanne

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

From emmanuel at hibernate.org  Thu May 28 09:07:11 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 28 May 2015 15:07:11 +0200
Subject: [hibernate-dev] Release announcements
In-Reply-To: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>
References: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>
Message-ID: <1238FDB0-A335-43DA-9966-F448406E04FB@hibernate.org>

The banner is indeed driven by RSS so we would lose that. Also push driven news persons would not go regularly to GitHub to see if anything is new.

I forgot with who I was discussing that but we do miss a list of the releases and their announcements. If the GitHub thing can be automated, that would be a nice complement to a regular blog announcement. It would complement nicely the new blog infra as you could reuse the same text and script that process.

On hosting distributions on GitHub, I still have a bitter taste when GitHub pulled the plug on release hosting the last time around. I don?t think we should trust them on this one.

Emmanuel

> On 28 May 2015, at 04:47, Steve Ebersole <steve at hibernate.org> wrote:
> 
> At the moment we write release announcements using in.relation.to and then
> announce in other mediums by posting that link.  We all agree (more or
> less) that the wiki editor and rendering on there leaves much to be desired.
> 
> Brett had mentioned a long time ago about GitHub and its release
> capabilities and tonight I went back and looked at them again.  I created a
> more descriptive release announcement in GitHub then its default of just
> using the tag message for this 5.0.0.CR1 release just to see how it worked
> out.  Here are the 2 links for comparison:
> 
> * http://in.relation.to/Bloggers/HibernateORM500CR1Release
> * https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR1
> 
> There are a few things to notice here.  First, I think we can all agree
> that the second looks considerably better.  Also, there is a lot to be said
> for these being closely available from the source repo.
> 
> Another thing to note is that the GitHub release has the ability to attach
> random zips and tgz.  I have not taken advantage of that as I felt bad
> uploading our 62 and 97 Mb release bundles here just for a PoC.  I do have
> a task for myself post 5.0 to re-think how we build these release
> bundles[1].  But ultimately whether it makes sens to attach them here comes
> down to whether we think SF and its FRS has any advantage.  I think
> download statistics will be the only discussion point there.
> 
> Anyway, moving forward I plan to move to this approach for release
> announcements.
> 
> The only sticky point is the sourcing for the banners on hibernate.org.
> What drives that?  RSS?
> 
> Thoughts?
> 
> [1] https://hibernate.atlassian.net/browse/HHH-9828
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From steve at hibernate.org  Thu May 28 09:33:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 08:33:16 -0500
Subject: [hibernate-dev] ORM and database testing
Message-ID: <CAFdSV9vDCoCndyx6QsbXazyoCt4TkJ9uq9=YfWPcydS=AkWp8g@mail.gmail.com>

Now that CR1 is out one of my tasks is to start setting up the database
specific jobs on CI.  Initially I will just work with MySQL and PostrgeSQL
(and maybe HSQLDB).

Part of this will be auditing how we do database testing (matrix plugin)
and what does/doesn't work there.  I definitely like the idea of "database
profiles".  Overall I am not sure that dynamically generating tasks
specific to each database profile was a great idea.  It was predicated on
the idea that I might want to run tests against all database profiles.  But
that simply has not been the case in practice to date.  I have to look
again at the complexity the actual matrix stuff adds.  If it is a lot of
complexity I might just remove that part and have this be driven by a
single build parameter (`gradle test -PdbProfile=mysql`, e.g.).

I'd also like to look at specific hooks for the profiles in terms of
pre-/post-events at the suite, class and test levels.  For example, we
might have the H2 profile set up pre-post hooks for the suite to manage the
database rather than each test building one itself.  This would have a lot
of benefits.  Presumably it would help speed up the build some.  It would
also work more closely to non-in-memory test builds and possibly help shake
out test problems in regards to db-object conflicts earlier.  Also, in
general we might decide to hook in after each class to drop schemas
(ultimately HHH-8451 is a better solution to both of these I think).

Anything else to consider here?

From sanne at hibernate.org  Thu May 28 09:44:15 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 28 May 2015 14:44:15 +0100
Subject: [hibernate-dev] ORM and database testing
In-Reply-To: <CAFdSV9vDCoCndyx6QsbXazyoCt4TkJ9uq9=YfWPcydS=AkWp8g@mail.gmail.com>
References: <CAFdSV9vDCoCndyx6QsbXazyoCt4TkJ9uq9=YfWPcydS=AkWp8g@mail.gmail.com>
Message-ID: <CAFm4XO1GdAhCqxnNsA-c03NhteGwL6+T+z++x0ddzVPqjZj9yA@mail.gmail.com>

+1
I particularly like the idea of having H2 start/stop like any other db.

Regarding profiles, rather than running the build with a single
profile in "maven style", would it not be feasible to have one build
iterate on each configuration set?
For example:

 gradle test -PdbProfiles=mysql,h2,mssql

I'd expect that to do a single compilation phase, then loop on the
tests 3 times with different settings as needed. Not sure how easy it
would be to get unified reports out of there, but we want to consider
*the* build successful when it passes all profiles, rather than having
to monitor the output of multiple builds (and all related email spam).
In an ideal evolution then maybe we would also be able to mark some
tests which are database independent to not be repeated at all.

Thanks,
Sanne


On 28 May 2015 at 14:33, Steve Ebersole <steve at hibernate.org> wrote:
> Now that CR1 is out one of my tasks is to start setting up the database
> specific jobs on CI.  Initially I will just work with MySQL and PostrgeSQL
> (and maybe HSQLDB).
>
> Part of this will be auditing how we do database testing (matrix plugin)
> and what does/doesn't work there.  I definitely like the idea of "database
> profiles".  Overall I am not sure that dynamically generating tasks
> specific to each database profile was a great idea.  It was predicated on
> the idea that I might want to run tests against all database profiles.  But
> that simply has not been the case in practice to date.  I have to look
> again at the complexity the actual matrix stuff adds.  If it is a lot of
> complexity I might just remove that part and have this be driven by a
> single build parameter (`gradle test -PdbProfile=mysql`, e.g.).
>
> I'd also like to look at specific hooks for the profiles in terms of
> pre-/post-events at the suite, class and test levels.  For example, we
> might have the H2 profile set up pre-post hooks for the suite to manage the
> database rather than each test building one itself.  This would have a lot
> of benefits.  Presumably it would help speed up the build some.  It would
> also work more closely to non-in-memory test builds and possibly help shake
> out test problems in regards to db-object conflicts earlier.  Also, in
> general we might decide to hook in after each class to drop schemas
> (ultimately HHH-8451 is a better solution to both of these I think).
>
> Anything else to consider here?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Thu May 28 10:06:16 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 09:06:16 -0500
Subject: [hibernate-dev] Release announcements
In-Reply-To: <1238FDB0-A335-43DA-9966-F448406E04FB@hibernate.org>
References: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>
	<1238FDB0-A335-43DA-9966-F448406E04FB@hibernate.org>
Message-ID: <CAFdSV9vgb0Q-mmxXYKKYSwhv+PC9G-8MuUOVZ+4ULz5isGBy5w@mail.gmail.com>

On Thu, May 28, 2015 at 8:07 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> The banner is indeed driven by RSS


I have not seen any RSS capability from the GitHub Release "system".



> so we would lose that.  Also push driven news persons would not go
> regularly to GitHub to see if anything is new.


That depends.  What we do today is to write the announcement in one place
and then announce in multiple places pointing to that one announcement.
That is still an option.  Just I am advocating writing the announcement in
GitHub rather than in Seam-wiki-text-whatnot.   We could very well write a
"Weblog Entry" (lol) on in.relation.to that links to the GitHub release.

The "next gen blog" has been "coming" for years.  That's not a dig at
anyone, just a simple point that I'd rather plan based on options I have
today rather than options that I will have at some indeterminate date.
Unless you can tell me definitively when the new blog system is going to be
available....


I forgot with who I was discussing that but we do miss a list of the
> releases and their announcements.


Yes, and no.  It depends on consistent tagging which I personally use for
ORM releases, but we have never really all agreed to across all projects.
But even then, the list is fugly[1] :)



> If the GitHub thing can be automated, that would be a nice complement to a
> regular blog announcement. It would complement nicely the new blog infra as
> you could reuse the same text and script that process.
>

I am actually contemplating *not* automating it.  It actually happens
automatically already.  By default it simply grabs the message you applied
t the tag as the description.  Essentially what happens is that a release
is automatically created for each tag.  You can edit that afterwards.  In
fact this is exactly what I did[2].  Compare that to a default release[3].
You could technically leverage the fact that it picks up the tag message to
provide the markdown.  But given that for ORM we manually tag anyway, it
really just makes sense to do that step through the GitHub release UI whcih
will also create the tag if you want.


>
> On hosting distributions on GitHub, I still have a bitter taste when
> GitHub pulled the plug on release hosting the last time around. I don?t
> think we should trust them on this one.


I am not tied to it.  We have other options for that anyway.  But having
one complete "picture" of the release is a very very very nice-to-have.
The release ymls in hibernate.org strive to be that, but just arent.


[1] http://in.relation.to/tag/Core+Release
[2] https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.CR1
[3] https://github.com/hibernate/hibernate-orm/releases/tag/5.0.0.Beta2

From steve at hibernate.org  Thu May 28 10:14:08 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 09:14:08 -0500
Subject: [hibernate-dev] ORM and database testing
In-Reply-To: <CAFm4XO1GdAhCqxnNsA-c03NhteGwL6+T+z++x0ddzVPqjZj9yA@mail.gmail.com>
References: <CAFdSV9vDCoCndyx6QsbXazyoCt4TkJ9uq9=YfWPcydS=AkWp8g@mail.gmail.com>
	<CAFm4XO1GdAhCqxnNsA-c03NhteGwL6+T+z++x0ddzVPqjZj9yA@mail.gmail.com>
Message-ID: <CAFdSV9uniRpOJbpaZv95jm8g9ekdwz_TFP3QkjWJu6JpFS3rjQ@mail.gmail.com>

On Thu, May 28, 2015 at 8:44 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> +1
> I particularly like the idea of having H2 start/stop like any other db.
>
> Regarding profiles, rather than running the build with a single
> profile in "maven style", would it not be feasible to have one build
> iterate on each configuration set?
> For example:
>
>  gradle test -PdbProfiles=mysql,h2,mssql
>
> I'd expect that to do a single compilation phase, then loop on the
> tests 3 times with different settings as needed. Not sure how easy it
> would be to get unified reports out of there, but we want to consider
> *the* build successful when it passes all profiles, rather than having
> to monitor the output of multiple builds (and all related email spam).
> In an ideal evolution then maybe we would also be able to mark some
> tests which are database independent to not be repeated at all.
>
> Thanks,
> Sanne


We have that today already today.  So yeah :)

The difference today is that my matrix plugin dynamically generates actual
tasks.  So assuming you had those profiles on your system you'd get dynamic
tasks: matrix_mysql, matrix_h2, matrix_mssql.  You'd also have a task
`matrix` that runs all of those.

The rub is that we actually do not leverage this today.  Today every single
build runs just one profile.  If we are going to allow running multiple
profiles at the same time, I personally think the matrix and dynamic tasks
are the better option.  So really I was more asking a question I guess
whether anyone plans on using that capability :)  Because to run just one
profile, the matrix add a lot of complexity that is probably just not
warranted.

From steve at hibernate.org  Thu May 28 10:23:59 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 09:23:59 -0500
Subject: [hibernate-dev] HCANN, AnnotationFactory and TCCL
In-Reply-To: <CAFm4XO3mwF2DN5p2VXhyUTf=cKNd8XzYue=pGLfws9EBvkB4DA@mail.gmail.com>
References: <CAFdSV9u4hpdy+iRRcHwuGt7x0FwHRmtd=tFpXL8Rf+Ve08R0LA@mail.gmail.com>
	<CAFm4XO3mwF2DN5p2VXhyUTf=cKNd8XzYue=pGLfws9EBvkB4DA@mail.gmail.com>
Message-ID: <CAFdSV9unenfwhUQU=Chu16EZPXzxKFohDnZk7rMnnE0odS1ROg@mail.gmail.com>

Ok, then everyone seems to be on board with the simple approach.  Awesome!
FWIW I'd have to imagine this is close to what the VM does for annotations
anyway.  So that's an extra win in my book.

On Thu, May 28, 2015 at 5:08 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

With that TCCL trick in place it seems it was possible to have the
> module actually use a set of annotations provided by the user, to
> override those (with same name) already provided by ORM. If that was
> meant as a "feature" I'd be glad to see it killed.
>

I think the "intent" was just non-intent tbh.  It just used TCCL rather
than allowing for specifying which ClassLoader to use because it was
"easier".  Any expectation beyond that *should* break imho.


The above approach seems nicer as you already have the Class,
> otherwise I'd prefer to see such helpers to always allow an explicit
> ClassLoader.
> I don't think you have to worry about ORM requiring new versions of
> HCANN occasionally, we all have to make changes to keep up anyway and
> a version upgrade is easy enough.
>

Well especially if we are  bumping the release family from 4.0 to 4.1


> We did have a problem with recent "planet alignment" efforts of
> versions on other platforms though, which was caused by a significant
> semantic change of a similar classloader improvement, and some people
> had upgraded the micro version of HCANN without enough testing. As far
> as I remember the dangerous upgrade was the upgrade from HCANN
> 4.0.1.Final to 4.0.5.Final, which breaks Hibernate ORM 4.2 within the
> app server.
>
> In retrospective we should have increased the minor version of HCANN,
> so maybe you could do that now when fixing the TCCL issue?
>

Yep, I probably should have done that back when.  I will do it now.  4.1?

From sanne at hibernate.org  Thu May 28 10:32:54 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 28 May 2015 15:32:54 +0100
Subject: [hibernate-dev] HCANN, AnnotationFactory and TCCL
In-Reply-To: <CAFdSV9unenfwhUQU=Chu16EZPXzxKFohDnZk7rMnnE0odS1ROg@mail.gmail.com>
References: <CAFdSV9u4hpdy+iRRcHwuGt7x0FwHRmtd=tFpXL8Rf+Ve08R0LA@mail.gmail.com>
	<CAFm4XO3mwF2DN5p2VXhyUTf=cKNd8XzYue=pGLfws9EBvkB4DA@mail.gmail.com>
	<CAFdSV9unenfwhUQU=Chu16EZPXzxKFohDnZk7rMnnE0odS1ROg@mail.gmail.com>
Message-ID: <CAFm4XO1DN6zGK7ABV_ACS7cGSCqbFDMdvfdeE2bGVN_EH=2tyA@mail.gmail.com>

What about making it 5.0 to align them all?

Search would soon need a 6.0, I'm resisting as much as possible as we
had several signs that people mostly ignore our reminders and expect
the components to be aligned on the major number. Therefore we expect
Search to upgrade to ORM 5 in a minor version.

On 28 May 2015 at 15:23, Steve Ebersole <steve at hibernate.org> wrote:
> Ok, then everyone seems to be on board with the simple approach.  Awesome!
> FWIW I'd have to imagine this is close to what the VM does for annotations
> anyway.  So that's an extra win in my book.
>
> On Thu, May 28, 2015 at 5:08 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> With that TCCL trick in place it seems it was possible to have the
>> module actually use a set of annotations provided by the user, to
>> override those (with same name) already provided by ORM. If that was
>> meant as a "feature" I'd be glad to see it killed.
>
>
> I think the "intent" was just non-intent tbh.  It just used TCCL rather than
> allowing for specifying which ClassLoader to use because it was "easier".
> Any expectation beyond that *should* break imho.
>
>
>> The above approach seems nicer as you already have the Class,
>> otherwise I'd prefer to see such helpers to always allow an explicit
>> ClassLoader.
>> I don't think you have to worry about ORM requiring new versions of
>> HCANN occasionally, we all have to make changes to keep up anyway and
>> a version upgrade is easy enough.
>
>
> Well especially if we are  bumping the release family from 4.0 to 4.1
>
>>
>> We did have a problem with recent "planet alignment" efforts of
>> versions on other platforms though, which was caused by a significant
>> semantic change of a similar classloader improvement, and some people
>> had upgraded the micro version of HCANN without enough testing. As far
>> as I remember the dangerous upgrade was the upgrade from HCANN
>> 4.0.1.Final to 4.0.5.Final, which breaks Hibernate ORM 4.2 within the
>> app server.
>>
>> In retrospective we should have increased the minor version of HCANN,
>> so maybe you could do that now when fixing the TCCL issue?
>
>
> Yep, I probably should have done that back when.  I will do it now.  4.1?
>

From steve at hibernate.org  Thu May 28 10:51:30 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 09:51:30 -0500
Subject: [hibernate-dev] HCANN, AnnotationFactory and TCCL
In-Reply-To: <CAFm4XO1DN6zGK7ABV_ACS7cGSCqbFDMdvfdeE2bGVN_EH=2tyA@mail.gmail.com>
References: <CAFdSV9u4hpdy+iRRcHwuGt7x0FwHRmtd=tFpXL8Rf+Ve08R0LA@mail.gmail.com>
	<CAFm4XO3mwF2DN5p2VXhyUTf=cKNd8XzYue=pGLfws9EBvkB4DA@mail.gmail.com>
	<CAFdSV9unenfwhUQU=Chu16EZPXzxKFohDnZk7rMnnE0odS1ROg@mail.gmail.com>
	<CAFm4XO1DN6zGK7ABV_ACS7cGSCqbFDMdvfdeE2bGVN_EH=2tyA@mail.gmail.com>
Message-ID: <CAFdSV9uZB8uWkrBFpbVWEZAPem48Hy0KBrF+GrPy+SFozUtNRw@mail.gmail.com>

Sold!  https://hibernate.atlassian.net/browse/HCANN/fixforversion/20151

On Thu, May 28, 2015 at 9:32 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> What about making it 5.0 to align them all?
>
> Search would soon need a 6.0, I'm resisting as much as possible as we
> had several signs that people mostly ignore our reminders and expect
> the components to be aligned on the major number. Therefore we expect
> Search to upgrade to ORM 5 in a minor version.
>
> On 28 May 2015 at 15:23, Steve Ebersole <steve at hibernate.org> wrote:
> > Ok, then everyone seems to be on board with the simple approach.
> Awesome!
> > FWIW I'd have to imagine this is close to what the VM does for
> annotations
> > anyway.  So that's an extra win in my book.
> >
> > On Thu, May 28, 2015 at 5:08 AM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >
> >> With that TCCL trick in place it seems it was possible to have the
> >> module actually use a set of annotations provided by the user, to
> >> override those (with same name) already provided by ORM. If that was
> >> meant as a "feature" I'd be glad to see it killed.
> >
> >
> > I think the "intent" was just non-intent tbh.  It just used TCCL rather
> than
> > allowing for specifying which ClassLoader to use because it was "easier".
> > Any expectation beyond that *should* break imho.
> >
> >
> >> The above approach seems nicer as you already have the Class,
> >> otherwise I'd prefer to see such helpers to always allow an explicit
> >> ClassLoader.
> >> I don't think you have to worry about ORM requiring new versions of
> >> HCANN occasionally, we all have to make changes to keep up anyway and
> >> a version upgrade is easy enough.
> >
> >
> > Well especially if we are  bumping the release family from 4.0 to 4.1
> >
> >>
> >> We did have a problem with recent "planet alignment" efforts of
> >> versions on other platforms though, which was caused by a significant
> >> semantic change of a similar classloader improvement, and some people
> >> had upgraded the micro version of HCANN without enough testing. As far
> >> as I remember the dangerous upgrade was the upgrade from HCANN
> >> 4.0.1.Final to 4.0.5.Final, which breaks Hibernate ORM 4.2 within the
> >> app server.
> >>
> >> In retrospective we should have increased the minor version of HCANN,
> >> so maybe you could do that now when fixing the TCCL issue?
> >
> >
> > Yep, I probably should have done that back when.  I will do it now.  4.1?
> >
>

From emmanuel at hibernate.org  Thu May 28 11:28:15 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 28 May 2015 17:28:15 +0200
Subject: [hibernate-dev] Release announcements
In-Reply-To: <CAFdSV9vgb0Q-mmxXYKKYSwhv+PC9G-8MuUOVZ+4ULz5isGBy5w@mail.gmail.com>
References: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>
	<1238FDB0-A335-43DA-9966-F448406E04FB@hibernate.org>
	<CAFdSV9vgb0Q-mmxXYKKYSwhv+PC9G-8MuUOVZ+4ULz5isGBy5w@mail.gmail.com>
Message-ID: <B53CFB6A-B3D2-430D-A7A3-DCA2EE961F67@hibernate.org>


> On 28 May 2015, at 16:06, Steve Ebersole <steve at hibernate.org> wrote:
> 
> The "next gen blog" has been "coming" for years.  That's not a dig at anyone, just a simple point that I'd rather plan based on options I have today rather than options that I will have at some indeterminate date.  Unless you can tell me definitively when the new blog system is going to be available....
> 

It?s there alright https://github.com/hibernate/in.relation.to and we have a set of opened issues on WEBSITE to bring it to market. Looks like we are ~ 4 weeks worth of effort from a first version that is good to go. We did make some good progress ~ 2 months ago. We have a window of opportunity somewhere in august and one somewhere in October (we do work on ?content and infra? by slices).

So not ?next week?, but not millions of ORM releases in the future either.

From steve at hibernate.org  Thu May 28 11:58:20 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 10:58:20 -0500
Subject: [hibernate-dev] HCANN, AnnotationFactory and TCCL
In-Reply-To: <CAFdSV9uZB8uWkrBFpbVWEZAPem48Hy0KBrF+GrPy+SFozUtNRw@mail.gmail.com>
References: <CAFdSV9u4hpdy+iRRcHwuGt7x0FwHRmtd=tFpXL8Rf+Ve08R0LA@mail.gmail.com>
	<CAFm4XO3mwF2DN5p2VXhyUTf=cKNd8XzYue=pGLfws9EBvkB4DA@mail.gmail.com>
	<CAFdSV9unenfwhUQU=Chu16EZPXzxKFohDnZk7rMnnE0odS1ROg@mail.gmail.com>
	<CAFm4XO1DN6zGK7ABV_ACS7cGSCqbFDMdvfdeE2bGVN_EH=2tyA@mail.gmail.com>
	<CAFdSV9uZB8uWkrBFpbVWEZAPem48Hy0KBrF+GrPy+SFozUtNRw@mail.gmail.com>
Message-ID: <CAFdSV9sXNPCHZt9qFmqd2uKcb7bSJQdCqj2uWpSRE=_b4GznuQ@mail.gmail.com>

Wow.  There are so many open issues against HCANN...

On Thu, May 28, 2015 at 9:51 AM, Steve Ebersole <steve at hibernate.org> wrote:

> Sold!  https://hibernate.atlassian.net/browse/HCANN/fixforversion/20151
>
> On Thu, May 28, 2015 at 9:32 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>
>> What about making it 5.0 to align them all?
>>
>> Search would soon need a 6.0, I'm resisting as much as possible as we
>> had several signs that people mostly ignore our reminders and expect
>> the components to be aligned on the major number. Therefore we expect
>> Search to upgrade to ORM 5 in a minor version.
>>
>> On 28 May 2015 at 15:23, Steve Ebersole <steve at hibernate.org> wrote:
>> > Ok, then everyone seems to be on board with the simple approach.
>> Awesome!
>> > FWIW I'd have to imagine this is close to what the VM does for
>> annotations
>> > anyway.  So that's an extra win in my book.
>> >
>> > On Thu, May 28, 2015 at 5:08 AM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >
>> >> With that TCCL trick in place it seems it was possible to have the
>> >> module actually use a set of annotations provided by the user, to
>> >> override those (with same name) already provided by ORM. If that was
>> >> meant as a "feature" I'd be glad to see it killed.
>> >
>> >
>> > I think the "intent" was just non-intent tbh.  It just used TCCL rather
>> than
>> > allowing for specifying which ClassLoader to use because it was
>> "easier".
>> > Any expectation beyond that *should* break imho.
>> >
>> >
>> >> The above approach seems nicer as you already have the Class,
>> >> otherwise I'd prefer to see such helpers to always allow an explicit
>> >> ClassLoader.
>> >> I don't think you have to worry about ORM requiring new versions of
>> >> HCANN occasionally, we all have to make changes to keep up anyway and
>> >> a version upgrade is easy enough.
>> >
>> >
>> > Well especially if we are  bumping the release family from 4.0 to 4.1
>> >
>> >>
>> >> We did have a problem with recent "planet alignment" efforts of
>> >> versions on other platforms though, which was caused by a significant
>> >> semantic change of a similar classloader improvement, and some people
>> >> had upgraded the micro version of HCANN without enough testing. As far
>> >> as I remember the dangerous upgrade was the upgrade from HCANN
>> >> 4.0.1.Final to 4.0.5.Final, which breaks Hibernate ORM 4.2 within the
>> >> app server.
>> >>
>> >> In retrospective we should have increased the minor version of HCANN,
>> >> so maybe you could do that now when fixing the TCCL issue?
>> >
>> >
>> > Yep, I probably should have done that back when.  I will do it now.
>> 4.1?
>> >
>>
>
>

From steve at hibernate.org  Thu May 28 12:33:22 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 11:33:22 -0500
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
Message-ID: <CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>

Anyone have any input here?  Or should I just start scheduling them how I
want?

On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole <steve at hibernate.org> wrote:

> Now that 5.0 is settling down I wanted to start planning where we go from
> here in terms of feature development and schedule/releases.
>
> Here is my high-level list of features/work:
> * rework SQL generation & HQL parser
> * change JDBC extraction to work by position, rather than alias (reworking
> SQL generation is a prerequisite)
> * rework annotation binding (Jandex, etc)
> * extended orm.xml, deprecate hbm.xml
> * discriminator-based multi-tenancy
> * port Hibernate Criteria constructs to JPA criteria, begin deprecation of
> Hibernate Criteria
> * extend JPA criteria API with fluent support
> * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
> * merging hibernate-entitymanager into hibernate-core
> * continue to fill out bytecode enhancement capabilities
>
> Some of these are more involved than others.  The task for re-writing SQL
> generation is a HUGE undertaking, but also has many huge benefits.
> Re-writing annotation binding is another huge undertaking, but again with
> many benefits.
>
> Any others we should add to the list here?
>
> And then we can work on scheduling them.
>

From steve at hibernate.org  Thu May 28 14:04:52 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 13:04:52 -0500
Subject: [hibernate-dev] Release announcements
In-Reply-To: <B53CFB6A-B3D2-430D-A7A3-DCA2EE961F67@hibernate.org>
References: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>
	<1238FDB0-A335-43DA-9966-F448406E04FB@hibernate.org>
	<CAFdSV9vgb0Q-mmxXYKKYSwhv+PC9G-8MuUOVZ+4ULz5isGBy5w@mail.gmail.com>
	<B53CFB6A-B3D2-430D-A7A3-DCA2EE961F67@hibernate.org>
Message-ID: <CAFdSV9vZRivtqsSPKBnhyxMHY=knUjxhRaNfBPvCQads_GpwsQ@mail.gmail.com>

So even though GitHub does not support RSS per-se, it does have a lot of
JSON support, including around these releases, including even creating them!

On Thu, May 28, 2015 at 10:28 AM, Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

>
> On 28 May 2015, at 16:06, Steve Ebersole <steve at hibernate.org> wrote:
>
> The "next gen blog" has been "coming" for years.  That's not a dig at
> anyone, just a simple point that I'd rather plan based on options I have
> today rather than options that I will have at some indeterminate date.
> Unless you can tell me definitively when the new blog system is going to be
> available....
>
>
> It?s there alright https://github.com/hibernate/in.relation.to and we
> have a set of opened issues on WEBSITE to bring it to market. Looks like we
> are ~ 4 weeks worth of effort from a first version that is good to go. We
> did make some good progress ~ 2 months ago. We have a window of opportunity
> somewhere in august and one somewhere in October (we do work on ?content
> and infra? by slices).
>
> So not ?next week?, but not millions of ORM releases in the future either.
>

From hardy at hibernate.org  Thu May 28 14:24:08 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 28 May 2015 20:24:08 +0200
Subject: [hibernate-dev] Release announcements
In-Reply-To: <B53CFB6A-B3D2-430D-A7A3-DCA2EE961F67@hibernate.org>
References: <CAFdSV9snN91z0Xgd+zeOgAU-S_tqKFakDW6do+uDnWjQ3rSUnw@mail.gmail.com>
	<1238FDB0-A335-43DA-9966-F448406E04FB@hibernate.org>
	<CAFdSV9vgb0Q-mmxXYKKYSwhv+PC9G-8MuUOVZ+4ULz5isGBy5w@mail.gmail.com>
	<B53CFB6A-B3D2-430D-A7A3-DCA2EE961F67@hibernate.org>
Message-ID: <20150528182408.GG35093@Nineveh.lan>

On Thu, May 28, 2015 at 05:28:15PM +0200, Emmanuel Bernard wrote:
> 
> > On 28 May 2015, at 16:06, Steve Ebersole <steve at hibernate.org> wrote:
> > 
> > The "next gen blog" has been "coming" for years.  That's not a dig at anyone, just a simple point that I'd rather plan based on options I have today rather than options that I will have at some indeterminate date.  Unless you can tell me definitively when the new blog system is going to be available....
> > 
> 
> It?s there alright https://github.com/hibernate/in.relation.to and we have a set of opened issues on WEBSITE to bring it to market. Looks like we are ~ 4 weeks worth of effort from a first version that is good to go. We did make some good progress ~ 2 months ago. We have a window of opportunity somewhere in august and one somewhere in October (we do work on ?content and infra? by slices).
> 
> So not ?next week?, but not millions of ORM releases in the future either.

My take on this is that we should finish it now. I know we made a "plan", but plans which are so rigid that they
cannot be adjusted to changing circumstances are imo no good plans. IMO the website should have been in the focus
of this iteration of "content and infra", but afaict nothing happened. I understand Steve's point of view 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/20150528/6e9a73c1/attachment-0001.bin 

From gbadner at redhat.com  Thu May 28 15:01:22 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 28 May 2015 15:01:22 -0400 (EDT)
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <20150528084205.GB35093@Nineveh.lan>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
Message-ID: <1057163851.6278953.1432839682190.JavaMail.zimbra@redhat.com>

Here is my 2 cents. 

I find it helpful that the changelog contains all jiras for all releases that feed into a particular version. It makes it clear when later branches were branched off. 

This is particularly helpful when we are maintaining multiple branches and commits are being backported to different branches.
 
My preference would be to truncate the changelogs to the point at which 4.2, 4.3, and 5 branches diverge.

For master: include everything starting form 4.3.6.Final (the last version in master changelog that is also included in 4.3 changelog).

For 4.3: include everything starting from 4.1.5.SP1 (the last version in 4.3 changelog that is also included in 4.2 changelog).

For 4.2: leave changelog.txt as is.

This helps me track down when things are amiss (e.g., for regressions). I know there are other ways to investigate things related to misplaced/forgotten commits, but the changelogs have been a good starting point for me.

Gail
 

----- Original Message -----
> From: "Hardy Ferentschik" <hardy at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Thursday, May 28, 2015 1:42:05 AM
> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> 
> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > +1 from me.  Although, on the other hand, do we really need to keep
> > maintaining that to begin with?  I guess I never thought simply having
> > users go to the JIRA release notes was a big deal.  Just my $.02.
> 
> Same for me on both counts, the proposed handling of changelog.txt as well as
> Brett's comment regarding the usefulness of this file altogether.
> 
> --Hardy
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From brmeyer at redhat.com  Thu May 28 15:04:11 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Thu, 28 May 2015 15:04:11 -0400 (EDT)
Subject: [hibernate-dev] hibernate-osgi JPA bootstrap & classloader
In-Reply-To: <CAFdSV9t7Z20UpFo3Drf0J0_hJjduxsnNv7_QU0nuxdD+Oq4wCg@mail.gmail.com>
References: <CAFdSV9vE63Yw2HUONhco1fFm2-4wHGr+3F70cCxAsYVz48CMiw@mail.gmail.com>
	<179957479.5879349.1432655053703.JavaMail.zimbra@redhat.com>
	<CAFdSV9v4jBh4wJkn39-r4JL61DjqMaPM7ajFcmZ4xYme8bP_=A@mail.gmail.com>
	<1741139628.6056252.1432671977583.JavaMail.zimbra@redhat.com>
	<CAFdSV9s+4b7is6CKsS7_9LE8sLtRMVO+JNJdS3JzO13aObYaMA@mail.gmail.com>
	<591309801.7224156.1432778975070.JavaMail.zimbra@redhat.com>
	<CAFdSV9t7Z20UpFo3Drf0J0_hJjduxsnNv7_QU0nuxdD+Oq4wCg@mail.gmail.com>
Message-ID: <697774531.8049780.1432839851943.JavaMail.zimbra@redhat.com>

> > > Is that the best way to know when TransactionManagers and DataSources
> > come
> > > and go too?  Or is there a more specific concept for listening to an
> > "OSGi
> > > service"?
> >
> > At least for TransactionManagers, yes, the BundleListener is probably the
> > best approach.  I'm not aware of a more specific way beyond that, but I'm
> > not 100%.  Honestly not sure about the DataSource -- can't remember if most
> > containers automatically expose that or not.
> >
> 
> But I would have to know the bundle that TransactionManager comes from in
> order to listener to it, no?

Doable.  In OsgiServiceUtil, look at its use of ServiceTracker.  Instead of ServiceTracker#getServices, we'd use ServiceTracker#getServiceReferences.  From the returned ServiceReference, we can get both the actual service impl, as well as the Bundle that provides it.

From steve at hibernate.org  Thu May 28 15:58:42 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 14:58:42 -0500
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <1057163851.6278953.1432839682190.JavaMail.zimbra@redhat.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
	<1057163851.6278953.1432839682190.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9tJHH7AoWcPrCK7LESohVMa48zzOHwxrtESmcyTQavfrg@mail.gmail.com>

I don't like the idea of a 5.0 change log having 4.x issues.  It kind of
defeats the whole purpose.

As a compromise, I can see noting the last previous family release in the
changlog.  Again using 5.0 as an example, make a note that 5.0 development
started after 4.3.6
On May 28, 2015 2:01 PM, "Gail Badner" <gbadner at redhat.com> wrote:

> Here is my 2 cents.
>
> I find it helpful that the changelog contains all jiras for all releases
> that feed into a particular version. It makes it clear when later branches
> were branched off.
>
> This is particularly helpful when we are maintaining multiple branches and
> commits are being backported to different branches.
>
> My preference would be to truncate the changelogs to the point at which
> 4.2, 4.3, and 5 branches diverge.
>
> For master: include everything starting form 4.3.6.Final (the last version
> in master changelog that is also included in 4.3 changelog).
>
> For 4.3: include everything starting from 4.1.5.SP1 (the last version in
> 4.3 changelog that is also included in 4.2 changelog).
>
> For 4.2: leave changelog.txt as is.
>
> This helps me track down when things are amiss (e.g., for regressions). I
> know there are other ways to investigate things related to
> misplaced/forgotten commits, but the changelogs have been a good starting
> point for me.
>
> Gail
>
>
> ----- Original Message -----
> > From: "Hardy Ferentschik" <hardy at hibernate.org>
> > To: "Brett Meyer" <brmeyer at redhat.com>
> > Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> > Sent: Thursday, May 28, 2015 1:42:05 AM
> > Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> >
> > On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > > +1 from me.  Although, on the other hand, do we really need to keep
> > > maintaining that to begin with?  I guess I never thought simply having
> > > users go to the JIRA release notes was a big deal.  Just my $.02.
> >
> > Same for me on both counts, the proposed handling of changelog.txt as
> well as
> > Brett's comment regarding the usefulness of this file altogether.
> >
> > --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 gbadner at redhat.com  Thu May 28 16:08:40 2015
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 28 May 2015 16:08:40 -0400 (EDT)
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <CAFdSV9tJHH7AoWcPrCK7LESohVMa48zzOHwxrtESmcyTQavfrg@mail.gmail.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
	<1057163851.6278953.1432839682190.JavaMail.zimbra@redhat.com>
	<CAFdSV9tJHH7AoWcPrCK7LESohVMa48zzOHwxrtESmcyTQavfrg@mail.gmail.com>
Message-ID: <589866540.6313066.1432843720858.JavaMail.zimbra@redhat.com>

+1 to listing the the version prior to branching.

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>, "Hardy Ferentschik" <hardy at hibernate.org>
> Sent: Thursday, May 28, 2015 12:58:42 PM
> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> 
> I don't like the idea of a 5.0 change log having 4.x issues.  It kind of
> defeats the whole purpose.
> 
> As a compromise, I can see noting the last previous family release in the
> changlog.  Again using 5.0 as an example, make a note that 5.0 development
> started after 4.3.6
> On May 28, 2015 2:01 PM, "Gail Badner" <gbadner at redhat.com> wrote:
> 
> > Here is my 2 cents.
> >
> > I find it helpful that the changelog contains all jiras for all releases
> > that feed into a particular version. It makes it clear when later branches
> > were branched off.
> >
> > This is particularly helpful when we are maintaining multiple branches and
> > commits are being backported to different branches.
> >
> > My preference would be to truncate the changelogs to the point at which
> > 4.2, 4.3, and 5 branches diverge.
> >
> > For master: include everything starting form 4.3.6.Final (the last version
> > in master changelog that is also included in 4.3 changelog).
> >
> > For 4.3: include everything starting from 4.1.5.SP1 (the last version in
> > 4.3 changelog that is also included in 4.2 changelog).
> >
> > For 4.2: leave changelog.txt as is.
> >
> > This helps me track down when things are amiss (e.g., for regressions). I
> > know there are other ways to investigate things related to
> > misplaced/forgotten commits, but the changelogs have been a good starting
> > point for me.
> >
> > Gail
> >
> >
> > ----- Original Message -----
> > > From: "Hardy Ferentschik" <hardy at hibernate.org>
> > > To: "Brett Meyer" <brmeyer at redhat.com>
> > > Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> > > Sent: Thursday, May 28, 2015 1:42:05 AM
> > > Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> > >
> > > On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > > > +1 from me.  Although, on the other hand, do we really need to keep
> > > > maintaining that to begin with?  I guess I never thought simply having
> > > > users go to the JIRA release notes was a big deal.  Just my $.02.
> > >
> > > Same for me on both counts, the proposed handling of changelog.txt as
> > well as
> > > Brett's comment regarding the usefulness of this file altogether.
> > >
> > > --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 steve at hibernate.org  Thu May 28 21:01:37 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 28 May 2015 20:01:37 -0500
Subject: [hibernate-dev] Release dist bundles
Message-ID: <CAFdSV9tUV978Cnfjmsg_WCx8YyNMyJSr4TeT6-RRcFzY1UpDQg@mail.gmail.com>

Appreciate any thoughts... https://hibernate.atlassian.net/browse/HHH-9828

From emmanuel at hibernate.org  Fri May 29 03:15:51 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 29 May 2015 09:15:51 +0200
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <20150528084205.GB35093@Nineveh.lan>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
Message-ID: <21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>


> On 28 May 2015, at 10:42, Hardy Ferentschik <hardy at hibernate.org> wrote:
> 
> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
>> +1 from me.  Although, on the other hand, do we really need to keep maintaining that to begin with?  I guess I never thought simply having users go to the JIRA release notes was a big deal.  Just my $.02.
> 
> Same for me on both counts, the proposed handling of changelog.txt as well as Brett's comment regarding the usefulness of this file altogether.

A more frequent than I thought usage of changelog vs JIRA is a mix of Ctrl+F + quick scan to know what has changed in a library or know what is affecting me. JIRA is not the most intuitive UI in the universe. With allt he bug statuses, the various intermediary releases to select etc, nothing beats changelog.txt.

From emmanuel at hibernate.org  Fri May 29 03:58:11 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 29 May 2015 09:58:11 +0200
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
	<CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>
Message-ID: <C780CA88-895A-49E2-A21C-FACA5DA47E00@hibernate.org>

My favs are

* discriminator-based multi-tenancy
* extend JPA criteria API with fluent support (does that mean embracing something like http://www.querydsl.com ? Os is that something different?
* rework SQL generation & HQL parser



> On 28 May 2015, at 18:33, Steve Ebersole <steve at hibernate.org> wrote:
> 
> Anyone have any input here?  Or should I just start scheduling them how I
> want?
> 
> On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole <steve at hibernate.org> wrote:
> 
>> Now that 5.0 is settling down I wanted to start planning where we go from
>> here in terms of feature development and schedule/releases.
>> 
>> Here is my high-level list of features/work:
>> * rework SQL generation & HQL parser
>> * change JDBC extraction to work by position, rather than alias (reworking
>> SQL generation is a prerequisite)
>> * rework annotation binding (Jandex, etc)
>> * extended orm.xml, deprecate hbm.xml
>> * discriminator-based multi-tenancy
>> * port Hibernate Criteria constructs to JPA criteria, begin deprecation of
>> Hibernate Criteria
>> * extend JPA criteria API with fluent support
>> * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
>> * merging hibernate-entitymanager into hibernate-core
>> * continue to fill out bytecode enhancement capabilities
>> 
>> Some of these are more involved than others.  The task for re-writing SQL
>> generation is a HUGE undertaking, but also has many huge benefits.
>> Re-writing annotation binding is another huge undertaking, but again with
>> many benefits.
>> 
>> Any others we should add to the list here?
>> 
>> And then we can work on scheduling them.
>> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From emmanuel at hibernate.org  Fri May 29 04:07:51 2015
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 29 May 2015 10:07:51 +0200
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <C780CA88-895A-49E2-A21C-FACA5DA47E00@hibernate.org>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
	<CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>
	<C780CA88-895A-49E2-A21C-FACA5DA47E00@hibernate.org>
Message-ID: <F977C829-81E1-44D3-9F19-48B2B00DBCAC@hibernate.org>

Also (thinking outloud).

Maybe planning 5.1 5.2 5.x as a savant dosage of:

- a focused and useful new feature that users tend to like (discriminator-based multi-tenancy, fluent criteria API, ?)
- a performance focused feature (position rather than alias usage in JDBC)
- a longer term work plan which might span several minors to be achieved (SQL generation & hQL parser, ?)

One of each per 5.x might be interesting to explore.

> On 29 May 2015, at 09:58, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> My favs are
> 
> * discriminator-based multi-tenancy
> * extend JPA criteria API with fluent support (does that mean embracing something like http://www.querydsl.com ? Os is that something different?
> * rework SQL generation & HQL parser
> 
> 
> 
>> On 28 May 2015, at 18:33, Steve Ebersole <steve at hibernate.org> wrote:
>> 
>> Anyone have any input here?  Or should I just start scheduling them how I
>> want?
>> 
>> On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole <steve at hibernate.org> wrote:
>> 
>>> Now that 5.0 is settling down I wanted to start planning where we go from
>>> here in terms of feature development and schedule/releases.
>>> 
>>> Here is my high-level list of features/work:
>>> * rework SQL generation & HQL parser
>>> * change JDBC extraction to work by position, rather than alias (reworking
>>> SQL generation is a prerequisite)
>>> * rework annotation binding (Jandex, etc)
>>> * extended orm.xml, deprecate hbm.xml
>>> * discriminator-based multi-tenancy
>>> * port Hibernate Criteria constructs to JPA criteria, begin deprecation of
>>> Hibernate Criteria
>>> * extend JPA criteria API with fluent support
>>> * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
>>> * merging hibernate-entitymanager into hibernate-core
>>> * continue to fill out bytecode enhancement capabilities
>>> 
>>> Some of these are more involved than others.  The task for re-writing SQL
>>> generation is a HUGE undertaking, but also has many huge benefits.
>>> Re-writing annotation binding is another huge undertaking, but again with
>>> many benefits.
>>> 
>>> Any others we should add to the list here?
>>> 
>>> And then we can work on scheduling them.
>>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



From mih_vlad at yahoo.com  Fri May 29 04:17:28 2015
From: mih_vlad at yahoo.com (Mihalcea Vlad)
Date: Fri, 29 May 2015 08:17:28 +0000 (UTC)
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <F977C829-81E1-44D3-9F19-48B2B00DBCAC@hibernate.org>
References: <F977C829-81E1-44D3-9F19-48B2B00DBCAC@hibernate.org>
Message-ID: <364084706.989674.1432887448039.JavaMail.yahoo@mail.yahoo.com>

>From a performance perspective, I'm glad we'll be able to override the EAGER fetching on a query-basis. We could have an UNFETCH directive to do the opposite of the current FETCH one.

The bytecode enhancement dirty-checking is also a plus.
?Vlad
 


     On Friday, May 29, 2015 11:09 AM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
   

 Also (thinking outloud).

Maybe planning 5.1 5.2 5.x as a savant dosage of:

- a focused and useful new feature that users tend to like (discriminator-based multi-tenancy, fluent criteria API, ?)
- a performance focused feature (position rather than alias usage in JDBC)
- a longer term work plan which might span several minors to be achieved (SQL generation & hQL parser, ?)

One of each per 5.x might be interesting to explore.

> On 29 May 2015, at 09:58, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
> My favs are
> 
> * discriminator-based multi-tenancy
> * extend JPA criteria API with fluent support (does that mean embracing something like http://www.querydsl.com ? Os is that something different?
> * rework SQL generation & HQL parser
> 
> 
> 
>> On 28 May 2015, at 18:33, Steve Ebersole <steve at hibernate.org> wrote:
>> 
>> Anyone have any input here?? Or should I just start scheduling them how I
>> want?
>> 
>> On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole <steve at hibernate.org> wrote:
>> 
>>> Now that 5.0 is settling down I wanted to start planning where we go from
>>> here in terms of feature development and schedule/releases.
>>> 
>>> Here is my high-level list of features/work:
>>> * rework SQL generation & HQL parser
>>> * change JDBC extraction to work by position, rather than alias (reworking
>>> SQL generation is a prerequisite)
>>> * rework annotation binding (Jandex, etc)
>>> * extended orm.xml, deprecate hbm.xml
>>> * discriminator-based multi-tenancy
>>> * port Hibernate Criteria constructs to JPA criteria, begin deprecation of
>>> Hibernate Criteria
>>> * extend JPA criteria API with fluent support
>>> * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
>>> * merging hibernate-entitymanager into hibernate-core
>>> * continue to fill out bytecode enhancement capabilities
>>> 
>>> Some of these are more involved than others.? The task for re-writing SQL
>>> generation is a HUGE undertaking, but also has many huge benefits.
>>> Re-writing annotation binding is another huge undertaking, but again with
>>> many benefits.
>>> 
>>> Any others we should add to the list here?
>>> 
>>> And then we can work on scheduling them.
>>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.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  Fri May 29 06:22:13 2015
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 29 May 2015 12:22:13 +0200
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
	<CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>
Message-ID: <20150529102213.GB43402@Nineveh.lan>

On Thu, May 28, 2015 at 11:33:22AM -0500, Steve Ebersole wrote:
> Anyone have any input here?  Or should I just start scheduling them how I
> want?

I think all goals sound good. I would say schedule as you seem fit, maybe 
with a focus of giving users something tangible asap (a bit of what Emmanuel 
says).

--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/20150529/5bcf7f54/attachment.bin 

From sanne at hibernate.org  Fri May 29 06:53:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 29 May 2015 11:53:47 +0100
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <20150529102213.GB43402@Nineveh.lan>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
	<CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>
	<20150529102213.GB43402@Nineveh.lan>
Message-ID: <CAFm4XO1-DX44N0YEJnJdN5F-_BP8xgKqVn8jVY2cnPAz0JqVrA@mail.gmail.com>

I agree as well :)

Just to add a minor twist:
 - the override to lazy from eager would be useful to Search; skipping
fields completely as an extra bonus (something I think ORM can't do at
all - for good reasons when it comes to end user API - but again
something Search would benefit from and not expose to users).
 - since I'm currently exploring the 2nd level cache keys and the
persistence context keys again, it's getting clear (again as we
discussed this before) to potentially use a different data structure
to hold the persistence context.

But neither is urgent, I'd prefer you to schedule things to minimize
overall effort (maximize overall throughput over latency of any of
these).

On "position rather than alias usage in JDBC": I was looking forward
for that as well. Wasn't it part of the 5.0 schedule? I thought it was
done.

Sanne


On 29 May 2015 at 11:22, Hardy Ferentschik <hardy at hibernate.org> wrote:
> On Thu, May 28, 2015 at 11:33:22AM -0500, Steve Ebersole wrote:
>> Anyone have any input here?  Or should I just start scheduling them how I
>> want?
>
> I think all goals sound good. I would say schedule as you seem fit, maybe
> with a focus of giving users something tangible asap (a bit of what Emmanuel
> says).
>
> --Hardy
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From sanne at hibernate.org  Fri May 29 06:59:47 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 29 May 2015 11:59:47 +0100
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
	<21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>
Message-ID: <CAFm4XO2ALBrxwZYA_cbcCN3uWgwFDUPmdt+woYnu9feCAt9REA@mail.gmail.com>

On 29 May 2015 at 08:15, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> On 28 May 2015, at 10:42, Hardy Ferentschik <hardy at hibernate.org> wrote:
>>
>> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
>>> +1 from me.  Although, on the other hand, do we really need to keep maintaining that to begin with?  I guess I never thought simply having users go to the JIRA release notes was a big deal.  Just my $.02.
>>
>> Same for me on both counts, the proposed handling of changelog.txt as well as Brett's comment regarding the usefulness of this file altogether.
>
> A more frequent than I thought usage of changelog vs JIRA is a mix of Ctrl+F + quick scan to know what has changed in a library or know what is affecting me. JIRA is not the most intuitive UI in the universe. With allt he bug statuses, the various intermediary releases to select etc, nothing beats changelog.txt.

+1
- JIRA's UI is not too bad but let's remember that while we use it
since years, others might not feel comfortable with it
- many of those receiving our "dist" package might not have internet
access at all
- the dist packages is long term archived, like we include sources it
should contain a snapshot of all state. I like JIRA but who knows how
long it will be there?


From steve at hibernate.org  Fri May 29 07:03:09 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 06:03:09 -0500
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <CAFm4XO1-DX44N0YEJnJdN5F-_BP8xgKqVn8jVY2cnPAz0JqVrA@mail.gmail.com>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
	<CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>
	<20150529102213.GB43402@Nineveh.lan>
	<CAFm4XO1-DX44N0YEJnJdN5F-_BP8xgKqVn8jVY2cnPAz0JqVrA@mail.gmail.com>
Message-ID: <CAFdSV9sheCTFOJ=ji+Puegyhb9SZz_X=9Ve52utJ=sCxPvtD-w@mail.gmail.com>

Guys "position rather than alias usage in JDBC" is a small part of a
massive set of related changes in how we build SQL and consume the
results.  And actually it is the piece that has any compatibility impact
since it means any and all custom Types will need to be re-written.

On Fri, May 29, 2015 at 5:53 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I agree as well :)
>
> Just to add a minor twist:
>  - the override to lazy from eager would be useful to Search; skipping
> fields completely as an extra bonus (something I think ORM can't do at
> all - for good reasons when it comes to end user API - but again
> something Search would benefit from and not expose to users).
>  - since I'm currently exploring the 2nd level cache keys and the
> persistence context keys again, it's getting clear (again as we
> discussed this before) to potentially use a different data structure
> to hold the persistence context.
>
> But neither is urgent, I'd prefer you to schedule things to minimize
> overall effort (maximize overall throughput over latency of any of
> these).
>
> On "position rather than alias usage in JDBC": I was looking forward
> for that as well. Wasn't it part of the 5.0 schedule? I thought it was
> done.
>
> Sanne
>
>
> On 29 May 2015 at 11:22, Hardy Ferentschik <hardy at hibernate.org> wrote:
> > On Thu, May 28, 2015 at 11:33:22AM -0500, Steve Ebersole wrote:
> >> Anyone have any input here?  Or should I just start scheduling them how
> I
> >> want?
> >
> > I think all goals sound good. I would say schedule as you seem fit, maybe
> > with a focus of giving users something tangible asap (a bit of what
> Emmanuel
> > says).
> >
> > --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 steve at hibernate.org  Fri May 29 07:05:49 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 06:05:49 -0500
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <CAFm4XO2ALBrxwZYA_cbcCN3uWgwFDUPmdt+woYnu9feCAt9REA@mail.gmail.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
	<21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>
	<CAFm4XO2ALBrxwZYA_cbcCN3uWgwFDUPmdt+woYnu9feCAt9REA@mail.gmail.com>
Message-ID: <CAFdSV9vCvf7hJwtYf-83REDxkFNmU4uk1yj6OayWyAoMyHbC=g@mail.gmail.com>

I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You want to
keep a massive changelog.txt containing all history forever?

On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> On 29 May 2015 at 08:15, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> >
> >> On 28 May 2015, at 10:42, Hardy Ferentschik <hardy at hibernate.org>
> wrote:
> >>
> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> >>> +1 from me.  Although, on the other hand, do we really need to keep
> maintaining that to begin with?  I guess I never thought simply having
> users go to the JIRA release notes was a big deal.  Just my $.02.
> >>
> >> Same for me on both counts, the proposed handling of changelog.txt as
> well as Brett's comment regarding the usefulness of this file altogether.
> >
> > A more frequent than I thought usage of changelog vs JIRA is a mix of
> Ctrl+F + quick scan to know what has changed in a library or know what is
> affecting me. JIRA is not the most intuitive UI in the universe. With allt
> he bug statuses, the various intermediary releases to select etc, nothing
> beats changelog.txt.
>
> +1
> - JIRA's UI is not too bad but let's remember that while we use it
> since years, others might not feel comfortable with it
> - many of those receiving our "dist" package might not have internet
> access at all
> - the dist packages is long term archived, like we include sources it
> should contain a snapshot of all state. I like JIRA but who knows how
> long it will be there?
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri May 29 07:09:28 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 29 May 2015 12:09:28 +0100
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <CAFdSV9vCvf7hJwtYf-83REDxkFNmU4uk1yj6OayWyAoMyHbC=g@mail.gmail.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
	<21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>
	<CAFm4XO2ALBrxwZYA_cbcCN3uWgwFDUPmdt+woYnu9feCAt9REA@mail.gmail.com>
	<CAFdSV9vCvf7hJwtYf-83REDxkFNmU4uk1yj6OayWyAoMyHbC=g@mail.gmail.com>
Message-ID: <CAFm4XO2yvj1PHvzqHmmfPjmOEs=4K9tFMzFm-7TBWKo_X_Ne_Q@mail.gmail.com>

I'm +1 especially to keep the changelog.txt file both maintained and included.

About pruning older content: I'd keep the past few years at least, for
sake of who's finally upgrading.
Maybe since version 3.0 onwards? Or just keep it all :)

On 29 May 2015 at 12:05, Steve Ebersole <steve at hibernate.org> wrote:
> I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You want to
> keep a massive changelog.txt containing all history forever?
>
> On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> On 29 May 2015 at 08:15, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>> >
>> >> On 28 May 2015, at 10:42, Hardy Ferentschik <hardy at hibernate.org>
>> >> wrote:
>> >>
>> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
>> >>> +1 from me.  Although, on the other hand, do we really need to keep
>> >>> maintaining that to begin with?  I guess I never thought simply having users
>> >>> go to the JIRA release notes was a big deal.  Just my $.02.
>> >>
>> >> Same for me on both counts, the proposed handling of changelog.txt as
>> >> well as Brett's comment regarding the usefulness of this file altogether.
>> >
>> > A more frequent than I thought usage of changelog vs JIRA is a mix of
>> > Ctrl+F + quick scan to know what has changed in a library or know what is
>> > affecting me. JIRA is not the most intuitive UI in the universe. With allt
>> > he bug statuses, the various intermediary releases to select etc, nothing
>> > beats changelog.txt.
>>
>> +1
>> - JIRA's UI is not too bad but let's remember that while we use it
>> since years, others might not feel comfortable with it
>> - many of those receiving our "dist" package might not have internet
>> access at all
>> - the dist packages is long term archived, like we include sources it
>> should contain a snapshot of all state. I like JIRA but who knows how
>> long it will be there?
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Fri May 29 07:16:22 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 06:16:22 -0500
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <CAFm4XO2yvj1PHvzqHmmfPjmOEs=4K9tFMzFm-7TBWKo_X_Ne_Q@mail.gmail.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
	<21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>
	<CAFm4XO2ALBrxwZYA_cbcCN3uWgwFDUPmdt+woYnu9feCAt9REA@mail.gmail.com>
	<CAFdSV9vCvf7hJwtYf-83REDxkFNmU4uk1yj6OayWyAoMyHbC=g@mail.gmail.com>
	<CAFm4XO2yvj1PHvzqHmmfPjmOEs=4K9tFMzFm-7TBWKo_X_Ne_Q@mail.gmail.com>
Message-ID: <CAFdSV9s+hKDTzdPVpnE2F=wutQAwp3xY54kRqsYGe0jTZakzEQ@mail.gmail.com>

So it makes sense to you that the changelog for 5.0 includes entries for
pre 1.0?

On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> I'm +1 especially to keep the changelog.txt file both maintained and
> included.
>
> About pruning older content: I'd keep the past few years at least, for
> sake of who's finally upgrading.
> Maybe since version 3.0 onwards? Or just keep it all :)
>
> On 29 May 2015 at 12:05, Steve Ebersole <steve at hibernate.org> wrote:
> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You want
> to
> > keep a massive changelog.txt containing all history forever?
> >
> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> On 29 May 2015 at 08:15, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >> >
> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik <hardy at hibernate.org>
> >> >> wrote:
> >> >>
> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> >> >>> +1 from me.  Although, on the other hand, do we really need to keep
> >> >>> maintaining that to begin with?  I guess I never thought simply
> having users
> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
> >> >>
> >> >> Same for me on both counts, the proposed handling of changelog.txt as
> >> >> well as Brett's comment regarding the usefulness of this file
> altogether.
> >> >
> >> > A more frequent than I thought usage of changelog vs JIRA is a mix of
> >> > Ctrl+F + quick scan to know what has changed in a library or know
> what is
> >> > affecting me. JIRA is not the most intuitive UI in the universe. With
> allt
> >> > he bug statuses, the various intermediary releases to select etc,
> nothing
> >> > beats changelog.txt.
> >>
> >> +1
> >> - JIRA's UI is not too bad but let's remember that while we use it
> >> since years, others might not feel comfortable with it
> >> - many of those receiving our "dist" package might not have internet
> >> access at all
> >> - the dist packages is long term archived, like we include sources it
> >> should contain a snapshot of all state. I like JIRA but who knows how
> >> long it will be there?
> >>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.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  Fri May 29 07:32:13 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 29 May 2015 12:32:13 +0100
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <CAFdSV9s+hKDTzdPVpnE2F=wutQAwp3xY54kRqsYGe0jTZakzEQ@mail.gmail.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
	<21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>
	<CAFm4XO2ALBrxwZYA_cbcCN3uWgwFDUPmdt+woYnu9feCAt9REA@mail.gmail.com>
	<CAFdSV9vCvf7hJwtYf-83REDxkFNmU4uk1yj6OayWyAoMyHbC=g@mail.gmail.com>
	<CAFm4XO2yvj1PHvzqHmmfPjmOEs=4K9tFMzFm-7TBWKo_X_Ne_Q@mail.gmail.com>
	<CAFdSV9s+hKDTzdPVpnE2F=wutQAwp3xY54kRqsYGe0jTZakzEQ@mail.gmail.com>
Message-ID: <CAFm4XO0-DUWqhc+UQztE9sR4VHm9m6uMiXd=PpJPVPShEvoq1g@mail.gmail.com>

I wouldn't stay awake at night because of that :) maybe only if the
file gets huge?
It's useful for people migrating, but since I doubt someone would
migrate from pre-1.0 (at least without expecting to rewrite it all),
that's why I suggested to keep from 3.0 onwards.

On 29 May 2015 at 12:16, Steve Ebersole <steve at hibernate.org> wrote:
> So it makes sense to you that the changelog for 5.0 includes entries for pre
> 1.0?
>
> On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero <sanne at hibernate.org>
> wrote:
>>
>> I'm +1 especially to keep the changelog.txt file both maintained and
>> included.
>>
>> About pruning older content: I'd keep the past few years at least, for
>> sake of who's finally upgrading.
>> Maybe since version 3.0 onwards? Or just keep it all :)
>>
>> On 29 May 2015 at 12:05, Steve Ebersole <steve at hibernate.org> wrote:
>> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You want
>> > to
>> > keep a massive changelog.txt containing all history forever?
>> >
>> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> On 29 May 2015 at 08:15, Emmanuel Bernard <emmanuel at hibernate.org>
>> >> wrote:
>> >> >
>> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik <hardy at hibernate.org>
>> >> >> wrote:
>> >> >>
>> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
>> >> >>> +1 from me.  Although, on the other hand, do we really need to keep
>> >> >>> maintaining that to begin with?  I guess I never thought simply
>> >> >>> having users
>> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
>> >> >>
>> >> >> Same for me on both counts, the proposed handling of changelog.txt
>> >> >> as
>> >> >> well as Brett's comment regarding the usefulness of this file
>> >> >> altogether.
>> >> >
>> >> > A more frequent than I thought usage of changelog vs JIRA is a mix of
>> >> > Ctrl+F + quick scan to know what has changed in a library or know
>> >> > what is
>> >> > affecting me. JIRA is not the most intuitive UI in the universe. With
>> >> > allt
>> >> > he bug statuses, the various intermediary releases to select etc,
>> >> > nothing
>> >> > beats changelog.txt.
>> >>
>> >> +1
>> >> - JIRA's UI is not too bad but let's remember that while we use it
>> >> since years, others might not feel comfortable with it
>> >> - many of those receiving our "dist" package might not have internet
>> >> access at all
>> >> - the dist packages is long term archived, like we include sources it
>> >> should contain a snapshot of all state. I like JIRA but who knows how
>> >> long it will be there?
>> >>
>> >> _______________________________________________
>> >> hibernate-dev mailing list
>> >> hibernate-dev at lists.jboss.org
>> >> https://lists.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  Fri May 29 07:48:08 2015
From: dreborier at gmail.com (andrea boriero)
Date: Fri, 29 May 2015 12:48:08 +0100
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <CAFm4XO0-DUWqhc+UQztE9sR4VHm9m6uMiXd=PpJPVPShEvoq1g@mail.gmail.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<5134CE9B.5020700@hibernate.org>
	<CAFdSV9sQ1qKPtWjjp5F2uGyKsBL4sDAyDDRsHwcKi=ozOKcVGw@mail.gmail.com>
	<CAFdSV9u3bA54ZYMTN17DtVeWd55eCXOEu_C-kVnORLOi-wUsMw@mail.gmail.com>
	<787909717.7222898.1432778511864.JavaMail.zimbra@redhat.com>
	<20150528084205.GB35093@Nineveh.lan>
	<21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>
	<CAFm4XO2ALBrxwZYA_cbcCN3uWgwFDUPmdt+woYnu9feCAt9REA@mail.gmail.com>
	<CAFdSV9vCvf7hJwtYf-83REDxkFNmU4uk1yj6OayWyAoMyHbC=g@mail.gmail.com>
	<CAFm4XO2yvj1PHvzqHmmfPjmOEs=4K9tFMzFm-7TBWKo_X_Ne_Q@mail.gmail.com>
	<CAFdSV9s+hKDTzdPVpnE2F=wutQAwp3xY54kRqsYGe0jTZakzEQ@mail.gmail.com>
	<CAFm4XO0-DUWqhc+UQztE9sR4VHm9m6uMiXd=PpJPVPShEvoq1g@mail.gmail.com>
Message-ID: <CAL00eSRTMqandAZaCstUgr7UBgsH799=11TQh8Tn6E4R_daimg@mail.gmail.com>

I would mantain all 5.x in the same changelog file and may be the previous
one.

On 29 May 2015 at 12:32, Sanne Grinovero <sanne at hibernate.org> wrote:

> I wouldn't stay awake at night because of that :) maybe only if the
> file gets huge?
> It's useful for people migrating, but since I doubt someone would
> migrate from pre-1.0 (at least without expecting to rewrite it all),
> that's why I suggested to keep from 3.0 onwards.
>
> On 29 May 2015 at 12:16, Steve Ebersole <steve at hibernate.org> wrote:
> > So it makes sense to you that the changelog for 5.0 includes entries for
> pre
> > 1.0?
> >
> > On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero <sanne at hibernate.org>
> > wrote:
> >>
> >> I'm +1 especially to keep the changelog.txt file both maintained and
> >> included.
> >>
> >> About pruning older content: I'd keep the past few years at least, for
> >> sake of who's finally upgrading.
> >> Maybe since version 3.0 onwards? Or just keep it all :)
> >>
> >> On 29 May 2015 at 12:05, Steve Ebersole <steve at hibernate.org> wrote:
> >> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You
> want
> >> > to
> >> > keep a massive changelog.txt containing all history forever?
> >> >
> >> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero <sanne at hibernate.org
> >
> >> > wrote:
> >> >>
> >> >> On 29 May 2015 at 08:15, Emmanuel Bernard <emmanuel at hibernate.org>
> >> >> wrote:
> >> >> >
> >> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik <hardy at hibernate.org>
> >> >> >> wrote:
> >> >> >>
> >> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> >> >> >>> +1 from me.  Although, on the other hand, do we really need to
> keep
> >> >> >>> maintaining that to begin with?  I guess I never thought simply
> >> >> >>> having users
> >> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
> >> >> >>
> >> >> >> Same for me on both counts, the proposed handling of changelog.txt
> >> >> >> as
> >> >> >> well as Brett's comment regarding the usefulness of this file
> >> >> >> altogether.
> >> >> >
> >> >> > A more frequent than I thought usage of changelog vs JIRA is a mix
> of
> >> >> > Ctrl+F + quick scan to know what has changed in a library or know
> >> >> > what is
> >> >> > affecting me. JIRA is not the most intuitive UI in the universe.
> With
> >> >> > allt
> >> >> > he bug statuses, the various intermediary releases to select etc,
> >> >> > nothing
> >> >> > beats changelog.txt.
> >> >>
> >> >> +1
> >> >> - JIRA's UI is not too bad but let's remember that while we use it
> >> >> since years, others might not feel comfortable with it
> >> >> - many of those receiving our "dist" package might not have internet
> >> >> access at all
> >> >> - the dist packages is long term archived, like we include sources it
> >> >> should contain a snapshot of all state. I like JIRA but who knows how
> >> >> long it will be there?
> >> >>
> >> >> _______________________________________________
> >> >> hibernate-dev mailing list
> >> >> hibernate-dev at lists.jboss.org
> >> >> https://lists.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 sanne at hibernate.org  Fri May 29 11:00:12 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 29 May 2015 16:00:12 +0100
Subject: [hibernate-dev] HSearch + Tika bridge using Wildfly modules
In-Reply-To: <650952943.8677484.1432909719158.JavaMail.zimbra@redhat.com>
References: <1663839921.8674641.1432909533929.JavaMail.zimbra@redhat.com>
	<650952943.8677484.1432909719158.JavaMail.zimbra@redhat.com>
Message-ID: <CAFm4XO0sd-iDn-VPvjFJ4OzY+fadDx+sihmNrExrMkJX5CEx9Q@mail.gmail.com>

Hi Brett,
we don't include all existing analysers and extensions within the
WildFly modules. In particular the Apache Tika libraries have a huge
amount of dependencies, you should choose the ones you need depending
on what kind of media you intend to parse.

Include any extension in your "application", we use the Hibernate ORM
classloader to lookup for extensions so these should be discoverable
if they are visible to the same classloader having your entities and
other extensions.

Sanne

On 29 May 2015 at 15:28, Brett Meyer <brmeyer at redhat.com> wrote:
> Hey Sanne!  Artificer has '<module name="org.hibernate.search.orm" services="export" />' defined in its jboss-deployment-structure dependencies.  But, when we try to use it, the following happens.
>
> Caused by: java.lang.ClassNotFoundException: org.apache.tika.parser.Parser from [Module "org.hibernate.search.engine:main" from local module loader @6cf76647 (finder: local module finder @665bf734 (roots: /home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules,/home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules/system/layers/base))]
>
> One of our entities uses the built-in TikaBridge.  I figured the search.orm module would bring the necessary Tika jars in with it.  Is there something else we need to add?


From steve at hibernate.org  Fri May 29 12:22:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 16:22:13 +0000
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <F977C829-81E1-44D3-9F19-48B2B00DBCAC@hibernate.org>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
	<CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>
	<C780CA88-895A-49E2-A21C-FACA5DA47E00@hibernate.org>
	<F977C829-81E1-44D3-9F19-48B2B00DBCAC@hibernate.org>
Message-ID: <CAFdSV9t-KLT_5O-wid5hkUEw6RoyJCFMxY2vFDS41EznRmG4RA@mail.gmail.com>

That is actually exactly the model I started with 4.x and what I plan on
continuing into 5.x

On Fri, May 29, 2015, 3:07 AM Emmanuel Bernard <emmanuel at hibernate.org>
wrote:

> Also (thinking outloud).
>
> Maybe planning 5.1 5.2 5.x as a savant dosage of:
>
> - a focused and useful new feature that users tend to like
> (discriminator-based multi-tenancy, fluent criteria API, ?)
> - a performance focused feature (position rather than alias usage in JDBC)
> - a longer term work plan which might span several minors to be achieved
> (SQL generation & hQL parser, ?)
>
> One of each per 5.x might be interesting to explore.
>
> > On 29 May 2015, at 09:58, Emmanuel Bernard <emmanuel at hibernate.org>
> wrote:
> >
> > My favs are
> >
> > * discriminator-based multi-tenancy
> > * extend JPA criteria API with fluent support (does that mean embracing
> something like http://www.querydsl.com ? Os is that something different?
> > * rework SQL generation & HQL parser
> >
> >
> >
> >> On 28 May 2015, at 18:33, Steve Ebersole <steve at hibernate.org> wrote:
> >>
> >> Anyone have any input here?  Or should I just start scheduling them how
> I
> >> want?
> >>
> >> On Tue, May 19, 2015 at 8:47 PM, Steve Ebersole <steve at hibernate.org>
> wrote:
> >>
> >>> Now that 5.0 is settling down I wanted to start planning where we go
> from
> >>> here in terms of feature development and schedule/releases.
> >>>
> >>> Here is my high-level list of features/work:
> >>> * rework SQL generation & HQL parser
> >>> * change JDBC extraction to work by position, rather than alias
> (reworking
> >>> SQL generation is a prerequisite)
> >>> * rework annotation binding (Jandex, etc)
> >>> * extended orm.xml, deprecate hbm.xml
> >>> * discriminator-based multi-tenancy
> >>> * port Hibernate Criteria constructs to JPA criteria, begin
> deprecation of
> >>> Hibernate Criteria
> >>> * extend JPA criteria API with fluent support
> >>> * ability to override EAGER fetching with LAZY (fetch profiles, HQL,
> etc)
> >>> * merging hibernate-entitymanager into hibernate-core
> >>> * continue to fill out bytecode enhancement capabilities
> >>>
> >>> Some of these are more involved than others.  The task for re-writing
> SQL
> >>> generation is a HUGE undertaking, but also has many huge benefits.
> >>> Re-writing annotation binding is another huge undertaking, but again
> with
> >>> many benefits.
> >>>
> >>> Any others we should add to the list here?
> >>>
> >>> And then we can work on scheduling them.
> >>>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev at lists.jboss.org
> >> https://lists.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 johara at redhat.com  Fri May 29 12:31:57 2015
From: johara at redhat.com (John O'Hara)
Date: Fri, 29 May 2015 17:31:57 +0100
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
Message-ID: <5568947D.5000104@redhat.com>

On 20/05/15 02:47, Steve Ebersole wrote:
> Now that 5.0 is settling down I wanted to start planning where we go from
> here in terms of feature development and schedule/releases.
>
> Here is my high-level list of features/work:
> * rework SQL generation & HQL parser
> * change JDBC extraction to work by position, rather than alias (reworking
> SQL generation is a prerequisite)
+1
I had been tasked to start investigating the two features above, as we 
have seen them to impact performance in the past. If you would like an 
additional pair of hands on either/both of these, please let me know

> * rework annotation binding (Jandex, etc)
> * extended orm.xml, deprecate hbm.xml
> * discriminator-based multi-tenancy
> * port Hibernate Criteria constructs to JPA criteria, begin deprecation of
> Hibernate Criteria
> * extend JPA criteria API with fluent support
> * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
> * merging hibernate-entitymanager into hibernate-core
> * continue to fill out bytecode enhancement capabilities
>
> Some of these are more involved than others.  The task for re-writing SQL
> generation is a HUGE undertaking, but also has many huge benefits.
> Re-writing annotation binding is another huge undertaking, but again with
> many benefits.
>
> Any others we should add to the list here?
>
> And then we can work on scheduling them.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
John O'Hara
johara at redhat.com

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


From smarlow at redhat.com  Fri May 29 12:50:26 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 29 May 2015 12:50:26 -0400
Subject: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status
	update...
Message-ID: <556898D2.8010103@redhat.com>

I ran part of the WildFly basic integration tests against the 
https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch, 
which includes the following Hibernate versions:

ORM 5.0.0.CR1
HCA 4.0.5.Final
HS 5.2.0.Final

I am seeing the below errors.

1. The Hibernate Search test 
(org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase) 
is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L

2. In the 
org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache, 
we are seeing a "java.lang.ClassNotFoundException: 
org.infinispan.commons.util.CloseableIteratorSet from [Module 
"org.hibernate.infinispan:main"http://pastie.org/10213943

Scott

From smarlow at redhat.com  Fri May 29 12:57:48 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 29 May 2015 12:57:48 -0400
Subject: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status
 update...
In-Reply-To: <556898D2.8010103@redhat.com>
References: <556898D2.8010103@redhat.com>
Message-ID: <55689A8C.5080304@redhat.com>

Also am using Infinispan 7.2.1.Final but noticed that Infinispan 
7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master 
to upgrade Infinispan.

On 05/29/2015 12:50 PM, Scott Marlow wrote:
> I ran part of the WildFly basic integration tests against the
> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
> which includes the following Hibernate versions:
>
> ORM 5.0.0.CR1
> HCA 4.0.5.Final
> HS 5.2.0.Final
>
> I am seeing the below errors.
>
> 1. The Hibernate Search test
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
> is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L
>
> 2. In the
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
> we are seeing a "java.lang.ClassNotFoundException:
> org.infinispan.commons.util.CloseableIteratorSet from [Module
> "org.hibernate.infinispan:main"http://pastie.org/10213943
>
> Scott
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From sanne at hibernate.org  Fri May 29 13:05:51 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 29 May 2015 18:05:51 +0100
Subject: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status
	update...
In-Reply-To: <556898D2.8010103@redhat.com>
References: <556898D2.8010103@redhat.com>
Message-ID: <CAFm4XO1rykkbc_W+6f+CYHTWtrX7BEA+7o-sUFaRbEoADWtoWw@mail.gmail.com>

Thanks Scott!

1. this error is expected: HS 5.2 is not compatible with ORM 5.
We'll need a compatible WildFly version to release a compatible
version, or alternatively know how to get the tests to run w/o the
jipijapa patch as I was trying ;-)

A backup plan is we stop producing Hibernate Search modules for
WildFly as part of our release, and split it up as a secondary task
like Hardy suggested today on IRC.

2. this is not expected, especially as I think the Infinispan version
already in WF is aligned with the one in ORM5?
Steve, do you remember about classloader strategy changes between
latest ORM 4.3 and 5.0.0.CR1?

Sanne


On 29 May 2015 at 17:50, Scott Marlow <smarlow at redhat.com> wrote:
> I ran part of the WildFly basic integration tests against the
> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
> which includes the following Hibernate versions:
>
> ORM 5.0.0.CR1
> HCA 4.0.5.Final
> HS 5.2.0.Final
>
> I am seeing the below errors.
>
> 1. The Hibernate Search test
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
> is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L
>
> 2. In the
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
> we are seeing a "java.lang.ClassNotFoundException:
> org.infinispan.commons.util.CloseableIteratorSet from [Module
> "org.hibernate.infinispan:main"http://pastie.org/10213943
>
> Scott
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From smarlow at redhat.com  Fri May 29 13:27:09 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 29 May 2015 13:27:09 -0400
Subject: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status
 update...
In-Reply-To: <CAFm4XO1rykkbc_W+6f+CYHTWtrX7BEA+7o-sUFaRbEoADWtoWw@mail.gmail.com>
References: <556898D2.8010103@redhat.com>
	<CAFm4XO1rykkbc_W+6f+CYHTWtrX7BEA+7o-sUFaRbEoADWtoWw@mail.gmail.com>
Message-ID: <5568A16D.5090201@redhat.com>



On 05/29/2015 01:05 PM, Sanne Grinovero wrote:
> Thanks Scott!
>
> 1. this error is expected: HS 5.2 is not compatible with ORM 5.
> We'll need a compatible WildFly version to release a compatible
> version, or alternatively know how to get the tests to run w/o the
> jipijapa patch as I was trying ;-)

In the interest of getting ORM 5 into WildFly 10 before HS is upgraded, 
we could disable 
org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase and 
create a blocking jira for WF10 assigned to you, so you can either 
enable the HibernateSearchJPATestCase test or remove Search from WildFly 
10 as you mention below (as a possible option).  Please let me know how 
you want me to proceed.

>
> A backup plan is we stop producing Hibernate Search modules for
> WildFly as part of our release, and split it up as a secondary task
> like Hardy suggested today on IRC.

>
> 2. this is not expected, especially as I think the Infinispan version
> already in WF is aligned with the one in ORM5?
> Steve, do you remember about classloader strategy changes between
> latest ORM 4.3 and 5.0.0.CR1?
>
> Sanne
>
>
> On 29 May 2015 at 17:50, Scott Marlow <smarlow at redhat.com> wrote:
>> I ran part of the WildFly basic integration tests against the
>> https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
>> which includes the following Hibernate versions:
>>
>> ORM 5.0.0.CR1
>> HCA 4.0.5.Final
>> HS 5.2.0.Final
>>
>> I am seeing the below errors.
>>
>> 1. The Hibernate Search test
>> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
>> is failing with an AbstractServiceMethodError http://pastebin.com/CzEgVp0L
>>
>> 2. In the
>> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
>> we are seeing a "java.lang.ClassNotFoundException:
>> org.infinispan.commons.util.CloseableIteratorSet from [Module
>> "org.hibernate.infinispan:main"http://pastie.org/10213943
>>
>> Scott
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From steve at hibernate.org  Fri May 29 13:43:13 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 12:43:13 -0500
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <C780CA88-895A-49E2-A21C-FACA5DA47E00@hibernate.org>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
	<CAFdSV9uvU6DpmoUPe1PCD-O2cZmY6=T68dSe9nY-s4BEw=JG8Q@mail.gmail.com>
	<C780CA88-895A-49E2-A21C-FACA5DA47E00@hibernate.org>
Message-ID: <CAFdSV9vtfvmLrhYNBb8CQT1n9aSA+rEQnU0LeYFEwVmGppK2NQ@mail.gmail.com>

>
> * extend JPA criteria API with fluent support (does that mean embracing
> something like http://www.querydsl.com ? Os is that something different?


I was not the one who brought up "fluency".  TBH, I do not remember who
brought it up nor what it was about.

In regards to Criteria I had wanted to extend it to expose Hibernate-only
concepts and port things we support in our native Criteria API.

From gbadner at redhat.com  Fri May 29 13:43:13 2015
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 29 May 2015 13:43:13 -0400 (EDT)
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <CAL00eSRTMqandAZaCstUgr7UBgsH799=11TQh8Tn6E4R_daimg@mail.gmail.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>
	<CAFm4XO2ALBrxwZYA_cbcCN3uWgwFDUPmdt+woYnu9feCAt9REA@mail.gmail.com>
	<CAFdSV9vCvf7hJwtYf-83REDxkFNmU4uk1yj6OayWyAoMyHbC=g@mail.gmail.com>
	<CAFm4XO2yvj1PHvzqHmmfPjmOEs=4K9tFMzFm-7TBWKo_X_Ne_Q@mail.gmail.com>
	<CAFdSV9s+hKDTzdPVpnE2F=wutQAwp3xY54kRqsYGe0jTZakzEQ@mail.gmail.com>
	<CAFm4XO0-DUWqhc+UQztE9sR4VHm9m6uMiXd=PpJPVPShEvoq1g@mail.gmail.com>
	<CAL00eSRTMqandAZaCstUgr7UBgsH799=11TQh8Tn6E4R_daimg@mail.gmail.com>
Message-ID: <1599628776.6851876.1432921393489.JavaMail.zimbra@redhat.com>

I would prefer retaining all bugs fixes that feed into EAP. 

The first Hibernate version used by EAP was roughly 3.2.4.sp1 (there were a few extra commits included in the version that got into EAP).

Are you planning to truncate the change logs for 3.2 or 3.3? If so, it would be helpful to me retain the bug fixes in those changelogs going back to at least 3.2.4.sp1

FWIW, I'm fine with the changelog containing everything. I don't particularly care how large they get.

----- Original Message -----
> From: "andrea boriero" <dreborier at gmail.com>
> To: "Sanne Grinovero" <sanne at hibernate.org>
> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> Sent: Friday, May 29, 2015 4:48:08 AM
> Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> 
> I would mantain all 5.x in the same changelog file and may be the previous
> one.
> 
> On 29 May 2015 at 12:32, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
> > I wouldn't stay awake at night because of that :) maybe only if the
> > file gets huge?
> > It's useful for people migrating, but since I doubt someone would
> > migrate from pre-1.0 (at least without expecting to rewrite it all),
> > that's why I suggested to keep from 3.0 onwards.
> >
> > On 29 May 2015 at 12:16, Steve Ebersole <steve at hibernate.org> wrote:
> > > So it makes sense to you that the changelog for 5.0 includes entries for
> > pre
> > > 1.0?
> > >
> > > On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero <sanne at hibernate.org>
> > > wrote:
> > >>
> > >> I'm +1 especially to keep the changelog.txt file both maintained and
> > >> included.
> > >>
> > >> About pruning older content: I'd keep the past few years at least, for
> > >> sake of who's finally upgrading.
> > >> Maybe since version 3.0 onwards? Or just keep it all :)
> > >>
> > >> On 29 May 2015 at 12:05, Steve Ebersole <steve at hibernate.org> wrote:
> > >> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You
> > want
> > >> > to
> > >> > keep a massive changelog.txt containing all history forever?
> > >> >
> > >> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero <sanne at hibernate.org
> > >
> > >> > wrote:
> > >> >>
> > >> >> On 29 May 2015 at 08:15, Emmanuel Bernard <emmanuel at hibernate.org>
> > >> >> wrote:
> > >> >> >
> > >> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik <hardy at hibernate.org>
> > >> >> >> wrote:
> > >> >> >>
> > >> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > >> >> >>> +1 from me.  Although, on the other hand, do we really need to
> > keep
> > >> >> >>> maintaining that to begin with?  I guess I never thought simply
> > >> >> >>> having users
> > >> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
> > >> >> >>
> > >> >> >> Same for me on both counts, the proposed handling of changelog.txt
> > >> >> >> as
> > >> >> >> well as Brett's comment regarding the usefulness of this file
> > >> >> >> altogether.
> > >> >> >
> > >> >> > A more frequent than I thought usage of changelog vs JIRA is a mix
> > of
> > >> >> > Ctrl+F + quick scan to know what has changed in a library or know
> > >> >> > what is
> > >> >> > affecting me. JIRA is not the most intuitive UI in the universe.
> > With
> > >> >> > allt
> > >> >> > he bug statuses, the various intermediary releases to select etc,
> > >> >> > nothing
> > >> >> > beats changelog.txt.
> > >> >>
> > >> >> +1
> > >> >> - JIRA's UI is not too bad but let's remember that while we use it
> > >> >> since years, others might not feel comfortable with it
> > >> >> - many of those receiving our "dist" package might not have internet
> > >> >> access at all
> > >> >> - the dist packages is long term archived, like we include sources it
> > >> >> should contain a snapshot of all state. I like JIRA but who knows how
> > >> >> long it will be there?
> > >> >>
> > >> >> _______________________________________________
> > >> >> hibernate-dev mailing list
> > >> >> hibernate-dev at lists.jboss.org
> > >> >> https://lists.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  Fri May 29 13:50:05 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 12:50:05 -0500
Subject: [hibernate-dev] Hibernate ORM - next steps
In-Reply-To: <5568947D.5000104@redhat.com>
References: <CAFdSV9v-xXGKX3VVe+npn5cWyGamX6ug0BDXF30HP2jaEkddzQ@mail.gmail.com>
	<5568947D.5000104@redhat.com>
Message-ID: <CAFdSV9viPi_z9Rqwfw_LVdjhcZDwoReAOCmVPKNA+CpVHWU_LA@mail.gmail.com>

I think Andy wanted to take a look at developing just the support to
references values by position rather than by alias without waiting on the
bigger task.  I don't think that is possible; at the least it is A LOT of
work much of which might change later when we do work on the bigger task.

I know personally, time/resources aside, the biggest reason I have not
worked a lot on the bigger task (other than my initial work on the new
query parser) is because I had hoped a solution would present itself to the
Antlr 4 quandary.  But it hasn't and likely wont and I think Gunnar and
Sanne and I are all in agreement that it probably just makes sense to base
this work on Antlr 3.

On Fri, May 29, 2015 at 11:31 AM, John O'Hara <johara at redhat.com> wrote:

> On 20/05/15 02:47, Steve Ebersole wrote:
> > Now that 5.0 is settling down I wanted to start planning where we go from
> > here in terms of feature development and schedule/releases.
> >
> > Here is my high-level list of features/work:
> > * rework SQL generation & HQL parser
> > * change JDBC extraction to work by position, rather than alias
> (reworking
> > SQL generation is a prerequisite)
> +1
> I had been tasked to start investigating the two features above, as we
> have seen them to impact performance in the past. If you would like an
> additional pair of hands on either/both of these, please let me know
>
> > * rework annotation binding (Jandex, etc)
> > * extended orm.xml, deprecate hbm.xml
> > * discriminator-based multi-tenancy
> > * port Hibernate Criteria constructs to JPA criteria, begin deprecation
> of
> > Hibernate Criteria
> > * extend JPA criteria API with fluent support
> > * ability to override EAGER fetching with LAZY (fetch profiles, HQL, etc)
> > * merging hibernate-entitymanager into hibernate-core
> > * continue to fill out bytecode enhancement capabilities
> >
> > Some of these are more involved than others.  The task for re-writing SQL
> > generation is a HUGE undertaking, but also has many huge benefits.
> > Re-writing annotation binding is another huge undertaking, but again with
> > many benefits.
> >
> > Any others we should add to the list here?
> >
> > And then we can work on scheduling them.
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> --
> John O'Hara
> johara at redhat.com
>
> JBoss, by Red Hat
> Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
> Street, Windsor, Berkshire, SI4 1TE, United Kingdom.
> Registered in UK and Wales under Company Registration No. 3798903
> Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
> (USA) and Michael O'Neill (Ireland).
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Fri May 29 13:52:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 12:52:55 -0500
Subject: [hibernate-dev] Changelog file in Hibernate ORM
In-Reply-To: <1599628776.6851876.1432921393489.JavaMail.zimbra@redhat.com>
References: <904008135.14065588.1362407650303.JavaMail.root@redhat.com>
	<21571007-5C14-4FDE-9A45-88CCC859AC20@hibernate.org>
	<CAFm4XO2ALBrxwZYA_cbcCN3uWgwFDUPmdt+woYnu9feCAt9REA@mail.gmail.com>
	<CAFdSV9vCvf7hJwtYf-83REDxkFNmU4uk1yj6OayWyAoMyHbC=g@mail.gmail.com>
	<CAFm4XO2yvj1PHvzqHmmfPjmOEs=4K9tFMzFm-7TBWKo_X_Ne_Q@mail.gmail.com>
	<CAFdSV9s+hKDTzdPVpnE2F=wutQAwp3xY54kRqsYGe0jTZakzEQ@mail.gmail.com>
	<CAFm4XO0-DUWqhc+UQztE9sR4VHm9m6uMiXd=PpJPVPShEvoq1g@mail.gmail.com>
	<CAL00eSRTMqandAZaCstUgr7UBgsH799=11TQh8Tn6E4R_daimg@mail.gmail.com>
	<1599628776.6851876.1432921393489.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9v6GThKWcUDj182JYu2hrQ=DQnne76g+LtnHWdKmmR1gQ@mail.gmail.com>

I am only planning to truncate this moving forward.  In fact it is already
done in master, aside from adding notes about where the 5.0 changes
dovetail with 4.3 changes.

On Fri, May 29, 2015 at 12:43 PM, Gail Badner <gbadner at redhat.com> wrote:

> I would prefer retaining all bugs fixes that feed into EAP.
>
> The first Hibernate version used by EAP was roughly 3.2.4.sp1 (there were
> a few extra commits included in the version that got into EAP).
>
> Are you planning to truncate the change logs for 3.2 or 3.3? If so, it
> would be helpful to me retain the bug fixes in those changelogs going back
> to at least 3.2.4.sp1
>
> FWIW, I'm fine with the changelog containing everything. I don't
> particularly care how large they get.
>
> ----- Original Message -----
> > From: "andrea boriero" <dreborier at gmail.com>
> > To: "Sanne Grinovero" <sanne at hibernate.org>
> > Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
> > Sent: Friday, May 29, 2015 4:48:08 AM
> > Subject: Re: [hibernate-dev] Changelog file in Hibernate ORM
> >
> > I would mantain all 5.x in the same changelog file and may be the
> previous
> > one.
> >
> > On 29 May 2015 at 12:32, Sanne Grinovero <sanne at hibernate.org> wrote:
> >
> > > I wouldn't stay awake at night because of that :) maybe only if the
> > > file gets huge?
> > > It's useful for people migrating, but since I doubt someone would
> > > migrate from pre-1.0 (at least without expecting to rewrite it all),
> > > that's why I suggested to keep from 3.0 onwards.
> > >
> > > On 29 May 2015 at 12:16, Steve Ebersole <steve at hibernate.org> wrote:
> > > > So it makes sense to you that the changelog for 5.0 includes entries
> for
> > > pre
> > > > 1.0?
> > > >
> > > > On Fri, May 29, 2015 at 6:09 AM, Sanne Grinovero <
> sanne at hibernate.org>
> > > > wrote:
> > > >>
> > > >> I'm +1 especially to keep the changelog.txt file both maintained and
> > > >> included.
> > > >>
> > > >> About pruning older content: I'd keep the past few years at least,
> for
> > > >> sake of who's finally upgrading.
> > > >> Maybe since version 3.0 onwards? Or just keep it all :)
> > > >>
> > > >> On 29 May 2015 at 12:05, Steve Ebersole <steve at hibernate.org>
> wrote:
> > > >> > I'm really not sure what y'all are +1'ing Emmanuel and Sanne.  You
> > > want
> > > >> > to
> > > >> > keep a massive changelog.txt containing all history forever?
> > > >> >
> > > >> > On Fri, May 29, 2015 at 5:59 AM, Sanne Grinovero <
> sanne at hibernate.org
> > > >
> > > >> > wrote:
> > > >> >>
> > > >> >> On 29 May 2015 at 08:15, Emmanuel Bernard <
> emmanuel at hibernate.org>
> > > >> >> wrote:
> > > >> >> >
> > > >> >> >> On 28 May 2015, at 10:42, Hardy Ferentschik <
> hardy at hibernate.org>
> > > >> >> >> wrote:
> > > >> >> >>
> > > >> >> >> On Wed, May 27, 2015 at 10:01:51PM -0400, Brett Meyer wrote:
> > > >> >> >>> +1 from me.  Although, on the other hand, do we really need
> to
> > > keep
> > > >> >> >>> maintaining that to begin with?  I guess I never thought
> simply
> > > >> >> >>> having users
> > > >> >> >>> go to the JIRA release notes was a big deal.  Just my $.02.
> > > >> >> >>
> > > >> >> >> Same for me on both counts, the proposed handling of
> changelog.txt
> > > >> >> >> as
> > > >> >> >> well as Brett's comment regarding the usefulness of this file
> > > >> >> >> altogether.
> > > >> >> >
> > > >> >> > A more frequent than I thought usage of changelog vs JIRA is a
> mix
> > > of
> > > >> >> > Ctrl+F + quick scan to know what has changed in a library or
> know
> > > >> >> > what is
> > > >> >> > affecting me. JIRA is not the most intuitive UI in the
> universe.
> > > With
> > > >> >> > allt
> > > >> >> > he bug statuses, the various intermediary releases to select
> etc,
> > > >> >> > nothing
> > > >> >> > beats changelog.txt.
> > > >> >>
> > > >> >> +1
> > > >> >> - JIRA's UI is not too bad but let's remember that while we use
> it
> > > >> >> since years, others might not feel comfortable with it
> > > >> >> - many of those receiving our "dist" package might not have
> internet
> > > >> >> access at all
> > > >> >> - the dist packages is long term archived, like we include
> sources it
> > > >> >> should contain a snapshot of all state. I like JIRA but who
> knows how
> > > >> >> long it will be there?
> > > >> >>
> > > >> >> _______________________________________________
> > > >> >> hibernate-dev mailing list
> > > >> >> hibernate-dev at lists.jboss.org
> > > >> >> https://lists.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  Fri May 29 14:03:27 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 13:03:27 -0500
Subject: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status
	update...
In-Reply-To: <55689A8C.5080304@redhat.com>
References: <556898D2.8010103@redhat.com>
	<55689A8C.5080304@redhat.com>
Message-ID: <CAFdSV9vbfokiTJp_6iXSWgDSe747iju36qRzaJarkgp1ntMMoA@mail.gmail.com>

Scott, first please use a SNAPSHOT build as you'll need it for the HCANN
fix I did, or you could just pull in the newest HCANN (5.0.0.Final)

As for the ClassNotFoundException, I really do not get this one.  So,
essentially:

1) hibernate-infinispan is able to access infinispan-core classes
2) hibernate-infinispan makes use of
this org/infinispan/commons/util/CloseableIteratorSet class as returned
from classes contained in infinispan-core.  I am not sure which jar
holds org/infinispan/commons/util/CloseableIteratorSet.
Anyone?
3) hibernate-infinispan is not able to access
org/infinispan/commons/util/CloseableIteratorSet

On Fri, May 29, 2015 at 11:57 AM, Scott Marlow <smarlow at redhat.com> wrote:

> Also am using Infinispan 7.2.1.Final but noticed that Infinispan
> 7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master
> to upgrade Infinispan.
>
> On 05/29/2015 12:50 PM, Scott Marlow wrote:
> > I ran part of the WildFly basic integration tests against the
> > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5 branch,
> > which includes the following Hibernate versions:
> >
> > ORM 5.0.0.CR1
> > HCA 4.0.5.Final
> > HS 5.2.0.Final
> >
> > I am seeing the below errors.
> >
> > 1. The Hibernate Search test
> >
> (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
> > is failing with an AbstractServiceMethodError
> http://pastebin.com/CzEgVp0L
> >
> > 2. In the
> >
> org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
> > we are seeing a "java.lang.ClassNotFoundException:
> > org.infinispan.commons.util.CloseableIteratorSet from [Module
> > "org.hibernate.infinispan:main"http://pastie.org/10213943
> >
> > Scott
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.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 May 29 14:06:55 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 13:06:55 -0500
Subject: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status
	update...
In-Reply-To: <CAFm4XO1rykkbc_W+6f+CYHTWtrX7BEA+7o-sUFaRbEoADWtoWw@mail.gmail.com>
References: <556898D2.8010103@redhat.com>
	<CAFm4XO1rykkbc_W+6f+CYHTWtrX7BEA+7o-sUFaRbEoADWtoWw@mail.gmail.com>
Message-ID: <CAFdSV9sKFdjNxC10J=MfJ9ueC4V0OfB_iLKdQJCPHgq+DMsFxw@mail.gmail.com>

On Fri, May 29, 2015 at 12:05 PM, Sanne Grinovero <sanne at hibernate.org>
wrote:

> 2. this is not expected, especially as I think the Infinispan version
> already in WF is aligned with the one in ORM5?
> Steve, do you remember about classloader strategy changes between
> latest ORM 4.3 and 5.0.0.CR1?


The only one that stands out to me is that 5.0 does absolutely zero
fiddling with the TCCL, whereas 4.3 did.  But 4.3 did that only during
bootstrap, here bootstrap is well over and done.  TBH this sounds much more
like a bad classpath definition on the part of WF/Jipijapa (see my earlier
reply)

From smarlow at redhat.com  Fri May 29 14:21:41 2015
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 29 May 2015 14:21:41 -0400
Subject: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status
 update...
In-Reply-To: <CAFdSV9vbfokiTJp_6iXSWgDSe747iju36qRzaJarkgp1ntMMoA@mail.gmail.com>
References: <556898D2.8010103@redhat.com>	<55689A8C.5080304@redhat.com>
	<CAFdSV9vbfokiTJp_6iXSWgDSe747iju36qRzaJarkgp1ntMMoA@mail.gmail.com>
Message-ID: <5568AE35.4010608@redhat.com>



On 05/29/2015 02:03 PM, Steve Ebersole wrote:
> Scott, first please use a SNAPSHOT build as you'll need it for the HCANN
> fix I did, or you could just pull in the newest HCANN (5.0.0.Final)

Will do.

>
> As for the ClassNotFoundException, I really do not get this one.  So,
> essentially:
>
> 1) hibernate-infinispan is able to access infinispan-core classes
> 2) hibernate-infinispan makes use of
> this org/infinispan/commons/util/CloseableIteratorSet class as returned
> from classes contained in infinispan-core.  I am not sure which jar
> holds org/infinispan/commons/util/CloseableIteratorSet.  Anyone?

infinispan-commons-7.2.1.Final.jar contains 
org.infinispan.commons.util.CloseableIteratorSet


> 3) hibernate-infinispan is not able to access
> org/infinispan/commons/util/CloseableIteratorSet
>
> On Fri, May 29, 2015 at 11:57 AM, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     Also am using Infinispan 7.2.1.Final but noticed that Infinispan
>     7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF master
>     to upgrade Infinispan.
>
>     On 05/29/2015 12:50 PM, Scott Marlow wrote:
>      > I ran part of the WildFly basic integration tests against the
>      > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5
>     branch,
>      > which includes the following Hibernate versions:
>      >
>      > ORM 5.0.0.CR1
>      > HCA 4.0.5.Final
>      > HS 5.2.0.Final
>      >
>      > I am seeing the below errors.
>      >
>      > 1. The Hibernate Search test
>      >
>     (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
>      > is failing with an AbstractServiceMethodError
>     http://pastebin.com/CzEgVp0L
>      >
>      > 2. In the
>      >
>     org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
>      > we are seeing a "java.lang.ClassNotFoundException:
>      > org.infinispan.commons.util.CloseableIteratorSet from [Module
>      > "org.hibernate.infinispan:main"http://pastie.org/10213943
>      >
>      > Scott
>      > _______________________________________________
>      > 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 <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>

From steve at hibernate.org  Fri May 29 14:39:54 2015
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 29 May 2015 18:39:54 +0000
Subject: [hibernate-dev] WildFly 10 + Hibernate ORM 5 integration status
	update...
In-Reply-To: <5568AE35.4010608@redhat.com>
References: <556898D2.8010103@redhat.com> <55689A8C.5080304@redhat.com>
	<CAFdSV9vbfokiTJp_6iXSWgDSe747iju36qRzaJarkgp1ntMMoA@mail.gmail.com>
	<5568AE35.4010608@redhat.com>
Message-ID: <CAFdSV9sPUJ=+p8J9_m+asNhANO2Vi9qgHkg8UbNsChsUKqz6fg@mail.gmail.com>

So:
1) hibernate-infinispan seems to be able to see infinispan-core (which is
what defines as a dependency)
2) hibernate-infinispan seems to not be able to see infinispan-commons
(which I would have to assume infinispan-core defines as a dependency)

This sure seems like a problem in the WF module/classpath set up...


On Fri, May 29, 2015 at 1:21 PM Scott Marlow <smarlow at redhat.com> wrote:

>
>
> On 05/29/2015 02:03 PM, Steve Ebersole wrote:
> > Scott, first please use a SNAPSHOT build as you'll need it for the HCANN
> > fix I did, or you could just pull in the newest HCANN (5.0.0.Final)
>
> Will do.
>
> >
> > As for the ClassNotFoundException, I really do not get this one.  So,
> > essentially:
> >
> > 1) hibernate-infinispan is able to access infinispan-core classes
> > 2) hibernate-infinispan makes use of
> > this org/infinispan/commons/util/CloseableIteratorSet class as returned
> > from classes contained in infinispan-core.  I am not sure which jar
> > holds org/infinispan/commons/util/CloseableIteratorSet.  Anyone?
>
> infinispan-commons-7.2.1.Final.jar contains
> org.infinispan.commons.util.CloseableIteratorSet
>
>
> > 3) hibernate-infinispan is not able to access
> > org/infinispan/commons/util/CloseableIteratorSet
> >
> > On Fri, May 29, 2015 at 11:57 AM, Scott Marlow <smarlow at redhat.com
> > <mailto:smarlow at redhat.com>> wrote:
> >
> >     Also am using Infinispan 7.2.1.Final but noticed that Infinispan
> >     7.2.2.Final is now in WildFly 10, so I'll sync my branch with WF
> master
> >     to upgrade Infinispan.
> >
> >     On 05/29/2015 12:50 PM, Scott Marlow wrote:
> >      > I ran part of the WildFly basic integration tests against the
> >      > https://github.com/scottmarlow/wildfly/tree/jipijapa3_hibernate5
> >     branch,
> >      > which includes the following Hibernate versions:
> >      >
> >      > ORM 5.0.0.CR1
> >      > HCA 4.0.5.Final
> >      > HS 5.2.0.Final
> >      >
> >      > I am seeing the below errors.
> >      >
> >      > 1. The Hibernate Search test
> >      >
> >
>  (org.jboss.as.test.integration.hibernate.search.HibernateSearchJPATestCase)
> >      > is failing with an AbstractServiceMethodError
> >     http://pastebin.com/CzEgVp0L
> >      >
> >      > 2. In the
> >      >
> >
>  org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase.testEvictEntityCache,
> >      > we are seeing a "java.lang.ClassNotFoundException:
> >      > org.infinispan.commons.util.CloseableIteratorSet from [Module
> >      > "org.hibernate.infinispan:main"http://pastie.org/10213943
> >      >
> >      > Scott
> >      > _______________________________________________
> >      > 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 <mailto:hibernate-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>

From brmeyer at redhat.com  Fri May 29 23:36:31 2015
From: brmeyer at redhat.com (Brett Meyer)
Date: Fri, 29 May 2015 23:36:31 -0400 (EDT)
Subject: [hibernate-dev] HSearch + Tika bridge using Wildfly modules
In-Reply-To: <CAFm4XO0sd-iDn-VPvjFJ4OzY+fadDx+sihmNrExrMkJX5CEx9Q@mail.gmail.com>
References: <1663839921.8674641.1432909533929.JavaMail.zimbra@redhat.com>
	<650952943.8677484.1432909719158.JavaMail.zimbra@redhat.com>
	<CAFm4XO0sd-iDn-VPvjFJ4OzY+fadDx+sihmNrExrMkJX5CEx9Q@mail.gmail.com>
Message-ID: <586396569.9056717.1432956991219.JavaMail.zimbra@redhat.com>

Sanne, I might still be missing something.  Artificer's war does not include any Hibernate ORM, Hibernate Search, or Tika jars.  For Wildfly 8.2, the war's jboss-deployment-structure.xml includes:

<module name="org.hibernate.search.orm" /> (includes tika-parsers-1.6.jar)
<module name="org.apache.tika" slot="1.6"/>
(Also using the org.hibernate module, but that's implicitly added by Wildfly.)

I understand what you're saying about the ORM classloader, but the above still didn't work.  I'm admittedly a little fuzzy on WF module classloading, but I'm wondering if that's not actually making its way into the ORM classloader, even though my war is the persistence unit.

However:

What *does* work is adding '<module name="org.apache.tika" slot="1.6"/>' directly in org.hibernate.search.engine's module.xml.

Apologies if 1.) I'm missing something and/or 2.) that's expected.  I can certainly tweak org.hibernate.search.engine's module.xml with our installer, but that's obviously less than desirable.  Any idea what we might be missing that would allow us to get that to work from the app itself?

Thanks for the help!

----- Original Message -----
> From: "Sanne Grinovero" <sanne at hibernate.org>
> To: "Brett Meyer" <brmeyer at redhat.com>
> Cc: "Hibernate.org" <hibernate-dev at lists.jboss.org>
> Sent: Friday, May 29, 2015 11:00:12 AM
> Subject: Re: HSearch + Tika bridge using Wildfly modules
> 
> Hi Brett,
> we don't include all existing analysers and extensions within the
> WildFly modules. In particular the Apache Tika libraries have a huge
> amount of dependencies, you should choose the ones you need depending
> on what kind of media you intend to parse.
> 
> Include any extension in your "application", we use the Hibernate ORM
> classloader to lookup for extensions so these should be discoverable
> if they are visible to the same classloader having your entities and
> other extensions.
> 
> Sanne
> 
> On 29 May 2015 at 15:28, Brett Meyer <brmeyer at redhat.com> wrote:
> > Hey Sanne!  Artificer has '<module name="org.hibernate.search.orm"
> > services="export" />' defined in its jboss-deployment-structure
> > dependencies.  But, when we try to use it, the following happens.
> >
> > Caused by: java.lang.ClassNotFoundException: org.apache.tika.parser.Parser
> > from [Module "org.hibernate.search.engine:main" from local module loader
> > @6cf76647 (finder: local module finder @665bf734 (roots:
> > /home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules,/home/brmeyer/IdeaProjects/artificer/installer/target/wildfly-8.2.0.Final/modules/system/layers/base))]
> >
> > One of our entities uses the built-in TikaBridge.  I figured the search.orm
> > module would bring the necessary Tika jars in with it.  Is there something
> > else we need to add?
> 

From sanne at hibernate.org  Sat May 30 20:47:27 2015
From: sanne at hibernate.org (Sanne Grinovero)
Date: Sun, 31 May 2015 01:47:27 +0100
Subject: [hibernate-dev] Hibernate Search for Hibernate 5 - status
Message-ID: <CAFm4XO3Scf0e==wBA0PzkXWYwfZZdt_jDHLHRejmNMgOUstsdQ@mail.gmail.com>

I'm concerned about seeing issues like this one being reported:
 - https://hibernate.atlassian.net/browse/HHH-9832

I don't think it's acceptable we withhold an Hibernate 5 compatible
version of Hibernate Search for much longer.

I have a working branch of Hibernate Search "on hold" since a while
which is compiling and passing all tests successfully up to the point
of WildFly integration tests, as I could not find a way yet to run the
tests using modules and override the Hibernate ORM version (see the
wildfly-dev mailing list for details).

It was not viable either to keep this Hibernate Search branch
backwards compatible with the Hibernate ORM version 4.3 as included in
available WildFly releases.
Also since I was focusing on the WildFly roadblock so far, the branch
still needs a bit of work, for example I didn't face the OSGi tests
yet.

The "theme" for current development branch - Hibernate Search 5.3 - so
far was about the great new faceting improvements. As I discussed with
Hardy, we'd like to polish that branch for a release, so include only
necessary wrap up and fixing any reported regression, but focus
aggressively already on a new minor branch so that we could release an
ORM5 compatible Alpha in short time.
We could even consider working on a 5.3 and 5.4 in parallel.

Would you all be ok in a quick release - probably named 5.4.0.Alpha1 -
of Hibernate Search to be compatible with ORM5 and omit publishing the
modules for WildFly? That would be useful for WildFly 10 too, so they
can include the new libraries and ORM 5, breaking the cycle.

As a next step we'll see also about breaking those cycles permanently;
e.g. Hardy suggested to release modules and feature packs for WildFly
as an independent cycle, and I like that although we can keep that
decision for a post 5.4.

Thanks,
Sanne

From guillaume.smet at gmail.com  Sun May 31 05:35:00 2015
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Sun, 31 May 2015 11:35:00 +0200
Subject: [hibernate-dev] Hibernate Search for Hibernate 5 - status
In-Reply-To: <CAFm4XO3Scf0e==wBA0PzkXWYwfZZdt_jDHLHRejmNMgOUstsdQ@mail.gmail.com>
References: <CAFm4XO3Scf0e==wBA0PzkXWYwfZZdt_jDHLHRejmNMgOUstsdQ@mail.gmail.com>
Message-ID: <CALt0+o8dzFVNi1WdtJBkDykJSjmBZksh3j46tmMKXW2Vv0AsAw@mail.gmail.com>

Hi Sanne,

On Sun, May 31, 2015 at 2:47 AM, Sanne Grinovero <sanne at hibernate.org>
wrote:
>
> I don't think it's acceptable we withhold an Hibernate 5 compatible
> version of Hibernate Search for much longer.
>

FWIW, I'm waiting for this to test Hibernate 5 on our applications and
provide feedback from the field on ORM 5. All our applications are highly
dependent on Search.

So, it would be nice to have an alpha of Search to test all this!

-- 
Guillaume