From mkouba at redhat.com  Thu Sep  1 05:05:16 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 1 Sep 2016 11:05:16 +0200
Subject: [weld-dev] Requesting comment on WELD-2062
In-Reply-To: <OFBBB712F0.9846A31D-ON0025801A.0056B700-8025801A.0056C4C8@notes.na.collabserv.com>
References: <OF20852869.9DFA7A9F-ON0025801A.004ACA9A-8025801A.004B41B3@notes.na.collabserv.com>
	<1a1ca939-dd4a-2df0-61b9-7bef53a72285@redhat.com>
	<OFBBB712F0.9846A31D-ON0025801A.0056B700-8025801A.0056C4C8@notes.na.collabserv.com>
Message-ID: <44d56df9-b192-8e66-1b21-e21455d86766@redhat.com>

Hi guys,

we've prepared PRs for Weld API [1] and implementation [2]. It would be 
great if you could look at it and tell us whether it makes sense for 
your particular use case.

Thanks,

Martin

[1]
https://github.com/weld/api/pull/45

[2]
https://github.com/weld/core/pull/1467

Dne 25.8.2016 v 17:47 Benjamin Confino napsal(a):
> Thanks Martin
>
> I hope your prototype works well.
>
> Regards
> Benjamin
>
>
>
> From:        Martin Kouba <mkouba at redhat.com>
> To:        Benjamin Confino/UK/IBM at IBMGB, weld-dev at lists.jboss.org,
> Cc:        Tom Evans/UK/IBM at IBMGB
> Date:        25/08/2016 15:52
> Subject:        Re: [weld-dev] Requesting comment on WELD-2062
> ------------------------------------------------------------------------
>
>
>
> Hi Benjamin,
>
> I've added a comment to the issue.
>
> Thanks,
>
> Martin
>
> Dne 25.8.2016 v 15:42 Benjamin Confino napsal(a):
>> Hello
>>
>> A while back this issue was raised:
>> https://issues.jboss.org/browse/WELD-2062
>>
>> I have recently encountered a similar issue in which an update to a
>> servlet does not take effect.
>>
>> I have verified the solution proposed in WELD-2062 manually. By using my
>> eclipse debugger I was able to modify a variable and force
>> AnnotatedTypeIdentifier.equals() to return false, this resolved the issue.
>>
>> My questions is, does AnnotatedTypeIdentifier.equals() need to be
>> modified to use the class instead of the className as suggested in
>> WELD-2062 or is this an integration issue where websphere has failed to
>> provide the required information?
>>
>>
>> Regards
>> Benjamin
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From BENJAMIC at uk.ibm.com  Thu Sep  1 17:30:04 2016
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Thu, 1 Sep 2016 22:30:04 +0100
Subject: [weld-dev] Requesting comment on WELD-2062
In-Reply-To: <44d56df9-b192-8e66-1b21-e21455d86766@redhat.com>
References: <OF20852869.9DFA7A9F-ON0025801A.004ACA9A-8025801A.004B41B3@notes.na.collabserv.com>
	<1a1ca939-dd4a-2df0-61b9-7bef53a72285@redhat.com>
	<OFBBB712F0.9846A31D-ON0025801A.0056B700-8025801A.0056C4C8@notes.na.collabserv.com>
	<44d56df9-b192-8e66-1b21-e21455d86766@redhat.com>
Message-ID: <OF8D8657BF.23EBC38D-ON00258021.00760AB7-80258021.00761C5C@notes.na.collabserv.com>

Hello Martin

Thanks for creating this. I'm out of the office tomorrow but will try to 
test this as soon as I can. 

Regards
Benjamin



From:   Martin Kouba <mkouba at redhat.com>
To:     Benjamin Confino/UK/IBM at IBMGB, 
Cc:     Tom Evans/UK/IBM at IBMGB, weld-dev at lists.jboss.org
Date:   01/09/2016 10:05
Subject:        Re: [weld-dev] Requesting comment on WELD-2062



Hi guys,

we've prepared PRs for Weld API [1] and implementation [2]. It would be 
great if you could look at it and tell us whether it makes sense for 
your particular use case.

Thanks,

Martin

[1]
https://github.com/weld/api/pull/45

[2]
https://github.com/weld/core/pull/1467

Dne 25.8.2016 v 17:47 Benjamin Confino napsal(a):
> Thanks Martin
>
> I hope your prototype works well.
>
> Regards
> Benjamin
>
>
>
> From:        Martin Kouba <mkouba at redhat.com>
> To:        Benjamin Confino/UK/IBM at IBMGB, weld-dev at lists.jboss.org,
> Cc:        Tom Evans/UK/IBM at IBMGB
> Date:        25/08/2016 15:52
> Subject:        Re: [weld-dev] Requesting comment on WELD-2062
> ------------------------------------------------------------------------
>
>
>
> Hi Benjamin,
>
> I've added a comment to the issue.
>
> Thanks,
>
> Martin
>
> Dne 25.8.2016 v 15:42 Benjamin Confino napsal(a):
>> Hello
>>
>> A while back this issue was raised:
>> https://issues.jboss.org/browse/WELD-2062
>>
>> I have recently encountered a similar issue in which an update to a
>> servlet does not take effect.
>>
>> I have verified the solution proposed in WELD-2062 manually. By using 
my
>> eclipse debugger I was able to modify a variable and force
>> AnnotatedTypeIdentifier.equals() to return false, this resolved the 
issue.
>>
>> My questions is, does AnnotatedTypeIdentifier.equals() need to be
>> modified to use the class instead of the className as suggested in
>> WELD-2062 or is this an integration issue where websphere has failed to
>> provide the required information?
>>
>>
>> Regards
>> Benjamin
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with 
number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20160901/5e6f5418/attachment-0001.html 

From mkouba at redhat.com  Tue Sep 13 08:18:34 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 13 Sep 2016 14:18:34 +0200
Subject: [weld-dev] Weld 2.4.0.Final released
Message-ID: <bd445a2c-5eaa-4c2b-f2f3-0a05b89b01b6@redhat.com>

http://weld.cdi-spec.org/news/2016/09/13/weld-240Final/

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From arjan.tijms at gmail.com  Wed Sep 14 13:14:11 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Wed, 14 Sep 2016 19:14:11 +0200
Subject: [weld-dev] Not possible to destroy normal scoped beans returned by
	producer method
Message-ID: <CAE=-AhCVcRxNKahBb30d5Td8hy95ezCS4dxtS43eMCdm=6zV8w@mail.gmail.com>

Hi,

I have a simple producer:

@Produced
@SessionScoped
public void Foo getFoo() { return new Foo());

If I subsequently want to destroy the Bean using:

Set<Bean<?>> beans = beanManager.getBeans(Foo.class);

Bean<?> bean = (Bean<T>) beanManager.resolve(beans);
Context context = beanManager.getContext(bean.getScope());

((AlterableContext) context).destroy(bean);

Then in Weld 2.3.2 the destroy method of the super class
of org.jboss.weld.context.http.HttpSessionContextImpl is called:

org.jboss.weld.context.AbstractContext

Containing this code:

    @Override
    public void destroy(Contextual<?> contextual) {
        if (!isActive()) {
            throw new ContextNotActiveException();
        }
        checkContextInitialized();
        if (contextual == null) {
            throw ContextLogger.LOG.contextualIsNull();
        }
        final BeanStore beanStore = getBeanStore();
        if (beanStore == null) {
            throw ContextLogger.LOG.noBeanStoreAvailable(this);
        }
        BeanIdentifier id = getId(contextual);
        ContextualInstance<?> beanInstance = beanStore.remove(id);
        if (beanInstance != null) {
            RequestScopedCache.invalidate();
            destroyContextualInstance(beanInstance);
        }
    }

Now the getBeanStore() method
(from org.jboss.weld.context.AbstractBoundContext) returns an
org.jboss.weld.context.beanstore.http.LazySessionBeanStore and this bean
store does *not* contain the Foo bean (no key for its BeanIdentifier).
There are other session scoped beans there that have been instantiated for
the test, but Foo is missing.

If subsequently the session is destroyed, the same destroy method is called
on the org.jboss.weld.context.http.HttpSessionContextImpl eventually, but
now the getBeanStore() method returns
an org.jboss.weld.context.beanstore.http.EagerSessionBeanStore, and this
one *does* contain the Foo bean.

The other beans that the EagerSessionBeanStore contain are equal to the
ones in the LazySessionBeanStore, the only difference is the Foo bean.

Is this a bug in Weld or am I doing something wrong?

Kind regards,
Arjan Tijms
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20160914/2a00ce93/attachment.html 

From mkouba at redhat.com  Thu Sep 15 02:48:20 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 15 Sep 2016 08:48:20 +0200
Subject: [weld-dev] Not possible to destroy normal scoped beans returned
 by producer method
In-Reply-To: <CAE=-AhCVcRxNKahBb30d5Td8hy95ezCS4dxtS43eMCdm=6zV8w@mail.gmail.com>
References: <CAE=-AhCVcRxNKahBb30d5Td8hy95ezCS4dxtS43eMCdm=6zV8w@mail.gmail.com>
Message-ID: <e211f659-f601-cb9c-3886-f3b806cc16b4@redhat.com>

Hi Arjan,

a simple reproducer would be helpful. There are few edge cases around 
session context and HTTP session which are problematic (e.g. 
HttpSession.invalidate()).

Do you call some method on the produced Foo before you call destroy? 
Because in Weld, normal scoped instances are created lazily and so does 
the HTTP session in case of @SessionScoped.

Thanks,

Martin

Dne 14.9.2016 v 19:14 arjan tijms napsal(a):
> Hi,
>
> I have a simple producer:
>
> @Produced
> @SessionScoped
> public void Foo getFoo() { return new Foo());
>
> If I subsequently want to destroy the Bean using:
>
> Set<Bean<?>> beans = beanManager.getBeans(Foo.class);
>
> Bean<?> bean = (Bean<T>) beanManager.resolve(beans);
> Context context = beanManager.getContext(bean.getScope());
>
> ((AlterableContext) context).destroy(bean);
>
> Then in Weld 2.3.2 the destroy method of the super class
> of org.jboss.weld.context.http.HttpSessionContextImpl is called:
>
> org.jboss.weld.context.AbstractContext
>
> Containing this code:
>
>     @Override
>     public void destroy(Contextual<?> contextual) {
>         if (!isActive()) {
>             throw new ContextNotActiveException();
>         }
>         checkContextInitialized();
>         if (contextual == null) {
>             throw ContextLogger.LOG.contextualIsNull();
>         }
>         final BeanStore beanStore = getBeanStore();
>         if (beanStore == null) {
>             throw ContextLogger.LOG.noBeanStoreAvailable(this);
>         }
>         BeanIdentifier id = getId(contextual);
>         ContextualInstance<?> beanInstance = beanStore.remove(id);
>         if (beanInstance != null) {
>             RequestScopedCache.invalidate();
>             destroyContextualInstance(beanInstance);
>         }
>     }
>
> Now the getBeanStore() method
> (from org.jboss.weld.context.AbstractBoundContext) returns an
> org.jboss.weld.context.beanstore.http.LazySessionBeanStore and this bean
> store does *not* contain the Foo bean (no key for its BeanIdentifier).
> There are other session scoped beans there that have been instantiated
> for the test, but Foo is missing.
>
> If subsequently the session is destroyed, the same destroy method is
> called on the
> org.jboss.weld.context.http.HttpSessionContextImpl eventually, but now
> the getBeanStore() method returns
> an org.jboss.weld.context.beanstore.http.EagerSessionBeanStore, and this
> one *does* contain the Foo bean.
>
> The other beans that the EagerSessionBeanStore contain are equal to the
> ones in the LazySessionBeanStore, the only difference is the Foo bean.
>
> Is this a bug in Weld or am I doing something wrong?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>

From arjan.tijms at gmail.com  Thu Sep 15 02:59:45 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 15 Sep 2016 08:59:45 +0200
Subject: [weld-dev] Not possible to destroy normal scoped beans returned
 by producer method
In-Reply-To: <e211f659-f601-cb9c-3886-f3b806cc16b4@redhat.com>
References: <CAE=-AhCVcRxNKahBb30d5Td8hy95ezCS4dxtS43eMCdm=6zV8w@mail.gmail.com>
	<e211f659-f601-cb9c-3886-f3b806cc16b4@redhat.com>
Message-ID: <CAE=-AhCwvpOeA6v4RuGbNk1Wabze5L8nOAQq4jPz9iUybBnZmg@mail.gmail.com>

Hi,

The produced Foo should have been used before it's destroyed, but I'll
double check it's also used right before the destroy method is called in
the same thread. I'll try to make a simple reproducer as well if it still
doesn't work correctly then.

Kind regards,
Arjan Tijms

On Thu, Sep 15, 2016 at 8:48 AM, Martin Kouba <mkouba at redhat.com> wrote:

> Hi Arjan,
>
> a simple reproducer would be helpful. There are few edge cases around
> session context and HTTP session which are problematic (e.g.
> HttpSession.invalidate()).
>
> Do you call some method on the produced Foo before you call destroy?
> Because in Weld, normal scoped instances are created lazily and so does the
> HTTP session in case of @SessionScoped.
>
> Thanks,
>
> Martin
>
> Dne 14.9.2016 v 19:14 arjan tijms napsal(a):
>
>> Hi,
>>
>> I have a simple producer:
>>
>> @Produced
>> @SessionScoped
>> public void Foo getFoo() { return new Foo());
>>
>> If I subsequently want to destroy the Bean using:
>>
>> Set<Bean<?>> beans = beanManager.getBeans(Foo.class);
>>
>> Bean<?> bean = (Bean<T>) beanManager.resolve(beans);
>> Context context = beanManager.getContext(bean.getScope());
>>
>> ((AlterableContext) context).destroy(bean);
>>
>> Then in Weld 2.3.2 the destroy method of the super class
>> of org.jboss.weld.context.http.HttpSessionContextImpl is called:
>>
>> org.jboss.weld.context.AbstractContext
>>
>> Containing this code:
>>
>>     @Override
>>     public void destroy(Contextual<?> contextual) {
>>         if (!isActive()) {
>>             throw new ContextNotActiveException();
>>         }
>>         checkContextInitialized();
>>         if (contextual == null) {
>>             throw ContextLogger.LOG.contextualIsNull();
>>         }
>>         final BeanStore beanStore = getBeanStore();
>>         if (beanStore == null) {
>>             throw ContextLogger.LOG.noBeanStoreAvailable(this);
>>         }
>>         BeanIdentifier id = getId(contextual);
>>         ContextualInstance<?> beanInstance = beanStore.remove(id);
>>         if (beanInstance != null) {
>>             RequestScopedCache.invalidate();
>>             destroyContextualInstance(beanInstance);
>>         }
>>     }
>>
>> Now the getBeanStore() method
>> (from org.jboss.weld.context.AbstractBoundContext) returns an
>> org.jboss.weld.context.beanstore.http.LazySessionBeanStore and this bean
>> store does *not* contain the Foo bean (no key for its BeanIdentifier).
>> There are other session scoped beans there that have been instantiated
>> for the test, but Foo is missing.
>>
>> If subsequently the session is destroyed, the same destroy method is
>> called on the
>> org.jboss.weld.context.http.HttpSessionContextImpl eventually, but now
>> the getBeanStore() method returns
>> an org.jboss.weld.context.beanstore.http.EagerSessionBeanStore, and this
>> one *does* contain the Foo bean.
>>
>> The other beans that the EagerSessionBeanStore contain are equal to the
>> ones in the LazySessionBeanStore, the only difference is the Foo bean.
>>
>> Is this a bug in Weld or am I doing something wrong?
>>
>> Kind regards,
>> Arjan Tijms
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20160915/74ca151b/attachment.html 

From arjan.tijms at gmail.com  Thu Sep 15 05:58:43 2016
From: arjan.tijms at gmail.com (arjan tijms)
Date: Thu, 15 Sep 2016 11:58:43 +0200
Subject: [weld-dev] Not possible to destroy normal scoped beans returned
 by producer method
In-Reply-To: <CAE=-AhCwvpOeA6v4RuGbNk1Wabze5L8nOAQq4jPz9iUybBnZmg@mail.gmail.com>
References: <CAE=-AhCVcRxNKahBb30d5Td8hy95ezCS4dxtS43eMCdm=6zV8w@mail.gmail.com>
	<e211f659-f601-cb9c-3886-f3b806cc16b4@redhat.com>
	<CAE=-AhCwvpOeA6v4RuGbNk1Wabze5L8nOAQq4jPz9iUybBnZmg@mail.gmail.com>
Message-ID: <CAE=-AhCSCF-Gc19FzKo=urZxgUMU9Pb00mOQiY3H9=kjwYXpRQ@mail.gmail.com>

Hi,

Just a quick follow up, it seems that if the bean is touched in 1 request
(so it's actually constructed and in the "global" bean store for the
session), then destroyed in another request within the same session that
hasn't touched the bean it fails.

But like you said, if the bean is touched within the same request (e.g.
@Inject Foo foo; ... foo.toString();) then destroying it works.

I'm not sure, do you think this is a bug, a spec issue, or "just the way
things are"?

Kind regards,
Arjan Tijms




On Thu, Sep 15, 2016 at 8:59 AM, arjan tijms <arjan.tijms at gmail.com> wrote:

> Hi,
>
> The produced Foo should have been used before it's destroyed, but I'll
> double check it's also used right before the destroy method is called in
> the same thread. I'll try to make a simple reproducer as well if it still
> doesn't work correctly then.
>
> Kind regards,
> Arjan Tijms
>
> On Thu, Sep 15, 2016 at 8:48 AM, Martin Kouba <mkouba at redhat.com> wrote:
>
>> Hi Arjan,
>>
>> a simple reproducer would be helpful. There are few edge cases around
>> session context and HTTP session which are problematic (e.g.
>> HttpSession.invalidate()).
>>
>> Do you call some method on the produced Foo before you call destroy?
>> Because in Weld, normal scoped instances are created lazily and so does the
>> HTTP session in case of @SessionScoped.
>>
>> Thanks,
>>
>> Martin
>>
>> Dne 14.9.2016 v 19:14 arjan tijms napsal(a):
>>
>>> Hi,
>>>
>>> I have a simple producer:
>>>
>>> @Produced
>>> @SessionScoped
>>> public void Foo getFoo() { return new Foo());
>>>
>>> If I subsequently want to destroy the Bean using:
>>>
>>> Set<Bean<?>> beans = beanManager.getBeans(Foo.class);
>>>
>>> Bean<?> bean = (Bean<T>) beanManager.resolve(beans);
>>> Context context = beanManager.getContext(bean.getScope());
>>>
>>> ((AlterableContext) context).destroy(bean);
>>>
>>> Then in Weld 2.3.2 the destroy method of the super class
>>> of org.jboss.weld.context.http.HttpSessionContextImpl is called:
>>>
>>> org.jboss.weld.context.AbstractContext
>>>
>>> Containing this code:
>>>
>>>     @Override
>>>     public void destroy(Contextual<?> contextual) {
>>>         if (!isActive()) {
>>>             throw new ContextNotActiveException();
>>>         }
>>>         checkContextInitialized();
>>>         if (contextual == null) {
>>>             throw ContextLogger.LOG.contextualIsNull();
>>>         }
>>>         final BeanStore beanStore = getBeanStore();
>>>         if (beanStore == null) {
>>>             throw ContextLogger.LOG.noBeanStoreAvailable(this);
>>>         }
>>>         BeanIdentifier id = getId(contextual);
>>>         ContextualInstance<?> beanInstance = beanStore.remove(id);
>>>         if (beanInstance != null) {
>>>             RequestScopedCache.invalidate();
>>>             destroyContextualInstance(beanInstance);
>>>         }
>>>     }
>>>
>>> Now the getBeanStore() method
>>> (from org.jboss.weld.context.AbstractBoundContext) returns an
>>> org.jboss.weld.context.beanstore.http.LazySessionBeanStore and this bean
>>> store does *not* contain the Foo bean (no key for its BeanIdentifier).
>>> There are other session scoped beans there that have been instantiated
>>> for the test, but Foo is missing.
>>>
>>> If subsequently the session is destroyed, the same destroy method is
>>> called on the
>>> org.jboss.weld.context.http.HttpSessionContextImpl eventually, but now
>>> the getBeanStore() method returns
>>> an org.jboss.weld.context.beanstore.http.EagerSessionBeanStore, and this
>>> one *does* contain the Foo bean.
>>>
>>> The other beans that the EagerSessionBeanStore contain are equal to the
>>> ones in the LazySessionBeanStore, the only difference is the Foo bean.
>>>
>>> Is this a bug in Weld or am I doing something wrong?
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing list
>>> weld-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20160915/88283d5f/attachment-0001.html 

From mkouba at redhat.com  Thu Sep 15 08:09:40 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 15 Sep 2016 14:09:40 +0200
Subject: [weld-dev] Not possible to destroy normal scoped beans returned
 by producer method
In-Reply-To: <CAE=-AhCSCF-Gc19FzKo=urZxgUMU9Pb00mOQiY3H9=kjwYXpRQ@mail.gmail.com>
References: <CAE=-AhCVcRxNKahBb30d5Td8hy95ezCS4dxtS43eMCdm=6zV8w@mail.gmail.com>
	<e211f659-f601-cb9c-3886-f3b806cc16b4@redhat.com>
	<CAE=-AhCwvpOeA6v4RuGbNk1Wabze5L8nOAQq4jPz9iUybBnZmg@mail.gmail.com>
	<CAE=-AhCSCF-Gc19FzKo=urZxgUMU9Pb00mOQiY3H9=kjwYXpRQ@mail.gmail.com>
Message-ID: <303b482f-624b-ded4-7f85-2262a7eb179c@redhat.com>

I see. Well, this is a bit problematic. The main problem is that Weld 
session context does not always synchronize with the underlying 
HttpSession. There is a thread local bean store which is 
"write-through", i.e. if attached any modifications are written to the 
HttpSession immediately. But in your case, the destroy operation is not 
recognized as a modification (bean instance is not found in the thread 
local bean store).

I think we can fix this particular problem - I've created WELD-2234 to 
track this issue.

I think this is undefined from spec point of view. And I'm not quite 
sure it would be possible to specify it in a clear way.

Martin

Dne 15.9.2016 v 11:58 arjan tijms napsal(a):
> Hi,
>
> Just a quick follow up, it seems that if the bean is touched in 1
> request (so it's actually constructed and in the "global" bean store for
> the session), then destroyed in another request within the same session
> that hasn't touched the bean it fails.
>
> But like you said, if the bean is touched within the same request (e.g.
> @Inject Foo foo; ... foo.toString();) then destroying it works.
>
> I'm not sure, do you think this is a bug, a spec issue, or "just the way
> things are"?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> On Thu, Sep 15, 2016 at 8:59 AM, arjan tijms <arjan.tijms at gmail.com
> <mailto:arjan.tijms at gmail.com>> wrote:
>
>     Hi,
>
>     The produced Foo should have been used before it's destroyed, but
>     I'll double check it's also used right before the destroy method is
>     called in the same thread. I'll try to make a simple reproducer as
>     well if it still doesn't work correctly then.
>
>     Kind regards,
>     Arjan Tijms
>
>     On Thu, Sep 15, 2016 at 8:48 AM, Martin Kouba <mkouba at redhat.com
>     <mailto:mkouba at redhat.com>> wrote:
>
>         Hi Arjan,
>
>         a simple reproducer would be helpful. There are few edge cases
>         around session context and HTTP session which are problematic
>         (e.g. HttpSession.invalidate()).
>
>         Do you call some method on the produced Foo before you call
>         destroy? Because in Weld, normal scoped instances are created
>         lazily and so does the HTTP session in case of @SessionScoped.
>
>         Thanks,
>
>         Martin
>
>         Dne 14.9.2016 v 19:14 arjan tijms napsal(a):
>
>             Hi,
>
>             I have a simple producer:
>
>             @Produced
>             @SessionScoped
>             public void Foo getFoo() { return new Foo());
>
>             If I subsequently want to destroy the Bean using:
>
>             Set<Bean<?>> beans = beanManager.getBeans(Foo.class);
>
>             Bean<?> bean = (Bean<T>) beanManager.resolve(beans);
>             Context context = beanManager.getContext(bean.ge
>             <http://bean.ge>tScope());
>
>             ((AlterableContext) context).destroy(bean);
>
>             Then in Weld 2.3.2 the destroy method of the super class
>             of org.jboss.weld.context.http.Ht
>             <http://org.jboss.weld.context.http.Ht>tpSessionContextImpl
>             is called:
>
>             org.jboss.weld.context.AbstractContext
>
>             Containing this code:
>
>                 @Override
>                 public void destroy(Contextual<?> contextual) {
>                     if (!isActive()) {
>                         throw new ContextNotActiveException();
>                     }
>                     checkContextInitialized();
>                     if (contextual == null) {
>                         throw ContextLogger.LOG.contextualIsNull();
>                     }
>                     final BeanStore beanStore = getBeanStore();
>                     if (beanStore == null) {
>                         throw ContextLogger.LOG.noBeanStoreAvailable(this);
>                     }
>                     BeanIdentifier id = getId(contextual);
>                     ContextualInstance<?> beanInstance =
>             beanStore.remove(id);
>                     if (beanInstance != null) {
>                         RequestScopedCache.invalidate();
>                         destroyContextualInstance(beanInstance);
>                     }
>                 }
>
>             Now the getBeanStore() method
>             (from org.jboss.weld.context.AbstractBoundContext) returns an
>             org.jboss.weld.context.beanstore.http.LazySessionBeanStore
>             and this bean
>             store does *not* contain the Foo bean (no key for its
>             BeanIdentifier).
>             There are other session scoped beans there that have been
>             instantiated
>             for the test, but Foo is missing.
>
>             If subsequently the session is destroyed, the same destroy
>             method is
>             called on the
>             org.jboss.weld.context.http.Ht
>             <http://org.jboss.weld.context.http.Ht>tpSessionContextImpl
>             eventually, but now
>             the getBeanStore() method returns
>             an
>             org.jboss.weld.context.beanstore.http.EagerSessionBeanStore,
>             and this
>             one *does* contain the Foo bean.
>
>             The other beans that the EagerSessionBeanStore contain are
>             equal to the
>             ones in the LazySessionBeanStore, the only difference is the
>             Foo bean.
>
>             Is this a bug in Weld or am I doing something wrong?
>
>             Kind regards,
>             Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
>             _______________________________________________
>             weld-dev mailing list
>             weld-dev at lists.jboss.org <mailto:weld-dev at lists.jboss.org>
>             https://lists.jboss.org/mailman/listinfo/weld-dev
>             <https://lists.jboss.org/mailman/listinfo/weld-dev>
>
>
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic