From k.alqinyah at gmail.com  Fri May  2 03:42:53 2014
From: k.alqinyah at gmail.com (Khalid Alqinyah)
Date: Fri, 2 May 2014 15:42:53 +0800
Subject: [hibernate-dev] GSoC Introduction
Message-ID: <CAJf9WpL9pibUZmL7iF8kWj8fLEHkEgum2ZH2yD98+3xwSTmgOA@mail.gmail.com>

Hi all,

My name is Khalid Alqinyah.

I'll be working on 'HV-825 Integration with Java 8' as part of Google
Summer of Code 2014. I'll be mentored by Gunnar and Hardy.

Looking forward to this project and working with the dev team.

/Khalid

From sanne at hibernate.org  Fri May  2 05:30:15 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 2 May 2014 10:30:15 +0100
Subject: [hibernate-dev] GSoC Introduction
In-Reply-To: <CAJf9WpL9pibUZmL7iF8kWj8fLEHkEgum2ZH2yD98+3xwSTmgOA@mail.gmail.com>
References: <CAJf9WpL9pibUZmL7iF8kWj8fLEHkEgum2ZH2yD98+3xwSTmgOA@mail.gmail.com>
Message-ID: <CAFm4XO0S60s+W_tCBHWKLiOsCsrt8Y_towPT4X7LhQFzY-qfaw@mail.gmail.com>

Hi Khalid,
that's great news, welcome!

Sanne

On 2 May 2014 08:42, Khalid Alqinyah <k.alqinyah at gmail.com> wrote:
> Hi all,
>
> My name is Khalid Alqinyah.
>
> I'll be working on 'HV-825 Integration with Java 8' as part of Google
> Summer of Code 2014. I'll be mentored by Gunnar and Hardy.
>
> Looking forward to this project and working with the dev team.
>
> /Khalid
> _______________________________________________
> 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  2 05:34:05 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 2 May 2014 11:34:05 +0200
Subject: [hibernate-dev] GSoC Introduction
In-Reply-To: <CAFm4XO0S60s+W_tCBHWKLiOsCsrt8Y_towPT4X7LhQFzY-qfaw@mail.gmail.com>
References: <CAJf9WpL9pibUZmL7iF8kWj8fLEHkEgum2ZH2yD98+3xwSTmgOA@mail.gmail.com>
	<CAFm4XO0S60s+W_tCBHWKLiOsCsrt8Y_towPT4X7LhQFzY-qfaw@mail.gmail.com>
Message-ID: <CADGJaX_zBfwb6JF0ensp3d09J9q5VNPe2P0JS0FVJoAg7NcTeg@mail.gmail.com>

2014-05-02 11:30 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:

> Hi Khalid,
> that's great news, welcome!
>

Welcome again and looking forward to your contributions, Khalid; I'm very
excited about this GSoC project becoming a reality!

--Gunnar



> Sanne
>
> On 2 May 2014 08:42, Khalid Alqinyah <k.alqinyah at gmail.com> wrote:
> > Hi all,
> >
> > My name is Khalid Alqinyah.
> >
> > I'll be working on 'HV-825 Integration with Java 8' as part of Google
> > Summer of Code 2014. I'll be mentored by Gunnar and Hardy.
> >
> > Looking forward to this project and working with the dev team.
> >
> > /Khalid
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.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 daltodavide at gmail.com  Fri May  2 05:41:26 2014
From: daltodavide at gmail.com (Davide D'Alto)
Date: Fri, 2 May 2014 10:41:26 +0100
Subject: [hibernate-dev] GSoC Introduction
In-Reply-To: <CADGJaX_zBfwb6JF0ensp3d09J9q5VNPe2P0JS0FVJoAg7NcTeg@mail.gmail.com>
References: <CAJf9WpL9pibUZmL7iF8kWj8fLEHkEgum2ZH2yD98+3xwSTmgOA@mail.gmail.com>
	<CAFm4XO0S60s+W_tCBHWKLiOsCsrt8Y_towPT4X7LhQFzY-qfaw@mail.gmail.com>
	<CADGJaX_zBfwb6JF0ensp3d09J9q5VNPe2P0JS0FVJoAg7NcTeg@mail.gmail.com>
Message-ID: <CANoTJYNsa+1UvRjfqci=NQcccnsuAHbg6Uz4wHWKOtsZWhQZrA@mail.gmail.com>

Welcome Kahlid!


On Fri, May 2, 2014 at 10:34 AM, Gunnar Morling <gunnar at hibernate.org>wrote:

> 2014-05-02 11:30 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
> > Hi Khalid,
> > that's great news, welcome!
> >
>
> Welcome again and looking forward to your contributions, Khalid; I'm very
> excited about this GSoC project becoming a reality!
>
> --Gunnar
>
>
>
> > Sanne
> >
> > On 2 May 2014 08:42, Khalid Alqinyah <k.alqinyah at gmail.com> wrote:
> > > Hi all,
> > >
> > > My name is Khalid Alqinyah.
> > >
> > > I'll be working on 'HV-825 Integration with Java 8' as part of Google
> > > Summer of Code 2014. I'll be mentored by Gunnar and Hardy.
> > >
> > > Looking forward to this project and working with the dev team.
> > >
> > > /Khalid
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Fri May  2 05:49:32 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 2 May 2014 11:49:32 +0200
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <CADGJaX_1jrYVozYTV-k66c4qXwJAqBPSy7i8M=33XFwQhNZY5A@mail.gmail.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
	<CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>
	<CADGJaX-24cbXJePWoECZ=S-d2wWQ=kT78bLm2epxkj4AKpJGGw@mail.gmail.com>
	<CADGJaX_=gzjz5NQdJsUTiXW815mTHV9EGC7DxqwQvpu9sDpg0g@mail.gmail.com>
	<CAFm4XO3rpbFKXgUS=40jkZ4EjLhzt7daoGU88y0YGMZhGHFWRA@mail.gmail.com>
	<CADGJaX_1jrYVozYTV-k66c4qXwJAqBPSy7i8M=33XFwQhNZY5A@mail.gmail.com>
Message-ID: <CADGJaX_iwiunu3-PRTAOV8OFsgedOrgyShKi3j2+o-V-StfYgA@mail.gmail.com>

Hi,

I've added our Summit demo on OGM, you can find it at [1].

The demo comes with a thorough README, so if you got a minute and want to
see Hibernate OGM in action (running on WildFly/EAP, locally or on
OpenShift, using Bean Validation, JAX-RS and AngularJS), give it a try.

There are some 3rd party JS/CSS libraries (Angular, Bootstrap etc.) checked
in which don't have the ASF2 license but the MIT license. The file headers
state their license and I've added a note to the main README saying:

    "If not stated otherwise, the demos are licensed under the Apache
License, Version 2.0. Refer to the headers of individual files for specific
license and copyright information, in particular of included library files."

Let me know in case there is a problem with that.

--Gunnar

[1]
https://github.com/hibernate/hibernate-demos/tree/master/hibernate-ogm/hiking-demo


2014-04-29 11:34 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> 2014-04-29 11:19 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> Created https://github.com/hibernate/hibernate-demos
>
>
> Cool, thanks.
>
> License: I've picked ASL2.. I guess that's ok for all our demos?
>>
>
> That seems reasonable to me.
>
>
>>
>> On 29 April 2014 07:00, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > 2014-04-29 7:58 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>> >
>> >> 2014-04-29 0:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >>> Nice idea!
>> >>> we could have each demo in a separate directory and put some
>> >>> description for each in the root readme file.
>> >>
>> >>
>> >> +1
>> >>
>> >>> But also the most polished demos, like if something evolves in being
>> >>> extemely polished and well documented, should eventually be promoted
>> >>> for inclusion in http://www.jboss.org/jdf/ . So I'd consider this
>> more
>> >>> of a lean sandbox, not something too formal? Or do we want to build
>> >>> something to be pointed at from our documentation? That would
>> >>> implicitly require some review and testing process at least.
>> >>
>> >>
>> >> For now I had something rather informal in mind. Just a place where
>> people
>> >> attending one of our talks can go and try out a demo themselves.
>> >>
>> >> Of course individual demos from this "sandbox" may evolve over time
>> into a
>> >> part of JDF or become part of the official documentation. As you say,
>> that'd
>> >> require more polishing and documentation, but also updating to stay in
>> sync
>> >> with the latest versions of our projects.
>> >
>> >
>> > That said, if we agree on the idea, could you create a "hibernate-demos"
>> > repository under the "hibernate" organization? I'm lacking the
>> permission to
>> > do so. I'll then add our demo and the root readme file so others can
>> follow.
>> >
>> >>
>> >>
>> >> --Gunnar
>> >>
>> >>> Sanne
>> >>>
>> >>>
>> >>> On 28 April 2014 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
>> >>> > +1
>> >>> >
>> >>> >
>> >>> > On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com>
>> >>> > wrote:
>> >>> >
>> >>> >> +1 from me.  I have several to contribute as well from various ORM
>> >>> >> presentations.
>> >>> >>
>> >>> >> https://github.com/brmeyer/HibernateDemos
>> >>> >>
>> >>> >> ----- Original Message -----
>> >>> >> From: "Gunnar Morling" <gunnar at hibernate.org>
>> >>> >> To: hibernate-dev at lists.jboss.org
>> >>> >> Sent: Monday, April 28, 2014 10:49:19 AM
>> >>> >> Subject: [hibernate-dev] GitHub repo for demo projects
>> >>> >>
>> >>> >> Hi,
>> >>> >>
>> >>> >> Together with Sanne I've been creating a demo app which shows some
>> >>> >> features
>> >>> >> of Hibernate OGM.
>> >>> >>
>> >>> >> Right now this lives under my personal account on GitHub, but IMO
>> it'd
>> >>> >> make
>> >>> >> sense to move it somewhere under https://github.com/hibernate/ to
>> make
>> >>> >> it
>> >>> >> more visible, encourage re-use and contributions by others etc.
>> >>> >>
>> >>> >> What do you think about creating a repo under the hibernate
>> >>> >> organization
>> >>> >> such as "hibernate-demos" which could host this and other demos for
>> >>> >> our
>> >>> >> projects in the future? Or would it even make more sense on a
>> >>> >> per-project
>> >>> >> base ("hibernate-ogm-demos" etc.)?
>> >>> >>
>> >>> >> --Gunnar
>> >>> >>
>> >>> >> [1] https://github.com/gunnarmorling/ogm-hiking-demo
>> >>> >> _______________________________________________
>> >>> >> hibernate-dev mailing list
>> >>> >> hibernate-dev at lists.jboss.org
>> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> >> _______________________________________________
>> >>> >> hibernate-dev mailing list
>> >>> >> hibernate-dev at lists.jboss.org
>> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> >>
>> >>> > _______________________________________________
>> >>> > hibernate-dev mailing list
>> >>> > hibernate-dev at lists.jboss.org
>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From gunnar at hibernate.org  Fri May  2 05:55:49 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 2 May 2014 11:55:49 +0200
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <775298646.14143302.1398781417803.JavaMail.zimbra@redhat.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<433255762.13249435.1398697430255.JavaMail.zimbra@redhat.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
	<CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>
	<CADGJaX-24cbXJePWoECZ=S-d2wWQ=kT78bLm2epxkj4AKpJGGw@mail.gmail.com>
	<CADGJaX_=gzjz5NQdJsUTiXW815mTHV9EGC7DxqwQvpu9sDpg0g@mail.gmail.com>
	<CAFm4XO3rpbFKXgUS=40jkZ4EjLhzt7daoGU88y0YGMZhGHFWRA@mail.gmail.com>
	<775298646.14143302.1398781417803.JavaMail.zimbra@redhat.com>
Message-ID: <CADGJaX9MEHMxdAq6EkLE4j_yU7hDq+dVuEsKddOfWt--J30sdQ@mail.gmail.com>

2014-04-29 16:23 GMT+02:00 Brett Meyer <brmeyer at redhat.com>:

> While we're on this subject, it's been suggested that having simple
> quickstart projects for testcase development would be helpful.  For
> example, see https://hibernate.atlassian.net/browse/HHH-9105.  Big +1
> from me -- it would be great to point JIRA reporters towards the quickstart
> when asking for a reproducer.


+1 It's a great and very helpful idea to simplify the creation of bug
reports / test cases.

Where should we control those?  /hibernate-testcase-quickstarts?
>

Which repo would that be, "hibernate-orm" in the case of ORM? How do you
intend this to be used, would people fork this, or should the copy&paste
that quickstart?

For Maven one could create an archetype for Hibernate bug report projects;
People could then create a project from that template using a single
command. Not sure what's an equivalent concept in the Gradle universe.


> ----- Original Message -----
> From: "Sanne Grinovero" <sanne at hibernate.org>
> To: "Gunnar Morling" <gunnar at hibernate.org>
> Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
> Sent: Tuesday, April 29, 2014 5:19:38 AM
> Subject: Re: [hibernate-dev] GitHub repo for demo projects
>
> Created https://github.com/hibernate/hibernate-demos
>
> License: I've picked ASL2.. I guess that's ok for all our demos?
>
> On 29 April 2014 07:00, Gunnar Morling <gunnar at hibernate.org> wrote:
> > 2014-04-29 7:58 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
> >
> >> 2014-04-29 0:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >>
> >>> Nice idea!
> >>> we could have each demo in a separate directory and put some
> >>> description for each in the root readme file.
> >>
> >>
> >> +1
> >>
> >>> But also the most polished demos, like if something evolves in being
> >>> extemely polished and well documented, should eventually be promoted
> >>> for inclusion in http://www.jboss.org/jdf/ . So I'd consider this more
> >>> of a lean sandbox, not something too formal? Or do we want to build
> >>> something to be pointed at from our documentation? That would
> >>> implicitly require some review and testing process at least.
> >>
> >>
> >> For now I had something rather informal in mind. Just a place where
> people
> >> attending one of our talks can go and try out a demo themselves.
> >>
> >> Of course individual demos from this "sandbox" may evolve over time
> into a
> >> part of JDF or become part of the official documentation. As you say,
> that'd
> >> require more polishing and documentation, but also updating to stay in
> sync
> >> with the latest versions of our projects.
> >
> >
> > That said, if we agree on the idea, could you create a "hibernate-demos"
> > repository under the "hibernate" organization? I'm lacking the
> permission to
> > do so. I'll then add our demo and the root readme file so others can
> follow.
> >
> >>
> >>
> >> --Gunnar
> >>
> >>> Sanne
> >>>
> >>>
> >>> On 28 April 2014 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
> >>> > +1
> >>> >
> >>> >
> >>> > On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com>
> >>> > wrote:
> >>> >
> >>> >> +1 from me.  I have several to contribute as well from various ORM
> >>> >> presentations.
> >>> >>
> >>> >> https://github.com/brmeyer/HibernateDemos
> >>> >>
> >>> >> ----- Original Message -----
> >>> >> From: "Gunnar Morling" <gunnar at hibernate.org>
> >>> >> To: hibernate-dev at lists.jboss.org
> >>> >> Sent: Monday, April 28, 2014 10:49:19 AM
> >>> >> Subject: [hibernate-dev] GitHub repo for demo projects
> >>> >>
> >>> >> Hi,
> >>> >>
> >>> >> Together with Sanne I've been creating a demo app which shows some
> >>> >> features
> >>> >> of Hibernate OGM.
> >>> >>
> >>> >> Right now this lives under my personal account on GitHub, but IMO
> it'd
> >>> >> make
> >>> >> sense to move it somewhere under https://github.com/hibernate/ to
> make
> >>> >> it
> >>> >> more visible, encourage re-use and contributions by others etc.
> >>> >>
> >>> >> What do you think about creating a repo under the hibernate
> >>> >> organization
> >>> >> such as "hibernate-demos" which could host this and other demos for
> >>> >> our
> >>> >> projects in the future? Or would it even make more sense on a
> >>> >> per-project
> >>> >> base ("hibernate-ogm-demos" etc.)?
> >>> >>
> >>> >> --Gunnar
> >>> >>
> >>> >> [1] https://github.com/gunnarmorling/ogm-hiking-demo
> >>> >> _______________________________________________
> >>> >> hibernate-dev mailing list
> >>> >> hibernate-dev at lists.jboss.org
> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >> _______________________________________________
> >>> >> hibernate-dev mailing list
> >>> >> hibernate-dev at lists.jboss.org
> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> >>
> >>> > _______________________________________________
> >>> > hibernate-dev mailing list
> >>> > hibernate-dev at lists.jboss.org
> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>> _______________________________________________
> >>> hibernate-dev mailing list
> >>> hibernate-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> >>
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From brmeyer at redhat.com  Fri May  2 14:19:24 2014
From: brmeyer at redhat.com (Brett Meyer)
Date: Fri, 2 May 2014 14:19:24 -0400 (EDT)
Subject: [hibernate-dev] GitHub repo for demo projects
In-Reply-To: <CADGJaX_iwiunu3-PRTAOV8OFsgedOrgyShKi3j2+o-V-StfYgA@mail.gmail.com>
References: <CADGJaX9P_CikxL8xLBqW1eBYTnYtrunymHL3KjheWJxxbu-g0A@mail.gmail.com>
	<CANoTJYO5jHUtwAGaTZK3yZ9UBC3J6uR6VznUU35fT7_v7jfgSw@mail.gmail.com>
	<CAFm4XO28XG4OZL90Ykj_mYZvmScZ4ivK9gTpeEjT9L3e_pDAAw@mail.gmail.com>
	<CADGJaX-24cbXJePWoECZ=S-d2wWQ=kT78bLm2epxkj4AKpJGGw@mail.gmail.com>
	<CADGJaX_=gzjz5NQdJsUTiXW815mTHV9EGC7DxqwQvpu9sDpg0g@mail.gmail.com>
	<CAFm4XO3rpbFKXgUS=40jkZ4EjLhzt7daoGU88y0YGMZhGHFWRA@mail.gmail.com>
	<CADGJaX_1jrYVozYTV-k66c4qXwJAqBPSy7i8M=33XFwQhNZY5A@mail.gmail.com>
	<CADGJaX_iwiunu3-PRTAOV8OFsgedOrgyShKi3j2+o-V-StfYgA@mail.gmail.com>
Message-ID: <337378844.16537416.1399054764483.JavaMail.zimbra@redhat.com>

Gunnar, thanks for getting things started!  I just added my suite (originally from my repo [1]) of ORM demos that I've used in various talks.  Admittedly, a few of them are a bit rough, so I'm definitely up for suggestions from the community!  I added:

Basic: simple comparison between JDBC, ORM, and JPA
Fetching Strategies: "when" (laziness) and "how" (fetch style)
Value Generation: annotations allowing in-memory and DB generated properties, both for INSERT and INSERT/UPDATE actions
Multi-Tenancy: multiple, concurrent databases and clients from a single Hibernate instance
Caching: entity second level cache (2LC) and query cache
Envers: historical/audited data
Spatial: geographical data

[1] https://github.com/brmeyer/HibernateDemos

----- Original Message -----
From: "Gunnar Morling" <gunnar at hibernate.org>
To: "Gunnar Morling" <gunnar at hibernate.org>
Cc: "hibernate-dev" <hibernate-dev at lists.jboss.org>
Sent: Friday, May 2, 2014 5:49:32 AM
Subject: Re: [hibernate-dev] GitHub repo for demo projects

Hi,

I've added our Summit demo on OGM, you can find it at [1].

The demo comes with a thorough README, so if you got a minute and want to
see Hibernate OGM in action (running on WildFly/EAP, locally or on
OpenShift, using Bean Validation, JAX-RS and AngularJS), give it a try.

There are some 3rd party JS/CSS libraries (Angular, Bootstrap etc.) checked
in which don't have the ASF2 license but the MIT license. The file headers
state their license and I've added a note to the main README saying:

    "If not stated otherwise, the demos are licensed under the Apache
License, Version 2.0. Refer to the headers of individual files for specific
license and copyright information, in particular of included library files."

Let me know in case there is a problem with that.

--Gunnar

[1]
https://github.com/hibernate/hibernate-demos/tree/master/hibernate-ogm/hiking-demo


2014-04-29 11:34 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:

> 2014-04-29 11:19 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>
>> Created https://github.com/hibernate/hibernate-demos
>
>
> Cool, thanks.
>
> License: I've picked ASL2.. I guess that's ok for all our demos?
>>
>
> That seems reasonable to me.
>
>
>>
>> On 29 April 2014 07:00, Gunnar Morling <gunnar at hibernate.org> wrote:
>> > 2014-04-29 7:58 GMT+02:00 Gunnar Morling <gunnar at hibernate.org>:
>> >
>> >> 2014-04-29 0:21 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>> >>
>> >>> Nice idea!
>> >>> we could have each demo in a separate directory and put some
>> >>> description for each in the root readme file.
>> >>
>> >>
>> >> +1
>> >>
>> >>> But also the most polished demos, like if something evolves in being
>> >>> extemely polished and well documented, should eventually be promoted
>> >>> for inclusion in http://www.jboss.org/jdf/ . So I'd consider this
>> more
>> >>> of a lean sandbox, not something too formal? Or do we want to build
>> >>> something to be pointed at from our documentation? That would
>> >>> implicitly require some review and testing process at least.
>> >>
>> >>
>> >> For now I had something rather informal in mind. Just a place where
>> people
>> >> attending one of our talks can go and try out a demo themselves.
>> >>
>> >> Of course individual demos from this "sandbox" may evolve over time
>> into a
>> >> part of JDF or become part of the official documentation. As you say,
>> that'd
>> >> require more polishing and documentation, but also updating to stay in
>> sync
>> >> with the latest versions of our projects.
>> >
>> >
>> > That said, if we agree on the idea, could you create a "hibernate-demos"
>> > repository under the "hibernate" organization? I'm lacking the
>> permission to
>> > do so. I'll then add our demo and the root readme file so others can
>> follow.
>> >
>> >>
>> >>
>> >> --Gunnar
>> >>
>> >>> Sanne
>> >>>
>> >>>
>> >>> On 28 April 2014 16:28, Davide D'Alto <daltodavide at gmail.com> wrote:
>> >>> > +1
>> >>> >
>> >>> >
>> >>> > On Mon, Apr 28, 2014 at 4:03 PM, Brett Meyer <brmeyer at redhat.com>
>> >>> > wrote:
>> >>> >
>> >>> >> +1 from me.  I have several to contribute as well from various ORM
>> >>> >> presentations.
>> >>> >>
>> >>> >> https://github.com/brmeyer/HibernateDemos
>> >>> >>
>> >>> >> ----- Original Message -----
>> >>> >> From: "Gunnar Morling" <gunnar at hibernate.org>
>> >>> >> To: hibernate-dev at lists.jboss.org
>> >>> >> Sent: Monday, April 28, 2014 10:49:19 AM
>> >>> >> Subject: [hibernate-dev] GitHub repo for demo projects
>> >>> >>
>> >>> >> Hi,
>> >>> >>
>> >>> >> Together with Sanne I've been creating a demo app which shows some
>> >>> >> features
>> >>> >> of Hibernate OGM.
>> >>> >>
>> >>> >> Right now this lives under my personal account on GitHub, but IMO
>> it'd
>> >>> >> make
>> >>> >> sense to move it somewhere under https://github.com/hibernate/ to
>> make
>> >>> >> it
>> >>> >> more visible, encourage re-use and contributions by others etc.
>> >>> >>
>> >>> >> What do you think about creating a repo under the hibernate
>> >>> >> organization
>> >>> >> such as "hibernate-demos" which could host this and other demos for
>> >>> >> our
>> >>> >> projects in the future? Or would it even make more sense on a
>> >>> >> per-project
>> >>> >> base ("hibernate-ogm-demos" etc.)?
>> >>> >>
>> >>> >> --Gunnar
>> >>> >>
>> >>> >> [1] https://github.com/gunnarmorling/ogm-hiking-demo
>> >>> >> _______________________________________________
>> >>> >> hibernate-dev mailing list
>> >>> >> hibernate-dev at lists.jboss.org
>> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> >> _______________________________________________
>> >>> >> hibernate-dev mailing list
>> >>> >> hibernate-dev at lists.jboss.org
>> >>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> >>
>> >>> > _______________________________________________
>> >>> > hibernate-dev mailing list
>> >>> > hibernate-dev at lists.jboss.org
>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> _______________________________________________
>> >>> hibernate-dev mailing list
>> >>> hibernate-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>
>> >>
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev at lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gbadner at redhat.com  Fri May  2 19:15:06 2014
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 2 May 2014 19:15:06 -0400 (EDT)
Subject: [hibernate-dev] GSoC Introduction
In-Reply-To: <CANoTJYNsa+1UvRjfqci=NQcccnsuAHbg6Uz4wHWKOtsZWhQZrA@mail.gmail.com>
References: <CAJf9WpL9pibUZmL7iF8kWj8fLEHkEgum2ZH2yD98+3xwSTmgOA@mail.gmail.com>
	<CAFm4XO0S60s+W_tCBHWKLiOsCsrt8Y_towPT4X7LhQFzY-qfaw@mail.gmail.com>
	<CADGJaX_zBfwb6JF0ensp3d09J9q5VNPe2P0JS0FVJoAg7NcTeg@mail.gmail.com>
	<CANoTJYNsa+1UvRjfqci=NQcccnsuAHbg6Uz4wHWKOtsZWhQZrA@mail.gmail.com>
Message-ID: <1131841821.18647857.1399072506735.JavaMail.zimbra@redhat.com>

Welcome! :)

----- Original Message -----
> From: "Davide D'Alto" <daltodavide at gmail.com>
> To: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Friday, May 2, 2014 2:41:26 AM
> Subject: Re: [hibernate-dev] GSoC Introduction
> 
> Welcome Kahlid!
> 
> 
> On Fri, May 2, 2014 at 10:34 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
> 
> > 2014-05-02 11:30 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
> >
> > > Hi Khalid,
> > > that's great news, welcome!
> > >
> >
> > Welcome again and looking forward to your contributions, Khalid; I'm very
> > excited about this GSoC project becoming a reality!
> >
> > --Gunnar
> >
> >
> >
> > > Sanne
> > >
> > > On 2 May 2014 08:42, Khalid Alqinyah <k.alqinyah at gmail.com> wrote:
> > > > Hi all,
> > > >
> > > > My name is Khalid Alqinyah.
> > > >
> > > > I'll be working on 'HV-825 Integration with Java 8' as part of Google
> > > > Summer of Code 2014. I'll be mentored by Gunnar and Hardy.
> > > >
> > > > Looking forward to this project and working with the dev team.
> > > >
> > > > /Khalid
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.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  Sat May  3 10:45:34 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Sat, 3 May 2014 09:45:34 -0500
Subject: [hibernate-dev] Build failure executing
	:hibernate-core:runAnnotationProcessors
In-Reply-To: <BLU170-W70926413B0CC9FD4C6872AD5410@phx.gbl>
References: <BLU170-W70926413B0CC9FD4C6872AD5410@phx.gbl>
Message-ID: <CAFdSV9sJU0u4ctuGXHrFWHHem3XNDR3rT4SYuc9RLFP=2eEk-Q@mail.gmail.com>

Are you using a local Gradle install, or the Gradle Wrapper?  If a local
Gradle install, which version?


On Wed, Apr 30, 2014 at 3:10 PM, Mahesh Gadgil <maheshgadgil at hotmail.com>wrote:

> I am facing the same issue Gale Badner mentioned in his email
> (hibernate-core:runAnnotationProcessors - BUILD FAILED) -
> Gail Badner Fri, 28 Mar 2014 16:35:18 -0700.
> but unlike him I am unable to resolve the issue. I am using java 1.7.0_51
> and tried to compile 4.3 branch.
>
> ThanksMahesh
> _______________________________________________
> 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  6 10:01:06 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 6 May 2014 09:01:06 -0500
Subject: [hibernate-dev] Jandex, scanning and discovery
In-Reply-To: <CAFdSV9tbahgiSWsThjW+WMnCoUhEJ+zb9WhP2UJPcScLJk9FTg@mail.gmail.com>
References: <CAFdSV9tMbyjDE5qdAHhBUvTaXNC5W-YSAsvnfr3uXbJRS2UUWA@mail.gmail.com>
	<13900ADC-5394-44A3-AFB7-591F2121E766@hibernate.org>
	<CAFdSV9uwPrc4Oa0UGjOus9C3Pe71Av_dDB=2SXu2zFNAve_hoA@mail.gmail.com>
	<901F31BB-98CC-4704-8B38-DF633A62030C@hibernate.org>
	<CAFdSV9uYjXNScDk_Pz67gmqPoZkBF7_q=w7y9B7bmSAMZta3bA@mail.gmail.com>
	<CAFdSV9sjvGvifJkU+Bpk7QPpHpvR65zJBJC0d3XbE87Lqx6zuQ@mail.gmail.com>
	<486345A4-6720-425E-8606-04B2D4BD732F@hibernate.org>
	<CAFdSV9tbahgiSWsThjW+WMnCoUhEJ+zb9WhP2UJPcScLJk9FTg@mail.gmail.com>
Message-ID: <CAFdSV9uRPEDL5STcVhr9Xmyp+805HPTeUa8Rinhd0Yrm-mbf4Q@mail.gmail.com>

FYI, I created a Pull Request[1] to discuss these changes if anyone was
interested.  If not I'll apply this later in the week.  The commits
incorporate some other concepts such as some changes to "user directed
logging" I discussed in hibernate-dev emails.  I have added some line
comments at important stuff.

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


On Wed, Apr 30, 2014 at 12:30 PM, Steve Ebersole <steve at hibernate.org>wrote:

> I am contemplating something very drastic here.  The back story is that we
> end up needing to index stuff from 2 places: the
> EntityManagerFactoryBuilder and again from MetadataBuildingProcess (part of
> Binder processing).  The indexing from EntityManagerFactoryBuilder happens
> just during JPA bootstrapping.  The indexing from MetadataBuildingProcess
> happens for both.  The difficulty this presents is that we end up needing
> to pass the same Indexer to both.
>
> What I started thinking would be better is to perform all the indexing
> from MetadataBuildingProcess.  But given the idea to perform a full index
> of all classes as we scan, that would also mean moving scanning
> into MetadataBuildingProcess.  Which I do not think is a bad idea (in fact
> in isolation I think its a great idea).  My concern is more that atm this
> is exposed as an SPI from HEM under the o.h.jpa package.  I could just move
> the package in total to hibernate-core, I'm just ecstatic about a o.h.jpa
> package being used for stuff that is (no longer) JPA specific.  But maybe
> that's ok i the short term?  Could also do a "ghost package" concept
> (deprecate old package and have it extend from new package) to help
> integrators in the short term.
>
> I have already made scanning not dependent upon the JPA spis.  Used to be
> that scanning operated on the PersistenceUnitDescriptor.  But really we
> just need a small subset of that information to actually perform scanning:
> 1) what is the root url?
> 2) what are the non-root urls?
>
> Not really needed for scanning, but needed in collecting the scan results:
> 1) list of explicitly provided class names
> 2) list of explicitly provided mapping file names
>
> So bottom line... none of this is JPA specific any more.  Moving scanning
> to MetadataBuildingProcess allows us to centralize indexing in one place.
>
> Thoughts?
>
>
> On Mon, Apr 28, 2014 at 1:09 PM, Hardy Ferentschik <hardy at hibernate.org>wrote:
>
>>
>> On 28 Jan 2014, at 17:20, Steve Ebersole <steve at hibernate.org> wrote:
>>
>> > Almost done with this.  We are much more aggressive about indexing
>> stuff into Jandex now (which is a good thing) when we are not handed a
>> Jandex Index.
>> >
>> > However, this does mean we need to be more careful in the case of JPA
>> and exclude-non-listed-classes.  ATM we drive annotations based on Jandex
>> (aka, the classes known to Jandex).  However, if we know index classes that
>> should not be used as entities, etc (because of exclude-non-listed-classes)
>> we are breaking the JPA spec.  To this end, I suggest that scanning:
>> > 1) Index everything
>> > 2) Keep a running tab of "allowable managed classes and packages".
>> >
>> > Later, when beginning interpretation of annotations (via Jandex) we can
>> cross-reference that with the list of allowable managed classes.  Currently
>> we do:
>> >
>> > for ( ClassInfo classInfo :
>> bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
>> >     // use them all...
>> > }
>> >
>> >
>> > What I am suggesting is:
>> >
>> > interface ManagedClassFilter {
>> >     public boolean allowAsManagedClass(ClassInfo classInfo);
>> > }
>> >
>> > for ( ClassInfo classInfo :
>> bindingContext.getJandexAccess().getIndex().getKnownClasses() ) {
>> >     if ( !managedClassFiler.allowAsManagedClass( classInfo ) ) {
>> >         continue;
>> >     }
>> > }
>> >
>> > Further, rather than maintaining potentially large lists of allowable
>> class and package names, I'd also suggest we recognize the cases when we
>> have open-ended discovery in play and simply use an "all inclusive"
>> strategy.
>>
>> sounds good.
>
>
>

From steve at hibernate.org  Tue May  6 11:46:32 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 6 May 2014 10:46:32 -0500
Subject: [hibernate-dev] IRC Developer Meeting - 5/6
Message-ID: <CAFdSV9uo7wpXzXMTjMm-NTBbJjQDrpDLOsH5Y7SHyYHt5k8JaQ@mail.gmail.com>

There was nothing discussed today

From hardy at hibernate.org  Tue May  6 15:43:35 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 6 May 2014 21:43:35 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <FD83D72C-A5A5-43F0-A86C-61FE822E1528@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
	<8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
	<FD83D72C-A5A5-43F0-A86C-61FE822E1528@hibernate.org>
Message-ID: <34E35E81-3F6F-43C2-81E8-5FEFBF4E8658@hibernate.org>

Where are we at in this discussion?

I think we basically have to main proposals.

#1 Don?t include the embedded id per default. If @IndexEmbedded is used via the depth parameter there is no way to include the embedded id.
     In order to include the id you would need to use includePaths. depth and includePaths can be used in combination, so something like this 
     is possible @IndexedEmbedded( depth = 1, includePaths = ?foo.id? ). This will include all configured fields of the embedded entity, plus its id.
#2 Don?t include the embedded id per default, but have an additional flag on @IndexedEmbedded to include the embedded id. The default would be false.
    To include the id would be something like @IndexedEmbedded( depth = 1, includeEmbeddedId = true ) or 
    @IndexedEmbedded(  includePaths = {?foo.a?, ?foo.b?, ?foo.c?} , includeEmbeddedId = true ).

I think I favour #2 atm, since it seems more symmetric. 

On top of this we seem to agree that it is a good idea to set the default depth value of @IndexedEmbedded to 0. This avoids the change in default values,
when includePaths is used. As a side effect the default @IndexedEmbedded annotation becomes a no-op and should be treated as an invalid configuration.
The choice here is between:

#1 Log warning and move on
#2 Throw an exception due to invalid configuration

My choice would be #2 again.

Thoughts?

?Hardy



On 30 Jan 2014, at 20:19, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
>> So it has been an explicit choice at some point of time.
>> 
>>> - API wise it's much more complex to express the request-for-removal
>>> than to simply add it to includePath when needed
>> 
>> The question is also about a consistent behaviour across all use cases. Sure, 
>> we can add the id via the include path, but what I want to make sure that our implementation
>> makes sense in all cases and we have a comprehensible solution for users. 
>> So, I guess you are saying here, that the document id is just not a regular field. 
> 
> To clarify what bugs me is, that you are basically suggesting that the id can be included via
> include path, but can never be used via the depth approach. 
> 
> One option we have not discussed yet, is an additional method on @indexedEmbedded. 
> Something like includeEmbeddedId. Default would be false. If you set it to true, the id is
> included. It makes id inclusion orthogonal to depth and includePath.
> 
> ?Hardy
> _______________________________________________
> 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  7 03:10:00 2014
From: guillaume.smet at gmail.com (Guillaume Smet)
Date: Wed, 7 May 2014 09:10:00 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
 embedded entity
In-Reply-To: <34E35E81-3F6F-43C2-81E8-5FEFBF4E8658@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
	<8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
	<FD83D72C-A5A5-43F0-A86C-61FE822E1528@hibernate.org>
	<34E35E81-3F6F-43C2-81E8-5FEFBF4E8658@hibernate.org>
Message-ID: <CALt0+o_iF4Vmve7TTUYXCi4ePq63F6479DfG02AQ_7TXFT1iqQ@mail.gmail.com>

Hi,

On Tue, May 6, 2014 at 9:43 PM, Hardy Ferentschik <hardy at hibernate.org> wrote:
> I think I favour #2 atm, since it seems more symmetric.

I'm also in favour of #2.

> On top of this we seem to agree that it is a good idea to set the default depth value of @IndexedEmbedded to 0. This avoids the change in default values,
> when includePaths is used. As a side effect the default @IndexedEmbedded annotation becomes a no-op and should be treated as an invalid configuration.
> The choice here is between:
>
> #1 Log warning and move on
> #2 Throw an exception due to invalid configuration
>
> My choice would be #2 again.

Same here. Otherwise, it will break (mostly) silently a lot of
applications out there.

-- 
Guillaume

From amits.84 at gmail.com  Thu May  8 07:51:04 2014
From: amits.84 at gmail.com (amit shah)
Date: Thu, 8 May 2014 17:21:04 +0530
Subject: [hibernate-dev] Session.evict does not allow nulls after upgrade
Message-ID: <CALpK9-R-KFXjTCgrM6f8eVJOLML2sRAPsF4izr32DkOD1UuvuQ@mail.gmail.com>

We upgraded hibernate from 3.6.0 to 4.3.5 but the application fails if null
is passed to Session.evict()
The application passes null since the code is generic.

Are there any alternatives?

Thanks,
Amit.

From m.schipperheyn at gmail.com  Thu May  8 09:02:51 2014
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Thu, 8 May 2014 10:02:51 -0300
Subject: [hibernate-dev] Interesting article Lucene Joins
Message-ID: <CAGvEgx4_OR=OOGAF5YiBYbD+v-S2aRB3W4tBLr01WM2eEhTW5g@mail.gmail.com>

http://blog.seecr.nl/2014/02/24/a-faster-join-for-solrlucene/

Just wanted to point out this article that talks about query time joins in
Lucene.

From steve at hibernate.org  Thu May  8 09:37:10 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 8 May 2014 08:37:10 -0500
Subject: [hibernate-dev] Session.evict does not allow nulls after upgrade
In-Reply-To: <CALpK9-R-KFXjTCgrM6f8eVJOLML2sRAPsF4izr32DkOD1UuvuQ@mail.gmail.com>
References: <CALpK9-R-KFXjTCgrM6f8eVJOLML2sRAPsF4izr32DkOD1UuvuQ@mail.gmail.com>
Message-ID: <CAFdSV9tREhFqK=1xuanbQQ8RDNYeY45iCwXAyXqANTW4fvu1tg@mail.gmail.com>

This list is for discussions about the development of Hibernate, not for
usage discussions.

The behavior you describe sounds the most reasonable to me actually, tbh.
 Also, generic code can (should, I'd argue) still do null checks...


On Thu, May 8, 2014 at 6:51 AM, amit shah <amits.84 at gmail.com> wrote:

> We upgraded hibernate from 3.6.0 to 4.3.5 but the application fails if null
> is passed to Session.evict()
> The application passes null since the code is generic.
>
> Are there any alternatives?
>
> Thanks,
> Amit.
> _______________________________________________
> 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  8 10:49:02 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 8 May 2014 09:49:02 -0500
Subject: [hibernate-dev] Loggers and categories
In-Reply-To: <CAFdSV9sccUDe1d6ED2K_sjwrjtQWpuERvGjgF0ZZgdbvsoKkrA@mail.gmail.com>
References: <CAFdSV9sccUDe1d6ED2K_sjwrjtQWpuERvGjgF0ZZgdbvsoKkrA@mail.gmail.com>
Message-ID: <CAFdSV9tz3_tOMy3RtQs=fvx60r+R=6USt4w3zgje__M268X+Ag@mail.gmail.com>

For those that did not see the Scanning/Jandex Pull Request I sent earlier,
it includes some initial proofing along these lines.

Essentially I started creating a set of distinct, functional-based
MessageLoggers which log to dedicated categories per functional area.
 Samples are by far the best way to explain this I think.  So in the
initial work related to Jandex building and Scanner changes I defined 2
such functional MessageLoggers:  DeprecationLogger and UrlMessageBundle[1].

@MessageLogger( projectCode = "HHH" )

@ValidIdRange( min = 90000001, max = 90001000 )

public interface DeprecationLogger {

    public static final DeprecationLogger DEPRECATION_LOGGER =
Logger.getMessageLogger(

            DeprecationLogger.class,

            "org.hibernate.orm.deprecation"

    );


    /**

     * Log about usage of deprecated Scanner setting

     */

    @LogMessage( level = INFO )

    @Message(

            value = "Found usage of deprecated setting for specifying
Scanner [hibernate.ejb.resource_scanner]; " +

                    "use [hibernate.archive.scanner] instead",

            id = 90000001

    )

    public void logScannerDeprecation();

}


First notice the DEPRECATION_LOGGER member.  This defines the distinct
category ("org.hibernate.orm.deprecation") that these message will be
logged to.  This is the change from using the names of the Class from which
this method gets called.  Each of these message logger categories will be
documented in the logging topical guide, which altogether makes it easier
for users to enable/disable these messages and get the information.

Notice I also started making use of the @ValidRange annotation to identify
the message ids each logger "reserves".


[1] The difference in naming is because I am not really yet sure how to
best handle the schizophrenic nature of these "loggers" that also just
format (with i18n) mesages for creating exceptions.  To me a call like
`throw new SomeException( someLogger.someMessage() )` just "feels" wrong.
 FWIW I did change the convention up a little in terms of the method names
(well i actually started a convention) such that methods that log start
with the prefix `log`; e.g. logMalformedUrl(..) versus just malformedUrl(..)



On Thu, Apr 17, 2014 at 11:05 AM, Steve Ebersole <steve at hibernate.org>wrote:

> Wanted to revisit something that's been bothering me ever since we moved
> to JBoss Logging : the definition of loggers.
>
> While I think we have always understood that there are really 2 different
> audiences for log messages, I think I have come to have a more clear
> understanding of what that means and its implications.
>
> We have log messages intended for usage scenarios and log messages
> intended for debugging scenarios.  To me, the first groups is represented
> by the JBoss Logging MessageLogger messages.  The second group are the
> things we simply "pass through" to the underlying log backend (trace, debug
> messages).
>
> In both cases we currently use the name of the Class initiating the log
> message as the "category name".  While I think that is absolutely the
> correct thing to do in the case of that second group, what about the first
> group?  For that first group I wonder if its better to have "logical
> category names" more like 'org.hibernate.orm.deprecations' and
> 'org.hibernate.orm.mapping'...  The idea being that its easier to switch
> these grouped categories on/off.
>
>

From steve at hibernate.org  Thu May  8 13:19:19 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 8 May 2014 12:19:19 -0500
Subject: [hibernate-dev] Loggers and categories
In-Reply-To: <CAFdSV9tz3_tOMy3RtQs=fvx60r+R=6USt4w3zgje__M268X+Ag@mail.gmail.com>
References: <CAFdSV9sccUDe1d6ED2K_sjwrjtQWpuERvGjgF0ZZgdbvsoKkrA@mail.gmail.com>
	<CAFdSV9tz3_tOMy3RtQs=fvx60r+R=6USt4w3zgje__M268X+Ag@mail.gmail.com>
Message-ID: <CAFdSV9tyHqE3+fSy=nUH_1yiGFVDoWiuhebys9UJ3zExm5Q8Pg@mail.gmail.com>

So a few follow ups question here.

First, wrt @MessageLogger/@LogMessage versus @MessageBundle do we want to
split these?  The cliff notes version is that @MessageBundle (and
@Message) is used to define parameterized messages for translation;
@MessageLogger/@LogMessage further says that resulting message is logged
(rather than returned to build an exception, etc).  Personally I think I
prefer to keep them together functionally.  Previously I only listed
DeprecationLogger, but UrlMessageBundle shows a mixed usage:


@MessageLogger( projectCode = "HHH" )
@ValidIdRange( min = 10000001, max = 10001000 )
public interface UrlMessageBundle {
  public static final UrlMessageBundle URL_LOGGER = Logger.getMessageLogger(
  UrlMessageBundle.class,
            "org.hibernate.orm.url"
  );

    /**
     * Logs a warning about a malformed URL, caused by a {@link
URISyntaxException}
  *
  * @param jarUrl The URL that lead to the {@link URISyntaxException}
  * @param e The underlying URISyntaxException
  */
  @LogMessage( level = WARN )
  @Message( value = "Malformed URL: %s", id = 10000001 )
  void logMalformedUrl(URL jarUrl, @Cause URISyntaxException e);

    ...

    /**
  * Access to the exception message used when a URL references names a file
that does not exist.
  * <p/>
  * TODO : detail when this is a warning {@link #logFileDoesNotExist}
versus an exception...
  *
  * @param filePart The "file part" that we gleaned from the URL
  * @param url The given URL
  *
  * @return The message
  */
  @Message( value = "File [%s] referenced by given URL [%s] does not
exist", id = 10000005 )
  String fileDoesNotExist(String filePart, URL url);
}

I think that "mixed" part is ok.  Anyone feel any different?

As Hardy and I discussed on the Pull Request (thanks for your thoughts
Hardy!)... we will need to do a good job identifying the reserved ids.
 Probably this involves a registry of the reserved keys on a wiki or
document somewhere, probably linking to the FQN of the MessageLogger that
reserved the range (along with a discussion of the loggers intent).  But I
wonder too if we want to categorize the ids in any way.  What I mean by
that is like what SQL does for its "error codes".  I don't have any clear
idea of categories atm; just throwing it out there.





On Thu, May 8, 2014 at 9:49 AM, Steve Ebersole <steve at hibernate.org> wrote:

> For those that did not see the Scanning/Jandex Pull Request I sent
> earlier, it includes some initial proofing along these lines.
>
> Essentially I started creating a set of distinct, functional-based
> MessageLoggers which log to dedicated categories per functional area.
>  Samples are by far the best way to explain this I think.  So in the
> initial work related to Jandex building and Scanner changes I defined 2
> such functional MessageLoggers:  DeprecationLogger and UrlMessageBundle[1].
>
> @MessageLogger( projectCode = "HHH" )
>
> @ValidIdRange( min = 90000001, max = 90001000 )
>
> public interface DeprecationLogger {
>
>     public static final DeprecationLogger DEPRECATION_LOGGER = Logger.getMessageLogger(
>
>             DeprecationLogger.class,
>
>             "org.hibernate.orm.deprecation"
>
>     );
>
>
>     /**
>
>      * Log about usage of deprecated Scanner setting
>
>      */
>
>     @LogMessage( level = INFO )
>
>     @Message(
>
>             value = "Found usage of deprecated setting for specifying Scanner [hibernate.ejb.resource_scanner]; " +
>
>                     "use [hibernate.archive.scanner] instead",
>
>             id = 90000001
>
>     )
>
>     public void logScannerDeprecation();
>
> }
>
>
> First notice the DEPRECATION_LOGGER member.  This defines the distinct
> category ("org.hibernate.orm.deprecation") that these message will be
> logged to.  This is the change from using the names of the Class from which
> this method gets called.  Each of these message logger categories will be
> documented in the logging topical guide, which altogether makes it easier
> for users to enable/disable these messages and get the information.
>
> Notice I also started making use of the @ValidRange annotation to identify
> the message ids each logger "reserves".
>
>
> [1] The difference in naming is because I am not really yet sure how to
> best handle the schizophrenic nature of these "loggers" that also just
> format (with i18n) mesages for creating exceptions.  To me a call like
> `throw new SomeException( someLogger.someMessage() )` just "feels" wrong.
>  FWIW I did change the convention up a little in terms of the method names
> (well i actually started a convention) such that methods that log start
> with the prefix `log`; e.g. logMalformedUrl(..) versus just malformedUrl(..)
>
>
>
> On Thu, Apr 17, 2014 at 11:05 AM, Steve Ebersole <steve at hibernate.org>wrote:
>
>> Wanted to revisit something that's been bothering me ever since we moved
>> to JBoss Logging : the definition of loggers.
>>
>> While I think we have always understood that there are really 2 different
>> audiences for log messages, I think I have come to have a more clear
>> understanding of what that means and its implications.
>>
>> We have log messages intended for usage scenarios and log messages
>> intended for debugging scenarios.  To me, the first groups is represented
>> by the JBoss Logging MessageLogger messages.  The second group are the
>> things we simply "pass through" to the underlying log backend (trace, debug
>> messages).
>>
>> In both cases we currently use the name of the Class initiating the log
>> message as the "category name".  While I think that is absolutely the
>> correct thing to do in the case of that second group, what about the first
>> group?  For that first group I wonder if its better to have "logical
>> category names" more like 'org.hibernate.orm.deprecations' and
>> 'org.hibernate.orm.mapping'...  The idea being that its easier to switch
>> these grouped categories on/off.
>>
>>
>

From hardy at hibernate.org  Thu May  8 14:20:12 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Thu, 8 May 2014 20:20:12 +0200
Subject: [hibernate-dev] Loggers and categories
In-Reply-To: <CAFdSV9tyHqE3+fSy=nUH_1yiGFVDoWiuhebys9UJ3zExm5Q8Pg@mail.gmail.com>
References: <CAFdSV9sccUDe1d6ED2K_sjwrjtQWpuERvGjgF0ZZgdbvsoKkrA@mail.gmail.com>
	<CAFdSV9tz3_tOMy3RtQs=fvx60r+R=6USt4w3zgje__M268X+Ag@mail.gmail.com>
	<CAFdSV9tyHqE3+fSy=nUH_1yiGFVDoWiuhebys9UJ3zExm5Q8Pg@mail.gmail.com>
Message-ID: <146A4557-F790-4759-8456-B659F3554E76@hibernate.org>


On 8 Jan 2014, at 19:19, Steve Ebersole <steve at hibernate.org> wrote:

> So a few follow ups question here.
> 
> First, wrt @MessageLogger/@LogMessage versus @MessageBundle do we want to
> split these?  

For what it?s worth, we do the split in Validator. I think I prefer it this way, but have no strong 
feeling about it.

?Hardy




From amits.84 at gmail.com  Fri May  9 01:01:26 2014
From: amits.84 at gmail.com (amit shah)
Date: Fri, 9 May 2014 10:31:26 +0530
Subject: [hibernate-dev] Session.evict does not allow nulls after upgrade
In-Reply-To: <CAFdSV9tREhFqK=1xuanbQQ8RDNYeY45iCwXAyXqANTW4fvu1tg@mail.gmail.com>
References: <CALpK9-R-KFXjTCgrM6f8eVJOLML2sRAPsF4izr32DkOD1UuvuQ@mail.gmail.com>
	<CAFdSV9tREhFqK=1xuanbQQ8RDNYeY45iCwXAyXqANTW4fvu1tg@mail.gmail.com>
Message-ID: <CALpK9-Si2AMvoLjo5KaJqZkjYnkWmadE9EH90PYsOAHHXj1yhA@mail.gmail.com>

Ok. I will move this discussion to the users group.
I understand that it sounds reasonable to have a null check but the
important point is that it has broken backwards compatibility. Any thoughts
on that?


On Thu, May 8, 2014 at 7:07 PM, Steve Ebersole <steve at hibernate.org> wrote:

> This list is for discussions about the development of Hibernate, not for
> usage discussions.
>
> The behavior you describe sounds the most reasonable to me actually, tbh.
>  Also, generic code can (should, I'd argue) still do null checks...
>
>
> On Thu, May 8, 2014 at 6:51 AM, amit shah <amits.84 at gmail.com> wrote:
>
>> We upgraded hibernate from 3.6.0 to 4.3.5 but the application fails if
>> null
>> is passed to Session.evict()
>> The application passes null since the code is generic.
>>
>> Are there any alternatives?
>>
>> Thanks,
>> Amit.
>> _______________________________________________
>> 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  9 07:37:32 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 9 May 2014 06:37:32 -0500
Subject: [hibernate-dev] Session.evict does not allow nulls after upgrade
In-Reply-To: <CALpK9-Si2AMvoLjo5KaJqZkjYnkWmadE9EH90PYsOAHHXj1yhA@mail.gmail.com>
References: <CALpK9-R-KFXjTCgrM6f8eVJOLML2sRAPsF4izr32DkOD1UuvuQ@mail.gmail.com>
	<CAFdSV9tREhFqK=1xuanbQQ8RDNYeY45iCwXAyXqANTW4fvu1tg@mail.gmail.com>
	<CALpK9-Si2AMvoLjo5KaJqZkjYnkWmadE9EH90PYsOAHHXj1yhA@mail.gmail.com>
Message-ID: <CAFdSV9v50cuqMekDvqNeGsT2-HtVubyyYxvAVzgKMbgZVNGQwQ@mail.gmail.com>

Here's the thing about "backwards compatibility"...  That's only true if
the behavior is documented and/or tested as such or if the behavior is just
"inherently reasonable".

As you even seem agree, the previous behavior is not inherently reasonable;
its at best questionable.  So then can you point me to some documentation
or regression tests that assert evict should accept nulls?




On Fri, May 9, 2014 at 12:01 AM, amit shah <amits.84 at gmail.com> wrote:

> Ok. I will move this discussion to the users group.
> I understand that it sounds reasonable to have a null check but the
> important point is that it has broken backwards compatibility. Any thoughts
> on that?
>
>
> On Thu, May 8, 2014 at 7:07 PM, Steve Ebersole <steve at hibernate.org>wrote:
>
>> This list is for discussions about the development of Hibernate, not for
>> usage discussions.
>>
>> The behavior you describe sounds the most reasonable to me actually, tbh.
>>  Also, generic code can (should, I'd argue) still do null checks...
>>
>>
>> On Thu, May 8, 2014 at 6:51 AM, amit shah <amits.84 at gmail.com> wrote:
>>
>>> We upgraded hibernate from 3.6.0 to 4.3.5 but the application fails if
>>> null
>>> is passed to Session.evict()
>>> The application passes null since the code is generic.
>>>
>>> Are there any alternatives?
>>>
>>> Thanks,
>>> Amit.
>>> _______________________________________________
>>> 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  9 13:25:40 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 9 May 2014 12:25:40 -0500
Subject: [hibernate-dev] Build failure executing
	:hibernate-core:runAnnotationProcessors
In-Reply-To: <BLU170-W18B82408D0F33F91963E5FD54C0@phx.gbl>
References: <BLU170-W70926413B0CC9FD4C6872AD5410@phx.gbl>
	<CAFdSV9sJU0u4ctuGXHrFWHHem3XNDR3rT4SYuc9RLFP=2eEk-Q@mail.gmail.com>
	<BLU170-W18B82408D0F33F91963E5FD54C0@phx.gbl>
Message-ID: <CAFdSV9suaxxY8AHarX_kB9A5fpHjU9Bbm4Sk6=YKBiLUe9mbAA@mail.gmail.com>

I was having some problems with this as well.  First initially setting up
my new machine, I had problems running this using 1.7.0_55 even though I
never previously had problems running previous JDKs.  I also saw problems
with this running the build using Java 8 JDK.

All in all I spent some time re-working source generation this week.  I
applied my changes to master.  I held off porting to 4.3 because it caused
worse problems trying to use Java 8 JDK and after spending a full day
trying to track down the reasons I gave up.


On Mon, May 5, 2014 at 4:23 PM, Mahesh Gadgil <maheshgadgil at hotmail.com>wrote:

> I am using wrapper and version is 1.9.
> This problem was resolved when I upgraded to java 1.7.0_55.
>
> Thanks
> Mahesh
>
>  ------------------------------
> Date: Sat, 3 May 2014 09:45:34 -0500
> Subject: Re: [hibernate-dev] Build failure executing
> :hibernate-core:runAnnotationProcessors
> From: steve at hibernate.org
> To: maheshgadgil at hotmail.com
> CC: hibernate-dev at lists.jboss.org
>
>
> Are you using a local Gradle install, or the Gradle Wrapper?  If a local
> Gradle install, which version?
>
>
> On Wed, Apr 30, 2014 at 3:10 PM, Mahesh Gadgil <maheshgadgil at hotmail.com>wrote:
>
> I am facing the same issue Gale Badner mentioned in his email
> (hibernate-core:runAnnotationProcessors - BUILD FAILED) -
> Gail Badner Fri, 28 Mar 2014 16:35:18 -0700.
> but unlike him I am unable to resolve the issue. I am using java 1.7.0_51
> and tried to compile 4.3 branch.
>
> ThanksMahesh
> _______________________________________________
> 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 12 11:38:52 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Mon, 12 May 2014 16:38:52 +0100
Subject: [hibernate-dev] [Search] Handling of mutual dependency with
	Infinispan
Message-ID: <CAFm4XO30RpxmqGtfccYr2MvZuJL6re5+Usu0LgMk4JbnrN3FmA@mail.gmail.com>

Now that finally Infinispan moved to build (and require) Java7, I'm
preparing to upgrade the Lucene Directory to Apache Lucene 4.8.

Sometimes it's trivial, some others we're out of luck and this is one
of such situations: the new Lucene code expects some new methods to
create and validate a CRC32 checksum signature of the Directory
segments.
Not too annoying - I can handle the coding - but it highlights an old
problem which is coming back.

Currently Infinispan is still using Hibernate Search 4.5, and provides
a Lucene Directory for both Lucene versions 3 and 4.
The current build provides the LuceneV4 support as an extension of the
V3 source module; this is a hack we introduced a year ago to make sure
we'd eventually be able to upgrade to Lucene4 and I was hoping now to
finally remove this fishy workaround as I initially expected it to be
a temporary measure.

But in practice such an upgrade of today would have been impossible:
Infinispan also depends on Hibernate Search. Having two different
modules in Infinispan is what enables us today to start an update to a
new version of Lucene.

I'm wondering if we should move the Lucene Directory code into
Hibernate Search; this also has licensing implications as that's using
ASL2 currently. And that's probably only moving the problem one step
down, as Infinispan Query still depends on Hibernate Search (engine)
and the Lucene Directory would still depend on Infinispan Core.

I'm not having a solution in mind; obviously we wouldn't have such a
problem if each of our projects *always* guaranteed a clean migration
path via default methods and deprecated methods, but this is a rule
which is occasionally broken: when it happens, the only thing I can
think of is that one of the two projects needs to release a tag which
has some broken components. For example, Infinispan to release
occasionally without the Query engine.

Sanne

From emmanuel at hibernate.org  Mon May 12 12:15:38 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 12 May 2014 18:15:38 +0200
Subject: [hibernate-dev] [Search] Handling of mutual dependency with
	Infinispan
In-Reply-To: <CAFm4XO30RpxmqGtfccYr2MvZuJL6re5+Usu0LgMk4JbnrN3FmA@mail.gmail.com>
References: <CAFm4XO30RpxmqGtfccYr2MvZuJL6re5+Usu0LgMk4JbnrN3FmA@mail.gmail.com>
Message-ID: <B9ED2DC9-5841-4AAD-9926-8842150E3280@hibernate.org>

I am not sure I understand everything you said. how about you take 20 mins tomorrow during our Hibernate NoORM team meeting on IRC?
Be careful, 20 mins run fast in practice :)

On 12 May 2014, at 17:38, Sanne Grinovero <sanne at hibernate.org> wrote:

> Now that finally Infinispan moved to build (and require) Java7, I'm
> preparing to upgrade the Lucene Directory to Apache Lucene 4.8.
> 
> Sometimes it's trivial, some others we're out of luck and this is one
> of such situations: the new Lucene code expects some new methods to
> create and validate a CRC32 checksum signature of the Directory
> segments.
> Not too annoying - I can handle the coding - but it highlights an old
> problem which is coming back.
> 
> Currently Infinispan is still using Hibernate Search 4.5, and provides
> a Lucene Directory for both Lucene versions 3 and 4.
> The current build provides the LuceneV4 support as an extension of the
> V3 source module; this is a hack we introduced a year ago to make sure
> we'd eventually be able to upgrade to Lucene4 and I was hoping now to
> finally remove this fishy workaround as I initially expected it to be
> a temporary measure.
> 
> But in practice such an upgrade of today would have been impossible:
> Infinispan also depends on Hibernate Search. Having two different
> modules in Infinispan is what enables us today to start an update to a
> new version of Lucene.
> 
> I'm wondering if we should move the Lucene Directory code into
> Hibernate Search; this also has licensing implications as that's using
> ASL2 currently. And that's probably only moving the problem one step
> down, as Infinispan Query still depends on Hibernate Search (engine)
> and the Lucene Directory would still depend on Infinispan Core.
> 
> I'm not having a solution in mind; obviously we wouldn't have such a
> problem if each of our projects *always* guaranteed a clean migration
> path via default methods and deprecated methods, but this is a rule
> which is occasionally broken: when it happens, the only thing I can
> think of is that one of the two projects needs to release a tag which
> has some broken components. For example, Infinispan to release
> occasionally without the Query engine.
> 
> 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 12 13:56:36 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 12 May 2014 19:56:36 +0200
Subject: [hibernate-dev] [Search] Handling of mutual dependency with
	Infinispan
In-Reply-To: <B9ED2DC9-5841-4AAD-9926-8842150E3280@hibernate.org>
References: <CAFm4XO30RpxmqGtfccYr2MvZuJL6re5+Usu0LgMk4JbnrN3FmA@mail.gmail.com>
	<B9ED2DC9-5841-4AAD-9926-8842150E3280@hibernate.org>
Message-ID: <76D1395E-8A43-4F52-A770-076CECCF2BA6@hibernate.org>


On 12 Jan 2014, at 18:15, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> I am not sure I understand everything you said.

Same here. 

> how about you take 20 mins tomorrow during our Hibernate NoORM team meeting on IRC?
> Be careful, 20 mins run fast in practice :)

+1 That meeting is at 16:00, right? Need to see whether I can make it, otherwise I suggest 
a separate meeting.


?Hardy




From gbadner at redhat.com  Mon May 12 15:20:11 2014
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 12 May 2014 15:20:11 -0400 (EDT)
Subject: [hibernate-dev] Reserved words
In-Reply-To: <794977501.6790300.1399922120387.JavaMail.zimbra@redhat.com>
Message-ID: <609921136.6792641.1399922411047.JavaMail.zimbra@redhat.com>

As of 4.2.12, there are some identifiers that no longer work when used in HQL/JPQL, e.g. [1].

Is there a list of reserved words somewhere?

Thanks,
Gail

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

From steve at hibernate.org  Mon May 12 16:58:02 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 12 May 2014 15:58:02 -0500
Subject: [hibernate-dev] Reserved words
In-Reply-To: <609921136.6792641.1399922411047.JavaMail.zimbra@redhat.com>
References: <794977501.6790300.1399922120387.JavaMail.zimbra@redhat.com>
	<609921136.6792641.1399922411047.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9vE0wpR+x9dgpZJyfRAamBxpUU+1Erb9F5q2YVFG8C5Qg@mail.gmail.com>

Not really.  In general any token whose text is explicitly given in any of
the grammars will be treated as a keyword.  Generally speaking this is
merely an oversight when someone alters the grammars.  However, the
definition of the OBJECT token actually hasn't changed since the SVN
migration.  The parameter rule (and its uses) however has changed much more
recently...  HHH-5126.  This was a change you made Gail.

One of the major improvements in the next gen parser is the move to "soft
keywords", where keywords are contextually recognized which essentially
removes the concept of a "reserved word".  We use that in a limited fashion
in the current grammars.

As for this particular report, do we have a simplified test?  The Jira just
lists the query.



On Mon, May 12, 2014 at 2:20 PM, Gail Badner <gbadner at redhat.com> wrote:

> As of 4.2.12, there are some identifiers that no longer work when used in
> HQL/JPQL, e.g. [1].
>
> Is there a list of reserved words somewhere?
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/browse/HHH-9154
> _______________________________________________
> 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 12 17:10:06 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Mon, 12 May 2014 16:10:06 -0500
Subject: [hibernate-dev] @MappedSuperclass, @Embeddable and consistency
Message-ID: <CAFdSV9tg+FjKTydeuLY6Rdt=73Er0TpyLKa-gh68yS4BHWOcSw@mail.gmail.com>

The JPA spec is completely silent on inheritance when it comes to
embeddable classes.  When Emmanuel was first developing
hibernate-annotations we decided to allow the use of @MappedSuperclass to
be extended to embeddable classes to control the persistence of attributes
when an embeddable had a superclass.

I want to make sure we are all supporting this consistently.  And if not,
whether we need to revisit that original decision.

For example, Gail has recently found inconsistencies in regards to how
envers handles @MappedSuperclass + @Embeddable, compared to ORM.
 Specificaly it has different expectations for audited attributes for
@MappedSuperclass when it comes to @Entity versus @Embeddable.

Adam/Lukasz. do you guys see that as a conscious decision?  If so, can you
validate why y'all decided to go that way?  If it was not a conscious
decision, are there major technical/implementation hurdles to overcome in
making this consistent?

In Search, OGM, etc are we consistent with this interpretation of
@MappedSuperclass + @Embeddable?

From maheshgadgil at hotmail.com  Tue May 13 11:39:28 2014
From: maheshgadgil at hotmail.com (Mahesh Gadgil)
Date: Tue, 13 May 2014 15:39:28 +0000
Subject: [hibernate-dev] question on matrix testing
Message-ID: <BLU170-W5712BF71228C30F89345F5D5340@phx.gbl>

I am running hibernate tests on SAP SYBASE ASE database currently. I am looking to get advice on what the best solution is to these problems.I know some tests that could not be run on ASE, have been skipped using SkipForDialect annotation in the past.The issues I am listing are for the remaining tests.
1. Some tests like below create a "User" table, which is not allowed by ASE. This can be fixed (thanks Brett Meyer) by adding @Table annotation and renaming the  table by adding and escaping double quotes as "\"User\"" and setting 'set quoted_identifier on' option on ASE. If this change makes into the source code, would this impact testing of other databases?
  org.hibernate.test.cache.CollectionCacheEvictionTest 
2. Many tests like below create column names in smaller case but use names with uppercase in the sql that's generated. These tests fail on ASE because of its default setting of 'case sensitive'. This is easily fixed by setting ASE to ignore 'case' altogether. However I believe we need to be consistent with our naming conventions to avoid such problems. org.hibernate.test.annotations.entity.BasicHibernateAnnotationsTest  ----- CATEGORY column
3. Some tests like below use defaults for datetime columns as CURRENT_TIMESTAMP. This needs to be replaced with getdate() for ASE. Is there a way, this can be made db independent or dynamic?
  org.hibernate.test.generated.DefaultGeneratedValueTest

The changes I make to source code to fix these issues on my machine would be overwritten every time I refresh the code from repository. So, I was wondering if there is a solution that resolves these issues for ASE but not impact testing on other databases.

Thanks
Mahesh 		 	   		  

From emmanuel at hibernate.org  Tue May 13 11:44:00 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 13 May 2014 17:44:00 +0200
Subject: [hibernate-dev] NoORM team meeting
Message-ID: <20140513154400.GA32083@hibernate.org>

Main subjects:
- circularity hell between Infinispan Core, Hiebrnate Search, Infinispan
  Lucene Directory, Infinispan Query
- OGM plans for beta 3 and beta 4. In particular beta 3 next week
- PRs around Neo4J, cypher dependency problem, remote container support
  missing
- OGM and query performance problem
- OGM and embedded structure not requiring a second load and necessary
  ORM changes
- Hibernate Search and @IndexedEmbedded(prefix="")
- Prototype on free-form entity
- CI server

Actions:
- Sanne to sum up by email what was agreed on for the Infinispan circularity
  problem
- Davide to consider remote access to Neo4J less of a priority than OGM
  GA
- Gunnar to open a blocker JIRA on the query performance
- Gunnar to dig up the choice to make ORM more flexible around EntityKey
- Gunnar and Emmanuel to implement above proposed solution in ORM
- Emmanuel to review davide's PR and the one on top of it whatever that
  means :)
- Davide to contact Paul Gier on the additional third party dependency
- Emmanuel to read the thread on @IndexedEmbedded
- Sanne to reduce concurrent subjects to make Hibernate Search progress
  a priority
- Hardy and Sanne to release Hibernate Search tomorrow

Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-13-13.24.html
Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-13-13.24.txt
Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-13-13.24.log.html

Emmanuel

From steve at hibernate.org  Tue May 13 13:22:03 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 May 2014 12:22:03 -0500
Subject: [hibernate-dev] IRC Dev Meeting - 5/13
Message-ID: <CAFdSV9vV2a5mbozzAxe=aNWE8Yi=_E8mSnw=Wo6UsfKh5320TQ@mail.gmail.com>

Mostly continued discussion of CI server over from the no-orm meeting

[10:30] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-13-14.59.html
[10:30] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-13-14.59.txt
[10:30] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-13-14.59.log.html

From steve at hibernate.org  Tue May 13 13:33:04 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 13 May 2014 12:33:04 -0500
Subject: [hibernate-dev] question on matrix testing
In-Reply-To: <BLU170-W5712BF71228C30F89345F5D5340@phx.gbl>
References: <BLU170-W5712BF71228C30F89345F5D5340@phx.gbl>
Message-ID: <CAFdSV9vSkxWV=wDY9Fb1izFFUjKrODC3KDxs1io1qww=XTw8pw@mail.gmail.com>

On Tue, May 13, 2014 at 10:39 AM, Mahesh Gadgil <maheshgadgil at hotmail.com>wrote:

> I am running hibernate tests on SAP SYBASE ASE database currently. I am
> looking to get advice on what the best solution is to these problems.I know
> some tests that could not be run on ASE, have been skipped using
> SkipForDialect annotation in the past.The issues I am listing are for the
> remaining tests.
> 1. Some tests like below create a "User" table, which is not allowed by
> ASE. This can be fixed (thanks Brett Meyer) by adding @Table annotation and
> renaming the  table by adding and escaping double quotes as "\"User\"" and
> setting 'set quoted_identifier on' option on ASE. If this change makes into
> the source code, would this impact testing of other databases?
>   org.hibernate.test.cache.CollectionCacheEvictionTest
>

Yes, we should make this change upstream


> 2. Many tests like below create column names in smaller case but use names
> with uppercase in the sql that's generated. These tests fail on ASE because
> of its default setting of 'case sensitive'. This is easily fixed by setting
> ASE to ignore 'case' altogether. However I believe we need to be consistent
> with our naming conventions to avoid such problems.
> org.hibernate.test.annotations.entity.BasicHibernateAnnotationsTest  -----
> CATEGORY column
>

TBH I think that having case-sensitive (non-delimited) identifiers is
silly.  I don't plan on changing these in the tests.  I'd expect you to
alter the db to not use case-sensitive identifiers.



> 3. Some tests like below use defaults for datetime columns as
> CURRENT_TIMESTAMP. This needs to be replaced with getdate() for ASE. Is
> there a way, this can be made db independent or dynamic?
>   org.hibernate.test.generated.DefaultGeneratedValueTest
>

current_timestamp is one of the few functions explicitly called out for
support in the SQL standard.   SAP SYBASE ASE does not support that?

From gbadner at redhat.com  Tue May 13 19:12:16 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 13 May 2014 19:12:16 -0400 (EDT)
Subject: [hibernate-dev] Reserved words
In-Reply-To: <CAFdSV9vE0wpR+x9dgpZJyfRAamBxpUU+1Erb9F5q2YVFG8C5Qg@mail.gmail.com>
References: <794977501.6790300.1399922120387.JavaMail.zimbra@redhat.com>
	<609921136.6792641.1399922411047.JavaMail.zimbra@redhat.com>
	<CAFdSV9vE0wpR+x9dgpZJyfRAamBxpUU+1Erb9F5q2YVFG8C5Qg@mail.gmail.com>
Message-ID: <2092811865.8006608.1400022736232.JavaMail.zimbra@redhat.com>

This appears to be due to the first commit for HHH-9100. I've re-opened https://hibernate.atlassian.net/browse/HHH-9154 and added details there.

Steve, can you take a look?

Thanks,
Gail

----- Original Message -----
> From: "Steve Ebersole" <steve at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Hibernate" <hibernate-dev at lists.jboss.org>
> Sent: Monday, May 12, 2014 1:58:02 PM
> Subject: Re: [hibernate-dev] Reserved words
> 
> Not really.  In general any token whose text is explicitly given in any of
> the grammars will be treated as a keyword.  Generally speaking this is
> merely an oversight when someone alters the grammars.  However, the
> definition of the OBJECT token actually hasn't changed since the SVN
> migration.  The parameter rule (and its uses) however has changed much more
> recently...  HHH-5126.  This was a change you made Gail.
> 
> One of the major improvements in the next gen parser is the move to "soft
> keywords", where keywords are contextually recognized which essentially
> removes the concept of a "reserved word".  We use that in a limited fashion
> in the current grammars.
> 
> As for this particular report, do we have a simplified test?  The Jira just
> lists the query.
> 
> 
> 
> On Mon, May 12, 2014 at 2:20 PM, Gail Badner <gbadner at redhat.com> wrote:
> 
> > As of 4.2.12, there are some identifiers that no longer work when used in
> > HQL/JPQL, e.g. [1].
> >
> > Is there a list of reserved words somewhere?
> >
> > Thanks,
> > Gail
> >
> > [1] https://hibernate.atlassian.net/browse/HHH-9154
> > _______________________________________________
> > 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 14 02:08:54 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 14 May 2014 08:08:54 +0200
Subject: [hibernate-dev] [OGM] types and sequence generator in dialect
	package
Message-ID: <20140514060854.GJ30944@hibernate.org>

It does not make a huge difference as these are in impl packages but I
wonder if somebody has a specific reasoning for putting types
(converters) and sequence generators inside the dialect package?

Granted they are wired in the dialect but in practice they are used by
the code base at large. I think naturally I would ahve put them under

    o.h.o.datastore.somenosql.type / generator or idgenerator

From emmanuel at hibernate.org  Wed May 14 10:12:17 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Wed, 14 May 2014 16:12:17 +0200
Subject: [hibernate-dev] [OGM] types and sequence generator in dialect
 package
In-Reply-To: <CANoTJYOoyAcAd-OywHfZi=Kdb2=Ur6kHM0CCcBuz0=Xa8kXpUQ@mail.gmail.com>
References: <20140514060854.GJ30944@hibernate.org>
	<CANoTJYOoyAcAd-OywHfZi=Kdb2=Ur6kHM0CCcBuz0=Xa8kXpUQ@mail.gmail.com>
Message-ID: <20140514141217.GP30944@hibernate.org>

adding the mailing list back.

Other datastores use the same approach as you so we need to eb
consistent

On Wed 2014-05-14 11:22, Davide D'Alto wrote:
> Neo4jSequenceGenerator and Neo4jTypeConverter were the result of some code
> that I've extracted from the dialect.
> Initially I didn't expect them to be used somewhere else outside the
> dialect.
> 
> Sounds good to me to move them to a separate package.
> 
> 
> On Wed, May 14, 2014 at 8:08 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
> 
> > It does not make a huge difference as these are in impl packages but I
> > wonder if somebody has a specific reasoning for putting types
> > (converters) and sequence generators inside the dialect package?
> >
> > Granted they are wired in the dialect but in practice they are used by
> > the code base at large. I think naturally I would ahve put them under
> >
> >     o.h.o.datastore.somenosql.type / generator or idgenerator
> > _______________________________________________
> > 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 14 10:38:53 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 14 May 2014 16:38:53 +0200
Subject: [hibernate-dev] [OGM] types and sequence generator in dialect
	package
In-Reply-To: <20140514141217.GP30944@hibernate.org>
References: <20140514060854.GJ30944@hibernate.org>
	<CANoTJYOoyAcAd-OywHfZi=Kdb2=Ur6kHM0CCcBuz0=Xa8kXpUQ@mail.gmail.com>
	<20140514141217.GP30944@hibernate.org>
Message-ID: <CADGJaX9waOt9=rdJVgGS9Pn3aujK=v3p2UQzLvYVJaCXGbtQBw@mail.gmail.com>

Atm. it's not handled consistently between dialects; e.g.
hibernate-ogm-mongodb already has a "type" package as you suggest.

+1 for making it consistent and having separate packages as you propose.

--Gunnar



2014-05-14 16:12 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> adding the mailing list back.
>
> Other datastores use the same approach as you so we need to eb
> consistent
>
> On Wed 2014-05-14 11:22, Davide D'Alto wrote:
> > Neo4jSequenceGenerator and Neo4jTypeConverter were the result of some
> code
> > that I've extracted from the dialect.
> > Initially I didn't expect them to be used somewhere else outside the
> > dialect.
> >
> > Sounds good to me to move them to a separate package.
> >
> >
> > On Wed, May 14, 2014 at 8:08 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>wrote:
> >
> > > It does not make a huge difference as these are in impl packages but I
> > > wonder if somebody has a specific reasoning for putting types
> > > (converters) and sequence generators inside the dialect package?
> > >
> > > Granted they are wired in the dialect but in practice they are used by
> > > the code base at large. I think naturally I would ahve put them under
> > >
> > >     o.h.o.datastore.somenosql.type / generator or idgenerator
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.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 maheshgadgil at hotmail.com  Wed May 14 12:22:15 2014
From: maheshgadgil at hotmail.com (Mahesh Gadgil)
Date: Wed, 14 May 2014 16:22:15 +0000
Subject: [hibernate-dev] question on matrix testing
In-Reply-To: <CAFdSV9sMrXkrh6=Jk2hzx5Ozb9MkPVszXWHfwdEFv4sz_eCaoQ@mail.gmail.com>
References: <BLU170-W5712BF71228C30F89345F5D5340@phx.gbl>,
	<CAFdSV9vSkxWV=wDY9Fb1izFFUjKrODC3KDxs1io1qww=XTw8pw@mail.gmail.com>,
	<BLU170-W23359509B9ED616112FFD6D5340@phx.gbl>,
	<CAFdSV9sMrXkrh6=Jk2hzx5Ozb9MkPVszXWHfwdEFv4sz_eCaoQ@mail.gmail.com>
Message-ID: <BLU170-W12059FFB253E3BC215BBDFFD5370@phx.gbl>

Didn't drop it on purpose. Sybase products, IQ and SQL Anywhere support the CURRENT_TIMESTAMP but ASE doesn't. I am not the person to answer the question of why. Would you recommend skipping this test for ASE or there is some workaround I am not aware of?
ThanksMahesh

Date: Wed, 14 May 2014 09:32:08 -0500
Subject: Re: [hibernate-dev] question on matrix testing
From: steve at hibernate.org
To: maheshgadgil at hotmail.com

Why do you keep dropping hibernate-dev from the recipients?
What I find odd is that Sybase does not support one of the few functions that the SQL spec explicitly names.


On Tue, May 13, 2014 at 2:00 PM, Mahesh Gadgil <maheshgadgil at hotmail.com> wrote:




On item 3.Current_timestamp is not supported on ASE. Here is what happens for that particular test.
16:32:56,424 ERROR SchemaExport:425 - HHH000389: Unsuccessful: create table T_ENT_GEN_DEF (id int not null, alwaysDate datetime default CURRENT_TIMESTAMP not null, createdDate datetime default CURRENT_TIMESTAMP not null, lastName varchar(255) null, name varchar(255) null, updated datetime null, vmCreatedCalendar datetime null, vmCreatedDate datetime null, vmCreatedSqlDate date null, vmCreatedSqlTime time null, vmCreatedSqlTimestamp datetime null, primary key (id)) lock datarows

16:32:56,424 ERROR SchemaExport:426 - The name 'CURRENT_TIMESTAMP' is illegal in this context. Only constants, constant expressions, or variables allowed here.  Column names are illegal.


There are CURRENT_BIGTIME and CURRENT_BIGDATETIME functions but they need to be used with '()'. So this would work.create table T_ENT_GEN_DEF (id int not null, alwaysDate datetime default CURRENT_BIGTIME() not null ........


ThanksMahesh
Date: Tue, 13 May 2014 12:33:04 -0500
Subject: Re: [hibernate-dev] question on matrix testing

From: steve at hibernate.org
To: maheshgadgil at hotmail.com
CC: hibernate-dev at lists.jboss.org


On Tue, May 13, 2014 at 10:39 AM, Mahesh Gadgil <maheshgadgil at hotmail.com> wrote:


I am running hibernate tests on SAP SYBASE ASE database currently. I am looking to get advice on what the best solution is to these problems.I know some tests that could not be run on ASE, have been skipped using SkipForDialect annotation in the past.The issues I am listing are for the remaining tests.



1. Some tests like below create a "User" table, which is not allowed by ASE. This can be fixed (thanks Brett Meyer) by adding @Table annotation and renaming the  table by adding and escaping double quotes as "\"User\"" and setting 'set quoted_identifier on' option on ASE. If this change makes into the source code, would this impact testing of other databases?



  org.hibernate.test.cache.CollectionCacheEvictionTest

Yes, we should make this change upstream 


2. Many tests like below create column names in smaller case but use names with uppercase in the sql that's generated. These tests fail on ASE because of its default setting of 'case sensitive'. This is easily fixed by setting ASE to ignore 'case' altogether. However I believe we need to be consistent with our naming conventions to avoid such problems. org.hibernate.test.annotations.entity.BasicHibernateAnnotationsTest  ----- CATEGORY column



TBH I think that having case-sensitive (non-delimited) identifiers is silly.  I don't plan on changing these in the tests.  I'd expect you to alter the db to not use case-sensitive identifiers.


 
3. Some tests like below use defaults for datetime columns as CURRENT_TIMESTAMP. This needs to be replaced with getdate() for ASE. Is there a way, this can be made db independent or dynamic?

  org.hibernate.test.generated.DefaultGeneratedValueTest

current_timestamp is one of the few functions explicitly called out for support in the SQL standard.   SAP SYBASE ASE does not support that?


 		 	   		  

 		 	   		  

From sanne at hibernate.org  Thu May 15 09:39:54 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 15 May 2014 14:39:54 +0100
Subject: [hibernate-dev] [Search] push-force on master
Message-ID: <CAFm4XO2Op0ZG4p01D6isbCq7RGccOcNEkLdwgjD0wuaOQ+wxrw@mail.gmail.com>

Hi all,
I've just used a push --force on master of Hibernate Search, hopefully
no damage as I undid a commit of just 15 minutes.

Sorry for any trouble, teaching merge procedures ;)

From emmanuel at hibernate.org  Thu May 15 12:29:19 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 15 May 2014 18:29:19 +0200
Subject: [hibernate-dev] Hibernate Commons Annotations uncompleted release
Message-ID: <FF3A76DE-CE38-4E05-A43C-B84B886BDB12@hibernate.org>

I was chatting with a user that is changelog conscious and he told me that Hibernate Commons Annotations 4.0.4 has been released but:

1. https://github.com/hibernate/hibernate-commons-annotations/blob/master/changelog.txt stops at 4.0.1
2. https://hibernate.atlassian.net/browse/HCANN/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel marks 4.0.4 as unreleased

I?ve fixed 2.

From emmanuel at hibernate.org  Thu May 15 17:07:18 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 15 May 2014 23:07:18 +0200
Subject: [hibernate-dev] [WEBSITE] hibernate-[project]-metadata.properties
Message-ID: <29BBC613-DF48-4BB5-BC6C-FD3079302BAA@hibernate.org>

Under the /project/ directory, you will find a strange .properties file. It will be used by jboss.org to collect up to date metadata about our projects. If something like CI, issue tracker, tagline, etc changes, these should be updated.
I?ve pushed the files and opened an issue to automate the file generation to reduce the risk of discrepancies https://hibernate.atlassian.net/browse/WEBSITE-189

Emmanuel

From sanne at hibernate.org  Thu May 15 19:18:06 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Fri, 16 May 2014 00:18:06 +0100
Subject: [hibernate-dev] Modules for WildFly -> wrong Infinispan being
	injected?
Message-ID: <CAFm4XO34cP2BMw0WVBHF9-O+2bQT9OpBc_B9Z_8SqZXrNEPKAg@mail.gmail.com>

I'm attempting to update Hibernate Search to use the latest Infinispan
7.0.0.Alpha4.

One of the notable changes in this Infinispan version is that the class

  org.infinispan.configuration.parsing.Parser60

was dropped, having now only a Parser70 implementation (which forces
you to rewrite all configuration files in a new format).

In my direct dependencies I'm listing exclusively Infinispan modules
having slot=7.0, so to load Infinispan dependencies from the custom
modules provided by the latest Infinispan tag.
Still I'm getting this exception when running our Arquillian integration tests:

Caused by: java.util.ServiceConfigurationError:
org.infinispan.configuration.parsing.ConfigurationParser: Provider
org.infinispan.configuration.parsing.Parser60 not a subtype
   at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51]
   at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
[rt.jar:1.7.0_51]
   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
[rt.jar:1.7.0_51]
   at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51]
   at org.infinispan.commons.util.ServiceFinder.addServices(ServiceFinder.java:60)
   at org.infinispan.commons.util.ServiceFinder.load(ServiceFinder.java:42)
   at org.infinispan.configuration.parsing.ParserRegistry.<init>(ParserRegistry.java:52)
   at org.hibernate.search.infinispan.impl.InfinispanConfigurationParser.<init>(InfinispanConfigurationParser.java:37)
[hibernate-search-infinispan-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
   at org.hibernate.search.infinispan.DefaultCacheManagerService.start(DefaultCacheManagerService.java:86)
[hibernate-search-infinispan-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
   at org.hibernate.search.engine.service.impl.StandardServiceManager$ServiceWrapper.startService(StandardServiceManager.java:255)
[hibernate-search-engine-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]

Parser60 is nowhere to be found across the dependencies I'm explicitly
listing; I'm guessing it's being injected on the classpath via the
dependency to Hibernate:main ?

Infinispan has similar integration tests for the modules, and this
wasn't catched there so I assume the difference of "being an Hibernate
application" could be something to explore.

I think this is probably not a new issue, but could have been hidden
previously: until previous Alpha releases of Infinispan a Parser60 was
actually being included, so I think in that case the explicit
dependency would have taken priority - by design or by luck. Also,
previous Infinispan releases had a less dramatic approach and would
include older parser implementations to keep backwards compatibility.

I'm confused at this point; I don't think it's expected for an
Hibernate user to get Infinispan classes on its classpath; I
understand Hibernate might need to load 2nd level cache, but this
should be an internal detail not exposed to modules consuming the ORM,
right?

I don't think I have ways to put exclusions in place, so I'm stuck;
hopefully I'm doing something wrong in my branch HSEARCH-1594 .. I'll
check again tomorrow but if someone is willing to have a look at what
I'm doing that would be great.

Sanne

From emmanuel at hibernate.org  Fri May 16 03:51:43 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 16 May 2014 09:51:43 +0200
Subject: [hibernate-dev] Making tests nicer with lambdas
In-Reply-To: <CADGJaX9mdvtNGCdcKgGOzwzNV4jQ4hL6BH9mKvRjD5F2aK8hAg@mail.gmail.com>
References: <CADGJaX9mdvtNGCdcKgGOzwzNV4jQ4hL6BH9mKvRjD5F2aK8hAg@mail.gmail.com>
Message-ID: <20140516075143.GH44615@hibernate.org>

These kind of tests are actually not in isolations between lambdas. You
often want to pass an id or value between blocks to be reused. I don't
think lambdas are porous enough for that. That would be surprising.

Emmanuel

On Fri 2014-04-25 10:41, Gunnar Morling wrote:
> Hey,
> 
> I've played around a bit with the idea of using Java 8 lambdas to make
> tests easier to write and read. We have many tests which open a session and
> TX, do some stuff, commit, open a new TX (and/or session), do some
> assertions and so on:
> 
>     Session session = openSession();
>   Transaction transaction = session.beginTransaction();
> 
>     // heavy testing action...
>     transaction.commit();
>   session.clear();
> 
>     transaction = session.beginTransaction();
> 
>     // load, assert...
>   transaction.commit();
>   session.clear();
> 
> The same could look like this using Java 8 lambdas:
> 
>     Foo foo = inTransactionWithResult( (session, tx) -> {
>         // heavy testing action...
>   } );
> 
>     inTransaction( (session, tx) -> {
>         // load, assert...
>   } );
> 
> Extracting the session/TX handling removes quite some clutter and focuses
> more on the actual testing logic. It also avoids problems due to dangling
> transactions e.g. in case of assertion failures as the TX handling is done
> in a finally block in inTransaction().
> 
> At this point I've just done a quick POC and would be interested in
> feedback whether you think that's worth pursuing or not. Note that
> different language levels can be used for test and main code, so we could
> make use of lambdas in tests while ensuring Java 6 compatibility for the
> delivered artifacts.
> 
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

From gunnar at hibernate.org  Fri May 16 04:25:20 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 16 May 2014 10:25:20 +0200
Subject: [hibernate-dev] Making tests nicer with lambdas
In-Reply-To: <20140516075143.GH44615@hibernate.org>
References: <CADGJaX9mdvtNGCdcKgGOzwzNV4jQ4hL6BH9mKvRjD5F2aK8hAg@mail.gmail.com>
	<20140516075143.GH44615@hibernate.org>
Message-ID: <CADGJaX-M7nE-UGkvTA-9M2ScUq+xDCcBCFATC6ULOYbYmK0jmQ@mail.gmail.com>

I had envisioned inTransactionWithResult() for that purpose. This returns a
value which can be used in the next lambda expression:

    Foo foo = inTransactionWithResult( (session, tx) -> {
        Foo f = new Foo();
        em.persist( f );
  } );

    inTransaction( (session, tx) -> {
        Foo f = em.find( Foo.class, foo.getId() );
        ...
  } );

But admittedly it doesn't work that nicely when more then one value needs
to be passed between lambdas. Also there is naming conflict between the
variable within the lambda expression and the variable holding the result.
One would naturally like to use the same name - as it is the same thing -
but that's not possible.

I didn't pursue the idea any further since then.

--Gunnar









2014-05-16 9:51 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> These kind of tests are actually not in isolations between lambdas. You
> often want to pass an id or value between blocks to be reused. I don't
> think lambdas are porous enough for that. That would be surprising.
>
> Emmanuel
>
> On Fri 2014-04-25 10:41, Gunnar Morling wrote:
> > Hey,
> >
> > I've played around a bit with the idea of using Java 8 lambdas to make
> > tests easier to write and read. We have many tests which open a session
> and
> > TX, do some stuff, commit, open a new TX (and/or session), do some
> > assertions and so on:
> >
> >     Session session = openSession();
> >   Transaction transaction = session.beginTransaction();
> >
> >     // heavy testing action...
> >     transaction.commit();
> >   session.clear();
> >
> >     transaction = session.beginTransaction();
> >
> >     // load, assert...
> >   transaction.commit();
> >   session.clear();
> >
> > The same could look like this using Java 8 lambdas:
> >
> >     Foo foo = inTransactionWithResult( (session, tx) -> {
> >         // heavy testing action...
> >   } );
> >
> >     inTransaction( (session, tx) -> {
> >         // load, assert...
> >   } );
> >
> > Extracting the session/TX handling removes quite some clutter and focuses
> > more on the actual testing logic. It also avoids problems due to dangling
> > transactions e.g. in case of assertion failures as the TX handling is
> done
> > in a finally block in inTransaction().
> >
> > At this point I've just done a quick POC and would be interested in
> > feedback whether you think that's worth pursuing or not. Note that
> > different language levels can be used for test and main code, so we could
> > make use of lambdas in tests while ensuring Java 6 compatibility for the
> > delivered artifacts.
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From hardy at hibernate.org  Fri May 16 07:22:52 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Fri, 16 May 2014 13:22:52 +0200
Subject: [hibernate-dev] [WEBSITE]
	hibernate-[project]-metadata.properties
In-Reply-To: <29BBC613-DF48-4BB5-BC6C-FD3079302BAA@hibernate.org>
References: <29BBC613-DF48-4BB5-BC6C-FD3079302BAA@hibernate.org>
Message-ID: <C7255475-172F-41F1-A218-E453485ABEFA@hibernate.org>


On 15 Jan 2014, at 23:07, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> Under the /project/ directory, you will find a strange .properties file. It will be used by jboss.org to collect up to date metadata about our projects.

How is that going to be used?

> If something like CI, issue tracker, tagline, etc changes, these should be updated.
> I?ve pushed the files and opened an issue to automate the file generation to reduce the risk of discrepancies https://hibernate.atlassian.net/browse/WEBSITE-189

+1 Should definitely be generated.

?Hardy

From emmanuel at hibernate.org  Fri May 16 09:03:17 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Fri, 16 May 2014 15:03:17 +0200
Subject: [hibernate-dev] [WEBSITE]
	hibernate-[project]-metadata.properties
In-Reply-To: <C7255475-172F-41F1-A218-E453485ABEFA@hibernate.org>
References: <29BBC613-DF48-4BB5-BC6C-FD3079302BAA@hibernate.org>
	<C7255475-172F-41F1-A218-E453485ABEFA@hibernate.org>
Message-ID: <2DD8A545-9672-4545-86FC-E26D459E205D@hibernate.org>


On 16 May 2014, at 13:22, Hardy Ferentschik <hardy at hibernate.org> wrote:

> 
> On 15 Jan 2014, at 23:07, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> Under the /project/ directory, you will find a strange .properties file. It will be used by jboss.org to collect up to date metadata about our projects.
> 
> How is that going to be used?

jboss.org noew infra will read this and generate a UI

> 
>> If something like CI, issue tracker, tagline, etc changes, these should be updated.
>> I?ve pushed the files and opened an issue to automate the file generation to reduce the risk of discrepancies https://hibernate.atlassian.net/browse/WEBSITE-189
> 
> +1 Should definitely be generated.
> 
> ?Hardy



From gbadner at redhat.com  Fri May 16 19:20:10 2014
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 16 May 2014 19:20:10 -0400 (EDT)
Subject: [hibernate-dev] Envers: Mapped-superclasses extended by
	embeddabables
In-Reply-To: <320975338.1782891.1400281705521.JavaMail.zimbra@redhat.com>
Message-ID: <859782354.1784121.1400282410002.JavaMail.zimbra@redhat.com>

Hi Adam,

The relevant issues:
HHH-8908 : Envers: Column of Embedded missing in Audit Table
HHH-9194 : Revert HHH-8908 fix
HHH-9193 : Default audit behavior of a mapped-superclass is inconsistent when extended by an entity vs an embeddable

I created a pull request for reverting HHH-8908 (https://github.com/hibernate/hibernate-orm/pull/742). The fix is reverted for HHH-9194 and I've re-purposed the testcases that were added to HHH-8908 for HHH-9193. I'm still a little fuzzy of the expectations of these tests, so please take a look at the pull request and let me know if anything needs to be changed.

I'm still unsure how on the ways to explicitly enable auditing for a mapped-superclass as a whole or particular fields/methods. Here are some guesses on how I think it should work. Assume the following uses AccessType.FIELD.

In the following, A.b.intValue should be audited; A.b.strValue should not be audited.

@Entity
@Audited
public class A{
    ...
    private B b;
    ...
}

@Embeddable
public class B extends AbstractB {
    private int intValue;
}

@MappedSuperclass
public class AbstractB {
    private String strValue;
}

In the following, both A.b.intValue and A.b.strValue should be audited:

@Entity
@Audited
@AuditOverride( name="b.strValue" )
public class A{
    ...
    private B b;
    ...
}

@Embeddable
public class B extends AbstractB {
    private int intValue;
}

@MappedSuperclass
public class AbstractB {
    private String strValue;
}

In the following, both A.b.intValue and A.b.strValue should be audited:

@Entity
@Audited
public class A{
    ...
    private B b;
    ...
}

@Embeddable
public class B extends AbstractB {
    private int intValue;
}

@MappedSuperclass
@Audited
public class AbstractB {
    private String strValue;
}

In the following, both A.b.intValue and A.b.strValue should be audited. 

@Entity
@Audited
public class A{
    ...
    private B b;
    ...
}

@Embeddable
@AuditOverride( class=AbstractB.class )
public class B extends AbstractB {
    private int intValue;
}

@MappedSuperclass
public class AbstractB {
    private String strValue;
}

What should be the outcome of the following? Should A.b.strValue still be audited even though A.b is explicitly not audited?

@Entity
@Audited
public class A{
    ...
    @NotAudited
    private B b;
    ...
}

@Embeddable
public class B extends AbstractB {
    private int intValue;
}

@MappedSuperclass
@Audited
public class AbstractB {
    private String strValue;
}

Please clarify or correct as necessary. At this point, I'm not sure which of the above cases work. Once the expected behavior is clarified, tests should be added to ensure that envers operates as expected. Jira issues should be added for cases that don't work.

Thanks,
Gail

From gunnar at hibernate.org  Mon May 19 03:28:38 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 19 May 2014 09:28:38 +0200
Subject: [hibernate-dev] Changing method signatures in micro releases
Message-ID: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>

Hi,

When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a changed
method signature in AbstractCollectionPersister (abstract
method doProcessQueuedOps() has a new parameter).

This causes a compilation failure in OGM, as we naturally still override
the old signature. I can solve this particular case in a compatible manner
by declaring both variants of the method in our sub-class (omitting the
@Override annotation), but I'm wondering how we should generally deal with
this kind of issue.

Are micro-releases considered strictly backwards-compatible, so that e.g.
all of ORM 4.3.x should be useable together with an integrator (such as
OGM) known to work with 4.3.0? This would have been my assumption
originally.

Are there any rules for what kind of changes are to be expected by an ORM
micro/minor/major update?

Thanks,

--Gunnar

From gbadner at redhat.com  Mon May 19 15:34:09 2014
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 19 May 2014 15:34:09 -0400 (EDT)
Subject: [hibernate-dev] Changing method signatures in micro releases
In-Reply-To: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
References: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
Message-ID: <214051673.2943844.1400528049085.JavaMail.zimbra@redhat.com>

Hi Gunnar, 

Thanks for mentioning this. I believe that org.hibernate.persister.collection and org.hibernate.persister.entity are considered APIs, which should definitely be backward-compatible for micro releases.

I'm looking at some alternatives to mitigate that. My first thought is that the fix for HHH-9078 should have been made only to OneToManyPersister, so that AbstractCollectionPersister would not be affected. If this is possible, I will add the old method back and deprecate the new one that caused you trouble.

I'll let you know what I find.

Regards,
Gail

----- Original Message -----
> From: "Gunnar Morling" <gunnar at hibernate.org>
> To: hibernate-dev at lists.jboss.org
> Sent: Monday, May 19, 2014 12:28:38 AM
> Subject: [hibernate-dev] Changing method signatures in micro releases
> 
> Hi,
> 
> When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a changed
> method signature in AbstractCollectionPersister (abstract
> method doProcessQueuedOps() has a new parameter).
> 
> This causes a compilation failure in OGM, as we naturally still override
> the old signature. I can solve this particular case in a compatible manner
> by declaring both variants of the method in our sub-class (omitting the
> @Override annotation), but I'm wondering how we should generally deal with
> this kind of issue.
> 
> Are micro-releases considered strictly backwards-compatible, so that e.g.
> all of ORM 4.3.x should be useable together with an integrator (such as
> OGM) known to work with 4.3.0? This would have been my assumption
> originally.
> 
> Are there any rules for what kind of changes are to be expected by an ORM
> micro/minor/major update?
> 
> 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  Mon May 19 18:16:56 2014
From: gbadner at redhat.com (Gail Badner)
Date: Mon, 19 May 2014 18:16:56 -0400 (EDT)
Subject: [hibernate-dev] Changing method signatures in micro releases
In-Reply-To: <214051673.2943844.1400528049085.JavaMail.zimbra@redhat.com>
References: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
	<214051673.2943844.1400528049085.JavaMail.zimbra@redhat.com>
Message-ID: <746066896.3028150.1400537816147.JavaMail.zimbra@redhat.com>

It was a simple matter to restore the old the method and provide a default implementation of the method added by HHH-9078.

I've create the following issues:

For master, 4.3, and 4.2 (because HHH-9078 was fixed on master, 4.3, and 4.2):
HHH-9204: Restore AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection, Serializable, SessionImplementor)
HHH-9205: Deprecate AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection, Serializable, int, SessionImplementor)

For master only:
HHH-9206: Remove AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection, Serializable, int, SessionImplementor)

Steve, I'm not 100% I did the right thing for HHH-9204 and HHH-9205, so please take a look at the pull request:
https://github.com/hibernate/hibernate-orm/pull/747

Thanks,
Gail 

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "Gunnar Morling" <gunnar at hibernate.org>
> Cc: hibernate-dev at lists.jboss.org
> Sent: Monday, May 19, 2014 12:34:09 PM
> Subject: Re: [hibernate-dev] Changing method signatures in micro releases
> 
> Hi Gunnar,
> 
> Thanks for mentioning this. I believe that org.hibernate.persister.collection
> and org.hibernate.persister.entity are considered APIs, which should
> definitely be backward-compatible for micro releases.
> 
> I'm looking at some alternatives to mitigate that. My first thought is that
> the fix for HHH-9078 should have been made only to OneToManyPersister, so
> that AbstractCollectionPersister would not be affected. If this is possible,
> I will add the old method back and deprecate the new one that caused you
> trouble.
> 
> I'll let you know what I find.
> 
> Regards,
> Gail
> 
> ----- Original Message -----
> > From: "Gunnar Morling" <gunnar at hibernate.org>
> > To: hibernate-dev at lists.jboss.org
> > Sent: Monday, May 19, 2014 12:28:38 AM
> > Subject: [hibernate-dev] Changing method signatures in micro releases
> > 
> > Hi,
> > 
> > When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a changed
> > method signature in AbstractCollectionPersister (abstract
> > method doProcessQueuedOps() has a new parameter).
> > 
> > This causes a compilation failure in OGM, as we naturally still override
> > the old signature. I can solve this particular case in a compatible manner
> > by declaring both variants of the method in our sub-class (omitting the
> > @Override annotation), but I'm wondering how we should generally deal with
> > this kind of issue.
> > 
> > Are micro-releases considered strictly backwards-compatible, so that e.g.
> > all of ORM 4.3.x should be useable together with an integrator (such as
> > OGM) known to work with 4.3.0? This would have been my assumption
> > originally.
> > 
> > Are there any rules for what kind of changes are to be expected by an ORM
> > micro/minor/major update?
> > 
> > Thanks,
> > 
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From sanne at hibernate.org  Tue May 20 09:09:13 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 20 May 2014 14:09:13 +0100
Subject: [hibernate-dev] Hibernate Search vs. 5.0.0.Alpha4 was released:
	Requires Java7 !
Message-ID: <CAFm4XO0h+P24cn-AwreXiRA1Sx8o20bO+QFeKvRBVuhvEzqVEw@mail.gmail.com>

Hello all,
we released version 5.0.0.Alpha4 of Hibernate Search

All details on:
  http://in.relation.to/Bloggers/HibernateSearchNowRequiresJava7BringsOSGiAndFieldBridgeDiscovery

Please note it requires Java7 at runtime!

Sanne

From steve at hibernate.org  Tue May 20 09:18:12 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 May 2014 08:18:12 -0500
Subject: [hibernate-dev] Changing method signatures in micro releases
In-Reply-To: <214051673.2943844.1400528049085.JavaMail.zimbra@redhat.com>
References: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
	<214051673.2943844.1400528049085.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9tSCazOq75vHY9PUgWDL0wGnB9Yr5cwNv5YhDxe30jk3A@mail.gmail.com>

Persisters are most certainly not generally considered APIs.  We simply
have not yet done the packaging split there.  APIs are things you use in
your application.  Applications generally are not calling persisters in
normal usage.


On Mon, May 19, 2014 at 2:34 PM, Gail Badner <gbadner at redhat.com> wrote:

> Hi Gunnar,
>
> Thanks for mentioning this. I believe that
> org.hibernate.persister.collection and org.hibernate.persister.entity are
> considered APIs, which should definitely be backward-compatible for micro
> releases.
>
> I'm looking at some alternatives to mitigate that. My first thought is
> that the fix for HHH-9078 should have been made only to OneToManyPersister,
> so that AbstractCollectionPersister would not be affected. If this is
> possible, I will add the old method back and deprecate the new one that
> caused you trouble.
>
> I'll let you know what I find.
>
> Regards,
> Gail
>
> ----- Original Message -----
> > From: "Gunnar Morling" <gunnar at hibernate.org>
> > To: hibernate-dev at lists.jboss.org
> > Sent: Monday, May 19, 2014 12:28:38 AM
> > Subject: [hibernate-dev] Changing method signatures in micro releases
> >
> > Hi,
> >
> > When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a changed
> > method signature in AbstractCollectionPersister (abstract
> > method doProcessQueuedOps() has a new parameter).
> >
> > This causes a compilation failure in OGM, as we naturally still override
> > the old signature. I can solve this particular case in a compatible
> manner
> > by declaring both variants of the method in our sub-class (omitting the
> > @Override annotation), but I'm wondering how we should generally deal
> with
> > this kind of issue.
> >
> > Are micro-releases considered strictly backwards-compatible, so that e.g.
> > all of ORM 4.3.x should be useable together with an integrator (such as
> > OGM) known to work with 4.3.0? This would have been my assumption
> > originally.
> >
> > Are there any rules for what kind of changes are to be expected by an ORM
> > micro/minor/major update?
> >
> > Thanks,
> >
> > --Gunnar
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From steve at hibernate.org  Tue May 20 09:28:11 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 May 2014 08:28:11 -0500
Subject: [hibernate-dev] Changing method signatures in micro releases
In-Reply-To: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
References: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
Message-ID: <CAFdSV9tKBUoM+V-YHVKUV14bchTV0M797W_7MzO+bTprQppKqA@mail.gmail.com>

We do strive to maintain backwards compatibility of SPIs.  That being said,
there are times when fixing a bug requires a new SPI method.  Which *seems*
to have been the case here.

First, I am not sure what you mean by OGM "naturally still override the old
signature".  What "old signature"?  This is a completely new method.  The
change here introduced CollectionPersister#processQueuedOps.
AbstractCollectionPersister
implements that processQueuedOps somewhat eventually delegating to
doProcessQueuedOps.
 Do you mean processQueuedOps?  If so, both these methods were added at the
same time.


On Mon, May 19, 2014 at 2:28 AM, Gunnar Morling <gunnar at hibernate.org>wrote:

> Hi,
>
> When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a changed
> method signature in AbstractCollectionPersister (abstract
> method doProcessQueuedOps() has a new parameter).
>
> This causes a compilation failure in OGM, as we naturally still override
> the old signature. I can solve this particular case in a compatible manner
> by declaring both variants of the method in our sub-class (omitting the
> @Override annotation), but I'm wondering how we should generally deal with
> this kind of issue.
>
> Are micro-releases considered strictly backwards-compatible, so that e.g.
> all of ORM 4.3.x should be useable together with an integrator (such as
> OGM) known to work with 4.3.0? This would have been my assumption
> originally.
>
> Are there any rules for what kind of changes are to be expected by an ORM
> micro/minor/major update?
>
> Thanks,
>
> --Gunnar
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From gunnar at hibernate.org  Tue May 20 09:59:15 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Tue, 20 May 2014 15:59:15 +0200
Subject: [hibernate-dev] Changing method signatures in micro releases
In-Reply-To: <CAFdSV9tKBUoM+V-YHVKUV14bchTV0M797W_7MzO+bTprQppKqA@mail.gmail.com>
References: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
	<CAFdSV9tKBUoM+V-YHVKUV14bchTV0M797W_7MzO+bTprQppKqA@mail.gmail.com>
Message-ID: <CADGJaX_qJKcPLu+_WqOjYs+iJw2mQN5oRJX_yvcCxvaXMy=YXA@mail.gmail.com>

Gail, Steve,

Thanks for your replies.

2014-05-20 15:28 GMT+02:00 Steve Ebersole <steve at hibernate.org>:

> We do strive to maintain backwards compatibility of SPIs.  That being
> said, there are times when fixing a bug requires a new SPI method.  Which
> *seems* to have been the case here.
>

That's good news.

In your other mail you said "We simply have not yet done the packaging
split there"; Is this to say AbstractCollectionPersister will move into
another package in the future which makes more apparent that it is an SPI
type?


>
> First, I am not sure what you mean by OGM "naturally still override the
> old signature".  What "old signature"?  This is a completely new method.  The
> change here introduced CollectionPersister#processQueuedOps.  AbstractCollectionPersister
> implements that processQueuedOps somewhat eventually delegating to doProcessQueuedOps.
>  Do you mean processQueuedOps?  If so, both these methods were added at
> the same time.
>

I mean doProcessQueuedOps() whose signature has changed between 4.3.4 and
4.3.5 from

    protected abstract void doProcessQueuedOps(PersistentCollection
collection, Serializable key, SessionImplementor session)

to

    protected abstract void doProcessQueuedOps(PersistentCollection
collection, Serializable key, int nextIndex, SessionImplementor session)

Our implementation used to override the former and thus didn't compile
against 4.3.5 after doing the update. I'm now declaring both versions, so
we can run with ORM <= 4.3.4 and >= 4.3.5.

--Gunnar



>
> On Mon, May 19, 2014 at 2:28 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
>
>> Hi,
>>
>> When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a changed
>> method signature in AbstractCollectionPersister (abstract
>> method doProcessQueuedOps() has a new parameter).
>>
>> This causes a compilation failure in OGM, as we naturally still override
>> the old signature. I can solve this particular case in a compatible manner
>> by declaring both variants of the method in our sub-class (omitting the
>> @Override annotation), but I'm wondering how we should generally deal with
>> this kind of issue.
>>
>> Are micro-releases considered strictly backwards-compatible, so that e.g.
>> all of ORM 4.3.x should be useable together with an integrator (such as
>> OGM) known to work with 4.3.0? This would have been my assumption
>> originally.
>>
>> Are there any rules for what kind of changes are to be expected by an ORM
>> micro/minor/major update?
>>
>> Thanks,
>>
>> --Gunnar
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>

From steve at hibernate.org  Tue May 20 12:09:43 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 May 2014 11:09:43 -0500
Subject: [hibernate-dev] IRC Developer meeting
Message-ID: <CAFdSV9um5hLE6gxxgVNh-b9Tt1W7mGTx0=APqJ1MnXhCyaGZ-w@mail.gmail.com>

Discussed new header for source files, new ParameterRecognizer for OGM
integration, and "DynamicAttributeContributor" for OGM/Infinispan support
(to be fleshed out more).

[11:06] <jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-20-14.48.html
[11:06] <jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-20-14.48.txt
[11:06] <jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-20-14.48.log.html

From sanne at hibernate.org  Tue May 20 14:14:26 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 20 May 2014 19:14:26 +0100
Subject: [hibernate-dev] HQL-Parser project to move to Java7?
Message-ID: <CAFm4XO2bV6Hy2AT9+DDxDknv60N7-SDXHTkMWynN9G1JsT+CBw@mail.gmail.com>

One of the modules of the HQL Parser project is now going to require
Java7 at runtime, which implies I have to compile that one with Java7
and use Java7 for testing.

Would it be ok to move the whole project to use Java7?

I don't stricly need all modules to drop Java6, but it would keep the
build simple, and I suspect we have no reason to keep this project
Java6 compatible.

Sanne

From steve at hibernate.org  Tue May 20 15:05:41 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 20 May 2014 14:05:41 -0500
Subject: [hibernate-dev] HQL-Parser project to move to Java7?
In-Reply-To: <CAFm4XO2bV6Hy2AT9+DDxDknv60N7-SDXHTkMWynN9G1JsT+CBw@mail.gmail.com>
References: <CAFm4XO2bV6Hy2AT9+DDxDknv60N7-SDXHTkMWynN9G1JsT+CBw@mail.gmail.com>
Message-ID: <CAFdSV9tx0MdBTdF0-QtB+ixu2wsqFCm9getL=JHGjLBHUAdBpQ@mail.gmail.com>

I'd prefer to not as we discussed on IRC


On Tue, May 20, 2014 at 1:14 PM, Sanne Grinovero <sanne at hibernate.org>wrote:

> One of the modules of the HQL Parser project is now going to require
> Java7 at runtime, which implies I have to compile that one with Java7
> and use Java7 for testing.
>
> Would it be ok to move the whole project to use Java7?
>
> I don't stricly need all modules to drop Java6, but it would keep the
> build simple, and I suspect we have no reason to keep this project
> Java6 compatible.
>
> Sanne
>

From sanne at hibernate.org  Tue May 20 16:54:42 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Tue, 20 May 2014 21:54:42 +0100
Subject: [hibernate-dev] Released HQL Parser versions 1.1.0.Alpha1 and
	1.1.0.Alpha2
Message-ID: <CAFm4XO3GK8CM7i7mwb8aGLYt=rnzt=zKaMPy11w1dSQPaLMW6Q@mail.gmail.com>

I've released both versions:
 1.1.0.Alpha1 is compatible with Hibernate Search 5.0.0.Alpha1
 1.1.0.Alpha2 is compatible with Hibernate Search 5.0.0.Alpha4

(I needed both as there are too many changes in Search to handle a single leap)

The target Java version is 1.6 as discussed with Steve; however if
you'll us it in combination with Hibernate Search 5 you'll need Java7
anyway (independent modules).

Cheers,
Sanne

From gbadner at redhat.com  Tue May 20 17:33:49 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 20 May 2014 17:33:49 -0400 (EDT)
Subject: [hibernate-dev] EntityPersister and Queryable
In-Reply-To: <1207944267.3867694.1400619865323.JavaMail.zimbra@redhat.com>
Message-ID: <1025106290.3882517.1400621629479.JavaMail.zimbra@redhat.com>

Because AbstractEntityPersister implements Queryable (but EntityPersister does not), core does something like this to get access to Queryable interface methods:

    final Queryable queryable = (Queryable) sessionFactory.getEntityPersister( entityName );

Is this an acceptable way for an application to get access to an entity persister's Queryable interface or is there some explicit SPI that should be used?

Thanks,
Gail

From adam at warski.org  Wed May 21 00:45:28 2014
From: adam at warski.org (Adam Warski)
Date: Wed, 21 May 2014 06:45:28 +0200
Subject: [hibernate-dev] Envers: Mapped-superclasses extended by
	embeddabables
In-Reply-To: <859782354.1784121.1400282410002.JavaMail.zimbra@redhat.com>
References: <859782354.1784121.1400282410002.JavaMail.zimbra@redhat.com>
Message-ID: <F97E3572-6CE1-4D5A-950D-C53E31717C6E@warski.org>

Sorry, no idea why I missed that email.

So the basic rule is:
- fields from a non-audited mapped superclass are never audited, unless an @AuditOverride is specified
- if the mapped superclass is audited, then its fields are of course audited as well

I don?t think we want to get into supporting a @AuditOverride(?b.field?) syntax, as it complicates the whole thing. When an @AO is placed on a component, the names refer to what is inside the component, so I guess we can use it here?

To address the specific questions:

> In the following, A.b.intValue should be audited; A.b.strValue should not be audited.
> 
> @Entity
> @Audited
> public class A{
>    ...
>    private B b;
>    ...
> }
> 
> @Embeddable
> public class B extends AbstractB {
>    private int intValue;
> }
> 
> @MappedSuperclass
> public class AbstractB {
>    private String strValue;
> }

Looks good

> In the following, both A.b.intValue and A.b.strValue should be audited:
> 
> @Entity
> @Audited
> @AuditOverride( name="b.strValue" )
> public class A{
>    ...
>    private B b;
>    ...
> }
> 
> @Embeddable
> public class B extends AbstractB {
>    private int intValue;
> }
> 
> @MappedSuperclass
> public class AbstractB {
>    private String strValue;
> }

As above, I don?t think we want to supoprt @AO(name=?b.strValue?)? To audit b.strValue, you?d have to add an @AO(name=?strValue?, forClass=AbstractB.class) on the b field directly.

> In the following, both A.b.intValue and A.b.strValue should be audited:
> 
> @Entity
> @Audited
> public class A{
>    ...
>    private B b;
>    ...
> }
> 
> @Embeddable
> public class B extends AbstractB {
>    private int intValue;
> }
> 
> @MappedSuperclass
> @Audited
> public class AbstractB {
>    private String strValue;
> }

Yes

> In the following, both A.b.intValue and A.b.strValue should be audited. 
> 
> @Entity
> @Audited
> public class A{
>    ...
>    private B b;
>    ...
> }
> 
> @Embeddable
> @AuditOverride( class=AbstractB.class )
> public class B extends AbstractB {
>    private int intValue;
> }
> 
> @MappedSuperclass
> public class AbstractB {
>    private String strValue;
> }

Yes

> What should be the outcome of the following? Should A.b.strValue still be audited even though A.b is explicitly not audited?
> 
> @Entity
> @Audited
> public class A{
>    ...
>    @NotAudited
>    private B b;
>    ...
> }
> 
> @Embeddable
> public class B extends AbstractB {
>    private int intValue;
> }
> 
> @MappedSuperclass
> @Audited
> public class AbstractB {
>    private String strValue;
> }

@NotAudited has precedence - so not audited.

I hope things are a bit clearer :). I suppose we should document these rules. If, of course, you think these rules are sound - any other ideas are always welcome :)

Adam

-- 
Adam Warski

http://twitter.com/#!/adamwarski
http://www.softwaremill.com
http://www.warski.org


From gunnar at hibernate.org  Wed May 21 03:10:30 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Wed, 21 May 2014 09:10:30 +0200
Subject: [hibernate-dev] HQL-Parser project to move to Java7?
In-Reply-To: <CAFm4XO2bV6Hy2AT9+DDxDknv60N7-SDXHTkMWynN9G1JsT+CBw@mail.gmail.com>
References: <CAFm4XO2bV6Hy2AT9+DDxDknv60N7-SDXHTkMWynN9G1JsT+CBw@mail.gmail.com>
Message-ID: <CADGJaX-TM8MM-PSfGYnA+CcLfkwxhfH9L3TAAiSxfFFemoVy=Q@mail.gmail.com>

You could mandate Java 7 at build time (and thus use 7 for testing), while
keeping the output compatible with Java 6.

I think it's another indication that the Lucene backend should live in its
own repo to allow for a customization of this sort of things and
independent release cycles.

--Gunnar



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

> One of the modules of the HQL Parser project is now going to require
> Java7 at runtime, which implies I have to compile that one with Java7
> and use Java7 for testing.
>
> Would it be ok to move the whole project to use Java7?
>
> I don't stricly need all modules to drop Java6, but it would keep the
> build simple, and I suspect we have no reason to keep this project
> Java6 compatible.
>
> 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 21 08:24:23 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Wed, 21 May 2014 07:24:23 -0500
Subject: [hibernate-dev] EntityPersister and Queryable
In-Reply-To: <1025106290.3882517.1400621629479.JavaMail.zimbra@redhat.com>
References: <1207944267.3867694.1400619865323.JavaMail.zimbra@redhat.com>
	<1025106290.3882517.1400621629479.JavaMail.zimbra@redhat.com>
Message-ID: <CAFdSV9uzAtDzT6Xh=0bzEvAaYS82hVL8DhYUWu=m7Bn-GaF38w@mail.gmail.com>

To be honest, I am not sure what you are asking.  Persisters are not meant
for application use.


On Tue, May 20, 2014 at 4:33 PM, Gail Badner <gbadner at redhat.com> wrote:

> Because AbstractEntityPersister implements Queryable (but EntityPersister
> does not), core does something like this to get access to Queryable
> interface methods:
>
>     final Queryable queryable = (Queryable)
> sessionFactory.getEntityPersister( entityName );
>
> Is this an acceptable way for an application to get access to an entity
> persister's Queryable interface or is there some explicit SPI that should
> be used?
>
> Thanks,
> Gail
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

From m.schipperheyn at gmail.com  Wed May 21 13:07:25 2014
From: m.schipperheyn at gmail.com (Marc Schipperheyn)
Date: Wed, 21 May 2014 14:07:25 -0300
Subject: [hibernate-dev] Does @ContainedIn trigger reindexing
Message-ID: <CAGvEgx71ahLb2Zc8LA01QKTWKpFUVSmghHLAwvirZzX3n+3DdQ@mail.gmail.com>

I couldn't find a test on this and I'm wondering if with a structure with
on the one hand @IndexedEmbedded(includePaths={"id","someField"}) and on
the other hand @ContainedIn, there would be a reindexing triggered of the
embedded element if "someOtherField" was changed at the root element (but
not any of the indexedembedded paths). In other words, is @ContainedIn
"smart"?

Marc

From smarlow at redhat.com  Wed May 21 15:36:13 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 21 May 2014 15:36:13 -0400
Subject: [hibernate-dev] EntityManagerFactoryBuilderImpl constructor is
 accessing the CDI BeanManager too early (during 1st phase) ...
Message-ID: <537D002D.4020805@redhat.com>

I started to push on Hibernate master integration for WildFly [1] + 
Jipijapa [2].

http://pastie.org/9196859 is a NPE that occurs when the CDI BeanManager 
is accessed during the first (EntityManagerFactoryBuilder) phase. 
Hibernate ORM shouldn't use the BeanManager until the second phase.

Scott

[1] https://github.com/scottmarlow/wildfly/tree/hibernate5

[2] https://github.com/scottmarlow/jipijapa/tree/JIPI-31

From emmanuel at hibernate.org  Thu May 22 05:21:13 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 22 May 2014 11:21:13 +0200
Subject: [hibernate-dev] [OGM and others] API, SPI and FPI
Message-ID: <C7FCF5B3-28FB-41DC-AA15-C0F624370D5D@hibernate.org>

(This discussion is around OGM but it is a very generic subject applicable to all projects.)

I made a mistake in naming the spi packages SPI because the definition of SPI is quite narrow and even more narrower in Java than elsewhere.

## Definitions 

### SPI

In Java and according to Wikipedia, a SPI (Service provider interface) is related to the notion of ServiceLoader http://en.wikipedia.org/wiki/Service_Provider_Interface
We certainly do not (or very rarely) have these kinds of services in our SPI packages.

Another point of you comes from this StackOverflow article
https://stackoverflow.com/questions/2954372/difference-between-spi-and-api

- the API is the description of classes/interfaces/methods/... that you call and use to achieve a goal and
- the SPI is the description of classes/interfaces/methods/... that you extend and implement to achieve a goal

A third point of you is the NetBeans one
http://wiki.netbeans.org/DevFaqApiSpi

SPI stands for Service Provider Interface. It is a subset of all things that can be API specific to situations where a library is providing classes which are called by the application (or API library), and which typically change the things the application is able to do.

I think everyone agrees that an SPI is kind of API.

### IPI or FPI (Integrator / Framework Public Interface)

I will use FPI as it tastes better than IPI but I have no preferences over integrators vs frameworks.

Now in my mind and for some obscure reasons, SPI really meant FPI. To my credit, I have done that fairly constantly on Hibernate Search and Bean Validation. Hibernate OGM was never properly packaged initially so that?s another story.

A FPI is used by a framework integrating or extending the project exposing these FPIs.

## What does really matter?

It is useful to differentiate an API used from an API extended (SPI) because the constraints are different:

- APIs used can add new methods and should be interfaces rather than classes.
- APIs extended (SPIs) should be abstract classes so that a new contract added can be offered by the project without breaking implementors.

But from a user point of you, I?m tempted to say "so what??. It does not change your inclination to make use of that contract.

It is useful to differentiate application developer(*) facing APIs from framework/integrator facing APIs (FPIs) to keep the API simple to use and to document. There is also a tendency to consider the application developer more sacred than the framework/integrator when it comes to breaking backward compatibility.

(*) I say application developer here but it really the primary user group of your project whereas the integrators are usually less numerous and more controllable.

To me the latter (API/FPI) is more generally useful and that is the one I wish to separate in different packages naming conventions.
The former it seems to me is very often self-obvious to the user and project maintainers. And from a usage PoV, it does not really matter. Plus there are cases where a contract is both used and extended (JDBC?s Connection contract for example).

Can and should we split according to both dimensions? I don?t think so. And if I have to chose, I?d prefer to split according to the API/ FPI dimension which is more generally useful to our customers and makes it clear what is non breakable (API), what is inconvenient to break (FPI), what is free lunch (implementation).

## References

There has been some discussions in the past as well https://issues.jboss.org/browse/TAG-47

Emmanuel

From steve at hibernate.org  Thu May 22 10:32:10 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Thu, 22 May 2014 09:32:10 -0500
Subject: [hibernate-dev] [OGM and others] API, SPI and FPI
In-Reply-To: <C7FCF5B3-28FB-41DC-AA15-C0F624370D5D@hibernate.org>
References: <C7FCF5B3-28FB-41DC-AA15-C0F624370D5D@hibernate.org>
Message-ID: <CAFdSV9s_J2zArfay-sa3MFO6xBcP75GJkUiitPDFdjXR8S-irA@mail.gmail.com>

Deja vu as we have had this exact discussion before (and actually, our
discussions pre-date those TAG discussions....)

You are basing your specific reading of what SPI means based on a single
wikipedia page that goes out of its way to point out its incompleteness :)
 And really even then in my opinion you are reading too much into its
mention of the JDK ServiceLoader.  What the wikiepdia says specifically is:

*Service Provider Interface* (SPI) is an
API<http://en.wikipedia.org/wiki/Application_programming_interface>
intended
> to be implemented or extended by a third party. It can be used to enable
> framework extension and replaceable components


That's actually not much different (if at all) from how I use the term SPI.
 To me, SPI is simply "the API that is used between internal components to
accomplish something".  A specific important distinction here is that APIs
are meant for application code to bind to, SPIs are not.  As I have pointed
out probably 100 times already, yes there are 2 facets to this.  To me an
SPI is made up of:
1) The SPI contracts that are meant to be extended by users and/or 3rd
parties.
2) The SPI contracts that are not intended for extension.

Another correlated break down is:
1) SPI contracts that do things
2) SPI contracts that are inputs/outputs to (1)

Take for example, the idea of scanning deployments for annotated classes
(mainly because this one is fresh in my mind).  The main SPI contract here
is Scanner and ArchiveDescriptorFactory.  These are each intended as
extension points, they both "do stuff".  All the rest of the "scanning spi"
is inouts/outputs to these 2.  Why is this an important distinction?  Well,
generally speaking where we get into trouble in terms of "changing SPIs"
later is when we change this first group.  When we have to make
changes to Scanner
or make changes to ArchiveDescriptorFactory we cause problems downstream
for folks that implement/extend this stuff.  That's where patterns like
parameter objects and delegates are sooooooooo beneficial.  As an
illustration, say we need to pass some new information into the single
Scanner method (this was the recent case I worked through).  If that means
adding a new parameter to that Scanner method, well that just screwed every
implementor of the Scanner interface because now their implementation is no
longer valid.  If instead, Scanner had made use of parameter objects (it
now does btw), the parameter object itself would have been changed causing
no problem of existing Scanner implementations.  The "parameter object" is
still part of the SPI.  But it falls into this second category.  Changing
these guys is essentially irrelevant in terms of causing no issues for
existing SPI implementations.


And as far as "a tendency to consider the application developer more sacred
than the framework/integrator when it comes to breaking backward
compatibility" I would not phrase it like that.  There are  a few parts to
this in my mind:

First,  I think you need to step back and look at the bigger picture.  The
API defines the features that Hibernate is exposing to the application
(save this thing, find that thing).  Its kind of broad and generally avoids
defining a feature in relation to an interaction between 2 things.  SPIs in
many ways are inherently more complicated to design because they need to
consider both sides of the problem.  Going back to scanning, that SPI needs
to consider Hibernate's requirements from scanning as well as any
requirements the implementation needs especially accounting for any quirks
in the various potential implementations.

Second, because of the "overlap" or "integration" aspects between teams and
projects there needs to be coordination and cooperation when
building/designing an SPI.  To be honest, this part has been lacking even
within "our team" across projects because people get focused on their work.
 What happens instead, again from my perspective, is no
coordination/cooperation
occurs in the building/designing of these; and then later people get upset
when the SPI needs to change because it was not well designed to begin
with.  Another aspects of this is "more eyes"; the more people involved in
the design of an API (SPI fits in here equally) looking at it, the better
designed it will be.


All that said, I don't plan on changing use of the phrase SPI based on (a
questionable interpretation of) one wikipedia page.


On Thu, May 22, 2014 at 4:21 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:

> (This discussion is around OGM but it is a very generic subject applicable
> to all projects.)
>
> I made a mistake in naming the spi packages SPI because the definition of
> SPI is quite narrow and even more narrower in Java than elsewhere.
>
> ## Definitions
>
> ### SPI
>
> In Java and according to Wikipedia, a SPI (Service provider interface) is
> related to the notion of ServiceLoader
> http://en.wikipedia.org/wiki/Service_Provider_Interface
> We certainly do not (or very rarely) have these kinds of services in our
> SPI packages.
>
> Another point of you comes from this StackOverflow article
> https://stackoverflow.com/questions/2954372/difference-between-spi-and-api
>
> - the API is the description of classes/interfaces/methods/... that you
> call and use to achieve a goal and
> - the SPI is the description of classes/interfaces/methods/... that you
> extend and implement to achieve a goal
>
> A third point of you is the NetBeans one
> http://wiki.netbeans.org/DevFaqApiSpi
>
> SPI stands for Service Provider Interface. It is a subset of all things
> that can be API specific to situations where a library is providing classes
> which are called by the application (or API library), and which typically
> change the things the application is able to do.
>
> I think everyone agrees that an SPI is kind of API.
>
> ### IPI or FPI (Integrator / Framework Public Interface)
>
> I will use FPI as it tastes better than IPI but I have no preferences over
> integrators vs frameworks.
>
> Now in my mind and for some obscure reasons, SPI really meant FPI. To my
> credit, I have done that fairly constantly on Hibernate Search and Bean
> Validation. Hibernate OGM was never properly packaged initially so that?s
> another story.
>
> A FPI is used by a framework integrating or extending the project exposing
> these FPIs.
>
> ## What does really matter?
>
> It is useful to differentiate an API used from an API extended (SPI)
> because the constraints are different:
>
> - APIs used can add new methods and should be interfaces rather than
> classes.
> - APIs extended (SPIs) should be abstract classes so that a new contract
> added can be offered by the project without breaking implementors.
>
> But from a user point of you, I?m tempted to say "so what??. It does not
> change your inclination to make use of that contract.
>
> It is useful to differentiate application developer(*) facing APIs from
> framework/integrator facing APIs (FPIs) to keep the API simple to use and
> to document. There is also a tendency to consider the application developer
> more sacred than the framework/integrator when it comes to breaking
> backward compatibility.
>
> (*) I say application developer here but it really the primary user group
> of your project whereas the integrators are usually less numerous and more
> controllable.
>
> To me the latter (API/FPI) is more generally useful and that is the one I
> wish to separate in different packages naming conventions.
> The former it seems to me is very often self-obvious to the user and
> project maintainers. And from a usage PoV, it does not really matter. Plus
> there are cases where a contract is both used and extended (JDBC?s
> Connection contract for example).
>
> Can and should we split according to both dimensions? I don?t think so.
> And if I have to chose, I?d prefer to split according to the API/ FPI
> dimension which is more generally useful to our customers and makes it
> clear what is non breakable (API), what is inconvenient to break (FPI),
> what is free lunch (implementation).
>
> ## References
>
> There has been some discussions in the past as well
> https://issues.jboss.org/browse/TAG-47
>
> Emmanuel
> _______________________________________________
> 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 22 12:01:47 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Thu, 22 May 2014 18:01:47 +0200
Subject: [hibernate-dev] [OGM and others] API, SPI and FPI
In-Reply-To: <CAFdSV9s_J2zArfay-sa3MFO6xBcP75GJkUiitPDFdjXR8S-irA@mail.gmail.com>
References: <C7FCF5B3-28FB-41DC-AA15-C0F624370D5D@hibernate.org>
	<CAFdSV9s_J2zArfay-sa3MFO6xBcP75GJkUiitPDFdjXR8S-irA@mail.gmail.com>
Message-ID: <20140522160147.GV12589@hibernate.org>

You misread me. I have to plan to change the meaning of SPI. I just
pointed the few most prominent definitions I have found while
researching the subject. What did strike me though is that SPI is much
less defined and explained than I anticipated.

What I am questioning is whether an API / SPI split is more or less
useful than a API / FPI (as I call it in the email) split for the users
of our libraries.

Emmanuel

On Thu 2014-05-22  9:32, Steve Ebersole wrote:
> Deja vu as we have had this exact discussion before (and actually, our
> discussions pre-date those TAG discussions....)
> 
> You are basing your specific reading of what SPI means based on a single
> wikipedia page that goes out of its way to point out its incompleteness :)
>  And really even then in my opinion you are reading too much into its
> mention of the JDK ServiceLoader.  What the wikiepdia says specifically is:
> 
> *Service Provider Interface* (SPI) is an
> API<http://en.wikipedia.org/wiki/Application_programming_interface>
> intended
> > to be implemented or extended by a third party. It can be used to enable
> > framework extension and replaceable components
> 
> 
> That's actually not much different (if at all) from how I use the term SPI.
>  To me, SPI is simply "the API that is used between internal components to
> accomplish something".  A specific important distinction here is that APIs
> are meant for application code to bind to, SPIs are not.  As I have pointed
> out probably 100 times already, yes there are 2 facets to this.  To me an
> SPI is made up of:
> 1) The SPI contracts that are meant to be extended by users and/or 3rd
> parties.
> 2) The SPI contracts that are not intended for extension.
> 
> Another correlated break down is:
> 1) SPI contracts that do things
> 2) SPI contracts that are inputs/outputs to (1)
> 
> Take for example, the idea of scanning deployments for annotated classes
> (mainly because this one is fresh in my mind).  The main SPI contract here
> is Scanner and ArchiveDescriptorFactory.  These are each intended as
> extension points, they both "do stuff".  All the rest of the "scanning spi"
> is inouts/outputs to these 2.  Why is this an important distinction?  Well,
> generally speaking where we get into trouble in terms of "changing SPIs"
> later is when we change this first group.  When we have to make
> changes to Scanner
> or make changes to ArchiveDescriptorFactory we cause problems downstream
> for folks that implement/extend this stuff.  That's where patterns like
> parameter objects and delegates are sooooooooo beneficial.  As an
> illustration, say we need to pass some new information into the single
> Scanner method (this was the recent case I worked through).  If that means
> adding a new parameter to that Scanner method, well that just screwed every
> implementor of the Scanner interface because now their implementation is no
> longer valid.  If instead, Scanner had made use of parameter objects (it
> now does btw), the parameter object itself would have been changed causing
> no problem of existing Scanner implementations.  The "parameter object" is
> still part of the SPI.  But it falls into this second category.  Changing
> these guys is essentially irrelevant in terms of causing no issues for
> existing SPI implementations.
> 
> 
> And as far as "a tendency to consider the application developer more sacred
> than the framework/integrator when it comes to breaking backward
> compatibility" I would not phrase it like that.  There are  a few parts to
> this in my mind:
> 
> First,  I think you need to step back and look at the bigger picture.  The
> API defines the features that Hibernate is exposing to the application
> (save this thing, find that thing).  Its kind of broad and generally avoids
> defining a feature in relation to an interaction between 2 things.  SPIs in
> many ways are inherently more complicated to design because they need to
> consider both sides of the problem.  Going back to scanning, that SPI needs
> to consider Hibernate's requirements from scanning as well as any
> requirements the implementation needs especially accounting for any quirks
> in the various potential implementations.
> 
> Second, because of the "overlap" or "integration" aspects between teams and
> projects there needs to be coordination and cooperation when
> building/designing an SPI.  To be honest, this part has been lacking even
> within "our team" across projects because people get focused on their work.
>  What happens instead, again from my perspective, is no
> coordination/cooperation
> occurs in the building/designing of these; and then later people get upset
> when the SPI needs to change because it was not well designed to begin
> with.  Another aspects of this is "more eyes"; the more people involved in
> the design of an API (SPI fits in here equally) looking at it, the better
> designed it will be.
> 
> 
> All that said, I don't plan on changing use of the phrase SPI based on (a
> questionable interpretation of) one wikipedia page.
> 
> 
> On Thu, May 22, 2014 at 4:21 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
> 
> > (This discussion is around OGM but it is a very generic subject applicable
> > to all projects.)
> >
> > I made a mistake in naming the spi packages SPI because the definition of
> > SPI is quite narrow and even more narrower in Java than elsewhere.
> >
> > ## Definitions
> >
> > ### SPI
> >
> > In Java and according to Wikipedia, a SPI (Service provider interface) is
> > related to the notion of ServiceLoader
> > http://en.wikipedia.org/wiki/Service_Provider_Interface
> > We certainly do not (or very rarely) have these kinds of services in our
> > SPI packages.
> >
> > Another point of you comes from this StackOverflow article
> > https://stackoverflow.com/questions/2954372/difference-between-spi-and-api
> >
> > - the API is the description of classes/interfaces/methods/... that you
> > call and use to achieve a goal and
> > - the SPI is the description of classes/interfaces/methods/... that you
> > extend and implement to achieve a goal
> >
> > A third point of you is the NetBeans one
> > http://wiki.netbeans.org/DevFaqApiSpi
> >
> > SPI stands for Service Provider Interface. It is a subset of all things
> > that can be API specific to situations where a library is providing classes
> > which are called by the application (or API library), and which typically
> > change the things the application is able to do.
> >
> > I think everyone agrees that an SPI is kind of API.
> >
> > ### IPI or FPI (Integrator / Framework Public Interface)
> >
> > I will use FPI as it tastes better than IPI but I have no preferences over
> > integrators vs frameworks.
> >
> > Now in my mind and for some obscure reasons, SPI really meant FPI. To my
> > credit, I have done that fairly constantly on Hibernate Search and Bean
> > Validation. Hibernate OGM was never properly packaged initially so that?s
> > another story.
> >
> > A FPI is used by a framework integrating or extending the project exposing
> > these FPIs.
> >
> > ## What does really matter?
> >
> > It is useful to differentiate an API used from an API extended (SPI)
> > because the constraints are different:
> >
> > - APIs used can add new methods and should be interfaces rather than
> > classes.
> > - APIs extended (SPIs) should be abstract classes so that a new contract
> > added can be offered by the project without breaking implementors.
> >
> > But from a user point of you, I?m tempted to say "so what??. It does not
> > change your inclination to make use of that contract.
> >
> > It is useful to differentiate application developer(*) facing APIs from
> > framework/integrator facing APIs (FPIs) to keep the API simple to use and
> > to document. There is also a tendency to consider the application developer
> > more sacred than the framework/integrator when it comes to breaking
> > backward compatibility.
> >
> > (*) I say application developer here but it really the primary user group
> > of your project whereas the integrators are usually less numerous and more
> > controllable.
> >
> > To me the latter (API/FPI) is more generally useful and that is the one I
> > wish to separate in different packages naming conventions.
> > The former it seems to me is very often self-obvious to the user and
> > project maintainers. And from a usage PoV, it does not really matter. Plus
> > there are cases where a contract is both used and extended (JDBC?s
> > Connection contract for example).
> >
> > Can and should we split according to both dimensions? I don?t think so.
> > And if I have to chose, I?d prefer to split according to the API/ FPI
> > dimension which is more generally useful to our customers and makes it
> > clear what is non breakable (API), what is inconvenient to break (FPI),
> > what is free lunch (implementation).
> >
> > ## References
> >
> > There has been some discussions in the past as well
> > https://issues.jboss.org/browse/TAG-47
> >
> > Emmanuel
> > _______________________________________________
> > 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 22 12:03:34 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 22 May 2014 17:03:34 +0100
Subject: [hibernate-dev] [OGM and others] API, SPI and FPI
In-Reply-To: <CAFdSV9s_J2zArfay-sa3MFO6xBcP75GJkUiitPDFdjXR8S-irA@mail.gmail.com>
References: <C7FCF5B3-28FB-41DC-AA15-C0F624370D5D@hibernate.org>
	<CAFdSV9s_J2zArfay-sa3MFO6xBcP75GJkUiitPDFdjXR8S-irA@mail.gmail.com>
Message-ID: <CAFm4XO0iZ7WOB6i-Pm17A2nAyM7aSbEa=_-MQcsUJz=o7jpBng@mail.gmail.com>

Looks like we're all aligned?
Steve made some concrete examples, Emmanuel pointed out how we have
been defining this vs. apparently other people.

I don't feel the need to change our interpretation, if that's what is
being discussed.

It's good to remember that there are different kinds of SPIs; we
indeed came to the conclusion that it's often much nicer to have an
abstract class when the SPI is meant to be provided by 3rd party code
but I think we need an interface in that case as well (in addition to
the abstract class).

Also breaking an SPI could bring as much pain as an API change.. when
an API changs the user is often in the position to be able to do
something about it. More often people get in trouble because they are
using a mixture of versions of different frameworks and libraries
which are meant to work together, and they don't.. in such scenarios
the user might not be able to do something about it, other than
lobbying and begging for fixes and releases in projects out of his
control.
An API change just invalidates project for people who are not able to
recompile, and makes books and training outdated :) Sure that's
annoying too, my point is just that SPI is not less important
*generally* but it depends on what API and what SPI we're talking
about.

But even when we discuss the same "kind" of SPIs, some are more
critical than others, and some are "internal" SPIs (like
hibernate-search to hibernate-search module), some are very close
(hibernate-orm to hibernate-search) some are slightly further down
(infinispan - hibernate-search).. others need critical stability
(container integration, etc..). And of course it's less painfull when
it affects something that 99% of users didn't know it existed in the
first place.

Conclusion, the package name will never set a rule: to me it's more
like a reminder to be carefull in any way possible as "someone" is
going to hate me. I am personally not even a fan of these specific
package naming conventions, an annotation would be just as good,
provided it gets somehow visibility in the javadoc (or even hides
javadocs for internals).


Sanne

On 22 May 2014 15:32, Steve Ebersole <steve at hibernate.org> wrote:
> Deja vu as we have had this exact discussion before (and actually, our
> discussions pre-date those TAG discussions....)
>
> You are basing your specific reading of what SPI means based on a single
> wikipedia page that goes out of its way to point out its incompleteness :)
>  And really even then in my opinion you are reading too much into its
> mention of the JDK ServiceLoader.  What the wikiepdia says specifically is:
>
> *Service Provider Interface* (SPI) is an
> API<http://en.wikipedia.org/wiki/Application_programming_interface>
> intended
>> to be implemented or extended by a third party. It can be used to enable
>> framework extension and replaceable components
>
>
> That's actually not much different (if at all) from how I use the term SPI.
>  To me, SPI is simply "the API that is used between internal components to
> accomplish something".  A specific important distinction here is that APIs
> are meant for application code to bind to, SPIs are not.  As I have pointed
> out probably 100 times already, yes there are 2 facets to this.  To me an
> SPI is made up of:
> 1) The SPI contracts that are meant to be extended by users and/or 3rd
> parties.
> 2) The SPI contracts that are not intended for extension.
>
> Another correlated break down is:
> 1) SPI contracts that do things
> 2) SPI contracts that are inputs/outputs to (1)
>
> Take for example, the idea of scanning deployments for annotated classes
> (mainly because this one is fresh in my mind).  The main SPI contract here
> is Scanner and ArchiveDescriptorFactory.  These are each intended as
> extension points, they both "do stuff".  All the rest of the "scanning spi"
> is inouts/outputs to these 2.  Why is this an important distinction?  Well,
> generally speaking where we get into trouble in terms of "changing SPIs"
> later is when we change this first group.  When we have to make
> changes to Scanner
> or make changes to ArchiveDescriptorFactory we cause problems downstream
> for folks that implement/extend this stuff.  That's where patterns like
> parameter objects and delegates are sooooooooo beneficial.  As an
> illustration, say we need to pass some new information into the single
> Scanner method (this was the recent case I worked through).  If that means
> adding a new parameter to that Scanner method, well that just screwed every
> implementor of the Scanner interface because now their implementation is no
> longer valid.  If instead, Scanner had made use of parameter objects (it
> now does btw), the parameter object itself would have been changed causing
> no problem of existing Scanner implementations.  The "parameter object" is
> still part of the SPI.  But it falls into this second category.  Changing
> these guys is essentially irrelevant in terms of causing no issues for
> existing SPI implementations.
>
>
> And as far as "a tendency to consider the application developer more sacred
> than the framework/integrator when it comes to breaking backward
> compatibility" I would not phrase it like that.  There are  a few parts to
> this in my mind:
>
> First,  I think you need to step back and look at the bigger picture.  The
> API defines the features that Hibernate is exposing to the application
> (save this thing, find that thing).  Its kind of broad and generally avoids
> defining a feature in relation to an interaction between 2 things.  SPIs in
> many ways are inherently more complicated to design because they need to
> consider both sides of the problem.  Going back to scanning, that SPI needs
> to consider Hibernate's requirements from scanning as well as any
> requirements the implementation needs especially accounting for any quirks
> in the various potential implementations.
>
> Second, because of the "overlap" or "integration" aspects between teams and
> projects there needs to be coordination and cooperation when
> building/designing an SPI.  To be honest, this part has been lacking even
> within "our team" across projects because people get focused on their work.
>  What happens instead, again from my perspective, is no
> coordination/cooperation
> occurs in the building/designing of these; and then later people get upset
> when the SPI needs to change because it was not well designed to begin
> with.  Another aspects of this is "more eyes"; the more people involved in
> the design of an API (SPI fits in here equally) looking at it, the better
> designed it will be.
>
>
> All that said, I don't plan on changing use of the phrase SPI based on (a
> questionable interpretation of) one wikipedia page.
>
>
> On Thu, May 22, 2014 at 4:21 AM, Emmanuel Bernard <emmanuel at hibernate.org>wrote:
>
>> (This discussion is around OGM but it is a very generic subject applicable
>> to all projects.)
>>
>> I made a mistake in naming the spi packages SPI because the definition of
>> SPI is quite narrow and even more narrower in Java than elsewhere.
>>
>> ## Definitions
>>
>> ### SPI
>>
>> In Java and according to Wikipedia, a SPI (Service provider interface) is
>> related to the notion of ServiceLoader
>> http://en.wikipedia.org/wiki/Service_Provider_Interface
>> We certainly do not (or very rarely) have these kinds of services in our
>> SPI packages.
>>
>> Another point of you comes from this StackOverflow article
>> https://stackoverflow.com/questions/2954372/difference-between-spi-and-api
>>
>> - the API is the description of classes/interfaces/methods/... that you
>> call and use to achieve a goal and
>> - the SPI is the description of classes/interfaces/methods/... that you
>> extend and implement to achieve a goal
>>
>> A third point of you is the NetBeans one
>> http://wiki.netbeans.org/DevFaqApiSpi
>>
>> SPI stands for Service Provider Interface. It is a subset of all things
>> that can be API specific to situations where a library is providing classes
>> which are called by the application (or API library), and which typically
>> change the things the application is able to do.
>>
>> I think everyone agrees that an SPI is kind of API.
>>
>> ### IPI or FPI (Integrator / Framework Public Interface)
>>
>> I will use FPI as it tastes better than IPI but I have no preferences over
>> integrators vs frameworks.
>>
>> Now in my mind and for some obscure reasons, SPI really meant FPI. To my
>> credit, I have done that fairly constantly on Hibernate Search and Bean
>> Validation. Hibernate OGM was never properly packaged initially so that?s
>> another story.
>>
>> A FPI is used by a framework integrating or extending the project exposing
>> these FPIs.
>>
>> ## What does really matter?
>>
>> It is useful to differentiate an API used from an API extended (SPI)
>> because the constraints are different:
>>
>> - APIs used can add new methods and should be interfaces rather than
>> classes.
>> - APIs extended (SPIs) should be abstract classes so that a new contract
>> added can be offered by the project without breaking implementors.
>>
>> But from a user point of you, I?m tempted to say "so what??. It does not
>> change your inclination to make use of that contract.
>>
>> It is useful to differentiate application developer(*) facing APIs from
>> framework/integrator facing APIs (FPIs) to keep the API simple to use and
>> to document. There is also a tendency to consider the application developer
>> more sacred than the framework/integrator when it comes to breaking
>> backward compatibility.
>>
>> (*) I say application developer here but it really the primary user group
>> of your project whereas the integrators are usually less numerous and more
>> controllable.
>>
>> To me the latter (API/FPI) is more generally useful and that is the one I
>> wish to separate in different packages naming conventions.
>> The former it seems to me is very often self-obvious to the user and
>> project maintainers. And from a usage PoV, it does not really matter. Plus
>> there are cases where a contract is both used and extended (JDBC?s
>> Connection contract for example).
>>
>> Can and should we split according to both dimensions? I don?t think so.
>> And if I have to chose, I?d prefer to split according to the API/ FPI
>> dimension which is more generally useful to our customers and makes it
>> clear what is non breakable (API), what is inconvenient to break (FPI),
>> what is free lunch (implementation).
>>
>> ## References
>>
>> There has been some discussions in the past as well
>> https://issues.jboss.org/browse/TAG-47
>>
>> 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 gunnar at hibernate.org  Thu May 22 17:20:33 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Thu, 22 May 2014 23:20:33 +0200
Subject: [hibernate-dev] Hibernate OGM 4.1.0.Beta3 is out,
 bringing improved support for Neo4j, querying and more
Message-ID: <CADGJaX9adBet3x-jphGAY6kK=1P1niEpYWnqNo6SDsKq_iYVfQ@mail.gmail.com>

Hi,

It's my great pleasure to announce the release of Hibernate OGM 4.1.0.Beta3.

This release is focused on an improved experience when working with the
Neo4j graph datastore and several improvements in the field of querying.
Check out the announcement post for all the details [1].

--Gunnar

[1]
in.relation.to/Bloggers/HibernateOGM410Beta3IsOutBringingImprovedSupportForNeo4jQueryingAndMore

From sanne at hibernate.org  Thu May 22 17:24:54 2014
From: sanne at hibernate.org (Sanne Grinovero)
Date: Thu, 22 May 2014 22:24:54 +0100
Subject: [hibernate-dev] Does @ContainedIn trigger reindexing
In-Reply-To: <CAGvEgx71ahLb2Zc8LA01QKTWKpFUVSmghHLAwvirZzX3n+3DdQ@mail.gmail.com>
References: <CAGvEgx71ahLb2Zc8LA01QKTWKpFUVSmghHLAwvirZzX3n+3DdQ@mail.gmail.com>
Message-ID: <CAFm4XO24x-Ft2L88hYqhW-b9r3vs-yp1M1tt9+puGGe8dn7Few@mail.gmail.com>

Hi Marc,
yes there is a degree of "smartness" in such logic, it attempts to use
the dirtyness information provided by the ORM and will skip indexing
operations if no field is changed among those which affect the index
state.
This is rather conservative, so the optimisation is disabled if there
are custom bridges on the involved entities as in that case we can't
safely relate the set of dirty fields to the index state.

As ultimate defense, if this is causing some undesired behaviour you
can disable it globally: see the hibernate.search.enable_dirty_check
configuration property in the documentation.

Sanne

On 21 May 2014 18:07, Marc Schipperheyn <m.schipperheyn at gmail.com> wrote:
> I couldn't find a test on this and I'm wondering if with a structure with
> on the one hand @IndexedEmbedded(includePaths={"id","someField"}) and on
> the other hand @ContainedIn, there would be a reindexing triggered of the
> embedded element if "someOtherField" was changed at the root element (but
> not any of the indexedembedded paths). In other words, is @ContainedIn
> "smart"?
>
> Marc
> _______________________________________________
> 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 23 09:27:26 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Fri, 23 May 2014 09:27:26 -0400
Subject: [hibernate-dev] EntityManagerFactoryBuilderImpl constructor is
 accessing the CDI BeanManager too early (during 1st phase) ...
In-Reply-To: <537D002D.4020805@redhat.com>
References: <537D002D.4020805@redhat.com>
Message-ID: <537F4CBE.2060307@redhat.com>

On 05/21/2014 03:36 PM, Scott Marlow wrote:
> I started to push on Hibernate master integration for WildFly [1] +
> Jipijapa [2].
>
> http://pastie.org/9196859 is a NPE that occurs when the CDI BeanManager
> is accessed during the first (EntityManagerFactoryBuilder) phase.
> Hibernate ORM shouldn't use the BeanManager until the second phase.

I'll create a HHH jira for the BeanManager access issue.

I'm also hitting some issues in existing unit tests (WildFly + Jipijapa) 
that I worked around by commenting them out.  We can discuss on IRC 
sometime or I could give more details here.

After we get past these issues, I'll make the change to pass the Jandex 
CompositeIndex into Hibernate 5.x, so we can see how that works.

>
> Scott
>
> [1] https://github.com/scottmarlow/wildfly/tree/hibernate5
>
> [2] https://github.com/scottmarlow/jipijapa/tree/JIPI-31
> _______________________________________________
> 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 23 11:10:10 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Fri, 23 May 2014 10:10:10 -0500
Subject: [hibernate-dev] [OGM and others] API, SPI and FPI
In-Reply-To: <CAFm4XO0iZ7WOB6i-Pm17A2nAyM7aSbEa=_-MQcsUJz=o7jpBng@mail.gmail.com>
References: <C7FCF5B3-28FB-41DC-AA15-C0F624370D5D@hibernate.org>
	<CAFdSV9s_J2zArfay-sa3MFO6xBcP75GJkUiitPDFdjXR8S-irA@mail.gmail.com>
	<CAFm4XO0iZ7WOB6i-Pm17A2nAyM7aSbEa=_-MQcsUJz=o7jpBng@mail.gmail.com>
Message-ID: <CAFdSV9vcQiMprZkgRgiOG334Gj+dVhrX1VBboS_0fpYHcJ+KYw@mail.gmail.com>

The split packages were really a vehicle to make auto-generation of osgi
metatdata possible.  It is nice too that they offer a quick visual clue
into the intent.  I agree that an annotation would work as well for some
aspects of this.  But using annotations would make the osgi auto-gen harder
for sure (doable still, just harder).

I agree we are all describing the same thing: integration points between 2
things (sometimes 2 projects, sometimes 2 modules, sometimes just 2 classes
or "services").  Personally I like to call them "touch points" as in the
point were things touch.  I am much less interested in what we call them
versus doing them right :)  We all agreed 2-3 years ago to call them SPI.
 I see no reason to change that simply because there is not a "nice, neat
wikipedia page" to talks about our view of these concepts.



On Thu, May 22, 2014 at 11:03 AM, Sanne Grinovero <sanne at hibernate.org>wrote:

> Looks like we're all aligned?
> Steve made some concrete examples, Emmanuel pointed out how we have
> been defining this vs. apparently other people.
>
> I don't feel the need to change our interpretation, if that's what is
> being discussed.
>
> It's good to remember that there are different kinds of SPIs; we
> indeed came to the conclusion that it's often much nicer to have an
> abstract class when the SPI is meant to be provided by 3rd party code
> but I think we need an interface in that case as well (in addition to
> the abstract class).
>
> Also breaking an SPI could bring as much pain as an API change.. when
> an API changs the user is often in the position to be able to do
> something about it. More often people get in trouble because they are
> using a mixture of versions of different frameworks and libraries
> which are meant to work together, and they don't.. in such scenarios
> the user might not be able to do something about it, other than
> lobbying and begging for fixes and releases in projects out of his
> control.
> An API change just invalidates project for people who are not able to
> recompile, and makes books and training outdated :) Sure that's
> annoying too, my point is just that SPI is not less important
> *generally* but it depends on what API and what SPI we're talking
> about.
>
> But even when we discuss the same "kind" of SPIs, some are more
> critical than others, and some are "internal" SPIs (like
> hibernate-search to hibernate-search module), some are very close
> (hibernate-orm to hibernate-search) some are slightly further down
> (infinispan - hibernate-search).. others need critical stability
> (container integration, etc..). And of course it's less painfull when
> it affects something that 99% of users didn't know it existed in the
> first place.
>
> Conclusion, the package name will never set a rule: to me it's more
> like a reminder to be carefull in any way possible as "someone" is
> going to hate me. I am personally not even a fan of these specific
> package naming conventions, an annotation would be just as good,
> provided it gets somehow visibility in the javadoc (or even hides
> javadocs for internals).
>
>
> Sanne
>
> On 22 May 2014 15:32, Steve Ebersole <steve at hibernate.org> wrote:
> > Deja vu as we have had this exact discussion before (and actually, our
> > discussions pre-date those TAG discussions....)
> >
> > You are basing your specific reading of what SPI means based on a single
> > wikipedia page that goes out of its way to point out its incompleteness
> :)
> >  And really even then in my opinion you are reading too much into its
> > mention of the JDK ServiceLoader.  What the wikiepdia says specifically
> is:
> >
> > *Service Provider Interface* (SPI) is an
> > API<http://en.wikipedia.org/wiki/Application_programming_interface>
> > intended
> >> to be implemented or extended by a third party. It can be used to enable
> >> framework extension and replaceable components
> >
> >
> > That's actually not much different (if at all) from how I use the term
> SPI.
> >  To me, SPI is simply "the API that is used between internal components
> to
> > accomplish something".  A specific important distinction here is that
> APIs
> > are meant for application code to bind to, SPIs are not.  As I have
> pointed
> > out probably 100 times already, yes there are 2 facets to this.  To me an
> > SPI is made up of:
> > 1) The SPI contracts that are meant to be extended by users and/or 3rd
> > parties.
> > 2) The SPI contracts that are not intended for extension.
> >
> > Another correlated break down is:
> > 1) SPI contracts that do things
> > 2) SPI contracts that are inputs/outputs to (1)
> >
> > Take for example, the idea of scanning deployments for annotated classes
> > (mainly because this one is fresh in my mind).  The main SPI contract
> here
> > is Scanner and ArchiveDescriptorFactory.  These are each intended as
> > extension points, they both "do stuff".  All the rest of the "scanning
> spi"
> > is inouts/outputs to these 2.  Why is this an important distinction?
>  Well,
> > generally speaking where we get into trouble in terms of "changing SPIs"
> > later is when we change this first group.  When we have to make
> > changes to Scanner
> > or make changes to ArchiveDescriptorFactory we cause problems downstream
> > for folks that implement/extend this stuff.  That's where patterns like
> > parameter objects and delegates are sooooooooo beneficial.  As an
> > illustration, say we need to pass some new information into the single
> > Scanner method (this was the recent case I worked through).  If that
> means
> > adding a new parameter to that Scanner method, well that just screwed
> every
> > implementor of the Scanner interface because now their implementation is
> no
> > longer valid.  If instead, Scanner had made use of parameter objects (it
> > now does btw), the parameter object itself would have been changed
> causing
> > no problem of existing Scanner implementations.  The "parameter object"
> is
> > still part of the SPI.  But it falls into this second category.  Changing
> > these guys is essentially irrelevant in terms of causing no issues for
> > existing SPI implementations.
> >
> >
> > And as far as "a tendency to consider the application developer more
> sacred
> > than the framework/integrator when it comes to breaking backward
> > compatibility" I would not phrase it like that.  There are  a few parts
> to
> > this in my mind:
> >
> > First,  I think you need to step back and look at the bigger picture.
>  The
> > API defines the features that Hibernate is exposing to the application
> > (save this thing, find that thing).  Its kind of broad and generally
> avoids
> > defining a feature in relation to an interaction between 2 things.  SPIs
> in
> > many ways are inherently more complicated to design because they need to
> > consider both sides of the problem.  Going back to scanning, that SPI
> needs
> > to consider Hibernate's requirements from scanning as well as any
> > requirements the implementation needs especially accounting for any
> quirks
> > in the various potential implementations.
> >
> > Second, because of the "overlap" or "integration" aspects between teams
> and
> > projects there needs to be coordination and cooperation when
> > building/designing an SPI.  To be honest, this part has been lacking even
> > within "our team" across projects because people get focused on their
> work.
> >  What happens instead, again from my perspective, is no
> > coordination/cooperation
> > occurs in the building/designing of these; and then later people get
> upset
> > when the SPI needs to change because it was not well designed to begin
> > with.  Another aspects of this is "more eyes"; the more people involved
> in
> > the design of an API (SPI fits in here equally) looking at it, the better
> > designed it will be.
> >
> >
> > All that said, I don't plan on changing use of the phrase SPI based on (a
> > questionable interpretation of) one wikipedia page.
> >
> >
> > On Thu, May 22, 2014 at 4:21 AM, Emmanuel Bernard <
> emmanuel at hibernate.org>wrote:
> >
> >> (This discussion is around OGM but it is a very generic subject
> applicable
> >> to all projects.)
> >>
> >> I made a mistake in naming the spi packages SPI because the definition
> of
> >> SPI is quite narrow and even more narrower in Java than elsewhere.
> >>
> >> ## Definitions
> >>
> >> ### SPI
> >>
> >> In Java and according to Wikipedia, a SPI (Service provider interface)
> is
> >> related to the notion of ServiceLoader
> >> http://en.wikipedia.org/wiki/Service_Provider_Interface
> >> We certainly do not (or very rarely) have these kinds of services in our
> >> SPI packages.
> >>
> >> Another point of you comes from this StackOverflow article
> >>
> https://stackoverflow.com/questions/2954372/difference-between-spi-and-api
> >>
> >> - the API is the description of classes/interfaces/methods/... that you
> >> call and use to achieve a goal and
> >> - the SPI is the description of classes/interfaces/methods/... that you
> >> extend and implement to achieve a goal
> >>
> >> A third point of you is the NetBeans one
> >> http://wiki.netbeans.org/DevFaqApiSpi
> >>
> >> SPI stands for Service Provider Interface. It is a subset of all things
> >> that can be API specific to situations where a library is providing
> classes
> >> which are called by the application (or API library), and which
> typically
> >> change the things the application is able to do.
> >>
> >> I think everyone agrees that an SPI is kind of API.
> >>
> >> ### IPI or FPI (Integrator / Framework Public Interface)
> >>
> >> I will use FPI as it tastes better than IPI but I have no preferences
> over
> >> integrators vs frameworks.
> >>
> >> Now in my mind and for some obscure reasons, SPI really meant FPI. To my
> >> credit, I have done that fairly constantly on Hibernate Search and Bean
> >> Validation. Hibernate OGM was never properly packaged initially so
> that?s
> >> another story.
> >>
> >> A FPI is used by a framework integrating or extending the project
> exposing
> >> these FPIs.
> >>
> >> ## What does really matter?
> >>
> >> It is useful to differentiate an API used from an API extended (SPI)
> >> because the constraints are different:
> >>
> >> - APIs used can add new methods and should be interfaces rather than
> >> classes.
> >> - APIs extended (SPIs) should be abstract classes so that a new contract
> >> added can be offered by the project without breaking implementors.
> >>
> >> But from a user point of you, I?m tempted to say "so what??. It does not
> >> change your inclination to make use of that contract.
> >>
> >> It is useful to differentiate application developer(*) facing APIs from
> >> framework/integrator facing APIs (FPIs) to keep the API simple to use
> and
> >> to document. There is also a tendency to consider the application
> developer
> >> more sacred than the framework/integrator when it comes to breaking
> >> backward compatibility.
> >>
> >> (*) I say application developer here but it really the primary user
> group
> >> of your project whereas the integrators are usually less numerous and
> more
> >> controllable.
> >>
> >> To me the latter (API/FPI) is more generally useful and that is the one
> I
> >> wish to separate in different packages naming conventions.
> >> The former it seems to me is very often self-obvious to the user and
> >> project maintainers. And from a usage PoV, it does not really matter.
> Plus
> >> there are cases where a contract is both used and extended (JDBC?s
> >> Connection contract for example).
> >>
> >> Can and should we split according to both dimensions? I don?t think so.
> >> And if I have to chose, I?d prefer to split according to the API/ FPI
> >> dimension which is more generally useful to our customers and makes it
> >> clear what is non breakable (API), what is inconvenient to break (FPI),
> >> what is free lunch (implementation).
> >>
> >> ## References
> >>
> >> There has been some discussions in the past as well
> >> https://issues.jboss.org/browse/TAG-47
> >>
> >> 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 gbadner at redhat.com  Fri May 23 18:08:45 2014
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 23 May 2014 18:08:45 -0400 (EDT)
Subject: [hibernate-dev] Changing method signatures in micro releases
In-Reply-To: <746066896.3028150.1400537816147.JavaMail.zimbra@redhat.com>
References: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
	<214051673.2943844.1400528049085.JavaMail.zimbra@redhat.com>
	<746066896.3028150.1400537816147.JavaMail.zimbra@redhat.com>
Message-ID: <1150636940.7074938.1400882925308.JavaMail.zimbra@redhat.com>

My changes for HHH-9204 and HHH-9205 need to be pushed to 4.2, 4.3, and master. This needs to happen by early next week so it can be released in 4.2.13.Final on Wednesday.

I want to make sure that my change fixes the regression introduced into 4.3.5 and 4.2.12, without breaking the fix that Gunnar made for OGM.

Gunnar, can you check my pull request at https://github.com/hibernate/hibernate-orm/pull/747 and make sure it doesn't break something for you?

Thanks!
Gail

----- Original Message -----
> From: "Gail Badner" <gbadner at redhat.com>
> To: "Steve Ebersole" <steve at hibernate.org>
> Cc: hibernate-dev at lists.jboss.org
> Sent: Monday, May 19, 2014 3:16:56 PM
> Subject: Re: [hibernate-dev] Changing method signatures in micro releases
> 
> It was a simple matter to restore the old the method and provide a default
> implementation of the method added by HHH-9078.
> 
> I've create the following issues:
> 
> For master, 4.3, and 4.2 (because HHH-9078 was fixed on master, 4.3, and
> 4.2):
> HHH-9204: Restore
> AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> Serializable, SessionImplementor)
> HHH-9205: Deprecate
> AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> Serializable, int, SessionImplementor)
> 
> For master only:
> HHH-9206: Remove
> AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> Serializable, int, SessionImplementor)
> 
> Steve, I'm not 100% I did the right thing for HHH-9204 and HHH-9205, so
> please take a look at the pull request:
> https://github.com/hibernate/hibernate-orm/pull/747
> 
> Thanks,
> Gail
> 
> ----- Original Message -----
> > From: "Gail Badner" <gbadner at redhat.com>
> > To: "Gunnar Morling" <gunnar at hibernate.org>
> > Cc: hibernate-dev at lists.jboss.org
> > Sent: Monday, May 19, 2014 12:34:09 PM
> > Subject: Re: [hibernate-dev] Changing method signatures in micro releases
> > 
> > Hi Gunnar,
> > 
> > Thanks for mentioning this. I believe that
> > org.hibernate.persister.collection
> > and org.hibernate.persister.entity are considered APIs, which should
> > definitely be backward-compatible for micro releases.
> > 
> > I'm looking at some alternatives to mitigate that. My first thought is that
> > the fix for HHH-9078 should have been made only to OneToManyPersister, so
> > that AbstractCollectionPersister would not be affected. If this is
> > possible,
> > I will add the old method back and deprecate the new one that caused you
> > trouble.
> > 
> > I'll let you know what I find.
> > 
> > Regards,
> > Gail
> > 
> > ----- Original Message -----
> > > From: "Gunnar Morling" <gunnar at hibernate.org>
> > > To: hibernate-dev at lists.jboss.org
> > > Sent: Monday, May 19, 2014 12:28:38 AM
> > > Subject: [hibernate-dev] Changing method signatures in micro releases
> > > 
> > > Hi,
> > > 
> > > When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a changed
> > > method signature in AbstractCollectionPersister (abstract
> > > method doProcessQueuedOps() has a new parameter).
> > > 
> > > This causes a compilation failure in OGM, as we naturally still override
> > > the old signature. I can solve this particular case in a compatible
> > > manner
> > > by declaring both variants of the method in our sub-class (omitting the
> > > @Override annotation), but I'm wondering how we should generally deal
> > > with
> > > this kind of issue.
> > > 
> > > Are micro-releases considered strictly backwards-compatible, so that e.g.
> > > all of ORM 4.3.x should be useable together with an integrator (such as
> > > OGM) known to work with 4.3.0? This would have been my assumption
> > > originally.
> > > 
> > > Are there any rules for what kind of changes are to be expected by an ORM
> > > micro/minor/major update?
> > > 
> > > Thanks,
> > > 
> > > --Gunnar
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > 
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 

From emmanuel at hibernate.org  Mon May 26 03:58:28 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 26 May 2014 09:58:28 +0200
Subject: [hibernate-dev] [Validator] CRLF Git issue
Message-ID: <20140526075828.GA47351@hibernate.org>

I had a strange problem this morning.
It was based on a earlier commit of Hibernate Validator from May 2nd
6bbe986b0ce8e309e23a811db919ce760ae58589

    warning: CRLF will be replaced by LF in
    engine/src/main/java/org/hibernate/validator/internal/constraintvalidators/PatternValidator.java.
    The file will have its original line endings in your working directory.


I had the following warning and whatever I tried (stash, reset --hard
etc) I could not get it fixed. I could have used

    git config core.autocrlf false

But it feels like hiding the problem. I ended up with a clean clone.
Do you guys have any idea of what went wrong? If I checkout the infamous
commit, the error reappears.

Emmanuel

PS: I felt like that
http://toub.es/2012/05/28/fatal-crlf-would-be-replaced-lf
In fact, I even forgot what I was supposed to check in the first place
;)

From gunnar at hibernate.org  Mon May 26 04:07:10 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 26 May 2014 10:07:10 +0200
Subject: [hibernate-dev] Changing method signatures in micro releases
In-Reply-To: <1150636940.7074938.1400882925308.JavaMail.zimbra@redhat.com>
References: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
	<214051673.2943844.1400528049085.JavaMail.zimbra@redhat.com>
	<746066896.3028150.1400537816147.JavaMail.zimbra@redhat.com>
	<1150636940.7074938.1400882925308.JavaMail.zimbra@redhat.com>
Message-ID: <CADGJaX9-19=OHzs1tHWFWcVHgpqDybycwJqcAHqqyKAhPeZ1Qg@mail.gmail.com>

2014-05-24 0:08 GMT+02:00 Gail Badner <gbadner at redhat.com>:

> My changes for HHH-9204 and HHH-9205 need to be pushed to 4.2, 4.3, and
> master. This needs to happen by early next week so it can be released in
> 4.2.13.Final on Wednesday.
>
> I want to make sure that my change fixes the regression introduced into
> 4.3.5 and 4.2.12, without breaking the fix that Gunnar made for OGM.
>
> Gunnar, can you check my pull request at
> https://github.com/hibernate/hibernate-orm/pull/747 and make sure it
> doesn't break something for you?
>

Yes, that works from OGM's perspective.

I'm only wondering about the deprecation; Are you intentionally deprecating
the new variant of the method (with the additional "nextIndex" param)? This
had been established as part of the original bug fix, so I'd have expected
that the old variant of the method (without that parameter) would be
deprecated instead. Or is the original fix not required anymore?

Thanks for your help,

--Gunnar


> Thanks!
> Gail
>
> ----- Original Message -----
> > From: "Gail Badner" <gbadner at redhat.com>
> > To: "Steve Ebersole" <steve at hibernate.org>
> > Cc: hibernate-dev at lists.jboss.org
> > Sent: Monday, May 19, 2014 3:16:56 PM
> > Subject: Re: [hibernate-dev] Changing method signatures in micro releases
> >
> > It was a simple matter to restore the old the method and provide a
> default
> > implementation of the method added by HHH-9078.
> >
> > I've create the following issues:
> >
> > For master, 4.3, and 4.2 (because HHH-9078 was fixed on master, 4.3, and
> > 4.2):
> > HHH-9204: Restore
> > AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> > Serializable, SessionImplementor)
> > HHH-9205: Deprecate
> > AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> > Serializable, int, SessionImplementor)
> >
> > For master only:
> > HHH-9206: Remove
> > AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> > Serializable, int, SessionImplementor)
> >
> > Steve, I'm not 100% I did the right thing for HHH-9204 and HHH-9205, so
> > please take a look at the pull request:
> > https://github.com/hibernate/hibernate-orm/pull/747
> >
> > Thanks,
> > Gail
> >
> > ----- Original Message -----
> > > From: "Gail Badner" <gbadner at redhat.com>
> > > To: "Gunnar Morling" <gunnar at hibernate.org>
> > > Cc: hibernate-dev at lists.jboss.org
> > > Sent: Monday, May 19, 2014 12:34:09 PM
> > > Subject: Re: [hibernate-dev] Changing method signatures in micro
> releases
> > >
> > > Hi Gunnar,
> > >
> > > Thanks for mentioning this. I believe that
> > > org.hibernate.persister.collection
> > > and org.hibernate.persister.entity are considered APIs, which should
> > > definitely be backward-compatible for micro releases.
> > >
> > > I'm looking at some alternatives to mitigate that. My first thought is
> that
> > > the fix for HHH-9078 should have been made only to OneToManyPersister,
> so
> > > that AbstractCollectionPersister would not be affected. If this is
> > > possible,
> > > I will add the old method back and deprecate the new one that caused
> you
> > > trouble.
> > >
> > > I'll let you know what I find.
> > >
> > > Regards,
> > > Gail
> > >
> > > ----- Original Message -----
> > > > From: "Gunnar Morling" <gunnar at hibernate.org>
> > > > To: hibernate-dev at lists.jboss.org
> > > > Sent: Monday, May 19, 2014 12:28:38 AM
> > > > Subject: [hibernate-dev] Changing method signatures in micro releases
> > > >
> > > > Hi,
> > > >
> > > > When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a
> changed
> > > > method signature in AbstractCollectionPersister (abstract
> > > > method doProcessQueuedOps() has a new parameter).
> > > >
> > > > This causes a compilation failure in OGM, as we naturally still
> override
> > > > the old signature. I can solve this particular case in a compatible
> > > > manner
> > > > by declaring both variants of the method in our sub-class (omitting
> the
> > > > @Override annotation), but I'm wondering how we should generally deal
> > > > with
> > > > this kind of issue.
> > > >
> > > > Are micro-releases considered strictly backwards-compatible, so that
> e.g.
> > > > all of ORM 4.3.x should be useable together with an integrator (such
> as
> > > > OGM) known to work with 4.3.0? This would have been my assumption
> > > > originally.
> > > >
> > > > Are there any rules for what kind of changes are to be expected by
> an ORM
> > > > micro/minor/major update?
> > > >
> > > > Thanks,
> > > >
> > > > --Gunnar
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>

From gunnar at hibernate.org  Mon May 26 04:28:12 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 26 May 2014 10:28:12 +0200
Subject: [hibernate-dev] [Validator] CRLF Git issue
In-Reply-To: <20140526075828.GA47351@hibernate.org>
References: <20140526075828.GA47351@hibernate.org>
Message-ID: <CADGJaX_5j4h2xJxR1tGAUjV=zdV+yyvC0q-3a-2cB4-6YFy+4Q@mail.gmail.com>

Hi,

Note that this commit is from May 2nd last year.

Historically there had been some files with Windows style line endings in
the HV repository. It was at this very time that I fixed this; since then
git takes care of this automatically upon check out (by using LF within the
repo and converting this to the right OS-dependent style upon check out).
This is done via a configuration in .gitattributes which causes git to do
the conversion upon check out.

Now I had somewhat unfortunately done this configuration first and only
afterwards fixed the concerned files with the wrong format. If you now
happen to check out one of those few commits between the changed
configuration in .gitattributes (753a0c7d) and the fix for PatternValidator
(62bd06a3), git will change the line ending style and give you the changes
you see in your working copy. To abandon that state, you can e.g. do a "git
checkout --force master".

Out of interest, what exactly did you to run into this issue?

--Gunnar





2014-05-26 9:58 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> I had a strange problem this morning.
> It was based on a earlier commit of Hibernate Validator from May 2nd
> 6bbe986b0ce8e309e23a811db919ce760ae58589
>
>     warning: CRLF will be replaced by LF in
>
> engine/src/main/java/org/hibernate/validator/internal/constraintvalidators/PatternValidator.java.
>     The file will have its original line endings in your working directory.
>
>
> I had the following warning and whatever I tried (stash, reset --hard
> etc) I could not get it fixed. I could have used
>
>     git config core.autocrlf false
>
> But it feels like hiding the problem. I ended up with a clean clone.
> Do you guys have any idea of what went wrong? If I checkout the infamous
> commit, the error reappears.
>
> Emmanuel
>
> PS: I felt like that
> http://toub.es/2012/05/28/fatal-crlf-would-be-replaced-lf
> In fact, I even forgot what I was supposed to check in the first place
> ;)
> _______________________________________________
> 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 26 07:58:13 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Mon, 26 May 2014 13:58:13 +0200
Subject: [hibernate-dev] [Validator] CRLF Git issue
In-Reply-To: <CADGJaX_5j4h2xJxR1tGAUjV=zdV+yyvC0q-3a-2cB4-6YFy+4Q@mail.gmail.com>
References: <20140526075828.GA47351@hibernate.org>
	<CADGJaX_5j4h2xJxR1tGAUjV=zdV+yyvC0q-3a-2cB4-6YFy+4Q@mail.gmail.com>
Message-ID: <E62E4931-2F67-418D-A1A1-7078A5AC61C2@hibernate.org>

So basically I haven?t touched nor looked at Hibernate Validator for a year. Damn.

On 26 May 2014, at 10:28, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hi,
> 
> Note that this commit is from May 2nd last year.
> 
> Historically there had been some files with Windows style line endings in the HV repository. It was at this very time that I fixed this; since then git takes care of this automatically upon check out (by using LF within the repo and converting this to the right OS-dependent style upon check out). This is done via a configuration in .gitattributes which causes git to do the conversion upon check out.
> 
> Now I had somewhat unfortunately done this configuration first and only afterwards fixed the concerned files with the wrong format. If you now happen to check out one of those few commits between the changed configuration in .gitattributes (753a0c7d) and the fix for PatternValidator (62bd06a3), git will change the line ending style and give you the changes you see in your working copy. To abandon that state, you can e.g. do a "git checkout --force master".
> 
> Out of interest, what exactly did you to run into this issue?
> 
> --Gunnar
> 
> 
> 
> 
> 
> 2014-05-26 9:58 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
> I had a strange problem this morning.
> It was based on a earlier commit of Hibernate Validator from May 2nd
> 6bbe986b0ce8e309e23a811db919ce760ae58589
> 
>     warning: CRLF will be replaced by LF in
>     engine/src/main/java/org/hibernate/validator/internal/constraintvalidators/PatternValidator.java.
>     The file will have its original line endings in your working directory.
> 
> 
> I had the following warning and whatever I tried (stash, reset --hard
> etc) I could not get it fixed. I could have used
> 
>     git config core.autocrlf false
> 
> But it feels like hiding the problem. I ended up with a clean clone.
> Do you guys have any idea of what went wrong? If I checkout the infamous
> commit, the error reappears.
> 
> Emmanuel
> 
> PS: I felt like that
> http://toub.es/2012/05/28/fatal-crlf-would-be-replaced-lf
> In fact, I even forgot what I was supposed to check in the first place
> ;)
> _______________________________________________
> 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 26 08:06:40 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 26 May 2014 14:06:40 +0200
Subject: [hibernate-dev] [Validator] CRLF Git issue
In-Reply-To: <E62E4931-2F67-418D-A1A1-7078A5AC61C2@hibernate.org>
References: <20140526075828.GA47351@hibernate.org>
	<CADGJaX_5j4h2xJxR1tGAUjV=zdV+yyvC0q-3a-2cB4-6YFy+4Q@mail.gmail.com>
	<E62E4931-2F67-418D-A1A1-7078A5AC61C2@hibernate.org>
Message-ID: <E222A197-B4A4-48AB-A033-C7A1C7C746E6@hibernate.org>

aha aha aha - need to think about a punishment for that :-)

On 26 Jan 2014, at 13:58, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> So basically I haven?t touched nor looked at Hibernate Validator for a year. Damn.
> 
> On 26 May 2014, at 10:28, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
>> Hi,
>> 
>> Note that this commit is from May 2nd last year.
>> 
>> Historically there had been some files with Windows style line endings in the HV repository. It was at this very time that I fixed this; since then git takes care of this automatically upon check out (by using LF within the repo and converting this to the right OS-dependent style upon check out). This is done via a configuration in .gitattributes which causes git to do the conversion upon check out.
>> 
>> Now I had somewhat unfortunately done this configuration first and only afterwards fixed the concerned files with the wrong format. If you now happen to check out one of those few commits between the changed configuration in .gitattributes (753a0c7d) and the fix for PatternValidator (62bd06a3), git will change the line ending style and give you the changes you see in your working copy. To abandon that state, you can e.g. do a "git checkout --force master".
>> 
>> Out of interest, what exactly did you to run into this issue?
>> 
>> --Gunnar



From gunnar at hibernate.org  Mon May 26 08:27:55 2014
From: gunnar at hibernate.org (Gunnar Morling)
Date: Mon, 26 May 2014 14:27:55 +0200
Subject: [hibernate-dev] [Validator] CRLF Git issue
In-Reply-To: <E62E4931-2F67-418D-A1A1-7078A5AC61C2@hibernate.org>
References: <20140526075828.GA47351@hibernate.org>
	<CADGJaX_5j4h2xJxR1tGAUjV=zdV+yyvC0q-3a-2cB4-6YFy+4Q@mail.gmail.com>
	<E62E4931-2F67-418D-A1A1-7078A5AC61C2@hibernate.org>
Message-ID: <CADGJaX-+iZ2TVG7Di_pwU1W7wkhHHbRJ6tLe6B0uFr8CabNUDg@mail.gmail.com>

Hehe; see it positive, at least you didn't ask why "svn update" doesn't
give you any changes ;-)


2014-05-26 13:58 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:

> So basically I haven?t touched nor looked at Hibernate Validator for a
> year. Damn.
>
> On 26 May 2014, at 10:28, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> Hi,
>
> Note that this commit is from May 2nd last year.
>
> Historically there had been some files with Windows style line endings in
> the HV repository. It was at this very time that I fixed this; since then
> git takes care of this automatically upon check out (by using LF within the
> repo and converting this to the right OS-dependent style upon check out).
> This is done via a configuration in .gitattributes which causes git to do
> the conversion upon check out.
>
> Now I had somewhat unfortunately done this configuration first and only
> afterwards fixed the concerned files with the wrong format. If you now
> happen to check out one of those few commits between the changed
> configuration in .gitattributes (753a0c7d) and the fix for PatternValidator
> (62bd06a3), git will change the line ending style and give you the changes
> you see in your working copy. To abandon that state, you can e.g. do a "git
> checkout --force master".
>
> Out of interest, what exactly did you to run into this issue?
>
> --Gunnar
>
>
>
>
>
> 2014-05-26 9:58 GMT+02:00 Emmanuel Bernard <emmanuel at hibernate.org>:
>
>> I had a strange problem this morning.
>> It was based on a earlier commit of Hibernate Validator from May 2nd
>> 6bbe986b0ce8e309e23a811db919ce760ae58589
>>
>>     warning: CRLF will be replaced by LF in
>>
>> engine/src/main/java/org/hibernate/validator/internal/constraintvalidators/PatternValidator.java.
>>     The file will have its original line endings in your working
>> directory.
>>
>>
>> I had the following warning and whatever I tried (stash, reset --hard
>> etc) I could not get it fixed. I could have used
>>
>>     git config core.autocrlf false
>>
>> But it feels like hiding the problem. I ended up with a clean clone.
>> Do you guys have any idea of what went wrong? If I checkout the infamous
>> commit, the error reappears.
>>
>> Emmanuel
>>
>> PS: I felt like that
>> http://toub.es/2012/05/28/fatal-crlf-would-be-replaced-lf
>> In fact, I even forgot what I was supposed to check in the first place
>> ;)
>> _______________________________________________
>> 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 26 08:34:53 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Mon, 26 May 2014 14:34:53 +0200
Subject: [hibernate-dev] [Validator] CRLF Git issue
In-Reply-To: <CADGJaX-+iZ2TVG7Di_pwU1W7wkhHHbRJ6tLe6B0uFr8CabNUDg@mail.gmail.com>
References: <20140526075828.GA47351@hibernate.org>
	<CADGJaX_5j4h2xJxR1tGAUjV=zdV+yyvC0q-3a-2cB4-6YFy+4Q@mail.gmail.com>
	<E62E4931-2F67-418D-A1A1-7078A5AC61C2@hibernate.org>
	<CADGJaX-+iZ2TVG7Di_pwU1W7wkhHHbRJ6tLe6B0uFr8CabNUDg@mail.gmail.com>
Message-ID: <A44E3916-1031-477F-AF0E-2F22068B221D@hibernate.org>


On 26 Jan 2014, at 14:27, Gunnar Morling <gunnar at hibernate.org> wrote:

> Hehe; see it positive, at least you didn't ask why "svn update" doesn't
> give you any changes ;-)

LOL

From emmanuel at hibernate.org  Tue May 27 06:01:12 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 27 May 2014 12:01:12 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <34E35E81-3F6F-43C2-81E8-5FEFBF4E8658@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
	<8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
	<FD83D72C-A5A5-43F0-A86C-61FE822E1528@hibernate.org>
	<34E35E81-3F6F-43C2-81E8-5FEFBF4E8658@hibernate.org>
Message-ID: <5ACB6923-879C-4C49-964F-5B757030D285@hibernate.org>


On 06 May 2014, at 21:43, Hardy Ferentschik <hardy at hibernate.org> wrote:

> Where are we at in this discussion?
> 
> I think we basically have to main proposals.
> 
> #1 Don?t include the embedded id per default. If @IndexEmbedded is used via the depth parameter there is no way to include the embedded id.
>     In order to include the id you would need to use includePaths. depth and includePaths can be used in combination, so something like this 
>     is possible @IndexedEmbedded( depth = 1, includePaths = ?foo.id? ). This will include all configured fields of the embedded entity, plus its id.
> #2 Don?t include the embedded id per default, but have an additional flag on @IndexedEmbedded to include the embedded id. The default would be false.
>    To include the id would be something like @IndexedEmbedded( depth = 1, includeEmbeddedId = true ) or 
>    @IndexedEmbedded(  includePaths = {?foo.a?, ?foo.b?, ?foo.c?} , includeEmbeddedId = true ).

I like #2 much better. It is too complex to ask of the user to understand how the combination of depth and includePaths work based on fairly arbitrary rules.
I thing the property should be named includeEmbeddedObjectsIds because embeddedId has a precise meaning in ORM.

One question in that case, what does this one do

    @IndexedEmbedded( includePath = { ?foo.id? }, includeEmbeddedId=false //default )

I think we should honour includePath according to the additive rule mentioned earlier and the path of least surprise.

> 
> I think I favour #2 atm, since it seems more symmetric. 
> 
> On top of this we seem to agree that it is a good idea to set the default depth value of @IndexedEmbedded to 0. This avoids the change in default values,
> when includePaths is used. As a side effect the default @IndexedEmbedded annotation becomes a no-op and should be treated as an invalid configuration.
> The choice here is between:
> 
> #1 Log warning and move on
> #2 Throw an exception due to invalid configuration
> 
> My choice would be #2 again.

Is that really a good idea? As you guys said, @IndexedEmbedded becomes a (silently or not) broken mapping :(
It also means that the simplest @IE usage requires to understand depth and / or includePath.
I don?t like that at all. It makes things more complex than they should be for the simple case.

Emmanuel

From emmanuel at hibernate.org  Tue May 27 06:19:47 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 27 May 2014 12:19:47 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
	<8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
Message-ID: <AB8834A4-172D-4D48-BB83-2B58B6AEFD2C@hibernate.org>


On 29 Apr 2014, at 20:43, Hardy Ferentschik <hardy at hibernate.org> wrote:

> On 29 Jan 2014, at 15:24, Sanne Grinovero <sanne at hibernate.org> wrote:
> 
>>>> But this forces you to list all fields to include explicitly in case you want the id added, but otherwise are happy
>>>> to just use the default @IndexedEmbedded.
>>> 
>>> I think we should keep the id with the default @IndexedEmbedded. It
>>> was weird to include the id when the includePath didn't ask for it but
>>> it would be weird to not include the id with the default
>>> @IndexedEmbedded.
>> 
>> It's not an indexed field, I don't think it was ever meant to be in
>> the index but rather a side effect of our recursion.. as we obviously
>> need the id of the root element.
> 
> Nope, the code is quite explicit. It contains a if/else statement checking whether 
> we are processing the root entity and in the else part the comment says:
> ?// component should index their document id?
> 
> This is also not just an outcome of the metadata refactoring, since this if statement 
> and comment also has been there in the DocumentBuilder code [1] 
> 
> So it has been an explicit choice at some point of time.

Correct.

From hardy at hibernate.org  Tue May 27 06:29:49 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 27 May 2014 12:29:49 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <5ACB6923-879C-4C49-964F-5B757030D285@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
	<8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
	<FD83D72C-A5A5-43F0-A86C-61FE822E1528@hibernate.org>
	<34E35E81-3F6F-43C2-81E8-5FEFBF4E8658@hibernate.org>
	<5ACB6923-879C-4C49-964F-5B757030D285@hibernate.org>
Message-ID: <327F4FDE-5FA4-4FB0-A551-AF872275F8B2@hibernate.org>

Thanks for the input. Comments inline.

On 27 Jan 2014, at 12:01, Emmanuel Bernard <emmanuel at hibernate.org> wrote:

> 
> On 06 May 2014, at 21:43, Hardy Ferentschik <hardy at hibernate.org> wrote:
> 
>> Where are we at in this discussion?
>> 
>> I think we basically have to main proposals.
>> 
>> #1 Don?t include the embedded id per default. If @IndexEmbedded is used via the depth parameter there is no way to include the embedded id.
>>    In order to include the id you would need to use includePaths. depth and includePaths can be used in combination, so something like this 
>>    is possible @IndexedEmbedded( depth = 1, includePaths = ?foo.id? ). This will include all configured fields of the embedded entity, plus its id.
>> #2 Don?t include the embedded id per default, but have an additional flag on @IndexedEmbedded to include the embedded id. The default would be false.
>>   To include the id would be something like @IndexedEmbedded( depth = 1, includeEmbeddedId = true ) or 
>>   @IndexedEmbedded(  includePaths = {?foo.a?, ?foo.b?, ?foo.c?} , includeEmbeddedId = true ).
> 
> I like #2 much better. It is too complex to ask of the user to understand how the combination of depth and includePaths work based on fairly arbitrary rules.
> I thing the property should be named includeEmbeddedObjectsIds because embeddedId has a precise meaning in ORM.

Cool. Seems we have now several votes for this approach. I will start implementing it then. 
+1 also for ?includeEmbeddedObjectsIds'

> One question in that case, what does this one do
> 
>    @IndexedEmbedded( includePath = { ?foo.id? }, includeEmbeddedId=false //default )
> 
> I think we should honour includePath according to the additive rule mentioned earlier and the path of least surprise.

Sounds reasonable.

>> On top of this we seem to agree that it is a good idea to set the default depth value of @IndexedEmbedded to 0. This avoids the change in default values,
>> when includePaths is used. As a side effect the default @IndexedEmbedded annotation becomes a no-op and should be treated as an invalid configuration.
>> The choice here is between:
>> 
>> #1 Log warning and move on
>> #2 Throw an exception due to invalid configuration
>> 
>> My choice would be #2 again.
> 
> Is that really a good idea? As you guys said, @IndexedEmbedded becomes a (silently or not) broken mapping :(
> It also means that the simplest @IE usage requires to understand depth and / or includePath.
> I don?t like that at all. It makes things more complex than they should be for the simple case.

So what is your take on this then? Leave as is and keep the fact that the default depth value changes its default value depending 
on whether or not includePaths is used? That would be option

#3 Keep status quo for value of depth parameter

I raised the concern that the simple @IndexEmbedded is now not valid anymore as well before. I guess the question is what you give more importance,
ability to use the annotation with its default values or have consistent default values which don?t change. 

I still think consistency is more important and #2 is the better approach. However, before going to #1, I would rather join you and keep the status quo
with #3.

Btw, enforcing a depth or includePath value might have the advantage of creating smaller (more targeted) indexes, since we less likely include 
fields which are need targeted by a query.

?Hardy



From smarlow at redhat.com  Tue May 27 09:35:20 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 27 May 2014 09:35:20 -0400
Subject: [hibernate-dev] EntityManagerFactoryBuilderImpl constructor is
 accessing the CDI BeanManager too early (during 1st phase) ...
In-Reply-To: <537F4CBE.2060307@redhat.com>
References: <537D002D.4020805@redhat.com> <537F4CBE.2060307@redhat.com>
Message-ID: <53849498.2010709@redhat.com>

On 05/23/2014 09:27 AM, Scott Marlow wrote:
> On 05/21/2014 03:36 PM, Scott Marlow wrote:
>> I started to push on Hibernate master integration for WildFly [1] +
>> Jipijapa [2].
>>
>> http://pastie.org/9196859 is a NPE that occurs when the CDI BeanManager
>> is accessed during the first (EntityManagerFactoryBuilder) phase.
>> Hibernate ORM shouldn't use the BeanManager until the second phase.
>
> I'll create a HHH jira for the BeanManager access issue.

HHH-9221

>
> I'm also hitting some issues in existing unit tests (WildFly + Jipijapa)
> that I worked around by commenting them out.  We can discuss on IRC
> sometime or I could give more details here.
>
> After we get past these issues, I'll make the change to pass the Jandex
> CompositeIndex into Hibernate 5.x, so we can see how that works.
>
>>
>> Scott
>>
>> [1] https://github.com/scottmarlow/wildfly/tree/hibernate5
>>
>> [2] https://github.com/scottmarlow/jipijapa/tree/JIPI-31
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From emmanuel at hibernate.org  Tue May 27 07:53:44 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 27 May 2014 13:53:44 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <CAFm4XO0cs3fxEHPGJ2eGHtC_D8OOQPf-EgyG8CJzgpFX5HebGQ@mail.gmail.com>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CAFm4XO0cs3fxEHPGJ2eGHtC_D8OOQPf-EgyG8CJzgpFX5HebGQ@mail.gmail.com>
Message-ID: <82F1B424-98D8-47FD-924C-2854C2AB7272@hibernate.org>


On 29 Apr 2014, at 15:09, Sanne Grinovero <sanne at hibernate.org> wrote:

> I'd actually like to propose to change the depth default to zero, and
> since includePath also defaults to an empty list, we'd be logging a
> warning as the @IndexedEmbedded annotation would have no effect.
> 
> 
>> I also find it not intuitive that this means:
>> "index all embedded fields up to the given depth, plus the specified paths?.
>> I never liked how we baked depth and includePath into the same annotation. A dedicated annotation would
>> have been more appropriate.
> 
> We've been there and couldn't agree on a better proposal. Feel free to
> reopen the case on a new thread, if you have a nice name in mind. But
> ultimately remember the goal is to allow queries on a well-known list
> of field names, and it would be great to validate for these queries,
> so to have a clear definitions of which indexing and analysis options
> are applied to each Lucene field, and how to apply a bi-directional
> projection.. so I'm still skeptical on leaving too much freedoom, or
> have multiple ways to achieve the same thing.

Right, splitting the annotation in two does not address the mix of both concepts.

From emmanuel at hibernate.org  Tue May 27 11:18:31 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 27 May 2014 17:18:31 +0200
Subject: [hibernate-dev] NoORM meeting
Message-ID: <A4ABBE47-AA74-4C56-8CEE-60D541462040@hibernate.org>

We discussed:

- Hibernate Search 5  / Infinispan 7 implications for OGM release wise
- The necessary changes from Infinispan to do remote Infinispan support in OGM
- the OGM roadmap
- Neo4J remaining tasks
- PoC for free f-rm entities in Hibernate Search

Actions:

- gmorling or DavideD to test an experimental branch using Hsearch 5 and Infinispan 7. Leaving out of master for now (emmanuel, 14:19:41)
- DavideD to remind and push for the necessary chnges required by OGM in Infinispan 7 (ML) (emmanuel, 14:23:45)
- emmanuel to provide feedback ont he OGM roadmap with date (emmanuel, 14:31:22)
- sanne to try and find time for the free-form PoC to unlock participation

Meeting ended Tue May 27 14:47:34 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
Minutes:        http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-27-13.49.html
Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-27-13.49.txt
Log:            http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-05-27-13.49.log.html

From emmanuel at hibernate.org  Tue May 27 11:29:35 2014
From: emmanuel at hibernate.org (Emmanuel Bernard)
Date: Tue, 27 May 2014 17:29:35 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <327F4FDE-5FA4-4FB0-A551-AF872275F8B2@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
	<8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
	<FD83D72C-A5A5-43F0-A86C-61FE822E1528@hibernate.org>
	<34E35E81-3F6F-43C2-81E8-5FEFBF4E8658@hibernate.org>
	<5ACB6923-879C-4C49-964F-5B757030D285@hibernate.org>
	<327F4FDE-5FA4-4FB0-A551-AF872275F8B2@hibernate.org>
Message-ID: <6A4C19DB-2065-406F-9C0C-F5E3048A7BF4@hibernate.org>


On 27 May 2014, at 12:29, Hardy Ferentschik <hardy at hibernate.org> wrote:

> Thanks for the input. Comments inline.
> 
> On 27 Jan 2014, at 12:01, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> 
>> 
>> On 06 May 2014, at 21:43, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> 
>>> Where are we at in this discussion?
>>> 
>>> I think we basically have to main proposals.
>>> 
>>> #1 Don?t include the embedded id per default. If @IndexEmbedded is used via the depth parameter there is no way to include the embedded id.
>>>   In order to include the id you would need to use includePaths. depth and includePaths can be used in combination, so something like this 
>>>   is possible @IndexedEmbedded( depth = 1, includePaths = ?foo.id? ). This will include all configured fields of the embedded entity, plus its id.
>>> #2 Don?t include the embedded id per default, but have an additional flag on @IndexedEmbedded to include the embedded id. The default would be false.
>>>  To include the id would be something like @IndexedEmbedded( depth = 1, includeEmbeddedId = true ) or 
>>>  @IndexedEmbedded(  includePaths = {?foo.a?, ?foo.b?, ?foo.c?} , includeEmbeddedId = true ).
>> 
>> I like #2 much better. It is too complex to ask of the user to understand how the combination of depth and includePaths work based on fairly arbitrary rules.
>> I thing the property should be named includeEmbeddedObjectsIds because embeddedId has a precise meaning in ORM.
> 
> Cool. Seems we have now several votes for this approach. I will start implementing it then. 
> +1 also for ?includeEmbeddedObjectsIds'
> 
>> One question in that case, what does this one do
>> 
>>   @IndexedEmbedded( includePath = { ?foo.id? }, includeEmbeddedId=false //default )
>> 
>> I think we should honour includePath according to the additive rule mentioned earlier and the path of least surprise.
> 
> Sounds reasonable.
> 
>>> On top of this we seem to agree that it is a good idea to set the default depth value of @IndexedEmbedded to 0. This avoids the change in default values,
>>> when includePaths is used. As a side effect the default @IndexedEmbedded annotation becomes a no-op and should be treated as an invalid configuration.
>>> The choice here is between:
>>> 
>>> #1 Log warning and move on
>>> #2 Throw an exception due to invalid configuration
>>> 
>>> My choice would be #2 again.
>> 
>> Is that really a good idea? As you guys said, @IndexedEmbedded becomes a (silently or not) broken mapping :(
>> It also means that the simplest @IE usage requires to understand depth and / or includePath.
>> I don?t like that at all. It makes things more complex than they should be for the simple case.
> 
> So what is your take on this then? Leave as is and keep the fact that the default depth value changes its default value depending 
> on whether or not includePaths is used? That would be option
> 
> #3 Keep status quo for value of depth parameter
> 
> I raised the concern that the simple @IndexEmbedded is now not valid anymore as well before. I guess the question is what you give more importance,
> ability to use the annotation with its default values or have consistent default values which don?t change. 
> 
> I still think consistency is more important and #2 is the better approach. However, before going to #1, I would rather join you and keep the status quo
> with #3.
> 
> Btw, enforcing a depth or includePath value might have the advantage of creating smaller (more targeted) indexes, since we less likely include 
> fields which are need targeted by a query.

#3 then #2 for me. I really like #3 better though for the reason I explained.
We should bet at horse races together ;)

From smarlow at redhat.com  Tue May 27 13:56:57 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Tue, 27 May 2014 13:56:57 -0400
Subject: [hibernate-dev] Pushed 3.18.2-GA release of Javassist...
Message-ID: <5384D1E9.6010501@redhat.com>

FYI, Javassist version 3.18.2-GA is now available. 
http://issues.jboss.org/browse/JASSIST/fixforversion/12323811 lists the 
four issues resolved.

Should we upgrade Hibernate ORM master to use Javassist 3.18.2-GA?

Scott

From gbadner at redhat.com  Tue May 27 14:04:15 2014
From: gbadner at redhat.com (Gail Badner)
Date: Tue, 27 May 2014 14:04:15 -0400 (EDT)
Subject: [hibernate-dev] Changing method signatures in micro releases
In-Reply-To: <CADGJaX9-19=OHzs1tHWFWcVHgpqDybycwJqcAHqqyKAhPeZ1Qg@mail.gmail.com>
References: <CADGJaX8daGW2aCZ8xaB05dJ-knjSdtUAaAhCT3=gmo9MqmKeyA@mail.gmail.com>
	<214051673.2943844.1400528049085.JavaMail.zimbra@redhat.com>
	<746066896.3028150.1400537816147.JavaMail.zimbra@redhat.com>
	<1150636940.7074938.1400882925308.JavaMail.zimbra@redhat.com>
	<CADGJaX9-19=OHzs1tHWFWcVHgpqDybycwJqcAHqqyKAhPeZ1Qg@mail.gmail.com>
Message-ID: <2030937114.9739209.1401213855281.JavaMail.zimbra@redhat.com>

The original bug could have been fixed without changing the SPI, since it only affected OneToManyPersister. Since there was no reason to change the SPI in the first place, I opted to deprecate the new method and keep the old.

Thanks for checking it!
Gail

----- Original Message -----
> From: "Gunnar Morling" <gunnar at hibernate.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: "Gunnar Morling" <gunnar at hibernate.org>, hibernate-dev at lists.jboss.org, "Steve Ebersole" <steve at hibernate.org>
> Sent: Monday, May 26, 2014 1:07:10 AM
> Subject: Re: [hibernate-dev] Changing method signatures in micro releases
> 
> 2014-05-24 0:08 GMT+02:00 Gail Badner <gbadner at redhat.com>:
> 
> > My changes for HHH-9204 and HHH-9205 need to be pushed to 4.2, 4.3, and
> > master. This needs to happen by early next week so it can be released in
> > 4.2.13.Final on Wednesday.
> >
> > I want to make sure that my change fixes the regression introduced into
> > 4.3.5 and 4.2.12, without breaking the fix that Gunnar made for OGM.
> >
> > Gunnar, can you check my pull request at
> > https://github.com/hibernate/hibernate-orm/pull/747 and make sure it
> > doesn't break something for you?
> >
> 
> Yes, that works from OGM's perspective.
> 
> I'm only wondering about the deprecation; Are you intentionally deprecating
> the new variant of the method (with the additional "nextIndex" param)? This
> had been established as part of the original bug fix, so I'd have expected
> that the old variant of the method (without that parameter) would be
> deprecated instead. Or is the original fix not required anymore?
> 
> Thanks for your help,
> 
> --Gunnar
> 
> 
> > Thanks!
> > Gail
> >
> > ----- Original Message -----
> > > From: "Gail Badner" <gbadner at redhat.com>
> > > To: "Steve Ebersole" <steve at hibernate.org>
> > > Cc: hibernate-dev at lists.jboss.org
> > > Sent: Monday, May 19, 2014 3:16:56 PM
> > > Subject: Re: [hibernate-dev] Changing method signatures in micro releases
> > >
> > > It was a simple matter to restore the old the method and provide a
> > default
> > > implementation of the method added by HHH-9078.
> > >
> > > I've create the following issues:
> > >
> > > For master, 4.3, and 4.2 (because HHH-9078 was fixed on master, 4.3, and
> > > 4.2):
> > > HHH-9204: Restore
> > > AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> > > Serializable, SessionImplementor)
> > > HHH-9205: Deprecate
> > > AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> > > Serializable, int, SessionImplementor)
> > >
> > > For master only:
> > > HHH-9206: Remove
> > > AbstractCollectionPersister.doProcessQueuedOps(PersistentCollection,
> > > Serializable, int, SessionImplementor)
> > >
> > > Steve, I'm not 100% I did the right thing for HHH-9204 and HHH-9205, so
> > > please take a look at the pull request:
> > > https://github.com/hibernate/hibernate-orm/pull/747
> > >
> > > Thanks,
> > > Gail
> > >
> > > ----- Original Message -----
> > > > From: "Gail Badner" <gbadner at redhat.com>
> > > > To: "Gunnar Morling" <gunnar at hibernate.org>
> > > > Cc: hibernate-dev at lists.jboss.org
> > > > Sent: Monday, May 19, 2014 12:34:09 PM
> > > > Subject: Re: [hibernate-dev] Changing method signatures in micro
> > releases
> > > >
> > > > Hi Gunnar,
> > > >
> > > > Thanks for mentioning this. I believe that
> > > > org.hibernate.persister.collection
> > > > and org.hibernate.persister.entity are considered APIs, which should
> > > > definitely be backward-compatible for micro releases.
> > > >
> > > > I'm looking at some alternatives to mitigate that. My first thought is
> > that
> > > > the fix for HHH-9078 should have been made only to OneToManyPersister,
> > so
> > > > that AbstractCollectionPersister would not be affected. If this is
> > > > possible,
> > > > I will add the old method back and deprecate the new one that caused
> > you
> > > > trouble.
> > > >
> > > > I'll let you know what I find.
> > > >
> > > > Regards,
> > > > Gail
> > > >
> > > > ----- Original Message -----
> > > > > From: "Gunnar Morling" <gunnar at hibernate.org>
> > > > > To: hibernate-dev at lists.jboss.org
> > > > > Sent: Monday, May 19, 2014 12:28:38 AM
> > > > > Subject: [hibernate-dev] Changing method signatures in micro releases
> > > > >
> > > > > Hi,
> > > > >
> > > > > When updating Hibernate OGM to make use of ORM 4.3.5, I noticed a
> > changed
> > > > > method signature in AbstractCollectionPersister (abstract
> > > > > method doProcessQueuedOps() has a new parameter).
> > > > >
> > > > > This causes a compilation failure in OGM, as we naturally still
> > override
> > > > > the old signature. I can solve this particular case in a compatible
> > > > > manner
> > > > > by declaring both variants of the method in our sub-class (omitting
> > the
> > > > > @Override annotation), but I'm wondering how we should generally deal
> > > > > with
> > > > > this kind of issue.
> > > > >
> > > > > Are micro-releases considered strictly backwards-compatible, so that
> > e.g.
> > > > > all of ORM 4.3.x should be useable together with an integrator (such
> > as
> > > > > OGM) known to work with 4.3.0? This would have been my assumption
> > > > > originally.
> > > > >
> > > > > Are there any rules for what kind of changes are to be expected by
> > an ORM
> > > > > micro/minor/major update?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > --Gunnar
> > > > > _______________________________________________
> > > > > hibernate-dev mailing list
> > > > > hibernate-dev at lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > > >
> > > > _______________________________________________
> > > > hibernate-dev mailing list
> > > > hibernate-dev at lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> >
> 

From steve at hibernate.org  Tue May 27 14:58:54 2014
From: steve at hibernate.org (Steve Ebersole)
Date: Tue, 27 May 2014 13:58:54 -0500
Subject: [hibernate-dev] Pushed 3.18.2-GA release of Javassist...
In-Reply-To: <5384D1E9.6010501@redhat.com>
References: <5384D1E9.6010501@redhat.com>
Message-ID: <CAFdSV9s7d8N6QFOfAiNL9_unmgL-vxPMeSMd+ZPG7U7cuVCz5Q@mail.gmail.com>

I am a little leery considering the issues this seems to cause every time...


On Tue, May 27, 2014 at 12:56 PM, Scott Marlow <smarlow at redhat.com> wrote:

> FYI, Javassist version 3.18.2-GA is now available.
> http://issues.jboss.org/browse/JASSIST/fixforversion/12323811 lists the
> four issues resolved.
>
> Should we upgrade Hibernate ORM master to use Javassist 3.18.2-GA?
>
> Scott
> _______________________________________________
> 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 27 15:55:17 2014
From: hardy at hibernate.org (Hardy Ferentschik)
Date: Tue, 27 May 2014 21:55:17 +0200
Subject: [hibernate-dev] [Search] Index embedded and id property of
	embedded entity
In-Reply-To: <6A4C19DB-2065-406F-9C0C-F5E3048A7BF4@hibernate.org>
References: <2B79F125-4684-4B75-B617-B6F8CD71EFEF@hibernate.org>
	<CAFm4XO35e_7P5xGxZPdMoL8xc19Fk4_oZUxy7a3y81zHiiVkkA@mail.gmail.com>
	<F95E990E-1850-4EA8-BDF9-23CC2052132C@hibernate.org>
	<CAFm4XO0RGyEoCyO9u1G6xcjq8iu0JaFrA6c9apZ6RTyeXLGP+w@mail.gmail.com>
	<05348290-FF9F-49E8-8790-816F5A6001B8@hibernate.org>
	<CALt0+o8=z2DHCqJo2UjA3MisENMU7JmUP=AA7aEjdXMa=vsaTA@mail.gmail.com>
	<CAFm4XO3xOnn0tBjMKbLaDMjDvpugaMFf+8gch4JJHzvy8pBk=A@mail.gmail.com>
	<8FA0E7E2-4ABC-4E56-A225-11DB7BA1B99F@hibernate.org>
	<FD83D72C-A5A5-43F0-A86C-61FE822E1528@hibernate.org>
	<34E35E81-3F6F-43C2-81E8-5FEFBF4E8658@hibernate.org>
	<5ACB6923-879C-4C49-964F-5B757030D285@hibernate.org>
	<327F4FDE-5FA4-4FB0-A551-AF872275F8B2@hibernate.org>
	<6A4C19DB-2065-406F-9C0C-F5E3048A7BF4@hibernate.org>
Message-ID: <F311953C-CDAD-49FB-9045-567662BC86F8@hibernate.org>


>> So what is your take on this then? Leave as is and keep the fact that the default depth value changes its default value depending 
>> on whether or not includePaths is used? That would be option
>> 
>> #3 Keep status quo for value of depth parameter
>> 
>> I raised the concern that the simple @IndexEmbedded is now not valid anymore as well before. I guess the question is what you give more importance,
>> ability to use the annotation with its default values or have consistent default values which don?t change. 
>> 
>> I still think consistency is more important and #2 is the better approach. However, before going to #1, I would rather join you and keep the status quo
>> with #3.
>> 
>> Btw, enforcing a depth or includePath value might have the advantage of creating smaller (more targeted) indexes, since we less likely include 
>> fields which are need targeted by a query.
> 
> #3 then #2 for me. I really like #3 better though for the reason I explained.
> We should bet at horse races together ;)

Tough negotiations. @Sanne, you brought this depth default of 0 up. WDYT?

?Hardy



From smarlow at redhat.com  Wed May 28 08:44:52 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Wed, 28 May 2014 08:44:52 -0400
Subject: [hibernate-dev] Pushed 3.18.2-GA release of Javassist...
In-Reply-To: <CAFdSV9s7d8N6QFOfAiNL9_unmgL-vxPMeSMd+ZPG7U7cuVCz5Q@mail.gmail.com>
References: <5384D1E9.6010501@redhat.com>
	<CAFdSV9s7d8N6QFOfAiNL9_unmgL-vxPMeSMd+ZPG7U7cuVCz5Q@mail.gmail.com>
Message-ID: <5385DA44.5070409@redhat.com>

The last upgrade (HHH-8463 3.18.1-GA) seemed to work fine.  I'll take a 
closer look at the changes to see if I overlooked any potential issues.

On 05/27/2014 02:58 PM, Steve Ebersole wrote:
> I am a little leery considering the issues this seems to cause every time...
>
>
> On Tue, May 27, 2014 at 12:56 PM, Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
>     FYI, Javassist version 3.18.2-GA is now available.
>     http://issues.jboss.org/browse/JASSIST/fixforversion/12323811 lists the
>     four issues resolved.
>
>     Should we upgrade Hibernate ORM master to use Javassist 3.18.2-GA?
>
>     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
>
>


From smarlow at redhat.com  Thu May 29 11:35:15 2014
From: smarlow at redhat.com (Scott Marlow)
Date: Thu, 29 May 2014 11:35:15 -0400
Subject: [hibernate-dev] Pushed 3.18.2-GA release of Javassist...
In-Reply-To: <5385DA44.5070409@redhat.com>
References: <5384D1E9.6010501@redhat.com>	<CAFdSV9s7d8N6QFOfAiNL9_unmgL-vxPMeSMd+ZPG7U7cuVCz5Q@mail.gmail.com>
	<5385DA44.5070409@redhat.com>
Message-ID: <538753B3.4010200@redhat.com>

I don't see anything naughty on the 3.18 branch 
https://github.com/jboss-javassist/javassist/tree/3.18

On 05/28/2014 08:44 AM, Scott Marlow wrote:
> The last upgrade (HHH-8463 3.18.1-GA) seemed to work fine.  I'll take a
> closer look at the changes to see if I overlooked any potential issues.
>
> On 05/27/2014 02:58 PM, Steve Ebersole wrote:
>> I am a little leery considering the issues this seems to cause every time...
>>
>>
>> On Tue, May 27, 2014 at 12:56 PM, Scott Marlow <smarlow at redhat.com
>> <mailto:smarlow at redhat.com>> wrote:
>>
>>      FYI, Javassist version 3.18.2-GA is now available.
>>      http://issues.jboss.org/browse/JASSIST/fixforversion/12323811 lists the
>>      four issues resolved.
>>
>>      Should we upgrade Hibernate ORM master to use Javassist 3.18.2-GA?
>>
>>      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
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


From gbadner at redhat.com  Thu May 29 16:52:24 2014
From: gbadner at redhat.com (Gail Badner)
Date: Thu, 29 May 2014 16:52:24 -0400 (EDT)
Subject: [hibernate-dev] Hibernate ORM 4.2.13.Final Released
Message-ID: <1550219395.11889429.1401396744585.JavaMail.zimbra@redhat.com>

Due to several regressions and improvements we decided to release 4.2.13.Final.  For more info, please see: http://in.relation.to/Bloggers/HibernateORM4213FinalReleased .

Gail Badner
Red Hat, Hibernate ORM

From gbadner at redhat.com  Fri May 30 02:39:38 2014
From: gbadner at redhat.com (Gail Badner)
Date: Fri, 30 May 2014 02:39:38 -0400 (EDT)
Subject: [hibernate-dev] Envers: Mapped-superclasses extended by
	embeddabables
In-Reply-To: <F97E3572-6CE1-4D5A-950D-C53E31717C6E@warski.org>
References: <859782354.1784121.1400282410002.JavaMail.zimbra@redhat.com>
	<F97E3572-6CE1-4D5A-950D-C53E31717C6E@warski.org>
Message-ID: <2045110796.12701323.1401431978841.JavaMail.zimbra@redhat.com>

Hi Adam,

Currently, the ways to enable auditing on a mapped-superclass that  we discussed below do not work when an embeddable class has no declared data. The only way I can find to enable auditing for the mapped-superclass is to annotate the embeddable class with @Audited.

For example:

@Entity
@Audited
public class A{
  ...
  private B b;
  ...
}
 
@Embeddable
@Audited // currently, this must be here in order for the mapped-superclass to be audited 
public class B extends AbstractB {
  // no declared data
}

@MappedSuperclass
@Audited // does nothing due to HHH-9193, but will be required after 
         // HHH-9193 is fixed, unless there is an @AuditOverride
public class AbstractB {
  private String strValue;
}

Annotating the embeddable class makes it work, but does this really make sense? Is this a reasonable workaround? Could this cause problems in future versions?

The test case attached to HHH-8908 illustrates this.

Thanks,
Gail

----- Original Message -----
> From: "Adam Warski" <adam at warski.org>
> To: "Gail Badner" <gbadner at redhat.com>
> Cc: adam at hibernate.org, "Hibernate" <hibernate-dev at lists.jboss.org>, "?ukasz Antoniak" <lukasz.antoniak at gmail.com>
> Sent: Tuesday, May 20, 2014 9:45:28 PM
> Subject: Re: Envers: Mapped-superclasses extended by embeddabables
> 
> Sorry, no idea why I missed that email.
> 
> So the basic rule is:
> - fields from a non-audited mapped superclass are never audited, unless an
> @AuditOverride is specified
> - if the mapped superclass is audited, then its fields are of course audited
> as well
> 
> I don?t think we want to get into supporting a @AuditOverride(?b.field?)
> syntax, as it complicates the whole thing. When an @AO is placed on a
> component, the names refer to what is inside the component, so I guess we
> can use it here?
> 
> To address the specific questions:
> 
> > In the following, A.b.intValue should be audited; A.b.strValue should not
> > be audited.
> > 
> > @Entity
> > @Audited
> > public class A{
> >    ...
> >    private B b;
> >    ...
> > }
> > 
> > @Embeddable
> > public class B extends AbstractB {
> >    private int intValue;
> > }
> > 
> > @MappedSuperclass
> > public class AbstractB {
> >    private String strValue;
> > }
> 
> Looks good
> 
> > In the following, both A.b.intValue and A.b.strValue should be audited:
> > 
> > @Entity
> > @Audited
> > @AuditOverride( name="b.strValue" )
> > public class A{
> >    ...
> >    private B b;
> >    ...
> > }
> > 
> > @Embeddable
> > public class B extends AbstractB {
> >    private int intValue;
> > }
> > 
> > @MappedSuperclass
> > public class AbstractB {
> >    private String strValue;
> > }
> 
> As above, I don?t think we want to supoprt @AO(name=?b.strValue?)? To audit
> b.strValue, you?d have to add an @AO(name=?strValue?,
> forClass=AbstractB.class) on the b field directly.
> 
> > In the following, both A.b.intValue and A.b.strValue should be audited:
> > 
> > @Entity
> > @Audited
> > public class A{
> >    ...
> >    private B b;
> >    ...
> > }
> > 
> > @Embeddable
> > public class B extends AbstractB {
> >    private int intValue;
> > }
> > 
> > @MappedSuperclass
> > @Audited
> > public class AbstractB {
> >    private String strValue;
> > }
> 
> Yes
> 
> > In the following, both A.b.intValue and A.b.strValue should be audited.
> > 
> > @Entity
> > @Audited
> > public class A{
> >    ...
> >    private B b;
> >    ...
> > }
> > 
> > @Embeddable
> > @AuditOverride( class=AbstractB.class )
> > public class B extends AbstractB {
> >    private int intValue;
> > }
> > 
> > @MappedSuperclass
> > public class AbstractB {
> >    private String strValue;
> > }
> 
> Yes
> 
> > What should be the outcome of the following? Should A.b.strValue still be
> > audited even though A.b is explicitly not audited?
> > 
> > @Entity
> > @Audited
> > public class A{
> >    ...
> >    @NotAudited
> >    private B b;
> >    ...
> > }
> > 
> > @Embeddable
> > public class B extends AbstractB {
> >    private int intValue;
> > }
> > 
> > @MappedSuperclass
> > @Audited
> > public class AbstractB {
> >    private String strValue;
> > }
> 
> @NotAudited has precedence - so not audited.
> 
> I hope things are a bit clearer :). I suppose we should document these rules.
> If, of course, you think these rules are sound - any other ideas are always
> welcome :)
> 
> Adam
> 
> --
> Adam Warski
> 
> http://twitter.com/#!/adamwarski
> http://www.softwaremill.com
> http://www.warski.org
> 
>