September 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-383) Clarify that session context is also destroyed at shutdown/undeploy

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-383?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-383: ---------------------------------- Well, an HTTP session does not have to be destroyed after a container is shut down. This is not defined in the servlet spec and I did not find anything relevant in the Java EE spec. See also CDITCK-482 comments. However, if we redefine this and state that it's destroyed after an HTTP session is invalidated, we would probably break backward compatibility (see also CDI-497). > Clarify that session context is also destroyed at shutdown/undeploy > ------------------------------------------------------------------- > > Key: CDI-383 > URL: https://issues.jboss.org/browse/CDI-383 > Project: CDI Specification Issues > Issue Type: Bug > Components: Contexts > Affects Versions: 1.1.PFD > Reporter: Marko Lukša > > Section 6.7.2. states "The session context is destroyed > when the HTTPSession times out, after all HttpSessionListener s have been called, and at the very end of any request > in which invalidate() was called, after all filters and ServletRequestListener s have been called." > The first part of the above sentence should not only say that the context is destroyed after all listeners have been called specifically in the event of a session timeout. It should specify that this is also true when the session is being destroyed as a result of server shutdown or web-app undeploy. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-532) Support multiple container in Java SE

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-532?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-532: ---------------------------------- Note that Weld SE 2.3 already supports multiple *isolated* containers. The containers may share the bean classes. However, a user is required to assign a unique ID per container started. See also http://weld.cdi-spec.org/news/2015/04/21/weld-300Alpha8/#_enhanced_api_fo.... I did not study jigsaw but if the requirement is to be able to run multiple isolated containers in one JVM, it does not really matter (it should work similarly in any modular environment). > Support multiple container in Java SE > ------------------------------------- > > Key: CDI-532 > URL: https://issues.jboss.org/browse/CDI-532 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Java SE Integration > Affects Versions: 1.2.Final > Reporter: Antoine Sabot-Durand > > We should propose a solution to support multiple container in Java SE. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.sy... ] Martin Kouba edited comment on CDI-561 at 9/17/15 4:53 AM: ----------------------------------------------------------- bq. Being able to capture an instance state to use its information outside CDI or as an event payload... I believe this should be the responsibility of a user and not a CDI container. AFAIK there's no reliable way to do this automatically. was (Author: mkouba): bq. Being able to capture an instance state to use its information outside CDI or as an event payload... I think this should be the responsibility of a user and not a CDI container. AFAIK there's no reliable way to do this automatically. > Add the possibility to unmanage a bean instance > ----------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-561: ---------------------------------- bq. Being able to capture an instance state to use its information outside CDI or as an event payload... I think this should be the responsibility of a user and not a CDI container. AFAIK there's no reliable way to do this automatically. > Add the possibility to unmanage a bean instance > ----------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-562) Add the possibility to retrieve {{Bean<T>}} from one of its instance

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-562?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-562: ---------------------------------- I think there are two similar open issues which might offer a better solution for this use case: # CDI-515 - allow to obtain Bean metadata from {{javax.enterprise.inject.Instance}}, so that if a user wants to get the metadata the programmatic lookup would help # CDI-10 - if we introduce a marking interface for client proxies, e.g. {{BeanProxy}}, we could also probably add {{getBean()}} method I'm not so sure it's a good idea to add a method to the BeanManager. Let's have the following producer: {code:java} clas FooProducer { @Alpha // qualifier @Produces Foo produceAlphaFoo() { ... } @Bravo // qualifier @Produces Foo produceBravoFoo() { ... } } {code} How to identify a bean for any {{Foo}} instance? We would have to use some internal construct even for contextual instances of dependent beans with no interceptors/decorators. And that's not possible - such a bean does not have to be proxyable. Or am I missing something? > Add the possibility to retrieve {{Bean<T>}} from one of its instance > -------------------------------------------------------------------- > > Key: CDI-562 > URL: https://issues.jboss.org/browse/CDI-562 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > > Since CDI 1.1 it's possible to inject its meta data in a bean instance wit {{@Inject Bean<T> meta;}}. Its very useful to get information like actual class or qualifier on the current bean. > This feature is great when we own the code and can add the injection point but when the bean is defined in a third party lib this information are not reachable. > It would be nice to have a method in the {{BeanManager}} or elsewhere being able to return the Bean<T> corresponding to a T instance or {{null}} if the instance is not managed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-562) Add the possibility to retrieve {{Bean<T>}} from one of its instance

by Antoine Sabot-Durand (JIRA)

Antoine Sabot-Durand created CDI-562: ---------------------------------------- Summary: Add the possibility to retrieve {{Bean<T>}} from one of its instance Key: CDI-562 URL: https://issues.jboss.org/browse/CDI-562 Project: CDI Specification Issues Issue Type: Feature Request Components: Beans Affects Versions: 2.0-EDR1, 1.2.Final Reporter: Antoine Sabot-Durand Since CDI 1.1 it's possible to inject its meta data in a bean instance wit {{@Inject Bean<T> meta;}}. Its very useful to get information like actual class or qualifier on the current bean. This feature is great when we own the code and can add the injection point but when the bean is defined in a third party lib this information are not reachable. It would be nice to have a method in the {{BeanManager}} or elsewhere being able to return the Bean<T> corresponding to a T instance or {{null}} if the instance is not managed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-561) Add the possibility to unmanage a bean instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-561: ------------------------------------- Summary: Add the possibility to unmanage a bean instance (was: Add the possibility to unmanage an instance) > Add the possibility to unmanage a bean instance > ----------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-561) Add the possibility to unmanage an instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-561: ------------------------------------- Description: CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful * Accessing the true class of the instance in a clean way * Being able to capture an instance state to use its information outside CDI or as an event payload The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. was: CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful * Accessing the true class of the instance in a clean way * Being able to capture an instance state to use its information outside CDI or as an event payload The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. > Add the possibility to unmanage an instance > ------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-561) Add the possibility to unmanage an instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-561: ------------------------------------- Fix Version/s: 2.0 (discussion) > Add the possibility to unmanage an instance > ------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (CDI-561) Add the possibility to unmanage an instance

by Antoine Sabot-Durand (JIRA)

[ https://issues.jboss.org/browse/CDI-561?page=com.atlassian.jira.plugin.sy... ] Antoine Sabot-Durand updated CDI-561: ------------------------------------- Description: CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful * Accessing the true class of the instance in a clean way * Being able to capture an instance state to use its information outside CDI or as an event payload The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. > Add the possibility to unmanage an instance > ------------------------------------------- > > Key: CDI-561 > URL: https://issues.jboss.org/browse/CDI-561 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Beans > Affects Versions: 1.2.Final, 1.1.Final, 2.0-EDR1 > Reporter: Antoine Sabot-Durand > Fix For: 2.0 (discussion) > > > CDI implementations make heavy uses of proxies to support normal scope and interceptor decorators. There are use case where being able to have a bean instance without its proxy could be useful > * Accessing the true class of the instance in a clean way > * Being able to capture an instance state to use its information outside CDI or as an event payload > The limitation we have on Async event is probably a good example. As we don't propagate active normal context at firing time, it's not possible to inject a bean with such a scope (except {{@ApplicationScoped}} since Application context is shared), it could be useful to give the possibility to copy such a bean instance to a standard pojo instance so it could be used as event payload for instance. > We could even imagine that the mechanism could be transparently activated if an asynchronous observer inject a {{@RequestScoped}} or {{@SessionScoped}} bean. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev September 2015