Re: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing

2017-09-07 Thread Gail Badner 
That's a better solution than what I had in mind.

On Thu, Sep 7, 2017 at 4:28 PM, Steve Ebersole  wrote:

> My suggestion to Sanne (not sure if he was going to take this approach)
> was to essentially copy the way I handle this in 6 :
> https://github.com/sebersole/hibernate-core/blob/wip/6.0/
> hibernate-core/src/main/java/org/hibernate/resource/cdi/
> spi/ManagedBeanRegistry.java
>
> On Thu, Sep 7, 2017, 5:38 PM Gail Badner  wrote:
>
>> OK, sounds good. Did Steve suggest how to fix it in HSearch? If he
>> didn't, I have kind of a hacky idea.
>>
>> On Thu, Sep 7, 2017 at 2:59 PM, Sanne Grinovero 
>> wrote:
>>
>>> On 7 September 2017 at 22:38, Gail Badner  wrote:
>>> > Are you saying that you don't need a fix for this?
>>>
>>> I'm going to need fixing the Hibernate Search code, but besides that
>>> yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa)
>>> nor Hibernate ORM.
>>>
>>> Thanks,
>>> Sanne
>>>
>>> >
>>> > On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero 
>>> > wrote:
>>> >>
>>> >> I had a chat with Steve about this and I understand better now why the
>>> >> WildFly/JipiJapa/HibernateORM does what it does.
>>> >>
>>> >> We'll update the Hibernate Search integration test and move on!
>>> >>
>>> >> Thanks,
>>> >> Sanne
>>> >>
>>> >>
>>> >> On 6 September 2017 at 22:19, Sanne Grinovero 
>>> wrote:
>>> >> > Hi Gail,
>>> >> >
>>> >> > the failing test is CDIInjectionIT from my personal branch of
>>> >> > Hibernate Search called "WildFly11" :
>>> >> >
>>> >> >
>>> >> > https://github.com/Sanne/hibernate-search/blob/
>>> WildFly11/integrationtest/wildfly/src/test/java/org/
>>> hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java
>>> >> >
>>> >> > It is an Arquillian test and it requires you to build Hibernate ORM
>>> >> > master first, as I switched the dependencies to use Hibernate ORM
>>> >> > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it
>>> requires
>>> >> > HHH-11950
>>> >> >
>>> >> > Thanks,
>>> >> > Sanne
>>> >> >
>>> >> >
>>> >> > On 1 September 2017 at 19:11, Gail Badner 
>>> wrote:
>>> >> >> I have a better understanding after discussing further with Scott,
>>> so I
>>> >> >> agree with Steve now.
>>> >> >>
>>> >> >> I have some ideas about how to fix this.
>>> >> >>
>>> >> >> Sanne, you mentioned getting a failure using an integration test.
>>> >> >> Please
>>> >> >> provide details for reproducing this.
>>> >> >>
>>> >> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole <
>>> st...@hibernate.org>
>>> >> >> wrote:
>>> >> >>>
>>> >> >>> The whole purpose of ExtendedBeanManager is cases where the
>>> >> >>> BeanManager is
>>> >> >>> not available when Hibernate boots (in other words when Hibernate
>>> is
>>> >> >>> told
>>> >> >>> which to use) .  This is a way to give Hibernate a callback when
>>> the
>>> >> >>> BeanManager is available.  IMO this ExtendedBeanManager
>>> implementing
>>> >> >>> BeanManager is inaccurate.  But would certainly like to hear
>>> Scott's
>>> >> >>> opinion
>>> >> >>> as well.
>>> >> >>>
>>> >> >>> Technically this situation is non-JPA compliant as JPA requires
>>> that
>>> >> >>> the
>>> >> >>> BeanManager passed to be available at boot-time.
>>> >> >>>
>>> >> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero <
>>> sa...@hibernate.org>
>>> >> >>> wrote:
>>> >> 
>>> >>  Hi Gail,
>>> >> 
>>> >>  no I haven't opened a WFLY issue as I'm not sure if this is an
>>> issue.
>>> >> 
>>> >>  There seems to be some inconsistency and it certainly breaks some
>>> >>  Hibernate Search tests but we could of course adapt things to
>>> the new
>>> >>  reality..  if this is how it's meant to be.
>>> >> 
>>> >>  The source code of the ExtendedBeanManager which you didn't find
>>> is
>>> >>  located in the WildFly source code; it's part of JipiJapa:
>>> >>   -
>>> >> 
>>> >>  https://github.com/wildfly/wildfly/blob/master/jpa/
>>> hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/
>>> HibernateExtendedBeanManager.java
>>> >> 
>>> >>  As you also noticed, it no longer implement the standard
>>> BeanManager
>>> >>  interface. I agree with you that I'd expect it to still
>>> implement it,
>>> >>  but clearly this was changed intentionally so I hope someone
>>> (Scott
>>> >>  possibly?) can clarify - or revert.
>>> >> 
>>> >>  In case this is intentionally no longer implementing the standard
>>> >>  interface we should at least clarify the javadocs if this
>>> >>  configuration property.
>>> >> 
>>> >>  The missing  javax.el.ELResolver and javax.el.ExpressionFactory
>>> is
>>> >>  unfortunate. I'd hope we could do better than just add them back,
>>> >>  maybe it requires a dedicated module? Having too many
>>> dependencies -
>>> >>  in this case half of Weld - slows down our bootstrap

Re: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing

2017-09-07 Thread Steve Ebersole 
My suggestion to Sanne (not sure if he was going to take this approach) was
to essentially copy the way I handle this in 6 :
https://github.com/sebersole/hibernate-core/blob/wip/6.0/hibernate-core/src/main/java/org/hibernate/resource/cdi/spi/ManagedBeanRegistry.java

On Thu, Sep 7, 2017, 5:38 PM Gail Badner  wrote:

> OK, sounds good. Did Steve suggest how to fix it in HSearch? If he didn't,
> I have kind of a hacky idea.
>
> On Thu, Sep 7, 2017 at 2:59 PM, Sanne Grinovero 
> wrote:
>
>> On 7 September 2017 at 22:38, Gail Badner  wrote:
>> > Are you saying that you don't need a fix for this?
>>
>> I'm going to need fixing the Hibernate Search code, but besides that
>> yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa)
>> nor Hibernate ORM.
>>
>> Thanks,
>> Sanne
>>
>> >
>> > On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero 
>> > wrote:
>> >>
>> >> I had a chat with Steve about this and I understand better now why the
>> >> WildFly/JipiJapa/HibernateORM does what it does.
>> >>
>> >> We'll update the Hibernate Search integration test and move on!
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >>
>> >> On 6 September 2017 at 22:19, Sanne Grinovero 
>> wrote:
>> >> > Hi Gail,
>> >> >
>> >> > the failing test is CDIInjectionIT from my personal branch of
>> >> > Hibernate Search called "WildFly11" :
>> >> >
>> >> >
>> >> >
>> https://github.com/Sanne/hibernate-search/blob/WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java
>> >> >
>> >> > It is an Arquillian test and it requires you to build Hibernate ORM
>> >> > master first, as I switched the dependencies to use Hibernate ORM
>> >> > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires
>> >> > HHH-11950
>> >> >
>> >> > Thanks,
>> >> > Sanne
>> >> >
>> >> >
>> >> > On 1 September 2017 at 19:11, Gail Badner 
>> wrote:
>> >> >> I have a better understanding after discussing further with Scott,
>> so I
>> >> >> agree with Steve now.
>> >> >>
>> >> >> I have some ideas about how to fix this.
>> >> >>
>> >> >> Sanne, you mentioned getting a failure using an integration test.
>> >> >> Please
>> >> >> provide details for reproducing this.
>> >> >>
>> >> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole <
>> st...@hibernate.org>
>> >> >> wrote:
>> >> >>>
>> >> >>> The whole purpose of ExtendedBeanManager is cases where the
>> >> >>> BeanManager is
>> >> >>> not available when Hibernate boots (in other words when Hibernate
>> is
>> >> >>> told
>> >> >>> which to use) .  This is a way to give Hibernate a callback when
>> the
>> >> >>> BeanManager is available.  IMO this ExtendedBeanManager
>> implementing
>> >> >>> BeanManager is inaccurate.  But would certainly like to hear
>> Scott's
>> >> >>> opinion
>> >> >>> as well.
>> >> >>>
>> >> >>> Technically this situation is non-JPA compliant as JPA requires
>> that
>> >> >>> the
>> >> >>> BeanManager passed to be available at boot-time.
>> >> >>>
>> >> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero <
>> sa...@hibernate.org>
>> >> >>> wrote:
>> >> 
>> >>  Hi Gail,
>> >> 
>> >>  no I haven't opened a WFLY issue as I'm not sure if this is an
>> issue.
>> >> 
>> >>  There seems to be some inconsistency and it certainly breaks some
>> >>  Hibernate Search tests but we could of course adapt things to the
>> new
>> >>  reality..  if this is how it's meant to be.
>> >> 
>> >>  The source code of the ExtendedBeanManager which you didn't find
>> is
>> >>  located in the WildFly source code; it's part of JipiJapa:
>> >>   -
>> >> 
>> >> 
>> https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java
>> >> 
>> >>  As you also noticed, it no longer implement the standard
>> BeanManager
>> >>  interface. I agree with you that I'd expect it to still implement
>> it,
>> >>  but clearly this was changed intentionally so I hope someone
>> (Scott
>> >>  possibly?) can clarify - or revert.
>> >> 
>> >>  In case this is intentionally no longer implementing the standard
>> >>  interface we should at least clarify the javadocs if this
>> >>  configuration property.
>> >> 
>> >>  The missing  javax.el.ELResolver and javax.el.ExpressionFactory is
>> >>  unfortunate. I'd hope we could do better than just add them back,
>> >>  maybe it requires a dedicated module? Having too many
>> dependencies -
>> >>  in this case half of Weld - slows down our bootstrap significantly
>> >>  and
>> >>  users have been complaining about that.
>> >> 
>> >>  Thanks,
>> >>  Sanne
>> >> 
>> >>  On 30 August 2017 at 06:58, Gail Badner 
>> wrote:
>> >>  > Hi Sanne,
>> >>  >
>> >>  > Do you have a WFLY

Re: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing

2017-09-07 Thread Gail Badner 
OK, sounds good. Did Steve suggest how to fix it in HSearch? If he didn't,
I have kind of a hacky idea.

On Thu, Sep 7, 2017 at 2:59 PM, Sanne Grinovero  wrote:

> On 7 September 2017 at 22:38, Gail Badner  wrote:
> > Are you saying that you don't need a fix for this?
>
> I'm going to need fixing the Hibernate Search code, but besides that
> yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa)
> nor Hibernate ORM.
>
> Thanks,
> Sanne
>
> >
> > On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero 
> > wrote:
> >>
> >> I had a chat with Steve about this and I understand better now why the
> >> WildFly/JipiJapa/HibernateORM does what it does.
> >>
> >> We'll update the Hibernate Search integration test and move on!
> >>
> >> Thanks,
> >> Sanne
> >>
> >>
> >> On 6 September 2017 at 22:19, Sanne Grinovero 
> wrote:
> >> > Hi Gail,
> >> >
> >> > the failing test is CDIInjectionIT from my personal branch of
> >> > Hibernate Search called "WildFly11" :
> >> >
> >> >
> >> > https://github.com/Sanne/hibernate-search/blob/
> WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/
> integration/wildfly/cdi/CDIInjectionIT.java
> >> >
> >> > It is an Arquillian test and it requires you to build Hibernate ORM
> >> > master first, as I switched the dependencies to use Hibernate ORM
> >> > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires
> >> > HHH-11950
> >> >
> >> > Thanks,
> >> > Sanne
> >> >
> >> >
> >> > On 1 September 2017 at 19:11, Gail Badner  wrote:
> >> >> I have a better understanding after discussing further with Scott,
> so I
> >> >> agree with Steve now.
> >> >>
> >> >> I have some ideas about how to fix this.
> >> >>
> >> >> Sanne, you mentioned getting a failure using an integration test.
> >> >> Please
> >> >> provide details for reproducing this.
> >> >>
> >> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole <
> st...@hibernate.org>
> >> >> wrote:
> >> >>>
> >> >>> The whole purpose of ExtendedBeanManager is cases where the
> >> >>> BeanManager is
> >> >>> not available when Hibernate boots (in other words when Hibernate is
> >> >>> told
> >> >>> which to use) .  This is a way to give Hibernate a callback when the
> >> >>> BeanManager is available.  IMO this ExtendedBeanManager implementing
> >> >>> BeanManager is inaccurate.  But would certainly like to hear Scott's
> >> >>> opinion
> >> >>> as well.
> >> >>>
> >> >>> Technically this situation is non-JPA compliant as JPA requires that
> >> >>> the
> >> >>> BeanManager passed to be available at boot-time.
> >> >>>
> >> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero <
> sa...@hibernate.org>
> >> >>> wrote:
> >> 
> >>  Hi Gail,
> >> 
> >>  no I haven't opened a WFLY issue as I'm not sure if this is an
> issue.
> >> 
> >>  There seems to be some inconsistency and it certainly breaks some
> >>  Hibernate Search tests but we could of course adapt things to the
> new
> >>  reality..  if this is how it's meant to be.
> >> 
> >>  The source code of the ExtendedBeanManager which you didn't find is
> >>  located in the WildFly source code; it's part of JipiJapa:
> >>   -
> >> 
> >>  https://github.com/wildfly/wildfly/blob/master/jpa/
> hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/
> HibernateExtendedBeanManager.java
> >> 
> >>  As you also noticed, it no longer implement the standard
> BeanManager
> >>  interface. I agree with you that I'd expect it to still implement
> it,
> >>  but clearly this was changed intentionally so I hope someone (Scott
> >>  possibly?) can clarify - or revert.
> >> 
> >>  In case this is intentionally no longer implementing the standard
> >>  interface we should at least clarify the javadocs if this
> >>  configuration property.
> >> 
> >>  The missing  javax.el.ELResolver and javax.el.ExpressionFactory is
> >>  unfortunate. I'd hope we could do better than just add them back,
> >>  maybe it requires a dedicated module? Having too many dependencies
> -
> >>  in this case half of Weld - slows down our bootstrap significantly
> >>  and
> >>  users have been complaining about that.
> >> 
> >>  Thanks,
> >>  Sanne
> >> 
> >>  On 30 August 2017 at 06:58, Gail Badner 
> wrote:
> >>  > Hi Sanne,
> >>  >
> >>  > Do you have a WFLY  issue for this?
> >>  >
> >>  > I've tentatively created a branch and pushed a commit to my fork
> >>  > that
> >>  > reproduces this issue. [1]
> >>  >
> >>  > It reproduces using Hibernate 5.1.11-SNAPSHOT and
> 5.2.11-SNAPSHOT.
> >>  >
> >>  > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest
> uses
> >>  > an
> >>  > implementation, ExtendedBeanManagerImpl [2], that implements both
> >>  > BeanManager,

Re: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing

2017-09-07 Thread Sanne Grinovero 
On 7 September 2017 at 22:38, Gail Badner  wrote:
> Are you saying that you don't need a fix for this?

I'm going to need fixing the Hibernate Search code, but besides that
yes I'm not needing (nor expecting) a fix in either WildFly (jipijapa)
nor Hibernate ORM.

Thanks,
Sanne

>
> On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero 
> wrote:
>>
>> I had a chat with Steve about this and I understand better now why the
>> WildFly/JipiJapa/HibernateORM does what it does.
>>
>> We'll update the Hibernate Search integration test and move on!
>>
>> Thanks,
>> Sanne
>>
>>
>> On 6 September 2017 at 22:19, Sanne Grinovero  wrote:
>> > Hi Gail,
>> >
>> > the failing test is CDIInjectionIT from my personal branch of
>> > Hibernate Search called "WildFly11" :
>> >
>> >
>> > https://github.com/Sanne/hibernate-search/blob/WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java
>> >
>> > It is an Arquillian test and it requires you to build Hibernate ORM
>> > master first, as I switched the dependencies to use Hibernate ORM
>> > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires
>> > HHH-11950
>> >
>> > Thanks,
>> > Sanne
>> >
>> >
>> > On 1 September 2017 at 19:11, Gail Badner  wrote:
>> >> I have a better understanding after discussing further with Scott, so I
>> >> agree with Steve now.
>> >>
>> >> I have some ideas about how to fix this.
>> >>
>> >> Sanne, you mentioned getting a failure using an integration test.
>> >> Please
>> >> provide details for reproducing this.
>> >>
>> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole 
>> >> wrote:
>> >>>
>> >>> The whole purpose of ExtendedBeanManager is cases where the
>> >>> BeanManager is
>> >>> not available when Hibernate boots (in other words when Hibernate is
>> >>> told
>> >>> which to use) .  This is a way to give Hibernate a callback when the
>> >>> BeanManager is available.  IMO this ExtendedBeanManager implementing
>> >>> BeanManager is inaccurate.  But would certainly like to hear Scott's
>> >>> opinion
>> >>> as well.
>> >>>
>> >>> Technically this situation is non-JPA compliant as JPA requires that
>> >>> the
>> >>> BeanManager passed to be available at boot-time.
>> >>>
>> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero 
>> >>> wrote:
>> 
>>  Hi Gail,
>> 
>>  no I haven't opened a WFLY issue as I'm not sure if this is an issue.
>> 
>>  There seems to be some inconsistency and it certainly breaks some
>>  Hibernate Search tests but we could of course adapt things to the new
>>  reality..  if this is how it's meant to be.
>> 
>>  The source code of the ExtendedBeanManager which you didn't find is
>>  located in the WildFly source code; it's part of JipiJapa:
>>   -
>> 
>>  https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java
>> 
>>  As you also noticed, it no longer implement the standard BeanManager
>>  interface. I agree with you that I'd expect it to still implement it,
>>  but clearly this was changed intentionally so I hope someone (Scott
>>  possibly?) can clarify - or revert.
>> 
>>  In case this is intentionally no longer implementing the standard
>>  interface we should at least clarify the javadocs if this
>>  configuration property.
>> 
>>  The missing  javax.el.ELResolver and javax.el.ExpressionFactory is
>>  unfortunate. I'd hope we could do better than just add them back,
>>  maybe it requires a dedicated module? Having too many dependencies -
>>  in this case half of Weld - slows down our bootstrap significantly
>>  and
>>  users have been complaining about that.
>> 
>>  Thanks,
>>  Sanne
>> 
>>  On 30 August 2017 at 06:58, Gail Badner  wrote:
>>  > Hi Sanne,
>>  >
>>  > Do you have a WFLY  issue for this?
>>  >
>>  > I've tentatively created a branch and pushed a commit to my fork
>>  > that
>>  > reproduces this issue. [1]
>>  >
>>  > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT.
>>  >
>>  > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses
>>  > an
>>  > implementation, ExtendedBeanManagerImpl [2], that implements both
>>  > BeanManager, ExtendedBeanManager.
>>  >
>>  > I don't see this test in 5.2, and I don't see any implementation of
>>  > ExtendedBeanManager in 5.2. I do see tests in
>>  > org.hibernate.jpa.test.cdi.extended, but have not had a chance to
>>  > look
>>  > at
>>  > those yet.
>>  >
>>  > I suspect that
>>  > org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager
>>  > should implement javax.enterprise.inject.spi.BeanManager as well. I
>>

Re: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing

2017-09-07 Thread Gail Badner 
Are you saying that you don't need a fix for this?

On Thu, Sep 7, 2017 at 10:36 AM, Sanne Grinovero 
wrote:

> I had a chat with Steve about this and I understand better now why the
> WildFly/JipiJapa/HibernateORM does what it does.
>
> We'll update the Hibernate Search integration test and move on!
>
> Thanks,
> Sanne
>
>
> On 6 September 2017 at 22:19, Sanne Grinovero  wrote:
> > Hi Gail,
> >
> > the failing test is CDIInjectionIT from my personal branch of
> > Hibernate Search called "WildFly11" :
> >
> > https://github.com/Sanne/hibernate-search/blob/
> WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/
> integration/wildfly/cdi/CDIInjectionIT.java
> >
> > It is an Arquillian test and it requires you to build Hibernate ORM
> > master first, as I switched the dependencies to use Hibernate ORM
> > 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires
> > HHH-11950
> >
> > Thanks,
> > Sanne
> >
> >
> > On 1 September 2017 at 19:11, Gail Badner  wrote:
> >> I have a better understanding after discussing further with Scott, so I
> >> agree with Steve now.
> >>
> >> I have some ideas about how to fix this.
> >>
> >> Sanne, you mentioned getting a failure using an integration test. Please
> >> provide details for reproducing this.
> >>
> >> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole 
> >> wrote:
> >>>
> >>> The whole purpose of ExtendedBeanManager is cases where the
> BeanManager is
> >>> not available when Hibernate boots (in other words when Hibernate is
> told
> >>> which to use) .  This is a way to give Hibernate a callback when the
> >>> BeanManager is available.  IMO this ExtendedBeanManager implementing
> >>> BeanManager is inaccurate.  But would certainly like to hear Scott's
> opinion
> >>> as well.
> >>>
> >>> Technically this situation is non-JPA compliant as JPA requires that
> the
> >>> BeanManager passed to be available at boot-time.
> >>>
> >>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero 
> >>> wrote:
> 
>  Hi Gail,
> 
>  no I haven't opened a WFLY issue as I'm not sure if this is an issue.
> 
>  There seems to be some inconsistency and it certainly breaks some
>  Hibernate Search tests but we could of course adapt things to the new
>  reality..  if this is how it's meant to be.
> 
>  The source code of the ExtendedBeanManager which you didn't find is
>  located in the WildFly source code; it's part of JipiJapa:
>   -
>  https://github.com/wildfly/wildfly/blob/master/jpa/
> hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/
> HibernateExtendedBeanManager.java
> 
>  As you also noticed, it no longer implement the standard BeanManager
>  interface. I agree with you that I'd expect it to still implement it,
>  but clearly this was changed intentionally so I hope someone (Scott
>  possibly?) can clarify - or revert.
> 
>  In case this is intentionally no longer implementing the standard
>  interface we should at least clarify the javadocs if this
>  configuration property.
> 
>  The missing  javax.el.ELResolver and javax.el.ExpressionFactory is
>  unfortunate. I'd hope we could do better than just add them back,
>  maybe it requires a dedicated module? Having too many dependencies -
>  in this case half of Weld - slows down our bootstrap significantly and
>  users have been complaining about that.
> 
>  Thanks,
>  Sanne
> 
>  On 30 August 2017 at 06:58, Gail Badner  wrote:
>  > Hi Sanne,
>  >
>  > Do you have a WFLY  issue for this?
>  >
>  > I've tentatively created a branch and pushed a commit to my fork
> that
>  > reproduces this issue. [1]
>  >
>  > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT.
>  >
>  > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses
> an
>  > implementation, ExtendedBeanManagerImpl [2], that implements both
>  > BeanManager, ExtendedBeanManager.
>  >
>  > I don't see this test in 5.2, and I don't see any implementation of
>  > ExtendedBeanManager in 5.2. I do see tests in
>  > org.hibernate.jpa.test.cdi.extended, but have not had a chance to
> look
>  > at
>  > those yet.
>  >
>  > I suspect that org.jboss.as.jpa.hibernate5.
> HibernateExtendedBeanManager
>  > should implement javax.enterprise.inject.spi.BeanManager as well. I
>  > tried
>  > making this change, and having BeanManager methods delegate to
>  > HibernateExtendedBeanManager#beanManager, but it looks like a
>  > dependency is
>  > missing, because javax.el.ELResolver and javax.el.ExpressionFactory
> are
>  > unresolved.
>  >
>  > Please let me know if I'm on the right (or wrong) track. I'll pick
> this
>  > up
>  > tomorrow.
>  >
>  >

Re: [hibernate-dev] CDI / ORM / WildFly / Search integration plumbing

2017-09-07 Thread Sanne Grinovero 
I had a chat with Steve about this and I understand better now why the
WildFly/JipiJapa/HibernateORM does what it does.

We'll update the Hibernate Search integration test and move on!

Thanks,
Sanne


On 6 September 2017 at 22:19, Sanne Grinovero  wrote:
> Hi Gail,
>
> the failing test is CDIInjectionIT from my personal branch of
> Hibernate Search called "WildFly11" :
>
> https://github.com/Sanne/hibernate-search/blob/WildFly11/integrationtest/wildfly/src/test/java/org/hibernate/search/test/integration/wildfly/cdi/CDIInjectionIT.java
>
> It is an Arquillian test and it requires you to build Hibernate ORM
> master first, as I switched the dependencies to use Hibernate ORM
> 5.2.11-SNAPSHOT (It otherwise won't work on WildFly 11 as it requires
> HHH-11950
>
> Thanks,
> Sanne
>
>
> On 1 September 2017 at 19:11, Gail Badner  wrote:
>> I have a better understanding after discussing further with Scott, so I
>> agree with Steve now.
>>
>> I have some ideas about how to fix this.
>>
>> Sanne, you mentioned getting a failure using an integration test. Please
>> provide details for reproducing this.
>>
>> On Wed, Aug 30, 2017 at 11:43 AM, Steve Ebersole 
>> wrote:
>>>
>>> The whole purpose of ExtendedBeanManager is cases where the BeanManager is
>>> not available when Hibernate boots (in other words when Hibernate is told
>>> which to use) .  This is a way to give Hibernate a callback when the
>>> BeanManager is available.  IMO this ExtendedBeanManager implementing
>>> BeanManager is inaccurate.  But would certainly like to hear Scott's opinion
>>> as well.
>>>
>>> Technically this situation is non-JPA compliant as JPA requires that the
>>> BeanManager passed to be available at boot-time.
>>>
>>> On Wed, Aug 30, 2017 at 12:02 PM Sanne Grinovero 
>>> wrote:

 Hi Gail,

 no I haven't opened a WFLY issue as I'm not sure if this is an issue.

 There seems to be some inconsistency and it certainly breaks some
 Hibernate Search tests but we could of course adapt things to the new
 reality..  if this is how it's meant to be.

 The source code of the ExtendedBeanManager which you didn't find is
 located in the WildFly source code; it's part of JipiJapa:
  -
 https://github.com/wildfly/wildfly/blob/master/jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/HibernateExtendedBeanManager.java

 As you also noticed, it no longer implement the standard BeanManager
 interface. I agree with you that I'd expect it to still implement it,
 but clearly this was changed intentionally so I hope someone (Scott
 possibly?) can clarify - or revert.

 In case this is intentionally no longer implementing the standard
 interface we should at least clarify the javadocs if this
 configuration property.

 The missing  javax.el.ELResolver and javax.el.ExpressionFactory is
 unfortunate. I'd hope we could do better than just add them back,
 maybe it requires a dedicated module? Having too many dependencies -
 in this case half of Weld - slows down our bootstrap significantly and
 users have been complaining about that.

 Thanks,
 Sanne

 On 30 August 2017 at 06:58, Gail Badner  wrote:
 > Hi Sanne,
 >
 > Do you have a WFLY  issue for this?
 >
 > I've tentatively created a branch and pushed a commit to my fork that
 > reproduces this issue. [1]
 >
 > It reproduces using Hibernate 5.1.11-SNAPSHOT and 5.2.11-SNAPSHOT.
 >
 > In 5.1, org.hibernate.jpa.test.cdi.ExtendedBeanManagerCdiTest uses an
 > implementation, ExtendedBeanManagerImpl [2], that implements both
 > BeanManager, ExtendedBeanManager.
 >
 > I don't see this test in 5.2, and I don't see any implementation of
 > ExtendedBeanManager in 5.2. I do see tests in
 > org.hibernate.jpa.test.cdi.extended, but have not had a chance to look
 > at
 > those yet.
 >
 > I suspect that org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager
 > should implement javax.enterprise.inject.spi.BeanManager as well. I
 > tried
 > making this change, and having BeanManager methods delegate to
 > HibernateExtendedBeanManager#beanManager, but it looks like a
 > dependency is
 > missing, because javax.el.ELResolver and javax.el.ExpressionFactory are
 > unresolved.
 >
 > Please let me know if I'm on the right (or wrong) track. I'll pick this
 > up
 > tomorrow.
 >
 > Regards,
 > Gail
 >
 > [1] https://github.com/gbadner/wildfly/tree/WFLY-CCE-bug
 > [2]
 >
 > https://github.com/hibernate/hibernate-orm/blob/5.1/hibernate-entitymanager/src/test/java/org/hibernate/jpa/test/cdi/ExtendedBeanManagerCdiTest.java#L195
 >
 > On Tue, Aug 29, 2017 at 8:18 AM, Sanne Grinovero 
 > wrote:
 >>
 >> Hi all,

Re: [hibernate-dev] Moving Java Forward Faster

2017-09-07 Thread Rory O'Donnell 
Hi Sanne,

Please do share your thoughts on the OpenJDK mailing list.

Rgds,Rory

On 07/09/2017 11:22, Sanne Grinovero wrote:
> Hi Rory,
>
> thank you very much for this heads up! Opening up the build-and-test
> infrastructure and the commercial components sounds like an amazing
> development.
>
> Some early thoughts. The methodology of faster release cycles is very
> welcome, yet the proposed versioning I saw mentioned on twitter to be
> "year based" is a bit puzzling: in our experience it's nice to be able
> to clearly differentiate a non-backwards compatible version from a
> backwards compatible version, and yet be in control of when an
> "incompatibility event" happens: that can't be time boxed as generally
> we all try to avoid it but sometimes innovation requires to.
>
> I guess we could agree that technically no changed software is fully
> backwards compatible from all perspectives, but people are aware of
> this and yet benefit from knowing the maintainer's intent. This seems
> to map to the "long term support" editions but then those LTS versions
> only become the "version" in people's perspective. Specifically my
> concern would be that different versions would be perceived as a
> significant migration risk even though such an update might be
> relatively much simpler than others. It's possible that in practice
> Java 10 already had some breaking changes planned so this concern
> wouldn't apply right now, but with such numbering you'll never be able
> to benefit from it even in future releases.
> I'd welcome faster innovation cycles but libraries like Hibernate
> can't drop support for JVMs still largely in use, so unless people get
> comfortable in adopting new JVM versions by removing any such mental
> barriers we won't be able to adopt new versions as fast as we'd all
> like. On the other hand if the suggestion is that libraries should
> generally target "long term support" platforms, then it becomes
> painfully slow: as in other OSS projects - like Fedora - practical
> needs dictate that you at least support the two latest platforms so
> that would force us to support 6+ years old JVMs and slow innovation
> down rather than speeding it up. (Fedora supports the last two
> releases but a new release appears every 6 months).
>
> We'll think about this in the team and see if it's worth sharing some
> more thoughts on the OpenJDK mailing list.
>
> Regards,
> Sanne
>
>
>
> On 7 September 2017 at 10:35, Rory O'Donnell  wrote:
>> Hi Sanne,
>>
>> Oracle is proposing a rapid release model for Java SE going-forward.
>>
>> The high points are highlighted below, details of the changes can be
>> found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2].
>>
>> Under the proposed release model, after JDK 9, we will adopt a strict,
>> time-based model with a new major release every six months, update
>> releases every quarter, and a long-term support release every three years.
>>
>> The new JDK Project will run a bit differently than the past "JDK $N"
>> Projects:
>>
>> - The main development line will always be open but fixes, enhancements,
>> and features will be merged only when they're nearly finished. The main
>> line will be Feature Complete [3] at all times.
>>
>> - We'll continue to use the JEP Process [4] for new features and other
>> significant changes. The bar to target a JEP to a specific release will,
>> however, be higher since the work must be Feature Complete in order to
>> go in. Owners of large or risky features will be strongly encouraged to
>> split such features up into smaller and safer parts, to integrate
>> earlier in the release cycle, and to publish separate lines of
>> early-access builds prior to integration.
>>
>> The JDK Updates Project will run in much the same way as the past "JDK
>> $N" Updates Projects, though update releases will be strictly limited to
>> fixes of security issues, regressions, and bugs in newer features.
>>
>> Related to this proposal, we intend to make a few changes in what we do:
>>
>> - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to
>> make it easier for developers to deploy Java applications to cloud
>> environments. We'll initially publish OpenJDK builds for Linux/x64,
>> followed later by builds for macOS/x64 and Windows/x64.
>>
>> - We'll continue to ship proprietary "Oracle JDK" builds, which include
>> "commercial features" [6] such as Java Flight Recorder and Mission
>> Control [7], under a click-through binary-code license [8]. Oracle will
>> continue to offer paid support for these builds.
>>
>> - After JDK 9 we'll open-source the commercial features in order to make
>> the OpenJDK builds more attractive to developers and to reduce the
>> differences between those builds and the Oracle JDK. This will take some
>> time, but the ultimate goal is to make OpenJDK and Oracle JDK builds
>> completely interchangeable.
>>
>> - Finally, for the long term we'll work with other OpenJDK

Re: [hibernate-dev] Moving Java Forward Faster

2017-09-07 Thread Sanne Grinovero 
Hi Rory,

thank you very much for this heads up! Opening up the build-and-test
infrastructure and the commercial components sounds like an amazing
development.

Some early thoughts. The methodology of faster release cycles is very
welcome, yet the proposed versioning I saw mentioned on twitter to be
"year based" is a bit puzzling: in our experience it's nice to be able
to clearly differentiate a non-backwards compatible version from a
backwards compatible version, and yet be in control of when an
"incompatibility event" happens: that can't be time boxed as generally
we all try to avoid it but sometimes innovation requires to.

I guess we could agree that technically no changed software is fully
backwards compatible from all perspectives, but people are aware of
this and yet benefit from knowing the maintainer's intent. This seems
to map to the "long term support" editions but then those LTS versions
only become the "version" in people's perspective. Specifically my
concern would be that different versions would be perceived as a
significant migration risk even though such an update might be
relatively much simpler than others. It's possible that in practice
Java 10 already had some breaking changes planned so this concern
wouldn't apply right now, but with such numbering you'll never be able
to benefit from it even in future releases.
I'd welcome faster innovation cycles but libraries like Hibernate
can't drop support for JVMs still largely in use, so unless people get
comfortable in adopting new JVM versions by removing any such mental
barriers we won't be able to adopt new versions as fast as we'd all
like. On the other hand if the suggestion is that libraries should
generally target "long term support" platforms, then it becomes
painfully slow: as in other OSS projects - like Fedora - practical
needs dictate that you at least support the two latest platforms so
that would force us to support 6+ years old JVMs and slow innovation
down rather than speeding it up. (Fedora supports the last two
releases but a new release appears every 6 months).

We'll think about this in the team and see if it's worth sharing some
more thoughts on the OpenJDK mailing list.

Regards,
Sanne



On 7 September 2017 at 10:35, Rory O'Donnell  wrote:
> Hi Sanne,
>
> Oracle is proposing a rapid release model for Java SE going-forward.
>
> The high points are highlighted below, details of the changes can be
> found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2].
>
> Under the proposed release model, after JDK 9, we will adopt a strict,
> time-based model with a new major release every six months, update
> releases every quarter, and a long-term support release every three years.
>
> The new JDK Project will run a bit differently than the past "JDK $N"
> Projects:
>
> - The main development line will always be open but fixes, enhancements,
> and features will be merged only when they're nearly finished. The main
> line will be Feature Complete [3] at all times.
>
> - We'll continue to use the JEP Process [4] for new features and other
> significant changes. The bar to target a JEP to a specific release will,
> however, be higher since the work must be Feature Complete in order to
> go in. Owners of large or risky features will be strongly encouraged to
> split such features up into smaller and safer parts, to integrate
> earlier in the release cycle, and to publish separate lines of
> early-access builds prior to integration.
>
> The JDK Updates Project will run in much the same way as the past "JDK
> $N" Updates Projects, though update releases will be strictly limited to
> fixes of security issues, regressions, and bugs in newer features.
>
> Related to this proposal, we intend to make a few changes in what we do:
>
> - Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to
> make it easier for developers to deploy Java applications to cloud
> environments. We'll initially publish OpenJDK builds for Linux/x64,
> followed later by builds for macOS/x64 and Windows/x64.
>
> - We'll continue to ship proprietary "Oracle JDK" builds, which include
> "commercial features" [6] such as Java Flight Recorder and Mission
> Control [7], under a click-through binary-code license [8]. Oracle will
> continue to offer paid support for these builds.
>
> - After JDK 9 we'll open-source the commercial features in order to make
> the OpenJDK builds more attractive to developers and to reduce the
> differences between those builds and the Oracle JDK. This will take some
> time, but the ultimate goal is to make OpenJDK and Oracle JDK builds
> completely interchangeable.
>
> - Finally, for the long term we'll work with other OpenJDK contributors
> to establish an open build-and-test infrastructure. This will make it
> easier to publish early-access builds for features in development, and
> eventually make it possible for the OpenJDK Community itself to publish
> authoritative builds of the JDK.
>
>

[hibernate-dev] Moving Java Forward Faster

2017-09-07 Thread Rory O'Donnell 
Hi Sanne,

Oracle is proposing a rapid release model for Java SE going-forward.

The high points are highlighted below, details of the changes can be 
found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2].

Under the proposed release model, after JDK 9, we will adopt a strict, 
time-based model with a new major release every six months, update 
releases every quarter, and a long-term support release every three years.

The new JDK Project will run a bit differently than the past "JDK $N" 
Projects:

- The main development line will always be open but fixes, enhancements, 
and features will be merged only when they're nearly finished. The main 
line will be Feature Complete [3] at all times.

- We'll continue to use the JEP Process [4] for new features and other 
significant changes. The bar to target a JEP to a specific release will, 
however, be higher since the work must be Feature Complete in order to 
go in. Owners of large or risky features will be strongly encouraged to 
split such features up into smaller and safer parts, to integrate 
earlier in the release cycle, and to publish separate lines of 
early-access builds prior to integration.

The JDK Updates Project will run in much the same way as the past "JDK 
$N" Updates Projects, though update releases will be strictly limited to 
fixes of security issues, regressions, and bugs in newer features.

Related to this proposal, we intend to make a few changes in what we do:

- Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to 
make it easier for developers to deploy Java applications to cloud 
environments. We'll initially publish OpenJDK builds for Linux/x64, 
followed later by builds for macOS/x64 and Windows/x64.

- We'll continue to ship proprietary "Oracle JDK" builds, which include 
"commercial features" [6] such as Java Flight Recorder and Mission 
Control [7], under a click-through binary-code license [8]. Oracle will 
continue to offer paid support for these builds.

- After JDK 9 we'll open-source the commercial features in order to make 
the OpenJDK builds more attractive to developers and to reduce the 
differences between those builds and the Oracle JDK. This will take some 
time, but the ultimate goal is to make OpenJDK and Oracle JDK builds 
completely interchangeable.

- Finally, for the long term we'll work with other OpenJDK contributors 
to establish an open build-and-test infrastructure. This will make it 
easier to publish early-access builds for features in development, and 
eventually make it possible for the OpenJDK Community itself to publish 
authoritative builds of the JDK.

Questions , comments, feedback to OpenJDK discuss mailing list [2]

Rgds,Rory

[1]https://mreinhold.org/blog/forward-faster
[2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
[3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
[4]http://openjdk.java.net/jeps/0
[5]http://openjdk.java.net/legal/gplv2+ce.html
[6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html
[7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
[8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html

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