[hibernate-dev] Changes to the JIRA "Pull request sent" status

[Guillaume Smet]

Hi,

A few months back, when an issue was in the "Pull request sent" status, it
was considered "In progress" and appeared here:
https://hibernate.atlassian.net/projects/HV/versions/3/tab/release-report-in-progress
.

This apparently got broken at some point (or someone changed it without
asking).

My personal preference is to consider the issues with pull requests as In
progress instead of To do and it seems more logical as, as soon as you have
a PR, the issue is definitely in progress.

I applied this change as it's a simple one (it's not a workflow change,
it's just marking "Pull request sent" as a "In progress" status) and IMHO
it was a regression.

If someone is against it and it was an intentional change, please speak up.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Changes to the JIRA "Pull request sent" status

[Yoann Rodiere]

Nice! I had noticed that, but didn't think further, assuming it would not
be configurable anyway.
Thanks for fixing it.

On Wed, 6 Jun 2018 at 12:44 Guillaume Smet  wrote:

> Hi,
>
> A few months back, when an issue was in the "Pull request sent" status, it
> was considered "In progress" and appeared here:
>
> https://hibernate.atlassian.net/projects/HV/versions/3/tab/release-report-in-progress
> .
>
> This apparently got broken at some point (or someone changed it without
> asking).
>
> My personal preference is to consider the issues with pull requests as In
> progress instead of To do and it seems more logical as, as soon as you have
> a PR, the issue is definitely in progress.
>
> I applied this change as it's a simple one (it's not a workflow change,
> it's just marking "Pull request sent" as a "In progress" status) and IMHO
> it was a regression.
>
> If someone is against it and it was an intentional change, please speak up.
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Changes to the JIRA "Pull request sent" status

[Sanne Grinovero]

Just curious, did that really work consistently?

As far as I know, the JIRA integration was never really able to match
GitHub PR changes to JIRA issues reliably.

On 6 June 2018 at 11:37, Guillaume Smet  wrote:
> Hi,
>
> A few months back, when an issue was in the "Pull request sent" status, it
> was considered "In progress" and appeared here:
> https://hibernate.atlassian.net/projects/HV/versions/3/tab/release-report-in-progress
> .
>
> This apparently got broken at some point (or someone changed it without
> asking).
>
> My personal preference is to consider the issues with pull requests as In
> progress instead of To do and it seems more logical as, as soon as you have
> a PR, the issue is definitely in progress.
>
> I applied this change as it's a simple one (it's not a workflow change,
> it's just marking "Pull request sent" as a "In progress" status) and IMHO
> it was a regression.
>
> If someone is against it and it was an intentional change, please speak up.
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Changes to the JIRA "Pull request sent" status

[Guillaume Smet]

On Wed, Jun 6, 2018 at 12:57 PM Sanne Grinovero  wrote:

> Just curious, did that really work consistently?
>

Well, it works consistently as in if your issue is in the "Pull request
sent" status, the issue is considered "In progress".

This status is associated with the explicit action "Link to pull request"
we have in the NoORM workflow so it's not about automatic detection.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Changes to the JIRA "Pull request sent" status

[Sanne Grinovero]

On 6 June 2018 at 12:04, Guillaume Smet  wrote:
> On Wed, Jun 6, 2018 at 12:57 PM Sanne Grinovero  wrote:
>>
>> Just curious, did that really work consistently?
>
>
> Well, it works consistently as in if your issue is in the "Pull request
> sent" status, the issue is considered "In progress".
>
> This status is associated with the explicit action "Link to pull request" we
> have in the NoORM workflow so it's not about automatic detection.

Thanks. This used to not work well at all, it was probably improved.

I don't know about others but I didn't make changes on JIRA in a long
time - or I'd normally share actions here.

>
> --
> Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Changes to the JIRA "Pull request sent" status

[Guillaume Smet]

On Wed, Jun 6, 2018 at 1:29 PM Sanne Grinovero  wrote:

> I don't know about others but I didn't make changes on JIRA in a long
> time - or I'd normally share actions here.
>

It might also be due to a JIRA upgrade as they did quite a lot of changes.

Anyway, we are back on track now.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 5.2.18 to be the last in 5.2 series?

[Guillaume Smet]

On Tue, Jun 5, 2018 at 10:33 PM Gail Badner  wrote:

> Chris mentioned that he is planning to release 5.2.18 on Thursday.
>

It would be nice if we could get
https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
5.2.18, considering it's a regression introduced after 5.2.13. If we didn't
expect 5.2.18 to be the last 5.2, I wouldn't ask.

I don't know if Christian has some bandwidth to take a look as it seems
related to his prior work.

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 5.2.18 to be the last in 5.2 series?

[Steve Ebersole]

+1 to stopping 5.2 releases.

On Wed, Jun 6, 2018 at 7:40 AM Guillaume Smet 
wrote:

> On Tue, Jun 5, 2018 at 10:33 PM Gail Badner  wrote:
>
> > Chris mentioned that he is planning to release 5.2.18 on Thursday.
> >
>
> It would be nice if we could get
> https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
> 5.2.18, considering it's a regression introduced after 5.2.13. If we didn't
> expect 5.2.18 to be the last 5.2, I wouldn't ask.
>
> I don't know if Christian has some bandwidth to take a look as it seems
> related to his prior work.
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 5.2.18 to be the last in 5.2 series?

[Chris Cranford]

I'm fine postponing the release for another week or 2 if that helps,
Christian. 

On 06/06/2018 08:26 AM, Guillaume Smet wrote:
> On Tue, Jun 5, 2018 at 10:33 PM Gail Badner  wrote:
>
>> Chris mentioned that he is planning to release 5.2.18 on Thursday.
>>
> It would be nice if we could get
> https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
> 5.2.18, considering it's a regression introduced after 5.2.13. If we didn't
> expect 5.2.18 to be the last 5.2, I wouldn't ask.
>
> I don't know if Christian has some bandwidth to take a look as it seems
> related to his prior work.
>

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 5.2.18 to be the last in 5.2 series?

[Vlad Mihalcea]

+1.

Unless there will be some serious issues that call for a 5.2.19 release, we
should focus on 5.3.

Vlad

On Wed, Jun 6, 2018 at 3:45 PM, Steve Ebersole  wrote:

> +1 to stopping 5.2 releases.
>
> On Wed, Jun 6, 2018 at 7:40 AM Guillaume Smet 
> wrote:
>
> > On Tue, Jun 5, 2018 at 10:33 PM Gail Badner  wrote:
> >
> > > Chris mentioned that he is planning to release 5.2.18 on Thursday.
> > >
> >
> > It would be nice if we could get
> > https://hibernate.atlassian.net/browse/HHH-12645 fixed before releasing
> > 5.2.18, considering it's a regression introduced after 5.2.13. If we
> didn't
> > expect 5.2.18 to be the last 5.2, I wouldn't ask.
> >
> > I don't know if Christian has some bandwidth to take a look as it seems
> > related to his prior work.
> >
> > --
> > Guillaume
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] What should be the contract for PersistenceUnitInfo#addTransformer with regard to multiple persistence units mapping the same entity class?

[Scott Marlow]

On Tue, Jun 5, 2018 at 3:38 PM, Luis Barreiro  wrote:

> My reading on that javadoc is that you only get the transformation once
> (the first time that a class is loaded) and after that, if it's used by
> other PUs, it may not get the transformations those PUs specify.
>

We added TRACE logging for WildFly 14 that shows when the transformation
occurs.  https://paste.fedoraproject.org/paste/gna7ww8aM59sXjnAUIsEJw shows
server output for ORM 5.1.14 + 5.3.1.  I also locally added a call to
Thread.printStack()
if org.hibernate.jpa.internal.enhance.EnhancingClassTransformerImpl returns
a non-null result (which means that the passed entity class was enhanced).

The server output, shows the persistence.xml for an invalid application, so
we can see what happens if the same entity class is mapped to two
persistence units, that both enable entity enhancing.

If there is interest in discussion this, we can meet up on hipchat or irc
(or discussing here is also fine).

It looks like EnhancingClassTransformerImpl doesn't return the correct
result, if no transformation is made.  Not a serious bug but I think
we EnhancingClassTransformerImpl
should return null if the class is already transformed.

Scott

> I would like to add that the enhancer is synchronous (it only enhance one
> class at a time), hence my question about synchronization, but you were
> obviously looking at a different level.
>
> Regards,
>
> Luis Barreiro
>
> Middleware Performance Team
> 
> On 06/05/2018 07:08 PM, Scott Marlow wrote:
>
> Thanks, I think they probably intended that the persistence provider would
> use a marker interface like org.hibernate.engine.spi.Managed to ensure
> that the enhancement is only done once.  Responses to your questions are
> inline below.
>
> On Tue, Jun 5, 2018 at 12:19 PM, Luis Barreiro 
> wrote:
>
>> Hi Scott,
>>
>> In the particular case of the hibernate bytecode enhancer, it adds the
>> org.hibernate.engine.spi.Managed marker interface to the entity so that
>> it only performs the enhancement once. (that implies that you can't have
>> the same entity enhanced for different features in the same class loader)
>>
>> Also, in theory, you could have multiple transformations applied to the
>> same entity / PU. So what is it you really want to check ?!
>>
> Mostly, I'm trying to understand why the [1] javadoc requires that classes
> are only transformed only once, as I would expect that some persistence
> providers could want to register multiple transformers.
>
>> I don't get you last paragraph ... why ORM will be only capable of
>> registering one transformer,
>>
> If we update the WildFly JPA container  JPADelegatingClassFileTransformer
> [2] to only allow the application entity class to be enhanced at most once
> (at runtime), ORM would be able to register multiple transformers but the
> first ORM transformer that actually enhances the entity class (e.g.
> transformer returns non-null return value), would need to terminate the
> "for each transformer" loop in [2].
>
> Since, as you said, ORM is already using a marker interface to know when a
> class is already enhanced, it sounds like WildFly doesn't really need to
> enforce the [1] contract (with regard to only transforming the entity class
> once).
>
>
>> and why will you need synchronization ?!
>>
> If WildFly JPADelegatingClassFileTransformer [2] where modified to
> prevent more than one transformation of an entity class, that would include
> checking across (parallel) persistence unit deployment threads, which could
> be done with a Java synchronization lock.
>
> Scott
>
> [1] https://docs.oracle.com/javaee/7/api/javax/persistence/spi/
> PersistenceUnitInfo.html#addTransformer-javax.persistence.spi.
> ClassTransformer-
>
> [2] https://github.com/wildfly/wildfly/blob/master/
> jpa/subsystem/src/main/java/org/jboss/as/jpa/classloader/
> JPADelegatingClassFileTransformer.java#L44
>
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev