November 2015 - cdi-dev - Jboss List Archives

[JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.sy... ] Martin Kouba commented on CDI-570: ---------------------------------- -1 for introducing "graceful" shutdown into CDI SE or something like @AbortAfter - this could bring a pile of other questions and problems, e.g. what about async events with custom Executor. > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-570: ----------------------------------- Yes, it's a whole category of problems. This not only affects shutdown but also normal runtime. If a synchronous event gets stuck then you can easily detect it. But if an async event get stuck then it might remain unnoticed for quite some time. Deadlocks might also occur much easier. We might probably think about introducing something like @AbortAfter(60000) ? Of course it makes all the CDI impls more heavyweight once we start with such things. > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.sy... ] Tomas Remes commented on CDI-570: --------------------------------- Yes I tend to agree with Mark. These are good questions and I am not really sure if we can specify something like "graceful" shutdown. > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-571) Producer and Disposer methods as remote business methods

by Tomas Remes (JIRA)

[ https://issues.jboss.org/browse/CDI-571?page=com.atlassian.jira.plugin.sy... ] Tomas Remes updated CDI-571: ---------------------------- Description: Currently it's possible to declare remote business method as a Producer or Disposer method: {quote} if a non-static method of a session bean class is annotated @Produces, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error. {quote} The question is whether it makes sense. IMO and with regarding to https://issues.jboss.org/browse/CDI-545 It doesn't. was: Currently it's possible to declare Producer and Disposal for remote business method: {quote} if a non-static method of a session bean class is annotated @Produces, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error. {quote} The question is whether it makes sense. IMO and with regarding to https://issues.jboss.org/browse/CDI-545 It doesn't. > Producer and Disposer methods as remote business methods > -------------------------------------------------------- > > Key: CDI-571 > URL: https://issues.jboss.org/browse/CDI-571 > Project: CDI Specification Issues > Issue Type: Clarification > Affects Versions: 1.2.Final, 2.0-EDR1 > Reporter: Tomas Remes > > Currently it's possible to declare remote business method as a Producer or Disposer method: > {quote} > if a non-static method of a session bean class is annotated @Produces, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error. > {quote} > The question is whether it makes sense. IMO and with regarding to https://issues.jboss.org/browse/CDI-545 It doesn't. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-571) Producer and Disposer methods as remote business methods

by Tomas Remes (JIRA)

Tomas Remes created CDI-571: ------------------------------- Summary: Producer and Disposer methods as remote business methods Key: CDI-571 URL: https://issues.jboss.org/browse/CDI-571 Project: CDI Specification Issues Issue Type: Clarification Affects Versions: 2.0-EDR1, 1.2.Final Reporter: Tomas Remes Currently it's possible to declare Producer and Disposal for remote business method: {quote} if a non-static method of a session bean class is annotated @Produces, and the method is not a business method of the session bean, the container automatically detects the problem and treats it as a definition error. {quote} The question is whether it makes sense. IMO and with regarding to https://issues.jboss.org/browse/CDI-545 It doesn't. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling

by Mark Struberg (JIRA)

[ https://issues.jboss.org/browse/CDI-570?page=com.atlassian.jira.plugin.sy... ] Mark Struberg commented on CDI-570: ----------------------------------- This has not much to do with the CDI spec. It's imo a container implementation detail. How long should the shutdown wait on an async event? What if an async event hangs? Should the server still shut down? > Weld shutdown in Java SE during asynch event calling > ---------------------------------------------------- > > Key: CDI-570 > URL: https://issues.jboss.org/browse/CDI-570 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Events > Affects Versions: 2.0-EDR1 > Reporter: Michael Remijan > > In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-370) Expand @RequestScoped and @SessionScoped to account for WebSocket

by MohanKumar Gundappa (JIRA)

[ https://issues.jboss.org/browse/CDI-370?page=com.atlassian.jira.plugin.sy... ] MohanKumar Gundappa commented on CDI-370: ----------------------------------------- Is there any alternate solution till this get's fixed? > Expand @RequestScoped and @SessionScoped to account for WebSocket > ----------------------------------------------------------------- > > Key: CDI-370 > URL: https://issues.jboss.org/browse/CDI-370 > Project: CDI Specification Issues > Issue Type: Feature Request > Reporter: Joseph Snyder > Assignee: Antoine Sabot-Durand > > We've been testing injection into a WebSocket endpoint. > @ReqestScoped objects are usable within the @OnOpen callback. This is because this object is executed within a valid request scope. > However if you try to use the injected object from within the @OnMessage callback you get a Weld error: > SEVERE: org.jboss.weld.context.ContextNotActiveException: > WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped > Can the definition of when @RequestScoped is active be expanded to include a WebSocket @OnMessage callback? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-570) Weld shutdown in Java SE during asynch event calling

by Michael Remijan (JIRA)

Michael Remijan created CDI-570: ----------------------------------- Summary: Weld shutdown in Java SE during asynch event calling Key: CDI-570 URL: https://issues.jboss.org/browse/CDI-570 Project: CDI Specification Issues Issue Type: Feature Request Components: Events Affects Versions: 2.0-EDR1 Reporter: Michael Remijan In a Java SE environment, there is no way to tell if there are async observers are in the process of being called when the time comes for the JVM to shut down. My assumption is the JVM should wait until all the async observers are complete before shutting down. Or perhaps this behavior can be configured through the CDI object, system property, or beans.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (CDI-37) Stateless scope

by Stephan Knitelius (JIRA)

[ https://issues.jboss.org/browse/CDI-37?page=com.atlassian.jira.plugin.sys... ] Stephan Knitelius commented on CDI-37: -------------------------------------- I guess his primary concern is that all the scopes imply that they are stateful in their respective contexts. Functionally @RequestScoped does the job, apart from its implied statefulness within a request. > Stateless scope > --------------- > > Key: CDI-37 > URL: https://issues.jboss.org/browse/CDI-37 > Project: CDI Specification Issues > Issue Type: Feature Request > Components: Contexts > Affects Versions: 1.0 > Reporter: Adam Warski > Fix For: 2.0 (discussion) > > > From a discussion on weld-dev (http://lists.jboss.org/pipermail/weld-dev/2011-January/002825.html): > Here's my use-case: > I have some beans which are inherently stateless, e.g. "services" or factory methods. The only fields they have are injected. I am using these beans in normal-scoped passivation-capable beans, e.g. session or conversation scoped. In such case, they also have to be passivation-capable, which means either > (a) be normal-scoped (proxyable) > (b) implement Serializable and leave the bean dependent-scoped > If I go with (a) this means that I'd have to put my bean in the request, session, conversation or application scope. However none of these choices make much sense, as they indicate the my beans holds request/session/etc-scoped data - which it doesn't, as it is stateless. > So I am left with (b) - implement Serializable + dependent scope. But is that the right thing to do always? Firstly, if I have a lot of such stateless beans, which are injected one into another, serializing a simple session-scope bean may mean that half the beans in my application get serialized. Secondly, a developer looking at such a bean could wonder why is this bean serializable? Esp if it doesn't have any state? > Hence what I'd like in fact is a proxyable scope (normal), which on serialization would only write the proxy information, on de-serialization would inject a new instance of the bean (or from a pool), and on injection would either behave as dependent (new instance), or take beans from a pool. Just as the EJB Stateless scope (except that I don't want to make my bean an EJB). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 1 month

1
0
0 / 0

Next meeting on nov 24th

by Antoine Sabot-Durand

Hi all, I'm at Devoxx BE this week and will be at Devoxx MA next week. So next meeting will be in 2 weeks. Antoine

9 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

cdi-dev November 2015