[JBoss JIRA] (CDI-601) Add container lifecycle event fired before container destroys all contexts
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-601?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba updated CDI-601:
-----------------------------
Description: The name might be something like {{BeforeContainerShutdown}. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. (was: The name might be something like `BeforeContainerShutdown`. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts. )
> Add container lifecycle event fired before container destroys all contexts
> --------------------------------------------------------------------------
>
> Key: CDI-601
> URL: https://issues.jboss.org/browse/CDI-601
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Reporter: Martin Kouba
> Fix For: 2.0 (discussion)
>
>
> The name might be something like {{BeforeContainerShutdown}. Note that we probably cannot change the name or semantics of `BeforeShutdown`, which is fired after container destroys all contexts.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
Re: [cdi-dev] Managing Dependent Scoped Beans
by Romain Manni-Bucau
Le 16 mai 2016 10:42, "Martin Kouba" <mkouba(a)redhat.com> a écrit :
>
>
>
> Dne 16.5.2016 v 10:36 Romain Manni-Bucau napsal(a):
>
>> I see, thks.
>>
>> I dont like having 2 methods with the same semantic there but agree the
>> default is misleading for such cases.
>>
>> 1. Cant we change the default? looks like current one can break apps if
>> misunderstood and not sure changing it is worse.
>
>
> I think we cannot due to backward compatibility.
>
>
>>
>> If not
>>
>> 2. Maybe we can type the returned type with a release method in the
>> instance wrapper instead of enriching Instance API making it contextual
>> by nature?: w=instance...get();w.getValue().work();w.release(/*no
param*/);
>
>
> Sorry, I don't get it. Do you want to change Instance.get() signature and
return some kind of wrapper? A simple snippet might help.
>
Yes get a method to have the wrapper to manage a single instance:
@Inject Instance i;
...
Wrapper w = i.getSelected();
...
w.getValue().businessmetd();
...
w.release();
>>
>> That is what most framework did finally to integrate with CDI so looks
>> natural.
>>
>> Le 16 mai 2016 10:23, "Martin Kouba" <mkouba(a)redhat.com
>> <mailto:mkouba@redhat.com>> a écrit :
>>
>> Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a):
>>
>>
>> Le 16 mai 2016 10:01, "Martin Kouba" <mkouba(a)redhat.com
>> <mailto:mkouba@redhat.com>
>> <mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>> a écrit :
>>
>> >
>> > Dne 15.5.2016 v 16:14 John D. Ament napsal(a):
>> > > Hey guys
>> > >
>> > > Seems like we have some issues in JIRA all focused on
>> managing the
>> > > lifecycle of Dependent scoped beans. It also seems like
>> we have many
>> > > differing opinions about how to manage them.
>> > >
>> > > - Martin raised a PR to add a release() method to Instance
>> to help
>> > > destroy a dependent bean
>> https://github.com/cdi-spec/cdi/pull/286
>> > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289
>> to update the
>> > > spec to clarify how to manage a dependent scoped bean.
>> > >
>> > > Right now, it seems that the big disagreement is whether
>> > > Instance.destroy() can destroy objects not created by it
>> (the case
>> being
>> > > around the CDI utility class, being an impl of Instance).
I'm
>> currently
>> > > heavily against Martin's proposed changes, but want to get
>> input from
>> > > others on the group to understand their perspective.
>> > >
>> > > - Does the spec require destroy() to be called only on
>> instances
>> that it
>> > > created? When I read 5.6.1 the only requirement I see is
>> that it
>> has to
>> > > be a dependent scoped bean. Note when I ask this I'm
>> asking from the
>> > > spec perspective, its a different problem if there's some
>> issues with
>> > > implementations following suite (I would imagine there
>> needs to be some
>> > > shared global registry of dependent scoped beans for this
>> to work).
>> > >
>> > > - Do we want two methods that effectively do the same
>> thing? I don't
>> > > see a strong difference between the two.
>> >
>> > Instance.destroy() currently always destroys the contextual
>> instance.
>> > Which is not always what users expect. That's why I proposed
>> to add
>> > Instance.release() - https://github.com/cdi-spec/cdi/pull/286
,
>> > previously Instance.getBean() -
>> https://github.com/cdi-spec/cdi/pull/273.
>> >
>>
>> Since you give the instance to both I guess the intention from
user
>> point of view is obvious and then we dont need 2 methods. What
>> would be
>> the other use case?
>>
>>
>> https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614
>>
>>
>> > >
>> > > On the flipside, my change is more a spec clarification.
>> I'm thinking
>> > > more now that it belongs as a reword of 5.6.1 to clarify
>> how to use
>> > > destroy() on dependent beans, rather than where I put it.
>> I think
>> > > realistically we have all of the tools needed to manage the
>> lifecycle of
>> > > these classes, just need to clarify them for people to use.
>> > >
>> > > John
>> > >
>> > >
>> > > _______________________________________________
>> > > cdi-dev mailing list
>> > > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
>>
>> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> > >
>> > > Note that for all code provided on this list, the provider
>> licenses
>> the code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>> ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>> > >
>> >
>> > --
>> > Martin Kouba
>> > Software Engineer
>> > Red Hat, Czech Republic
>> > _______________________________________________
>> > cdi-dev mailing list
>> > cdi-dev(a)lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
>> <mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>
>>
>> > https://lists.jboss.org/mailman/listinfo/cdi-dev
>> >
>> > Note that for all code provided on this list, the provider
>> licenses
>> the code under the Apache License, Version 2
>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
>> ideas
>> provided on this list, the provider waives all patent and other
>> intellectual property rights inherent in such information.
>>
>>
>> --
>> Martin Kouba
>> Software Engineer
>> Red Hat, Czech Republic
>>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
7 years, 11 months
Re: [cdi-dev] Managing Dependent Scoped Beans
by Romain Manni-Bucau
Le 16 mai 2016 10:01, "Martin Kouba" <mkouba(a)redhat.com> a écrit :
>
> Dne 15.5.2016 v 16:14 John D. Ament napsal(a):
> > Hey guys
> >
> > Seems like we have some issues in JIRA all focused on managing the
> > lifecycle of Dependent scoped beans. It also seems like we have many
> > differing opinions about how to manage them.
> >
> > - Martin raised a PR to add a release() method to Instance to help
> > destroy a dependent bean https://github.com/cdi-spec/cdi/pull/286
> > - I raised a PR https://github.com/cdi-spec/cdi/pull/289 to update the
> > spec to clarify how to manage a dependent scoped bean.
> >
> > Right now, it seems that the big disagreement is whether
> > Instance.destroy() can destroy objects not created by it (the case being
> > around the CDI utility class, being an impl of Instance). I'm currently
> > heavily against Martin's proposed changes, but want to get input from
> > others on the group to understand their perspective.
> >
> > - Does the spec require destroy() to be called only on instances that it
> > created? When I read 5.6.1 the only requirement I see is that it has to
> > be a dependent scoped bean. Note when I ask this I'm asking from the
> > spec perspective, its a different problem if there's some issues with
> > implementations following suite (I would imagine there needs to be some
> > shared global registry of dependent scoped beans for this to work).
> >
> > - Do we want two methods that effectively do the same thing? I don't
> > see a strong difference between the two.
>
> Instance.destroy() currently always destroys the contextual instance.
> Which is not always what users expect. That's why I proposed to add
> Instance.release() - https://github.com/cdi-spec/cdi/pull/286,
> previously Instance.getBean() - https://github.com/cdi-spec/cdi/pull/273.
>
Since you give the instance to both I guess the intention from user point
of view is obvious and then we dont need 2 methods. What would be the other
use case?
> >
> > On the flipside, my change is more a spec clarification. I'm thinking
> > more now that it belongs as a reword of 5.6.1 to clarify how to use
> > destroy() on dependent beans, rather than where I put it. I think
> > realistically we have all of the tools needed to manage the lifecycle of
> > these classes, just need to clarify them for people to use.
> >
> > John
> >
> >
> > _______________________________________________
> > cdi-dev mailing list
> > cdi-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/cdi-dev
> >
> > Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> cdi-dev mailing list
> cdi-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the
code under the Apache License, Version 2 (
http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas
provided on this list, the provider waives all patent and other
intellectual property rights inherent in such information.
7 years, 11 months
[JBoss JIRA] (CDI-30) An API for managing built in contexts
by John Ament (JIRA)
[ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.sys... ]
John Ament commented on CDI-30:
-------------------------------
HI Arjan,
I always find it easier to discuss on ML's but will try to answer you here.
I think what you're asking for is to intercept at the container level and change how they initialize. I'm curious, under what cases do you not have an active request?
In addition, I think you're looking for the equivalent of {{Context.isActive}}. Part of me even wonders if swapping around the impl to be {{Context.activate()}} and {{Context.deactivate()}} may be better from a domain standpoint.
> An API for managing built in contexts
> -------------------------------------
>
> Key: CDI-30
> URL: https://issues.jboss.org/browse/CDI-30
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Nicklas Karlsson
> Assignee: John Ament
> Fix For: 2.0 (discussion)
>
>
> Add management API for built in contexts allowing them to be reused as needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months
[JBoss JIRA] (CDI-30) An API for managing built in contexts
by arjan tijms (JIRA)
[ https://issues.jboss.org/browse/CDI-30?page=com.atlassian.jira.plugin.sys... ]
arjan tijms commented on CDI-30:
--------------------------------
[~meetoblivion]
[First PR|https://github.com/cdi-spec/cdi/pull/291/files] looks good!
Would it be an idea to set a wrapped (or decorated) context controller?
What I'm looking for is a way to start contexts possibly earlier than a specific container implementation normally starts them, and stop them possibly later. If the context is started earlier in say a request, then eventually the container will also start that same context later in the request. If that will throw an exception the request will not proceed, which is of course not intended.
Likewise, when the container stops the context this will thus be too early.
With a wrapped context controller, the {{startContexts}} and {{stopContexts}} calls can be ignored for those contexts the application (extension/library) wanted to start earlier and stop later. This does of course assume that the container itself will also use this context controller instead of the current proprietary code.
Additionally, the PR does not contain the check anymore to see if the context is already active or already stopped. Is that still intended to be added? This would be particularly useful for code that needs to be portable between different containers, where one container may already have started the context at a given point, where another container has not (catching the exception would be an alternative here but is obviously not so nice).
Another point, what about letting the caller of the {{startContexts}} method optionally pass in the objects (or a lambda to obtain them) on which that context primarily depends (if any). E.g. for the request scope, pass in an {{HttpServletRequest}} instance.
> An API for managing built in contexts
> -------------------------------------
>
> Key: CDI-30
> URL: https://issues.jboss.org/browse/CDI-30
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Nicklas Karlsson
> Assignee: John Ament
> Fix For: 2.0 (discussion)
>
>
> Add management API for built in contexts allowing them to be reused as needed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 11 months