7:43 a.m.
WildFly would like to have a version of 5.3+, that is compatible with ORM
5.1, with regard to the org.hibernate.session changes (including mapping of
exceptions thrown, so that the same exceptions are thrown).
Is it even possible to have an extra org.hibernate.Session interface + impl
(bridge) that matches the same session included in 5.1? The impl would
delegate to the real underlying org.hibernate.Session impl classes and also
wrap thrown exceptions, so that Hibernate 5.1 native ORM apps, continue to
work without code changes
Or something like that.
I could see how some users wouldn't want to use the compatibility layer to
avoid extra overhead, so in WildFly, we would have to make that possible
also.
What do you think?
We would need something similar in ORM 6.0+ that is also compatible with
5.1, if this is possible.
Scott
4:28 p.m.
Didn't we discuss this at our last meeting?
The general opinion - and final verdict - was that doing like you're
asking now again would be way too much work and not generally worth
it, not least not in the best interest of all our users. Technically
it's certainly possible, but a lot of work going at cost of more
useful progress, not least possibly causing confusion to users in
various ways.
Our proposal is unchanged (from the meeting):
we'll have - experimentally - two versions in WildFly.
In a first stage this would be version 5.1 and 5.3, so that people
needing backwards compatibility with 5.1 can use 5.1 (can't have
better compatibility than that!), while people wanting to use a later
version can opt in for that.
In a second stage, possibly onboarding some lessons, version 5.3 will
be gradually replaced with 6.0. MAYBE 6.0 will be API compatible with
5.3, but definitely not with 5.1.
I'm not sure if we can have this in WildFly.next, but the sooner the
better. As soon as we have a stable release of Hibernate ORM 5.3 we'll
start looking into details of such a double integration.
Thanks,
Sanne
On 31 January 2018 at 06:43, Scott Marlow <smarlow(a)redhat.com> wrote:
WildFly would like to have a version of 5.3+, that is compatible with
ORM
5.1, with regard to the org.hibernate.session changes (including mapping of
exceptions thrown, so that the same exceptions are thrown).
Is it even possible to have an extra org.hibernate.Session interface + impl
(bridge) that matches the same session included in 5.1? The impl would
delegate to the real underlying org.hibernate.Session impl classes and also
wrap thrown exceptions, so that Hibernate 5.1 native ORM apps, continue to
work without code changes
Or something like that.
I could see how some users wouldn't want to use the compatibility layer to
avoid extra overhead, so in WildFly, we would have to make that possible
also.
What do you think?
We would need something similar in ORM 6.0+ that is also compatible with
5.1, if this is possible.
Scott
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:49 p.m.
Not to mention, I'm really not even sure what this request "means". As we
all understand 5.1 -> 5.2 unified SessionFactory/EntityManagerFactory and
Session/EntityManager, and that caused us to have to make changes to
certain method signatures - most notably `Session#getFlushMode` was one of
the problems. Session defined that returning a FlushMode; however JPA also
defined this same method, although poorly named IMO since it instead
returns JPA's FlushModeType (so why the method is not called
`#getFlushModeType` is beyond me. Anyway the point is that there is no way
to rectify these - there is no way that we can define a contract that
simultaneously conforms to both.
As Sanne said, and as we all agreed during f2f, the best approach is to
have both versions available for use.
On Wed, Jan 31, 2018 at 9:28 AM Sanne Grinovero <sanne(a)hibernate.org> wrote:
Didn't we discuss this at our last meeting?
The general opinion - and final verdict - was that doing like you're
asking now again would be way too much work and not generally worth
it, not least not in the best interest of all our users. Technically
it's certainly possible, but a lot of work going at cost of more
useful progress, not least possibly causing confusion to users in
various ways.
Our proposal is unchanged (from the meeting):
we'll have - experimentally - two versions in WildFly.
In a first stage this would be version 5.1 and 5.3, so that people
needing backwards compatibility with 5.1 can use 5.1 (can't have
better compatibility than that!), while people wanting to use a later
version can opt in for that.
In a second stage, possibly onboarding some lessons, version 5.3 will
be gradually replaced with 6.0. MAYBE 6.0 will be API compatible with
5.3, but definitely not with 5.1.
I'm not sure if we can have this in WildFly.next, but the sooner the
better. As soon as we have a stable release of Hibernate ORM 5.3 we'll
start looking into details of such a double integration.
Thanks,
Sanne
On 31 January 2018 at 06:43, Scott Marlow <smarlow(a)redhat.com> wrote:
> WildFly would like to have a version of 5.3+, that is compatible with ORM
> 5.1, with regard to the org.hibernate.session changes (including mapping
of
> exceptions thrown, so that the same exceptions are thrown).
>
> Is it even possible to have an extra org.hibernate.Session interface +
impl
> (bridge) that matches the same session included in 5.1? The impl would
> delegate to the real underlying org.hibernate.Session impl classes and
also
> wrap thrown exceptions, so that Hibernate 5.1 native ORM apps, continue
to
> work without code changes
>
> Or something like that.
>
> I could see how some users wouldn't want to use the compatibility layer
to
> avoid extra overhead, so in WildFly, we would have to make that possible
> also.
>
> What do you think?
>
> We would need something similar in ORM 6.0+ that is also compatible with
> 5.1, if this is possible.
>
> Scott
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:30 p.m.
On 01/31/2018 10:49 AM, Steve Ebersole wrote:
Not to mention, I'm really not even sure what this request
"means". As
we all understand 5.1 -> 5.2 unified SessionFactory/EntityManagerFactory
and Session/EntityManager, and that caused us to have to make changes to
certain method signatures - most notably `Session#getFlushMode` was one
of the problems. Session defined that returning a FlushMode; however
JPA also defined this same method, although poorly named IMO since it
instead returns JPA's FlushModeType (so why the method is not called
`#getFlushModeType` is beyond me. Anyway the point is that there is no
way to rectify these - there is no way that we can define a contract
that simultaneously conforms to both.
As Sanne said, and as we all agreed during f2f, the best approach is to
have both versions available for use.
Which Hibernate ORM release would be best for the second version that we
include? ORM 5.3 or 6.0?
Agreed that we will still include ORM 5.1, in WildFly. For the second
ORM version that we include (whatever the version is), we have an
additional requirement now. Future releases of WildFly need to be
(JPA/native application) compatible with the Hibernate ORM versions that
we include.
We will be releasing WildFly more frequently, and want users to be able
to able to keep up with our pace, as we release more often.
Scott
7:50 p.m.
What is meant by "(JPA/native application) compatible with the Hibernate
ORM versions that we include"?
Both 5.3 and 6.0 are JPA 2.2, but 5.1 is JPA 2.1. Does that mean they
violate that requirement?
On Thu, Feb 8, 2018 at 12:30 PM Scott Marlow <smarlow(a)redhat.com> wrote:
On 01/31/2018 10:49 AM, Steve Ebersole wrote:
> Not to mention, I'm really not even sure what this request "means".
As
> we all understand 5.1 -> 5.2 unified SessionFactory/EntityManagerFactory
> and Session/EntityManager, and that caused us to have to make changes to
> certain method signatures - most notably `Session#getFlushMode` was one
> of the problems. Session defined that returning a FlushMode; however
> JPA also defined this same method, although poorly named IMO since it
> instead returns JPA's FlushModeType (so why the method is not called
> `#getFlushModeType` is beyond me. Anyway the point is that there is no
> way to rectify these - there is no way that we can define a contract
> that simultaneously conforms to both.
>
> As Sanne said, and as we all agreed during f2f, the best approach is to
> have both versions available for use.
Which Hibernate ORM release would be best for the second version that we
include? ORM 5.3 or 6.0?
Agreed that we will still include ORM 5.1, in WildFly. For the second
ORM version that we include (whatever the version is), we have an
additional requirement now. Future releases of WildFly need to be
(JPA/native application) compatible with the Hibernate ORM versions that
we include.
We will be releasing WildFly more frequently, and want users to be able
to able to keep up with our pace, as we release more often.
Scott
8:54 p.m.
On 02/08/2018 01:50 PM, Steve Ebersole wrote:
What is meant by "(JPA/native application) compatible with the
Hibernate
ORM versions that we include"?
It means that for a while, we can only upgrade WildFly to newer
Hibernate ORM versions that are compatible with one of the two Hibernate
versions that we include with WildFly 12+.
Both 5.3 and 6.0 are JPA 2.2, but 5.1 is JPA 2.1. Does that mean they
violate that requirement?
I think the 5.3 versus 6.0 question, is more will applications written
against the (application level) Hibernate 5.3 ORM classes, work
correctly against 6.0. For determining which classes exactly, are
application level classes, the Hibernate team should decide that.
If the design for Hibernate ORM code changes, misses an application
compatibility issue that we miss, that cannot be avoided. However, when
the WildFly team looks at the latest/greatest version of Hibernate ORM
to include, we will face pressure against bringing in any newer ORM
version that requires application coding/configuration changes.
On Thu, Feb 8, 2018 at 12:30 PM Scott Marlow <smarlow(a)redhat.com
<mailto:smarlow@redhat.com>> wrote:
On 01/31/2018 10:49 AM, Steve Ebersole wrote:
> Not to mention, I'm really not even sure what this request
"means". As
> we all understand 5.1 -> 5.2 unified
SessionFactory/EntityManagerFactory
> and Session/EntityManager, and that caused us to have to make
changes to
> certain method signatures - most notably `Session#getFlushMode`
was one
> of the problems. Session defined that returning a FlushMode; however
> JPA also defined this same method, although poorly named IMO since it
> instead returns JPA's FlushModeType (so why the method is not called
> `#getFlushModeType` is beyond me. Anyway the point is that there
is no
> way to rectify these - there is no way that we can define a contract
> that simultaneously conforms to both.
>
> As Sanne said, and as we all agreed during f2f, the best approach
is to
> have both versions available for use.
Which Hibernate ORM release would be best for the second version that we
include? ORM 5.3 or 6.0?
Agreed that we will still include ORM 5.1, in WildFly. For the second
ORM version that we include (whatever the version is), we have an
additional requirement now. Future releases of WildFly need to be
(JPA/native application) compatible with the Hibernate ORM versions that
we include.
We will be releasing WildFly more frequently, and want users to be able
to able to keep up with our pace, as we release more often.
Scott
11:08 p.m.
Hi Scott,
remember ORM 6.0 doesn't exist yet. Technically 5.3 doesn't exist yet
either, but it's close.
I'd start working to get 5.3 included so that we can address all
integration issues, and additional unknowns caused by having multiple
versions. If when we're all done fixing such problems 6.0 will be out,
we'll re-evaluate the situation.
In the meantime we'll check if 6.0 is going to be strickly compatible
with 5.3: hard to answer on that in a definitive way when neither is
ready. Unless Steve knows of some *public API* which definitely needs
to break between 5.3 to 6.0? AFAIR last time we had such a
conversation there was no clear agreement on what extensions should be
considered public API *in the scope of WildFly's requirements*. Scott,
do you have an update on that, or maybe refresh our memories?
Thanks,
Sanne
On 8 February 2018 at 19:54, Scott Marlow <smarlow(a)redhat.com> wrote:
On 02/08/2018 01:50 PM, Steve Ebersole wrote:
>
> What is meant by "(JPA/native application) compatible with the Hibernate
> ORM versions that we include"?
It means that for a while, we can only upgrade WildFly to newer Hibernate
ORM versions that are compatible with one of the two Hibernate versions that
we include with WildFly 12+.
>
> Both 5.3 and 6.0 are JPA 2.2, but 5.1 is JPA 2.1. Does that mean they
> violate that requirement?
I think the 5.3 versus 6.0 question, is more will applications written
against the (application level) Hibernate 5.3 ORM classes, work correctly
against 6.0. For determining which classes exactly, are application level
classes, the Hibernate team should decide that.
If the design for Hibernate ORM code changes, misses an application
compatibility issue that we miss, that cannot be avoided. However, when the
WildFly team looks at the latest/greatest version of Hibernate ORM to
include, we will face pressure against bringing in any newer ORM version
that requires application coding/configuration changes.
>
>
> On Thu, Feb 8, 2018 at 12:30 PM Scott Marlow <smarlow(a)redhat.com
> <mailto:smarlow@redhat.com>> wrote:
>
>
>
> On 01/31/2018 10:49 AM, Steve Ebersole wrote:
> > Not to mention, I'm really not even sure what this request
> "means". As
> > we all understand 5.1 -> 5.2 unified
> SessionFactory/EntityManagerFactory
> > and Session/EntityManager, and that caused us to have to make
> changes to
> > certain method signatures - most notably `Session#getFlushMode`
> was one
> > of the problems. Session defined that returning a FlushMode;
> however
> > JPA also defined this same method, although poorly named IMO since
> it
> > instead returns JPA's FlushModeType (so why the method is not
> called
> > `#getFlushModeType` is beyond me. Anyway the point is that there
> is no
> > way to rectify these - there is no way that we can define a
> contract
> > that simultaneously conforms to both.
> >
> > As Sanne said, and as we all agreed during f2f, the best approach
> is to
> > have both versions available for use.
>
> Which Hibernate ORM release would be best for the second version that
> we
> include? ORM 5.3 or 6.0?
>
> Agreed that we will still include ORM 5.1, in WildFly. For the second
> ORM version that we include (whatever the version is), we have an
> additional requirement now. Future releases of WildFly need to be
> (JPA/native application) compatible with the Hibernate ORM versions
> that
> we include.
>
> We will be releasing WildFly more frequently, and want users to be
> able
> to able to keep up with our pace, as we release more often.
>
> Scott
>
2:32 p.m.
Hi Sanne,
Good question about what is public API exactly. In WF modules, we have a
way to mark the entire module as private. That doesn't help here, and that
would only be a "how" not answering "what extensions".
Having said that, it would be interesting to know the "how" as well.
Perhaps documentation could state what APIs in Hibernate 5.3 that could be
expected to *not* be the same in 6.0+. This wouldn't include new method
signatures added but instead only existing method signatures removed. As
well as, existing methods that are going to be repurposed in some way.
I am not sure if this is enough but we could explore this idea if it would
give us enough flexibility to move from 5.3 to 6.0+, later.
Scott
On Feb 8, 2018 5:09 PM, "Sanne Grinovero" <sanne(a)hibernate.org> wrote:
Hi Scott,
remember ORM 6.0 doesn't exist yet. Technically 5.3 doesn't exist yet
either, but it's close.
I'd start working to get 5.3 included so that we can address all
integration issues, and additional unknowns caused by having multiple
versions. If when we're all done fixing such problems 6.0 will be out,
we'll re-evaluate the situation.
In the meantime we'll check if 6.0 is going to be strickly compatible
with 5.3: hard to answer on that in a definitive way when neither is
ready. Unless Steve knows of some *public API* which definitely needs
to break between 5.3 to 6.0? AFAIR last time we had such a
conversation there was no clear agreement on what extensions should be
considered public API *in the scope of WildFly's requirements*. Scott,
do you have an update on that, or maybe refresh our memories?
Thanks,
Sanne
On 8 February 2018 at 19:54, Scott Marlow <smarlow(a)redhat.com> wrote:
On 02/08/2018 01:50 PM, Steve Ebersole wrote:
>
> What is meant by "(JPA/native application) compatible with the Hibernate
> ORM versions that we include"?
It means that for a while, we can only upgrade WildFly to newer Hibernate
ORM versions that are compatible with one of the two Hibernate versions
that
we include with WildFly 12+.
>
> Both 5.3 and 6.0 are JPA 2.2, but 5.1 is JPA 2.1. Does that mean they
> violate that requirement?
I think the 5.3 versus 6.0 question, is more will applications written
against the (application level) Hibernate 5.3 ORM classes, work correctly
against 6.0. For determining which classes exactly, are application level
classes, the Hibernate team should decide that.
If the design for Hibernate ORM code changes, misses an application
compatibility issue that we miss, that cannot be avoided. However, when
the
WildFly team looks at the latest/greatest version of Hibernate ORM
to
include, we will face pressure against bringing in any newer ORM version
that requires application coding/configuration changes.
>
>
> On Thu, Feb 8, 2018 at 12:30 PM Scott Marlow <smarlow(a)redhat.com
> <mailto:smarlow@redhat.com>> wrote:
>
>
>
> On 01/31/2018 10:49 AM, Steve Ebersole wrote:
> > Not to mention, I'm really not even sure what this request
> "means". As
> > we all understand 5.1 -> 5.2 unified
> SessionFactory/EntityManagerFactory
> > and Session/EntityManager, and that caused us to have to make
> changes to
> > certain method signatures - most notably `Session#getFlushMode`
> was one
> > of the problems. Session defined that returning a FlushMode;
> however
> > JPA also defined this same method, although poorly named IMO since
> it
> > instead returns JPA's FlushModeType (so why the method is not
> called
> > `#getFlushModeType` is beyond me. Anyway the point is that there
> is no
> > way to rectify these - there is no way that we can define a
> contract
> > that simultaneously conforms to both.
> >
> > As Sanne said, and as we all agreed during f2f, the best approach
> is to
> > have both versions available for use.
>
> Which Hibernate ORM release would be best for the second version that
> we
> include? ORM 5.3 or 6.0?
>
> Agreed that we will still include ORM 5.1, in WildFly. For the
second
> ORM version that we include (whatever the version is), we
have an
> additional requirement now. Future releases of WildFly need to be
> (JPA/native application) compatible with the Hibernate ORM versions
> that
> we include.
>
> We will be releasing WildFly more frequently, and want users to be
> able
> to able to keep up with our pace, as we release more often.
>
> Scott
>
3:51 p.m.
On 10 February 2018 at 13:32, Scott Marlow <smarlow(a)redhat.com> wrote:
Hi Sanne,
Good question about what is public API exactly. In WF modules, we have a
way to mark the entire module as private. That doesn't help here, and that
would only be a "how" not answering "what extensions".
Having said that, it would be interesting to know the "how" as well.
Perhaps documentation could state what APIs in Hibernate 5.3 that could be
expected to *not* be the same in 6.0+. This wouldn't include new method
signatures added but instead only existing method signatures removed. As
well as, existing methods that are going to be repurposed in some way.
I am not sure if this is enough but we could explore this idea if it would
give us enough flexibility to move from 5.3 to 6.0+, later.
That sounds like a workable idea. Users won't have to wait for 6, and
we can document our intentions.
We've previously used labels such as "experimental" on some APIs but
that hasn't been very effective.
To avoid misunderstandings, I'd prefer an explicit "opt in" for what
we consider stable API. So rather than listing what is *not*
supported, I propose we mark/annotate/document the methods we consider
stable. Would that work for WildFly's needs?
This way we'll likely be very conservative in 5.3 with what we
document to be "stable", providing essentially JPA and a few more
cherry picked essentials; we could then relax restrictions in smaller
steps while the new stuff matures.
I expect some cathegories of users will find our selection too
restrictive, but those more demanding are free to use ORM 5.1 for the
time being and let us know what they'd like to see supported in the
next round.
I also expect the majority of users to not care at all what we
document being stable or not, so everyone will have options ;)
Thanks,
Sanne
Scott
On Feb 8, 2018 5:09 PM, "Sanne Grinovero" <sanne(a)hibernate.org> wrote:
Hi Scott,
remember ORM 6.0 doesn't exist yet. Technically 5.3 doesn't exist yet
either, but it's close.
I'd start working to get 5.3 included so that we can address all
integration issues, and additional unknowns caused by having multiple
versions. If when we're all done fixing such problems 6.0 will be out,
we'll re-evaluate the situation.
In the meantime we'll check if 6.0 is going to be strickly compatible
with 5.3: hard to answer on that in a definitive way when neither is
ready. Unless Steve knows of some *public API* which definitely needs
to break between 5.3 to 6.0? AFAIR last time we had such a
conversation there was no clear agreement on what extensions should be
considered public API *in the scope of WildFly's requirements*. Scott,
do you have an update on that, or maybe refresh our memories?
Thanks,
Sanne
On 8 February 2018 at 19:54, Scott Marlow <smarlow(a)redhat.com> wrote:
>
>
> On 02/08/2018 01:50 PM, Steve Ebersole wrote:
>>
>> What is meant by "(JPA/native application) compatible with the Hibernate
>> ORM versions that we include"?
>
>
> It means that for a while, we can only upgrade WildFly to newer Hibernate
> ORM versions that are compatible with one of the two Hibernate versions
> that
> we include with WildFly 12+.
>
>>
>> Both 5.3 and 6.0 are JPA 2.2, but 5.1 is JPA 2.1. Does that mean they
>> violate that requirement?
>
>
> I think the 5.3 versus 6.0 question, is more will applications written
> against the (application level) Hibernate 5.3 ORM classes, work correctly
> against 6.0. For determining which classes exactly, are application level
> classes, the Hibernate team should decide that.
>
> If the design for Hibernate ORM code changes, misses an application
> compatibility issue that we miss, that cannot be avoided. However, when
> the
> WildFly team looks at the latest/greatest version of Hibernate ORM to
> include, we will face pressure against bringing in any newer ORM version
> that requires application coding/configuration changes.
>
>
>>
>>
>> On Thu, Feb 8, 2018 at 12:30 PM Scott Marlow <smarlow(a)redhat.com
>> <mailto:smarlow@redhat.com>> wrote:
>>
>>
>>
>> On 01/31/2018 10:49 AM, Steve Ebersole wrote:
>> > Not to mention, I'm really not even sure what this request
>> "means". As
>> > we all understand 5.1 -> 5.2 unified
>> SessionFactory/EntityManagerFactory
>> > and Session/EntityManager, and that caused us to have to make
>> changes to
>> > certain method signatures - most notably `Session#getFlushMode`
>> was one
>> > of the problems. Session defined that returning a FlushMode;
>> however
>> > JPA also defined this same method, although poorly named IMO since
>> it
>> > instead returns JPA's FlushModeType (so why the method is not
>> called
>> > `#getFlushModeType` is beyond me. Anyway the point is that there
>> is no
>> > way to rectify these - there is no way that we can define a
>> contract
>> > that simultaneously conforms to both.
>> >
>> > As Sanne said, and as we all agreed during f2f, the best approach
>> is to
>> > have both versions available for use.
>>
>> Which Hibernate ORM release would be best for the second version that
>> we
>> include? ORM 5.3 or 6.0?
>>
>> Agreed that we will still include ORM 5.1, in WildFly. For the
>> second
>> ORM version that we include (whatever the version is), we have an
>> additional requirement now. Future releases of WildFly need to be
>> (JPA/native application) compatible with the Hibernate ORM versions
>> that
>> we include.
>>
>> We will be releasing WildFly more frequently, and want users to be
>> able
>> to able to keep up with our pace, as we release more often.
>>
>> Scott
>>
>
2267
days inactive
2277
days old
8 comments
3 participants
participants (3)
-
Sanne Grinovero -
Scott Marlow -
Steve Ebersole